Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

From: Geoff Huston <[email-masked]>
Date: Sun, 4 Mar 2018 09:32:00 +1100

Hi Duane,

> On 1 Mar 2018, at 9:45 am, Wessels, Duane <[email-masked]> wrote:
> 
> Thanks for the update.
> 
> IMO this document really needs a Privacy Considerations section and maybe also some additions to the Security Considerations.  Whereas the signals in 8145 are between the validator and the zone owner, this technique enables third parties (with either good or bad intentions) to learn something about the security configuration of recursive name servers.  Possibly all of them.

If one could direct queries directly at individual recursive resolvers then it may possible to determine some information about the behaviour of recursive resolvers, but with the use of forwarders it is sometimes challenging to determine if the observed behaviour is that of the recursive resolver or the target of the forwarder. However, to perform that task, its much more than a simple scripted get of a URL. At the user level it requires the use of code that allows DNS queries to be sent to recursive resolvers.

The sentinel changes the behaviour of a DNSSEC-validating resolver by making an otherwise validated response into a SERVFAIL signal depending on the exact query and the state of the trusted key stash in the validating resolver. However the intrinsic value of that information (that a resolver trusts a key whose hash matches a particular number) seems to me to be somewhat abstract. Section 5 of RFC4035 specifies that a trusted key must appear at the apex DNSKEY RRSET, so even if a) I know of a key pair where the public key part matches the hash value, and b) I can construct a DNS situation where this key is used to sign a RR, the key must still sit within a chain of trust. I guess that the knowledge that resolver X trusts a key with a hash value of Y does not leave me much the wiser in terms of exploitable knowledge about the (in)security of that resolver.

> 
> Similarly, I think the document could be more transparent and consistent about who is able to make the determinations.  For example it currently says:
> 
>   "allow an end user to determine the trusted key state"
> 
>   "allow a user to determine the state of their DNS resolution system"
> 
>   "allow us to infer a trust key state"
> 
>   "allow the client to determine the category"
> 
> I'd like to see at least in the abstract "...allows end users and third parties to determine…"

Aren’t we getting into issues of DNS privacy here rather than the sentinel per se? Its not as if the sentinel process calls for any change in the DNS query response mechanism. There is no forking off information to third parties in any form in this draft - the user agent asks a particular query form to its DNS resolvers and the user agent will get a response. As far as I can tell, in the same way that the DNS itself admits third parties to look over the shoulder of DNS transactions in every other DNS query and response, this is no different as far as I can tell.  And in the same way as various DNS privacy mechanisms make it harder for third parties to eavesdrop on user activity, this is no different, and the user agent can take the same measures to attempt to increase the eavesdropping degree of difficulty on sentinel queries as much as any other DNS query that the user agent may make.

It seems I must be missing something here that has triggered your concerns Duane - could you explain them in a little more details?

thanks,

    Geoff

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 5 Mar 2018 22:31:02 +0000

> On Mar 3, 2018, at 2:32 PM, Geoff Huston <[email-masked]> wrote:
> 
>  I guess that the knowledge that resolver X trusts a key with a hash value of Y does not leave me much the wiser in terms of exploitable knowledge about the (in)security of that resolver.

If there is a key or algorithm compromise for key Y then that seems like useful information to an attacker.

> It seems I must be missing something here that has triggered your concerns Duane - could you explain them in a little more details?

No, I wasn't thinking of eavesdropping.  I'm thinking whatever Geoff can do, a motivated nation state can just as easily do.  For example...

The country of Freedonia decides it doesn't trust the ICANN-controlled Internet and goes off and builds its own root server system and signs its version of the root zone with its own set of DNSSEC keys.  Persons and organizations operating in Freedonia are required to install this trust anchor and remove the IANA trust anchor.  kskroll sentinel provides a way for Freedonia to monitor compliance with this policy.  They can use known techniques (ads, embedded javascript, unique URL hostnames) to learn which keys are in the trust anchor set for resolvers/devices within (and even outside) its realm.

