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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Feb 2019 20:55:12 -0800

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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 21 Feb 2019 00:54:17 -0500

> On Feb 20, 2019, at 11:55 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

My take is rather different.  I see "REQUIRETLS = no" as an enabler of
adoption for DANE and MTA-STS, and as the primary feature of this draft
that will have a more significant positive security impact (by paving
the way to adoption of more secure transport by default) than the
"REQUIRETLS = yes" option, which likely won't see much use.

There's no conflict with DANE and MTA-STS here, neither trumps the
senders local policy, whether set by the administrator or delegated
by the administrator to the user.

While we can hope that operational excellence will make delivery problems
due to botched MTA-STS or DANE rare, there will surely be temporary outages
here and there, and giving users a mechanism to work around them is better
than disabling transport security for all users at the first whiff of a
problem, defeating much of the protection that DANE and MTA-STS would
enable.

Providers that support a user override, can be much more confident that
enabling recipient security policy will be something their users can
work with, because on a delivery failure, the user can resend with
"REQUIRETLS = no" if the message requires little privacy protection,
but is time sensitive.  The user knows best which messages are OK to
resend without authentication (possibly in the clear).

Companies where there are regulatory constraints to not let users
override transport security policy (HIPAA, ...) can elect to not support
"REQUIRETLS = no" and even strip the header to reduce the likelihood
of it taking effect downstream.

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Feb 2019 10:24:17 +0000

Hi Benjamin,
A couple of comments on some of your DISCUSS points:

> On 21 Feb 2019, at 04:55, Benjamin Kaduk <[email-masked]> wrote:
> 
> deployment.

While I have sympathy toward the feeling that some users would be unable to decide, there are certain classes of email messages that would require either "yes" or "no" option. For example, banking statements sent in email might always require "yes".

>  There doesn't seem to be much in this document to justify

The default option is always present (as it is the default SMTP behaviour) when the client chooses not to use the extension. So "don't care" option is always possible.
> specified?

There are several SMTP extensions on Standards Track that have similar properties. IETF generally didn't require "prove that it gets deployed" for them. There are already some implementations (as per the write-up).

>  If we anticipate it becoming a part of the de facto core,

We haven't done this in the past even for widely deployed SMTP extensions. This is not a reason not to do this in the future, but I think starting with this extension would cause more confusion.

Best Regards,
Alexey

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 21 Feb 2019 06:02:39 -0600

> The default option is always present (as it is the default SMTP behaviour) when the client chooses not to use the extension. So "don't care" option is always possible.

I'm looking at Section 4.3 and reading it as requiring the MUA (or other
agent) to make an explicit "yes/no" choice; it use wording like "In either
case", etc.  Can you point me at what the "no choice" option in that text?

> There are several SMTP extensions on Standards Track that have similar properties. IETF generally didn't require "prove that it gets deployed" for them. There are already some implementations (as p…

It's just surprising to see a "your message won't get sent if the whole
path doesn't support this extension" behavior; this seems to require a
critical mass of deployment before any major usage is possible.
I don't object per se to specifying things like this, but it does make one
wonder whether we should spend so much effort on things that may be of
little use in practice.

> We haven't done this in the past even for widely deployed SMTP extensions. This is not a reason not to do this in the future, but I think starting with this extension would cause more confusion.

Perhaps this could be discussed on the call (which, sadly, I don't expect
ot be on).  I recognize that it would be weird to start a precedent here,
and of course if the intention is not that this extension become de facto
part of core SMTP then my concern disappears.

-Benjamin

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 21 Feb 2019 08:42:16 -0500

Hi Benjamin,

> > > On 21 Feb 2019, at 04:55, Benjamin Kaduk <[email-masked]> wrote:

 (snip)

> wonder whether we should spend so much effort on things that may be of

There is a bit of Catch-22 here: we need this in an RFC to see if we want widespread use.

> part of core SMTP then my concern disappears.

I can add this topic to the informal telechat next week.

Best Regards,
Alexey

---

From: Jim Fenton <[email-masked]>
Date: Tue, 26 Feb 2019 15:26:05 -0800

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

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

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

> mandatory, SMTP feature set, should we not indicate that by an Updates:
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.
> actually mitigate the lack of server authentication by the client that's
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.
> 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.
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.

