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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 17 Jul 2019 12:18:28 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-uta-smtp-require-tls-08: 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 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  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?

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

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.

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[original comment section unchanged; contents likely to be stale]

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.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 30 Jul 2019 16:11:36 -0700

I like this better too.

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

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

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

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

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.

-Jim

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Jul 2019 19:02:23 -0500

> requests that the mail system not heed a default policy of the recipient

Works for me; thanks.

> additional motivation, I could mention this paper and add an informative

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

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

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

> If the above seems OK, I'll push out a revision to the draft with those

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

Thanks!

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 30 Jul 2019 21:19:40 -0400

> there is less of a decision burden when there is a clear default behavior.

I don't quite understand this comment. :-(  Typically, the "Require-TLS"
signal originates at the submitting MUA, not an MTA.  MTAs may
*support* "Require-TLS", but they generally won't originate the
policy for messages in transit.

Some MSAs (or outbound edge MTAs) may add "Require-TLS" to messages
in transit for "business-partner" destinations where there's a
reasonable prior expectation that authenticated TLS is available
along the entire delivery path.  But this will be the exception,
rather than the rule.

Similar considerations apply even more strongly to explicit "don't
care", which should not be added by a transit MTA, and instead
should result from a user's choice to request delivery even in the
face of degraded transport security.

So I don't know what to make of "MTAs implementing require-TLS
should default to requiring TLS and only request no-TLS in special
cases".

Neither requiring TLS (end-to-end in the sense of the present draft)
nor requesting "no-TLS" (really requesting delivery despite lack
of or failure of authenticated TLS en-route) is somenthing that the
MTA would normally choose.  Rather the MTA, in support of the
present draft, would implement the policy conveyed in the message
envelope (require) or headers (don't care).

Sorry to be so dense, perhaps you can expand your point to make it
more clear...

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 30 Jul 2019 23:16:25 -0700

> am happy to suggest text modifications but cannot put a blocking Discuss

I'm confused by your comment (as was Viktor). My comment above was 
motivation for having a REQUIRETLS option. Nobody is suggesting that we 
get rid of or otherwise change the default "don't care" -- REQUIRETLS is 
an option, and SMTP will continue to work the way it currently does when 
REQUIRETLS is not applied to a message.

> other direction we can talk about that, too.

This was the intended direction of the clarification.

> happening in the web world, though.

The RFC 7672 definition of Reference Identifier includes the CN-ID, so 
it would be more consistent to include it when referencing 6125 as well.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 31 Jul 2019 05:08:42 -0400

On Tue, Jul 30, 2019 at 11:16:25PM -0700, Jim Fenton wrote:

> The RFC 7672 definition of Reference Identifier includes the CN-ID, so it
> would be more consistent to include it when referencing 6125 as well.

For the record, RFC7672 has aged a bit since ~2014 when most of it
was written, so at some point support for CN-ID could be reconsidered.

In that light, I took a look at the certificates currently live on
MX hosts found by the DANE survey, and of 854 certificates on MX
hosts that use DANE-TA records (for which name checks are in scope)
22 have CN-ID and no SAN.  That may be too high a rate to pull the
plug just yet. :-(

One notable example is the state of Bavaria:

  bayern.de. IN MX 10 mail.bayern.de. ; NoError AD=1
  _25._tcp.mail.bayern.de. IN TLSA 2 0 1 32a2bc1d515cdbc412b62b47a1cccf2bb1b8e3ef309f982458d3a7c61797422a ; NoError AD=1
      cert sha256 [matched] <- 2 0 1 32a2bc1d515cdbc412b62b47a1cccf2bb1b8e3ef309f982458d3a7c61797422a
      cert sha256 [matched] <- 2 0 1 32a2bc1d515cdbc412b62b47a1cccf2bb1b8e3ef309f982458d3a7c61797422a

which sports a V1 cert (no extensions, hence no SANs).  The issuer
looks like a private CA:

  C = DE
  ST = Bayern
  O = Freistaat Bayern
  CN = Bayerische DANE-CA

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 31 Jul 2019 18:02:52 -0500

> I don't quite understand this comment. :-(  Typically, the "Require-TLS"

Probably because it has no sensible interpretation; sorry about that :(

I think that the only change needed is s/MTA/MUA/, though.

> Sorry to be so dense, perhaps you can expand your point to make it

Just my tired brain being sloppy about MTA vs. MUA (and not even reading
the document properly, either).

Thank you for expending the time to write out the explanation above; I
think probably we have shed enough electrons on this topic, should take
Jim's proposed new text, and move on.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 31 Jul 2019 18:05:29 -0500

> was written, so at some point support for CN-ID could be reconsidered.

Sure.

It doesn't really have to be this document, though -- thanks to Jim for
pointing out the RFC 7672 precedent.

> 22 have CN-ID and no SAN.  That may be too high a rate to pull the

That seems likely; I don't feel a particular need to introduce skew between
reality and the text of the specification.  I guess, if the WG wants, we
could recommend SRV-ID but still allow CN-ID (but this really is up to the
WG and it is not part of a Discuss point given the 7672 precedent).

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 31 Jul 2019 19:58:07 -0400

> WG and it is not part of a Discuss point given the 7672 precedent).

I don't know which MTAs, if any, support "SRV-ID" for in peer MTA
certificates.  DNS-ID (with possible fallback on CN-ID) is the only
option for both DANE and MTA-STS.  I don't expect that the present
draft is the right vehicle for pushing for SRV-ID support between
MTAs.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 31 Jul 2019 19:02:42 -0500

> draft is the right vehicle for pushing for SRV-ID support between

Sigh, my flawed brain at work again.  Thank you for keeping me honest, and
sorry for the repeated brain-os.

-Ben