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

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-uta-smtp-require-tls-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/



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

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

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?

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.

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.


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

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?

           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?)

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.

   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?

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

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?

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"?

   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?

   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?

   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?

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?

   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.

   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?

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.

                                                     REQUIRETLS requires
   successful certificate validation before sending the message.

(As mentioned above, we need greater clarity about what the validation
specifically entails.)

                 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?

Section A.1

In light of https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ please
consider using IPv6 examples.