> What processing should happen when REQUIRETLS is received and the
Ben Campbell caught this as well; the exemption for bounce messages in
this section needs to be removed.
> 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.
> the above fails" could include "(including MTA-STS validation)" for extra
In this case, transmission of a REQUIRETLS-tagged message fails.
> (e.g., via preconfiguration) go straight to TLS with no STARTTLS
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.
> 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.
> This is an "inability to negotiate" combined with a rejection of
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.
> nit: "requiring TLS for outgoing mail"?
Sure, but if you're requiring TLS through this mechanism it's
necessarily for outgoing mail.
> is a bounce and apply the preceding MUSTs?  If not, perhaps this also
It seems like it should, yes.
> 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.
> could get a bounce, or whether or not the bounce would leak the message
This is simply, "remember that you might not get a bounce". That's
probably true anyway.
> 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.
> 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 note that such administrative traffic can include message contents
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.
> rather than doing so itself.
Sure.
> (As mentioned above, we need greater clarity about what the validation
Addressed above.
> validation portion of the TLS connection?
Yes.
> consider using IPv6 examples.

OK, although this protocol does not reference IP addresses of any sort,
so the improvement would be only decorative.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 26 Feb 2019 18:45:57 -0500

> It seems like it should, yes.

Actually, absolutely not.  It is not the job of email *relays* to
modify the message content, and they must not be obligated to do
so.  Message modifications break DKIM signatures, and require
content processing logic that relays are not expected to support.

The bounce is constructed as a new message at the server that
encounters the initial delivery problem, it is *only* at *that*
point that the decision can be made to include or exclude the
original message body in the bounce.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 26 Feb 2019 16:03:37 -0800

> original message body in the bounce.
Good point; so we should just remove the phrase "and MAY be transformed
to RET=HDRS on relay"? It contradicts the previous MUST anyway.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 26 Feb 2019 19:19:20 -0500

> to RET=HDRS on relay"? It contradicts the previous MUST anyway.

To be clear, certainly by the time the message is a bounce traversing
a relay back towards the envelope sender, it is too late to change
the structure of the bounce message.  So no "bounce detection" is
appropriate. 

However, along the original delivery path towards to the recipient,
one might require or allow relays to replace "RET=FULL" with
"RET=HDRS", so that by the time the message eventually bounces it
leaks less content.  Ideally of course the MUA sending the message
with REQUIRETLS "yes", should also have specified "RET=HDRS".

So my previous message does not preclude relays on the outbound
path (towards the original recipient) changing the "RET=" value in
the original envelope.  That's probably what the draft is getting
at, and perhaps could be stated more clearly.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 Feb 2019 13:35:42 -0600

Hi Viktor,

Sorry for the slow response.  It took me a while to mull over why exactly
this position felt incorrect to me.

> "REQUIRETLS = yes" option, which likely won't see much use.

It seems like implicit in this stance is a belief that DANE and/or MTA-STS
as currently specified are flawed, in that they do not have a reasonable
path to substantial deployment (in bounded time).  I'm inclined to believe
you about that; you have a lot of real-world experience in these areas and
also have spent a lot of time working on finding actual deployment paths!
But what I have trouble with is that the response to "DANE/MTA-STS are
flawed" is not "make an extension to them that fixes them" but rather "make
a new thing that says to ignore parts of them", with no pointer from the
DANE or MTA-STS ecosystem to the new thing, to let people know what they
should be doing.

> by the administrator to the user.

Local policy will always be a trump card; sure.  It is free to ignore any
and all RFCs.  But we still have some responsibility for what guidance we
provide as input into local policy, and having one RFC say "ignore that
other RFC" when both are active proposed standard documents (and not in an
Updates: relationship) doesn't look very good.

> resend without authentication (possibly in the clear).

It sounds like we could frame this as a DANE/MTA-STS "escape hatch",
wherein the sender knows that the recipient requested TLS but the sender
decides to send without TLS anyway.  But this still seems like it would
need some concrete tie-in to the base DANE/MTA-STS specs.

Sure.

-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 Feb 2019 14:11:38 -0600

> of Section 4.2.2), but doesn't quite capture the intended meaning, which

I think even swapping the order to "TLS Required: no" would be an
improvement, since it's a declarative statement rather than an imperative.

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

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

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

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

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

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

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

> that STARTTLS isn't mentioned here. This is REQUIRETLS, not

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?

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

> bounce is generated. This behavior isn't specific to REQUIRETLS at all.

I think we're in violent agreement here.

> It seems like it should, yes.

[this is covered downthread, it looks like]

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

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

> mailing lists, this would happen in the case of the RequireTLS header

Maybe s/this characteristic/the header field/, then?

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

> so the improvement would be only decorative.

Indeed.

-Benjamin

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 27 Feb 2019 15:12:04 -0500

On Wed, Feb 27, 2019 at 01:35:42PM -0600, Benjamin Kaduk wrote:

> path to substantial deployment (in bounded time).

