> On Mar 14, 2019, at 11:53 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
> We had a bunch more discussion on this on the IESG call. It seems like
> the primary use case for TLS-Required=no may be to exempt what's basically
> the control channel from the requirement to use TLS. So, for instance,
> I am getting persistent bounces from you and I want to notify you
> about it, so I send that notification with the TLS-Required=no flag set
> [0].
That's one use case, but another important use case, is giving *users*
the ability to resent low-sensitivity but time-sensitive messages, that
bounced or were delayed because of downstream misconfiguration.
Think "Happy Birthday Grandma" (ideally not belated) postcard (i.e.
cleartext OK).
> Assuming that's right, then ISTM that actually this is not the ideal
> design, both because it's not clear how the flag gets set and because
> the recipient has had no chance to weigh in.
The "flag" gets set by the MUA, by adding the appropriate header. For
webmail clients, that'd be something the WebUI could provide as option
when the user is reviewing a bounce or a delay notice for a message he
sent that did not (yet? and will likely not as-is) make it to the intended
recipient.
For power-users (postmasters, or other technologists) using Mutt, Pine, ...
the header can just be added in their favourite message editor.
> What I would suggest would
> instead be to extend MTA-STS and DANE to exempt specific "control"
> addresses (e.g., Postmaster) from mandatory TLS. This seems like it
> would solve the main problem while avoiding opening the can of
> users just marking routine messages as non-sensitive.
Unfortunately, that does not work. These days, a large fraction of
domains have no working "postmaster" addresses. The technical contact
addresses for many domains are no longer published in WHOIS, but one
may be able to scrape a responsible user from the website, or from
the DNS SOA "mrname".
There are no "control address" localparts that work for (essentially)
all domains, and email to "postmaster" may actually in some cases be
sensitive, and unrelated to transport security obstacles.
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've been sending DANE-related misconfiguration notices since 2014,
and postmaster@ bounces back as undeliverable in ~30% of the cases,
and is not necessarily read by anyone even if delivered, I typically
include additional notice recipients whenever available. ]
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
