On Thu, Feb 21, 2019 at 12:22:32PM -0800, Eric Rescorla wrote:
> > A recipient has no expectation that the sending MTA supports any of
> > DANE, MTA-STS, REQUIRETLS, or even STARTTLS.
>
> Nor do Web servers have any expectation that clients support HSTS, but we
> still don't allow it to be overridden by some http-no-really:// link.
"http-no-really://" links are not the right analogy, links are
typically delivered to the user, they rarely expressions of the
user's policy choice.
Browers have interactive human users who can on the spot chose to
override whatever security policy is in place. Firefox by default
offers me the opportunity to make certificate exceptions permanent,
and I always have to remember to uncheck the check-box to make an
exception for just the one connection.
SMTP servers deliver in the background, with the user out of the
loop, hence the need for "REQUIRETLS = no".
> > More harmful to security than acknowledging that either participant
> > has the freedom to choose the policy that works best for them, is
> > restricting their choices to the point of making the use of security
> > mechanisms too burdensome to deploy.
>
> The problem with this mechanism is that it is denying the recipient the
> right to choose what works for them.
I am not aware of any such right. The receiving system is announcing
a capability, and the sending system does its best to achieve the
highest common security level. The input to finding the highest
common level includes software feature availability and local policy,
potentially including user preference.
The receiving system *cannot* expect to enforce its ceiling, all
it can do is offer more security, and hope that it will be used.
For that to happen, more senders would have to support the security
mechanisms, but they are likely to hold back if these offer no way
workable way to manage exceptions.
Firefox and Chrome offer dialogues to bypass the built-in browser
security mechanisms, a somewhat analogous control should be available
to mail user agents.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
