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

[Benjamin Kaduk <[e-mail]>]

Hi Viktor,

Sorry for the slow response.  It took me a while to mull over why exactly
this position felt incorrect to me.

On Thu, Feb 21, 2019 at 12:54:17AM -0500, Viktor Dukhovni wrote:
> > On Feb 20, 2019, at 11:55 PM, Benjamin Kaduk <[e-mail]> wrote:
> > 
> > While I understand that there can be cases where it is desired to ignore
> > recipient-domain indications to use TLS, such as to report problems with
> > the TLS capabilities of those domains, I have strong qualms about
> > describing this protocol as an "override" for DANE and MTA-STS, or that
> > such recipient-domain signals should be "ignored".  In effect, by
> > attempting to do so, this document is fundamentally modifying the
> > protocol semantics for (SMTP) DANE and MTA-STS, something that can only
> > properly be done by clearly calling out the behavior change and an
> > Updates: relationship with the documents whose semantics are being
> > modified.  Alternately, it could also be reasonable to remove claims of
> > "override" or "ignore" and to leave the semantics of the header field as
> > being that the sender requests one behavior, and the MTA can balance the
> > requests of the sender and recipient at their own discretion. This is
> > still not a great option, though, as it would seem to put multiple IETF
> > proposed standards at odds with each other.
> 
> My take is rather different.  I see "REQUIRETLS = no" as an enabler of
> adoption for DANE and MTA-STS, and as the primary feature of this draft
> that will have a more significant positive security impact (by paving
> the way to adoption of more secure transport by default) than the
> "REQUIRETLS = yes" option, which likely won't see much use.

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).  I'm inclined to believe
you about that; you have a lot of real-world experience in these areas and
also have spent a lot of time working on finding actual deployment paths!
But what I have trouble with is that the response to "DANE/MTA-STS are
flawed" is not "make an extension to them that fixes them" but rather "make
a new thing that says to ignore parts of them", with no pointer from the
DANE or MTA-STS ecosystem to the new thing, to let people know what they
should be doing.

> There's no conflict with DANE and MTA-STS here, neither trumps the
> senders local policy, whether set by the administrator or delegated
> by the administrator to the user.

Local policy will always be a trump card; sure.  It is free to ignore any
and all RFCs.  But we still have some responsibility for what guidance we
provide as input into local policy, and having one RFC say "ignore that
other RFC" when both are active proposed standard documents (and not in an
Updates: relationship) doesn't look very good.

> While we can hope that operational excellence will make delivery problems
> due to botched MTA-STS or DANE rare, there will surely be temporary outages
> here and there, and giving users a mechanism to work around them is better
> than disabling transport security for all users at the first whiff of a
> problem, defeating much of the protection that DANE and MTA-STS would
> enable.
> 
> Providers that support a user override, can be much more confident that
> enabling recipient security policy will be something their users can
> work with, because on a delivery failure, the user can resend with
> "REQUIRETLS = no" if the message requires little privacy protection,
> but is time sensitive.  The user knows best which messages are OK to
> resend without authentication (possibly in the clear).

It sounds like we could frame this as a DANE/MTA-STS "escape hatch",
wherein the sender knows that the recipient requested TLS but the sender
decides to send without TLS anyway.  But this still seems like it would
need some concrete tie-in to the base DANE/MTA-STS specs.

> Companies where there are regulatory constraints to not let users
> override transport security policy (HIPAA, ...) can elect to not support
> "REQUIRETLS = no" and even strip the header to reduce the likelihood
> of it taking effect downstream.

Sure.

-Benjamin