On 6/19/10 8:04 AM, Paul Hoffman wrote: > At 12:36 PM +0100 6/19/10, Alexey Melnikov wrote: >> Hi Paul, >> >> Paul Hoffman wrote: >> >>> 1. The certificate MUST include a "DNS-ID" (i.e., a >>> subjectAltName identifier of type dNSName). >>> >>> 2. If the service using the certificate deploys a technology in >>> which a server is discovered by means of DNS SRV records >>> [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate >>> SHOULD include an "SRV-ID" (i.e., an instance of the SRVName >>> form of otherName from the GeneralName structure in the >>> subjectAltName as specified in [SRVNAME]). >>> >>> If 2 is true, what is the value of the required DNS-ID? >>> >> One or more hostname for machines that would provide the specified >> service. I.e. most likely some/all hostnames from the output of DNS >> SRV lookup, but I can think of some examples where other hostnames >> can be used in addition to or instead of these. E.g. a machine on >> internal network, hostname of a NAT box, etc. > > So a cert says "the hostname of this server is www.example.com, and > you can look up the hostname for the server using SRV"? What does > that mean in a security context? If I get back one name of > yyy.example.com, does that mean that the host has both names, or that > there was a lookup error?
My understanding of the SRVName extension is that it is primarily intended to restrict the use of a certificate to a particular application type (e.g., IMAP or XMPP). This is what Shumon meant when he said: If someone intends to deploy a certificate with an application specific name form such as SRV-ID or URI-ID, then they typically would not want to have a dNSName in the certificate, to make sure that the cert can't be (mis)used for unrelated application services at that domain name. However, DNS SRV records have the property of enabling you to redirect the source domain (e.g., example.com) to a target domain (e.g., apps.example.net) that is outside of the trust boundary of the source domain. Thus draft-daboo-srv-email says: A malicious attacker with access to the DNS server data, or able to get spoofed answers cached in a recursive resolver, can potentially cause MUAs to connect to any IMAP, POP3 or submission server chosen by the attacker. In the absence of a secure DNS option, MUAs SHOULD check that the target FQDN returned in the SRV record matches the original service domain that was queried. If the target FQDN is not in the queried domain, MUAs SHOULD verify with the user that the SRV target FQDN is suitable for use before executing any connections to the host. During recent discussions within the XMPP WG, we decided that we didn't need text along those lines because a malicious attacker with access to the DNS server data could simply return an evil IP address in a DNS result, so why bother the user with scary warnings about a DNS SRV mismatch? It's unfortunate that RFC 4985 glosses over the difference between (1) the use of SRVName extensions to restrict deployment to a particular application type and (2) the use of DNS SRV records to redirect a source domain to a target domain that might be outside the trust boundary of the source domain. It might be appropriate for draft-saintandre-tls-server-id-check to have some text about this, and I'll try to write that soon. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
