Paul,
--On 22 January 2010 14:51:38 -0500 Paul Wouters <[email protected]> wrote:
the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible.
1. Therefor*e*
2. I don't think the last sentence follows from the foregoing, in that
this behaviour is desirable for the zone operator! (I know what
you mean).
3. Aside from that, I don't think an injunction to avoid Opt-Out in
these terms is sensible in a delegation only zone. In such a zone,
I don't really see the additional security risk from opt out across
insecure delegations, given if a spoof can be done, it can be
done at the delegated zone level.
If I secure example.org, and .org is signed, OPT-OUT might cause a spoofed
exemple.org to not be caught by the user's validating resolver. Therefor,
I do think opt-out should be avoided when possible.
If I run .org, which is signed, but example.org is NOT signed (i.e.
is an unsigned delegation), there seems to be little reason to avoid opt out
across it. Whilst it might be harder to spoof the absence or existence
of the delegation, I can still spoof the contents (or absence of
contents) in example.org. So, whilst opt-out should be avoided
across intervals containing secure delegations, I see no reason
to avoid it across intervals that don't contain secure delegations.
There are considerable operational
advantages in Opt Out (zone size, cryptographic complexity etc.)
I understand zone size, though I don't understand "cryptographic
complexity".
Having different "security values" attached to data within the same zone
seems
more complex to me, not less complex?
I meant computational resource requirements resultant from crypto
operations, not algorithmic complexity.
The owner names in NSEC3 RRs are cryptographic hashes of the original owner
name. Assume you have a delegation only zone consisting of sparse secure
delegations amongst many insecure delegations. If you are using NSEC3 at
all, using opt-out substantially reduces the number of NSEC3 records (since
many insecure delegations will cluster together within the opt-out
interval) and thus the length of the NSEC3 chain, and hence reduce the
number of cryptographic hash calculations. Similarly the zone itself is
smaller, so less work to sign. The situation is exacerbated where the
insecure delegations are volatile.
It might be worth mentioning (but is perhaps blindingly obvious) that
NSEC3 is substantially more complex in terms of implementation than
NSEC. Whilst one can by visual inspection spot the odd problem with
a small zone's NSEC chain, it's far harder with NSEC3. Obviously, if
a tool chain is used to NSECify and sign the zone, that's a problem
for the implementor rather than the operator.
--
Alex Bligh
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
