To:
David Blacka <davidb@research.netsol.com>
Cc:
namedroppers@ops.ietf.org, dnssec@cafax.se
From:
Derek Atkins <warlord@MIT.EDU>
Date:
16 Oct 2001 21:19:12 -0400
In-Reply-To:
David Blacka's message of "16 Oct 2001 16:28:35 -0400"
Sender:
owner-dnssec@cafax.se
Subject:
Re: comments on delegation signer
David Blacka <davidb@research.netsol.com> writes:
> First is a fairly minor issue: the DS draft states that in the textual
> representation of a DS record, HEX should be used to display the SHA-1
> hash. However, this is inconsistent with the other DNSSEC RR types.
> This forces implementors to create or have access to a base16
> conversion library, in addition to a base64 library. I can see no
> particularly compelling reason to use hex here, especially considering
> that base64 is sufficient for the other DNSSEC records.
Hex is used in the DS draft because pretty much every other security
protocol uses hex to represent hash values. As for a base-16
"library", last I checked it was provided in LIBC. Two particular
functions you should know about: "printf" and "scanf". If that isn't
sufficient for your tastes, any programmer worth their grain in salt
can write a base16 parser in less that 10 lines of C.
> Instead, a better approach might be to require DS enabled servers to
> return either:
>
> NS RR set + DS RR set + SIG{DS} set (for secure delegations)
>
> OR
>
> NS RR set + NXT + SIG{NXT}. (for insecure delegations)
>
> The NXT record needs to show the non-existence of a DS (or KEY) RR
> set.
I was under the impression that this was implied by the fact that the
parent zone was secured in the first place. The DS SIG on the DS
record is implied by the fact that the parent is secure. So in the
case of a secure delegation the client should expect NS + DS +
SIG{DS}. Alternatively is should expect expect NS + NXT + SIG{NXT} in
the case on an insecure delegation. Again, this is implied by 2535.
> Merely receiving NS RRs could either be an error (if we are aware that
> the zone is using DS) or could be interpreted as a SIG@child
> delegation.
Merely receiving NS RRs would violate 2535, so the client would know
something was up. OTOH, DNSSec does not protect against most DoS
attacks.
> --
> David Blacka <davidb@research.netsol.com>
> Sr. Research Engineer Verisign Applied Research
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available