Subject: [Uta] Require TLS=NO is very much needed

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Nov 2017 19:01:58 -0500

People are forgetting that especially smaller sites
that implement STS or DANE don't always have the
operational discipline to keep these working.  I
have considerable evidence to support this claim.

A sender with urgent non-sensitive messages may well
reasonably want to see the message delivered despite
such failures.  Indeed, this is typically the right
thing to do with failure reports!

At present, the sender address I use to send DANE
failure notices is statically exempted from enforcing
DANE policy (rather than message by message).

-- 
	Viktor.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 17 Nov 2017 02:56:51 +0100

> DANE policy (rather than message by message).

The sense of the room in Singapore was that the semantics
of REQUIRETLS=NO was sufficiently different from REQUIRETLS
that it would be better to move it to a separate document.
It was suggested that REQUIRETLS=NO might be better
represented as a message header even.

In any case it is not clear to me that there is or ever was
consensus to keep this feature /in its current form/ in the
REQUIRETLS draft.

As always, discussions on the list will determine this but
barring clear support for keeping the feature in the draft
we need to find another form for this feature.

	Cheers Leif

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Nov 2017 21:55:54 -0500

> On Nov 16, 2017, at 8:56 PM, Leif Johansson <[email-masked]> wrote:
> 

The room was not populated by enough folks with deep operational
experience in email, especially operational experience with
email transport security policy.

As I pointed out in another message, BOTH REQUIRETLS=YES
*and* REQUIRETLS=NO need to be encapsulated in headers, but
the YES case *also* needs an ESMTP extension, while the
NO case does not.  It makes sense to define both in the
same document.

> consensus to keep this feature /in its current form/ in the

Consensus can yet be achieved after more discussion with
folks getting a chance to think through the issues more deeply.

> we need to find another form for this feature.

We're far from done with REQUIRETLS, there are still many
questions around *specificity* of what REQUIRETLS means.
The present draft makes possible overly prescriptive
security criteria, this needs to change.  The client
can't reasonably expect to know the hop-by-hop security
"topology", therefore CHAIN,DANE,DNSSEC are too much
detail.  The policy needs to be just ternary:

  * Yes.  Require an authenticated secure-channel.
  * No. Proceed despite authentication failure that
    would normally prevent message delivery.
  * No REQUIRETLS verb or header, do the default thing.

-- 
	Viktor.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 17 Nov 2017 04:06:05 +0100

> email transport security policy.

I will set this aside for now. I encourage everyone to express
their opinions on this topic. Right now the consensus is not
clear either way.

> folks getting a chance to think through the issues more deeply.

Indeed.

My response to your message was meant to encourage discussion!

	Cheers Leif

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Nov 2017 14:10:56 +0800

> consensus to keep this feature /in its current form/ in the

(As a participant) Maybe write a separate draft?

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Nov 2017 02:01:42 -0500

> On Nov 17, 2017, at 1:10 AM, Alexey Melnikov <[email-masked]> wrote:
> 

There'd be considerable overlap between the documents,
both need essentially the same mechanisms to tunnel
TLS policy in headers, and there should only be one
such header to avoid having to resolve conflicts.

The security issues are two sides of the same coin
and should be discussed together.  Both features
override default TLS policy, one to require greater
than default security, the other to deliver despite
failure of default security policy.

The obstacle in the current draft was that  the "NO"
case appeared to over-complicate the ESMTP extension,
but it is now clear that the "NO" case need not use
the "ESMTP" extension and should be carried exclusively
via a header.  However, since the same TLS policy
header is also needed for the "YES" case (but with
a slightly different payload), the same draft should
specify both.  We should not force these to be separate
just to hurry the "YES" case out the door.  Let's do
this right.

-- 
	Viktor.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 17 Nov 2017 08:28:51 +0100

> (As a participant) Maybe write a separate draft?

Yes I think thats a fine way to resolve this. My sense of
the room is that there is wide support for /the idea/ but
people feel that the current SMTP-focused draft becomes
overly complex by having this feature in there.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Nov 2017 03:00:45 -0500

> On Nov 17, 2017, at 2:28 AM, Leif Johansson <[email-masked]> wrote:
> 

