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

From: Nico Williams <[email-masked]>
Date: Fri, 1 Mar 2019 12:51:12 -0600

On Thu, Feb 28, 2019 at 08:15:03AM -0800, Barry Leiba wrote:
> > My idea of an ideal end-state for hop-by-hop security for e-mail is
> > that:
> 
> See, this is why we often say that IETF folks should not generally try
> to design UI things:

What on Earth made you choose to be so condescending here?  Do I not get
to express my personal preferences?

How about a response to the substantive parts of my post?

Nico
--

---

From: Barry Leiba <[email-masked]>
Date: Sat, 2 Mar 2019 10:09:32 -0500

> to express my personal preferences?

I'm sorry.  I didn't mean to condescend, and please accept my apology
for having worded it badly.

> How about a response to the substantive parts of my post?

The only part I was addressing was the suggestion of prominent UI
indications, which I do not think is a good thing for the reasons I've
said: Almost all users will not understand at all what the indications
mean, and many will understand incorrectly to the point of being
misinformed by them.

Barry

---

From: Nico Williams <[email-masked]>
Date: Sat, 9 Mar 2019 14:15:43 -0600

> for having worded it badly.

Thanks.

UI design isn't easy, but *we*, IETF participants, cannot say that we
know so little about it that we won't even begin to discuss UI design.

I think it would be irresponsible for us to not consider UI issues and
design at all.

It would also be irresponsible (this must have been your point) to not
recognize our limitations here and seek help from domain experts.

Our publication process involves reviews and iteration precisely so we
can fine-tune such things.

> mean, and many will understand incorrectly to the point of being

So, the UI details can vary.  E.g.,

 - The default might be that inbound email delivered with unacceptable
   security options gets bounced.  This is for users like my mom.

 - A non-default option might be that inbound email delivered with
   unacceptable security options gets bounced and yet also delivered to
   a "insecure" or spam folder.  This is for users like me.

 - Yet another non-default option might be that inbound email delivered
   with unacceptable security options gets delivered anyways and some
   less-obvious-than-an-insecure-mailfolder UI indicator (the sort you
   were objecting to) gets set.  This also for users like me.

Email is insecure today.  There's no path to a flag-day cutover to a
universe where email is secure.  Having no UI indicators of any kind is
not going to work for a migration to secure-by-default email.

Like it or not, we *do* have UI indicators of this sort for email today.
Things like spam folders.  Or gmail's warnings about suspicious emails.

I don't think we're ready to not have any such indicators.  Not on the
web, and not for email.

Even on the web, we might be removing or de-emphasizing the lock icon,
but still you get the "something went wrong" page with a not-easy-to-
notice "i know what I'm doing, let me see it anyways" button a few
clicks away.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Mar 2019 17:01:37 -0700

On Thu, Feb 28, 2019 at 10:36 AM Viktor Dukhovni <[email-masked]>
wrote:

> On Thu, Feb 28, 2019 at 09:42:31AM -0800, Eric Rescorla wrote:
>
> > > The preferences we're talking about here (MTA-STS and DANE) are
> basically
> > > advertisements saying, "if you send mail to this domain, you should
> expect
> > > to use TLS when doing so."
> >
> > and "if you recognize this indicator, you should fail if the server
> doesn't
> > do TLS", right? Just like HSTS.
>
> Thanks for the clarification, I now see how you're arriving at your
> position.  The key difference is that you see MTA-STS and DANE as
> analogous to HSTS in setting a mandatory security policy for the
> client.  But the analogy is crucially imperfect.
>
>     * With browsers, given an "http://" URL or bare domain in the
>       browser's address bar, the client either honours that and uses
>       an unauthenticated, unencrypted channel, or given HSTS
>       unconditionally upgrades to encrypted authenticated HTTPS.
>
>     * With SMTP, there isn't a second email address format for email
>       delivery over TLS.  The MTA chooses the best available security
>       level opportunistically.  The baseline is cleartext delivery.
>
>     * SMTP upgrades to (unauthenticated) STARTTLS opportunistically,
>       when offered by the peer.  Even in the absence of DANE, MTA-STS,
>       etc., the sender can and most often does use STARTTLS (~92%
>       of the time in/out of Gmail).  Which is sufficient to deal
>       with passive monitoring.
>
>     * But active attacks can forge MX replies, strip STARTTLS or
>       MiTM the TLS session.
>
>     * What DANE and MTA-STS (after first contact) do is harden the
>       peer signal against active attack, *enabling* the sending system
>       to negotiate the highest shared security level.
>
>     * Neither *obligates* the sending system to use them without
>       exceptions.
>
>     * This is in part because even without either, STARTTLS is then
>       typically used, and is often viewed as an adequate compromise
>       between security and reliabile delivery.
>

