Subject: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

From: tjw ietf <[email-masked]>
Date: Thu, 5 Apr 2018 12:35:55 -0400

After walking through the 168 emails on this draft in the inbox, I feel
we're ready to take this to WGLC.

(We are aware of the two points raised my Job and Paul)

This starts a Working Group Last Call for:  draft-ietf-dnsop-kskroll-
sentinel

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/

The Current Intended Status of this document is: Proposed Standard

In the brushing of the camel, the draft is focused on determining if
a particular root key has been loaded into resolvers.

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
if someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on:  23:59
19 April 2018

thanks
tim

---

From: Job Snijders <[email-masked]>
Date: Thu, 05 Apr 2018 17:15:47 +0000

Hi all,

While the chair notes awareness of the point I raised, I’d like the be
explicit to avoid any confusion.

This document is *not* ready for publication. There is no implementation
report available for review and consideration.

Should the working group produce an implementation report and demonstrate
multiple implementations before April 15th, I’d ofcourse be willing to
reconsider my position.

Kind regards,

Job

On Thu, 5 Apr 2018 at 18:36, tjw ietf <[email-masked]> wrote:

> This starts a Working Group Last Call for:
>  draft-ietf-dnsop-kskroll-sentinel
>
> This starts a two week Working Group Last Call process, and ends on:
>  23:59 19 April 2018
>
> thanks
> tim
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: tjw ietf <[email-masked]>
Date: Thu, 5 Apr 2018 13:37:09 -0400

Thanks Job for keeping *me* straight.

Tim

On Thu, Apr 5, 2018 at 1:15 PM, Job Snijders <[email-masked]> wrote:

>> if someone feels the document is *not* ready for publication, please
>> speak out with your reasons.
>>

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 06 Apr 2018 13:18:06 +0200

> (We are aware of the two points raised my Job and Paul)

Especially given that an implementation is in fact available (in Knot), 
why not take this opportunity to start demanding Implementation Status 
sections for those drafts where that requirement makes sense? Because it 
certainly makes sense here!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Petr Špaček <[email-masked]>
Date: Fri, 6 Apr 2018 14:00:53 +0200

> certainly makes sense here!

Please note that we did not update Knot Resolver to comply with latest
version of the draft *yet*. This is likely to happen over next couple
weeks, not sooner. We have hands full with other tasks at the moment.

Of course patches to
https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/modules/ta_sentinel/ta_sentinel.lua
are more than welcome!

Speaking of Joes comment, it makes sense to me. AFAIK other resolvers
are going to implement this anyway so there is no point in rushing the
RFC out and setting it in stone before it gets implemented at least twice.

-- 
Petr Špaček  @  CZ.NIC

---

From: Job Snijders <[email-masked]>
Date: Fri, 06 Apr 2018 12:29:33 +0000

> RFC out and setting it in stone before it gets implemented at least twice.

My grandmother used to tell me you can’t build a stable chair with just two
legs. Three is the minimum. Or perhaps four:
https://commons.wikimedia.org/wiki/File:BrokenChair.jpg

Kind regards,

Job

---

From: Warren Kumari <[email-masked]>
Date: Fri, 6 Apr 2018 08:37:15 -0400

> report available for review and consideration.

[with absolutely no hats]

I get that you believe that this is wrong, but DNSOP currently has no
requirement for there to be an implementation report (nor for there to
be any implementations). The way to change this is by proposing that
this change (done), having the discussion (ongoing) and then having
the chairs declare consensus and that they will require this going
forward. It would also be useful for there to be clarity about what
exactly is required, and for what sort of documents (e.g how does one
implement attrleaf? or SUDN?), and when this would go into effect.

A number of people have told me that they wait until something becomes
an RFC before being willing implement it (some of this may be because
a significant number of adopted document have simply expired and not
been published) - suddenly requiring implementations is a large
change, and deciding it now and retroactively applying it to documents
which were about cooked seems a little unreasonable. I'd also note
that this somewhat disenfranchises participants who a: don't code and
/ or b: don't work for a vendor.