My sense is that it was just a gut reaction from an audience
not steeped in the subject matter, based on a perceived
difficulty that does not actually exist, because the "NO"
case turns out to have no footprint at the ESMTP layer.

However, both the "YES" and "NO" cases have closely related
and mutually exclusive message header footprints with similar
reasons for existence and closely related security considerations.

My take is that the vibe from the "room" arrived at a hasty
conclusion from false premises, and should be ignored.  It was
premature, the draft is not yet far enough along to decide the
question at hand. First the design space needs to be more clearly
understood.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 17 Nov 2017 08:49:35 +0000

➢ My take is that the vibe from the "room" arrived at a hasty
    conclusion from false premises, and should be ignored.  It was
    premature, the draft is not yet far enough along to decide the
    question at hand. First the design space needs to be more clearly
    understood.

I was there and I disagree with your characterization.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 17 Nov 2017 01:08:18 -0800

> their opinions on this topic. Right now the consensus is not

(as an individual, not document editor): As I mentioned in another
thread, I see REQUIRETLS and the "REQUIRETLS=NO" (but under a different
name, as a header field) as being different enough and implemented
independently of each other that the latter should be a separate draft.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Nov 2017 04:15:32 -0500

> On Nov 17, 2017, at 3:49 AM, Salz, Rich <[email-masked]> wrote:
> 

I watched the entire session after the fact, I stand by my
assessment that the conclusions were premature.  I've been
focused on this space for ~15 years now, so I am probably
not making stuff up...

We should also keep in mind that as DANE and STS gain more
adoption, it will be the "NO" case that will be far more
useful to the majority of users.  The "YES" case will see
very little use.  In particular email reports from the
"tlsrpt" draft, will need "NO", to make sure they get to
the problem destination, despite their expired or otherwise
invalid certificates, disabled STARTTLS, ...

-- 
	Viktor.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 17 Nov 2017 11:01:25 +0100

> I was there and I disagree with your characterization.

Yeah I also disagree (as an individual). The person who made the
comment is the same person who first suggested the feature be added.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Fri, 17 Nov 2017 11:06:02 +0100

On 2017-11-17 10:15, Viktor Dukhovni wrote:
> not making stuff up..

I feel a certain level of frustration from you Victor but
let me assure you you have no reason to feel that way - as
usual in the IETF the only decisions that matter are the
ones made on the list.

Let me suggest that we focus less on who said what and
why and instead focus on the issue at hand: should we
split the draft or not!

As chair I want to encourage everyone to present their
views regardless of how many years they may have under
their belt.

	Cheers Leif

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Nov 2017 06:24:16 -0500

> On Nov 17, 2017, at 5:01 AM, Leif Johansson <[email-masked]> wrote:
> 

FWIW, my recollection is that I was the who suggested the need for the
"NO" case when Jim first presented the idea REQUIRETLS (in Berlin IIRC).
But of course who suggested it first should not grant any special
privilege to have work in that direction stop or continue.

-- 
	Viktor.

---

From: [email-masked]
Date: Fri, 17 Nov 2017 06:12:41 -0800 (PST)

> just to hurry the "YES" case out the door.  Let's do

I'm with Viktor on this one. Having two documents where only one is
needed will not only create redundant material that needs to be kept
in sync, it's more stuff people implementing this have to read.

This is already too complicated and spread over too many specifications. Let's
please not make it more so.

				Ned

---

From: Leif Johansson <[email-masked]>
Date: Fri, 17 Nov 2017 15:23:39 +0100

> privilege to have work in that direction stop or continue.

I meant that as an indication that the person probably know what they
were talking about.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Nov 2017 15:28:23 +0100

I've been watching the back and forth and trying to get my hands around
the technical issues between the two cases.  The closest I see for a
technical explanation in this thread is this:

> NO case does not.  It makes sense to define both in the

For those of us who were not in the room, can someone explain the case
in technical detail for *not* doing REQUIRETLS=NO in the same document? 
Jim?

Eliot

---

From: Jim Fenton <[email-masked]>
Date: Fri, 17 Nov 2017 08:19:10 -0800

> in technical detail for *not* doing REQUIRETLS=NO in the same document? 

