Subject: [DNSOP] A conversational description of sentinel.

From: Warren Kumari <[email-masked]>
Date: Sun, 14 Jan 2018 20:51:56 -0500

Hi all,

I had a conversation with a friend earlier today, who had carefully read
the document
​ (https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/)​
, but had not managed to understand it at all
​.​
​Since
 this friend is bright, and really understand
​s​
DNS, I figured that the document doesn't do as good a job explaining how
this would be used in practice as it should. Sometimes it is easier to
explain things in an informal manner, and so here is a (hopefully better)
description of draft-ietf-dnsop-kskroll-sentinel).

2 things seemed to be causing confusion:
1: The only "magic" that happens is in validating recursive resolvers,
right before they send the response to a query
​. T​
here is no magic / change needed in authoritative servers, stubs, or
anywhere else.

2: Anyone who wants to provide a service like this
​(see below) ​
can - you don't need to be in any special location in the DNS tree to do
this.

The (new) rules:
A: If the qname starts with _is-ta, and the included keyid is *NOT* in the
trust store, the resolver changes the answer to a SERVFAIL (otherwise
things proceed normally).
B: If the qname starts with _not-ta and the included keyid *IS* in the
trust store, the resolver changes the answer to a SERVFAIL (otherwise
things proceed normally).

(There is some pseudo-code below, but it makes this look much more complex
(and I dislike pseudo-code - it's hard to guess at the level of abstraction
to use!).

​Let's pretend ​
I'm the operator of example.com, and I'd like to help users know if the
resolvers that they use will survive the new keyroll (with key id 12345).

I publish this in my a zone:

_is-ta-12345.example.com.   600     IN      A       192.0.2.1
_is-ta-12345.example.com.   600     IN     RRSIG   A <valid signature>

_not-ta-12345.example.com.   600     IN      A       192.0.2.2
_not-ta-12345.example.com.   600     IN     RRSIG   A <valid signature>

invalid.example.com. 600     IN      A       192.0.2.3
invalid.example.com. 600     IN      RRSIG A <0x0000 (an invalid signature)>

​I also run 3 webservers:
​
192.0.2.1
​   -- a picture of a cute kitten
192.0.2.
​2   -- a picture of a puppy
192.0.2.
​3  -- a picture of a fish.​
​
​

I now tell users to please browse to www.example.com, where I have a
webpage which includes the following links: http://_is-ta-12345.example.com/
​(​
kitten) , http://_not-ta-12345.example.com/ (puppy),
http://invalid.example.com/ (fish).
​The pictures the user can see tells them if they will survive the rollover.
​

The user can be in one of 4 classes, depending on which animals they see:

1: The user sees a Fish, a Kitten and a Puppy  -- they fetched all the URLs
(including http://invalid.example.com/). If they see a Fish, they are not
using a validating resolver and so will survive the keyroll (it actually
means that at least 1 of their resolvers is not validating). The user is
happy and goes to have ice-cream (nonV).

2: The user sees a only Kitten and a Puppy (they fetched http://_
is-ta-12345.example.com/ and http://_not-ta-12345.example.com/, but not
http://invalid.example.com/.) This means that they are using a
​legacy ​
validating resolver
​ (it ​
doesn't implement this mechanism
​)​
.
​They cannot tell, and this test doesn't tell them anything
 (Vleg).

3: They see only a Kitten (they fetched http://_is-ta-12345.example.com/,
not http://_not-ta-12345.example.com/, and not http://invalid.example.com/).
The user is behind a validating resolver which implements this mechanism,
and knows about the new key. They are happy, and go have ice-cream (Vnew).

4: The user sees only a Puppy (they did not fetch http://_
is-ta-12345.example.com/, they did fetch http://_not-ta-12345.example.com/,
they did not fetch http://invalid.example.com). The user is behind a
validating resolver which implements this mechanism, but does NOT have the
new key). The user is sad, and calls their ISP to complain (and has cold
porridge for dinner) (Vold).

+-------------+----------+-----------+------------+
| Type\Query  |  _is-ta  |  _not-ta  |  invalid   |
+-------------+----------+-----------+------------+
| Vnew        |    A     |  SERVFAIL |  SERVFAIL  |
| Vold        | SERVFAIL |      A    |  SERVFAIL  |
| Vleg        |    A     |      A    |  SERVFAIL  |
| nonV        |    A     |      A    |     A      |
+-------------+----------+-----------+------------+

​In the real world, the user will not be expected to figure this out from
looking at pictures --  a bit of JS on www.example.com will do the 3
fetches and report "You'll be just fine", "You will have issues, call your
ISP and get them to install the new key" or "Sorry, cannot tell.​ Call your
ISP and ask them to upgrade to a resolver which does this!". There will
also likely be some Geoffvertisement which will do this on a large scale
and report back.

​Hopefully this clears things up some -- the only code change needs to
happen on recursive resolvers, the A record returned is unmolested (so that
if can be used for something) and the only action is to make some VALID
answers INVALID (A (or whatever) -> SERVFAIL).

W​

​Pseudo-code:​

func extract_ta(string):
   # Extracts the queried trust anchor (a set of digits) from a qname.
   # E.g: "perl -pne "s/_.*-ta-(\d*)\..*/\1/" (_is-ta-55555.foo -> 55555)
   return (numbers)

<normal processing>
...
queried_ta = extract_ta (qname);
if qname startswith("_is-ta-"):
   if queried_ta is in trust_store:
      return;
   else:
      return SERVFAIL

if qname startswith("_not-ta-"):
   if queried_ta is in trust_store:
      return SERVFAIL;
   else:
      return;
---

-- 
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: Joe Abley <[email-masked]>
Date: Sun, 14 Jan 2018 21:08:11 -0500

Hi Warren,

On 14 Jan 2018, at 20:51, Warren Kumari <[email-masked]> wrote:

> I had a conversation with a friend earlier today, who had carefully read the document​ (https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/)​, but had not managed to understand it at all​.​ ​Since this friend is bright, and really understand​s​ DNS, I figured that the document doesn't do as good a job explaining how this would be used in practice as it should. Sometimes it is easier to explain things in an informal manner, and so here is a (hopefully better) description of draft-ietf-dnsop-kskroll-sentinel).
> 

I think the document would benefit from some explicit advice for zone administrators and some explicit requirements for validating resolvers, and having them both separated into obviously-distinct sections. An example of a specific experiment would also be useful.

A careful review of some of the terminology would also probably help. At the moment the text contains contains phrases like "query name that is signed with a DNSEC signature" that I think adds to the ambiguity and confusion (query names are not signed; RRSets are signed, and the corresponding part of an RRSet to a QNAME in the sense that I think is intended is an owner name).

I definitely agree that even with some prior idea of what this mechanism is trying to do (and some prior exposure to the geoffsperiments that provide context) this draft is quite hard to understand. The small handful of slides I saw Geoff present about this seemed far easier to understand than the draft, in fact.

I would be happy to suggest text if that seems useful, but I haven't done that here since it seems likely that other text changes are already in the pipeline, based on reviews on this list so far.

Joe

---

From: william manning <[email-masked]>
Date: Mon, 15 Jan 2018 04:22:40 -0800

your wrote,: "​In the real world, the user will not be expected to figure
this out [...] --  a bit of JS on www.example.com will do the 3 fetches and
report "You'll be just fine", "You will have issues, call your ISP and get
them to install the new key" or "Sorry, cannot tell.​ Call your ISP and ask
them to upgrade to a resolver which does this!"."

I think its a bit  sad that for the DNS to work, one now needs to run
http[s] and JS.   So much for stand alone protocols. Now if you could show
how this works without JS or HTTP, then we might be getting somewhere.

/Wm

On Sun, Jan 14, 2018 at 5:51 PM, Warren Kumari <[email-masked]> wrote:

> 1: The user sees a Fish, a Kitten and a Puppy  -- they fetched all the
> URLs (including http://invalid.example.com/). If they see a Fish, they
> are not using a validating resolver and so will survive the keyroll (it
> actually means that at least 1 of their resolvers is not validating). The
> user is happy and goes to have ice-cream (nonV).
>
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Joe Abley <[email-masked]>
Date: Mon, 15 Jan 2018 08:49:19 -0500

On 15 Jan 2018, at 07:22, KenM <[email-masked]> wrote:

> I think its a bit  sad that for the DNS to work, one now needs to run http[s] and JS.   So much for stand alone protocols. Now if you could show how this works without JS or HTTP, then we might be getting somewhere.

We could write the client test code in java or a tangle of perl libraries, or load custom software onto tiny, USB-powered computers and hand them out to literally tens of people that we meet in niche technical meetings around the world. Or use the preferred devops approach of wget | sh as root, although I'm not sure we should insist on that level of security.

Joe

---

From: Ralph Dolmans <[email-masked]>
Date: Mon, 15 Jan 2018 15:02:44 +0100

Hi Warren, all,

On 15-01-18 02:51, Warren Kumari wrote:
> The (new) rules:
> A: If the qname starts with _is-ta, and the included keyid is *NOT* in
> the trust store, the resolver changes the answer to a SERVFAIL
> (otherwise things proceed normally).

It is still not clear to me which trust anchor a validator should use
for the sentinel processing. Is that (1) the root trust anchor with
corresponding keyid, (2) the trust anchor with matching keyid for the
domain that is queried, so the example.com trust anchor in your example,
or (3) any trust anchor from the trust store with a matching keyid?

1. Does not require changes in the root zone and makes it possible for
anyone to create a root KSK test. It also means that this test can not
be used for any non-root trust anchor.
2. Requires changes in the root zone, but makes it possible to test the
trust anchor for any zone.
3. Reduces the usefulness of the data. You know that a trust anchor for
that keyid is configured, but you don't know for which zone. Given the
limited number of keyids this does not sound like a good option. A trust
anchor in the trust store with the keyid of the new root KSK does then
not imply that validation will work after the keyroll.

-- Ralph

---

From: Warren Kumari <[email-masked]>
Date: Mon, 15 Jan 2018 15:16:21 +0000

On Mon, Jan 15, 2018 at 7:22 AM william manning <[email-masked]>
wrote:

> this out [...] --  a bit of JS on www.example.com will do the 3 fetches
> and report "You'll be just fine", "You will have issues, call your ISP and
> get them to install the new key" or "Sorry, cannot tell.​ Call your ISP and
> ask them to upgrade to a resolver which does this!"."
>

% dig invalid.example.com
A: Did I get an answer (SERVFAIL isn't an answer)? I'm not validating.
Keyroll won't affect me.

% dig _is-ta-12345.example.com
% dig _not-ta-12345.example.com
B: Did I get an answer to both?  My resolvers haven't been upgraded, I
cannot tell what will happen.

C: Did I get an answer for _is-ta-12345.example.com and a SERVFAIL for _
not-ta-12345.example.com ? My resolver supports sentinal (is sentinent?!),
and has the new key. I'll be fine.

D: Did I get a SERFVAIL for _is-ta-12345.example.com and an answer for _
not-ta-12345.example.com ? My resolver supports sentinal, and does not have
the new key. I'll die during the rollover.

This works just fine without JS or HTTP -- but expecting users (which is
ultimatly what we are trying to measure) to do the above, and then report
that back somewhere is not really viable.

RFC8145 tried to measure using the DNS only -- but that only lets you know
what *resolvers* will be OK, which is fairly meaningless; I have a resolver
in my basement which only has the old key, but seeing as no users are
querying it, it it's nearly as important as my local ISP, whose resolver
services thousands of users.

If you have a better proposal, we are all ears...
W

>> the trust store, the resolver changes the answer to a SERVFAIL (otherwise
>> (There is some pseudo-code below, but it makes this look much more
>> complex (and I dislike pseudo-code - it's hard to guess at the level of
>> abstraction to use!).
>>
>>
>> ​Let's pretend ​
>> not http://_not-ta-12345.example.com/, and not
>> http://invalid.example.com/). The user is behind a validating resolver
>> which implements this mechanism, and knows about the new key. They are
>> happy, and go have ice-cream (Vnew).
>>
>> is-ta-12345.example.com/, they did fetch http://_
>> not-ta-12345.example.com/, they did not fetch http://invalid.example.com).
>> but does NOT have the new key). The user is sad, and calls their ISP to
>> complain (and has cold porridge for dinner) (Vold).
>>

---

From: Tony Finch <[email-masked]>
Date: Thu, 25 Jan 2018 15:10:24 +0000

(catching up on old messages)

> http://_is-ta-12345.example.com/

Isn't this going to cause problems with software that checks hostname
syntax?

Wouldn't it be better to use something like a double hyphen to avoid
collisions?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Shannon, Rockall: Northwest backing south later, 5 to 7, occasionally gale 8,
decreasing 4 for a time. Very rough or high, becoming rough or very rough.
Showers, rain later. Mainly good.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 25 Jan 2018 10:36:18 -0500

> Isn't this going to cause problems with software that checks hostname

Good catch; I stumbled into this on Monday when setting up an example...

BIND (for one) checks names with underscores, but only for A records:
$ ~/src/code/scripts/ddns.sh
> update add _tony.dnssec-example.com 600 IN A 127.0.0.1
check-names failed: bad owner '_tony.dnssec-example.com'
> update add _tony.dnssec-example.com 600 IN CNAME www.example.com
> ^c
$

For this reason, when setting up my toy example I used CNAMES:

$dig _is-ta-20236.dnssec-example.com
...
;; ANSWER SECTION:
_is-ta-20236.dnssec-example.com. 30 IN  CNAME   ron.kumari.net.
ron.kumari.net.         600     IN      A       204.194.23.4

There is a (very incomplete) example at http://www.dnssec-example.com/
-- I had created this for some slides, and so the code favors length /
clarity over prettiness.
Also, the "invalid" part test doesn't work yet, because, well, BIND
keeps resigning my "invalid.dnssec-example.com" record and making it
valid :-)

> Wouldn't it be better to use something like a double hyphen to avoid

Possibly, or using CNAMES. I (personally) liked the underscores as it
separated this from the rest of the namespace, but the double hyphen
also sounds like an interesting idea.
What does the WG think?

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: "Paul Hoffman" <[email-masked]>
Date: Thu, 25 Jan 2018 08:17:51 -0800

>> Isn't this going to cause problems with software that checks hostname

Yes. However, that software will only be on the authoritative server 
side, yes? If you're a researcher who wants to run a sentinel test, you 
can use authoritative server software that doesn't block that. For 
example, I'm pretty sure Geoff's software either does not block that or 
could be tweaked easily to not block.

> also sounds like an interesting idea.

Sentinel would be the first example of label-based special cases in 
resolver software. The special-case labels can be anything that would 
not ordinarily appear at the left. Using 
dcyen28c5wxcf95fcsxceexwwe1z-ta-12345.example.com works just as well, 
and would probably cause fewer implementers to make bad assumptions 
about the future. Underscores are already used for preventing those 
assumptions, but any unused string works.

--Paul Hoffman