DW

---

From: Mark Andrews <[email-masked]>
Date: Tue, 6 Mar 2018 10:27:58 +1100

> On 6 Mar 2018, at 9:31 am, Wessels, Duane <[email-masked]> wrote:
> 
> 

And recursive servers will just be modified to lie to hide non compliance.  Also how do you prevent there being minor differences in the zone content which are identifiable?

> DW
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

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

---

From: Geoff Huston <[email-masked]>
Date: Tue, 6 Mar 2018 11:05:10 +1100

> If there is a key or algorithm compromise for key Y then that seems like useful information to an attacker.

Good point - thanks for pointing it out. There are many dangers in a compromised KSK DNSKEY when resolvers still trust the key, and the sentinel approach could be used. I don't think this is a show-stopper, but it is useful to be explicit about the risks here.

> The country of Freedonia decides it doesn't trust the ICANN-controlled Internet and goes off and builds its own root server system and signs its version of the root zone with its own set of DNSSEC…

I wonder if this is just a sentinel issue or a more generic issue? It seems like this information could be revealed in a number of ways, and it does not exclusively need a sentinel function in resolvers. For example, if researcher Duane sets up a test zone in Freedonia and sets up validly and invalidly signed domain names within the Freedonia name realm, then couldn’t a Ad-bsed large scale test reveal this information anyway without recourse to a sentinel? Endpoints outside Freedonia would presumably see two invalidly signed names, while folk within the realm would see the validly signed one and not the other. i.e. the sentinel approach would not be the only way to expose this information. 

So yes, this is a risk, but in this case its not a risk that is exclusively triggered by this sentinel behaviour, as it would be visible in a number of ways, as far as I can tell.

Geoff

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 6 Mar 2018 00:30:00 +0000

> On Mar 5, 2018, at 4:05 PM, Geoff Huston <[email-masked]> wrote:
> 
> For example, if researcher Duane sets up a test zone in Freedonia and sets up validly and invalidly signed domain names within the Freedonia name realm, then couldn’t a Ad-bsed large scale test reveal this information anyway without recourse to a sentinel? Endpoints outside Freedonia would presumably see two invalidly signed names, while folk within the realm would see the validly signed one and not the other. i.e. the sentinel approach would not be the only way to expose this information. 

I think its different.  The above can tell you whether certain names were resolvable (maybe even validatable?) but kskroll sentinel tells you that specific key tags are or are not present in the TA store even if those keys don't have "active" chains of trust.

DW

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 19 Mar 2018 17:26:48 +0100

> I think its different.  The above can tell you whether certain names were resolvable (maybe even validatable?) but kskroll sentinel tells you that specific key tags are or are not present in the TA…

Yes, the point of this RFC is to disclose information that we don't know
how to obtain without the RFC.  The question is whether the positive or
negative potential of this disclosure is larger (possibly in each
deployed instance separately).

TL;DR: altogether the risks known so far seem acceptable to me.  The
"leaked" information is noted in the "Security Considerations" section
(incl. third parties).  Of course, implementations might like to provide
a way to disable compliance to this RFC.

If a root key is compromised, this information does seem misusable to
simplify choosing targets for attacks.  Here it might be good that the
RFC is written to disclose only the root trust.  The RFC might
theoretically be amended to handle revoked keys in a special way - to
hide some parts of information that we don't need now, but such attempts
don't seem worth it (to me).  One reason is complexity, and the more
important one is that it will also be *useful* that people have a way to
test that their resolver correctly distrusts revoked root keys.  Note
that the good testability effects of this RFC apply even in regular
rollovers (without key compromise), so we can detect bad instances more
easily, and the negative effects only apply in the (unlikely) case of
root key compromise.  (It seems similar to usual
security-through-obscurity arguments.)

I suppose cases like Freedonians will need some extra patches or
configuration knobs, in case they want to hide their non-compliance
while appearing to follow the RFC.  That is, assuming the non-compliance
can't be found out in some other easy way (already).

--Vladimir