Notes from the NSEC3 workshop in Frankfurt

Day 1

Tools used:

All tools linked here: Implementations

All in hope to find any combinations that works...

Wiki test plan: Testing

Version 3 of the test plan here: http://www.nsec3.org/pipermail/nsec3-testing/attachments/20060405/4b71860a/Test_Plan_NSEC3-v3.txt

draft 5 pre3, hasn't been posted yet, but is here: http://www.nsec3.org/draft-ietf-dnsext-nsec3-05pre3.txt

Geoff sent resolved and unresolved issues to nsec3-testers.

Mark: do we cover empty wildcards? Make sure we cover that.

Issue: do we have signalling between nsec and nsec3 zones? what happens when an nsec only resolver try to resolve an nsec3 zone? do we need signalling? suggestion, pick a signal and put that in the perl tools, during the workshop (roy).

There was a long discussion on how to signal nsec3, and how to set up tests with chains going from nsec3->nsec->nsec3 and such. Also if the signal is going to be the new key type.

The transisition for a zone from NSEC to NSEC3 will be from NSEC to unsigned to NSEC3, each stage will be 2*TTL.

Roy will run the test zone ws.nsec3.org, with zone1.ws.nsec3.org etc.

"Internal" copy of IMP3 has been distributed to the workshop.

Issue, do we need to simultaneously support one, two or more nsec3 chains? Jabber-note: "wouter: Issue from Mark(ISC): multiple complete chains. Prop to not allow multiple complete chains."

Issue, potential wildcard hashes should not collide with any other nsec3 hash. (11:23:06 AM) wouter: Req for signers (from Mark, Wouter): please make sure you have no collisions (11:23:22 AM) wouter: but also between non-existing wildcards and all other existing NSEC3s.)

geoff: So is Mark making a case for changing the language of the draft to say that collisions are so unlikely (provided that truncation is not in use) that implementations may safely ignore collision issues altogether? 

(11:52:13 AM) wouter: TYPE_NSEC3 is 65324 for testing purposes.
(11:52:33 AM) roy@nominet.org.uk: ack

The hierarchy of test domains is set up, running different implementations, but using the same signed zones. First test is IMP1(ben), next is IMP3, and the last is IMP2. 

             ws.nsec3.org
      broken.ws.nsec3.org
          oo.ws.nsec3.org
      sec.oo.ws.nsec3.org
    unsec.oo.ws.nsec3.org
sec.unsec.oo.ws.nsec3.org
          no.ws.nsec3.org
      sec.no.ws.nsec3.org
    unsec.no.ws.nsec3.org

Workshop wiki with all files is here: Workshop1

Problem with compiling the zones is that IMP1/IMP2(?) zonec can't handle ENT.

Day 2

AXFR/IXFR issue:

