D. J. Bernstein writes ("Re: An easy example of A6 unreliability"):
> The SIG semantics don't have to be modified. When the server copies the
> A record, it can also move it into its own zone, sign it, and change the
> NS record accordingly.
I complained:
> This would I think be rather poor practice on the part of the server.
> Signing something just because someone else signed something is not
> usually a good idea, [...]
In fact, you can set it up so that it's not necessary for the server
to re-sign the A's for the nameservers into the parent zone.
Consider a nameserver for example.com. If we have something like
example.com NS ns0.iana.org
foobar.iana.org A 10.0.0.1
then the obvious problem is that the client can't verify the signature
on the A because the packet syntax makes it hard to make it clear
which key signed it, and that the client doesn't necessarily have (and
maybe will have trouble finding and verifying) the relevant zone key.
However, in fact this is just the this surface problem. It arises
because of the deeper problem that the cryptographic delegation
structure is wrong.
The key which signs the A doesn't really have anything to do with the
key for example.com. The example.com key doesn't explicitly delegate
to the key to [foobar.]iana.org; instead, it merely names iana.org and
expects the general secure DNS infrastructure to find the right key to
sign that record. The crypto delegation path is from example.com via
(implicitly) the global root key to the keys for org, iana.org and
then possibly another zone key for foobar.iana.org if that's a
subzone. This is totally insane.
Instead, if you do this
example.com NS ns0.iana.org
ns0.example.com A 10.0.0.1
and forbid that ns0 is delegated, then the delegation path problem
doesn't arise. Here the delegation path is quite simple: com
delegates by signing the NS RR and the example.com zone key, and the
example.com zone key itself signs the A.
A client which has all of the relevant RRs can check the certificate
chain, and hence the validity of the nameserver address, straight
away.
If the client *doesn't* get both the address RR and its signature from
the original server for com, they have a problem. They can't check
the signature on the A, so they don't know that it's valid. They
probably shouldn't cache it and should vaoid using it. At best they
could use it as a hint to try to find authenticated copies of the same
data - or alternatively, they could make queries for the delegation
address and its signature record from the parent server, which
hopefully has a copy.
So I'm coming to the conclusion that to get delegation to work
sensibly with secure DNS, we have to require something like this:
* Delegation NS hostnames must be in the zone being delegated to
(and must have exactly one extra label?)
* When serving up a delegation, the parent server must pass on the
glue, including the glue's signature. What if it won't fit in the
packet ? Perhaps the server should set TC and the client should retry
with TCP, or perhaps the parent server for a delegation must be
willing to serve up the glue, including its signature, in response to
an explicit request.
Ian.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
