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

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

Warning: tangent.

On 6/29/10 10:09 PM, Shumon Huque wrote:
> On Tue, Jun 29, 2010 at 03:49:38PM -0600, Peter Saint-Andre wrote:
>
>> 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).

Correct. Here's the rub:

   mail.hostingprovider would have to be configured with that
   certificate (with the co-operation of example.com).

In most cases, the admins of example.com don't want to trust
hostingprovider.com with their private keys, and the admins of
hostingprovider.com don't want the legal liability of holding private
keys for example.com either. In the XMPP community we have been working
on a solution to this problem (see draft-ietf-xmpp-dna), but the problem
applies more generally (IMAP, etc.) and is becoming more urgent with the
spread of hosted applications. Richard Barnes has coined the term "High
Assurance Re-Direction" ("HARD") for this problem. He and I have been
planning to write an I-D that describes this "HARD problem", but it's
becoming increasingly unlikely that we'll meet the I-D cutoff before
Maastricht.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/