Subject: Re: [Uta] Fwd: New Version Notification for draft-fenton-smtp-require-tls-02.txt

From: Jeremy Harris <[email-masked]>
Date: Fri, 2 Sep 2016 16:45:16 +0100

On 16/08/16 23:09, Jim Fenton wrote:
> Name:		draft-fenton-smtp-require-tls
> Revision:	02

A prototype implementation is available at
http://git.exim.org/users/jgh/exim.git

branch "ietf_requiretls"
build with EXPERIMENTAL_REQUIRETLS

If anyone else has a prototype running, I can do
interop testing.
-- 
Cheers,
  Jeremy

---

From: Jim Fenton <[email-masked]>
Date: Sun, 18 Sep 2016 15:47:41 -0700

Apologies for the very late reply; this slipped through the cracks somehow.

On 8/22/16 7:53 AM, Jeremy Harris wrote:
> - Section 2, bullet point discussing the DNSSEC parameter:
>
>   Should the requirement for dnssec to extend also to SRV,
>   A and AAAA lookups?

Yes; I'm not sure why I singled out MX and CNAME because I know those
aren't the only ways of locating the server. I would propose to change
"confirm that any MX record or CNAME lookup used to locate the SMTP
server" to "confirm that and DNS record lookup(s) used to locate the
SMTP server".
>
>
> - Section 3.2, last paragraph (onward transmission must use
>   REQUIRETLS):
>
>   Should this have a "MUST" ?

That requirement should have been made elsewhere, but I agree it
wouldn't hurt to use more normative language here.
>
>
> - Section 3.3, on introducing the need to REQUIRETLS to a
>   message transmission chain:
>
>   Currently the only actor described as having this authority
>   is the sourcing MUA.   What about a MAY permitting an MTA to
>   either introduce or upgrade the requirement associated with
>   a message?   Probably best to also specifically "MUST NOT"
>   any downgrade or removal, too.

The phrase "or based on policy" was intended to allow an MTA to
introduce a REQUIRETLS option, but that perhaps isn't clear enough.
Downgrades are definitely a no-no, doesn't hurt to emphasize that.
>
>
> - Should a receiving MTA be required to mark up the
>   Received:  header it adds in some specific way for
>   REQUIRETLS messages?

It would help to diagnose problems. In some circumstances it couldn't be
depended upon (a bad actor MTA could downgrade REQUIRETLS and strip
header fields from Received: header fields as well) but as I have said,
if the MTA you're entrusting your message to is a bad actor, you need
more than transport-level security anyway.

But I'm not clear on the extent to which the content of Received: header
fields is standardized. I don't see any mention in RFC 3207 of
annotating them to indicate the use of STARTTLS (even though I typically
see that), and without that having such a requirement in REQUIRETLS
seems out of place. Does anyone know if that requirement exists elsewhere?

Thanks for the very helpful review.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 18 Sep 2016 20:35:16 -0400

> On Sep 18, 2016, at 6:47 PM, Jim Fenton <[email-masked]> wrote:
> 

No other DNS records are used by MTAs to locate the nexthop relay
for a destination domain.  SRV records are used exclusively (and rarely,
given the paucity of adoption of RFC6186) by MUAs.  Since it is the
MUA that signals the required TLS policy in the first place, the MUA
also determines what constitutes sufficient security for the initial
MUA -> MSA hop.  It is not clear that this specification, which I think
defines the responsibilities of the MTA on the receiving end of this
policy, need also cover the responsibilities of the MSA.

Sorry, have not yet read the draft, more comments at that time.
I still think that any such mechanism needs to be able to not only
request a greater protection for a given messages, but also to request
lesser protection, prioritizing delivery over security.  On the
MUA -> MSA link, the administrator may, as a matter of local policy,
configure a policy to refuse messages that request security downgrades.
Other MTAs would not have such liberty.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 18 Sep 2016 21:38:25 -0400

> On Aug 22, 2016, at 10:53 AM, Jeremy Harris <[email-masked]> wrote:
> 
>> draft-fenton-smtp-require-tls
ion
> Abstract
> 
>    The SMTP STARTTLS option, used in negotiating transport-level
>    encryption of SMTP connections, is not as useful from a security
>    standpoint as it might be because of its opportunistic nature;
>    message delivery is prioritized over security.

Delivery is not prioritized over security when the sending domain's
policy requires TLS for the given destination; or when the receiving
domain publishes DANE or (less reliably for initial delivery) STS
policy.  What's opportunistic in the presence of DANE or STS is the
use of the stronger requirement dynamically, destination by destination,
via discovery of the destination's policy.

>    This document
>    describes a complementary SMTP service extension, REQUIRETLS.  If the
>    REQUIRETLS option is used when sending a message, it causes message
>    transmission to fail if a TLS connection with the required security
>    characteristics cannot be completed with the next hop MTA, or if that
>    MTA does not also advertise that it supports REQUIRETLS.  Message
>    originators may therefore expect transport security to be used for
>    messages sent with this option.

