Subject: [DNSOP] RFC4641bis Editing Status Report.

From: Olaf Kolkman <[email-masked]>
Date: Sat, 20 Mar 2010 09:10:32 -0700

Colleagues

This is a status update on RFC4641bis. Please refer to links provided for more details on the issues. I have no particular issues I need to discuss in the face to face meeting and will present what is written below in a somewhat condensed form. If folk have something they would like to discuss it is probably best to give a heads-up here.

High level summary:

Most changes in the document are with respect to the description about keys and key maintenance (section 3). I've tried to stress the operational tradeoffs and make those the basis of the cryptographic considerations. The idea is that the tradeoff between costs and threats set the operational handling of the keys. Once you know how you want to handle the keys operationally set the appropriate crypto parameters. 

Also there is a completely new section on the Next Record types (section 5) and there are considerations added about the changing ones dns operator (section 4.4.5)

In detail
- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs
Addressed in a section 3.1.4.3  "Private Key Storage"
I believe this issue to be resolved.

- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/NSEC-NSEC3
Complete new section 5.

There is one remaining point there brought up in 
	From: 	Florian Weimer <[email-masked]>
	Subject: 	Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
	Date: 	February 22, 2010 11:20:16 PM PST
	To: 	Olaf Kolkman <[email-masked]>
	Cc: 	Alex Bligh <[email-masked]>, Paul Wouters <[email-masked]>, dnsop WG <[email-masked]>

NSEC making the packet too big base on the argument that " However, NSEC records are sometimes returned in response to
DO=0 queries"

I believe there is consensus that that is caused by an implementation bug. Therefore the issue can be closed.

- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Review-NIST

Scott reported that this issue can be closed.

- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency
- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/cryptography_flawed
- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/discussion_of_timescales
- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/rollover_assumptions

I believe these issues where addressed by reordering and rewriting parts of section 3. But this section may need a little more work to clarify that the approach is from operational perspective rather than a highest achievable crypto perspective.

http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/non-cooperative-registrars
Added as:
4.4.5.2.  Non Cooperationg DNS Operators

This issue is resolved although a review of the supporting figure is needed.

The following issues have not yet been addressed and the issue needs to be reviewed on relevance against the current version

http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_and_parent_keys
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/timing_terminology

I've added
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Signature_validity
From the recent mail from Sebastian where he asks for guidance on signature validity intervals

that is an issue that is probably closely related to 

http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/timing_terminology

which I will address in the next version.

Yours,

--Olaf Kolkman
  document editor

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Paul Wouters <[email-masked]>
Date: Sat, 20 Mar 2010 15:34:55 -0400 (EDT)

> - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/NSEC-NSEC3

That still states:

 	"as well as no algorithm choice for SHA-256"

That's been resolved now, see http://www.bind9.net/dns-sec-algorithm-numbers
RSASHA256 has DNSKEY algorihtm 8 and RSASHA-512 has alg 10. As far as I
know, these include NSEC3, though the registry contains no pointers for that.

Is it noted anywhere that algorithms > 5 imply NSEC3 support? If not, should we?

Paul

---

From: Chris Thompson <[email-masked]>
Date: 20 Mar 2010 19:51:34 +0000

>know, these include NSEC3, though the registry contains no pointers for that.

It contains a pointer to RFC 5702, and section 5.2 of RFC5702 is completely
clear on the subject.

>Is it noted anywhere that algorithms > 5 imply NSEC3 support? If not, should we?

I suppose it is still open to DNSEXT to submit new algorithms which imply
NSEC only, but of course that is not expected to happen. (Anyway, 253 & 254
are "> 5" and there it's a matter for private agreement.)

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.