Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Tue, Jul 30, 2019 at 04:11:36PM -0700, Jim Fenton wrote:
> On 7/17/19 12:18 PM, Benjamin Kaduk via Datatracker wrote:
> 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I'm glad that we were able to come to consensus to rename the header
> > field to "TLS-Required"; that addresses a key concern of mine.
> 
> 
> I like this better too.
> 
> >
> > I  also appreciate the addition of the "Policy Conflicts" section that portrays
> > a fairly clear picture of the interaction between this mechanism, DANE, and
> > MTA-STS.  I still wish that we were able to bring the technologies into greater
> > alignment and not need to convey the sense that standards-track mechanisms
> > are in conflict with each other, but cannot justify blocking publication based
> > solely on that desire.
> > In this space, though, I do request an additional wording tweak in Appendix A.2,
> > which currently states "The TLS-Required header field is used when the sender
> > of the message wants to override the default policy of the recipient domain to
> > require TLS." which uses the "override" terminology without couching it as a
> > request.  Can we reword to include "request" here as well?
> 
> 
> How about, "The TLS-Required header field is used when the sender
> requests that the mail system not heed a default policy of the recipient
> domain requiring TLS."

Works for me; thanks.

> >
> > The following paragraph (unchanged from my ballot on -07) received only minimal
> > discussion so far:
> > I'm also concerned about the apparent new burden placed on senders in
> > Section 4.3 to actively decide whether every outgoing message requires
> > end-to-end TLS protection or is safe to forward without TLS ("when TLS
> > is to be required, [...].  When TLS is not to be required, [...]"), where both
> > "[...]" require new behavior not present in a client that does not implement
> > this specification.  To some extent this is an editorial matter of how the
> > new mechanisms are portrayed, but I don't see much in this document to justify
> > the stance that the default "don't care" option should be removed (for clients
> > that implement this specification at all).
> 
> 
> The justification here is much the same as for MTA-STS (RFC 8461).
> Paragraph 2 of the introduction of RFC 8461 presents the justification,
> and paragraph 3 of the introduction to this draft says much the same thing.
> 
> This work was inspired by a paper, "Neither Snow Nor Rain Nor MITM ...An
> Empirical Analysis of Email Delivery Security"
> http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf that there was a
> presentation about at an IETF meeting a few years ago (can't find it on
> datatracker currently). If you think the draft would benefit from
> additional motivation, I could mention this paper and add an informative
> reference to it.

This makes it sound like your stance is roughly, "we want to make TLS on by
default but have to deal with deployed reality in order to get there",
which would seem to have the consequence that "MTAs implementing
require-TLS should default to requiring TLS and only request no-TLS in
special cases".  I would support such a position, and in that case would be
less concerned about the apparent lack of a "don't care" option, since
there is less of a decision burden when there is a clear default behavior.

That would also make this very solidly an editorial matter, in which case I
am happy to suggest text modifications but cannot put a blocking Discuss
position in place...

> >
> > It seems that we are in agreement that it's okay to have a "don't care" option,
> > which is indicated by not using the extension at all.  That said, I still think that
> > the specific text of Section 4.3 conveys an impression that there is a requirement
> > to actively decide, with the language about "has the authority to decide whether to
> > require TLS", "when TLS is  to be required", "when TLS is not to be required", and
> > "in either case, the decision [...] MAY be done based on [...]".   Perhaps I'm just misreading
> > the text, but I haven't seen any signals to that effect yet.  I'd suggest (but am open
> > to further refinement" changing to "has the option to decide whether to require TLS"
> > and "if one of these cases is selected, the decision [...]" as a way to clarify the language used.
> 
> 
> Here's a revision to that paragraph that I think makes it clearer that
> it's OK not to decide:
> 
> An MUA or other agent making the initial introduction of a message has
> the option to decide whether to require TLS. If TLS is to be required,
> it MUST do so by negotiating STARTTLS and REQUIRETLS and include the
> REQUIRETLS option on the MAIL FROM command, as is done for message relay.
> 
> Does that convey this adequately?

...whereas this goes in a different direction, and makes a different
editorial clarification.  So, yes, this is fine, but if we want to go the
other direction we can talk about that, too.

> 
> >
> > [discussion of "de facto part of the core SMTP spec" removed, on  indications
> > that this is not the intent]
> >
> > We had some good discussion about the three potential cases for authenticating
> > the TLS connection:
> > (1) Dane per RFC 7672
> > (2) MTA-STS per RFC 8461
> > (3) DNSSEC-validated MX records + WebPKI authentication of the MX hosts
> >
> > I think a little more specificity is needed for the (3) case; we do say to use
> > the RFC 6125 procedures but still need to specify (e.g.) that the DNS-ID name
> > type is used and (IIRC) that the hostname resulting from the MX lookup is
> > used as the DNS-ID to be validated.
> 
> 
> How about if I add the following text to 4.2.1 step 4:
> 
> The hostname from the MX record lookup (or the domain name in the
> absence of an MX record where an A record is used directly) MUST match
> the DNS-ID or CN-ID of the certificate presented by the server.

That would work pretty well.  I do have to ask/check whether deployed
reality means we have to keep CN-ID or could try to ditch it, as is slowly
happening in the web world, though.

> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > [original comment section unchanged; contents likely to be stale]
> 
> 
> In that case I'll skip trying to respond to the comments.
> 
> If the above seems OK, I'll push out a revision to the draft with those
> changes.

It's probably safe to do so, though feel free to hold off if you think
anything still requires further discussion.

Thanks!

-Ben