On Thu, Mar 14, 2019 at 09:43:35AM -0700, Eric Rescorla wrote:
> > Think "Happy Birthday Grandma" (ideally not belated) postcard (i.e.
> > cleartext OK).
>
> Well, my point is that this use case is in direct conflict with the plain
> text of the semantics of MTA-STS.
Neither MTA-STS nor DANE specify a per-message opt-out mechanism.
A key difference in our viewpoints, is that in my view once such
an opt-out is invoked, DANE and MTA-STS are no longer in use, so
there's no conflict at all, since the sender is no longer using
DANE or MTA-STS, the sender has elected a different security policy
for the message (typically opportunistic STARTTLS).
No sender is obligated to use DANE or MTA-STS, and this draft
delegates part of the decision to the sender. The sender's MTA may
choose to not honour the "RequireTLS: no" hint, because local policy
mandates stronger security for a particular destination or in general.
A browser doing HTTPS allows me to click through various warnings
and see a site whose certificate does not match its name, is expired
etc. Email delivery is asynchronous, and so the corresponding user
opt-out signal needs to be in the message content.
> > By far the more reliable notification channel, is email to an actual
> > user, who knows how to reach support for his provider, or in SOHO
> > cases knows (or is) the administrator in person.
>
> I think you are misunderstanding me. I am saying that the same indication
> that says "use TLS" should also list the exempt addresses.
Well, that's not going to happen. The receiving systems are not
anticipating and planning for failure. You're still trying to put
all the controls on the receiving side, and that just does not work,
and does not give users the option of delivering time-sensitive
messages directly to their correspondents (rather than the support
team that may not get around to a ticket from a stranger for days).
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
