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. >> >>>
Re: [DNSOP] RFC4641bis - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration
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". > > 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. > > > > (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 :) > > > > 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 is or should be free to interpret the SEP as defined in RFC 4034. > > 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). Agreed. > > > 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. 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
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 __