REQUIRETLS "no", is essential for at least the "postmaster" address
(in the rare cases when that still works), or some address scraped
from the destination domain's website, found in the few WHOIS records
that still list contact addresses, or in a working DNS SOA "mrname".
When all else fails, the user can notify the peer end user on the
receiving domain to contact his postmaster, open a support ticket etc.

Both specifications do a fine job of specifying the recipient's
preferred policy.  No specification, regardless of the details, can
ensure that the recipienet lives up to the promised service level.

DANE, MTA-STS, any superior design or security-theatre-de-jour, will
still lead to cases where security degrades delivery.  At the very
least one needs to be able to exempt delivery to the email address
of the domain contact.

And when all else fails, and the message is just "let's do lunch",
nothing will be more effective than a clear user choice to deliver
anyway.  This a fact of life, and not a defect in DANE or MTA-STS.
The need is intrinsic to multi-hop asynchronous delivery, by providing
the equivalent of the "press OK" to skip various warnings in
end-to-end interactive applications.

If your point is that DANE and MTA-STS should have provided an
end-user opt-out from the outset, maybe so, but I should note that
RequireTLS entered the UTA queue about the same time as MTA-STS,
and with the understanding that the "no" mechanism will be a useful
complement for both MTA-STS and DANE or any other techology which
by defers delivery in the face of apparent active attacks (which
are often simply operational negligence on the receiving end).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 27 Feb 2019 15:27:00 -0500

On Wed, Feb 27, 2019 at 02:11:38PM -0600, Benjamin Kaduk wrote:

> DANE and/or MTA-STS give me an MX hostname.

MX records give you an MX hostname.  With DANE, that MX hostname is
DNSSEC verified.  With MTA-STS the hostname is checked against the
MTA-STS policy via a (sometimes cached) HTTPS callout.

> Do I require that exact hostname to be present in the X.509 certificate
> presented by the TLS server?

Not in the case of DANE (for SMTP).  The certificate can be completely
anonymous, and would still be matched via a "3 [01] [012]" TLSA record.

