> On Thu 2018-03-22 15:17:18 -0400, Viktor Dukhovni wrote:
> >> On Mar 22, 2018, at 2:59 PM, Martin Thomson <[email protected]>
> >> wrote:
> >>
> >> https://tools.ietf.org/html/draft-trammell-optional-security-not-00 is
> >> relevant.
> >
> > A reasonable guiding principle, but sometimes *availability* trumps
> > security.
> > This is sufficiently often the case with email to make explicit preference
> > for
> > delivery above all other concerns a necessary feature.
> >
> > When a user gets a delay warning for their initial attempt to send a
> > time-sensitive
> > message, it should be possible to resend the message with an explicit
> > opt-out of
> > enhanced security protections (beyond unauthenticated opportunistic
> > STARTTLS).
> can't they opt-out by re-sending to their submission agent without the
> REQUIRETLS SMTP command?
You're assuming that the only TLS-related failure case that could occur
is when REQUIRETLS is used. I can assure this is not the case. TLS failures
occur all the time, and as things stand we deal with them by falling back
to no-TLS transfer. In such cases we cannot tell whether it's an attacker
or a received-side problem.
MTA-STS changes this: It provides a way for receivers to state that they
want TLS used and senders should assume a problem is caused by an attacker.
The problem is they are still going to be screwups - in fact they are likely to
increase in number - and this combined with MTA-STS is going to be an issue.
> or is the fear that their submission agent
> will invoke REQUIRETLS on the next hop without the user's permission?
The REQUIRETLS SMTP extension isn't even on my radar. My only interest in this
draft is that it provides a way for senders to say "screw privacy, I want my
message delivered".
> fwiw, i think troubleshooting alone might be sufficient reason to
> document the "RequireTLS: NO" message header, but i'm pretty unclear on
> any sane UI/UX story for how a troubleshooter manages to introduce it --
> it's pretty much expert feature territory (e.g. those of us who edit our
> message headers by hand).
I would hope it's obvious that you don't present in a UI as having anything to
do with TLS, security layers, and other technical matters. A presentation along
the lines of "favor delivery over privacy" would seem to make at least some
sense.
Ned
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
