Eric Rescorla wrote:
>
> Götz Babin-Ebell <[EMAIL PROTECTED]> writes:
>
> > [1 <text/plain; us-ascii (7bit)>]
> > Don Zick wrote:
> >
> > Hello Don,
> >
> > > I'm not actually using DNS at all. For the application I'm working with
> > > the TLS clients and servers must be statically configured with a Fully
> > > Qualified Domain Name. I match up the statically configured FQDN for a
> > > client with the DNS name from the client's certificate.
> >
> > You are using DNS.
> >
> > On the network layer you only have the IP address.
> > To get the FQDN you need to use DNS.
> >
> > And compared with certificate / private key
> > authentication it is trivial to forge a wrong DNS answer.
> > (At least if you don't use DNSSEC on all your clients and servers...)
> >
> > When an attacker is able to steal a private key,
> > he is also able to poison your DNS...
> I think you're misreading Don's message. He's not looking up the
> client's FQDN from the IP, he's extracting it from the verified
> certificate. It's perfectly legitimate to use this for authentication
> decisions and this doesn't relay on trusting the DNS.
And how gets he the connection IP-Address <-> FQDN ?
->He uses DNS.
Why should he use the FQDN in the cert for any other uses ?
If he wants to allow user XYZ presenting certificate C_XYZ to
do some things, all he has to do is look in an internal
table to map the cert to the allowed tasks.
Introducing the FQDN into this is a useless layer of complexity...
> Note that HTTPS behaves essentially this way: you use the DNS to
> resolve the IP to connect to the server. You then compare the
> server's FQDN (as found in the certificate) against the URL.
But this is to avoid trust in a possible poisoned DNS.
This needs the private key secure on the server.
His plan was to do it the other way round:
If an attacker has obtained the private key he wants
to prevent missuse with DNS.
And that is broken.
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
S/MIME Cryptographic Signature
