Re: [DNSOP] On Powerbind
Looking for this:
https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml ?
—Olaf
PS. Haven’t looked at this code for over a decade. That last croak,
Postel principle violation?
On 16 Apr 2020, at 23:08, Dick Franks wrote:
Warren,
Comments in line
On Thu, 16 Apr 2020 at 20:31, Warren Kumari wrote:
8
Just checking - the DNSKEY Flags field is 16 bits, and we have so far
burned:
Bit 15 - SEP
Bit 7 - Zone key
Bit 8 - Revoked
Did I miss any (I wasn't able to find a registry for this)?
If not, we still have 13 bits left, and so using one for this seems
ok
to me, especially if recursives doing something with it is
optional...
(I had mistakenly remembered the Flags as being only 8 bits)
I'm still not convinced that DNSSEC Transparency will come to pass,
nor that many zones will use this flag, but I'm now much more
sanguine
about giving it a bit...
The lack(?) of a registry is indeed regrettable.
However, there seems to be some historical meaning attached to some of
the other flag bits.
If I look back at Net::DNS::SEC 0.17, bequeathed to me by one Olaf
Kolkman, the DS create() method contains the following mysterious
(perl) lines, for which I can offer no coherent explanation:
# The key must not be a NULL key.
if (($keyrr->{"flags"} & hex("0xc000") ) == hex("0xc000") ){
croak "\nCreating a DS record for a NULL key is illegal";
}
# Bit 0 must not be set.
if (($keyrr->{"flags"}) & hex("0x8000")) {
croak "\nCreating a DS record for a key with flag bit 0 set ".
"to 0 is illegal";
}
# Bit 6 must be set to 0 bit 7 must be set to 1
if ( ($keyrr->{"flags"} & hex("0x300")) != hex("0x100")){
croak "\nCreating a DS record for a key with flags 6 and 7 not
set ".
"0 and 1 respectively is illegal";
}
which would seem to indicate that some of the other bits were thought
to have some meaning circa 2013.
Perhaps Olaf can shed some light on this topic.
Dick Franks
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Olaf M. Kolkman Tweets as: @kolkman
Principal - Internet Technology, Policy, and Advocacy
Internet Societyhttps://www.internetsociety.org
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-rfc6598-rfc6303
On 21 okt. 2013, at 17:29, Tim Wicinski tim.wicin...@teamaol.com wrote: Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. I support adoption although that feels like a formality: Since most responders to your call feel it’s ready I would suggest that the chairs help the editor to convince the AD to individually sponsor the draft and have it IETF last called. That is not an end-run. Maybe that exceptional path creates more overhead than first adopting and immediately last calling, I am happy with this document either way. —Olaf signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-11.txt
Dear Chairs, Some friendly reminders... On May 21, 2012, at 11:40 AM, Olaf Kolkman wrote: Chairs, would you like us to incorporate (some of, see comments from Paul H.) the suggestions in the document _now_ or after you have done your review? This question has been left unanswered. Can you please make sure this document is at the IESG before June? This question has been left unanswered too. Some highlights from https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc4641bis/history/ 2011-06-27 06 Peter Koch IETF state changed to In WG Last Call from WG Document 2011-12-05 08 Peter Koch IETF state changed to WG Consensus: Waiting for Write-Up from In WG Last Call 2011-12-05 08 Peter Koch WGLC discussion on the list did not raise objections That is almost 6 month now. Granted, we have had some comments coming in after the WGLC ended, all of the type that would make reasonable errata. Besides, that is a sign that people take the effort to find and read the draft, to me an indication that there is a need for this document to be published. Please give us an indication when this document will be submitted to the IESG. --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl o...@nlnetlabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on RFC4641bis
Thanks for the very detailed review! Due to family circumstances I cannot be at the dnsop meeting and I will not have time to review all the points you made before thursday. However, since you highlighted this point in the hallway, I would like to ask the working group for guidance. 4.1 Key Rollovers I would STRONGLY suggest that you minimize this section. Just give an overview of how the different rollover methods function and compare them with each other. Refer to the key timing draft, so that we do not get the timings in two documents. From our hallway conversation I understand you mostly refer to the tables and that the fact that text relies on them. We have argued about this during our last face2face meeting. And my take-away from that discussion was that the timings draft was supposed to be guidance for implementors, while this draft is targeted to operators. My understanding was that the tables where a helpful addition (a picture says more than a thousand words). Quickly going back to the minutes I noticed that the above argument (and a counter-argument resembling yours, by Andrew) was captured. But that the room made 'useful sounds' which I took for consensus with keeping the tables in. I would like to get confirmation from the chairs whether that was is the correct interpretation of the discussion instead of revisiting this issue. There may be some more points in your review that are revisiting issues that I think we closed. Unless the chairs instruct me otherwise I am tempted to keep closed issues closed. That said, I really appreciate your detailed review. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] algorithm rollover use cases (was: Signed TLD status)
On Sep 30, 2010, at 3:03 PM, Matthijs Mekking wrote a long mail starting with: On the dnssec-deployment list, the Signed TLD status thread [1] evolved into a discussion how algorithm rollover works in specific use cases. My feeling is that this discussion belongs to DNSOP and so I want to share Key to that message was the distinction of 3 cases for algorithm rollover Now there are other use cases: a) Single Type Signing Scheme Algorithm Rollover b) Trust Anchor Algorithm Rollover (5011 may be used) c) Both a) and b). a pre-published, in step 2 (new RRSIGs). The shadow key must be removed at the same time the revoked KSK_1 is removed from the zone. I have taken a stab at differentiating these cases and guiding the reader through in what will be subsections of section 4.1.5. The figures provided will be added to an appendix. Updated draft to be posted by the cut-off. Thanks --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] grave erroneous statement in draft 4641bis-03
On Jul 27, 2010, at 11:31 AM, Jelte Jansen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 the introduction suggests that the root has not been signed yet. ;-) In version 05, to appear before the cut-off it reads: At the time of writing -the root has just been signed and the first secure delegations are provisioned- there exists relatively little experience with DNSSEC in production environments below the TLD level; --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 4641bis (draft 3 and 4) review - largely 5011 related
Clearly I am trying to get a (hopefully WG last call ready) version 05 of the document out by the deadline. Some comments in-line based on specific feedback you provided. On Aug 5, 2010, at 9:43 AM, Matthijs Mekking wrote: The KSK RFC5011-based rollover method says that the removed key must be post-published as revoked at least holdback timer long. However, that parameter is just a management value for the validating resolver. It should be post-published as revoked the Maximum Zone TTL long. Proposed text: RFC5011 increases the duration of key rollovers, because the key to be removed must first be revoked. Thus, before the DNSKEY1 removal phase, DNSKEY1 must be published for one more Maximum Zone TTL with the REVOKE bit set. The revoked key must be self-signed, so in this phase the DNSKEY RRset must also be signed with DNSKEY1. ACK, this proposed text (modulo some stylistic differences) is added to version 5. This is also true for algorithm rollover. Proposed text: Trust anchor algorithm rollover is as simple as a regular RFC5011 based rollover. The old trust anchor must be revoked before it is removed from the zone. However, at every RRset there must be at least one signature for each algorithm used in the DNSKEY RRset. This means that a different key with the same algorithm, other than the revoked key, must sign the entire zone. This can be the ZSK. More operations is needed if the single type signing scheme is used. Before rolling the algorithm, a new key must be introduced with the same algorithm as the key that is candidate for revocation. That key can than temporarily act as ZSK during the algorithm rollover. ACK. this is added too. End proposed text. Rolling the algorithm of only the KSK or only the ZSK is in my point of view infeasible and useless. And one more RFC 5011 note: In section 4.2.3 (Compromise of Keys Anchored in Resolvers), it might be relevant to mention that RFC5011 can also recover from compromised keys, as long as at least one valid trust-anchor key remains uncompromised. Hmm.. but the compromiser can also initiate a rollover. Therefore I am not sure if the word recover is correct in this context. Finally, some editorial nits in version 4: - - You replaced the names of the DNSKEYs in the tables (for example, DNSKEY_1 becomse DNSKEY_Z_1), but not in the text. ACK - - In the ZSK pre-publish rollover method, at the DNSKEY removal stage, the text says re-sign with DNSKEY1. Although not necessary, it should also be re-signed with DNSKEY11 (DNSKEY_Z_11), because it does so in the table. ACK - - In the ZSK double signature rollover method, at the DNSKEY removal stage, the text says The key set now only containing DNSKEY 11, is re-signed with DNSKEY 1. Again, also resign with DNSKEY_Z_11. Also, the key set also containst DNSKEY_Z_11. ACK Below are some more inline comments. [skip] On a point about RFC5011 text you remark: The text now says: It is therefore recommended to roll KSKs that are likely to be used as trust-anchors if and only if those rollovers can be tracked using standardized (e.g. RFC5011) mechanisms. To avoid confusion, I would add on a regular basis here. ACK [skip] --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] 4641bis (draft 3) status update
Colleagues, Shortly before the cutt-off I submitted version 3. In this mail I want to raise a number of points that are up for discussion in Maastricht (or on the list). For the Maastricht meeting I plan to use _no_ slides but go through the points one by one and discuss/hum etc. The document can be found at: http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-03 And the diffs between this and the previous version are highlighted here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc4641bis-03.txt Based on the feedback during last IETF I've tried to differ the tone of the document. The general approach is that the document gives the considerations and motivations for different operational choices and has weakened some of its earlier recommendations. Specifically the arguments for splitting key and zone signing key or using a 'single type signing scheme' have had some attention. One general comment, when you review please do not review for style/typos quite yet. I've received a set of corrections that I've already applied on the trunk[*]. Please review for content now and wait for typos and other editorial nits review till version 4 appeared. - Point 1: Is the set of arguments presented for major operational choices (e.g. single versus ksk-zsk split, and key effectivity period) complete and are the arguments fairly represented? Addressing all these arguments and considerations has created a fairly long document. In fact the choice has been to make the document comprehensive in presenting the considerations while not giving strong recommendations one way or another. This causes the document to be rather long and raises the question of the target audience. Also see: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/KSK-ZSK-Split - Point 2: Should this document try to give strong recommendations or should a separate document (set) be made that gives recommendations for certain operational environments (e.g. BCP for root, BCP for TLD, BCP for enterprise)? I am looking for specific guidance but as a straw man for consensus: This document should not give strong recommendations but provide comprehensive arguments (like it does now); development of recommendations is left for later, either in a follow up (RFC4641bis-bis) or as a set of separate documents) -Point 3: There have also been some questions about what audience the document is trying to address. The document is targeted to the 'the authoritative side of the DNS equation'. Is that indeed what the WG wants? If so is that clear enough from the document. (Please send concrete suggestions to improve if not). If there is consensus that the document talks to the authoritative side then the chairs may want to ask the question as to whether there a need for separate guidance for resolver operators, and maybe even ask for volunteers ;-) The following points are more detailed. -Point 4: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration Version 3 of the document has tried to address these issues (pending a conclusion of point 3 above) but in order to close this issue I would like to know whether the document [is] in any way restrictive on not using 5011, or is its consideration for advising RFC5011 to strong? Silence on this point will be taken as finding the right balance. -Point 5: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Signature_validity Text added in 4.4.2, is this text satisfactory http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-03#section-4.4.2 The paragraph talks about a Maximum signature validity and Minimum validity period in fairly broad terms. It also provides motivations for differentiating Signature Validity periods for different RRsets in a zone, those motivations are few and week. Again, is this section complete in providing arguments and are the arguments fair? If not, what are concrete recommendations for improvement. - Point 6 Is Appendix B useful? Or drop it? - Point 7 Any objections on closing the following: - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency (take a look at 3.1.1. Motivations for the KSK and ZSK Separation, the last paragraphs) - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent During the authoring of versions 2 and 3 of the document the first issues have been addressed. The differentiation between trustanchor-parent situation has been taken into account but not as drastically as Paul suggested. I believe this issue can be closed after review of version 3 of the document. - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/discussion_of_timescales - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/non-cooperative-registrars -
Re: [DNSOP] RFC4641bis Editing Status Report.
FWIW, This has been addressed in draft-03 although I just noticed that the last paragraph of 3.1.4.1. still needs a minor rewrite to reflect availability of SHA 256. (Now there is an inconstancy between giving references to the specs and saying one has to wait for availability). On Mar 20, 2010, at 8:34 PM, Paul Wouters wrote: On Sat, 20 Mar 2010, Olaf Kolkman wrote: - 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 Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC4641bis - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration
On Jul 8, 2010, at 7:53 PM, bmann...@vacation.karoshi.com wrote: On Thu, Jul 08, 2010 at 11:39:33AM +0200, Olaf Kolkman wrote: I observe though that 4641 is mainly written from the perspective of a 'zone-owner' and that I am not quite sure where to give specific advice to administrators of recursive nameservers. So before text is drafted there is an explicit question to the WG on whether this document should contain a section that gives guidance to recursive nameserver operators? is there also a distinction between a zone owner and its authoritative nameservers? If the document is primarly oriented toward a zone owner then references to nameserver administrators should be; a) kept to a minimum, and b) clearly stated at the head of the docuement, the focus of the advice, e.g. to zone owners. Sorry, your answer makes me realize there is a different way of asking the question, allow me to rephrase: Currently, and I do not think that has been a conscious choice, the document's center of gravity on the operational considerations at the authoritative side of the equation. It talks only very little about the validating side of the operational equation. Should it? 2. There are also multiple ways in which the auth nameserver operators will manage key rollover. Authoritative operators should free to decide if they want to manage their keys in a RFC5011 manner or not. RFC4641bis should place no restriction on authoritative servers. Hmmm. Currently the document does not restrict auth servers but it does give recommendations such as (in version 02 in the 1 but last paragraph of 3.1.2: It is therefore recommended to regularly roll KSKs if and only if those rollovers can be tracked using automated RFC5011 type mechanisms. Note the way this is phrased doesn't even say that 5011 is the magic bullet. Question to the WG: is the document in any way restrictive on not using 5011, or is its consideration for advising RFC5011 to strong? there have been some arguements about the periodicity of key rolls. Unless this document can have a clearly defenseable position for recommending regular rollovers and having such tied to RFC 5011, it might be wise to decouple this work from RFC 5011... unless this work really depends on RFC 5011 use. The document is currently a bit inconsistent in its recommendations on 'regular' rollover. I am in the process of trying to clean those inconsistencies for version 3 of the doc in the spirit of what I understand to be the WGs position. I paraphrase that as giving the various arguments and tradeoffs. In that context I believe that section 3.2.2.1 and 3.2.2.2 in version 2 of the document are very close. In the context of RFC5011 the current recommendation is: That if a KSK is (expected to be) a trust anchor than you should only regularly roll it if you use a standardized mechanism that allows the validator to track. The actual wording refers to 5011, see second to last paragraph in 3.1.2.2 since RFC5011 is the only standards track mechanism to allow validators to track the key. I believe the following text to be a little clearer in intend: It is therefore recommended to roll KSKs (that are likely to be used as trust-anchors) if and only if those rollovers can be tracked using standardized (e.g. RFC5011) mechanisms. (3. With RFC5011 we now have some confusion in the current RFCs about the status of the SEP bit. RFC4034 describes the SEP bit as follows Bit 15 of the Flags field is the Secure Entry Point flag, described in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a key intended for use as a secure entry point. This flag is only intended to be a hint to zone signing or debugging software as to the intended use of this DNSKEY record; validators MUST NOT alter their behaviour during the signature validation process in any way based on the setting of this bit. RFC4041 RFC4041 recommends In this document, we assume a one-to-one mapping between KSK and SEP keys and we assume the SEP flag to be set on all KSKs This clearly alters RFC 4034 and gives some meaning to the SEP bit. s/4041/4641/ My understanding about the SEP bit is reflected in the RFC 4034 text. In 4061, the authors have exceeded the definition in 4034 and based their work on that assumption... which doesn't appear to be valid :) I try to figure out if there is anything actionable, beyond smiling too ... :-) RFC5011 RFC5011 describes a method for securely managing key rollover via the use of the SEP bit and the addition of a revoke bit. This clearly redefines the original meaning of the SEP bit in RFC4034. Could 4641bis or something mention 1. RFC3757 is not obsolete 2. RFC3757 is updated by RFC5011 RFC 5011 describes A method, not THE ONLY method. One
Re: [DNSOP] That key size argument...was Re: The case for single active key
On Jun 24, 2010, at 11:59 AM, George Barwood wrote: It could also note that validators SHOULD NOT check the RRSIG for a DNSKEY RRset where all the keys are validated by DS records. This document (4641-bis) is supposed to give operational guidance only. Implementation guidance for validators should (IMHO) go to another document. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC4641bis - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration
On Jun 16, 2010, at 5:25 PM, John Dickinson wrote: Hi, Sorry for the very late reply to this issue. http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration Paul asked for proper use of 5011 to be added to 4641bis. I agree, In fact could we go further and give implementation advice? These are some thoughts on the subject, I know they cross into dnsext space but I think 4641bis might want to mention some of them. 1. One thing missing in RFC5011 is a mechanism to signal validator operators that RFC5011 key management is being performed. 2. There currently exist several ways in which validator operators can configure and manage their DNSSEC TAs. These mechanisms are different in each validator, according to the design of the implementors. The current situation is that all known validators configure their trust anchors differently according to whether or not they are 5011 TA's or non-5011 TA's. There is no good reason for this. In addition, since RFC5011 provides no signalling there may be no way for validator operators to know where to configure the TA key. 4641bis could suggest to implementors that all TA's be configured in an identical manner in any given implementation. Note: 4641bis should say nothing about how the implementation should do this, just that all TA keys be treated equally in the configuration. If the validator ever sees a revoke bit set on a key in a self signed RRSet it MUST stop trusting it, as described in RFC5011. If the validator never sees a revoked bit then as long as the authoritative operator is making the validator operator aware of key changes in some other way there will be no issues. This should help ensure that keys are configured correctly. I agree with this. I observe though that 4641 is mainly written from the perspective of a 'zone-owner' and that I am not quite sure where to give specific advice to administrators of recursive nameservers. So before text is drafted there is an explicit question to the WG on whether this document should contain a section that gives guidance to recursive nameserver operators? 2. There are also multiple ways in which the auth nameserver operators will manage key rollover. Authoritative operators should free to decide if they want to manage their keys in a RFC5011 manner or not. RFC4641bis should place no restriction on authoritative servers. Hmmm. Currently the document does not restrict auth servers but it does give recommendations such as (in version 02 in the 1 but last paragraph of 3.1.2: It is therefore recommended to regularly roll KSKs if and only if those rollovers can be tracked using automated RFC5011 type mechanisms. Note the way this is phrased doesn't even say that 5011 is the magic bullet. Question to the WG: is the document in any way restrictive on not using 5011, or is its consideration for advising RFC5011 to strong? (3. With RFC5011 we now have some confusion in the current RFCs about the status of the SEP bit. RFC4034 describes the SEP bit as follows Bit 15 of the Flags field is the Secure Entry Point flag, described in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a key intended for use as a secure entry point. This flag is only intended to be a hint to zone signing or debugging software as to the intended use of this DNSKEY record; validators MUST NOT alter their behaviour during the signature validation process in any way based on the setting of this bit. RFC4041 RFC4041 recommends In this document, we assume a one-to-one mapping between KSK and SEP keys and we assume the SEP flag to be set on all KSKs This clearly alters RFC 4034 and gives some meaning to the SEP bit. s/4041/4641/ RFC5011 RFC5011 describes a method for securely managing key rollover via the use of the SEP bit and the addition of a revoke bit. This clearly redefines the original meaning of the SEP bit in RFC4034. Could 4641bis or something mention 1. RFC3757 is not obsolete 2. RFC3757 is updated by RFC5011 I do not think that this (non standards track document) should tinker with the status of any standards track document. Besides I believe that what is in 4034 says: SEP is not interpreted during the validation but can be used as a hint for operational matters (and then mentions debugging and zonesigning). The SEP bit is described in [RFC3757] and updated in RFC5011. However, it plays no part in the validation process. It may only be used in the automated key rollover process as described in RFC5011.) While chewing on section 3.1 yesterday and today it seemed that having a separate section on the use of SEP is appropriate. On this work is in progress. (I updated http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration) --Olaf Olaf M. Kolkman
Re: [DNSOP] RFC4641bis Editing Status Report.
You probably noticed I swapped in the document and tackling issues one-by-one. On Mar 20, 2010, at 8:51 PM, Chris Thompson wrote: On Mar 20 2010, Paul Wouters wrote: On Sat, 20 Mar 2010, Olaf Kolkman wrote: - 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. 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.) Rereading this particular issue it seems that the current text in version 02 ( http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-02#section-5.3.1 ) is convoluting DNS signing algorithms with the NSEC3 digest-algorithm field. I am not quite sure what this section tries to accomplish except for the fact that NSEC3 support is signaled in the algorithm numbers, which I don't think is in scope at this particular place (section 5.3) in the document. I think that talking about NSEC3 hash algorithm rolover is in scope (in section 5.3) and modified the text to read: t At the moment of writing there is only one NSEC3 Hashing algorithm defined. xref target=RFC5155/ specifically calls out that when a new hash algorithm for use with NSEC3 is specified, a transition mechanism MUST also be defined. Therefore this document does not considder NSEC3 hash algorithm transition. /t --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Late comments on rfc4641bis
On Mar 24, 2010, at 11:19 PM, Patrik Fältström wrote: General comment: The document is not clear enough regarding the roles of the registrant, dns operator, registrar and registry -- where the dns operator is in the document implied to be the one that hold the private keys. Further, the same organsiation might have one or more of these roles. ACK. 4.4.1. OLD: The initial key exchange is always subject to the policies set by the parent. NEW: The initial key exchange is always subject to the policies set by the parent. This is specifically important in a registry-registrar model where the key material is to be passed from the DNS operator, via a registrar to the (parent) registry, where both DNS operator and registrar is selected by the registrant and they might be different organisations. ACK. 4.4.2. OLD: In the registry-registrar model, one can use the DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [14], which allows transfer of DS RRs and optionally DNSKEY RRs. NEW: In the registry-registrar model, one can between registry and registrar use the DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [14], which allows transfer of DS RRs and optionally DNSKEY RRs. There is no standardized way for moving the data between DNS operator and registrar although the DNSSEC extensions to epp can be used there as well. Different registrars have different mechanisms, where a simple web interface is what is used in most cases, and various APIs are used in other cases. This didn't quite parse I've rewritten: t The storage considerations also relate to the design of the customer interface and the method by which data is transferred between registrant and registry; Will the child zone administrator be able to upload DS RRs with unknown hash algorithms or does the interface only allow DNSKEYs? When Registries support the Extensible Provisioning Protocol (EPP) xref target=RFC4310/ then that can be used for registrar-registry interactions since that protocol allows the transfer of DS and optionally DNSKEY RRs. For moving data between DNS operator and registrar there is no standardized way for moving the data. Different registrars have different mechanisms, ranging from simple web interfaces to various APIs. In some cases the use of the DNSSEC extentions to EPP may be aplicable to. /t 4.4.5.2. OLD: However, there is no operational methodology to work around this business issue and proper contractual relations ships between registrants and their registrars seem to be the only solution to cope with these problems. NEW: However, there is no operational methodology to work around this business issue, and proper contractual relationships between all involved parties seems to be the only solution to cope with these problems. It should though be noted that the problem with temporary broken delegations in many cases already exists when DNS operator is changed for a zone, as that often implies also move of services that the DNS reference. So if not DNS is down for a while does in reality not have so much impact as services referenced by the DNS also will be down in the same service window. To minimise such problems, the only recommendation is to have relative short TTL on all involved resource records, and that will solve many of the problems regarding changes to a zone. Not only the time when DNS operator is changed and DNSSEC is in use. I agree with the changes (specifically the change of contracts between registrants and registrars to 'all parties') although I've rewritten the paragraphs a bit for clarity (I hope): t However, there is no operational methodology to work around this business issue, and proper contractual relationships between all involved parties seems to be the only solution to cope with these problems. It should be noted that in many cases, the problem with temporary broken delegations already exists when a zone changes from one DNS operator to another. Besides, it is often the case that when the DNS moves from one operator to another the services that that zone references also change operator, possibly involving some downtime. /t t In any case. To minimise such problems, the classic recommendation is to have relative short TTL on all involved resource records. That will solve many of the problems regarding changes to a zone regardless of whether DNSSEC is used. /t --Olaf
Re: [DNSOP] RFC4641-bis: The case for single active key
On Jun 17, 2010, at 11:15 PM, Olafur Gudmundsson wrote: Currently section 3 of the document mandates that all zones be signed using the KSK+ZSK model, I content this is outdated advice. Version 02 of the draft offers the choice. And in fact it starts of by saying (in 3.1 second paragraph) that if you do not split KSK and ZSK functionality you should set the SEP flag on all keys in your keyset, thereby making the choice rather explicit up front. I agree the document tends to give more arguments for than against a splitting KSK and ZSK functionality and that the final sentence of 3.1.1 is rather explicit in its advice. But mandate? Anyhow... some comments below... Background #1: Why bring this up now While reviewing draft-ietf-dnsop-dnssec-dps-framework I found myself loving certain sections of the document and hating other sections. Before sending out a nasty review, I read the document over again and realized that the sections I hated were all derived from the recommendations in RFC4641, thus I'm starting few threads to talk about the major issues I have with this document. Background #2: History of KSK+ZSK split I have been working on DNSSEC for a long time and during that time I have changed my mind on what is good a few times. The split key KSK+ZSK idea is good in certain environments but not in all. The original DNSSEC specifications did not have this split. The split was introduced after people realized that there might be breaks in the trust chain, or parents might be hard to update. The split is introduced by the DS draft (May 2001) and SEP flag draft (Sept 2002). The point of the SEP flag was to be able to pick out which DNSKEY(s) is supposed be configured as a DS in parent or a Trust Anchor. RFC5011 trust anchor maintainer should use the SEP flag while tracking changes. I believe the SEP flag to be orthogonal to the choice of splitting the functionality. The SEP flag should be used to indicate that the key is intended as the Secure Entry Point into the zone. Section 3.1 of version 02 is rather explicit about this by saying that if you do not separate the functionality between KSK and ZSK you should always set the SEP flag. Lets treat KSK and ZSK separation independent of the SEP flag. Also, during editing I coiled the term Common Signing Key when the distinction between KSK and ZSK is not made. Background #3: Key strengths and life time RSA and DSA algorithms have the interesting property that the number of bits in the key can be selected, by adding bits to the key the key gets stronger. Stronger keys can be used longer. The idea for KSK's was that the KSK would sign the DNSKEY rrset, be stronger than the ZSK and would live longer than the ZSK === reducing the load on parent in changing keys. But not all key algorithms have this variable key length property, for example ECC-GOST has fixed length, thus the stronger KSK argument does not apply. Agreed. I modified the text in the document (see below) slightly to highlight that key-size differences are a weak argument for KSK-ZSK separation: Finally there is a risk of cryptanalysis of the key material. The cost of such analysis are correlated to the length of the key. However, cryptanalysis arguments provide no strong motivation for a KSK/ZSK split based on packet size considerations: If one differentiates between a KSK and a ZSK, requires that the resistance against crypto analysis is the same, and the amount of ZSKs rollovers during a KSK Effectivity (see xref target=key_lifetime/) period is in the order 10s to 100s than the differences key sizes of the KSK and ZSK roughly are small enough not to significantly affect signing times or DNS packet length.. Not sure if this parses, feedback would be appreciated. Background #4: Difficulty in updating parents From a child zone perspective a parent can have one of the following behaviors: - unsigned - signed but refusing accepting DS[1] - signed but slower in updating than the child desires[2] - signed and easy to update. [1] This can be either either parent policy or a deficiency by an intermediary such as the child's registrar. [2] This can apply when update takes a while to show up in DNS or when the parent has LARGE TTL on the DS record thus it takes a long time for the old DS set to expire from caches. In the first two cases having KSK+ZSK split may make sense. In the last case there is limited/no DNS operational need for split key operation. The third case is hopefully rare, and can be recommended out of existence. I think you are missing something here. A key may be configured as a trust-anchor. In which case a 3rd party interaction is needed. One that is even more difficult to control than the parental interaction. This is (IMHO) not academic: In enterprise environments it
[DNSOP] RFC4641bis Editing Status Report.
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. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 23, 2010, at 8:20 AM, Florian Weimer wrote: * Olaf Kolkman: 5.3.3. NSEC3 Salt The salt with NSEC3 is not used to increase the work required by an attacker attacking multiple domains, but as a method to enable creating a new set of hash values if at some point that might be required. The salt is used as a roll over. The FQDN RRlabel, which is part of the value that is hashed, already ensures that brute force work for one RRlabel can not be re-used to attack other RRlabel due to their uniquenes. Key rollovers limit the amount of time attackers can spend on attacking a certain key before it is retired. The salt serves the same purpose for the hashes, which are independant of the key being Kolkman GiebenExpires September 8, 2009 [Page 33] Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 used, and therefor do not change when rolling over a key. Changing the salt would cause an attacker to lose all precalculated work for that zone. The salt of all NSEC3 records in a zone needs to be the same. Since changing the salt requires the NSEC3 records to be regenerated, and thus requires generating new RRSIG's over these NSEC3 records, it is recommended to only change the salt when changing the Zone Signing Key, as that process in itself already requires all RRSIG's to be regenerated. However, unlike Zone Signing Key changes, NSEC3 salt changes do not need special rollover procedures. It is possible to change the salt each time the zone is updated. ACK (Assuming that this is true, which I think it is.) Perhaps the following is helpful as well? 5.3.5 Response size considerations NSEC3 records are larger than NSEC records because of the embedded hashes. However, NSEC records are sometimes returned in response to DO=0 queries, pushing the response over the 512 byte limit and causing TCP fallback (or worse). This does not happen with NSEC3 records because their owner name does not normally match the queried name. Therefore, NSEC3 records provide better insulation of child zones from the DNSSEC deployment in the parent zone. Isn't that only the case for QTYPE=ANY? Or when the server at the authoritative side is broken? For both cases I do not think that this is a strong consideration. Also, but orthogonal, At Labs we are about to measure the impact of the amount of NSEC3 iterations on a recursive nameserver. Maybe there are some additional considerations that flow from that, will keep you all posted. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
Alex, I have taken your recommendations and added them to the current text. Also the other discussion about enumarability of highly structured zones found a place. However, I did do some slight rephrasing. I don't think I changed the spirit of your suggestions. The text in my current draft can be found below. --Olaf --On 22 January 2010 12:04:07 +0100 Olaf Kolkman o...@nlnetlabs.nl wrote: Strawman text said: Though some claim all data in the DNS should be considered public, it sometimes is considered to be more then private, but less then public data. That does not describe the problem well, in that (1) it is not the data that is somewhere between public and private, it is that the mechanisms of access to that data that change, and (2) it completely ignores opt-out. How about Though all agree DNS data should be accessible through query mechanisms, a side effect of NSEC is that it allows the contents of a zone file to be enumerate in full by sequential query. Whilst for some operators this behaviour is acceptable or even desirable, for others it is undesirable for policy, regulatory or other reasons. This is the first reason for development of NSEC3. The second reason for the existence of NSEC3 is that NSEC requires a signature over every RR in the zonefile, thereby ensuring that any denial of existence is cryptographically signed. However, in a large zonefile containing many delegations very few of which are to signed zones, this may produce unacceptable additional overhead especially where insecure delegations are subject to frequent update (a typical example might be a TLD operator with few registrants using secure delegations). NSEC3 allows intervals between two such delegations to Opt-out in which case they may contain one more more insecure delegations, thus reducing the size and cryptographic complexity of the zone. 5.3.4 Opt-out An Opt-Out NSEC3 RR does not assert the existence or non-existence of the insecure delegations that it may cover. This allows for the addition or removal of these delegations without recalculating or re- signing RRs in 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. There are considerable operational advantages in Opt Out (zone size, cryptographic complexity etc.) for large zones only sparsely populated with secure delegations, particularly where few queries have DO set anyway. -- Alex Bligh [...] 5. Next Record type There are currently two types of next records that are provide authenticated denial of existence of DNS data in a zone. o The NSEC [4] record builds a linked list of sorted RRlabels with their record types in the zone. o The NSEC3 [24] record builds a similar linked list, but uses hashes instead of the RRLabels. 5.1. Reasons for the existence of NSEC and NSEC3 The NSEC record requires no cryptographic operations aside from validating its associated signature record. It is human readable and can be used in manual queries to determin correct operation. The disadvantage is that it allows for zone walking, where one can request all the entries of a zone by following the next RRlabel pointed to in each subsequent NSEC record. Kolkman GiebenExpires September 8, 2009 [Page 31] Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 Though all agree DNS data should be accessible through query mechanisms, a side effect of NSEC is that it allows the contents of a zone file to be enumerate in full by sequential query. Whilst for some operators this behaviour is acceptable or even desirable, for others it is undesirable for policy, regulatory or other reasons. This is the first reason for development of NSEC3. The second reason for the existence of NSEC3 is that NSEC requires a signature over every RR in the zonefile, thereby ensuring that any denial of existence is cryptographically signed. However, in a large zonefile containing many delegations very few of which are to signed zones, this may produce unacceptable additional overhead especially where insecure delegations are subject to frequent update (a typical example might be a TLD operator with few registrants using secure delegations). NSEC3 allows intervals between two such delegations to Opt-out in which
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 17, 2010, at 4:03 PM, Paul Wouters wrote: On Wed, 17 Feb 2010, Olaf Kolkman wrote: Though all agree DNS data should be accessible through query mechanisms, a side effect of NSEC is that it allows the contents of a zone file to be enumerate in full by sequential query. Whilst for Small typos: enumerated and sequential queries I am not sure about the should in that sentence either. How about is accessable through query mechanisms? That works for me. Also, during further editing I have changed the tone of the paragraph a bit: Instead of reasons for development I mention the differences and don't claim them to be motivations. There are probably many views on the history on how NSEC3 and OPT-OUT came about and I don;t want to waist time on arguing about those views on history. delegations). NSEC3 allows intervals between two such delegations to Opt-out in which case they may contain one more more insecure delegations, thus reducing the size and cryptographic complexity of the zone. at the expense of some deniability? I feel we need to make it clear here that there is a trade-of. Opt-out isn't all positive. It has a price. I turned that into: at the expense of the abillity to cryptographically deny the existence of names in a specific span. 5.2. NSEC or NSEC3 The first reason to deploy NSEC3, prevention of zone enumeration, makes sense when zone content is not highly structured or trivially only makes sense ? I think that is right. I cannot come up with occasions whereby those conditions hold and NSEC3 as a prevention for zone enumeration is still a smart thing to do. 5.3. NSEC3 parameters The NSEC3 hashing includes the FQDN in its uncompressed form. This over its uncompressed form? The hash does not 'include' it. I overlooked this when I copied the text from P.W. who originally supplied it :-) How about hashing algorithm is performed on the FQDN ... 5.3.1. NSEC3 Algorithm The NSEC3 algorithm is specified as a version of the DNSKEY algorithm. The current options are: Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm 3, DSA. Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5, RSASHA1. The algorithm choice therefor depends solely on the DNSKEY algorithm picked. The next record algorithm choice therefor. to make it less confusing? Ack 5.3.3. NSEC3 Salt The salt with NSEC3 is not used to increase the work required by an attacker attacking multiple domains, but as a method to enable creating a new set of hash values if at some point that might be required. The salt is used as a roll over. I would throw this around. pun No, you would not, at least you didn't the first time around the initial text was yours /pun (or am I seriously wrong and acknowledging the wrong person for this significant contribution?) Don't start saying what the salt is not for, but say what it is for. I like this suggestion! First: Key rollovers limit the amount of time attackers can spend on attacking a certain key before it is retired. The salt serves the same purpose for the hashes, which are independant of the key being used, and therefor do not change when rolling over a key. Changing the salt would cause an attacker to lose all precalculated work for that zone. I changed the implementation a bit, given the abundant amount of discussion about key rollovers (which I will try to turn into concrete text) I want to not make that parallel. And then: The FQDN RRlabel, which is part of the value that is hashed, already ensures that brute force work for one RRlabel can not be re-used to attack other RRlabel due to their uniquenes. The salt of all NSEC3 records in a zone needs to be the same. Since changing the salt requires the NSEC3 records to be regenerated, and thus requires generating new RRSIG's over these NSEC3 records, it is recommended to only change the salt when changing the Zone Signing Key, as that process in itself already requires all RRSIG's to be regenerated. I did some editing and rewriting. See the full dump below. Should there be any explanation about the NSEC3PARAM record here? Not sure yet, I take WG guidance. The Opt-Out mechanism was introduced to allow for a gradual introduction of signed records in zones that contain mostly delegation records. The use of the OPT-OUT flag changes the meaning of the NSEC3 span from authoritative denial of the existence of names within the span to a proof that DNSSEC is not available for the delegations within the span. [Editors Note: One could make this construct more correct by talking about the hashed names and the hashed span, but I believe that is overkill]. If you think of protecting typosquatting domain spoofs, it might be important to realise that the span is over hashes, and not over most domains that resemble your
[DNSOP] rfc4641bis: NSEC vs NSEC3.
On Jan 21, 2010, at 6:52 PM, Paul Wouters wrote: On Thu, 21 Jan 2010, Olaf Kolkman wrote: In trying to get a reasonable version 2 out of the door before Anaheim I am trying to identify and where possibly close open issues. As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has the open issues listed and a per issue highlight of their history. I still don't see any recommendations regarding NSEC vs NSEC3. I mailed you some comments about two IETF's ago I believe. Do you still have that email, or should I try to dig it out? That was oversight. In fact I need to close/re read the mail (and follow up thread) on your comments on the other topics. But for the benefit of opening discussion here is the relevant open issue (http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/NSEC-NSEC3) including your straw man text for the working group to comment on. --Olaf $Id: NSEC-NSEC3 36 2010-01-22 11:02:32Z olaf $ 20100122 NSEC-NSEC3 Paul Wouters Added: 22 jan 2010 Discussion missing about NSEC vs NSEC3 Parameters from: http://www.ietf.org/mail-archive/web/dnsop/current/msg07282.html Discussion: From: Paul Wouters p...@xelerance.com Subject:Comments/Additions on I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt Date: April 28, 2009 12:23:21 AM GMT+02:00 To: Olaf Kolkman o...@nlnetlabs.nl Cc: dnsop WG dnsop@ietf.org, namedropp...@ops.ietf.org WG namedropp...@ops.ietf.org I am furthermore missing a discussion on NSEC vs NSEC3 and NSEC3 parameters. I've tried to write something sensible that is included below, as a presumed section 5: 5 Next Record type There are currently two types of next records that are provide authenticated denial of existence of DNS data in a zone. - The NSEC (RFC 4034) record builds a linked list of sorted RRlabels with their record types in the zone. - The NSEC3 (RFC5 155) record builds a similar linked list, but uses hashes instead of the RRLabels. 5.1 Reasons for the existence of NSEC and NSEC3 The NSEC record requires no cryptographic operations aside from validating its associated signature record. It is human readable and can be used in manual queries to determin correct operation. The disadvantage is that it allows for zone walking, where one can request all the entries of a zone by following the next RRlabel pointed to in each subsequent NSEC record. Though some claim all data in the DNS should be considered public, it sometimes is considered to be more then private, but less then public data. The NSEC3 record uses a hashing method of the requested RRlabel. To increase the workload required to guess entries in the zone, the number of hashing interations can be specified in the NSEC3 record. Additionally, a salt can be specified that also modifies the hashes. Note that NSEC3 does not give full protection against information leakage from the zone. 5.2 NSEC or NSEC3 For small zones that only contain contain records in the APEX and a few common (guessable) RRlabels such as www or mail, NSEC3 provides no real additional security, and the use of NSEC is recommended to ease the work required by signers and validating resolvers. For large zones where there is an implication of not readilly available RRlabels, such as those where one has to sign an NDA before obtaining it, NSEC3 is recommended. 5.3 NSEC3 parameters The NSEC3 hashing includes the FQDN in its uncompressed form. This ensures brute force work done by an attacker for one (FQDN) RRlabel cannot be re-used for another (FQDN) RRlabel attack, as these entries are per definition unique. 5.3.1 NSEC3 Algorithm The NSEC3 algorithm is specified as a version of the DNSKEY algorithm. The current options are: Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm 3, DSA. Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5, RSASHA1. The algorithm choice therefor depends solely on the DNSKEY algorithm picked. [Note that there is an issue here as well as mentioned in Section 3.4 regarding RSASSA-PKCS1-v1_5 vs RSASSA-PSS as well as no algorithm choice for SHA-256] 5.3.2 NSEC3 Iterations RFC-5155 describes the useful limits of iterations compared to RSA key size. These are 150 iterations for 1024 bit keys, 500 iterations for 2048 bit keys and 2,500 iterations for 4096 bit keys. Choosing 2/3rd of the maximum is deemed to be a sufficiently costly yet not excessive value. 5.3.3 NSEC3 Salt The salt with NSEC3 is not used to increase the work required by an attacker attacking multiple domains, but as a method to enable creating a new set of hash values if at some point that might be required. The salt is used as a roll over. The FQDN RRlabel, which is part of the value that is hashed, already ensures that brute force work for one RRlabel can not be re-used to attack other RRlabel due to their uniquenes. Key rollovers limit the amount of time attackers can spend on attacking a certain key before
Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt
In trying to get a reasonable version 2 out of the door before Anaheim I am trying to identify and where possibly close open issues. As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has the open issues listed and a per issue highlight of their history. This thread, about the use of HSMs, is captured in http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs the content of that page is replicated below. I believe I captured the gist of the discussion in a modified version of paragraph 3.6 (see below). The first two paragraphs are not modified, the text starting with The ideal situation has been. I welcome editorial comments off-list. If the chair believes the current text captures consensus I will move this issue to the closed issues list. --Olaf $Id: cryptography_flawed 14 2009-02-09 18:54:12Z olaf $ 20100121 The use of HSMs Shane Kerr/Ed Lewis Added: 21 jan 2010 http://www.ietf.org/mail-archive/web/dnsop/current/msg07190.html and http://www.ietf.org/mail-archive/web/dnsop/current/msg07193.html The recommendation to use a HSM is far to strong. Arguments of fate sharing and operational overhead are being made on the list. Discussion: From: Shane Kerr sh...@ca.afilias.info Subject:Re: [DNSOP] I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt Date: April 21, 2009 1:03:58 PM GMT+02:00 Cc: dnsop WG dnsop@ietf.org I believe the key of the thread is captured in the following quotes: Stephane Bortzmeyer wrote: But the risk for the key is not only people modifying it, it is simply people *reading* it (a concern which also exists for the database but is much less important). I have no practical experience with HSMs but, in my mind, the interesting thing is that they guarantee noone will read the key without an authorization (that's quite unlike the database where you certainly prefer a few unauthorized looks to a complete loss). This is the key point IMHO. AIUI, the attack vector that HSM are designed to protect is that someone makes a copy of your key signing material without you knowing about it. Once they do that, they can spoof replies until such time as you roll your key. If an unauthorized person modifies the contents of the database backing your zone, you may or may not know about it, but an observant customer will at least notice that the data has changed. So the two are not totally equivalent. Having said that, I agree that HSM hysteria is a bit overblown, and that the actual DNSSEC signing is very, very unlikely to be the weakest link in DNS security in any organization. Resolution: Following the suggestion from: From: Peter Koch p...@denic.de Subject:Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt Date: April 27, 2009 1:19:45 PM GMT+02:00 To: IETF DNSOP WG dnsop@ietf.org I rewrote the text to highlight the economic tradeoff, the relevant part of section 3.6 is copied below. 3.6. Private Key Storage It is recommended that, where possible, zone private keys and the zone file master copy that is to be signed be kept and used in off- line, non-network-connected, physically secure machines only. Periodically, an application can be run to add authentication to a zone by adding RRSIG and NSEC RRs. Then the augmented file can be transferred. When relying on dynamic update to manage a signed zone [11], be aware that at least one private key of the zone will have to reside on the master server. This key is only as secure as the amount of exposure the server receives to unknown clients and the security of the host. Although not mandatory, one could administer the DNS in the following way. The master that processes the dynamic updates is unavailable from generic hosts on the Internet, it is not listed in the NS RRSet, although its name appears in the SOA RRs MNAME field. The nameservers in the NS RRSet are able to receive zone updates through NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This approach is known as the hidden master setup. The ideal situation is to have a one-way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off-net and should not be updated based on an unsecured network mediated communication. The ideal situation may not be achievable because of economic tradeoffs between risks and costs. For instance, keeping a zone file off-line is not practical and will increase the costs of operating a DNS zone. So in practice the machines on which zone files are
[DNSOP] rfc4641bis: ZSK-roll-frequency
As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has the open issues listed and a per issue highlight of their history. This issue is captured in http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency current content of that page is replicated below. I welcome substantive discussion on-list while I'd be happy to receive editorial comments off-list If the chair believes the current text captures consensus I will move this issue to the closed issues list. --Olaf $Id: ZSK-roll-frequency 31 2009-10-07 08:19:53Z olaf $ 2008090101 ZSK-roll-frequency EKR/ Paul Hoffman Added: 7 Oct 2009 See: http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html Rfc4641 argues for frequent ZSK rollovers, the argument therein is based on operational arguments that are (implicitly) based on operator acces to private keys and/or the timeline in which changes in which the (zone) operator may need to be replaced. EKRs argument is based on cryptographic strength and argues another view. The current considerations need to be made more explicit. Resolution: Added the following paragraph to section 3.3: t The motivation for having the ZSK's effectivity period shorter than the KSK's effectivity period is rooted in the operational consideration that it is more likely that operators have more frequent read access to the ZSK than to the KSK. If ZSK's are maintained on cryptographic Hardware Security Modules (HSM) than the motivation to have different key effectivity periods is weakend. /t Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
On Jan 21, 2010, at 3:09 PM, Rose, Scott W. wrote: Perhaps the wording is a bit incorrect in that it an insider attack (the admin accessing the key) is not the biggest threat. The ZSK is accessed more often and if it isn't on an HSM (or similar), there could be a risk that it could be exposed by someone other than the responsible DNS admin. Of course the use of an HSM minimizes this risk. How about this as suggested text? t The motivation for having the ZSK's effectivity period shorter than the KSK's effectivity period is rooted in the operational consideration that the ZSK may be at more risk of exposure as the ZSK is often used more frequently (e.g. zone data updates, etc.). If ZSK's are maintained on cryptographic Hardware Security Modules (HSM) than the motivation to have different key effectivity periods is weakend. /t I understand EKR's remark (thanks) in addition to the improvement Scott suggested there is the argument that if a rollover remains a special event it is bound to go wrong, while if it is part of regular operational procedure the operators do not have to go through the learning curve. That argument works, but not in the case that EKR brought up, if _the_ operator gets sacked the rollover done by the new one is the first one that new operator does, she wouldn't have the benefit of operational routine. --Olaf [nothing below, only context] Scott On 1/21/10 8:34 AM, Eric Rescorla e...@rtfm.com wrote: I'm not really an active member of the WG, so I certainly wouldn't say that my position has much of an affect on consensus, but I'm unconvinced by the argument offered below. Sure, the ZSK is at greater risk because operators have access to it, but so what? If an operator actually steals the key (or, say, is fired), you change the key then. However, given that you allow the operator to sign stuff with the key as long as he's employed, I don't see how repeatedly changing it during that period offers much value at all. -Ekr On Thu, Jan 21, 2010 at 5:28 AM, Olaf Kolkman o...@nlnetlabs.nl wrote: As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has the open issues listed and a per issue highlight of their history. This issue is captured in http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency current content of that page is replicated below. I welcome substantive discussion on-list while I'd be happy to receive editorial comments off-list If the chair believes the current text captures consensus I will move this issue to the closed issues list. --Olaf $Id: ZSK-roll-frequency 31 2009-10-07 08:19:53Z olaf $ 2008090101 ZSK-roll-frequency EKR/ Paul Hoffman Added: 7 Oct 2009 See: http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html Rfc4641 argues for frequent ZSK rollovers, the argument therein is based on operational arguments that are (implicitly) based on operator acces to private keys and/or the timeline in which changes in which the (zone) operator may need to be replaced. EKRs argument is based on cryptographic strength and argues another view. The current considerations need to be made more explicit. Resolution: Added the following paragraph to section 3.3: t The motivation for having the ZSK's effectivity period shorter than the KSK's effectivity period is rooted in the operational consideration that it is more likely that operators have more frequent read access to the ZSK than to the KSK. If ZSK's are maintained on cryptographic Hardware Security Modules (HSM) than the motivation to have different key effectivity periods is weakend. /t Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop === Scott Rose NIST sco...@nist.gov ph: +1 301-975-8439 Google Voice: +1-571-249-3671 http://www.dnsops.gov/ === Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
On Jan 21, 2010, at 5:28 PM, Tony Finch wrote: On Thu, 21 Jan 2010, Olaf Kolkman wrote: I understand EKR's remark (thanks) in addition to the improvement Scott suggested there is the argument that if a rollover remains a special event it is bound to go wrong, while if it is part of regular operational procedure the operators do not have to go through the learning curve. That argument works, but not in the case that EKR brought up, if _the_ operator gets sacked the rollover done by the new one is the first one that new operator does, she wouldn't have the benefit of operational routine. Operational routines like this will be automated. That is what I would hope. But documents like this do suggest the defaults and EKRs arguments for 'ad-hoc' rolling or the other comments for regular rolling do impact the market that provides the automation. -- Olaf (Full disclosure: NLnet Labs is part of a group that develops this sort of software, opendnssec). Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] Why ZSK rollover is a Bad Idea (tm)
On Oct 7, 2009, at 2:44 PM, Eric Rescorla wrote: From this perspective we might roll a ZSK more frequently than a KSK because the ZSK needs to be stored on-line to facilitate re-signing when the zone changes. With the KSK we have the option of keeping it off-line, and arguably the risk of compromise is consequently lower. Regular testing of the machinery is still important, however. Again, this seems like an argument for the ZSK/KSK split, which I'm not really arguing against (I haven't developed an opinion). My argument is purely against generating a new ZSK every time you sign it with the KSK. I don't think that provides much security benefit and certainly does have plenty of room for error. Aha, I agree, FWIW there is no such requirement/suggestion in 4641 or 4641 bis. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] Why ZSK rollover is a Bad Idea (tm)
On Oct 7, 2009, at 9:23 AM, Olaf Kolkman wrote: hope I can address a few of the issues before Yokohama. s/Yokohama/Hiroshima/ Should I call my travel office? ;-) --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should draft-ietf-dnsop-rfc4641bis cover RFC 5011 practices?
On 16 mrt 2009, at 16:34, Paul Hoffman wrote: It feels like a lot of DNSSEC questions these days are being answered by that's covered if you use RFC 5011. If so, then maybe proper use of RFC 5011 (such as when to assume that a zone is *really* being signed, not just for practice) should be part of draft-ietf-dnsop-rfc4641bis. I think you have a point. I can imagine that such section would be about putting trust in a trust-anchor and the considerations that apply there. Shooting from the hip here are some considerations: - When to trust a trust anchor: * whenever the zone-owner declares that a key is ready to be used as trust-anchor and * whenever you, as validator administrator, are satisfied that the rollover procedure is documented clearly enough and you are confident you can track the rollovers - When not to trust a trust anchor: * when a key appears in a zone and there is no trusted out-of-band communication that such key is in production. - Cases where transitive trust may work: * when a trusted third party validates the key-zone binding, the production readiness, and tracks the keys. (ITAR) * when copying zone data from a parental zone to which you have a DNS trust relation. I can see rare cases why you would want to establish a trust- anchor in the middle of a chain of trust that is in place. But if you follow this route I'm not sure about if there is a fate sharing argument that renders this sort of configuration useless. Obvious missing points? I've added this as open issue: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration --Olaf PGP.sig Description: This is a digitally signed message part ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RFC4641bis road trip: first stop
Lectori Salutem, draft-ietf-dnsop-rfc4641bis-01 has just been posted. I realize that this is not according to the rule to not submit 01 drafts shortly after a version 00 has been submitted and would understand if it would therefore not be able to feature the agenda. While draft-ietf-dnsop-rfc4641bis-00 is RFC4641 backported to XML with the errata fixed and some nits corrected this version contains some substantive material currently this is only strawman text intended to get progress on the issues currently addressed; not all open issues are addressed yet. For those who are familiar with the RFC4641 material I suggest that you look at appendix D.2 of the document that gives a summary of the changes and use the diff tool to assess where chances have been made. In other words use http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-dnsop-rfc4641bis-00.txturl2=http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-01.txt or http://tinyurl.com/cm4qw2 I would like to ask careful review of the new recommendations in section 3, specifically the key size recommendations. As far as progressing this document I would like to close issues one by one and hope that after they are closed we can be strong enough not to revisit them. I will try to make an effort to high light certain arguments in the issue lists. Using SVN is a bit of an experiment. The issue list can be found at: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ Kind regards, --Olaf Kolkman PGP.sig Description: This is a digitally signed message part ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Dear Dean, [Removing Jorge from the CC-list, this reply is supposed to be technical in nature. Also removing the IESG since this appears to be a WG issue, they can go back to the archives if and when relevant] The answer to both the questions is yes. There is still no evidence for no, and _still_ no one has come forward with personal knowledge of any attacks: -Sullivan appears to have no personal knowledge of any attacks working at Afilias, and doesn't assert having personal knowledge. -Conrad says BCP38 hasn't worked (it has indeed worked--imagine if no one implemented BCP38), worked for Nomimum, and ICANN, and appears to have no personal knowledge of any attacks and does not assert personal knowledge. -Andrews works for ISC, the document author's employer. Appears to have no personal knowledge of any attacks, and doesn't assert having any. -Maton Sotomayer works for the Canada National Research Council, and also appears to have no direct knowledge of any attacks, and doesn't assert having any. -Darcy works for Chrysler, appears to oppose the document, I think. Not one single attack has been cited where the two measures cited were actually insufficient. I do not have first hand experience from being under attack but I have seen enough arguments that reflector attacks are not only hypothetically possible but they also happen in real life. Not only from private conversations but also from, for instance, http://staff.washington.edu/dittrich/misc/ddos/grc-syn.txt and http://www.isotf.org/news/DNS-Amplification-Attacks.pdf and references therein. The fact that folk do not have first hand experience in being attacked does not dismis them from making an informed trade-off. For example. Fortunately, nobody in my circle of friends or family has ever been in a serious car crash. But that does not dismiss me from telling my kids that they SHOULD wear their seat belts (actually in my household it is a MUST). An informed trade-off is what I made when reviewing the document. To recap: For some reason that promotors can't or won't explain, they want everyone take the extreme measure to close open recursors, even though this causes harm to many users through cache poisoning of recursors they can't control. Although I agree that universal BCP38 deployment would mitigate reflector type DDOS attacks and the Kaminsky style cache poison attacks. I also know that BCP38 is far from universally deployed. Because I think that BCP38 deployment is not yet sufficient I support draft-ietf-dnsop-reflectors-are-evil-06. The draft as is does explain in detail what the problem is with DDOS caused by reflection and argues that By default, nameservers SHOULD NOT offer recursive service to external networks.. That is an instruction to us (I am wearing my NLnet Labs Hat) as software developers who ship software to be very careful in what sort of settings I present to whoever installs our software. The document does not prevent an operator to change to a non-default setting and offer recursion to the world but allows them to make an informed decision. DNSSEC advocates sell DNSSEC as a solution to cache poisoning. So they are making a situation worse for their own benefit and profit. I have not seen your argument (maybe I've overlooked it) why DNSSEC advocates benefit from this draft being published. I think BCP38 has to do with it. For what its worth if your argument is (I am guessing): BCP38 would, if it were to be universally deployed, mitigate Kaminsky style attacks. If that is the argument I would actually agree. And even though DNSSEC protects against other types of attacks as well full deployment of BCP38 might change the cost/benefit ratio for the deployment of DNSSEC. Even as a DNSSEC advocate I might be starting to sing a different tune then, but not now. --Olaf Kolkman (NLnet Labs) PGP.sig Description: This is a digitally signed message part ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
