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

From: Tim Wicinski <[email-masked]>
Date: Mon, 4 May 2020 15:08:20 -0400

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 6 May 2020 10:48:36 +0200

On Mon, May 04, 2020 at 03:08:20PM -0400,
 Tim Wicinski <[email-masked]> wrote 

> 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.")

---

From: Jacques Latour <[email-masked]>
Date: Wed, 6 May 2020 18:15:22 +0000

I support the adoption of this document as well, perhaps a bit long but as Stéphane stated with draft-ietf-dnsop-extended-error, it would nice to have a good story on understanding why resolvers return SERVFAIL.
 
>-----Original Message-----
>From: DNSOP <[email-masked]> On Behalf Of Stephane Bortzmeyer
>Sent: May 6, 2020 4:49 AM
>To: Tim Wicinski <[email-masked]>
>Cc: dnsop <[email-masked]>; dnsop-chairs <[email-masked]>
>Subject: [EXT] Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
>
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

---

From: Daniel Migault <[email-masked]>
Date: Wed, 6 May 2020 17:48:29 -0400

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 <[email-masked]>
wrote:

>  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

> 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

> and expiration dates are allowed to be off by 10% of the signature
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

> 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

> about. Monitoring is a good idea but monitoring what? "Important" (for
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

> This erro has been raised by Bob and already corrected in the version on
the repository:
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd

The correct text is:
This introduces a potentially huge vector for configuration errors, due to
human intervention as well as potential misunderstanding of ongoing
operations.

Others grammar and language issues have also been corrected.

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 6 May 2020 17:57:56 -0400

Hi Jacques,

Thanks you for the feedbacks. As suggested by Stephane, the document needs
to emphasize on the communication between the client and the resolver. I
open the following issue and will address this in the next version.
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/2

Yours,
Daniel

On Wed, May 6, 2020 at 2:16 PM Jacques Latour <[email-masked]>
wrote:

> I support the adoption of this document as well, perhaps a bit long but as
> Stéphane stated with draft-ietf-dnsop-extended-error, it would nice to have
> a good story on understanding why resolvers return SERVFAIL.
>
> >Subject: [EXT] Re: [DNSOP] Call for Adoption:

-- 
Daniel Migault
Ericsson

---

From: Shumon Huque <[email-masked]>
Date: Thu, 7 May 2020 08:34:21 -0400

> already too low). The current draft seems a good starting point and I

I also support adoption and will review/contribute etc.

> is the difficulty to understand why a resolver returns a SERVFAIL to

Yup.

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

> and expiration dates are allowed to be off by 10% of the signature

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.

> 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

---

From: Shumon Huque <[email-masked]>
Date: Thu, 7 May 2020 08:50:21 -0400

> a possibly unacceptably small or large skew values depending on the

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.

---

From: Bob Harold <[email-masked]>
Date: Thu, 7 May 2020 09:04:30 -0400

> a possibly unacceptably small or large skew values depending on the

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

---

From: Brian Dickson <[email-masked]>
Date: Thu, 7 May 2020 10:55:23 -0700

On Mon, May 4, 2020 at 12:10 PM Tim Wicinski <[email-masked]> wrote:

> <https://datatracker..ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/>
>
>

I support adoption of this draft by DNSOP. I am willing to review.

Brian

---

From: Daniel Migault <[email-masked]>
Date: Thu, 7 May 2020 14:00:11 -0400

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

-- 
Daniel Migault
Ericsson

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 May 2020 14:16:49 -0400

On 4 May 2020, at 15:08, Tim Wicinski <[email-masked]> 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/
> 
> 

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

---

From: Daniel Migault <[email-masked]>
Date: Thu, 7 May 2020 15:39:08 -0400

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 <[email-masked]> wrote:

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

-- 
Daniel Migault
Ericsson

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 May 2020 15:42:44 -0400

Hi Daniel,

On 7 May 2020, at 15:39, Daniel Migault <[email-masked]> 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.

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

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 7 May 2020 20:16:06 -0400

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 <[email-masked]> 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.
>
> > 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.
>

---

From: "Ralf Weber" <[email-masked]>
Date: Sun, 10 May 2020 09:50:24 +0200

Moin!

> 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

---

From: Daniel Migault <[email-masked]>
Date: Mon, 11 May 2020 08:59:53 -0400

Thanks Brian. That is really much appreciated!
Yours,

Daniel

On Thu, May 7, 2020 at 1:56 PM Brian Dickson <[email-masked]>
wrote:

>> https://datatracker.ietf..org/doc/draft-mglt-dnsop-dnssec-validator-requirements/
> I support adoption of this draft by DNSOP.. I am willing to review.
>
> Brian
>
>
>

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Mon, 11 May 2020 09:04:16 -0400

Hi Tim,

Just to clarify, I fully agree there is a lot of similarities and we will
work on it with Joe.

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 12 May 2020 09:19:35 +0400

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

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 18 May 2020 13:48:40 -0400

All

Thanks for all the feedback on this call for adoption.  DNSOP will
be adopting this document to work on

thanks
tim