Re: [Uta] Email over TLS drafts

["Orit Levin (LCA)" <[e-mail]>]

Keith and Chris,
Thanks a lot for your detailed feedback!
We all seem to agree that it is very helpful to start the conversation on the list before the meeting.
Also, we are in rough agreement on the rest of the points, I think. Please, see inline.
Cheers,
Orit.

 > -----Original Message-----
> From: Chris Newman [mailto:[e-mail]]
> Sent: Monday, February 24, 2014 1:49 PM
> To: Keith Moore; Orit Levin (LCA); Alexey Melnikov
> Cc: [e-mail]
> Subject: Re: Email over TLS drafts
> 
> --On February 23, 2014 18:40:32 -0500 Keith Moore
> <[e-mail]> wrote:
> > On 02/23/2014 05:47 PM, Orit Levin (LCA) wrote:
> >> Dear authors,
> >> In preparation for the London meeting, a few questions/comments about
> >> the email drafts:
> >>
> >> First, both drafts address the interface between MUA and MSA only,
> >> correct? It would be interesting to show (in the presentation), what the
> >> situation looks like for other email interfaces (e.g., between MTAs).
> >
> > I could certainly address that in a presentation, especially since I've
> > already talked about it in Vancouver.
> >

OL: Great, thanks! I had to find and read the DANE TLS draft, to figure out the differences. I think that a high level intro (with pointers to other RFCs/drafts) needs to be included in the draft especially for non-IETF insiders.

> > However, I'd really like to minimize presentation time and maximize
> > discussion time.   I realize that since this is the first meeting of the
> > UTA WG, some presentation time is probably appropriate.
 
OL: Yes, at the first meeting, a succinct intro to each topic will be very helpful for establishing common grounds among a broad range of UTA participants. It might even save some Q&A cycles :-) .

   But overall
> > IETF seems to be stuck very much in powerpoint zombie mode (not to
> single
> > out powerpoint, the problem exists no matter which tool you use to put
> > slides on a screen), with the result that WG's don't make effective use
> > of meeting time.
> 
> +1. People who haven't taken time to read the draft should be confused by
> the presentation, or we've made it too long. I find most IETF presentations
> low value unless the words "open issues" are prominent on the slide.
> 
OL: I wouldn't disagree, except for the first meeting. Certainly, people do need to read the drafts and post  questions for clarification on the list before the meeting.

> > Bottom line: I need to confer with my co-author, but my intention is to
> > try to make the presentation as brief as possible so as to permit more
> > time for discussion.   I can, however, include at least one slide about
> > the difference between using TLS in MUA-server interaction vs. MTA-MTA
> > interaction.  (Hint: the differences almost all result from the fact that
> > MUA-server interaction happens by prior agreement between the parties,
> > whereas there's no such assumption about MTA-MTA interaction).
> 
> The MTA-MTA TLS standards were botched in both specification and
> deployment. I'm inclined to let the separate DANE proposal be the
> mid/long-term answer for MTA-to-MTA, although I'd consider it an open
> issue
> whether more deployment of unauthenticated encryption for MTA-to-MTA
> might
> be worth some effort.
> 
> >> draft-newman-email-deep-01
> >>
> >> - I think that merging the two drafts was the right move. It allows
> >> readers to see the whole range of techniques for consideration. That
> >> being said, the draft includes both (1) suggestions for preferred
> >> methods of operation based on existing standards and (2) new
> mechanisms
> >> to enhance privacy when email protocols are secured by TLS.  Would you
> >> consider discussing  the two categories using parallel tracks (drafts)
> >> in order to streamline the work?
> >
> > Offhand, I'm not sure how this would streamline the work, and it seems to
> > me that it could actually delay implementation.   Multiple drafts, of
> > course, require more editing cycles and more time in the working group
> > (probably more face to face meetings) - especially when it is necessary
> > to keep the drafts in sync with one another. Multiple documents can also
> > make things confusing to implementors, who have to read and understand
> > all of the documents and also understand how those documents fit
> > together.  Both (1) and (2) require code changes, even though the changes
> > in (1) are somewhat modest.   My guess is that most implementors would
> > prefer to implement and test both sets of changes at the same time.
> 
> As an implementer, I'll +1 this. However, if the WG has rough consensus to
> split the document, I won't be a vocal opponent.
> 
> > Though I'm not even sure I understand what you mean by (2), unless
> you're
> > referring to latches.   If that's what you mean, I think it might make
> > sense to split latches from the rest of the document  if it takes us too
> > long to understand how to make them work well, and therefore that
> > including latches would significantly delay publication of the other
> > material. 
 
OL: That was my exact point :-)
New ideas would better be developed separately from clarifications and/or improvement techniques.

  I think it's a bit early to make that determination, but
