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

From: Geoff Huston <[email-masked]>
Date: Thu, 3 May 2018 18:15:49 +1000

Hi WG Chairs (and WG)

We have submitted -12 of this draft which we believe incorperates the substantive review comments made during the WG Last Call period that were posted to the WG Mailing List.
> 
> 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. 

We have also taken the implementation comments posted to the WG mailing list and collected them in a new section titled "Implementation Experience” in the light of Suzanne’s request

So we would like to pass this draft back to the WG Chairs at this point for your review for potential submission as an RFC.

Thanks,

 Geoff (for co-editors Joao and Warren)

---

From: Ralph Dolmans <[email-masked]>
Date: Thu, 3 May 2018 11:20:54 +0200

Hi,

> We have also taken the implementation comments posted to the WG mailing list and collected them in a new section titled "Implementation Experience” in the light of Suzanne’s request

This draft is by now implemented in Unbound and is in version 1.7.1
which we just released. I didn't find deficiencies in the latest version
of the draft that would hinder implementation.

I like to second Ondrej's earlier remark that from an implementors point
making an implementation for an early draft makes little sense, which is
why we waited until now. We need a somewhat stable specification before
we make code that will be used in the real world to prevent pollution
and in this case would make it even harder to do proper measurements.

-- Ralph

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 May 2018 13:06:03 -0400

what are the implications for older (pre-KSKROLL) validators when icann 
eventually rolls the key?

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 03 May 2018 10:16:25 -0700

On 3 May 2018, at 10:06, Paul Vixie wrote:

> what are the implications for older (pre-KSKROLL) validators when 
> icann eventually rolls the key?

None. That is, they will either be ready or they won't be, and this 
draft doesn't change that. This draft is about signaling, not about 
actually being ready for a roll.

--Paul Hoffman

---

From: Geoff Huston <[email-masked]>
Date: Fri, 4 May 2018 07:39:47 +1000

> On 4 May 2018, at 3:06 am, Paul Vixie <[email-masked]> wrote:
> 
> what are the implications for older (pre-KSKROLL) validators when icann eventually rolls the key?

I assume that you are referring to security-aware resolvers that do not perform the actions specified in this draft. There are no implications at all for these resolvers.

Any trusted key measurement conducted using such a resolver will show that the resolver is a security-aware resolver, but is not performing the sentinel method.

Geoff

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 May 2018 17:57:55 -0400

Geoff Huston wrote:
>
>> On 4 May 2018, at 3:06 am, Paul Vixie<[email-masked]>  wrote:
>>
> I assume that you are referring to security-aware resolvers that do
> not perform the actions specified in this draft. There are no
> implications at all for these resolvers.
>
> Any trusted key measurement conducted using such a resolver will show
> that the resolver is a security-aware resolver, but is not performing
> the sentinel method.

thanks. i feared for a moment a second TCR.

-- 
P Vixie

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 4 May 2018 10:04:13 +0200

I reviewed the -11 to -12 changes and they look good to me.

The document is ready to go in my opinion.

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

> On 3 May 2018, at 10:15, Geoff Huston <[email-masked]> wrote:
> 
> Hi WG Chairs (and WG)
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Job Snijders <[email-masked]>
Date: Mon, 7 May 2018 19:07:05 +0000

On Thu, May 03, 2018 at 06:15:49PM +1000, Geoff Huston wrote:
> We have submitted -12 of this draft which we believe incorperates the
> substantive review comments made during the WG Last Call period that
> were posted to the WG Mailing List.
> 
> > 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. 
> 
> We have also taken the implementation comments posted to the WG
> mailing list and collected them in a new section titled
> "Implementation Experience” in the light of Suzanne’s request
> 
> So we would like to pass this draft back to the WG Chairs at this
> point for your review for potential submission as an RFC.

1/ While this is a step in the right direction, I'm not yet entirely
impressed by the 'Implementation Experience' section. Is it somehow hard
to write an implementation report that describes which implementations
comply with the BCP 14 / RFC 8174 terms used in
draft-ietf-dnsop-kskroll-sentinel? Are the authors experiencing some
blocker in this regard?

