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

[Benjamin Kaduk <[e-mail]>]

On Thu, Feb 21, 2019 at 10:24:17AM +0000, Alexey Melnikov wrote:
> Hi Benjamin,
> A couple of comments on some of your DISCUSS points:
> 
> > On 21 Feb 2019, at 04:55, Benjamin Kaduk <[e-mail]> wrote:
> > 
> > I'm also concerned about the apparent new burden placed on senders to
> > actively decide whether every outgoing message requires end-to-end TLS
> > protection or is safe to forward without TLS, especially in light of the
> > apparent goal (see next paragraph) of quickly achieving (near-)universal
> > deployment.
> 
> While I have sympathy toward the feeling that some users would be unable to decide, there are certain classes of email messages that would require either "yes" or "no" option. For example, banking statements sent in email might always require "yes".
> 
> >  There doesn't seem to be much in this document to justify
> > the stance that the default "don't care" option should be removed.
> 
> The default option is always present (as it is the default SMTP behaviour) when the client chooses not to use the extension. So "don't care" option is always possible.

I'm looking at Section 4.3 and reading it as requiring the MUA (or other
agent) to make an explicit "yes/no" choice; it use wording like "In either
case", etc.  Can you point me at what the "no choice" option in that text?

> > The "must chain forward to final delivery" property for the REQUIRETLS
> > option seems to present some incremental deployment difficulties, in that
> > it will be nigh-impossible to successfully deliver such a message until
> > there is fairly significant deployment coverage.  E.g., if any major email
> > hosting provider does not implement, then it will forever remain a niche
> > technology.  What indication to we have that this technology can succeed as
> > specified?
> 
> There are several SMTP extensions on Standards Track that have similar properties. IETF generally didn't require "prove that it gets deployed" for them. There are already some implementations (as per the write-up).

It's just surprising to see a "your message won't get sent if the whole
path doesn't support this extension" behavior; this seems to require a
critical mass of deployment before any major usage is possible.
I don't object per se to specifying things like this, but it does make one
wonder whether we should spend so much effort on things that may be of
little use in practice.

> >  If we anticipate it becoming a part of the de facto core,
> > mandatory, SMTP feature set, should we not indicate that by an Updates:
> > relationship?
> 
> We haven't done this in the past even for widely deployed SMTP extensions. This is not a reason not to do this in the future, but I think starting with this extension would cause more confusion.

Perhaps this could be discussed on the call (which, sadly, I don't expect
ot be on).  I recognize that it would be weird to start a precedent here,
and of course if the intention is not that this extension become de facto
part of core SMTP then my concern disappears.

-Benjamin