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

[Benjamin Kaduk <[e-mail]>]

On Thu, Feb 28, 2019 at 02:49:13PM -0800, Jim Fenton wrote:
> On 2/27/19 12:11 PM, Benjamin Kaduk wrote:
> > On Tue, Feb 26, 2019 at 03:26:05PM -0800, Jim Fenton wrote:
> >> On 2/21/19 8:55 PM, Benjamin Kaduk wrote:
> >>> ----------------------------------------------------------------------
> >>> DISCUSS:
> >>> ----------------------------------------------------------------------
> >>>
> >>> I'm pretty sad to see that the "RequireTLS: no" header field has the
> >>> name "require TLS" and the opposite semantics.  It seems like the
> >>> positvie signal that we are trying to indicate is "Ignore TLS" or "TLS
> >>> optional" or similar; why does the header field need to be named
> >>> "Require TLS" -- isn't that confusing to users?
> >> "Ignore TLS" would have the wrong semantics; even with RequireTLS: NO we
> >> want it to negotiate TLS if it can; it's just that the sender is asking
> >> that TLS transport not be required by recipient policy for this
> >> particular message. "TLS optional" is closer (and is used in the heading
> >> of Section 4.2.2), but doesn't quite capture the intended meaning, which
> >> is "don't require TLS".
> > I think even swapping the order to "TLS Required: no" would be an
> > improvement, since it's a declarative statement rather than an imperative.
> 
> 
> Works for me. That might also clear up some potential confusion where
> the spec refers to the REQUIRETLS SMTP extension and the RequireTLS
> header field. It will need to be "TLS-Required: no" so there isn't a
> space in the header field name.
> 
> >
> >>> While I understand that there can be cases where it is desired to ignore
> >>> recipient-domain indications to use TLS, such as to report problems with
> >>> the TLS capabilities of those domains, I have strong qualms about
> >>> describing this protocol as an "override" for DANE and MTA-STS, or that
> >>> such recipient-domain signals should be "ignored".  In effect, by
> >>> attempting to do so, this document is fundamentally modifying the
> >>> protocol semantics for (SMTP) DANE and MTA-STS, something that can only
> >>> properly be done by clearly calling out the behavior change and an
> >>> Updates: relationship with the documents whose semantics are being
> >>> modified.  Alternately, it could also be reasonable to remove claims of
> >>> "override" or "ignore" and to leave the semantics of the header field as
> >>> being that the sender requests one behavior, and the MTA can balance the
> >>> requests of the sender and recipient at their own discretion. This is
> >>> still not a great option, though, as it would seem to put multiple IETF
> >>> proposed standards at odds with each other.
> >> I don't like the "own discretion" option either; I feel like some
> >> desired behavior should be specified, even if it's as a SHOULD. Since
> >> RequireTLS: NO affects the handling of a single message, it should take
> >> precedence over a general policy published by a domain for all messages.
> > I seem to be missing some logical steps here.  Why does that conclusion
> > follow from that input?
> 
> 
> Maybe not exactly in this context, but it's common for finer-grained
> directives to take precedence over coarser ones (in routing protocols,
> for example). So it seemed at least intuitive if not exactly logical.

Generally true, though here we see a fine-grained thing in domain A and a
coarse-grained thing in related domain B (er, using the generic English
definition of "domain", not the DNS one), so it's not quite as clear-cut.