2/ Moving the Walkthrough Example to the end of the document as an
appendix has greatly improved the readability of the document.

3/ Section 3 states: "The responses received from queries to resolve
each of these names would allow us to infer a trust key state of the
resolution environment.".
>From what I understand, in today's DNS world we can only reasonably
expect to do one query per packet. It is well understood that many
operators use BGP-4 anycasting (ECMP), the likes of dnsdist, and/or
simple UDP loadbalancers. I think it may be good to document that
running 3 queries (in essence 3 independent experiments) may not
generate sufficient data to properly infer the state (or any state) of
the resolution environment. Each query (as part of a single sentinel
data gathering session) may be handled by an entirely different resolver
with different keys, contaminating any lookup in the proposed truth
tables. Section 4 covers a number of cases where the results are
indeterminate. It maybe should be added to Section 4 that the client has
no awareness of how the resolver environment is constructed, and thus
requiring multiple independent queries to infer state has its downsides.

Kind regards,

Job

---

From: Mark Andrews <[email-masked]>
Date: Tue, 8 May 2018 11:05:50 +1000

> On 8 May 2018, at 5:07 am, Job Snijders <[email-masked]> wrote:
> 

Is it a implementation report or a compliance report?

To actually do a full compliance report for this draft it would require including a complete DNSSEC compliance report and in turn a complete STD 13 compliance report to meet this “MUST”.

   DNSSEC-Validating resolvers that implement this mechanism MUST
   perform validation of responses in accordance with the DNSSEC
   response validation specification [RFC4035].

A exhaustive compliance report would run to a couple of thousand tests without doing a DNSSEC compliance report due to the combinatorial nature of this draft.

You would need validate as secure zone, a validate as bogus zone, a validate as insecure w/ signatures, a validate as insecure w/o signatures.  You then for all of these need zones with and without A and AAAA records at the test names where without includes both NODATA and NXDOMAIN.  You then need to multiply that by servers configured to validate and those configured not to validate.  Then you need to multiply this by having the functionality enabled or disabled.  You then need to do a test for each of the conditions in the list of conditions that must be met for the modified responses to be returned.  You also need to do that where the label looked up after a CNAME and a DNAME.

We skipped some of these tests when we built our system tests by I believe we hit enough of them to be happy that the code is operating correctly.

