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. > > 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. > >> - Change its certificate to include a complete list of all the domains >> it is serving, and have its CA sign off on that certificate. > > Not needed in the "ask the user" approach, which is what 6186 > entails. Also not needed with SRV records protected with DNSSEC. > With plain-old SRV records, and no user confirmation, one is left > with no trustworthy identifiers other than SRV-ID (_imap.domainpart > of user's email address and the like). > > So, if indeed MUAs want to implement this draft, and "ask the user" > is acknowledged as denial of reality, then they MUST use SNI. > > For example RFC7671 and RFC7672 mandate SNI for DANE clients. > > Indeed in TLS 1.3 SNI becomes mandatory to implement and send: > > https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-8.2 As I read that spec, it says mandatory to implement, not mandatory to use (it's up to the application whether it claims to be capable of using it or not) - but it permits servers to mandate its use. *Almost* there - but if this draft wishes to mandate its use, it will have to say so (and say which identifier it's going to send - AFAIK, it only gets to send one.) > >> The reason it cannot provide one certificate per served domain is that >> neither this specification nor any other specification I have found says >> that the client MUST include any distinguishing information (such as a >> Server Name Indication) that says what name it is expecting the server >> to provide service for. > > See above. >