So I think the abstract can start with this text.  I think that
"next hop" should be "next-hop".  And of course, I still think
that the specification should be able to specify both upgrade
and downgrade of TLS policy, so not "REQUIRETLS", but

	TLS=MAY|MUST

or perhaps

	TLS=MAY|ENCRYPT|SECURE

where "ENCRYPT" can be unauthenticated, but "SECURE" requires
an authenticated connection.

> 1.  Introduction
> 
>    The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a
>    means by which an SMTP server and client can establish a Transport
>    Layer Security (TLS) protected session for the transmission of email
>    messages.  In this application, TLS is used only upon mutual
>    agreement (successful negotiation) between the client and server; if
>    this is not possible, the message is sent unencrypted.

Once again, while RFC3207 is silent on TLS policy, (IMHO rather wisely
defining only the mechanism), it is not the case the result is always
cleartext fallback.  Indeed, in some industries, it is rather common
to arrange bilateral mandatory TLS policies between peer organizations.

>    Even if a TLS
>    protected session is established, it is uncommon for the client to
>    abort the SMTP session if certificate validation fails to
>    authenticate the SMTP server.

This is a feature, not a bug, it has led to rather wide adoption of
SMTP TLS encryption.  There's no need to disparage the state of TLS
in SMTP.  Rather, just start with the case for this extension.

>    The opportunistic nature of SMTP TLS enables several "on the wire"
>    attacks on SMTP security between MTAs.  These include passive
>    eavesdropping on connections for which TLS is not used, interference
>    in the SMTP protocol to prevent TLS from being negotiated (presumably
>    followed by eavesdropping), and insertion of a man-in-the-middle
>    attacker taking advantage of the lack of server authentication by the
>    client.  Attacks are more described in more detail in the Security
>    Considerations section of this document.

This is adequately covered in Section 1.3 of RFC7672 and likely need
not be repeated here.

>    The REQUIRETLS SMTP service extension allows the SMTP client to
>    specify that a given message sent during a particular session MUST be
>    sent over a TLS protected session with specified security
>    characteristics.  It also requires that the SMTP server advertise
>    that it also supports REQUIRETLS, in effect promising that it will
>    honor the requirement to require STARTTLS and REQUIRETLS for all
>    onward transmissions of messages specifying that requirement.

Thus I think you should start with and expand on the need for per-message
policy signaling.

>    o  Any server authentication requirements specified as an option to
>       the REQUIRETLS option (see below) MUST have been satisfied in
>       establishing the current session.

Again change REQUIRETLS to TLS or TLSPOLICY as an attribute-value
pair with the policy in question as the value.

>    An optional parameter to the REQUIRETLS MAIL FROM option specifies
>    the requirements for server authentication that MUST be used for any
>    onward transmission of the following message.

In which case the parameter ceases to be optional.

>    The parameter takes
>    the form of either a single value or comma-separated list, separated
>    from the REQUIRETLS option by a single "=" (equals-sign) character.
>    If present, the parameter MUST take one or more of the following
>    values:

Multiple values seem needlessly complex.  This mechanism should not
be over-engineered.

>    o  CHAIN - The certificate presented by the SMTP server MUST verify
>       successfully in a trust chain leading to a certificate trusted by
>       the SMTP client.  The choice of trusted (root) certificates by the
>       client is at their own discretion.  The client MAY choose to use
>       the certificate set maintained by the CA/B forum [citation needed]
>       for this purpose.

See above for the MAY|ENCRYPT|SECURE trichotomy, anything more is much
to complex to be usable.  An overly detailed specification will make
this specification unusable, and thus futile.  In particular, only
the need for authentication can reasonably be specified, the mechanism
(WebPKI, DANE, STS).

>    o  DANE - The certificate presented by the SMTP server MUST verify
>       succesfully using DANE as specified in [RFC7672].

Much as I am spend my time promoting DANE, this is a mistake.  Such
a requirement is overly prescriptive.

>    o  DNSSEC - The server MUST confirm that any MX record or CNAME
>       lookup used to locate the SMTP server must be DNSSEC [RFC4035]
>       signed and valid.

This too is most likely misguided.

>    The CHAIN and DANE parameters are additive; if both are specified,
>    either method of certificate validation is acceptable.  If neither
>    CHAIN nor DANE is specified, the certificate presented by the SMTP
>    server is not required to be verified.

See above.

> 3.1.  REQUIRETLS Receipt Requirements
> 
>    Upon receipt of a REQUIRETLS option on a MAIL FROM command during the
>    receipt of a message, an SMTP server MUST tag that message as
>    requiring TLS transmission with the specified option(s).  The manner
>    in which this tagging takes place is implementation-dependent.  If
>    the message is being locally aliased and redistributed to multiple
>    addresses, all instances of the message MUST be tagged in the same
>    manner.

