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

[Benjamin Kaduk <[e-mail]>]

On Wed, Feb 27, 2019 at 03:12:04PM -0500, Viktor Dukhovni wrote:
> On Wed, Feb 27, 2019 at 01:35:42PM -0600, Benjamin Kaduk wrote:
> 
> > It seems like implicit in this stance is a belief that DANE and/or MTA-STS
> > as currently specified are flawed, in that they do not have a reasonable
> > path to substantial deployment (in bounded time).
> 
> REQUIRETLS "no", is essential for at least the "postmaster" address
> (in the rare cases when that still works), or some address scraped
> from the destination domain's website, found in the few WHOIS records
> that still list contact addresses, or in a working DNS SOA "mrname".
> When all else fails, the user can notify the peer end user on the
> receiving domain to contact his postmaster, open a support ticket etc.
> 
> Both specifications do a fine job of specifying the recipient's
> preferred policy.  No specification, regardless of the details, can
> ensure that the recipienet lives up to the promised service level.
> 
> DANE, MTA-STS, any superior design or security-theatre-de-jour, will
> still lead to cases where security degrades delivery.  At the very
> least one needs to be able to exempt delivery to the email address
> of the domain contact.
> 
> And when all else fails, and the message is just "let's do lunch",
> nothing will be more effective than a clear user choice to deliver
> anyway.  This a fact of life, and not a defect in DANE or MTA-STS.

If it's a fact of life; why was the capability to do so not built into DANE
or MTA-STS?  It really does seem like a defect, the way you're portraying
it: the stated goal of the spec is at odds with reality, and reality is not
going to break.  So, yes, as you say below, my point is that they should
have provided an end-user opt-out from the outset, and if this document now
is to provide that opt-out, it should be treated as an update that remedies
the omission.

-Benjamin

> The need is intrinsic to multi-hop asynchronous delivery, by providing
> the equivalent of the "press OK" to skip various warnings in
> end-to-end interactive applications.
> 
> If your point is that DANE and MTA-STS should have provided an
> end-user opt-out from the outset, maybe so, but I should note that
> RequireTLS entered the UTA queue about the same time as MTA-STS,
> and with the understanding that the "no" mechanism will be a useful
> complement for both MTA-STS and DANE or any other techology which
> by defers delivery in the face of apparent active attacks (which
> are often simply operational negligence on the receiving end).
> 
> -- 
> 	Viktor.
>