S:rootkeysentinel:Mon May  7 17:55:35 UTC 2018
T:rootkeysentinel:1:A
A:rootkeysentinel:System test rootkeysentinel
I:rootkeysentinel:PORTRANGE:11300 - 11399
I:rootkeysentinel:get test ids (1)
I:rootkeysentinel:test id: oldid=35058 (configured)
I:rootkeysentinel:test id: newid=36058 (not configured)
I:rootkeysentinel:test id: badid=42835
I:rootkeysentinel:check authoritative server (expect NOERROR) (2)
I:rootkeysentinel:check test zone resolves with 'root-key-sentinel yes;'
I:rootkeysentinel:  (expect NOERROR) (3)
I:rootkeysentinel:check root-key-sentinel-is-ta with old ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NOERROR) (4)
I:rootkeysentinel:check root-key-sentinel-not-ta with old ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect SERVFAIL) (5)
I:rootkeysentinel:check root-key-sentinel-not-ta with old ta, CD=1 and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NOERROR) (6)
I:rootkeysentinel:check root-key-sentinel-is-ta with new ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect SERVFAIL) (7)
I:rootkeysentinel:check root-key-sentinel-is-ta with new ta, CD=1 and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NOERROR) (8)
I:rootkeysentinel:check root-key-sentinel-not-ta with new ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NOERROR) (9)
I:rootkeysentinel:check root-key-sentinel-is-ta with bad ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect SERVFAIL) (10)
I:rootkeysentinel:check root-key-sentinel-is-ta with bad ta, CD=1 and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NXDOMAIN) (11)
I:rootkeysentinel:check root-key-sentinel-not-ta with bad ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NXDOMAIN) (12)
I:rootkeysentinel:check root-key-sentinel-is-ta with out-of-range ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NXDOMAIN) (13)
I:rootkeysentinel:check root-key-sentinel-not-ta with out-of-range ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NXDOMAIN) (14)
I:rootkeysentinel:check root-key-sentinel-is-ta with no-zero-pad ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NXDOMAIN) (15)
I:rootkeysentinel:check root-key-sentinel-not-ta with no-zero-pad ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NXDOMAIN) (16)
I:rootkeysentinel:check CNAME to root-key-sentinel-is-ta with old ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NOERROR) (17)
I:rootkeysentinel:check CNAME to root-key-sentinel-not-ta with old ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NOERROR) (18)
I:rootkeysentinel:check CNAME to root-key-sentinel-is-ta with new ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NOERROR) (19)
I:rootkeysentinel:check CNAME to root-key-sentinel-not-ta with new ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NOERROR) (20)
I:rootkeysentinel:check CNAME to root-key-sentinel-is-ta with bad ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NXDOMAIN) (21)
I:rootkeysentinel:check CNAME to root-key-sentinel-not-ta with bad ta and
I:rootkeysentinel:  'root-key-sentinel yes;' (expect NXDOMAIN) (22)
I:rootkeysentinel:check test zone resolves with 'root-key-sentinel no;'
I:rootkeysentinel:  (expect NOERROR) (23)
I:rootkeysentinel:check root-key-sentinel-is-ta with old ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NOERROR) (24)
I:rootkeysentinel:check root-key-sentinel-not-ta with old ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NOERROR) (25)
I:rootkeysentinel:check root-key-sentinel-is-ta with new ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NOERROR) (26)
I:rootkeysentinel:check root-key-sentinel-not-ta with new ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NOERROR) (27)
I:rootkeysentinel:check root-key-sentinel-is-ta with bad ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NXDOMAIN) (28)
I:rootkeysentinel:check root-key-sentinel-not-ta with bad ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NXDOMAIN) (29)
I:rootkeysentinel:check root-key-sentinel-is-ta with out-of-range ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NXDOMAIN) (30)
I:rootkeysentinel:check root-key-sentinel-not-ta with out-of-range ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NXDOMAIN) (31)
I:rootkeysentinel:check root-key-sentinel-is-ta with no-zero-pad ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NXDOMAIN) (32)
I:rootkeysentinel:check root-key-sentinel-not-ta with no-zero-pad ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NXDOMAIN) (33)
I:rootkeysentinel:check CNAME to root-key-sentinel-is-ta with old ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NOERROR) (34)
I:rootkeysentinel:check CNAME to root-key-sentinel-not-ta with old ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NOERROR) (35)
I:rootkeysentinel:check CNAME to root-key-sentinel-is-ta with new ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NOERROR) (36)
I:rootkeysentinel:check CNAME to root-key-sentinel-not-ta with new ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NOERROR) (37)
I:rootkeysentinel:check CNAME to root-key-sentinel-is-ta with bad ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NXDOMAIN) (38)
I:rootkeysentinel:check CNAME to root-key-sentinel-not-ta with bad ta and
I:rootkeysentinel:  'root-key-sentinel no;' (expect NXDOMAIN) (39)
I:rootkeysentinel:exit status: 0
R:rootkeysentinel:PASS
E:rootkeysentinel:Mon May  7 17:55:38 UTC 2018

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

---

From: Job Snijders <[email-masked]>
Date: Tue, 8 May 2018 08:49:04 +0000

On Tue, May 08, 2018 at 11:05:50AM +1000, Mark Andrews wrote:
> > impressed by the 'Implementation Experience' section. Is it somehow
> > hard to write an implementation report that describes which
> > implementations comply with the BCP 14 / RFC 8174 terms used in

Well, the current section on the implementations isn't much of either,
it is very sparse. This working group should try to raise the bar for
RFC publication, not explore what the bare minimum is. 