The "yes" and "no" cases solve different problems: in the case of "yes"
it's stating a security requirement, and in the case of "no" it's
enhancing deliverability in the presence of MTA-STS or DANE policies. I
can picture that some MTAs might deploy one and not the other, which
makes it confusing if we're calling them both REQUIRETLS and putting
them in the same specification.

The "yes" case involves negotiation of an SMTP extension and may also
involve the addition of a header field. The "no" case involves only the
addition of a header field.

-Jim

---

From: Bron Gondwana <[email-masked]>
Date: Sun, 19 Nov 2017 20:45:54 +1100

> focused on this space for ~15 years now, so I am probably

I have, admittedly, only been focused on this space for 13 years, which
I guess means you win on pure number of years.
I was a person who stood up in both Prague and again in Singapore and
argued for a header rather than REQUIRETLS=NO at SMTP stage.  I see no
benefit to adding anything at SMTP stage, or even checking if the
receiver claims to support REQUIRETLS.  If you have a message that
doesn't want TLS checking, then you need to try your best to deliver
it regardless, so you won't be checking for this extension before
trying to send.
> invalid certificates, disabled STARTTLS, ...

I agree with this.  There needs to be a way to contact
misconfigured sites.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Bron Gondwana <[email-masked]>
Date: Sun, 19 Nov 2017 20:52:32 +1100

On Sat, 18 Nov 2017, at 01:28, Eliot Lear wrote:
> I've been watching the back and forth and trying to get my
> hands around> the technical issues between the two cases.  The closest I see for a
>> **and** REQUIRETLS=NO need to be encapsulated in headers, but
>> the YES case **also** needs an ESMTP extension, while the
> For those of us who were not in the room, can someone explain the case> in technical detail for **not** doing REQUIRETLS=NO in the same
> document?> Jim?
> 
> Eliot

That's a great summary of the key point, and I totally agree with Viktor
here, though I would even more strongly argue that definining
REQUIRETLS=NO as an ESMTP extension would be a mistake.  It doesn't add
any additional signal on top of the header, and creates more cases where
the two sets of information could be out of alignment.
I would argue that if REQUIRETLS=YES is given via ESMTP then the lack of
a REQUIRETLS=YES header on the same message MUST cause a rejection,
meaning that nobody would deploy the YES case unless they had both in
alignment.
Whereas the NO case is always just a hint to intermediate sites to relax
their tests.  For NO a header is plenty, since you never want to stop
trying to deliver just because you can't negotiate something at ESMTP
for the NO case.
I'm really quite happy for it to be a single document for the reasons
Ned and Viktor have suggested - it's easier to get adoption.
That said, I could see sites deploying NO support without deploying YES,
since YES requires you to to ensure that your downstreams are at least
claiming to play ball.  So that's an argument for either two separate
documents or the spec saying that it's legitimate to implement NO only.
It's less important how many documents are produced than the ability for
sites to offer NO without YES.
Cheers,

Bron.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 19 Nov 2017 13:58:28 -0500

> On Nov 19, 2017, at 4:52 AM, Bron Gondwana <[email-masked]> wrote:
> 
> That said, I could see sites deploying NO support without deploying YES, since YES requires you to to ensure that your downstreams are at least claiming to play ball.  So that's an argument for either two separate documents or the spec saying that it's legitimate to implement NO only.  It's less important how many documents are produced than the ability for sites to offer NO without YES.

I think that a single specification in no way obligates
anyone to implement all its features, a site could implement
any of the four possibilities regardless of the number of
documents the IETF publishes in this space.  A single
specification is IMHO simpler, since it concerns the
same security policy issue:

   * Whether to deliver despite lack of a secure channel

The "REQUIRETLS=YES" case says "stop" and asks the nexthop
to do likewise both via out-of-band (ESMTP) and in-band
(header) signalling.

The "REQUIRETLS=NO" case says "go", and asks the nexthop
to do likewise just via in-band (header) signalling.

The header should I think be a common header, and the
same considerations apply wrt. "Resent" and "List"
messages.  That is, if the header is normally:

	TLS-Required: Yes|No

Then in a resent message (that has a Resent-From or
a Resent-Message-Id header) the above header is ignored
and any TLS policy override would need to be:

	Resent-TLS-Required: Yes|No

and in a list message (that has a List-Id header) any
override would have to be a "List-TLS-Required" header.

-- 
	Viktor.