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"
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...
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
