On Thu, Feb 21, 2019 at 12:43 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> 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. > No, they're the expression of the link generator's policy choice, but the same situation obtains, if you do, for instance, XHR. 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. > You can't override HSTS, actually. > > 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. No, it's saying "don't deliver this at all, if you can't do this" > 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. > See above. -Ekr > -- > Viktor. > >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
