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 <fwei...@bfk.de>
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
Date: February 22, 2010 11:20:16 PM PST
To: Olaf Kolkman <o...@nlnetlabs.nl>
Cc: Alex Bligh <a...@alex.org.uk>, Paul Wouters
<p...@xelerance.com>, dnsop WG <dnsop@ietf.org>
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