> > maybe we'll have a better understanding after the discussion in London.
> 
> I also agree. Having discussion time for latches is important. I think it's
> the most interesting new idea in the spec, but I'm just not sure it will
> make the cost/benefit cutoff. If it needs to be split out of the draft or
> dropped, so be it.
> 
> >> - I am curious why the proposed latch mechanism (defined and used in
> >> sections 4, 6, and 7) has been considered for email applications
> >> specifically. I understand that you need some kind of an "application"
> >> or "signalling" or "management" protocol to implement the mechanism,
> but
> >> potentially it could be a common one to serve any application. This
> >> question seems especially applicable to the latches' definitions
> >> themselves.
> >
> > One answer is that both Chris and myself started working on our proposals
> > before the UTA group was even being discussed, and certainly before its
> > charter and scope took shape.   Also, I've personally found it useful to
> > further narrow the scope of my proposal (from TLS for all email protocols
> > to just MUA-server interactions) because there were just too many subtle
> > differences between even those two use cases to sort out all at once.
> > So I'd be somewhat reluctant to try to broaden the scope of latches just
> > yet.
> >
OL: Totally understood. By moving "latches" to a dedicated and separate from the "email over TLS" draft, would allow keeping all options open.

> > Latches, if they can be made to work well, probably are more generally
> > applicable than just for interactions between MUAs and email servers, but
> > I don't think it's immediately apparent just how many differences there
> > would need to be in the latches for each use case.  But I don't want to
> > discourage others from trying to understand how latches would be used
> > with other protocols.
> 
> It's also been my experience that when the IETF tries to develop a general
> broadly applicable mechanism from scratch, the effort usually fails. On the
> flip side if a mechanism is developed for a specific application, deployed
> successfully and then generalized there's a much higher chance of success.
> So I'm presently unwilling to work on a generalized latch mechanism
> although I do think the mechanism is an interesting idea that should be
> considered for generalization if some deployment for a specific application
> proves successful.
> 
> > p.s.  More generally, I'd like to caution people against assuming that
> > there's a "one size fits all" profile of TLS that makes sense across a
> > wide variety of protocols and application scenarios.   If nothing else,
> > there are subtle differences in the way that different protocols and
> > applications interpret DNS names and use DNS which almost certainly
> > should affect signature and certificate evaluation.  I think we're just
> > beginning to scratch the surface of these.  If it works out that a small
> > number of broadly defined profiles are sufficient to secure most apps,
> > that would be a happy result, but I don't think we should assume that
> > this will be the case.
> 
> I'm often dismayed by how complex generalized specifications become. RFC
> 6125 was an attempt to generalize certificate verification across
> applications (I provided the nudge that started that effort). It ended up
> quite a bit more complex than application-specific certificate verification
> text (e.g. the relevant part of RFC 4513) and it didn't eliminate the need
> for application-specific profiles such as
> draft-melnikov-email-tls-certs-01. RFC 6125 may get more consistency among
> application TLS profiles, but it comes with a rather high negative cost to
> specification readability. I'm uncertain it was worth the effort and the
> exercise made me more skeptical of attempts to generalize.
> 

OL: I hope that we have this "generality" vs. application-specific considerations discussion on Friday. We will need to keep it specific and to the point, though! ;-)

> 		- Chris