I've used this example before: what I was hoping for is reports that
allude to the BCP14 terms and implementation's compliance similar to
what is done here: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations
Overviews like these are easy to consume for humans, and are derived
from extensive tests like the one you showed below.

I'd like to note that describing people's intention to implement in a
section called 'Implementation experience' of course doesn't add much
value. :-)

> To actually do a full compliance report for this draft it would
> require including a complete DNSSEC compliance report and in turn a
> complete STD 13 compliance report to meet this “MUST”.
>
> A exhaustive compliance report would run to a couple of thousand tests
> without doing a DNSSEC compliance report due to the combinatorial
> nature of this draft.
> 
> You would need validate as secure zone, a validate as bogus zone, a
> validate as insecure w/ signatures, a validate as insecure w/o
> signatures.  You then for all of these need zones with and without A
> and AAAA records at the test names where without includes both NODATA
> and NXDOMAIN.  You then need to multiply that by servers configured to
> validate and those configured not to validate.  Then you need to
> multiply this by having the functionality enabled or disabled.  You
> then need to do a test for each of the conditions in the list of
> conditions that must be met for the modified responses to be returned.
> You also need to do that where the label looked up after a CNAME and a
> DNAME.
> 
> We skipped some of these tests when we built our system tests by I
> believe we hit enough of them to be happy that the code is operating
> correctly.

Yes, I think you are touching upon the core of the issue. Discussing
_how_ to test a specification is exactly the type of discussion to be
held in this working group.

Its commonly accepted that even seemingly simple specifications may be
stringing together a number of complex features. Extensive testing and
demonstrations of such testing are a necessity to be able to claim
'running code and rough consensus'.

> [snip]

Thanks for sharing this!

So, the current status is that there is no longer zero, but now a single
implementation of draft-ietf-dnsop-kskroll-sentinel-12?
I see progress, but not last call material.

Kind regards,

Job

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 08 May 2018 11:11:32 +0200

On 24 Apr 2018, at 15:02, Ondřej Surý wrote:

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

Nobody is changing the rules (yet - but we can dream!); some people are 
just being more vocal about the real need for implementation experience.

> We need to have a discussion on the mechanisms that would allow 
> implementors to know when to start the implementation of existing 
> draft.

I don’t think what we need here is more ‘procedure’. Either a 
draft manages to get (at least one) implementer involved early - or the 
draft is most likely not worth pursuing.

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

It makes little sense to call a protocol change ‘fully baked’ if 
nobody has checked that implementation is even possible.

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

The costs are the very best reason to demand implementation experience 
before calling something ‘fully baked’. If a draft has real merit, 
somebody will invest time/money. If it does not have merit, nobody will 
implement, and the draft will die the death it deserves. In other words, 
a draft needs to put its money where its mouth is. This way, drafts that 
actually help operations (this is dnsOP, after all) will get the 
attention they need, while other drafts may wither away - and that’s a 
good thing.

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

---

From: Joao Damas <[email-masked]>
Date: Wed, 9 May 2018 09:39:56 +0200

Hi Job,

While I do agree with you that having implementations early on is a very desirable requirement, though I would disagree with making it a hard requirement (see the case of aggressive negative caching and how it unfolded as an example), for any new idea brought to the IETF I would like to point out a couple of things here:

- there is an established way for drafts to progress to RFCs and within the RFC levels. The progression from proposed to full Standard absolutely requires implementations (plural)
- the issue is not specific to any give wg, it is an IETF-wide issue and so the right place for discussion of improving this aspect of standards development is the IETF list rather any specific wg list
- in the specific case in the subject, there is funding available to support final implementation of this idea on three code bases. This won’t be released until we are past a successful last-call (because that’s how it works) and so stalling this specific draft on behalf of a way more general idea and discussion is actually having the opposite effect of what the discussion’s goals are. It is delaying final implementation.

Just my 2 cents

Joao

> On 8 May 2018, at 10:49, Job Snijders <[email-masked]> wrote:
>

---

From: Job Snijders <[email-masked]>
Date: Wed, 9 May 2018 14:56:18 +0200

Dear Joao,

