Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
All Thanks for all the feedback on this call for adoption. DNSOP will be adopting this document to work on thanks tim On Tue, May 12, 2020 at 1:19 AM Loganaden Velvindron wrote: > On Mon, May 4, 2020 at 11:10 PM Tim Wicinski wrote: > > > > > > > > All, > > > > As we stated in the meeting and in our chairs actions, we're going to run > > regular call for adoptions over next few months. > > We are looking for *explicit* support for adoption. > > > > > > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements > > > > The draft is available here: > https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ > > > I support adoption of the draft and i'm willing to review it. > > > > 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. > > > > Please also indicate if you are willing to contribute text, review, etc. > > > > This call for adoption ends: 18 May 2020 > > > > Thanks, > > tim wicinski > > DNSOP co-chair > > > > ___ > > 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] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
On Mon, May 4, 2020 at 11:10 PM Tim Wicinski wrote: > > > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements > > The draft is available here: > https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ > I support adoption of the draft and i'm willing to review it. > > 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. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 18 May 2020 > > Thanks, > tim wicinski > DNSOP co-chair > > ___ > 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] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
Hi Tim, Just to clarify, I fully agree there is a lot of similarities and we will work on it with Joe. Yours, Daniel On Thu, May 7, 2020 at 8:16 PM Tim Wicinski wrote: > > Daniel > > Thanks for taking Joe's draft under advice and I agree there is work to be > collaborated on. > > Tim > (speaking as a chair) > > On Thu, May 7, 2020 at 3:42 PM Joe Abley wrote: > >> Hi Daniel, >> >> On 7 May 2020, at 15:39, Daniel Migault wrote: >> >> > Thanks for putting the reference of that draft. I have always thought >> that the draft you were mentioning was the one that became RFC7958. >> >> 7958 came from draft-jabley-dnssec-trust-anchor, but the confusion is >> entirely reasonable! >> >> > The current draft mentions that TA should be associated with >> bootstrapping mechanism and that boostrapping for the root zone should be >> extended to other TA. >> >> Yep. >> >> > There are clearly some overlap between the two drafts and I also have >> the impression the drafts can be merged. >> > the following issue has been opened: >> > >> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/7 >> >> Happy to help with that if it's something that the authors/working group >> decide is useful. >> >> I support adoption of this draft, now that I've read it properly. >> >> >> Joe >> > -- Daniel Migault Ericsson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
Thanks Brian. That is really much appreciated! Yours, Daniel On Thu, May 7, 2020 at 1:56 PM Brian Dickson wrote: > > > On Mon, May 4, 2020 at 12:10 PM Tim Wicinski wrote: > >> >> >> All, >> >> As we stated in the meeting and in our chairs actions, we're going to run >> regular call for adoptions over next few months. >> We are looking for *explicit* support for adoption. >> >> >> This starts a Call for Adoption for >> draft-mglt-dnsop-dnssec-validator-requirements >> >> The draft is available here: >> https://datatracker.ietf..org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ >> <https://datatracker..ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/> >> >> >> 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 of this draft by DNSOP.. I am willing to review. > > Brian > > > >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 18 May 2020 >> >> Thanks, >> tim wicinski >> DNSOP co-chair >> >> ___ >> 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 > -- Daniel Migault Ericsson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
Moin! On 4 May 2020, at 21:08, Tim Wicinski wrote: This starts a Call for Adoption for draft-mglt-dnsop-dnssec-validator-requirements The draft is available here: https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ 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 adaption, will review and may contribute text. So long -Ralf —-- Ralf Weber ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
+1. Agree with Stephane and support adoption of this draft. Thanks Sanjay Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements Stephane Bortzmeyer Wed, 06 May 2020 08:48 UTCShow header<https://mailarchive.ietf.org/arch/browse/dnsop/> On Mon, May 04, 2020 at 03:08:20PM -0400, Tim Wicinski <mailto:tjw.i...@gmail.com;> wrote a message of 64 lines which said: > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements >I think it is important to have such a document, because DNSSEC failures may seriously endanger the deployment of DNSSEC (which is already too low). The current draft seems a good starting point and I support its adoption. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
Daniel Thanks for taking Joe's draft under advice and I agree there is work to be collaborated on. Tim (speaking as a chair) On Thu, May 7, 2020 at 3:42 PM Joe Abley wrote: > Hi Daniel, > > On 7 May 2020, at 15:39, Daniel Migault wrote: > > > Thanks for putting the reference of that draft. I have always thought > that the draft you were mentioning was the one that became RFC7958. > > 7958 came from draft-jabley-dnssec-trust-anchor, but the confusion is > entirely reasonable! > > > The current draft mentions that TA should be associated with > bootstrapping mechanism and that boostrapping for the root zone should be > extended to other TA. > > Yep. > > > There are clearly some overlap between the two drafts and I also have > the impression the drafts can be merged. > > the following issue has been opened: > > > https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/7 > > Happy to help with that if it's something that the authors/working group > decide is useful. > > I support adoption of this draft, now that I've read it properly. > > > Joe > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
Hi Daniel, On 7 May 2020, at 15:39, Daniel Migault wrote: > Thanks for putting the reference of that draft. I have always thought that > the draft you were mentioning was the one that became RFC7958. 7958 came from draft-jabley-dnssec-trust-anchor, but the confusion is entirely reasonable! > The current draft mentions that TA should be associated with bootstrapping > mechanism and that boostrapping for the root zone should be extended to other > TA. Yep. > There are clearly some overlap between the two drafts and I also have the > impression the drafts can be merged. > the following issue has been opened: > https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/7 Happy to help with that if it's something that the authors/working group decide is useful. I support adoption of this draft, now that I've read it properly. Joe signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
Hi Joe, Thanks for putting the reference of that draft. I have always thought that the draft you were mentioning was the one that became RFC7958. The current draft mentions that TA should be associated with bootstrapping mechanism and that boostrapping for the root zone should be extended to other TA. There are clearly some overlap between the two drafts and I also have the impression the drafts can be merged. the following issue has been opened: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/7 Yours, Daniel On Thu, May 7, 2020 at 2:17 PM Joe Abley wrote: > On 4 May 2020, at 15:08, Tim Wicinski wrote: > > > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements > > > > The draft is available here: > https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ > > > > > > 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. > > > > Please also indicate if you are willing to contribute text, review, etc. > > I have not looked at this draft far beyond the table of contents, but it > strikes me that this is very similar to an earlier draft that I recall > failing to persuade the working group to adopt: > > https://tools.ietf.org/html/draft-jabley-dnsop-validator-bootstrap-00 > > If there is new-found enthusiasm for documenting these kinds of things > then I am overjoyed. Perhaps there is an opportunity to merge that existing > work from 2011 with this effort. > > > Joe > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
On 4 May 2020, at 15:08, Tim Wicinski wrote: > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements > > The draft is available here: > https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ > > > 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. > > Please also indicate if you are willing to contribute text, review, etc. I have not looked at this draft far beyond the table of contents, but it strikes me that this is very similar to an earlier draft that I recall failing to persuade the working group to adopt: https://tools.ietf.org/html/draft-jabley-dnsop-validator-bootstrap-00 If there is new-found enthusiasm for documenting these kinds of things then I am overjoyed. Perhaps there is an opportunity to merge that existing work from 2011 with this effort. Joe signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
Thanks for the feed back Shumon, I agree that we should at least clarify where the responsibilities are so the mechanisms become more focused on smoothing the edges rather that compensating what the other party may not do. I also agree that fixed values might be more appropriated and the RDO should ensure time derivation will go beyond these values. Yours, Daniel On Thu, May 7, 2020 at 8:50 AM Shumon Huque wrote: > On Thu, May 7, 2020 at 8:34 AM Shumon Huque wrote: > >> On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer >> wrote: >> >> The draft apparently do not mention advices on expiration slack (such >>> as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a >>> consensus on (I quote Unbound documentation) "The signature inception >>> and expiration dates are allowed to be off by 10% of the signature >>> lifetime"? >>> >> >> RFC 6781 Section 4.4.2 (Signature Validity Periods) does mention having >> a reasonable signature inception offset, but recommends no value. It does >> not mention a signature expiration skew. It would be good to treat this >> subject in the document. Personally, I would prefer a fixed value (~ 5 to >> 10 minutes) rather than a percentage. Otherwise, the validator may be >> using >> a possibly unacceptably small or large skew values depending on the >> validity >> interval. >> > > Just to quickly follow-up on my own post (sorry!), I realize this draft is > only > about validator requirements, but RFC6781 describers signer > recommendations. > > Still, the skew issue has come up for me recently in signer implementations > too. One commercial DNSSEC implementation we were using was generating > on-the-fly signatures with _no_ inception offset - which means if the > validator's > clock was off even slightly, and supported no skew, it would fail. It > required > some vigorous arguing with this vendor to get them to use an inception > offset. > So, the skew issue ideally needs to be addressed on both sides (and it > might > be reasonable to mention that in this draft). > > Shumon. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
On Mon, May 4, 2020 at 12:10 PM Tim Wicinski wrote: > > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements > > The draft is available here: > https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ > <https://datatracker..ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/> > > > 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 of this draft by DNSOP. I am willing to review. Brian > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 18 May 2020 > > Thanks, > tim wicinski > DNSOP co-chair > > ___ > 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] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
On Thu, May 7, 2020 at 8:34 AM Shumon Huque wrote: > On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer > wrote: > >> On Mon, May 04, 2020 at 03:08:20PM -0400, >> Tim Wicinski wrote >> a message of 64 lines which said: >> >> > This starts a Call for Adoption for >> > draft-mglt-dnsop-dnssec-validator-requirements >> >> I think it is important to have such a document, because DNSSEC >> failures may seriously endanger the deployment of DNSSEC (which is >> already too low). The current draft seems a good starting point and I >> support its adoption. >> > > I also support adoption and will review/contribute etc. > > I'm willing to review. Let's start immediately with -09: >> >> draft-ietf-dnsop-extended-error (recently approved by the IESG) should >> be mentioned, since one of the biggest operational problem with DNSSEC >> is the difficulty to understand why a resolver returns a SERVFAIL to >> you. >> > > Yup. > > > More often, to date, failed validation is due to operator error and >> > not an attempt to forge data. >> >> It can be a bug in software, too. Specially with complicated things >> like NSEC3+optout+ENT+dynupdate :-{ >> > > Yes, unfortunately I concur. My experience recently deploying DNSSEC > for a large organization made it clear to me that even recent versions of > mature DNS implementations often have a variety of operationally > impacting DNSSEC bugs. > > The draft apparently do not mention advices on expiration slack (such >> as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a >> consensus on (I quote Unbound documentation) "The signature inception >> and expiration dates are allowed to be off by 10% of the signature >> lifetime"? >> > > RFC 6781 Section 4.4.2 (Signature Validity Periods) does mention having > a reasonable signature inception offset, but recommends no value. It does > not mention a signature expiration skew. It would be good to treat this > subject in the document. Personally, I would prefer a fixed value (~ 5 to > 10 minutes) rather than a percentage. Otherwise, the validator may be using > a possibly unacceptably small or large skew values depending on the > validity > interval. > I agree. The amount a clock is likely to be out of sync is not related to the signature lifetime in any way. A fixed value based on likely clock skew or operational experience would be better. (Just my opinion, not meaning to sound like an authority on the subject.) -- Bob Harold > > > However, a DNSSEC validator is not able to determine other than by >> > trying whether a signature scheme is supported by the authoritative >> > server. >> >> This one is unclear. First, the signer is not always an authoritative >> server, signature can be done offline. Second, querying the DNSKEY is >> enough, no? (Or querying the signatures, but I assume a zone won't >> publish a DNSKEY without being able to sign with this algorithm.) >> > > As the spec is currently written, yes, the DNSKEY RRset will give this > information. > > Shumon > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
On Thu, May 7, 2020 at 8:34 AM Shumon Huque wrote: > On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer > wrote: > > The draft apparently do not mention advices on expiration slack (such >> as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a >> consensus on (I quote Unbound documentation) "The signature inception >> and expiration dates are allowed to be off by 10% of the signature >> lifetime"? >> > > RFC 6781 Section 4.4.2 (Signature Validity Periods) does mention having > a reasonable signature inception offset, but recommends no value. It does > not mention a signature expiration skew. It would be good to treat this > subject in the document. Personally, I would prefer a fixed value (~ 5 to > 10 minutes) rather than a percentage. Otherwise, the validator may be using > a possibly unacceptably small or large skew values depending on the > validity > interval. > Just to quickly follow-up on my own post (sorry!), I realize this draft is only about validator requirements, but RFC6781 describers signer recommendations. Still, the skew issue has come up for me recently in signer implementations too. One commercial DNSSEC implementation we were using was generating on-the-fly signatures with _no_ inception offset - which means if the validator's clock was off even slightly, and supported no skew, it would fail. It required some vigorous arguing with this vendor to get them to use an inception offset. So, the skew issue ideally needs to be addressed on both sides (and it might be reasonable to mention that in this draft). Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer wrote: > On Mon, May 04, 2020 at 03:08:20PM -0400, > Tim Wicinski wrote > a message of 64 lines which said: > > > This starts a Call for Adoption for > > draft-mglt-dnsop-dnssec-validator-requirements > > I think it is important to have such a document, because DNSSEC > failures may seriously endanger the deployment of DNSSEC (which is > already too low). The current draft seems a good starting point and I > support its adoption. > I also support adoption and will review/contribute etc. I'm willing to review. Let's start immediately with -09: > > draft-ietf-dnsop-extended-error (recently approved by the IESG) should > be mentioned, since one of the biggest operational problem with DNSSEC > is the difficulty to understand why a resolver returns a SERVFAIL to > you. > Yup. > More often, to date, failed validation is due to operator error and > > not an attempt to forge data. > > It can be a bug in software, too. Specially with complicated things > like NSEC3+optout+ENT+dynupdate :-{ > Yes, unfortunately I concur. My experience recently deploying DNSSEC for a large organization made it clear to me that even recent versions of mature DNS implementations often have a variety of operationally impacting DNSSEC bugs. The draft apparently do not mention advices on expiration slack (such > as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a > consensus on (I quote Unbound documentation) "The signature inception > and expiration dates are allowed to be off by 10% of the signature > lifetime"? > RFC 6781 Section 4.4.2 (Signature Validity Periods) does mention having a reasonable signature inception offset, but recommends no value. It does not mention a signature expiration skew. It would be good to treat this subject in the document. Personally, I would prefer a fixed value (~ 5 to 10 minutes) rather than a percentage. Otherwise, the validator may be using a possibly unacceptably small or large skew values depending on the validity interval. > However, a DNSSEC validator is not able to determine other than by > > trying whether a signature scheme is supported by the authoritative > > server. > > This one is unclear. First, the signer is not always an authoritative > server, signature can be done offline. Second, querying the DNSKEY is > enough, no? (Or querying the signatures, but I assume a zone won't > publish a DNSKEY without being able to sign with this algorithm.) > As the spec is currently written, yes, the DNSKEY RRset will give this information. Shumon ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
Hi Stephane, Thanks you for the comments. Please see inline my responses. Yours, Daniel On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer wrote: > On Mon, May 04, 2020 at 03:08:20PM -0400, > Tim Wicinski wrote > a message of 64 lines which said: > > > This starts a Call for Adoption for > > draft-mglt-dnsop-dnssec-validator-requirements > > I think it is important to have such a document, because DNSSEC > failures may seriously endanger the deployment of DNSSEC (which is > already too low). The current draft seems a good starting point and I > support its adoption. > > I'm willing to review. Let's start immediately with -09: > > draft-ietf-dnsop-extended-error (recently approved by the IESG) should > be mentioned, since one of the biggest operational problem with DNSSEC > is the difficulty to understand why a resolver returns a SERVFAIL to > you. > > This is a good catch and the DNS client side is yet missing in the draft. Activation of EDE should be recommended. This provides the DNS client has a better understanding of the resolution, increases trust in the resolver. I have created an issue here and will come with additional text. https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/2 > More often, to date, failed validation is due to operator error and > > not an attempt to forge data. > > It can be a bug in software, too. Specially with complicated things > like NSEC3+optout+ENT+dynupdate :-{ > This is correct. I cannot say this case the "bug" is entirely clear to me, but at a high level the problem was due to a difference of interpretation between a signer and authoritative server. This resulted in data the resolver could not result in a proper validation. Even when fixed on the authoritative part, some resolver were not handling this properly. I believe that the experience associated to that bug could impact the document as follows: 1) the draft should mention that validation failure can also be due to software bugs. 2) we should have a recommendation for running different implementations and provide the ability to switch to one in case a bug is detected. 3) What is unclear to me is how EDE could have helped in this case. I opened the following issue: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/3 > The draft apparently do not mention advices on expiration slack (such > as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a > consensus on (I quote Unbound documentation) "The signature inception > and expiration dates are allowed to be off by 10% of the signature > lifetime"? > > Correct. This is not considered in the current document. I am happy to consider the consensus. The following issue has been opened: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/4 > > However, a DNSSEC validator is not able to determine other than by > > trying whether a signature scheme is supported by the authoritative > > server. > > This one is unclear. First, the signer is not always an authoritative > server, signature can be done offline. Second, querying the DNSKEY is > enough, no? (Or querying the signatures, but I assume a zone won't > publish a DNSKEY without being able to sign with this algorithm.) > > Correct. In this section I wanted to emphasize on providing a validator some means to ensure that it can safely deprecate an algorithm. While a resolver that supports a signature scheme can apply that signature to all received signed RRset. On the authoritative side, each zone needs to be requested. The problem associated to request this is mostly the knowledge of the zone. I think the section should: 1) clarify the text and mentioning how the signature schemes are discovered. 2) It is unclear if we should keep track of the requested domain, in order to be able to request the DNSKEYs 3) emphasize on a communication of supported algorithms between authoritative servers and resolvers. I have opened the following issue: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/5 Section 12 "Invalid Reporting Recommendations" is questionable. Since > most DNSSEC validation errors are not attacks, reporting these errors > may overload the DRO with problems she can do nothing > about. Monitoring is a good idea but monitoring what? "Important" (for > the DRO) domains? > > I agree that we could be a little be more specific. At minimum I envisioned logging the domains with the number of failures and reporting those with a threshold. I opened the following issue: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/6 > Also, the draft has many, it seems, grammar / language > problems. ("This introduces a potentially huge vector for &
Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
On Mon, May 04, 2020 at 03:08:20PM -0400, Tim Wicinski wrote a message of 64 lines which said: > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements I think it is important to have such a document, because DNSSEC failures may seriously endanger the deployment of DNSSEC (which is already too low). The current draft seems a good starting point and I support its adoption. I'm willing to review. Let's start immediately with -09: draft-ietf-dnsop-extended-error (recently approved by the IESG) should be mentioned, since one of the biggest operational problem with DNSSEC is the difficulty to understand why a resolver returns a SERVFAIL to you. > More often, to date, failed validation is due to operator error and > not an attempt to forge data. It can be a bug in software, too. Specially with complicated things like NSEC3+optout+ENT+dynupdate :-{ The draft apparently do not mention advices on expiration slack (such as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a consensus on (I quote Unbound documentation) "The signature inception and expiration dates are allowed to be off by 10% of the signature lifetime"? > However, a DNSSEC validator is not able to determine other than by > trying whether a signature scheme is supported by the authoritative > server. This one is unclear. First, the signer is not always an authoritative server, signature can be done offline. Second, querying the DNSKEY is enough, no? (Or querying the signatures, but I assume a zone won't publish a DNSKEY without being able to sign with this algorithm.) Section 12 "Invalid Reporting Recommendations" is questionable. Since most DNSSEC validation errors are not attacks, reporting these errors may overload the DRO with problems she can do nothing about. Monitoring is a good idea but monitoring what? "Important" (for the DRO) domains? Also, the draft has many, it seems, grammar / language problems. ("This introduces a potentially huge vector for configuration errors, but due to human intervention as well as potential misunderstanding of ongoing operations.") ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
All, As we stated in the meeting and in our chairs actions, we're going to run regular call for adoptions over next few months. We are looking for *explicit* support for adoption. This starts a Call for Adoption for draft-mglt-dnsop-dnssec-validator-requirements The draft is available here: https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ 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. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 18 May 2020 Thanks, tim wicinski DNSOP co-chair ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop