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

[Viktor Dukhovni <[e-mail]>]

> On Nov 16, 2017, at 8:56 PM, Leif Johansson <[e-mail]> wrote:
> 
> 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.

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.

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

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

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

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.