Alexey Melnikov <[email protected]> wrote: > On 12/04/2015 00:08, Brian Smith wrote: >> Even if the client uses SRV records, it will still operate just fine >> using DNS-IDs and without supporting SRV-ID, right? > > In general case this is not true. This will only work correctly if DNS SRV > is pointing to a server in the same DNS domain. > > Take for example a case where email addresses @example.com are outsourced to > another provider, e.g. gmail.com > When a client connects to IMAP service for example.com, it needs to know > that imap.gmail.com is a legitimate server for this service. So either > imap.gmail.com's TLS certificate needs to include sRVName _imap.example.com > or it needs to include dNSName for example.com. The latter is of course > problematic if only IMAP service is delegated to imap.gmail.com.
When the MUA connects to imap.gmail.com, how would the server know which certificate to give the MUA? Would the MUA put "_imap.example.com" in the SNI extension of the TLS ClientHello when connecting to the GMail server? If so, where is it explained how SRV-IDs are mapped to SNI? In particular, it seems like when RFC 6066 says "the only server names supported are DNS hostnames" it means SNI must only be used with DNS-IDs. That seems problematic. It also seems unreasonable to expect mail servers for GMail and other large mail hosting servers to have certificates that contain SRV-IDs that identify every single customer. > I would not interpret it like this, because CABForum can't talk for uses of > TLS outside of the browser world. Many members of the CABForum consider the scope of the CABForum to include all TLS certificates that can be *could* be used by a web browser. More importantly, browser root CA inclusion programs generally don't consider the needs of MUAs to be any different than browsers as far as TLS certificates are concerned, so there's no provisions for SRV-IDs. It is pretty typical for root stores to base their set of root CA certificates on what browsers, Mozilla in particular, include in their root CA programs, so I think that those concerns are likely to limit the application of the advice in this draft RFC unless/until the root inclusion policies are updated to deal with SRV-IDs. > XMPP uses presence of XMPP URIs (see Section 13.7.1.4 of RFC 6120) in > subjectAltName for TLS verification. According to your interpretation > CABForum certificates disallow XMPP use as well. Yes. > and yes. I am tempted to collect more information and show examples of how > this can be done in Java and using other open source libraries. I think it would be great to see a working example, especially as far as SNI is concerned. > 1) I've looked at several big Mail Service Providers and pretty much all of > them use DNS SRV to advertise location of their submission/imap servers. > They don't user sRVName in subjectAltNames, which makes it impossible for > email clients to verify whether such servers are legitimate. So I think > something needs to be done to address this problem. I agree. > 2) I am expecting that some CAs would be unable to validate/accept sRVNames > in certificate signing requests. This can be intentional and can be covered > by "local policy". But at least they must not crash and burn when they > encounter sRVName in subjectAltNames. otherName and uniformResourceIdentifier are intentionally ignored by the Firefox/Thunderbird certificate verification, except that any otherName or uniformResourceIdentifier name constraint at all in the issuer certificate chain will automatically cause validation to fail. > 3) This document is not reflecting universally widespread practice, because > frankly too many email clients don't verify TLS certificates, and server > certificates don't comply with very basic requirements expressed in much > earlier RFCs. I don't believe there is a requirement for a Standard Track > RFC to only reflect what is already deployed, in many cases Standard Track > RFCs are drawing attention to what should be the recommended practice. Like I said, I think generally the goal is a good one. However, the mechanism seems problematic as far as deployment is concerned: 1. Root CA inclusion programs for Thunderbird and other MUAs need to be updated to consider SRV-IDs, particularly what otherName name constraints a "technically constrained externally-operated sub-CA" must have. 2. Certificate verification logic needs to be extended to provide a proper API and a proper implementation of that API for dealing with SRV-IDs, because SRV-IDs need to be treated differently from DNS-IDs (and CN-IDs), and current APIs are mostly/totally designed for DNS-IDs. 3. It seems unreasonable to require that the mail hosting provider have certificates with srvName subjectAltName entries for all customers' DNS names. Even for moderately-sized hosts, this would seem to require the management of a too-large number of certificates. 4. It isn't clear how a CA would go about securely verifying that a mail hosting provider like GMail is authorized by a domain name owner (e.g. example.com) to request and use a certificate with a srvName for the domain name (e.g. GMail asking for an _imap.example.com certificate). In practice, traditionally standardizing such practices is done in the CABForum. If CABForum is inappropriate here, then how will such issuing practices be standardized? 5. If the owner of example.com switches his hosting from mail.gmail.com to mail.outlook.com, how does the owner of example.com go about disabling the certificate containing srvName _imap.example.com that mail.gmail.com is using? It seems to me like it is worth considering an alternative mechanism where it is possible for example.com to say that imap.gmail.com is hosting its email for a certain duration of time, such that imap.gmail.com doesn't need to get any certificate that specifically mentions example.com, siimlar to the Alt-Svc mechanism for HTTP/2. Cheers, Brian _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
