Re: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard

[Shumon Huque <[e-mail]>]

On Mon, Aug 02, 2010 at 11:39:44AM +0200, Stefan Winter wrote:
> Hi,
> 
> > Well that, and SRVName. There are many other custom types
> > defined by specific applications but those aren't the focus
> > of this document.
> >   
> 
> a closely related question to that. In one of my drafts, SRVNames are
> used, but not directly.
> 
> There is a S-NAPTR based algorithm which first tries to find a specific
> S-NAPTR, and then follows the results from there (typically, via SRVName
> to hostname to IP addresses).
> If there is no S-NAPTR, a SRV query is tried.
> 
> In the latter case, matching between the SRV record in DNS vs.
> SAN-SRVName can be done, and the server id can be verified.
> But in the former case, if S-NAPTR in DNS is forged, it is well possible
> to drive the querying peer to a bogus SRV record, and an attacker can
> have a (unrelated) certificate for this other SRVName. That was, the
> querying host can be tricked into initiating a connection to a false
> peer because it cannot verify that the NAPTR -> SRV step was correct.
> 
> I've been thinking about a workaround for that. As much as I know, there
> is no subjectAltName for NAPTR verification. So my only conclusion so
> far is: using NAPTR can only work securely if requiring DNSSEC; so that
> the NAPTR can't possibly be forged.

Stefan,

Yes, I think I agree with your analysis.

And even if there were a subjectaltname for NAPTR services, it 
appears that the components of the (service specific) identity you 
want to verify are in the RDATA of the NAPTR record, rather than 
the owner name of the record, so you need to secure the DNS mapping.

> I wonder: is there another way of securing server discovery in the
> presence of a NAPTR -> SRV redirection?

Besides DNSSEC, or some other secure mapping service, I can't think 
of an obvious one. You'd need to figure out how to encode the service 
identity in the DNS query name, which is precisely the thing the 
S-NAPTR lookup is trying to find.

> 
> And do you consider disususing this issue in your draft?
> 

Are you proposing to just discuss this issue, or that we should
try to find a solution to the problem?

-- 
Shumon Huque
University of Pennsylvania.