Subject: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Mar 2018 11:55:51 +1100

This title of this document DOES NOT match reality.

"A Sentinel for Detecting Trusted Keys in DNSSEC” should be
replaced by “A Root Key Trust Anchor Sentinel for DNSSEC”.

kskroll-sentinel-<what>-<id> really needs something other
than “kskroll” as the first field.  “root-key-sentinal-<what>-<id>”
really more clearly matches what it does.

Any other changes that follow from these two changes"

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Mar 2018 14:12:46 +1100

> On 23 Mar 2018, at 11:55 am, Mark Andrews <[email-masked]> wrote:
> 
> than “kskroll” as the first field.  “root-key-sentinel-<what>-<id>”

If we want to make this generic then we need at least two sets
of labels. One set for the root so we can avoid the single label issue
and one set for other TA’s which encode the TA’s name in the query.

e.g. 
	“ta-sentinel-<what>-<id>.<ta-name>.”

---

From: Geoff Huston <[email-masked]>
Date: Fri, 23 Mar 2018 09:21:14 +0000

> On 23 Mar 2018, at 12:55 am, Mark Andrews <[email-masked]> wrote:
> 
> Any other changes that follow from these two changes”
> 

I personally think this is getting into bike shedding at this point.

The title of the document is an adequate description of the content
and folk who want to know more should read the document, not guess
from the title!

The label is a piece of syntactic convenience and is entirely
arbitrary. We could start an almost infinite discussion thread
over which label is better, but in the end its just a label.

regards,

    Geoff

---

From: Joao Damas <[email-masked]>
Date: Fri, 23 Mar 2018 09:29:01 +0000

Mark,

> On 23 Mar 2018, at 00:55, Mark Andrews <[email-masked]> wrote:
> 

Sigh	, really?

> really more clearly matches what it does.

It is just a string that is easily identifiable. Let’s get over this.

Joao

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 09:38:36 +0000

Hi Joao,

I think Mark has a legitimate question. Once we settle on one specific label, it will get stapled all over - not only the label in the domain name, but also configuration options, etc… etc…

I proposed rzksk-sentinel for our configuration to enable/disable it, but Mark is quite right that this needs to be in sync with the label.

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

> On 23 Mar 2018, at 09:29, Joao Damas <[email-masked]> wrote:
> 
> Mark,
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 09:40:09 +0000

Pleas, just ignore me. It’s too early in the morning.

The label is of-course is-ta. and not-ta.

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

> On 23 Mar 2018, at 09:38, Ondřej Surý <[email-masked]> wrote:
> 
> Hi Joao,
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Mar 2018 21:07:25 +1100

Geoff you are wrong. Titles should tell you what you are about
to read especially technical documents. There are WAY TOO MANY
RFC TO READ EVERYONE ON THEM.

If I had a TA for andrews.wattle.id.au the current title would
indicate that I could test resolvers to see if there is a TA
installed for it.

The current draft *is not* generic.  It is root TA specific.
That needs to be reflected in the title.

As for the label it can be used for more than rolling KSKs.
It can be used to see what resolvers are supporting new TA
*when you are not rolling keys*.  The current name reflects
*one* use, not all uses.

Mark

> On 23 Mar 2018, at 8:21 pm, Geoff Huston <[email-masked]> wrote:
> 
> 
>

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 10:19:24 +0000

Again, blame the morning and the Google that led me to old version of the draft, in fact the current draft says:

   [ NOTE: This version uses the labels "kskroll-sentinel-is-ta-<key-
   tag>", "kskroll-sentinel-not-ta-<key-tag>"; older versions of this
   document used "_is-ta-<key-tag>", "_not-ta-<key-tag>".  Also note
   that the format of the tag-index is now zero-filled decimal.
   Apolgies to those who have began implmenting.]

And I believe the “kskrool-" part is in fact wrong, as even though it targets the current RZ KSK Roll, it’s not what the mechanism describes - this is a mechanism to monitor root zone trust anchors.

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Mar 2018 21:28:05 +1100

Also Section 3.1 is not specific enough to implement.  QNAME needs a
qualifier (current or original).

