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

[Benjamin Kaduk <[e-mail]>]

On Tue, Jul 30, 2019 at 09:19:40PM -0400, Viktor Dukhovni wrote:
> On Tue, Jul 30, 2019 at 07:02:23PM -0500, Benjamin Kaduk wrote:
> 
> > > This work was inspired by a paper, "Neither Snow Nor Rain Nor MITM ...An
> > > Empirical Analysis of Email Delivery Security"
> > > http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf that there was a
> > > presentation about at an IETF meeting a few years ago (can't find it on
> > > datatracker currently). If you think the draft would benefit from
> > > additional motivation, I could mention this paper and add an informative
> > > reference to it.
> > 
> > This makes it sound like your stance is roughly, "we want to make TLS on by
> > default but have to deal with deployed reality in order to get there",
> > which would seem to have the consequence that "MTAs implementing
> > require-TLS should default to requiring TLS and only request no-TLS in
> > special cases".  I would support such a position, and in that case would be
> > less concerned about the apparent lack of a "don't care" option, since
> > there is less of a decision burden when there is a clear default behavior.
> 
> I don't quite understand this comment. :-(  Typically, the "Require-TLS"

Probably because it has no sensible interpretation; sorry about that :(

I think that the only change needed is s/MTA/MUA/, though.

> signal originates at the submitting MUA, not an MTA.  MTAs may
> *support* "Require-TLS", but they generally won't originate the
> policy for messages in transit.
> 
> Some MSAs (or outbound edge MTAs) may add "Require-TLS" to messages
> in transit for "business-partner" destinations where there's a
> reasonable prior expectation that authenticated TLS is available
> along the entire delivery path.  But this will be the exception,
> rather than the rule.
> 
> Similar considerations apply even more strongly to explicit "don't
> care", which should not be added by a transit MTA, and instead
> should result from a user's choice to request delivery even in the
> face of degraded transport security.
> 
> So I don't know what to make of "MTAs implementing require-TLS
> should default to requiring TLS and only request no-TLS in special
> cases".
> 
> Neither requiring TLS (end-to-end in the sense of the present draft)
> nor requesting "no-TLS" (really requesting delivery despite lack
> of or failure of authenticated TLS en-route) is somenthing that the
> MTA would normally choose.  Rather the MTA, in support of the
> present draft, would implement the policy conveyed in the message
> envelope (require) or headers (don't care).
> 
> Sorry to be so dense, perhaps you can expand your point to make it
> more clear...

Just my tired brain being sloppy about MTA vs. MUA (and not even reading
the document properly, either).

Thank you for expending the time to write out the explanation above; I
think probably we have shed enough electrons on this topic, should take
Jim's proposed new text, and move on.

-Ben