Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements

[Tim Wicinski]

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

[Loganaden Velvindron]

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

[Daniel Migault]

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

[Daniel Migault]

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/
>> 
>>
>>
>> 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

[Ralf Weber]

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

[sanjay . mishra=40verizon . com]

+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

[Tim Wicinski]

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

[Joe Abley]

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

[Daniel Migault]

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

[Joe Abley]

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

[Daniel Migault]

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

[Brian Dickson]

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/
> 
>
>
> 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

[Bob Harold]

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

[Shumon Huque]

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

[Shumon Huque]

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

[Daniel Migault]

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
> configuration errors, but due to human intervention as well as
> potential misunderstanding of ongoing operations.")
>
> This erro has been raised by Bob and already corrected in the version on
the repository:

Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements

[Stephane Bortzmeyer]

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