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.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
