Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alfred, I have no further comments on part (A). I have also adopted the leftovers in part (B), with explanation in between lines. Best regards, Matthijs On 04/11/2012 10:08 PM, Alfred � wrote: Matthijs, again thanks for your quick and detailed response and action. A few selected follow-up remark can be found inline below. On 11 Apr 2012 15:48:26 +0200, Matthijs Mekking wrote: On 04/05/2012 12:48 AM, Alfred H�nes wrote: Here we go with part (B); if deemed necessary, please consider to provide feedback for the items below on the list. Again, all items that are adopted without feedback necessary have been omitted from this reply. And I additionally dropped those items where I'm satisfied with your response and do not see the need to add more thoughts. (B) Editorial flaws ... (B.3) Section 1.2 -- clarification With respect to item (B.1) above, I suggest to even better clarify the definition of Signature validity period in Section 1.2 (1st bullet): OLD: | o Signature validity period The period that a signature is valid. | It starts at the time specified in the signature inception field | of the RRSIG RR and ends at the time specified in the expiration | field of the RRSIG RR. NEW: | o Signature validity period The time interval during which a | signature is valid. It starts at the (absolute) time specified in | the signature inception field of the RRSIG RR and ends at the | (absolute) time specified in the expiration field of the RRSIG RR. I don't see why this should be changed. Do you prefer interval over period? Do you want the clarify that the times are absolute? This is a non-issue in my opinion. Well, the issue is that RFCs 4033 and 4034, after initially using the precise term, signature validity interval, have switched to use the misnomer signature validity period, and we are stuck with that unfortunate usage for consistency with RFCs 4033/4034. Period is used in Re-Sign Period Refresh Period in this draft in the proper sense of a period - a recurring, floating interval that relates to the reciprocal value, a frequency. Therefore I still believe that it is worth emphasizing here, early in the document, that period in signature validity period is different, actually being a fixed time interval that, once passed, will not recur. The suggested two additions of parenthetical absolute [time] seem to be a suitable way to do that with a very small textual footprint. Ok, with that explanation I at least understand why you suggested this change. Adopted. ... (B.6) Section 4.1.5, list items below Figure 5 -- clarifications (c) In subsequent list items, I suggest to clarify the text -- where becessary -- by making the distinction between old and newer data more explicit, and -- in two instances -- an indication of the possibility of more than one DNSKEY RR (as in the Figure, due to the split KSK/ZSK scheme used) should be indicated by talking about the DNSKEY RRset: | new DNSKEY: After the cache data has expired, the new key can be added to the zone. --- v | new DNSKEY: After the old cache data has expired, the new key can be added to the zone. What is an old cache? I suggest After the old data has expired from cache here. The proposed text did say old cache data, not old cache. :-) But the wording you suggest is fine as well; I just tried to a change with a smaller footprint. But it was ambiguous (at least to me), so I suggested the other wording. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhpABAAoJEA8yVCPsQCW5yVsH/jSUiaExz5hP7s5sscxXOIaz UmP2r3KLOWnG6f46I3inkRSv2LcDfLnI0OFkWnjhoy2bR0QbRfTeEMWRkFfJBSAc 2cOMoKgcF+ytRQl2PBkEUiRsnoe+9ExRQHD2HnnyrNHdYyj3Lt445x0XoDF4NnAw P2KZugLbxW15LHkfQ4ng/kwExw9bIVCAkk75zn2DtQx3YomSa7APdZreDhrTYrJL GRY53vEsdhxXo4wPJxp+PqSzVG5YlhCgEwMAjucWNOy74JKq1PS75B7KfKwpMAhj +EXNulnmf8zevkobrWA7J8f8SCrzVUbquqiytk6+/hRVxt3XVnVl1ccFSjT88o4= =uGVH -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marc, Coming back to your review items, I only think point 1 is not decided on yet. But I don't think this should stop progress. You can find my responses in between lines. Best regards, Matthijs On 04/03/2012 11:11 AM, Marc Lampo wrote: Hello again, About 1) If the document is for the authoritative side, why not simply state so. Instead of this confusing statement about relationship between authoritative and validating NS's ? I believe it does state so, without confusion: The first sentence says the document is aimed for people that are active at the authoritative side. The second sentence says that we consider no relationship with the people running the recursive side. You think the document can do without the latter sentence. I think it is a fair assumption. About 2) So it is two steps ? I made it three stages. ;) About 3) I forgot the word corresponding, my fault there. As such the text is not wrong, please don't misunderstand me. But the parent the only way, for a parent, to known/verify that DS information is correct, is by querying for the DNSKEY RRset and check if the corresponding ( ;-) DNSKEY is indeed present. If it is not, there is no way the parent can distinguish between a child zone administrator performing a double-DS rollover or making an error ... The text is not wrong, so we do not need action for 4641bis here. My point of view on this topic: As long as there is a valid DS with corresponding DNSKEY, adding another DS is no error. Maybe you are afraid what happens if the child zone operator removes the old DNSKEY and replaces it with the new (mismatched) one. Now you have encountered the error. But such things are not specific to Double-DS rollover, it can happen also without being in a rollover: I could remove my DNSKEYs from my zone, and it would go bogus. Same thing. My point is, as long as the zone is able to be validated, there is no error made (in terms of DNSSEC). About 4) I can agree with the present text. Ok. About 5) Me too, I think published signatures should never be expired. Consequently, every key rollover will make signatures disappear that are, as such, not expired yet. From that point of view it makes little difference if signature validity period is a couple of weeks or months or years. But if the zone administrator uses long validity time with the intention not to recalculate regularly, this implies that the ZSK cannot rollover either. (and this is practice - out there, right now ! There is one TLD that has signatures valid till the end of the current year, and never did any key rollover since it started with DNSSEC) To conclude : I can just agree with the present text. Ok. Kind regards, Marc Lampo EURid (for .eu) -Original Message- From: Matthijs Mekking [mailto:matth...@nlnetlabs.nl] Sent: 03 April 2012 10:36 AM To: Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt Hi, On 04/02/2012 04:35 PM, Marc Lampo wrote: Hello to the list, Nice piece of work ! Some remarks - nothing spectacular : 1) Last sentence in the first paragraph - Introduction (about : no direct relation between ... and validating caching name servers.) Isn't this sentence superfluous ? I fail to see where a possible relation would indeed change something to these guidelines. But by including the sentence about no relationship, one starts to wonder if something escapes me ... The document just tries to make it very clear that it is targeted to the authoritative side of the DNS equation. 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence states there are three steps. I think this is an error : There are three states, yes; but there are only two manipulations to perform. (to me it seems logical to interpret step as : operation to perform) Sure. More important is the fact that it is one step/stage shorter than Pre-publish ZSK rollover. 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3 Security Lameness (actually, 4.1.3 introduces another way of KSK rollover. In that respect the title of the section is confusing !) In 4.1.3 the text suggest to publish a DS record in the parent for which there is no DNSKEY record in the child zone. It suggests to publish a DS record for which there is no *corresponding* DNSKEY record in the child zone, next to an existing chain of trust between parent and child. That is different from no DNSKEY record in the child zone. In 4.3.3 the text suggest the parent could verify that the DNSKEY is actually published by the child. -- 4.3.3 could explicitly state that, if a parent performs this kind of checking, then the double DS method of 4.1.3 is not possible. There is already a forward reference in section 4.1.3 to 4.3.3. Furthermore : as registry (for .eu) we think that it is important to assist our registrars in
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt
Hello Matthijs, Regarding 1 - ... no relationship ... validating ... Suggestion (a phrase that does not hint at any possible relationship) : This document holds no information that applies to the configuration of validating recursive name servers (validators). Ok regarding 2 : three stages OK regarding 3 : consequences for validation by parents (as a matter of fact, we're going to check if we adapt our present validation ourselves) For 4 and 5 there was already an OK. Kind regards, Marc -Original Message- From: Matthijs Mekking [mailto:matth...@nlnetlabs.nl] Sent: 12 April 2012 10:53 AM To: Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marc, Coming back to your review items, I only think point 1 is not decided on yet. But I don't think this should stop progress. You can find my responses in between lines. Best regards, Matthijs On 04/03/2012 11:11 AM, Marc Lampo wrote: Hello again, About 1) If the document is for the authoritative side, why not simply state so. Instead of this confusing statement about relationship between authoritative and validating NS's ? I believe it does state so, without confusion: The first sentence says the document is aimed for people that are active at the authoritative side. The second sentence says that we consider no relationship with the people running the recursive side. You think the document can do without the latter sentence. I think it is a fair assumption. About 2) So it is two steps ? I made it three stages. ;) About 3) I forgot the word corresponding, my fault there. As such the text is not wrong, please don't misunderstand me. But the parent the only way, for a parent, to known/verify that DS information is correct, is by querying for the DNSKEY RRset and check if the corresponding ( ;-) DNSKEY is indeed present. If it is not, there is no way the parent can distinguish between a child zone administrator performing a double-DS rollover or making an error ... The text is not wrong, so we do not need action for 4641bis here. My point of view on this topic: As long as there is a valid DS with corresponding DNSKEY, adding another DS is no error. Maybe you are afraid what happens if the child zone operator removes the old DNSKEY and replaces it with the new (mismatched) one. Now you have encountered the error. But such things are not specific to Double-DS rollover, it can happen also without being in a rollover: I could remove my DNSKEYs from my zone, and it would go bogus. Same thing. My point is, as long as the zone is able to be validated, there is no error made (in terms of DNSSEC). About 4) I can agree with the present text. Ok. About 5) Me too, I think published signatures should never be expired. Consequently, every key rollover will make signatures disappear that are, as such, not expired yet. From that point of view it makes little difference if signature validity period is a couple of weeks or months or years. But if the zone administrator uses long validity time with the intention not to recalculate regularly, this implies that the ZSK cannot rollover either. (and this is practice - out there, right now ! There is one TLD that has signatures valid till the end of the current year, and never did any key rollover since it started with DNSSEC) To conclude : I can just agree with the present text. Ok. Kind regards, Marc Lampo EURid (for .eu) -Original Message- From: Matthijs Mekking [mailto:matth...@nlnetlabs.nl] Sent: 03 April 2012 10:36 AM To: Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt Hi, On 04/02/2012 04:35 PM, Marc Lampo wrote: Hello to the list, Nice piece of work ! Some remarks - nothing spectacular : 1) Last sentence in the first paragraph - Introduction (about : no direct relation between ... and validating caching name servers.) Isn't this sentence superfluous ? I fail to see where a possible relation would indeed change something to these guidelines. But by including the sentence about no relationship, one starts to wonder if something escapes me ... The document just tries to make it very clear that it is targeted to the authoritative side of the DNS equation. 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence states there are three steps. I think this is an error : There are three states, yes; but there are only two manipulations to perform. (to me it seems logical to interpret step as : operation to perform) Sure. More important is the fact that it is one step/stage shorter than Pre-publish ZSK rollover. 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3 Security Lameness (actually, 4.1.3 introduces another way of KSK rollover. In that respect the title of the section is confusing !) In 4.1.3 the text
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/2012 12:48 PM, Marc Lampo wrote: Hello Matthijs, Regarding 1 - ... no relationship ... validating ... Suggestion (a phrase that does not hint at any possible relationship) : This document holds no information that applies to the configuration of validating recursive name servers (validators). Not only that, also the entities on the authoritative side don't have influence on the entities on the recursive side. Ok regarding 2 : three stages OK regarding 3 : consequences for validation by parents (as a matter of fact, we're going to check if we adapt our present validation ourselves) For 4 and 5 there was already an OK. Kind regards, Marc -Original Message- From: Matthijs Mekking [mailto:matth...@nlnetlabs.nl] Sent: 12 April 2012 10:53 AM To: Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt Hi Marc, Coming back to your review items, I only think point 1 is not decided on yet. But I don't think this should stop progress. You can find my responses in between lines. Best regards, Matthijs On 04/03/2012 11:11 AM, Marc Lampo wrote: Hello again, About 1) If the document is for the authoritative side, why not simply state so. Instead of this confusing statement about relationship between authoritative and validating NS's ? I believe it does state so, without confusion: The first sentence says the document is aimed for people that are active at the authoritative side. The second sentence says that we consider no relationship with the people running the recursive side. You think the document can do without the latter sentence. I think it is a fair assumption. About 2) So it is two steps ? I made it three stages. ;) About 3) I forgot the word corresponding, my fault there. As such the text is not wrong, please don't misunderstand me. But the parent the only way, for a parent, to known/verify that DS information is correct, is by querying for the DNSKEY RRset and check if the corresponding ( ;-) DNSKEY is indeed present. If it is not, there is no way the parent can distinguish between a child zone administrator performing a double-DS rollover or making an error ... The text is not wrong, so we do not need action for 4641bis here. My point of view on this topic: As long as there is a valid DS with corresponding DNSKEY, adding another DS is no error. Maybe you are afraid what happens if the child zone operator removes the old DNSKEY and replaces it with the new (mismatched) one. Now you have encountered the error. But such things are not specific to Double-DS rollover, it can happen also without being in a rollover: I could remove my DNSKEYs from my zone, and it would go bogus. Same thing. My point is, as long as the zone is able to be validated, there is no error made (in terms of DNSSEC). About 4) I can agree with the present text. Ok. About 5) Me too, I think published signatures should never be expired. Consequently, every key rollover will make signatures disappear that are, as such, not expired yet. From that point of view it makes little difference if signature validity period is a couple of weeks or months or years. But if the zone administrator uses long validity time with the intention not to recalculate regularly, this implies that the ZSK cannot rollover either. (and this is practice - out there, right now ! There is one TLD that has signatures valid till the end of the current year, and never did any key rollover since it started with DNSSEC) To conclude : I can just agree with the present text. Ok. Kind regards, Marc Lampo EURid (for .eu) -Original Message- From: Matthijs Mekking [mailto:matth...@nlnetlabs.nl] Sent: 03 April 2012 10:36 AM To: Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt Hi, On 04/02/2012 04:35 PM, Marc Lampo wrote: Hello to the list, Nice piece of work ! Some remarks - nothing spectacular : 1) Last sentence in the first paragraph - Introduction (about : no direct relation between ... and validating caching name servers.) Isn't this sentence superfluous ? I fail to see where a possible relation would indeed change something to these guidelines. But by including the sentence about no relationship, one starts to wonder if something escapes me ... The document just tries to make it very clear that it is targeted to the authoritative side of the DNS equation. 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence states there are three steps. I think this is an error : There are three states, yes; but there are only two manipulations to perform. (to me it seems logical to interpret step as : operation to perform) Sure. More important is the fact that it is one step/stage shorter than Pre-publish ZSK rollover. 3) 4.1.3
Re: [DNSOP] on Negative Trust Anchors
Hello, this is not a reply to any comment already made on this approach of negative trust anchors. (I just posted a reply with RFC4641bis in the subject, about this) It holds an alternative possibility to overcome the problem - for operators of validating name servers - of failing domains because of DNSSEC. The alternative is to have a parent regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information it finds published. If the parent detects security lameness (term used in RFC4641bis) its possible reaction could be to remove the DS information. The draft of Negative Trust Anchors does not mention anything about informing the operator of the failing domain. But since a parent domain operator should know who operates the child domains, they can also actively inform (eg. send email to registered contact person). That way, somebody can start working on correcting the root cause. The advantage over negative trust anchor would be that this is more centrally managed : the action by the parent (remove DS) is visible (TTL permitted) to any validating name server. (the negative trust anchor needs to be configured by every validating NS, whose administrators bother to do so) I acknowledge that negative trust anchor applies to however the chain-of-trust starts (from the root-zone, or from some DLV). But since the root is DNSSEC'd since close to 2 years, I expect the DLV approach is less important anyway. While my company, as registry for .eu, does not do this (yet ?), we do validate DNSSEC information when submitted, prior to publishing it as DS records (only if validation yields success). So, we already decide not to publish wrong information (at one point in time). The suggestion to regularly verify again extends that behaviour from not publishing if wrong (at submission time) to stop publishing if wrong (as part of normal operation) (the contract with registrars states that information provided by registrars must be correct. If not, the contract allows for some reactions (like blocking a domain in case of fake identities, but - by extension - to correctness of DNSSEC information) Marc Lampo Security Officer EURid (for .eu) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/2012 02:09 PM, Marc Lampo wrote: Hello all, (This also concerns the other discussion about Negative Trust Anchors, I'll post with that subject as well) -Original Message- From: Matthijs Mekking [mailto:matth...@nlnetlabs.nl] ... Not only that, also the entities on the authoritative side don't have influence on the entities on the recursive side. Actually, there is something that influences the recursive side ! (I'm referring to 4.3.3 Security lameness, where is state removing a DS RR) Sorry that I didn't make myself clear, perhaps influence was a bad word here. Of course the changes you make in your zone influences the recursive side. What I (and the document) try to make clear is that entities on the authoritative side do not have influence on *the operations* at the recursive side. Are there more people who think the text in the introduction is confusing? If so, please speak up and preferably suggest other wordings. Furthermore, we are shifting away from your review item (1), which was about the text in the introduction. You are now talking about security lameness. There are already considerations about that topic in 4641bis. Your suggestion is already there, see Section 4.3.3! Best regards, Matthijs Since this document is about DNSSEC Operational Practices, perhaps include a suggestion that parents regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information they find published. If the parent detects security lameness its possible reaction could be to remove the DS information. While my company, as registry for .eu, does not do this (yet ?), we do validate DNSSEC information when submitted, prior to publishing it as DS records (only if validation yields success). So, we already decide not to publish wrong information (at one point in time). The suggestion to regularly verify again extends that behaviour from not publishing if wrong (at submission time) to stop publishing if wrong (as part of normal operation) (the contract with registrars states that information provided by registrars must be correct. If not, the contract allows for some reactions (like blocking a domain in case of fake identities, but - by extension - to correctness of DNSSEC information) The advantage over negative trust anchor would be that this is more centrally managed : the action by the parent (remove DS) is visible (TTL permitted) to any validating name server. (the negative trust anchor needs to be configured by every validating NS, whose administrators bother to do so. And good point for Comcast who is obviously committed here !) I acknowledge that negative trust anchor applies to however the chain-of-trust starts (from the root-zone, or from some DLV). But since the root is DNSSEC'd since close to 2 years, I expect the DLV approach is less important anyway. Kind regards, Marc Lampo Security Officer EURid (for .eu) -Original Message- From: Matthijs Mekking [mailto:matth...@nlnetlabs.nl] Sent: 12 April 2012 01:04 PM To: Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt On 04/12/2012 12:48 PM, Marc Lampo wrote: Hello Matthijs, Regarding 1 - ... no relationship ... validating ... Suggestion (a phrase that does not hint at any possible relationship) : This document holds no information that applies to the configuration of validating recursive name servers (validators). Not only that, also the entities on the authoritative side don't have influence on the entities on the recursive side. Ok regarding 2 : three stages OK regarding 3 : consequences for validation by parents (as a matter of fact, we're going to check if we adapt our present validation ourselves) For 4 and 5 there was already an OK. Kind regards, Marc -Original Message- From: Matthijs Mekking [mailto:matth...@nlnetlabs.nl] Sent: 12 April 2012 10:53 AM To: Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt Hi Marc, Coming back to your review items, I only think point 1 is not decided on yet. But I don't think this should stop progress. You can find my responses in between lines. Best regards, Matthijs On 04/03/2012 11:11 AM, Marc Lampo wrote: Hello again, About 1) If the document is for the authoritative side, why not simply state so. Instead of this confusing statement about relationship between authoritative and validating NS's ? I believe it does state so, without confusion: The first sentence says the document is aimed for people that are active at the authoritative side. The second sentence says that we consider no relationship with the people running the recursive side. You think the document can do without the latter sentence. I think it is a fair assumption. About 2) So it is
Re: [DNSOP] on Negative Trust Anchors
Moin! On 12.04.2012, at 14:21, Marc Lampo wrote: It holds an alternative possibility to overcome the problem - for operators of validating name servers - of failing domains because of DNSSEC. The alternative is to have a parent regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information it finds published. If the parent detects security lameness (term used in RFC4641bis) its possible reaction could be to remove the DS information. It is something completely different and I certainly welcome TLDs doing that. But it's not an alternative it's an addition. Someone who wants to operate DNSSEC aware resolvers that validate today must have the ability to deploy negative trust anchors IMHO. The draft of Negative Trust Anchors does not mention anything about informing the operator of the failing domain. But since a parent domain operator should know who operates the child domains, they can also actively inform (eg. send email to registered contact person). That way, somebody can start working on correcting the root cause. Agreed, we should amend section 7 with steps to do when a negative trust anchor is discovered and that should be one of them. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400 Redwood City, California 94063 ralf.we...@nominum.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
Mark, On 12.04.2012, at 14:21, Marc Lampo wrote: It holds an alternative possibility to overcome the problem - for operators of validating name servers - of failing domains because of DNSSEC. The alternative is to have a parent regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information it finds published. If the parent detects security lameness (term used in RFC4641bis) its possible reaction could be to remove the DS information. = From my experience, active parenting is not a good practice. Specifically in this case, you are assuming that the parent knows the algorithms used for the DS record. He would have to in order to validate. That might not always hold true. Additionally, the record is not 'yours', it is just parked in your zone by the child. For the parent to Tamper with either the NS or DS is IMHO not a good practice. /S ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On Thu, Apr 12, 2012 at 08:27:21AM -0600, Stephan Lagerholm wrote: Specifically in this case, you are assuming that the parent knows the algorithms used for the DS record. He would have to in order to validate. That might not always hold true. Additionally, the record is not 'yours', it is just parked in your zone by the child. For the parent to Tamper with either the NS or DS is IMHO not a good practice. The DS is _not_ parked in the parent zone by the child. Unlike the NS record, the DS record is authoritative data at the parent, and never at the child. As I read the RFCs, the DS record is fully and completely parent-side data, and is the parent's assertion of its relationship to the child. I really think we have to get over the idea that the DS record is somehow the child's data that is merely represented in the parent side. That way of thinking about this is a good way, IMO, to get failed chains across the zone cut. IMO it is better to think of the DS/DNSKEY pair as a way of expressing accord across a zone cut, with each side contributing a portion of the effort and holding a portion of the responsibility. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New I-D on Negative Trust Anchors
Joe Abley joe.ab...@icann.org writes:
On 2012-04-11, at 12:09, Wes Hardaker wrote:
NTA example.com Thu Apr 12 09:06:42 PDT 2012
I realise this is just a thought experiment
Well, true it certainly is. And in fact the above thought experiment
wasn't meant to imply a resource record, but rather a config line. I
should have probably written it like this:
NTA {
example.com Thu Apr 12 09:06:42 PDT 2012;
};
Or something. In actuality, I'd expect every implementation to have a
different config file structure of couse.
--
Wes Hardaker
SPARTA, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Maximum negative trust anchor duration, was New I-D on Negative Trust Anchors
Paul Wouters p...@nohats.ca writes: On Wed, 11 Apr 2012, Shane Kerr wrote: Disabling DNSSEC validation for broken domains seems completely rational, at least for some types of brokenness. So someone will make a browser plugin to enable this. Let them. In our validation work within firefox we deliberately did *not* put in a continue anyway button. -- Wes Hardaker SPARTA, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
In message dd056a31a84cfc4ab501bd56d1e14bbbd2e...@exchange.secure64.com, Steph an Lagerholm writes: Mark, On 12.04.2012, at 14:21, Marc Lampo wrote: It holds an alternative possibility to overcome the problem - for operators of validating name servers - of failing domains because of DNSSEC. The alternative is to have a parent regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information it finds published. If the parent detects security lameness (term used in RFC4641bis) its possible reaction could be to remove the DS information. = From my experience, active parenting is not a good practice. Specifically in this case, you are assuming that the parent knows the algorithms used for the DS record. He would have to in order to validate. That might not always hold true. Additionally, the record is not 'yours', it is just parked in your zone by the child. For the parent to Tamper with either the NS or DS is IMHO not a good practice. There is a difference between Tamper and Hey, you stuffed up. You need to fix the delegation or we will remove it as it is causing operational problems and yes there *are* RFCs that permit this to happen. Parents are already REQUIRED to make these sorts of checks of the records involved in the delegation according to RFC 1034. As for not knowing the DS algorithm what is just garbage. For DS records to be useful the algorithms need to be well known. There are no private DS algorithms. Mark /S ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
Mark Andrews Thursday, April 12, 2012 6:10 PM: On 12.04.2012, at 14:21, Marc Lampo wrote: It holds an alternative possibility to overcome the problem - for operators of validating name servers - of failing domains because of DNSSEC. The alternative is to have a parent regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information it finds published. If the parent detects security lameness (term used in RFC4641bis) its possible reaction could be to remove the DS information. = From my experience, active parenting is not a good practice. Specifically in this case, you are assuming that the parent knows the algorithms used for the DS record. He would have to in order to validate. That might not always hold true. Additionally, the record is not 'yours', it is just parked in your zone by the child. For the parent to Tamper with either the NS or DS is IMHO not a good practice. There is a difference between Tamper and Hey, you stuffed up. You need to fix the delegation or we will remove it as it is causing operational problems and yes there *are* RFCs that permit this to happen. Being Insecure is not necessary better than being Bogus. Hey you got hacked, so we will remove the DS so that people can get to that bogus site Parents are already REQUIRED to make these sorts of checks of the records involved in the delegation according to RFC 1034. If you do an algorithm rollover, then you will have two DS at the parent but only one will correspond to a DNSKEY at the zone. As for not knowing the DS algorithm what is just garbage. For DS records to be useful the algorithms need to be well known. There are no private DS algorithms. That is not how I read RFC 4034, section 5.1.2 and appendix A.1. What am I missing? The algorithm number used by the DS RR is identical to the algorithm number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm number types. 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY 252 Indirect [INDIRECT] n - 253 Private [PRIVATEDNS] y see below OPTIONAL 254 Private [PRIVATEOID] y see below OPTIONAL 255 reserved /S ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
In message dd056a31a84cfc4ab501bd56d1e14bbbd2e...@exchange.secure64.com, Steph an Lagerholm writes: Mark Andrews Thursday, April 12, 2012 6:10 PM: On 12.04.2012, at 14:21, Marc Lampo wrote: It holds an alternative possibility to overcome the problem - for operators of validating name servers - of failing domains because of DNSSEC. The alternative is to have a parent regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information it finds published. If the parent detects security lameness (term used in RFC4641bis) its possible reaction could be to remove the DS information. =3D From my experience, active parenting is not a good practice. Specifically in this case, you are assuming that the parent knows the algorithms used for the DS record. He would have to in order to validate. That might not always hold true. Additionally, the record is not 'yours', it is just parked in your zone by the child. For the parent to Tamper with either the NS or DS is IMHO not a good practice. =20 There is a difference between Tamper and Hey, you stuffed up. You need to fix the delegation or we will remove it as it is causing operational problems and yes there *are* RFCs that permit this to happen. Being Insecure is not necessary better than being Bogus. Hey you got hacked, so we will remove the DS so that people can get to that bogus site I said remove the delegation. Get their attention as doing anything else doesn't work. Parents are already REQUIRED to make these sorts of checks of the records involved in the delegation according to RFC 1034. If you do an algorithm rollover, then you will have two DS at the parent but only one will correspond to a DNSKEY at the zone. Garbage. You don't add DS records until there are DNSKEYs for the algorithm and you remove all DS records for the old algorithm *before* you remove the DNSKEY for the old algorithm. If you fail to do this you will introduce validation failures. You can have DS records that don't correspond to a DNSKEY but the algorithm MUST match one that does correspond to a DNSKEY. This lets you publish a single KSK DNSKEY per algorithm. As for not knowing the DS algorithm what is just garbage. For DS records to be useful the algorithms need to be well known. There are no private DS algorithms. That is not how I read RFC 4034, section 5.1.2 and appendix A.1.=20 What am I missing? The algorithm number used by the DS RR is identical to the algorithm number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the=20 algorithm number types. 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY 252 Indirect [INDIRECT] n - 253 Private [PRIVATEDNS] y see below OPTIONAL 254 Private [PRIVATEOID] y see below OPTIONAL 255 reserved DS records have a DNSSEC algorithm which matches the DNSKEY and a DS hash algorithm. You can compute a DS record without knowing the DNSSEC algorithm. You can match DS records to DNSKEY records without knowing the DNSSEC algorithm. You do need to know the DS hash algorithm and there are no private DS hash algorithms. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-gersch-dnsop-revdns-cidr-01: Alternative Encoding for Names at Octet Boundaries
I think this is a good draft. I do have one comment, based on experimenting with both encoding a /16 in DNS zone files and the resulting lookups on those IP prefixes contained under it. As this document progresses I would very much like to advocate that the WG considers picking a single method for encoding the prefixes in zone files and, just as importantly, that the only method be the one outlined in Section 5.3: http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-01#section-5.3 Ultimately, I found it somewhat confusing to obey the encoding rules defined in Section 5.1 wrt octet/nibble-aligned vs. non-octet/nibble-aligned IP prefixes. As one real-world example, consider the case of a IPv4 /8, with a variety of octet vs. non-octet aligned prefixes allocated (for routing) and delegated (for DNS) to downstream customers. In that case, tools use to encode in the DNS zone files, as well as look them up (e.g.: dig), must not use m notation for prefixes at /8, /16 and /24 boundaries. However, for prefixes at non-octet aligned boundaries, (e.g.: /9, /18, /20, etc.), they do need to use m notation. I believe the problem will only get substantially worse when considering nibble vs. non-nibble boundaries for IPv6 prefixes being encoded. While the current draft has tried to do a good job prescribing the rules for encoding looking up prefixes on octet/nibble vs. non-octet/non-nibble boundaries in Section 5.1, I've found that it is substantially more simple using a single naming scheme in Section 5.3 for all prefix lengths. Thus, I would propose that the WG consider all IP prefixes be encoded as per what has been defined in Section 5.3. Ultimately, I think this should result in simpler tools used to encode the zones and, just as importantly, tools that will be developed to look-up RRsets in these zones. Lastly, FWIW, I agree with the practical operational considerations provided in paragraphs 2 - 4 of Section 5.3 as to why having the m sub-domain for holding the IP prefixes is a good thing, hence why I recommend that be the single approach. I would welcome others thoughts on the matter. -shane ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