This is not always possible.  Once a message leaves the world of SMTP
relaying, and is handed off to delivery agents, it is no longer possible
to convey the TLS requirements, but some delivery agents re-inject email
back into the email system for further delivery.  This is quite common
with mailing lists, or gateways to SMS systems, ...  Indeed it is not
clear that one should be able to specify mandatory TLS only as far as
the list server and not beyond.

> 3.2.  REQUIRETLS Sender Requirements
> 
>    When sending a message tagged with a TLS requirement, the sending
>    (client) MTA MUST:
> 
>    o  Look up the SMTP server to which the message is to be sent.  If
>       the DNSSEC option is included in the message tag, the MX record
>       lookups in this process MUST use DNSSEC verification and the
>       response(s) MUST be DNSSEC-signed in order to ensure the integrity
>       of the resource identifier [RFC6125] used to authenticate the SMTP
>       server.

Again the use of DNSSEC should not be specified.  The MTA is responsible
for achieving "MAY|ENCRYPT|SECURE" via some suitable mechanism.  Anything
more specific will defeat this enterprise by making too much email
undeliverable.

> 7.  Security Considerations
> 
>    The purpose of REQUIRETLS is to improve communications security for
>    email by giving the originator of a message an expectation that it
>    will be transmitted in an encrypted form "over the wire".  When used,
>    REQUIRETLS changes the traditional behavior of email transmission,
>    which favors delivery over the ability to send email messages using
>    transport-layer security, to one in which messages are not
>    transmitted unless the required security is available.

This will need to change if the extension is made more flexible to
specify both upgrade and downgrade policies.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 19 Sep 2016 10:02:06 -0700

> policy, need also cover the responsibilities of the MSA.

Not specifying specific record types should work fine, then.

The MUA does get to decide what is sufficient security for the MUA ->
MSA hop, but that doesn't include whether the outgoing MTA associated
with that MSA will honor and propagate REQUIRETLS requirements
downstream. It's therefore important that the MSA advertise REQUIRETLS
support and acknowledge its responsibilities if REQUIRETLS is specified
in a message submitted to it.
> Other MTAs would not have such liberty.

I don't understand this. In practice, delivery is already prioritized
over security, so you can get that by just not using REQUIRETLS.

By "request security downgrades" do you mean negotiate a weaker cipher
suite, or (in the case of the MUA administrator) decide to ignore
certificate verification, etc.? If that's what you mean, sure, but
REQUIRETLS is all about making that apply to subsequent hops (past
submission) as well.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 19 Sep 2016 13:19:58 -0400

> On Sep 19, 2016, at 1:02 PM, Jim Fenton <[email-masked]> wrote:
> 

In the face of DANE and STS, some users may encounter transient
difficulties with mail delivery to some domains due to security
policy and the failure of the receiving domain to correctly
maintain their certificates and/or TLSA records.

Users may at times want to selectively override such policy on a
per-message basis.  Administrators of corporate outbound MSAs may
want to deny users that choice.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 19 Sep 2016 10:44:52 -0700

> via discovery of the destination's policy.

It's still opportunistic from the standpoint of a user sending a message
and asking whether the message will be transmitted securely. A large
provider is very unlikely to broadly establish policies requiring TLS
for their outgoing messages, even for specific destination domains,
because of the possibility that something will break (e.g., certificate
expiration) and cause their outgoing mail to queue. This would
potentially affect large numbers of their customers who don't care about
TLS.

Also, that only applies for the first hop. What about after that? I
would not expect the user to research the DANE or STS status of their
mail recipient. In the general case, with mail forwarders, it's not even
possible to do that.

> an authenticated connection.

Hyphenation: agree.
I don't understand the difference between TLS=MAY and not specifying
REQUIRETLS at all.
> to arrange bilateral mandatory TLS policies between peer organizations.

My experience is that cleartext fallback is common, and that it is
exploited by certain "email firewall" products as well as at a national
level in some places. I will change this to "the message is often sent
unencrypted" since the statement is too absolute now.
> in SMTP.  Rather, just start with the case for this extension.

I understand why it is the way it is, and did not disparage TLS in SMTP,
but merely stated the way that it works. Is there anything inaccurate in
that sentence?
> This is adequately covered in Section 1.3 of RFC7672 and likely need

Maybe, but it's not a lot of repetition and helps establish the motivation.
> pair with the policy in question as the value.
Are you suggesting that the name of the service extension, the MAIL FROM
option, or both?  I am reluctant to use the word "policy" because of
confusion with MTA STS and I don't think of something that applies to a
single message as much of a policy, any more than the recipient address
is a policy on where to deliver the message.
> In which case the parameter ceases to be optional.

