On Sun, Mar 27, 2016 at 08:17:28PM -0700, Jim Fenton wrote:
> >> I have received suggestions that there also be options to require
> >> specific TLS version, cipher suites, PFS, etc. as well, and my gut feel
> >> is that's getting too specific.
>
> > Don't let this be over-engineered. That's a guaranteed way to fail
> > to produce a workable protocol. Of course it is [not] clear that even
> > a simple REQUIRETLS can gain sufficient traction, but to the extent
> > that you want this to have a fighting chance you should resist all
> > calls for overly-specific policy.
>
> I'm sensitive to over-engineering this. That said, there are mail
> senders who might consider their threat model to include an actor that
> has control over a commonly-accepted root certificate (as some
> nation-states do). Much of the motivation behind the CHAIN and DANE
> options was to allow such senders to be more specific about what forms
> of certificate verification they consider acceptable.
>
> This is probably a narrow use case, but perhaps very important for these
> senders. Let's see what the rough consensus is.
So just to be clear, my view is that allowing the sender to specify
the authentication mechanism that is to be used along the entire
delivery chain is a non-starter.
If I ever get around to implementing this specification in Postfix,
I would most likely ignore any specific authentication mechanism,
and, when authentication is requested, deliver via whichever of
WebPKI, DNSSEC/DANE (or perhaps STS, ...) happens to work.
An initial implementation of this specification would likely also
include controls to downgrade the requested TLS security for trusted
relay hops, so that Internet-facing border MTAs can terminate
REQUIRETLS and deliver without authentication or in the clear to
internal mail servers.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