On Wed, May 09, 2018 at 09:39:56AM +0200, Joao Damas wrote:
> While I do agree with you that having implementations early on is a
> very desirable requirement, though I would disagree with making it a
> hard requirement (see the case of aggressive negative caching and how
> it unfolded as an example), for any new idea brought to the IETF I
> would like to point out a couple of things here:
> 
> - there is an established way for drafts to progress to RFCs and
>   within the RFC levels. The progression from proposed to full Standard
>   absolutely requires implementations (plural)

>From a rhetoric perspective you are quite creative in making a
_seemingly_ reasonable point: "why don't we kick the can down the road
and require implementations on the 'proposed standard' -> 'internet
standard' barrier?". But in my opinion you are misrepresenting the
'established way', this is reason for concern. The IETF TOA is a
foundational document https://www.ietf.org/tao.html, let's look at
section "A.5 Documents": 

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

Now let's look at https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-12
and in the upper left corner we see: "Intended status: Standards Track".

Publishing draft-ietf-dnsop-kskroll-sentinel as RFC on the Standards
Track - without implementations - is, plainly said, not very IETF-like.
But I'm happy to observe that the feedback received during WGLC was
taken serious and at least one implementer got to work, with indications
that more will follow.

> - the issue is not specific to any give wg, it is an IETF-wide issue
>   and so the right place for discussion of improving this aspect of
>   standards development is the IETF list rather any specific wg list

You seem to be attempting to move the elephant in the room to a
different room (generalizing the issue to an IETF wide scope), this
distracts from the issue at hand. Bert Hubert's talk about the "DNS
Camel" should have made it clear to anyone that DNSOP itself has a
problem. Each working group has to come up with strategies to maximize
the quality of their publications; in the case of DNSOP one of the
aspects of the solution is fairly obvious: require running code. This is
not an IETF-wide issue.

The IETF norm is to demonstrate interoperable independent
implementations, and if you'd like to argue there should be an exception
for the DNSOP working group, the onus is on you to take that discussion
to the IETF list.

> - in the specific case in the subject, there is funding available to
>   support final implementation of this idea on three code bases. This
>   won’t be released until we are past a successful last-call (because
>   that’s how it works) and so stalling this specific draft on behalf of
>   a way more general idea and discussion is actually having the opposite
>   effect of what the discussion’s goals are. It is delaying final
>   implementation.

You may be holding the argument upside down: not having implementations
delays having a high quality protocol specification, which delays RFC
publication, which (in the diffusion of innovations theory) delays the
early & late majority. When not even "innovators" and "early adaptors"
can get behind a given draft, that draft is already in trouble.

There is no need to _release_ said implementations to the public. The
implementers are right to not publish releases containing features that
have not yet been standardized.

A common approach is to have implementations sit on feature/beta
branches, so that you can demonstrate that there is interopability, to
have discussion about how to test & validate that the implementation
confirms to the protocol specification. Implementer feedback is crucial
in constructing a protocol specification. If there are zero
implementations of a concept a lot of the discussion about that concept
is merely theoretical.

This is not a chicken-egg situation. If someone believes this draft is
good and serves a purpose benefical to the Internet community, they will
attempt to implement the draft and during that development process
feedback is collected which the working group can consider to either
improver wording, remove non-essential parts, or re-architect the whole
thing.

Kind regards,

Job

---

From: Benno Overeinder <[email-masked]>
Date: Wed, 9 May 2018 15:12:32 +0200

Hi all,

(Speaking as implementer/NLnet Labs.)

To update all readers of this thread.

> taken serious and at least one implementer got to work, with indications

There are now 2 implementations of kskroll-sentinel:
1) peer-reviewed and merged in the BIND master branch;
2) released with Unbound 1.7.1 last week.

(And the draft mentions the implemention early versions of this
technique into the Knot resolver.)

Implementation reports/observations for BIND and Unbound have been sent
to the mailing list.

-- Benno

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

---

From: Benno Overeinder <[email-masked]>
Date: Wed, 9 May 2018 15:34:13 +0200