With MTA-STS, yes, the name would have to match the certificate.
(Which makes deployment more difficult in some use-cases, but
c'est la vie).

> I didn't see any text in the document that clearly says the answer
> is "yes".

Since, the answer is not always yes, the appropriate behaviour is
left to the security mechanism.

> prudent to reference it here as well.

In the case of DANE-EE(3) the only requirement is that the "3 X Y"
TLSA record matches.  Name checks and expiration, etc. are out of
scope, but I would expect friction with some implementations if the
keyUsage is not compatible with TLS or the negotiated key exchange
mechanism.  So the certificate keyUsage SHOULD be provisioned with
under same constraints the same as would apply with WebPKI.

With MTA-STS, all the usual WebPKI stuff applies.

> do I need to bother with (3) at all?

There is no implicit TLS for MTA-to-MTA relay, and none in the
foreseeable future, so this issue is moot.

> 6125 here.

Except that's not the case with DANE.

-- 
	Viktor.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 27 Feb 2019 16:00:30 -0600

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 <[email-masked]> wrote:

> > >                                                      REQUIRETLS
> requires

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 27 Feb 2019 19:08:53 -0500

> On Feb 27, 2019, at 5:00 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> 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. 

That's a bike-shed colour I for one can happily live with, and for
the record, as a matter of english grammar, you're probably right
that it conveys the intent a bit more clearly.  So I would not
stand in the way of tweaking the header name if there's consensus
around that.

The header is primarily for machine consumption, so the value is
not important so long as it is understood by all the MTAs along
the forward path.  So tweaking for clarity of the description in
the RFC is fine, so long as some name or other attains consensus.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 Feb 2019 20:13:09 -0600

> anyway.  This a fact of life, and not a defect in DANE or MTA-STS.

If it's a fact of life; why was the capability to do so not built into DANE
or MTA-STS?  It really does seem like a defect, the way you're portraying
it: the stated goal of the spec is at odds with reality, and reality is not
going to break.  So, yes, as you say below, my point is that they should
have provided an end-user opt-out from the outset, and if this document now
is to provide that opt-out, it should be treated as an update that remedies
the omission.

-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 Feb 2019 20:18:19 -0600

> (Which makes deployment more difficult in some use-cases, but

Section 2 has this nice note about "MUST verify successfully using DANE as
specified in RFC 7672".  I am demanding an equivalent level of
specification for the previous clause, about "verify successfully in a
trust chain leading to a certificate trusted by the SMTP client", which
sadly lacks a current single comprehensive reference.

> left to the security mechanism.

It still needs to actually be specified somewhere!  My understanding is
that the intent here is to make the TLS verification of X.509 certificates
for the non-DANE case more strict than current practices, and as such we
need to actually specify the desired practices, here.

> With MTA-STS, all the usual WebPKI stuff applies.

Then the document needs to say so!

> foreseeable future, so this issue is moot.

So why can't (4) use the string "STARTTLS" and be less confusing to the
reader?

> Except that's not the case with DANE.

Apparently the implicit "for the non-DANE case" got lost.  Sorry.

-Benjamin

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 27 Feb 2019 23:21:33 -0500

> sadly lacks a current single comprehensive reference.

What's happening here is that there are three ways to satisfy the
authenticated delivery requirements, the last of which could perhaps
be made more explicit, even if largely obvious from context:

    1.  DANE per RFC7672
    2.  MTA-STS per RFC8461
    3.  DNSSEC-validated MX records + WebPKI authentication of the MX host.

The reason 3 is new with this specification, is that both DANE and
MTA-STS are opportunistic security, to be used when supported by
the peer and enabled at the sending system, but otherwise messages
are sent with "traditional" unauthenticated opportunistic TLS,
(perhaps even cleartext).  DANE and MTA-STS therefore first and
foremost provide a more robust way to signal that TLS should be
available, and only then about how to authenticate the peer over
that expected (STARTTLS) channel.

With "RequireTLS yes", the signal that TLS should be expected, is
no longer needed, it is instead provided by the sender.  Which
leaves just the authentication part, which is not viable unless the
MX hostname can be obtained securely.  But once the MX hostname is
not subject to forgery, authentication is just basic WebPKI.

Which means that absent DANE, the peer can be authenticated either
once DNSSEC provides a tamper-resistant MX RRset, or MTA-STS validates
the MX RRset out of band (HTTPS).

So one way to frame the sender's decision-tree is:

    1. If the MX RRset is not DNSSEC validated, use MTA-STS
    2. Otherwise if the current MX host has no TLSA records,
       do WebPKI by the book with the MX hostname as the
       reference identifier.
    3. With both DNSSEC and TLSA records present, do DANE.

What's new here is the second possibility which is not covered by
any previous SMTP security specification.

> So why can't (4) use the string "STARTTLS" and be less confusing to the

No objections if you feel that's less confusing, either way it is
STARTTLS.  FWIW, I did not take into account the possibility of
some sort of local policy for a particular destination that routes
email via an alternate port (not 25) possibly via an SSH tunnel,
implicit TLS or IPSec, etc.  Such arrangements are rare, but an
exhaustive list of all the various encrypted channels is difficult
to compile.  Also, what are the requirements for authenticating an
SSH tunnel or an IPSec tunnel?

-- 
	Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 28 Feb 2019 14:52:47 +0000

> foreseeable future, so this issue is moot.

I'm hoping for tcpcrypt.  Agreed the future is still foggy though.
-- 
Cheers,
  Jeremy

---

From: Jim Fenton <[email-masked]>
Date: Thu, 28 Feb 2019 11:14:52 -0800

> the RFC is fine, so long as some name or other attains consensus.
That works for me as well, subject to WG rough consensus, of course,
except that header field names can't contain spaces, so I would change
it to "TLS-Required: no".

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 28 Feb 2019 14:49:13 -0800

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

> I seem to be missing some logical steps here.  Why does that conclusion

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.

> week (I was unable to make last week's call, unfortunately).

Yes, I understand the discussion was pushed out.

> state of deployment that we reach.

Thanks for explaining. I expect it to remain an optional feature.

> server?  I didn't see any text in the document that clearly says the answer

I see that Viktor has explained this better than I would have. (Thanks,
Viktor).

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

> prudent to reference it here as well.

See Viktor's response.

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

> do I need to bother with (3) at all?

There's one circumstance where implicit TLS might happen, and that's
message submission. It's probably step 4 that's the problem there, since
the TLS session is negotiated earlier in that case.

> additional text discussion for clarity.

See Viktor's response.

> overtaken by events given some of the other ballot threads, though.

Yes, that's being addressed in response to other comments.

> it seems slightly at odds with the text in the document.

We will consider generalizing the text to cover other message
origination cases besides mailing list relay.

> Maybe s/this characteristic/the header field/, then?

That's clearer.

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 28 Feb 2019 17:57:21 -0500

> On Feb 28, 2019, at 5:49 PM, Jim Fenton <[email-masked]> wrote:
> 

Yes, thanks, indeed there's potential for implicit TLS during initial
submission (now that port 465 is back from the dead) and perhaps also
final delivery via LMTP.  So my note about STARTTLS being the only
relevant protocol may not cover the "edge" cases.

-- 
	Viktor.