> On Feb 20, 2019, at 11:55 PM, Benjamin Kaduk <ka...@mit.edu> 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.
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.
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).
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.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
