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

[Spencer Dawkins at IETF <[e-mail]>]

Not my ballot thread, but "TLS Required: no" is a LOT clearer to me. I'm
not the target audience, but the original order screws me up every time I
see it in a ballot e-mail.

Do the right thing, of course.

Spencer

On Wed, Feb 27, 2019 at 2:11 PM Benjamin Kaduk <[e-mail]> 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.
>
> > >
> > > 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?
>
> > 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).
>
> > >
> > > 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.
>
> > > 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'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.
>
> > >
> > > ----------------------------------------------------------------------
> > > 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.
>
> > >
> > > 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/)
>
> > > Section 4.2.1
> > >
> > >    2.  If the server lookup is accomplished via the recipient domain's
> > >        MX record (the usual case) and is not accompanied by a valid
> > >        DNSSEC signature, the client MUST also validate the SMTP server
> > >        name using MTA-STS as described in RFC 8461 [RFC8461]
> > >        Section 4.1.
> > >
> > > What happens if this validation fails?  Perhaps the below text "If any
> of
> > > the above fails" could include "(including MTA-STS validation)" for
> extra
> > > clarity.
> > In this case, transmission of a REQUIRETLS-tagged message fails.
> > >
> > >    3.  Open an SMTP session with the peer SMTP server using the EHLO
> > >        verb.
> > >
> > >    4.  Establish a TLS-protected SMTP session with its peer SMTP server
> > >        and authenticate the server's certificate as specified in
> > >        [RFC6125] or [RFC7672] as applicable.
> > >
> > > "STARTTLS" does not appear in here anywhere.
> > > Separately, is this combination of steps going to preclude any setups
> that
> > > (e.g., via preconfiguration) go straight to TLS with no STARTTLS
> > > negotiation?
> > Either STARTTLS or implicit TLS (i.e., on a different port) would
> > satisfy this requirement. It's because of the "straight to TLS" case
> > that STARTTLS isn't mentioned here. This is REQUIRETLS, not
> > REQUIRESTARTTLS.
>
> I'm complaining more about the transition from (3) to (4) than either one
> per se.  If I open a connection and then establish a (new?) TLS-protected
> session, that seems to mostly be STARTTLS.  But if I use implicit TLS, why
> do I need to bother with (3) at all?
>
> > > What name is used as input to certificate validation (for the 6125
> branch)?
> > > Is Appendix B.4 therein supposed to be normative?  (The Appendix B
> header
> > > indicates that the content is non-normative.)
> > 6125 Appendix B.4 just quotes RFC 4954. Perhaps I need to be normatively
> > referencing the latter instead? In any case, the intent is that the MX
> > hostname match one of the names on the certificate.
>
> Given that 4954 just talks about the client's "understanding of the server
> hostname", I'd suggest that this document explictly state that the MX
> hostname must match, independently of the question of citing 4954 and/or
> 6125 here.  (Hmm, and Section 14 of 4954, that talks about "server
> hostname", is predicated on supporting SASL [PLAIN] over TLS anyway, which
> isn't particularly general.)  So I'd be onboard with citing 4954 here
> (possibly in addition to 6125?) but there likely still needs to be some
> additional text discussion for clarity.
>
> > > Section 4.2.2
> > >
> > >    Some SMTP servers may be configured to require STARTTLS connections
> > >    as a matter of policy and not accept messages in the absence of
> > >    STARTTLS.  A non-delivery notification MUST be returned to the
> sender
> > >    if message relay fails due to an inability to negotiate STARTTLS
> when
> > >    required by the server.
> > >
> > > This is an "inability to negotiate" combined with a rejection of
> > > non-STARTTLS, right?
> > This is just a situation where the server requires that TLS be
> > negotiated, and the client isn't able to do that so delivery fails and a
> > bounce is generated. This behavior isn't specific to REQUIRETLS at all.
>
> I think we're in violent agreement here.
>
> > > Section 5
> > >
> > >    The path from the origination of an error bounce message back to the
> > >    MAIL FROM address may not share the same REQUIRETLS support as the
> > >    forward path.  Therefore, users requiring TLS are advised to make
> > >    sure that they are capable of receiving mail using REQUIRETLS as
> > >
> > > nit: "requiring TLS for outgoing mail"?
> > Sure, but if you're requiring TLS through this mechanism it's
> > necessarily for outgoing mail.
> > >
> > >    If a REQUIRETLS message is bounced, the server MUST behave as if
> > >    RET=HDRS was present as described in [RFC3461].  If both RET=FULL
> and
> > >    REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be
> > >    transformed to RET=HDRS on relay.  The SMTP client for a REQUIRETLS
> > >
> > > If the MAY is not taken, will the next hop be obligated to detect that
> this
> > > is a bounce and apply the preceding MUSTs?  If not, perhaps this also
> > > should be a MUST?
> > It seems like it should, yes.
>
> [this is covered downthread, it looks like]
>
> > >    bounce message uses an empty MAIL FROM return-path as required by
> > >    [RFC5321].  When the MAIL FROM return-path is empty, the REQUIRETLS
> > >    parameter SHOULD NOT cause a bounce message to be discarded even if
> > >    the next-hop relay does not advertise REQUIRETLS.
> > >
> > > Perhaps an internal cross-reference up to Section 4.2.1 is in order?
> > This section says, "ignore REQUIRETLS for bounce messages" so it
> > shouldn't be doing section 4.2.1. Or perhaps I misunderstand the comment.
>
> I was just noting that 4.2.1 had the complementary text that exempted
> bounce messages from certain REQUIRETLS processing; this comment may be
> overtaken by events given some of the other ballot threads, though.
>
> > >    Senders of messages requiring TLS are advised to consider the
> > >    possibility that bounce messages will be lost as a result of
> > >    REQUIRETLS return path failure, and that some information could be
> > >    leaked if a bounce message is not able to be transmitted with
> > >    REQUIRETLS.
> > >
> > > It's not really clear how actionable this is.  If you have a message
> > > that you want to send, you're either going to send it or not send it.
> > > What would you change about the message based on whether or not you
> > > could get a bounce, or whether or not the bounce would leak the message
> > > contents?
> > This is simply, "remember that you might not get a bounce". That's
> > probably true anyway.
> > >
> > > Section 6
> > >
> > >    Mailing lists, upon receipt of a message, originate new messages to
> > >    list addresses.  This is distinct from an aliasing operation that
> > >    redirects the original message, in some cases to multiple
> recipients.
> > >
> > > I'm not entirely sure how universally acknowledged this claim is; at
> > > MIT, we have lots of "mailing lists" implemented via the central Moira
> > > management database, but the actual implementation on the mailhubs is
> > > more like the aliasing operation described in the second sentence.
> > > Is there a need to make this distinction in order to support the
> > > following points, or could they stand on their own without this?
> > There are lots of cases where a new message is originated as the result
> > of a received message, mailing lists (as distinct from distribution
> > aliases) being a very common one. But there are also various other
> > things that originate new messages, like the vacation program, sieve,
> > etc. Perhaps this section should be generalized, but right now it's
> > setting context for how REQUIRETLS could be supported by mailing lists,
> > at the list operator's discretion.
>
> To be clear, I'm not asking for any change here (and this is the
> non-blocking COMMENT section anyway).  I'm just noting my experience when
> it seems slightly at odds with the text in the document.
>
> > >    The requirement to preserve the REQUIRETLS tag therefore does not
> > >    necessarily extend to mailing lists, although the inclusion of the
> > >    RequireTLS header field MAY cause messages sent to mailing lists to
> > >    inherit this characteristic.  [...]
> > >
> > > Maybe I'm confused, but doesn't the REQUIRETLS tag and the RequireTLS
> > > header field have very different characteristics?  I don't understand
> > > which one "this characteristic" is supposed to refer to.
> > Since header fields are typically copied into the messages sent by
> > mailing lists, this would happen in the case of the RequireTLS header
> > field as well.
>
> Maybe s/this characteristic/the header field/, then?
>
> > >    Mailing list operators MAY apply REQUIRETLS requirements in incoming
> > >    messages to the resulting messages they originate.  If this is done,
> > >    they SHOULD also apply these requirements to administrative traffic,
> > >    such as messages to moderators requesting approval of messages.
> > >
> > > Maybe note that such administrative traffic can include message
> contents
> > > intended for the list?
> > I'm not sure what you mean here. The main concern is the compromise of
> > metadata, i.e., that a particular user has subscribed to a list. I
> > realize this isn't perfect, and that there are other ways (such as
> > timing and size of messages) by which this could be inferred.
>
> I think that the compromise of non-meta data is also a concern, probably a
> contender for "main" concern.
>
> Consider when I send a message, with REQUIRETLS tag and sensitive contents,
> to a moderated mailing list.  Mailman (among others?) will then accordingly
> notify the moderator that a message requires action, and at least in some
> configurations will *include the entire message contents* that need
> moderation.  So I'm saying that mailman should propagate the REQUIRETLS tag
> when it's sending that "action required" message, since otherwise the
> message contents that I, the sender, thought were protected by REQUIRETLS,
> would lose that protection.
>
> > > Section 8.2
> > >
> > >    clear, where they can be intercepted.  REQUIRETLS detects the
> failure
> > >    of STARTTLS and declines to send the message rather than send it
> > >    insecurely.
> > >
> > > nit: I'd say that REQUIRETLS requires the detection and declining,
> > > rather than doing so itself.
> > Sure.
> > >
> > >                                                      REQUIRETLS
> requires
> > >    successful certificate validation before sending the message.
> > >
> > > (As mentioned above, we need greater clarity about what the validation
> > > specifically entails.)
> > Addressed above.
> > >
> > >                  REQUIRETLS requires that the recipient domain's MX
> > >    record lookup be validated either using DNSSEC or via a published
> > >    MTA-STS policy that specifies the acceptable SMTP server hostname(s)
> > >    for the recipient domain.
> > >
> > > Are we then required to use those server hostname(s) in the certificate
> > > validation portion of the TLS connection?
> > Yes.
> > >
> > > Section A.1
> > >
> > > In light of https://www.iab.org/2016/11/07/iab-statement-on-ipv6/
> please
> > > consider using IPv6 examples.
> >
> > OK, although this protocol does not reference IP addresses of any sort,
> > so the improvement would be only decorative.
>
> Indeed.
>
> -Benjamin
>
>