Re: [Uta] Email over TLS drafts

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

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

Cheers,
Orit.


> -----Original Message-----
> From: Alexey Melnikov [mailto:[e-mail]]
> Sent: Tuesday, February 25, 2014 11:43 AM
> To: Orit Levin (LCA)
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Email over TLS drafts
> 
> Hi,
> 
> On 23/02/2014 22:47, 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?
> 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).
> >
> > 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 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 "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.
> I think trying this out for email first and then generalizing later is
> the best course of action.
 
OL: I addressed these in my previous email. I think, we all are in rough agreement here. ;-)

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

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

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

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