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

[Vladimír Čunát <[e-mail]>]

On 03/06/2018 01:30 AM, Wessels, Duane wrote:
> 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.

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