To followup on myself, and was dropped with quoting email.

> Implementation reports/observations for BIND and Unbound have been sent

For the future, if the DNSOP working group likes to see an
implementation report in a more structured manner, e.g. following the
RFC 2119 terms for compliance, please let me know.

Of course, we are not volunteering to write extensive reports, but a set
of minimal considerations could give guidance.

-- Benno

---

From: Joe Abley <[email-masked]>
Date: Wed, 9 May 2018 09:41:04 -0400

Hi Benno,

> Implementation reports/observations for BIND and Unbound have been sent

That's great.

To the earlier question (the WGLC or WGLCish one) I have sympathy with what Job is saying, but I think we should be pragmatic and not pick on the one DNS extension that is actually seeing coordinated funding, implementation and testing because of problems that have been observed with entirely different extensions whose track record is not so good.

Perhaps an acceptable compromise would be to expand slightly on the implementation reports from -12 (which I tend to agree look a bit like placeholders) and expand them to include details of:

 - specific revisions of code bases, and whether they were released, public and private
 - revisions of code bases (with similar detail) that exhibited interestingly different behaviour from that described in -12

For example, the use of different labels in earlier revisions of the draft seems worth mentioning to the extent that it's possible some code based on those earlier revisions is or has been running, and examples of those labels might well show up in historical or future data sets.

With the observed high level of engagement from three major vendors on this it doesn't seem like fleshing out that section would take very long, and if it helped improve consensus on pushing the doc towards the IESG (which I am in favour of) it might be a good investment in time. I realise it's only a snapshot in time, but really so is a release.

