Re: [Uta] Email over TLS drafts

[Keith Moore <[e-mail]>]

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.

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

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

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

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.