Subject: 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

From: Stefan Winter <[email-masked]>
Date: Mon, 02 Aug 2010 11:39:44 +0200

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.

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

And do you consider disususing this issue in your draft?

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Shumon Huque <[email-masked]>
Date: Tue, 3 Aug 2010 22:57:54 -0400

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

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

---

From: Stefan Winter <[email-masked]>
Date: Wed, 04 Aug 2010 07:46:39 +0200

Hi,

> S-NAPTR lookup is trying to find.

Thanks for giving this some thought!

> try to find a solution to the problem?

I wouldn't mind if you try to solve it, of course :-) But since there is
apparently no trivial "fix" to server id validation, I'd be just as
happy with a simple paragraph stating that validation of
(S-)NAPTR-derived identities doesn't work in a trusted manner without
DNSSEC.

(But that's just me, since I don't mind prescribing DNSSEC in my draft;
but my working group chair already expressed that he'd prefer something
else)

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 05 Aug 2010 14:10:59 -0600

> but my working group chair already expressed that he'd prefer something

I've added a note about this to our working copy (Jeff and I are working
to push out -09 today).

Peter

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