Subject: [DNSOP] Edns opts vs qname

From: Mark Andrews <[email-masked]>
Date: Thu, 7 Apr 2016 20:48:43 -0300

Warren. In both cases receiving a query with either a option or a qname encoding ids it is a indication that the IP address or the clients behind the IP address have the trust anchor configured.  You may receive a option without the recursive server actually validating.

As far as I can see both options provide the same information.

Mark

---

From: Shane Kerr <[email-masked]>
Date: Wed, 13 Apr 2016 15:54:08 +0200

Mark,

At 2016-04-07 20:48:43 -0300
Mark Andrews <[email-masked]> wrote:

> Warren. In both cases receiving a query with either a option or a
> qname encoding ids it is a indication that the IP address or the
> clients behind the IP address have the trust anchor configured.  You
> may receive a option without the recursive server actually validating.
> 

Actually using a QNAME does provide more information, since it can
reveal validators behind a resolver with different trust anchors.

While the QNAME approach does feel a bit like a hack, I have to admit
that it probably is slightly better. I can't even think of useful
information that having both approaches would add....

(I do think that using human-readable key tags in the QNAME approach
makes sense, as someone suggested in the WG session. Because I am a
human, and don't care about 1 or 2 extra bytes for these relatively rare
queries, but I do care about being able to check logs without
running them through my secret decoder ring...)

Cheers,

--
Shane

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Apr 2016 10:37:52 -0400 (EDT)

> information that having both approaches would add....

Yes, and if you use _trustanchor instead of _ta, you could also use
capitalization on each resolver that understood the specialness of
this query. So each hop that understands it uppercases one character.

So you can tell that _TRustanchor at least got forwarded twice. Not
sure how you would signal if the different forwards had different
keys though.

Might interact badly with 0x20 :)

Paul

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 13 Apr 2016 15:53:43 +0000

> On Apr 13, 2016, at 6:54 AM, Shane Kerr <[email-masked]> wrote:
> 
> Mark,
> 

Shane,

Can you explain your reasoning some more, or what you mean by different?

Do you mean a stub and its recursive having different trust anchors?  Or do
you mean two different stubs with different trust anchors?

As I see it both approaches reveal multiple trust anchors behind a single IP,
but the EDNS0 approach can reveal the "order" of trust anchors.

> information that having both approaches would add....

There is one difference.  With the EDNS0 approach (as written) if you have
a validating stub (or other client) and a validating recursive, then you'd
get two sets of key tags in one message.  So this would tell you that there
are two validators in that resolution chain.

With the QNAME approach the two validators would send independent queries
and they would not be so strongly linked.

Having said that, I don't think this difference is important enough to
justify EDNS0 over QNAME.  That is, its hard for me to imagine that the
information provided by this difference would affect the go/no-go progress
of a rollover.

> running them through my secret decoder ring...)

I don't have a strong opinion about hex/decimal, human readable, etc. 

I do feel strongly that the QNAME approach should have a lot of "signal"
in order to separate real data from random noise.  i.e., the signal could
take the form of punctuation, keywords, or check digit.

DW

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Apr 2016 06:56:32 +1000

In message <[email-masked]>, "Wessels, Duane" writes:
> Do you mean a stub and its recursive having different trust anchors?  Or
> do you mean two different stubs with different trust anchors?
>
> As I see it both approaches reveal multiple trust anchors behind a single
> IP, but the EDNS0 approach can reveal the "order" of trust anchors.
>
>
> >
> get two sets of key tags in one message.  So this would tell you that
> there are two validators in that resolution chain.

No, you may get two sets and only when they differ.  You also need
to maintain a seperate cache just for these tag values.  Even if
you get multiple sets there is nothing that says the first must be
the resolvers just that all sets should be included.

> > running them through my secret decoder ring...)

I care about being able to fit more tags into a single label.  It
is only 63 octets which gives 14 hex tag values [(63 - 4) / 4] compared
with 10 when using decimals and a value seperator [(63 - 4 - 5) / 6 + 1]
or 11 if you just zero pad to width 5 and no seperator [(63 - 4) / 5].

> take the form of punctuation, keywords, or check digit.

So label length % 4 == 0 + strncasecmp(label, "_ta-", 4) == 0 + type
== NULL + suffix == zone name + label suffix is all hexdigits is
not enough to pull it out of a query stream?

strncasecmp(buf, "v=spf1", 6) + buf[6] == 0 || buf[6] == ' ' is
basically all that is used to pull out SPF records out of txt records
after collapsing the rdata into a single buffer.

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

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 13 Apr 2016 21:33:43 +0000