I'm sorry, but I don't see how any of this is meaningfully different from
the
situation with HSTS. In both cases, the receiving system indicates that
the sending system ought to use secure transport, and if the sending
system conforms to the specification providing that indication, it is
required to use secure transport. See:
https://tools.ietf.org/html/rfc8461#section-5

"

 When sending to an MX at a domain for which the sender has a valid,
   non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS applies
   the result of a policy validation failure in one of two ways,
   depending on the value of the policy "mode" field:

   1.  "enforce": In this mode, Sending MTAs MUST NOT deliver the
       message to hosts that fail MX matching or certificate validation
       or that do not support STARTTLS."

DANE and MTA-STS describe what a sender must do *when* doing DANE
> or MTA-STS, in order to get a result that is (more) resistant to
> active downgrade attacks, but they are not mandates.  The sender
> can elect to not implement either or both,

This seems to be precisely the situation with HSTS. Clients are not
obligated
to implement HSTS.

> or to skip either or
> both for selected destinations.
>

I actually don't see this text in 8461. Can you supply a link?

All that this draft does is specify a way for the sending system
> to give the user some control over the handling of his message,
> so that MUAs and downstream relays can recognize the user's
> preference and perhaps take it into account.

That's one read of it, but another is that it allows the sender to
instruct the intermediary to override the receiver's clearly expressed
preferences.

We should keep in mind that email is often the medium used to
> communicate about operational failures.  And that not infrequently,
> insecure email is the medium through which more essential security
> is brought back into service elsewhere.
>

Well, this seems like potentially an argument that MTA-STS is a bad idea,
but it's not clear to me that this document is the appropriate fix, for the
reasons I indicate above.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 12 Mar 2019 21:47:54 -0400

> On Mar 12, 2019, at 8:01 PM, Eric Rescorla <[email-masked]> wrote:
> 
> I'm sorry, but I don't see how any of this is meaningfully different from the

The difference is that MTAs with published DANE and MTA-STS policies
nevertheless in the majority of cases still accept email not only
from senders who don't do DANE or MTA-STS (and use unauthenticated
opportunistic STARTLS), but also in cleartext!

Unlike HSTS where the port 80 website typically only serve the HSTS
policy and a redirect to HTTPS, the MTA's published DANE or MTA-STS
policy is an offer of support for security delivery to the sender,
it is NOT a mandate.

The normative MUSTs in e.g. the DANE SMTP RFC are there to ensure that
senders implement DANE correctly *when* they choose to do that, and don't
do something half-baked leading to a false sense of security.

There is no expectation that DANE preëmpts sender policy, and MTAs use
whatever rules they have for a particular "envelope" to determine the
relevant security policy.  The present draft just adds an important
signal from the sending user.

My perspective on the SMTP security landscape is based on 18 years of
Postfix development and a decade as Postmaster at Morgan Stanley where
among other activities (email for the Google IPO) I managed mandatory
TLS peering with many business partners, and saw first hand what it
takes to deal with all the edge-cases.  Email is different from the Web,
and experience learned in one doesn't always carry over to the other.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Mar 2019 20:00:35 -0700

> policy is an offer of support for security delivery to the sender,

I'm not sure why this is relevant, given that an active attacker can simply
continue with the HTTP connection and proxy it to HTTPS with the server.
And of course in many cases the sensitive information has already been said.

> do something half-baked leading to a false sense of security.

And similarly, clients can choose not to do HSTS, but when they do HSTS,
there are rules for what they do.

> relevant security policy.

The plain language I cited, which requires the conformant client to behave a
certain way. If there is some textual evidence to the contrary, please cite
it.
Otherwise, we just have different interpretations of the intent of this
text and I don't see a reason to adopt yours.

> and experience learned in one doesn't always carry over to the other.

Surely you're familiar with the term "argument from authority".

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Mar 2019 01:15:27 -0400

> On Mar 12, 2019, at 11:00 PM, Eric Rescorla <[email-masked]> wrote:
> 

Yes, and also quite aware that FWIW, that's in part the argument I'm
making.  The idea is that am I am not just citing the dead trees that
only loosely capture the spirit of the specifications.  Having written
the DANE specification, crafted its first MTA implementation, and worked
hard to see it adopted, I think that while any authority I may bring to
this is by no means dispositive, it still should carry some weight, and
ought to be considered, among whatever other factors you might find
relevant.

