> On Nov 16, 2017, at 8:56 PM, Leif Johansson <[email protected]> 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.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
