Re: [Uta] Email over TLS drafts

[Alexey Melnikov <[e-mail]>]

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

> 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.
> Thanks and looking forward to your presentations in London,
> Orit.