For onward transmission of that particular message? Yes. Broadly
however, the parameter is optional: MTAs implementing REQUIRETLS are not
required to include the REQUIRETLS option on every message they send.
> Multiple values seem needlessly complex.  This mechanism should not

I noted this comment from the last version, and am looking for more
opinions on this.
> the need for authentication can reasonably be specified, the mechanism
This looks to be a reasonable simplification if rough consensus is that
we should simplify as you suggest.
> This too is most likely misguided.

Please elaborate on 'misguided': also overly prescriptive? Unlikely to
be used?
> the list server and not beyond.

See section 5 for discussion of mailing lists. It is recognized that
some MTAs may not be able to guarantee onward use of TLS; they must not
advertise REQUIRETLS or at least must not accept REQUIRETLS-tagged messages.
> more specific will defeat this enterprise by making too much email

As noted above.
> specify both upgrade and downgrade policies.

I'm still not understanding the concept of downgrade policies that
you're describing.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Mon, 19 Sep 2016 10:48:58 -0700

> want to deny users that choice.
Ah, I understand now. Please ignore my questions my subsequent message
that were sent before I read this one.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 19 Sep 2016 18:02:09 +0000

On Mon, Sep 19, 2016 at 10:44:52AM -0700, Jim Fenton wrote:

> and asking whether the message will be transmitted securely.

Actually, it is not, provided the destination domain has published
DANE (or perhaps some day STS) policy.  The user may not know which
domains have done that, though some email providers are making an
effort to expose such information to their users (e.g. at least
Postini).  The outbound MTAs of postini.de, gmx.de and others
enforce DANE policy when published by the destination domain.

> A large
> expiration) and cause their outgoing mail to queue.

And yet a few large providers already have done exactly that.

> Also, that only applies for the first hop.

Indeed.  That's the nature of opportunistic security, you get only
as much security as is possible.  See RFC7435.  In the majority of
cases there are clear benefits to not raising the bar too high.

Keep in mind that the "first hop" if often the last hop over the
public Internet.  Further hops are often internal to the receiving
network, and the threat is then much lower, and use of TLS is likely
mandatory (if ones bothers to publish externally facing DANE TLSA
records, it makes sense to protect all internal links).

-- 
	Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 20 Sep 2016 00:40:54 +0100

On 19/09/16 19:02, Viktor Dukhovni wrote:
> DANE (or perhaps some day STS) policy.

Irrelevant.  DANE provides a means for the target MX to request
encryption, REQUIRETLS provides a means for the sender to request
encryption.  Both are valuable.
-- 
Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 19 Sep 2016 19:45:27 -0400

> On Sep 19, 2016, at 7:40 PM, Jeremy Harris <[email-masked]> wrote:
> 

You've lost context.  I'm not saying that REQUIRETLS is unnecessary,
I am saying that the converse of REQUIRETLS is also necessary.  That
is a user should be able to express:

	* Security or bust, mandatory TLS all the way even of not
          mandated by standing policy.
OR
	* Delivery or bust, opportunistic TLS all the way, despite 
          any standing policy that requires (authenticated?) TLS.

-- 
	Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 30 Sep 2016 10:47:12 +0100

On 19/09/16 02:38, Viktor Dukhovni wrote:
> policy.

The draft is referring to the currently more common case where those
policies or protocols are not in use.  Possibly it could make that
explicit.

>    I still think

Why downgrade?  Currently the proposal is for an absolute
requirement of security; are you asking for an absolute
requirement for plaintext and no peer-verification?  Or
are you asking for a means of providing permission for
those (the word "MAY" suggests the latter to me)?

If the latter
- is there any difference from the current opportunistic use of
  STARTTLS, in the absence of system-policy, DANE or STS?
- is the intent to override system-policy, DANE and STS?

I am, at best, unconvinced as to the utility of a downgrade.

> an authenticated connection.

I don't like the word "SECURE"; it's not clear per. se. whether it
requires encryption, endpoint-identity-verification, or both.

> to arrange bilateral mandatory TLS policies between peer organizations.

Again the draft is speaking to the common case.
Such industries could implement REQUIRETLS as a means of enforcing
their policies, or remain with their current per-system policies,
or run with both.

> In which case the parameter ceases to be optional.

The parameter is optional in the syntax of the MAIL option.
If present during reception, its semantics require it be used
on any onward transmission.

> Multiple values seem needlessly complex.  This mechanism should not
[...]
> the need for authentication can reasonably be specified, the mechanism

Suspect you missed out a "should not be" at the end there?

> the list server and not beyond.

Partially agree.  We could make it clear that we're only covering the
SMTP end-to-end (but including alias-style exploders) and specifically
not covering mailinglist-style re-transmission.

-- 
Cheers,
  Jeremy