(Draft is good though, and in my opinion it could be written up and sent to the IESG right now. It still has to pass the IESG's scrutiny and an IETF-wide last call though, and I think the suggestions above if followed could only oil the tracks through those processes.)

Joe

---

From: Benno Overeinder <[email-masked]>
Date: Wed, 9 May 2018 15:49:25 +0200

Reacting on the "when to implement" part of the subject, and speaking
for NLnet Labs.

On 08/05/2018 11:11, Peter van Dijk wrote:
> It makes little sense to call a protocol change ‘fully baked’ if nobody
> has checked that implementation is even possible.

I think there is a sweet point when developers start to think of
implementing a draft.  Not necessarily WGLC, but a stable document is
preferred with us at NLnet Labs.  (We indicated this also on the mic in
the Prague DNSOP WG meeting (or Singapore?) for the kskroll-sentinel draft.)

As Ralph Dolmans mentioned in his email on the list (specifically for
the kskroll-sentinel draft):
"We need a somewhat stable specification before we make code that will
be used in the real world to prevent pollution and in this case would
make it even harder to do proper measurements."

Above is specific for the kskroll-sentinel draft of course, and for
other drafts this point for adoption to get a (prototype) implementation
can be earlier or later.

-- Benno

---

From: Job Snijders <[email-masked]>
Date: Thu, 17 May 2018 11:29:45 +0000

> requiring multiple independent queries to infer state has its downsides.

Do the authors agree with the above observation? If so, we can work to
produce text.

Kind regards,

Job

---

From: Joao Damas <[email-masked]>
Date: Thu, 17 May 2018 15:26:40 +0200

> On 17 May 2018, at 13:29, Job Snijders <[email-masked]> wrote:
> 
> Do the authors agree with the above observation?

No, not really, at least in my case. What you are saying is that an incoherent system behaves in inconsistent manners (a service exposes itself to the outside as a homogeneous system but doesn’t behave that way). In that case the problem is not one or more queries, the problem is an internally misconfigured system.
If you are referring to the case when a client has several resolvers that I can try, I think what we can do is stress even more is that this measures the client’s resolver environment, not aspects of particular resolvers. We are after finding out whether a user can get a successful resolution in their configure environment.

Joao

---

From: Warren Kumari <[email-masked]>
Date: Wed, 23 May 2018 14:39:40 -0400

On Thu, May 17, 2018 at 9:27 AM Joao Damas <[email-masked]> wrote:

> No, not really, at least in my case. What you are saying is that an
> incoherent system behaves in inconsistent manners (a service exposes itself
> to the outside as a homogeneous system but doesn’t behave that way). In
> that case the problem is not one or more queries, the problem is an
> internally misconfigured system.
> If you are referring to the case when a client has several resolvers that
> I can try, I think what we can do is stress even more is that this measures
> the client’s resolver environment, not aspects of particular resolvers. We
> are after finding out whether a user can get a successful resolution in
> their configure environment.
>
> ​Just so the WG knows, the authors (myself in particular) had some
productive discussions with Job at the RIPE meeting in Marseille.
​
As a reminder, this mechanism is designed to measure the *user* impact of
the KSK roll - this means that querying the first resolver in e.g:
resolve.conf, getting SERVFAIL and then failing over to the second (or
third or n-th) until a response is received is fine, and expected.

The document currently contains:
"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."
and
"The sentinel test described in this document determines whether a **user's
browser or operating system** looking up the special names that are used in
this protocol would be able to validate using the root KSK indicated by the
special names. The protocol uses the DNS SERVFAIL response code (RCODE 2)
for this purpose because that is the response code that is returned by
resolvers when DNSSEC validation fails. If a browser or operating system
has multiple resolvers configured, and those resolvers have different
properties (for example, one performs DNSSEC validation and one does not),
the sentinel mechanism **might search among the different resolvers**, or
might not, depending on how the browser or operating system is configured.
Note that the sentinel mechanism described here measures a very different
(and likely more useful) metric than RFC8145.  RFC 8145 relies on resolvers
reporting towards the root servers a list of locally cached trust anchors
for the root zone. Those reports can be used to infer how many resolvers
may be impacted by a KSK roll, but not what the user impact of the KSK roll
will be." (emphasis added)
and
"Note that a slew of other issues can also cause SERVFAIL responses, **and
so the sentinel processing may sometimes result in incorrect
conclusions.**" (emphasis added).

An example of a case where an incorrect conclusion could occur is if the
client is using an Anycast recursive resolver (e.g: 8.8.8.8) and some of
the backends of that Anycast network have only the old key, and some have
the new key, and ECMP directs you to different backend. Another exmaple is
if the resolver learns the new key *during* a clients testing. To me these
feel like pathological cases, and are covered by "may sometimes result in
incorrect conclusions".
Does the WG feel that this is sufficient, or would it like additional text?
If so, can you propose some?
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: 神明達哉 <[email-masked]>
Date: Fri, 25 May 2018 10:15:43 -0700

At Wed, 23 May 2018 14:39:40 -0400,
Warren Kumari <[email-masked]> wrote:

> Just so the WG knows, the authors (myself in particular) had some

> The document currently contains:
[...]

> If so, can you propose some?

I don't have a strong opinion on the main question (I'm fine with the
current version of this draft regarding this matter).  But I'd like to
point out that the above quoted text regarding SERVFAIL and "incorrect
conclusions" (which I think I proposed before) mainly concerned cases
where SERVFAIL is returned for a different reason than the one
described in kskroll-sentinel such as query timeout (note the "other
issues" in the text).  Likewise, "incorrect conclusions" mainly
intended such cases as deducing Vnew/Vold/Vleg labels while the
corresponding SERVFAIL was returned for a different reason.  I think
it's slightly different from a type of "incorrect conclusions"
discussed in this thread, since an incorrect conclusion is reached not
because SERVFAIL is returned for a different reason but because it's
inconsistent which server sends which.

Again, I'm fine with the current text anyway.  But if we want to tweak
the text in response to the concern in this thread while preserving
the original text quoted above, then we might say something like:

OLD
    [...] Note that a slew of other issues can also cause SERVFAIL
    responses, and so the sentinel processing may sometimes result in
    incorrect conclusions.

NEW
    [...] Note that a slew of other issues can also cause SERVFAIL
    responses and DNS transactions are not always reliable or
    consistent, and so the sentinel processing may sometimes result in
    incorrect conclusions.

--
JINMEI, Tatuya