Hi Jim,
On Fri, Aug 02, 2019 at 10:17:37AM -0700, Jim Fenton wrote:
> It seems we're fairly clear on what needs to go into the revision, except....
>
> On 7/30/19 11:16 PM, Jim Fenton wrote:
> > On 7/30/19 5:02 PM, Benjamin Kaduk wrote:
> >> On Tue, Jul 30, 2019 at 04:11:36PM -0700, Jim Fenton wrote:
> >>> On 7/17/19 12:18 PM, Benjamin Kaduk via Datatracker wrote:
> >>>
> >>>> The following paragraph (unchanged from my ballot on -07) received
> >>>> only minimal
> >>>> discussion so far:
> >>>> I'm also concerned about the apparent new burden placed on senders in
> >>>> Section 4.3 to actively decide whether every outgoing message requires
> >>>> end-to-end TLS protection or is safe to forward without TLS ("when TLS
> >>>> is to be required, [...]. When TLS is not to be required, [...]"),
> >>>> where both
> >>>> "[...]" require new behavior not present in a client that does not
> >>>> implement
> >>>> this specification. To some extent this is an editorial matter of
> >>>> how the
> >>>> new mechanisms are portrayed, but I don't see much in this document
> >>>> to justify
> >>>> the stance that the default "don't care" option should be removed
> >>>> (for clients
> >>>> that implement this specification at all).
> >>>
> >>> The justification here is much the same as for MTA-STS (RFC 8461).
> >>> Paragraph 2 of the introduction of RFC 8461 presents the justification,
> >>> and paragraph 3 of the introduction to this draft says much the same
> >>> thing.
> >>>
> >>> 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.
> >>
> >> That would also make this very solidly an editorial matter, in which
> >> case I
> >> am happy to suggest text modifications but cannot put a blocking Discuss
> >> position in place...
> >
> >
> > I'm confused by your comment (as was Viktor). My comment above was
> > motivation for having a REQUIRETLS option. Nobody is suggesting that
> > we get rid of or otherwise change the default "don't care" --
> > REQUIRETLS is an option, and SMTP will continue to work the way it
> > currently does when REQUIRETLS is not applied to a message.
> >
> At this point I'm not clear on whether you consider the motivation for
> REQUIRETLS to be sufficient (ala RFC 8461) or whether additional
> content, such as a reference to this paper, should be added. It sounds
> like it may make the case too strongly, i.e., to imply that we might be
> trying to change the behavior of email from default-opportunistic TLS to
> something else. But if you think additional motivation is needed vs.
> what's in the current draft, I'll try to improve that.
Sorry for causing confusion.
I was never concerned about the level of motivation for REQUIRETLS as a
whole. What I was worried about was the apparent indication in the text
that all MUAs (not MTAs as I erroneously said before) that implement the
feature would have to decide, for each message, whether or not to require
TLS. Since this was just a problem of me misreading the text, and there
was in fact no intent to remove the default "don't care" option for MUAs,
there is no need to add any additional motivating text in the document.
Does that help?
Thanks,
Ben
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