I'm (of course) fine if the WG / chairs decide that DNSOP needs
implementations before progressing documents, but your wording makes
it sound like you believe this this is already the case, and not
simply your (strong) preference.

W

>> https://datatracker.ietf..org/doc/draft-ietf-dnsop-kskroll-sentinel/
>>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Job Snijders <[email-masked]>
Date: Fri, 6 Apr 2018 13:45:01 +0000

Dear Warren,

On Fri, Apr 06, 2018 at 08:37:15AM -0400, Warren Kumari wrote:
> > While the chair notes awareness of the point I raised, I’d like the
> > be explicit to avoid any confusion.
> >
> > This document is *not* ready for publication. There is no
> > implementation report available for review and consideration.
> 

The authors of draft-ietf-dnsop-kskroll-sentinel (combined) have at
least 40 years of IETF experience. As such I'm not hesitant to hold them
to the highest standards. Cowboy hats notwithstanding. The protocol
specification will be better for it, and the working group will gain
experience.

> be any implementations). 

The working group chair asked for feedback from the working group:

    tjw wrote:
    "Please review the draft and offer relevant comments.  If this does
    not seem appropriate please speak out. if someone feels the document
    is *not* ready for publication, please speak out with your reasons."
    (https://mailarchive.ietf.org/arch/msg/dnsop/TfW55JEhQOybvlFLcPjybU6ATVU)

Naturally, I did what was asked of me.

> The way to change this is by proposing that this change (done), having
> the discussion (ongoing) and then having the chairs declare consensus
> and that they will require this going forward. It would also be useful
> for there to be clarity about what exactly is required, and for what
> sort of documents (e.g how does one implement attrleaf? or SUDN?), and
> when this would go into effect.

While you are right that it is useful to define what is required for
what sort of document, but I'd like to observe that at this moment, we
are looking at a draft with 0 (zero, null, nada) implementations*, and
also no implementation report draft which stipulates what should be
tested. So your specific question is perhaps somewhat moot. Whatever the
answer is, it will be larger than zero.

    [* Petr was kind enough to provide the working group with an update
    on the progress of a knot implementation, he shared that knot is not
    compatible with the draft-ietf-dnsop-kskroll-sentinel-07 specification
    https://mailarchive.ietf.org/arch/msg/dnsop/ZJ9P7iXUfMoBEojCxVAsJTNs5_Y ]

> which were about cooked seems a little unreasonable. 

"Documents which were about cooked" ?!?! Is this some kind of special
pre-WGLC status? Perhaps the word we are looking for is 'undercooked'? :-)

I have trouble following the line of thought here. Perhaps you can share
your thought on why IDR doesn't seem troubled by these concerns? Companies that
apply "Won't implement until RFC"-policies risk staying behind on the
innovation curve. That is their choice.

I've not seen any attempt to retroactively apply common sense without
following proper process. The process to obsolete/deprecate published
RFCs is well known, and if someone chooses to write a deprecation draft
where the main reason is "lack of implementations" they are free to do
so?

IETF protocol specifications without implementations are worthless. The
IETF TOA lists the phrase "running code" five times. Section A.5 states:

    "IETF Standards Track specifications are not considered to be
    satisfactory standards until interoperable independent
    implementations have been demonstrated. (This is the embodiment of
    the "running code" slogan.)"
    source: https://www6.ietf.org/tao.html

draft-ietf-dnsop-kskroll-sentinel-07 targets "Standards Track". The
current state of draft-ietf-dnsop-kskroll-sentinel and my understanding
of the IETF slogan "rough consensus and running code" are incompatible.

> I'd also note that this somewhat disenfranchises participants who a:
> don't code and / or b: don't work for a vendor.

I fail to see what disenfranchisement you are referring to. Can you
elaborate? You don't need to have code abilities to create a protocol
specifications, but you'll need to work with protocol implementers. I'd
like to keep the IETF process as inclusive as possible.

> simply your (strong) preference.

I am aware DNSOP does not have a policy of requiring implementations,
and I find this lack of policy regrettable. I believe this document is
not ready for WGLC, for the reasons I listed.

Kind regards,

Job

---

From: Joe Abley <[email-masked]>
Date: Fri, 6 Apr 2018 07:00:30 -0700

> answer is, it will be larger than zero.

I feel that I'm a reasonably pragmatic person and I am not generally
in favour of boiling the ocean when all we were asked for was an
ISO-standard cup of tea.

However, I think it's worth reflecting on what happens when we don't
have a firm grip on protocol compliance in related implementations --
we get the kind of confusion that resulted from RFC8145. Although that
confusion has numerous root causes, we know for a fact that
variability in implementation has contributed to the madness.

The purpose of this particular draft is to facilitate useful
measurements that will yield a clear signal. I don't imagine the
authors of the draft are any more eager to see a noisy signal than the
rest of us.

If we can make it easier for implementations to behave reliably and
predictably e.g. by specifying what compliance means, I regardless of
the formal requirements of the working group, perhaps we should.

Joe

---

From: 神明達哉 <[email-masked]>
Date: Fri, 6 Apr 2018 11:43:57 -0700

At Thu, 05 Apr 2018 17:15:47 +0000,

> report available for review and consideration.

(After reading other messages in this thread) I tend to agree.  Even
after careful reviews of protocol text, an attempt of actually
implementing it often reveals non-negligible issues that were
overlooked in the review.  Of course, it's a different question
whether dnsop adopts the requirement as a general rule for any
documents (although I would support the idea personally), at least in
this particular case I think it makes sense because:
- right now there's no known implementation of the latest version of
  the draft
- there seems to be some reasonable expectation that Knot will support
  the latest version not far from now
So it makes sense to me to hold off at least until Knot (or any other
implementation) actually adds
support for it or a sufficient amount of time (a couple of weeks?)
elapses without a news.  In the latter case we might discuss whether
we should make a compromise to move forward at that point.

--
JINMEI, Tatuya

---

From: Joe Abley <[email-masked]>
Date: Fri, 6 Apr 2018 11:49:17 -0700

On Apr 6, 2018, at 14:43, 神明達哉 <[email-masked]> wrote:

> overlooked in the review.

I think it's perhaps worth looking at this from the implementation
perspective, yes.

I don't doubt that we can expect close collaboration and testing
between APNIC Labs and the various resolver implementors, especially
given the experience with 8145.

If I'm right about that, it seems to me that (a) delaying the last
call to allow any unexpected issues with the specification to be
documented and (b) including details of the testing/compliance
criteria in the document for the benefit of future implementations are
both good ideas.

In other words, don't think of this as a constraint on publication but
rather an opportunity to make the document better without holding up
implementation.

Joe

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 6 Apr 2018 17:49:42 -0400

Hi,

Thanks all for vigorous discussion, but I think it would be helpful to separate comments on draft-ietf-dnsop-kskroll-sentinel from general comments on WG guidelines for future documents. 

> On Apr 6, 2018, at 9:45 AM, Job Snijders <[email-masked]> wrote:
> 
> 

The fact that we don’t have a rule about all documents doesn’t mean an issue can’t be raised about a specific document.

While it’s often disappointing to editors when the WG raises significant issues in WGLC, that’s kind of what WGLC is for.

We’re hearing that having an RFC will be helpful to promoting implementation, and also that this draft may not be ready to be advanced for publication because it doesn’t include implementation experience. This is something the WG needs to comment on further, because it seems substantive to me so it will have to be addressed one way or another before we advance the document— but those inputs are somewhat in disagreement.

Editors: Please take “concern about a description of current implementation status” as WGLC input, and consider what you might be able to add to the draft to address it. 

WG vendors/implementers: Can folks who have implemented kskroll-sentinel, or considered implementing it, please speak up on your concerns/plans?

Thanks,
Suzanne (&Tim)

---

From: Warren Kumari <[email-masked]>
Date: Fri, 6 Apr 2018 22:09:50 -0400

> Thanks all for vigorous discussion, but I think it would be helpful to separate comments on draft-ietf-dnsop-kskroll-sentinel from general comments on WG guidelines for future documents.

Yup, I fully agree -- these have become conflated. (This drove the
irritated tone of my prior email.)

> The fact that we don’t have a rule about all documents doesn’t mean an issue can’t be raised about a specific document.

Yup, and they have been raised about this document.

> We’re hearing that having an RFC will be helpful to promoting implementation, and also that this draft may not be ready to be advanced for publication because it doesn’t include implementation experience.

Yeah, it is disappointing, but the authors are big boys and girls, and
after sobbing into our pillows for a little bit we'll be okay... :P

It seems to me that there is a fairly strong signal from the WG for
*this* document should have an implementation section -- speaking only
for myself, this seems like a reasonable request.

Again, for *this* document I understand that the WG wants an
implementation section, and so we should add one - I'm not sure we'd
be able to have that done by April 19th, and so I'm not sure if the
chairs want to consider pausing the WGLC.

> This is something the WG needs to comment on further, because it seems substantive to me so it will have to be addressed one way or another before we advance the document— but those inputs are somewhat in disagreement.
>

Yup, that would be helpful  - bits I know of are that Knot has an
implementation based on an earlier version (with a different label),
and Petr says that it will be some time before they are able to update
it; I've never touched Lua, if I get a chance I might try patch their
implementation with the new strings ("Hold my beer" / "How hard can it
be?")).
I think I heard that ISC was considering adding support, but was
planning on waiting till RFC / some sort of LC.

On the "other" side of this there are a few "client" implementations
-- the infamous ksk-test.net, Ray Bellis has
http://www.bellis.me.uk/sentinel/, and Paul Hoffman also has code
(which I have embarrassingly misplaced).

Once we have more details, these could be folded into the
implementation section...

W

---

From: Evan Hunt <[email-masked]>
Date: Sat, 7 Apr 2018 06:27:14 +0000

> planning on waiting till RFC / some sort of LC.

Yes. The work in progress is available here:
https://gitlab.isc.org/isc-projects/bind9/merge_requests/123

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Benno Overeinder <[email-masked]>
Date: Sat, 7 Apr 2018 11:41:37 +0200

Hi Suzanne, Warren, DNSOP WG,

> On 7 Apr 2018, at 04:09, Warren Kumari <[email-masked]> wrote:
> 

NLnet Labs is planning to add kskroll-sentinel support soon.  We will report progress and feedback to the authors of the kskroll-sentinel draft.

Code will be made available in our repository and asap be part of the Unbound release (for packaging & distribution).

Cheers,

— Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

---

From: Bob Harold <[email-masked]>
Date: Mon, 9 Apr 2018 11:54:27 -0400

On Sat, Apr 7, 2018 at 5:41 AM, Benno Overeinder <[email-masked]> wrote:

> >> WG vendors/implementers: Can folks who have implemented
> kskroll-sentinel, or considered implementing it, please speak up on your
> concerns/plans?
> >
> NLnet Labs is planning to add kskroll-sentinel support soon.  We will
> report progress and feedback to the authors of the kskroll-sentinel draft.
>
> Code will be made available in our repository and asap be part of the
> Unbound release (for packaging & distribution).
>
> Cheers,
>
> — Benno
>
>
> --
> Benno J. Overeinder
> NLnet Labs
+1 to holding for a while to see if implementations find any issues.

-- 
Bob Harold

---

From: George Michaelson <[email-masked]>
Date: Thu, 12 Apr 2018 11:36:55 +1000

I'd like the WG to close on this. It feels to me like we've had useful
edit in the call and the document is now stable and ready to move onto
the next phase.

Ship it.

-George

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 13 Apr 2018 10:40:19 +0200

Hello Suzanne,

On 6 Apr 2018, at 23:49, Suzanne Woolf wrote:

> We’re hearing that having an RFC will be helpful to promoting 
> implementation, and also that this draft may not be ready to be 
> advanced for publication because it doesn’t include implementation 
> experience. This is something the WG needs to comment on further, 
> because it seems substantive to me so it will have to be addressed one 
> way or another before we advance the document— but those inputs are 
> somewhat in disagreement.

In WG context, not in draft context: I do not think these inputs are in 
disagreement. If a draft can find -zero- implementers that think the 
draft is a sufficiently good idea that they write an implementation 
during draft status, the draft is, most likely, a bad idea.

> Editors: Please take “concern about a description of current 
> implementation status” as WGLC input, and consider what you might be 
> able to add to the draft to address it.
>
> kskroll-sentinel, or considered implementing it, please speak up on 
> your concerns/plans?

Because of privacy concerns (currently raised in section 7 of the draft 
quite briefly), PowerDNS will not be implementing this protocol.

Kind regards,

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 24 Apr 2018 15:02:22 +0200

And the MR was peer-review and merged into BIND master branch with intent to backport the feature into older release branches.

I don’t think it’s a useful or helpful to change the rules for existing adopted work.  We need to have a discussion on the mechanisms that would allow implementors to know when to start the implementation of existing draft. From implementors point, it makes little sense to start implementing before the protocol change is almost fully baked (aka WGLC and further), because until then the protocol might change considerably.

So, if we require implementation report further down the road, it needs to be more clearly defined than people suddenly shouting “this is not ready” when WGLC starts.  And while the attempt to implement something is certainly useful to get valuable feedback, it also imposes some costs (with undefined limit) on implementors (especially the open source implementors) and it sort of discards the whole “Proposed Standard” -> “Internet Standard” classification at global IETF level.

I get that we probably need something more lightweight than “Internet Standard” at the WG level, but this needs to be discussed and consensus reached.

ISC gave our feedback during the implementation and here are some nits from me (re-reading the document again):

~~~

Section "2.  Protocol Walkthrough Example" will be made into Appendix at publication time, so just reminder here that you also need to change the references like "(see the logic below)” when you move the section - perhaps add direct reference to the other section this refers to?

~~~

The table in 3.2 says:

"Key Tag is trusted” and “Key Tag is not trusted” - it seems little bit confusing to me; I think that “Key is trusted” and “Key is not trusted”; or some change similar to this needs to be made:

“First, the resolver determines if the Key Tag is trusted by comparing numerical value of <key-tag>
   to any of the Key Tags of an active root zone KSK which is
   currently trusted…"

in paragraph just before the table you mix “Key Tag” and “keytag” and there’s also <key-tag>…

My understanding of the text and the proposed fix:

[…]

   First, the resolver determines if the numerical value of <key-tag> is
   equal to any of the Key Tags of an active root zone KSK which is
   currently trusted by the local resolver and is stored in its store of
   trusted keys.  If a match is found the <key-tag> is trusted. An active
   root zone KSK is one which could currently be used for
   validation (that is, a key that is not in either the AddPend or
   Revoked state as described in [RFC5011]).  

   Second, the resolver alters the response being sent to the original
   query based on both the left-most label and the presence of a key
   with given Key Tag in the trust anchor store.  Two labels and two
   possible states of the <key-tag> generate four possible combinations
   summarized in the table:

    Label      |   <key-tag> is trusted    |   <key-tag> is not trusted
    ------------------------------------------------------------------
    is-ta      | return original answer  | return SERVFAIL
    not-ta     | return SERVFAIL         | return original answer

[…]

~~~

   o  A query name that is signed with a DNSSEC signature that cannot be
      validated (such as if the corresponding RRset is not signed with a
      valid RRSIG record).

This is called “Bogus” by RFC 4033 Section 5 -> maybe a reference?

~~~

In  Section: 7.  Privacy Considerations

s/mechansim/mechanism/

~~~

That is all folks.

Cheers,
Ondrej
--
Ondřej Surý
[email-masked]

> On 7 Apr 2018, at 08:27, Evan Hunt <[email-masked]> wrote:
>