Subject: [Uta] Email over TLS drafts

From: "Orit Levin (LCA)" <[email-masked]>
Date: Sun, 23 Feb 2014 22:47:29 +0000

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).

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?

- 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. 

draft-melnikov-email-tls-certs-01

This draft seems to specify the preferred methods of operation based on existing standards. It would helpful to show (in presentation and in the document) which of the recommendations are about putting constraints on the existing standard vs. what statements are real changes to the standard and thus require replacing sections in the existing RFC.

Are any of the suggested recommendations in this draft would apply to applications other than email?

Thanks and looking forward to your presentations in London,
Orit.

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Feb 2014 18:40:32 -0500

> 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., be…

I could certainly address that in a presentation, especially since I've 
already talked about it in Vancouver.

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.   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.

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).

> - 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 pref…

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.

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.   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 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 "appli…

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.

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.

Keith

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Feb 2014 19:43:08 +0000

Hi,

On 23/02/2014 22:47, Orit Levin (LCA) wrote:
> First, both drafts address the interface between MUA and MSA only, correct?
Yes. Earlier discussions pointed out that TLS deployment realities for 
MTA-to-MTA links are a bit different from MUA-to-MSA. In particular 
certificate verification rules might be different.
> It would be interesting to show (in the presentation), what the situation looks like for other email interfaces (e.g., between MTAs).
>
I am not an editor, but I am personally Ok with both being discussed in 
the same draft. If the WG ends up not quickly converging on new bits, it 
might be worth discussing the split.
> - 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 "appli…
I think trying this out for email first and then generalizing later is 
the best course of action.
> This draft seems to specify the preferred methods of operation based on existing standards. It would helpful to show (in presentation and in the document) which of the recommendations are about put…

This intends to replace SMTP Submission TLS server verification procedure, because RFC 3207 is underspecified in this respect.
It also intends to replace IMAP TLS server verification procedure from RFC 3501. If you think it would help the discussion, I can quote specific text being replaced and what is the practical difference for implementations. draft-melnikov-email-tls-certs is a profile of RFC 6125, so it is using different terminology, which makes understanding the difference a bit trickier.

> Are any of the suggested recommendations in this draft would apply to applications other than email?
I think this is quite specific to email. I know that XMPP and HTTP 
differ slightly from what is proposed for email.

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Wed, 26 Feb 2014 13:22:32 +0000

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:[email-masked]]
> Sent: Monday, February 24, 2014 1:49 PM
> To: Keith Moore; Orit Levin (LCA); Alexey Melnikov
> Cc: [email-masked]
> Subject: Re: Email over TLS drafts
> 
> --On February 23, 2014 18:40:32 -0500 Keith Moore
> <[email-masked]> wrote:
> >> 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).
> >

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.

> > 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
> 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.

> > 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.
> 
> >> - 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
> > 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.
> 
> 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
> > 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
> 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.

> > 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.
> 
> 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

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Wed, 26 Feb 2014 13:45:35 +0000

Alexey,
Thanks for the answers!
Please, see inline.

Cheers,
Orit.

> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Tuesday, February 25, 2014 11:43 AM
> To: Orit Levin (LCA)
> Cc: [email-masked]; [email-masked]; [email-masked]
> correct?
> > It would be interesting to show (in the presentation), what the situation
> looks like for other email interfaces (e.g., between MTAs).
> >
> > - 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?
> 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.
 
OL: I addressed these in my previous email. I think, we all are in rough agreement here. ;-)

> > This draft seems to specify the preferred methods of operation based on
> existing standards. It would helpful to show (in presentation and in the
> document) which of the recommendations are about putting constraints on
> the existing standard vs. what statements are real changes to the standard
> and thus require replacing sections in the existing RFC.
> 
> This intends to replace SMTP Submission TLS server verification procedure,
> because RFC 3207 is underspecified in this respect.
> It also intends to replace IMAP TLS server verification procedure from RFC
> 3501. If you think it would help the discussion, I can quote specific text being
> replaced and what is the practical difference for implementations. draft-
> melnikov-email-tls-certs is a profile of RFC 6125, so it is using different
> terminology, which makes understanding the difference a bit trickier.
> 

OL: I am concerned about the readability for two distinct types of readers: newcomers (both implementers and deployers) vs.  those familiar with the existing RFCs. Replacing a chapter with the new text  would work for the former, while a diff-like implementation guide would help the latter...  So it seems that both are needed in the same document... As a precedent, RFC3261 Section 28 comes to mind... (Luckily, our case is not as long as that of SIP.) It would be interesting to know what other think. 

> differ slightly from what is proposed for email.

OL: That's totally cool from my perspective. Just making sure that we all are paying attention to the "generic" angle.