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

[Stefan Winter <[e-mail]>]

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: [phone]
Fax: [phone]