Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

[Jim Fenton <[e-mail]>]

On 03/25/2016 11:24 AM, Viktor Dukhovni wrote:
> On Thu, Mar 24, 2016 at 07:12:43PM -0700, Jim Fenton wrote:
>
>> Not to distract from the STS discussion, but I thought I'd point out
>> another approach to SMTP TLS 'encouragement' that I submitted a few
>> weeks ago: draft-fenton-smtp-require-tls-01. There has been some
>> discussion of this draft, primarily on the ietf-smtp mailing list and a
>> little on the perpass list.
> Parallel discussion is not unprecedented on IETF lists...
>
>> REQUIRETLS is an SMTP service extension that allows an SMTP client to
>> specify (via a MAIL FROM option) that a given message must be sent over
>> a TLS protected session with specified security characteristics. Options
>> allow the specification of allowable methods of server certificate
>> verification, including web-PKI and DANE. In advertising its support for
>> REQUIRETLS, the SMTP server is promising to honor that requirement.
> Section 2. 
>
>     <quote>
>        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.
>     </quote>
>
>     Does requiring DNSSEC cover just the MX RRset, or also the
>     address records of the individual MX hosts.  I ask because
>     in Section 3 you say:
>
>     <quote>
>        o  Look up the SMTP server to which the message is to be sent.  If
> 	  the DNSSEC option is included in the message tag, all lookups in
> 	  this process MUST use DNSSEC verification and the response MUST be
> 	  DNSSEC-signed.
>     </quote>
>
>     If the entire goal is to ensure the integrity of the RFC 6125
>     "reference identifier" used to authenticate the nexthop SMTP
>     server, then it is perhaps a good idea to say so explicitly.

The primary purpose was indeed to ensure the integrity of the reference
identifier; this is discussed in the Security Considerations (section
6.2, paragraph 3). The rationale is that the address records are less of
a concern because the client will be verifying the server's certificate.
But that won't always be the case, so I'm on the fence about whether to
require address verification or not. If the MX record points to an
address in the same DNS zone, it'll be covered by DNSSEC, of course, but
MX records often point off to a service provider, and requiring DNSSEC
there might be an additional barrier to deployment.

>
>     <quote>
>        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.
>     </quote>
>
>     This is reasonably clear, either suffices when both are specified.
>     I am concerned that giving the user the choice to specify either
>     alone, rather than just a single "AUTHENTICATED" (or similar)
>     keyword, may be too much rope.  The "REQUIRETLS" service
>     extension, just by requiring authenticated TLS on every single
>     hop, is already typically equivalent to "BOUNCEME", and making
>     delivery even less likely by giving the sender control over
>     the authentication mechanism is I believe counterproductive.

I'm chuckling about calling it BOUNCEME, but it's an apt description at
present, since there is no REQUIRETLS deployment and the messages will
be bounced for that reason alone.

By not using the CHAIN and DANE options, certificate verification is not
required, so if too many messages are being bounced with those options,
they'll not see use. But without those options, we're limiting the
effectiveness of REQUIRETLS to passive attacks only; MITM attacks will
still be possible.

I have received suggestions that there also be options to require
specific TLS version, cipher suites, PFS, etc. as well, and my gut feel
is that's getting too specific.

>
>     If STS enters the mix, would that need to be added as yet
>     another keyword?  Would STS be an alternative to DNSSEC (to
>     protect the reference identifiers via its MX host constraints)
>     or an alternative to CHAIN/DANE?
>
>     The reason I mention this, is to illustrate that this level of
>     specificity in the client's REQUIRETLS request is IMHO unwise.
>
>     A much more pragmatic approach (at the cost of some uncertainty
>     about which mechanisms are used on any given hop) is to leave
>     the authentication details unspecified.  Given how little
>     experience and deployment we have for authenticated MTA-to-MTA
>     SMTP, I strongly suggest a more "generic" approach to
>     authentication.

I have had some discussions with the STS folks and have been thinking
about ways the two proposals might be complementary. Using REQUIRETLS to
require the use of TLS, and STS to specify the type of authentication,
is an interesting idea along those lines.
>
> Section 3.4.  Delivery of REQUIRETLS messages
>
>     <quote>
>        Messages are usually delivered to end users using protocols other
>        than SMTP such as IMAP [RFC3501], POP [RFC1939], or web mail systems.
>        Mail delivery agents supporting REQUIRETLS SHOULD require that
>        message delivery take place over authenticated, encrypted channels.
>     </quote>
>
>     Terminology problem.  This confuses delivery protocols with
>     access protocols.  IMAP and POP are not delivery protocols.
>     The only IETF delivery protocol is LMTP.

Good observation; thanks.

-Jim