On Thu, Mar 14, 2019 at 9:38 AM Viktor Dukhovni <vik...@dukhovni.org> wrote:
> > 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). > Well, my point is that this use case is in direct conflict with the plain text of the semantics of MTA-STS. > > 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. > Yes, that's what my footnote assumes. This seems pretty weak. > > 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 think you are misunderstanding me. I am saying that the same indication that says "use TLS" should also list the exempt addresses. -Ekr > [ 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
