Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Thu, Mar 14, 2019 at 9:38 AM Viktor Dukhovni <[e-mail]> wrote:

> > On Mar 14, 2019, at 11:53 AM, Eric Rescorla <[e-mail]> 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.
>
>