(Note from Mark: The current NSEC3 wire format is not future proof. Without knowledge of the hashlength for the algorithm, you don't know where the hash ends... Not clear in the draft. Also bitmap error in IMP3.)

Today IMP2 cannot get a zone transfer from any other IMP1/IMP2 because it asks for the zone with IXFR and no IMP1/IMP2 version can provide IXFR at all. IMP2 can take a zone transfer from IMP3 but there is a bug in IMP2 incoming zone transfer code that's is impeding progress.

IMP3 can't receive a zone transfer with an NSEC3 that has an empty bitmap, for example ENT.

TESTS

Zone signing tests:

All good, but signing a zone with a very long name, didn't work with one not mentioned signer.

Zone transfer tests:

IMP3 version is now fixed, can do transfers (from IMP3 to IMP1), still need some tests. What happens with unknown hash algorithms during zone transfers? Still needs testing.

Discussion point: SHOULD you be able to load the zone with unknown hash algorithms? What is the expected behaviour?

Authorative answers tests:

The draft is not very clear on NSEC3 records should ... show up in the bitmap. Might not be consistent. Test cases 12 and 14, queried directly for NSEC3 records. Different responses from the servers, something seems wrong. Needs discussion. Relevant test case might also be number 15. 11 can't be done?

Recursive server tests:

Works out using IMP3 dig and unbound. New test proposed, wildcard with NSEC3.

Resolver/validator tests:

Fairly stable. Adding to the BROKEN zone. Still needs work. Found some bugs in drill.

Bitmap question, what happens when the nsec3 name has the same name as the A record?

Note the following things not being tested: ancestor zones on same server, any NSEC-->NSEC3 or NSEC3-->NSEC delegations

From Mark: the draft is missing words on "iterations" which caused the implementation bug in BIND. 0 iterations made hashes missing...

(1-dimensional vs 2-dimensional tests. The test plan is only for 1 resolver and 1 server. Add more tests to find out where it actually works, like a secure delegation in 2 steps in the chain.)

Might also want to test the DS grandparent problem with NSEC3.

All tests are done with IMP1 with IMP2 as fallback. IMP3 might not be working according to spec.

(We should) break down the test plan and add tree based tests. Dynamic updating is not tested (and not in the draft?)

The current NSEC3 wire format is not future proof without knowledge of hashlength for the algorithm in use. Propose to add a length field.

DISCUSSION POINTS (after the first tests with IMP1) found here: DiscussionPoints

day 3

Going for IMP3 testing.

Wiki pages for the testing groups are created by Geoff. Test_Notes

The IMP3 tests have exposed a minor problem with Unbound - Unbound fails to send any response back if it has a validation error.

Final status of where we are (after the tests)

Ed: figuring out how to sign zones to look for special cases that are not obvious.. (tear things apart) how do one match what i asked for with the reply i received... ordering of the hashes.

Matt: all test result are in the wiki. no tests of negative stuff done yet. Ben: those tests worth doing on Unbound, because it handles them, but drill don't Roy: finished test number 12

Matt: what tests are still depending on broken packets?

IMP1/IMP2/(?) has support for incomplete chain... (ignores incomplete chains) supports loading of the zone (with an incomplete chain?). supports multiple incomplete chains.

Scott: updated the test results on the wiki

Suz/Mark: authorative tests against IMP3 and IMP1/IMP2, hit som ambiguities. discovered some bind bugs, at least one in IMP2.

Geoff: has been working on a script to validate NSEC3 chains automatically

Ed: Is there any danger if doing an axfr with the hashnames with the names as a comment together? (for debug use) (Peter: what? new record type?) no, in the zone file... (the signer can do it)
Mark: you can have dig do that.
Roy: would it help if you have a tool that you can pipe the zone through?
(there seems to be such a tool.) Ben: a good tool would provide the proof of what you want to know..
Mark: theoretically dig could provide you with the proof.
Ed: (it's getting harder to understand the proof)
Matt: what ed is stalking about has never bothered me. but it may depend on perspective.

Peter: a little progress text discussion.
stuck on unknown hash algorithm (in zone loading), how to fail/warn/...

Open issues (Matt): (this is newer: WS1_ToDo)

  1. Dynamic update
    Ben: not an issue, the server rebuilds as necessary (opt-in). If opt-out you have to add DS.
  2. Auth server behaviour in presence of unknown NSEC3 hash algorithm (Peter writes text)
    Mark sends text to namedroppers.
  3. Incomplete NSEC3 chains (consensus is to allow them)
  4. NSEC/NSEC3 coexistence in the same zone (needs discussion)
    Dependent on signalling mechanism in (this list) issue #5
    Update draft: signalling allows new key to sign NSEC as well as NSEC3, draft to also describe potential transition mechanism using these semantics.
  5. Signalling NSEC3 delegations to RFC4035 resolvers (given to Dave, refer it to namedroppers)
  6. Mixing opt-out/not-opt-out-bit spans in one zone (Matt is posting to nsec3-testing)
  7. Check potential wildcard name with collisions at signing time (update to draft, MUST not collide)
  8. Field hash length in NSEC3 RDATA (update draft)
  9. (Non-)existence of NSEC3 owner names (Peter is writing text)
  10. Opt-Out isn't enforceable--note in draft? (Matt will update security considerations in draft)

Non-existant TLDs: The proposal is that if you try to prove the apex you don't have to do that. (you don't have to add the particular NSEC3 that does that since you'll have other NSEC3 RRs that either by their existence (or by their respective RRSIG) prove that the apex exists)

"Current" list of issues at Issues Most fixed, issue 7, 8, 9, 10, 11, 12, 13 and 14 is still left, also on the above open issues-list. The current Issue-list has out of date texts as well.

NSEC -> NSEC3 roll link from Geoff: http://www.atm.tut.fi/list-archive/namedroppers-2005/msg01162.html

Last discussion was in the Jabber room: 

(03:10:47 PM) ogud: WRT NSEC->NSEC3 or NSEC3 -> NSEC that does not have to be covered, as the requirenet is only to support NSECx to/from Unsecure.  In my mind that implies that NSEC++ and NSEC CANNOT coexist in the same zone, the document needs to be clear that any such zone is BOGUS. 
(03:11:22 PM) weiler: would someone in the room like to channel olafur?
(03:11:49 PM) pawal: so if .SE wants to make the transition to NSEC3 it has to go through unsecure first...
(03:12:02 PM) ogud: Yes 
(03:12:44 PM) ogud: But that Unsecure state can be real short, by having all RRsigs expire at some time and bring the new NSEC3 zone up few minutes later 
(03:12:55 PM) ogud: s/some/same/
(03:13:41 PM) pawal: that means we have to update our slave servers really fast, which is not a process we have today
(03:14:58 PM) weiler: yesterday, we had matt arguing that rolling trust anchors would not be very possible.  de-installing (or rolling) trust anchors would be a necessary part of an NSEC-->NSEC3 or NES--> unsecure transition.
(03:15:37 PM) ogud: The question becomes, where is the pain, in specialized software that is only going to be used few times OR by having operational guidelines on how do do it. 
(03:15:44 PM) pk: How do I bring up a zone at the size of DE 'a few minutes later"?
(03:17:39 PM) geoff: I think we have implicitly moved NSEC <-> NSEC3 roll from "non-requirement" to "issue list" status now.
(03:17:55 PM) ogud: Peter: Routing tricks, you split your servers into two groups one serves NSEC the other is offline loaded with NSEC3, before the switch the first group is answering queries, when you switch you tell the routers to change which servers are now answering. 
(03:18:05 PM) geoff: Do folks agree?
(03:20:46 PM) geoff: Ben says this is still not a requirement, but would be nice to document method which minimises (perhaps to zero) any period of insecurity.
(03:21:11 PM) geoff: (If I got that right . . .)
(03:22:12 PM) ogud: Peter: this is exactly what the anycast clusters are supposed to be able to do. Turn on/off a set of nodes as required.  
(03:24:15 PM) ogud: I agree 100% with Ben, we can either have a protocol methold or a operational methold, personally I preffer the second one. as that makes the protocol simpler and there is less of a chance of things going to real bad state. 
(03:24:50 PM) pk: ogud: well, yes, but neither does one have everything under anycast nor is it controllable in the 'few minutes' range. But anyway I'm not saying we need to complicate the protocol and the solution at the drawing board looks good
(03:25:40 PM) pk: we might want to have an "nsec/nsec3 transitioning guide", though
(03:27:07 PM) ogud: Peter: Anycast tricks are only needed by "bigger" zones, small zones can do this in few minutes, the question is what do "medium" zones do. (not sure where the lines are).   
Ben's proposal is to have the new DS records for NSEC3 mean "NSEC _or_ NSEC3".

Reopen the issue on how to make the transition from NSEC to NSEC3.