Hi Duane,
> On 1 Mar 2018, at 9:45 am, Wessels, Duane <dwess...@verisign.com> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