> 
> >
> >> As to whether REQUIRETLS updates those specifications, I understand from
> >> Alexey that there is some precedent for not calling out an "Updates"
> >> relationship for mail extensions such as this, and he has far more
> >> experience than I on such things.
> > I think the plan is for the IESG to chat about this topic in real-time next
> > week (I was unable to make last week's call, unfortunately).
> 
> 
> Yes, I understand the discussion was pushed out.
> 
> >
> >>> I'm also concerned about the apparent new burden placed on senders to
> >>> actively decide whether every outgoing message requires end-to-end TLS
> >>> protection or is safe to forward without TLS, especially in light of the
> >>> apparent goal (see next paragraph) of quickly achieving (near-)universal
> >>> deployment.  There doesn't seem to be much in this document to justify
> >>> the stance that the default "don't care" option should be removed.
> >> I'm unsure whether or not near-universal deployment will ever be
> >> achieved. There are important use cases (reporters in remote
> >> jurisdictions sending email to their editors, dissidents communicating
> >> among themselves, workers at some sensitive NGOs communicating with
> >> their organizations) where limited deployment among these populations
> >> would be beneficial to protect their email against MITM attacks by
> >> middle-boxes would be beneficial.
> >>
> >>> The "must chain forward to final delivery" property for the REQUIRETLS
> >>> option seems to present some incremental deployment difficulties, in that
> >>> it will be nigh-impossible to successfully deliver such a message until
> >>> there is fairly significant deployment coverage.  E.g., if any major email
> >>> hosting provider does not implement, then it will forever remain a niche
> >>> technology.  What indication to we have that this technology can succeed as
> >>> specified?  If we anticipate it becoming a part of the de facto core,
> >>> mandatory, SMTP feature set, should we not indicate that by an Updates:
> >>> relationship?
> >> See above; I'm not sure whether it will remain a niche technology or
> >> not. I'm also not sure why the deployment coverage has to do with
> >> whether there should be an Updates: relationship.
> > It's not directly related to the deployment coverage, but rather to the
> > sense of "is this something that we consider to be logically part of the
> > core minimum implementable unit?".  If the deployment of this is big enough
> > that a substantial chunk of normal Internet-wide mail traffic sets the
> > REQUIRETLS tag, then de facto you must implement it if you want to keep
> > getting mail.  That's the case that I'm worried about, though the
> > subsequent discussion has made me less certain that that will be the end
> > state of deployment that we reach.
> 
> 
> Thanks for explaining. I expect it to remain an optional feature.

That's helpful to know, thanks.

> >
> >>> I'm also unsure exactly how tightly nailed down the (non-DANE) TLS
> >>> certificate validation process is supposed to be as a result of this
> >>> document; more in the COMMENT section.  It seems that without some form
> >>> of strict certificate (host)name validation, this mechanism does not
> >>> actually mitigate the lack of server authentication by the client that's
> >>> described as a goal.
> >> In what respect is the certificate name validation not strict? DNSSEC or
> >> MTA-STS is required to make sure that the MX hostname can't be altered
> >> in a DNS response, and that should be the name on the certificate.
> > DANE and/or MTA-STS give me an MX hostname.  Do I require that exact
> > hostname to be present in the X.509 certificate presented by the TLS
> > server?  I didn't see any text in the document that clearly says the answer
> > is "yes".
> 
> 
> I see that Viktor has explained this better than I would have. (Thanks,
> Viktor).
> 
> >
> >>> I'd also like to discuss whether it's safe to require that the tag and
> >>> header be mutually exclusive.  (As per the COMMENT section,) I don't have
> >>> a great picture on what scenarios could cause that to arise, how common
> >>> they are, and what the impact would be for strict enforcement.
> >> Section 4.1 describes the behavior if the MAIL FROM option and header
> >> field are both present: the MAIL FROM option wins.
> > I'm not saying it's under-specified; I'm asking if there's a reason we need
> > to allow the combination at all.  Are there existing deployments that allow
> > it that we need to be compatible with?  Does it provide some benefit in
> > some use case?  If there's no reason to have it, it just seems like
> > needless complexity and risk of misimplementation.
> 
> 
> No existing deployments exist that we need to be compatible with in this
> respect. Since the two mechanisms have opposite effect, the combination
> should never happen.

(My preference would be to just disallow it, but I don't plan to hold a
DISCUSS point to force the change -- when I said "I'd like to discuss"
that's all I wanted.)

> >
> >>> ----------------------------------------------------------------------
> >>> COMMENT:
> >>> ----------------------------------------------------------------------
> >>>
> >>> Section 2
> >>>
> >>>    o  The certificate presented by the SMTP server MUST either verify
> >>>       successfully in a trust chain leading to a certificate trusted by
> >>>       the SMTP client or it MUST verify successfully using DANE as
> >>>       specified in RFC 7672 [RFC7672].  For trust chains, the choice of
> >>>       trusted (root) certificates is at the discretion of the SMTP
> >>>       client.
> >>>
> >>> I don't see how this requirement restricts the presented end-entity
> >>> certificate so as to eliminate the attacks that exploit "the lack of server
> >>> authentication by the client".  What does certificate have to name in order
> >>> to be trusted by the client?
> >> The certificate has to name the hostname returned by the MX record
> >> lookup that the client MTA thinks it is communicating with (or recipient
> >> domain name in the case of finding the MTA via an A record lookup). Does
> >> this requirement need to be more explicit? I thought it was obvious.
> > "verify successfully" is pretty vague.  Do I just verify the signatures
> > along the chain?  Do I need to check those fiddly keyUsage bits?  Do I care
> > what the CN/SAN is?  We cite RFC 6125 in Section 4.2.1, but it's probably
> > prudent to reference it here as well.
> 
> 
> See Viktor's response.
> 
> >
> >>> Section 4.1
> >>>
> >>>    Upon receipt of the REQUIRETLS option on a MAIL FROM command during
> >>>    the receipt of a message for which the return-path is not empty
> >>>    (indicating a bounce message), an SMTP server MUST tag that message
> >>>    as needing REQUIRETLS handling.
> >>>
> >>> What processing should happen when REQUIRETLS is received and the
> >>> return-path *is* empty?
> >> Ben Campbell caught this as well; the exemption for bounce messages in
> >> this section needs to be removed.
> >>>            If the REQUIRETLS MAIL FROM parameter is specified, the
> >>>    RequireTLS header field MUST be ignored but MAY be included in onward
> >>>    relay of the message.
> >>>
> >>> How could this scenario arise?  (Why is it not a user error to attempt to
> >>> use both -- isn't one requiring TLS and the other disclaiming its use,
> >>> making them mutually incompatible?)
> >> It shouldn't normally happen, but I thought it worthwhile to define the
> >> behavior of the protocol in this case anyway.
> > I agree that it's worthwhile.  Could it be a hard error instead of this?
> > (Per https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/)
> 
> 
> It could, but two mechanisms occur at different stages (envelope and
> message data). The error would not be reported until the end of the DATA
> stage of message transmission, although I suppose that's OK. We should
> probably allocate another error subcode if we're going to do that.

Understood.

-Benjamin

[more good stuff trimmed]