> On Apr 13, 2016, at 1:56 PM, Mark Andrews <[email-masked]> wrote:
> 
> 
> No, you may get two sets and only when they differ.

No, the -01 of the draft says:

   the recursive resolver
   SHOULD transmit the two Key Tag lists using separate instances of the
   edns-key-tag option code in the OPT meta-RR.

(It doesn't say they can be collapsed if identical)

>  You also need
> to maintain a seperate cache just for these tag values.  

I'm not sure where you get this idea.  The draft does not say that.

> Even if

True the draft does not specify ordering, but it easily could.

> or 11 if you just zero pad to width 5 and no seperator [(63 - 4) / 5].

Seems like plenty to me.  And the draft does say this:

   It is RECOMMENDED that implementations place reasonable limits on the
   number of Key Tags to include in the outgoing edns-key-tag option.

> not enough to pull it out of a query stream?

Actually I forgot that you proposed using QTYPE=NULL which I think is a 
good enough signal.  

DW

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Apr 2016 07:46:11 +1000

In message <[email-masked]>, "Wessels, Duane
" writes:
> >=20
> >=20
> > In message <[email-masked]>, "Wessels,=
>  Duane" writes:
> >>=20
> >>=20
> >>>=20
> >>=20
> >>=20
> >> There is one difference.  With the EDNS0 approach (as written) if you ha=
> ve
> >> a validating stub (or other client) and a validating recursive, then you=
> 'd
> >=20

		When a validating recursive resolver receives a query
   that includes the edns-key-tag option with a Key Tag list that
   differs from its own, it SHOULD forward both the client's Key Tag
   list as well as its own. 

Note the word "differs".

> > to maintain a seperate cache just for these tag values. =20
> 

In practice you will need to maintain a cache or the down stream
TAG list will statistically never make it into the upstream query.

> >=20
> >> With the QNAME approach the two validators would send independent querie=
> s
> >>=20
> >> information provided by this difference would affect the go/no-go progre=
> ss
> >> of a rollover.
> >>=20
> >>> human, and don't care about 1 or 2 extra bytes for these relatively rar=
> e
> >=20

> >=20
> >>=20
> >> in order to separate real data from random noise.  i.e., the signal coul=
> d
> >=20
> > So label length % 4 =3D=3D 0 + strncasecmp(label, "_ta-", 4) =3D=3D 0 + t=
> ype
> > =3D=3D NULL + suffix =3D=3D zone name + label suffix is all hexdigits is
> Actually I forgot that you proposed using QTYPE=3DNULL which I think is a=20
> good enough signal. =20
> 
> DW

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Apr 2016 10:35:45 +1000

Also note we can do both _ta-XXXX/NULL and a EDNS option with
_ta-XXXX/NULL being the short term solution and the EDNS option
being a long term solution.  Aggressive negative caching is potentially
going to have a impact on _ta-XXXX/NULL as all the _ta-XXXX labels
are going to be in the same NSEC range.

	<zone> NSEC <first-name>.<zone> ...

		or 

	*.<zone> NSEC <second-name>.<zone> ...

Note a zone operator can defeat the aggressive negative caching by
adding records with _ta-xxxx ownernames for the known tags sets.

For a single algorithm KSK roll this would be where xxxx is the old
tag and yyyy the new tag.

	_ta-xxxx.<zone>
	_ta-xxxxyyyy.<zone> or _ta-yyyyxxxx
	_ta-yyyy.<zone>

Note this is also a example of the negative effects of aggressive
negative caching.

Mark

---

From: Shane Kerr <[email-masked]>
Date: Tue, 19 Apr 2016 20:38:47 +0200

Duane,

Apologies for the late reply.

At 2016-04-13 15:53:43 +0000

> you mean two different stubs with different trust anchors?

I meant the first. I thought that the stub's trust anchor will be
revealed by QNAME, but not by EDNS. Looking at the draft I see that I
was wrong. :( 

> but the EDNS0 approach can reveal the "order" of trust anchors.

Yes, this is true. I don't know if this is useful information, but it
actually is more information! :)

> information provided by this difference would affect the go/no-go progress

Agreed.

> take the form of punctuation, keywords, or check digit.

Possibly a HMAC of the trust anchors used, with the string "Whoops, we
should have done this in 2010" as the secret key?

And then also the human-readable secret key, so I can read it. ;)

Cheers,

--
Shane