Bottom line, while working with the Postfix and broader email community
to bring greater transport security to email, my read is that senders
do not view anything that recipient systems might publish as a mandate
that preëmpts their policy options.

Indeed my experience tells me (as e.g. explained in RFC7435) that we get
greater adoption of security systems when we give participants a range of
options and not just once size fits all.

While a higher fraction of Web traffic than email traffic is *strongly*
protected with authenticated TLS, a larger fraction of email traffic
than Web traffic is protected from passive monitoring, because support
for unauthenticated STARTTLS was easier to deploy and operate.

With Let's Encrypt, HTTP is now starting to catch up on TLS adoption, but
some have rightly noted that it has also become much easier for various
MiTM attackers to obtain fraudulent DV certificates.  We're seeing an
unsurprising tradeoff between ubiquity and security.

We should not deny senders the opportunity to take sender preference
into account, this will ease the adoption path to greater security,
and will help to make security more deployable.  Strong security that
only a few deploy is ultimately not a success story.  Sometimes (e.g.
Let's Encrypt) we compromise in the name of ease of deployment.

-- 
	Viktor.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 13 Mar 2019 16:58:54 -0400

Hi Ekr,

On Thu, Feb 21, 2019, at 3:07 PM, Eric Rescorla wrote:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I support Benjamin's DISCUSS.
> 
> To elaborate on one point a bit: it seems to me that it's harmful to
> security to allow the sender to unilaterally override the recipient's
> preferences that something be encrypted. To forestall one argument,
> yes, the sender knows the contents of the message, but the recipient
> knows their own circumstances, and they may be at particular risk

I don't agree with this part of your DISCUSS and with your argument that this is the same as HSTS (I will try to gather my counter-arguments in a separate email), but in the interest of being constructive: can you suggest a possible fix (or directions towards the fix) to address your DISCUSS?

Thank you,
Alexey

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Mar 2019 14:13:45 -0700

On Wed, Mar 13, 2019 at 1:59 PM Alexey Melnikov <[email-masked]>
wrote:

> I don't agree with this part of your DISCUSS and with your argument that
> this is the same as HSTS (I will try to gather my counter-arguments in a
> separate email), but in the interest of being constructive: can you suggest
> a possible fix (or directions towards the fix) to address your DISCUSS?
>

Well, I think this field should only override the outgoing and not incoming
policies (or be removed).

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Mar 2019 17:49:07 -0400

> On Mar 13, 2019, at 5:13 PM, Eric Rescorla <[email-masked]> wrote:
> 
> Well, I think this field should only override the outgoing and not incoming policies (or be removed).

To be clear, let's imagine a company (say a bank) with the following TLS
policies (written roughly Postfix-style, but should be clear even to the
uninitiated):

	# Mandatory PKIX authenticated TLS with back office settlement business partner,
	# And mutually agreed set of CAs.
	#
	partner.example		secure tafile=partner-cas.pem match=mx.partner.example

	# Mandatory DANE-TLS with another business partner known to support DANE
	#
	partner2.example	dane-only

	# Opportunistic DANE TLS when available with general-purpose email
	# (In real life the global default would be specified elsewhere)
	*			dane

I think you're saying that the company could allow its users to bypass
the locally-policy business partner domain rules, but must refuse to
allow users to exempt casual correspondence from DANE (or MTA-STS)
policy when published by the destination domain.

Is that right?

-- 
-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Mar 2019 14:55:02 -0700

> policy when published by the destination domain.

Yes.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Mar 2019 08:53:29 -0700

We had a bunch more discussion on this on the IESG call. It seems like
the primary use case for TLS-Required=no may be to exempt what's basically
the control channel from the requirement to use TLS. So, for instance,
I am getting persistent bounces from you and I want to notify you
about it, so I send that notification with the TLS-Required=no flag set
[0].

Assuming that's right, then ISTM that actually this is not the ideal
design, both because it's not clear how the flag gets set and because
the recipient has had no chance to weigh in. What I would suggest would
instead be to extend MTA-STS and DANE to exempt specific "control"
addresses (e.g., Postmaster) from mandatory TLS. This seems like it
would solve the main problem while avoiding opening the can of
users just marking routine messages as non-sensitive.

-Ekr

[0] In some unspecified way? Perhaps a button in the MUA UI?

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 Mar 2019 12:38:17 -0400

> On Mar 14, 2019, at 11:53 AM, Eric Rescorla <[email-masked]> wrote:
> 

That's one use case, but another important use case, is giving *users*
the ability to resent low-sensitivity but time-sensitive messages, that
bounced or were delayed because of downstream misconfiguration.

Think "Happy Birthday Grandma" (ideally not belated) postcard (i.e.
cleartext OK).

> the recipient has had no chance to weigh in.

The "flag" gets set by the MUA, by adding the appropriate header.  For
webmail clients, that'd be something the WebUI could provide as option
when the user is reviewing a bounce or a delay notice for a message he
sent that did not (yet? and will likely not as-is) make it to the intended
recipient.

For power-users (postmasters, or other technologists) using Mutt, Pine, ...
the header can just be added in their favourite message editor.

> What I would suggest would

Unfortunately, that does not work.  These days, a large fraction of
domains have no working "postmaster" addresses.  The technical contact
addresses for many domains are no longer published in WHOIS, but one
may be able to scrape a responsible user from the website, or from
the DNS SOA "mrname".

There are no "control address" localparts that work for (essentially)
all domains, and email to "postmaster" may actually in some cases be
sensitive, and unrelated to transport security obstacles.

By far the more reliable notification channel, is email to an actual
user, who knows how to reach support for his provider, or in SOHO
cases knows (or is) the administrator in person.

[ I've been sending DANE-related misconfiguration notices since 2014,
  and postmaster@ bounces back as undeliverable in ~30% of the cases,
  and is not necessarily read by anyone even if delivered, I typically
  include additional notice recipients whenever available. ]

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 Mar 2019 12:40:29 -0400

-- 
	Viktor.

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

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Mar 2019 09:43:35 -0700

> Think "Happy Birthday Grandma" (ideally not belated) postcard (i.e.

Well, my point is that this use case is in direct conflict with the plain
text of the semantics of MTA-STS.

> the header can just be added in their favourite message editor.

Yes, that's what my footnote assumes. This seems pretty weak.

> cases knows (or is) the administrator in person.

I think you are misunderstanding me. I am saying that the same indication
that says "use TLS" should also list the exempt addresses.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Mar 2019 11:58:35 -0500

On Wed, Mar 13, 2019 at 02:55:02PM -0700, Eric Rescorla wrote:
> >         [...]

So:

  "I MAY      allow MY users to trump MY      policy"
  "I MUST NOT allow MY users to trump OTHERS' policy"

?

If my contractual relationship with my partners required me to enforce
their policies, I couldn't object to enforcing their rules.

If I don't have a contractual relationship with some domain, why should
I be required to enforce THEIR policy?  As you've pointed out, I could
just publish my email to them in a newspaper ad.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 Mar 2019 13:10:12 -0400

> text of the semantics of MTA-STS.

Neither MTA-STS nor DANE specify a per-message opt-out mechanism.
A key difference in our viewpoints, is that in my view once such
an opt-out is invoked, DANE and MTA-STS are no longer in use, so
there's no conflict at all, since the sender is no longer using
DANE or MTA-STS, the sender has elected a different security policy
for the message (typically opportunistic STARTTLS).

No sender is obligated to use DANE or MTA-STS, and this draft
delegates part of the decision to the sender.  The sender's MTA may
choose to not honour the "RequireTLS: no" hint, because local policy
mandates stronger security for a particular destination or in general.

A browser doing HTTPS allows me to click through various warnings
and see a site whose certificate does not match its name, is expired
etc.  Email delivery is asynchronous, and so the corresponding user
opt-out signal needs to be in the message content.

> that says "use TLS" should also list the exempt addresses.

Well, that's not going to happen.  The receiving systems are not
anticipating and planning for failure.  You're still trying to put
all the controls on the receiving side, and that just does not work,
and does not give users the option of delivering time-sensitive
messages directly to their correspondents (rather than the support
team that may not get around to a ticket from a stranger for days).

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Mar 2019 12:27:32 -0500

> users just marking routine messages as non-sensitive.

I mean, that's an improvement, but I still don't think this is right.
You're asking me to enforce someone else's local policy for them without
exceptions (their exceptions, but not mine).

Do we have other Internet protocols that work this way?

Note that normative requirements aren't a peer's local policy.  So those
aren't it.  SPF and such can be disregarded.  Why can't MTA-STS?

This strikes me as a huge departure from how we've done things before.
I'd like this to be very explicit if it must happen, and I think we need
a lengthier, generic discussion of this change.

BTW, RFC8461 (MTA-STS) does NOT require that the sender honor MTA-STS!
                                                        -----

In all cases where RFC8461 says what to do in the face of policy
failures, it refers to "a Sending MTA honoring MTA-STS" -- not a sending
MTA that implements MTA-STS, but one that honors MTA-STS.

I think you're over-reading the text in RFC8461.

E.g.,

  | 4.  Policy Validation
  |
  |    When sending to an MX at a domain for which the sender has a valid
  |    and non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS MUST
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                                     ^^^^^^^^
  |    check whether:
  |
  |    [...]
  |
  | 5.  Policy Application
  |
  |    When sending to an MX at a domain for which the sender has a valid,
  |    non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS applies
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                                 ^^^^^^^^
  |    the result of a policy validation failure in one of two ways,
  |    depending on the value of the policy "mode" field:
  |
  |    [...]

How does this not allow a sending MTA to... not honor MTA-STS?

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Mar 2019 10:31:32 -0700

>   |    and non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS MUST

It's allowed to not *generally* honor STS, but this text does not have any
provision for just ignoring it for some messages. Any other reading seems
extremely strained.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Mar 2019 13:02:52 -0500

On Thu, Mar 14, 2019 at 10:31:32AM -0700, Eric Rescorla wrote:
> >   | [quotes from RFC8461 elided]
> >

RFC8461 does not say "generally honoring MTA-STS".  Where do you get
that?  Did I miss something?  The word certainly does not appear.

Any reading of RFC8461 where you insert this missing "generally" looks
strained to me.  How would an implementor reading the RFC get that?  Are
they expected to look in the archives of this and other threads to find
that the IESG decided that this absent "generally" was there?

Even if RFC8461 *did* say that, so what.  There's no normative
definition of "generally honoring MTA-STS" there.

Even if RFC8461 *did* say that and had a normative definition of
"generally honoring MTA-STS", we could just update it.  If not even
consider it an erratum (it would have been an error, IMO).

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 Mar 2019 14:17:51 -0400

> On Mar 14, 2019, at 1:31 PM, Eric Rescorla <[email-masked]> wrote:
> 
> It's allowed to not *generally* honor STS, but this text does not
> have any provision for just ignoring it for some messages.

In MTAs (e.g. Postfix), the delivery policy is *always* per message,
or more precisely per message recipient.  Either the message sender
or message content (filter) can map to a default transport with an
associated set security mechanisms/policies, and then a specific
recipient may map to a suitable recipient-specific transport.

When a particular envelope is mapped to a non-DANE policy, the DANE
specification does not apply.  Ditto for MTA-STS, and this is the
only plausible reading of either specification.  When in Rome do
as the Roman's do, but elsewhere togas are not standard attire.

Just because Postfix *implements* DANE, does not make it *generally*
honoured.  DANE, if enabled at all, is either used or not used for
a particular envelope, with multiple factors taken into account.

Thus the same destination domain's published TLSA records, may or
may not get used, depending on the sender, the message content or
the recipient.

This draft merely formalizes a standard signal that an MUA can use
to feed into the transport policy selection.

Other MTAs similarly have lots of per-message-envelope knobs.  So
"honor" always only applies one message at a time.  Just because
some envelopes adhere to a policy does not make that policy more
equal than others.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 14 Mar 2019 17:22:55 -0700

Picking a somewhat arbitrary place to join this discussion...

> text of the semantics of MTA-STS.

IMO, characterizing MTA-STS and DANE as policy mechanisms is confusing.
If it was a policy that the receiving domain wanted to enforce, it would
not accept mail unless STARTTLS had been negotiated. But few
general-purpose domains do that, because they don't want to cut
themselves off from client MTAs that haven't implemented STARTTLS, or
that can't negotiate compatible parameters. And of course MTA-STS and/or
DANE are needed to protect against man-in-the-middle attacks by impostor
server MTAs.

MTA-STS and DANE are advertisement mechanisms: they are advertising that
they support STARTTLS (possibly with reference to specific public keys
their certificates contain). They are saying that it is inadvisable from
a security standpoint to send mail to them unless STARTTLS can be
negotiated (with the right public keys if applicable).

But MTA-STS and DANE are not enforcement mechanisms. Domains publishing
MTA-STS and DANE, by in large, still accept mail from MTAs that don't
implement MTA-STS and DANE, and that therefore might send mail without
STARTTLS. So they aren't enforcing their own policies, if the semantics
of the policies involved enforcement.

> MTA that implements MTA-STS, but one that honors MTA-STS.

And that text describes how a client MTA uses MTA-STS as an
advertisement mechanism.

Another way to accomplish the effect of TLS-Required: no (for a single
hop, anyway) would be to route the message through an MTA that
(intentionally) does not implement MTA-STS nor DANE. That would be
perfectly OK, so why is 'TLS-Required: no' in conflict?

-Jim