Den 02. des. 2015 13:16, skrev Alexey Melnikov: > On 02/12/2015 12:06, Harald Alvestrand wrote: >> Den 01. des. 2015 18:37, skrev Viktor Dukhovni: >>> On Tue, Dec 01, 2015 at 03:34:32PM +0100, Harald Alvestrand wrote: >>> >>>> If I understand this draft correctly, I object. >>>> >>>> It says: >>>> >>>> >>>> 2. When using email service discovery procedure specified in >>>> [RFC6186] the client MUST also use the right hand side of the >>>> email address as another "reference identifier" to compare >>>> against SRV-ID identifier in the server certificate. >>> The key word in that text is "another". This does not require the >>> server to have a certificate that matches this identifier, provided >>> there is some other some suitable identifier. It provides additional >>> flexibility, not a constraint. >>> >>> NOTE HOWEVER, that use of the server name from the SRV record as >>> a DNS-ID reference identifier offers no security at all absent >>> DNSSEC. So "another" might become "only" in that case. The 6186 >>> approach to address lack of trustworthy identifiers basically boils >>> down to "ask the user". Once the user confirms the SRV record it >>> becomes pinned, and the server name becomes one of the reference >>> identifiers. >> Which server name? I couldn't tell from this draft either which would be >> presented or which would be stored (I assume you'd want them to be the >> same). >> >> Actually this highlights another problem: The draft claims to replace >> section 2.4 of RFC 2591, "Server identity check", but fails to provide >> replacement text for a crucial part of that document: >> >> "If the match fails, the client SHOULD either ask for explicit user >> confirmation, or terminate the connection and indicate the server's >> identity is suspect." >> >> This document doesn't say anything about what should happen once the >> match is finished. > It does by reference, see RFC 6125. OK, now I see it: It says (3.3 intro) "Matching is performed according to the rules specified in Section 6 of [RFC6125], including "certificate pinning" and the procedure on failure to match". Consider this issue satisfied. >>> My question upthread was whether this draft continues that legacy, >>> or departs from it. >>> >>> HOWEVER: >>> >>>> If I understand RFC 6186 correctly, a (possibly large scale) IMAP email >>>> service provider that wishes to serve a new domain "example org" >>>> according to RFC 6186 must do two things: >>> I am not aware of any adoption of RFC 6186. Are there are any MUAs >>> actually doing RFC 6186 SRV lookups? If there are none, is it worth >>> debating? >> The draft claims to have a normative dependency on RFC 6186. If the use >> of RFC 6186 is not worth debating, the reference is worth deleting. > There are some uses of RFC 6186. How widespread? I don't know. > Note - I don't have an opinion on the use or non-use of 6186. What I'm saying is that if we reference it, we need to have something the providers will be able to practice.