Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

[Viktor Dukhovni <[e-mail]>]

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.

    <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.

    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.

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.

-- 
	Viktor.