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

[Shumon Huque <[e-mail]>]

On Tue, Jun 29, 2010 at 03:49:38PM -0600, Peter Saint-Andre wrote:
> 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.

Yup, that's what I meant ..

> 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?

Yeah, I think I agree with that.

> 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.

I'm not sure I see a problem here. So what if the domain name of 
the SRV owner (LHS) is in a different administrative domain than 
the domain name in the rdata of the SRV record (RHS)? The TLS certificate
matching function should only be considering the first one. It
can't trust the resolved name unless the lookup was authenticated
anyway (with DNSSEC), or the resolved name was explicitly trusted by
static local configuration. I assume the use case is hosting
providers, eg.

  _imap._tcp.example.com  IN SRV 10 10 143  mail.hostingprovider.com

All the client needs to do is authenticate the certificate associated 
with the identity on the left side (eg. SRVName of _imap.example.com 
or dNSName of example.com etc). mail.hostingprovider would have to be 
configured with that certificate (with the co-operation of example.com). 
If the client gets redirected to connect to mail.evil.com by a DNS attack, 
the client will fail to authenticate the name on the left side (unless 
the attacker has also stolen the cert and key).

--Shumon.