The leftmost label of the QNAME is either "kskroll-sentinel-is-ta-
      <key-tag>" or "kskroll-sentinel-not-ta-<key-tag>"
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Fri, 23 Mar 2018 11:08:02 +0000

> RFC TO READ EVERYONE ON THEM.

... you lack ambition :-P

> *when you are not rolling keys*.  The current name reflects

True, it does reflect one use case, not all -- however, we have
already changed the name multiple times and implementers are
(understandably) becoming annoyed, and supporting N different labels
for the tester is also annoying [0].

How about a compromise - we update the draft name, but keep the label
the same - the only people who likely care about the label are
implementers and testers - once someone sees the name they will read
the doc and quickly discover how it can be used.

W

-- 
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: Mark Andrews <[email-masked]>
Date: Fri, 23 Mar 2018 22:47:08 +1100

> On 23 Mar 2018, at 10:08 pm, Warren Kumari <[email-masked]> wrote:
> 

As an implementer I say TOUGH!  The job of the working group is to
put out good specifications not to take short cuts just because
something has been implemented based on a draft.  This is the expected
cost of implementing on a draft.  I’ve re-written plenty of code to
follow draft changes.

I’ve got code to implement this.  Some corner cases are currently
undefined. Changing the label name will cause me to have to re-write
parts of what I have already written.  I know this but I’m still
calling for the changes.  Not only will the specific labels change
but potentially configuration arguments and with that documentation.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 12:08:11 +0000

Warren,

> however, we have

Who are exactly these people?

We are aware only of Knot Resolver implementation so far. And I guess Geoff has a “client” side implementation, but it’s not like everybody already implemented this and we are the last one that are asking for a change.

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

---

From: George Michaelson <[email-masked]>
Date: Fri, 23 Mar 2018 12:08:59 +0000

isn't it a #define string? or passed in via environment from configure?

-G

---

From: Warren Kumari <[email-masked]>
Date: Fri, 23 Mar 2018 12:13:45 +0000

On Fri, Mar 23, 2018 at 11:47 AM, Mark Andrews <[email-masked]> wrote:
> something has been implemented based on a draft.

... and the job of the authors is to document what the WG wants.

Dear DNSOP,

Please clearly express a preference for:
1: Keeping the current label -- kskroll-sentinel-is-ta-20326.example.com
2: Changing it to the new label -- root-key-sentinal-is-ta-20326.example.com

This is (obviously) a trivial change for us to make (sed
's/kskroll-sentinel-/root-key-sentinal-/g), but not sure what y'all
would like.

W

> This is the expected

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 12:14:44 +0000

It’s not only that - however unbelievable it might seems, but we also have tests (and variable names) and I do believe the things should be consistent for future generations.

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

> On 23 Mar 2018, at 12:08, George Michaelson <[email-masked]> wrote:
>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 23 Mar 2018 12:22:16 +0000

>       <key-tag>" or "kskroll-sentinel-not-ta-<key-tag>"

This was too terse for me to parse.

The check is: Does the left most label in the query name match
"kskroll-sentinel-is-ta-<key-tag>" where <key-tag> is as unsigned
decimal integer (as described in [RFC4034], section 5.3), zero-padded
to five digits (for example, a Key Tag 42 would be represented in the
label as 00042).

So, kskroll-sentinel-is-ta-19036.example.com would match, as would
kskroll-sentinel-is-ta-20326.example.com, as would
kskroll-sentinel-is-ta-00042.example.net.
The question is not kskroll-sentinel-is-ta-original.example.com.

I really don't understand your question -- please help.
W

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Mar 2018 23:40:51 +1100

What is the expected behaviour given
example.net CNAME kskroll-sentinel-is-ta-<key-tag>.example.com
when you query for example.net when the key-tag does not match
a root TA? etc.

> On 23 Mar 2018, at 11:22 pm, Warren Kumari <[email-masked]> wrote:
>

---

From: Ralph Dolmans <[email-masked]>
Date: Fri, 23 Mar 2018 16:11:00 +0100

> 2: Changing it to the new label -- root-key-sentinal-is-ta-20326.example.com

I prefer the second option (with sentinel instead of sentinal). Please
change the label so it reflects the behaviour of the query, now that
changes are still possible.

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 23 Mar 2018 15:19:11 +0000

I agree with Mark, especially about the title.  

For the magic string, I'd like to see it closer to Mark's proposal, but its not a deal breaker.

DW

> On Mar 22, 2018, at 5:55 PM, Mark Andrews <[email-masked]> wrote:
>

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 23 Mar 2018 15:20:54 +0000

> On Mar 23, 2018, at 5:13 AM, Warren Kumari <[email-masked]> wrote:
> 
> Dear DNSOP,
> 

I prefer #2.

DW

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 23 Mar 2018 16:13:08 +0000

I also prefer #2

Personally, I would go with rzksk-sentinel because it’s shorter and more accurate, but #2 will make me happy.

Ondrej
--
Ondřej Surý — ISC

> On 23 Mar 2018, at 15:20, Wessels, Duane <[email-masked]> wrote:
> 
>

---

From: Joao Damas <[email-masked]>
Date: Fri, 23 Mar 2018 17:11:37 +0000

I am happy with whatever the wg agrees but let’s agree, otherwise time keeps sliding and the only label that is going to be accurate for the next generations will be “ksk-roll-that-never-was” ;)

