Re: [certid] What DNS-ID if also using a DNS-SRV?

[Peter Saint-Andre <[e-mail]>]

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/