150 likes | 289 Views
key-signing key flag [1] & wildcard-optimization [2]. Olaf Kolkman [1] with Jakob Schlyter [2] with Johan Ihren and Roy Arends. Key Signing Key (KSK) Flag. draft-ietf-dnsext-keyrr-key-signing-flag-03 with Jakob Schlyter. The Gist.
E N D
key-signing key flag [1] &wildcard-optimization [2] Olaf Kolkman [1] with Jakob Schlyter [2] with Johan Ihren and Roy Arends
Key Signing Key (KSK) Flag draft-ietf-dnsext-keyrr-key-signing-flag-03 with Jakob Schlyter
The Gist • Operational need to distinguish between key-singing keys and zone-signing keys. • Not used in the protocol and verification process but useful for troubleshooting and key exchanges. • Use the 15th bit so that the parity determines the ‘role’ of the key, that’s for us… humans.
KSK Example Before: net 300 IN KEY 256 3 5 Ox1tVxw+j... 300 IN KEY 256 3 5 OTxq2ce5J... After: net 300 IN KEY 256 3 5 Ox1tVxw+j... 300 IN KEY 257 3 5 OTxq2ce5J...
What’s next • Final update and last call?
DNSSEC Wildcard Optimization draft-olaf-dnsext-dnssec-wildcard-optimization-01 with Johan Ihren and Roy Arends
Background • Assumption: One needs proof for non-existence of a wildcards. • The proof is to be supplied in the common case where there is no wildcard in a zone. • That proof is complicated and somewhat expensive in terms of computational resources and packet size. • Is there a way to signal that there is no wildcard in a zone?
Very common case • Root will need to proof that *. does not exist. • As an aside: • Some people love the idea of a wildcard at the root
The proposal • Use a bit in the NXT RRs type bitmap to signal non-existence of wildcards • The meaning: There is no wildcard expansion possible of any name in the zone’s namespace spanned by a NXT RR. • Simplest algorithm to set the bit: • Turn it on on all NXT RRs in the zone if there are no wildcards in the zone • Turn it of on all NXT RRs in the zone if there is any wildcard in the zone
Server side • If the NXT RR proving the non-existence of an exact match has the bit set then no further NXT RRs are needed. • If the bit is not set on that NXT RR a full denial of existence needs to be served.
Resolvers Side • When bit is set on the NXT RR proving the denial of existence of the QNAME, no further proof is needed; • Full RFC2535 type proof of non existence is to be expected and processed if the bit is not set.
Pros and Cons Pro: • Shortcut to a simple and fast code path for server and resolver in the case there are no wildcards. • Smaller footprint on the wire and in caches. Con: • Although bypassed in the ‘common case; the complicated verification code is still needed. • Special meaning of type bitmap bit: • RR type code without RR. • Backwards incompatible (needs to piggyback on DS flag date)
Current version of doc. • The suggested algorithm for setting the bit contains an error • Details will be posted to namedroppers • Clarifications are needed
What’s next • Update the draft • Does the working group think this is a sane path. General comment: • DNSSEC protocol specs need to describe algorithm for denial of authentication of wildcards • If not, resolver implementers will do it wrong. • No need for more than 2 NXT RRs? (Give me an example that needs more.)
Questions??? • http://www.ripe.net/disi • olaf@ripe.net