Joao

> On 23 Mar 2018, at 16:13, Ondřej Surý <[email-masked]> wrote:
> 
> I also prefer #2
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 23 Mar 2018 17:19:36 +0000

+1 to the title “A Root Key Trust Anchor Sentinel for DNSSEC”.

+1 to option #2 with the spelling correction.

--Paul Hoffman

---

From: Bob Harold <[email-masked]>
Date: Fri, 23 Mar 2018 13:22:42 -0400

> +1 to option #2 with the spelling correction.
+1

-- 
Bob Harold

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 23 Mar 2018 14:53:45 -0300

> > +1 to option #2 with the spelling correction.

Agree with both.

But let me emphasize Joao's point, we need to pick those now and move
forward.

Fred

---

From: Paul Vixie <[email-masked]>
Date: Fri, 23 Mar 2018 11:00:03 -0700

i'm concerned about the age-old human protocol being employed here.

first one guy shouts bikeshed! (usually somebody who's been bikeshedding.)

nextly, some folks say "the details don't matter, only uniqueness."

then there's a bunch of back and forth about whether and which details 
matter.

then there's a lot of folks saying, "personally i would go with..." or 
"i prefer ..." or "my vote is for..."

then somebody inevitably says "this is taking too long, let's just pick 
something."

it's how ipv6 and dnssec were standardized, with sweepingly bad results 
that our great grandchildren will no doubt shake their heads about, in 
wonder.

i request a different protocol.

can the co-chairs convene a design team made up of people from each camp 
named above, and lock them in a room and shove pizza under the door 
until they have a proposal that can be accepted on its _merits_?

vixie

re:

Joao Damas wrote:
>> On 23 Mar 2018, at 16:13, Ondřej Surý<[email-masked]>  wrote:
>>
>> I also prefer #2
>>
>>> On 23 Mar 2018, at 15:20, Wessels, Duane<[email-masked]>  wrote:
>>>
>>>
>>>> On Mar 23, 2018, at 5:13 AM, Warren Kumari<[email-masked]>  wrote:
>>>>
>>>> Dear DNSOP,
>>>>

-- 
P Vixie

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 23 Mar 2018 15:15:05 -0300

Paul,

> until they have a proposal that can be accepted on its _merits_?

This doesn't seams to be the case. The document is being reviewed by
the WG for a while and just adjusting the label and the document's
name, closing their use only for the root, is a good move.

This expansion in scope was included in the beginning of the
discussion just to make the point that the root is not different from
any other zone and this mechanism could be expanded for other
cases... perfect and over engineered. The reality is this is only
needed for the root that has no parent. Please no one start the
argument of local configure anchors any zone down the tree. If this is
the case for an enterprise or Mil. network they have their ways of
controlling/distributing those anchors.

The document is good on it's own merits.

Fred

---

From: João Damas <[email-masked]>
Date: Fri, 23 Mar 2018 18:15:53 +0000

A design team to pick a label? Wow, just wow!

João

> On 23 Mar 2018, at 18:00, Paul Vixie <[email-masked]> wrote:
> 
> then there's a bunch of back and forth about whether and which details matter.
> 
> then there's a lot of folks saying, "personally i would go with..." or "i prefer ..." or "my vote is for..."
> 
> then somebody inevitably says "this is taking too long, let's just pick something."
> 
> it's how ipv6 and dnssec were standardized, with sweepingly bad results that our great grandchildren will no doubt shake their heads about, in wonder.
> 
> can the co-chairs convene a design team made up of people from each camp named above, and lock them in a room and shove pizza under the door until they have a proposal that can be accepted on its _merits_?
> 
> vixie
> 
> re:
> 
> Joao Damas wrote:

---

From: Warren Kumari <[email-masked]>
Date: Sat, 24 Mar 2018 10:44:15 +0000

>> > +1 to option #2 with the spelling correction.

Awesome, thanks - this seems to be the consensus.

A new version of I-D, draft-ietf-dnsop-kskroll-sentinel-08.txt
has been successfully submitted by Warren Kumari and posted to the
IETF repository.

Name:           draft-ietf-dnsop-kskroll-sentinel
Revision:       08
Title:          A Root Key Trust Anchor Sentinel for DNSSEC
Document date:  2018-03-24
Group:          dnsop
Pages:          15
URL:
https://www.ietf.org/internet-drafts/draft-ietf-dnsop-kskroll-sentinel-08.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-08
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-kskroll-sentinel-08

Abstract:
   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be verified by building a
   chain of trust starting from a trust anchor and proceeding down to a
   particular node in the DNS.  This document specifies a mechanism that
   will allow an end user and third parties to determine the trusted key
   state for the root key of the resolvers that handle that user's DNS
   queries.  Note that this method is only applicable for determing
   which keys are in the trust store for the root key.

   There is an example / toy implementation of this at http://www.ksk-
   test.net .

   [ This document is being collaborated on in Github at:
   https://github.com/APNIC-Labs/draft-kskroll-sentinel.  The most
   recent version of the document, open issues, etc should all be
   available here.  The authors (gratefully) accept pull requests.  Text
   in square brackets will be removed before publication. ]

W

---

From: Michał Kępień <[email-masked]>
Date: Mon, 26 Mar 2018 12:04:22 +0200

> when you query for example.net when the key-tag does not match

This question is still outstanding as of version -08 of the draft.

-- 
Best regards,
Michał Kępień

---

From: Ralph Dolmans <[email-masked]>
Date: Mon, 26 Mar 2018 12:35:25 +0200

> This question is still outstanding as of version -08 of the draft.

It is indeed, and it is a question that needs to be answered before it
is possible to properly implement the sentinel.

For the sake of simplicity I prefer that the *original* QNAME should
match the special label.

-- Ralph

---

From: Petr Špaček <[email-masked]>
Date: Mon, 26 Mar 2018 13:09:44 +0200

> We are aware only of Knot Resolver implementation so far. And I guess Geoff has a “client” side implementation, but it’s not like everybody already implemented this and we are the last one that are…

I'm fine with change, even though tests need to be re-signed which is
always PITA.

Petr Špaček  @  CZ.NIC

---

From: Petr Špaček <[email-masked]>
Date: Mon, 26 Mar 2018 13:13:21 +0200

On 26.3.2018 12:35, Ralph Dolmans wrote:> On 26-03-18 12:04, Michał
> For the sake of simplicity I prefer that the *original* QNAME should

Meaning of QNAME is (re)defined here:
https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-09#page-10
Let's be explicit and use "QNAME (original)".

-- 
Petr Špaček  @  CZ.NIC

---

From: Warren Kumari <[email-masked]>
Date: Mon, 26 Mar 2018 21:46:00 +0100

> Let's be explicit and use "QNAME (original)".

Thank you, I've made this, and incorporated a few other edits (thanks
to Paul Hoffman for the PR) and posted a new version (-09)

W