Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only...

[Ólafur Guðmundsson <[e-mail]>]

On Wed, Jan 4, 2017 at 12:33 PM, Nicholas Weaver <[e-mail]>
wrote:

> Any system which prevents zone enumeration requires online signing,
> https://www.cs.bu.edu/~goldbe/papers/nsec5faq.html
>
> But NSEC5 is almost certainly not going to be adopted, simply because of
> the partial deployment problem.
>
> NSEC3 lies work today, but people worry that NSEC3 might have server
> compromise compromise the ZSK.
>
>
>
> So why not simply add a new DNSKEY record flag: NSEC3-only.  This flag
> means that the key in question can only be used to sign an NSEC* record
> when presenting NXDOMAIN.
>

I used to think that was a good idea, but .... given that this will add
keys to the DNSKEY set I think it is not worth it with RSA the DNSKEY sets
are too large in most cases.
With ECC keys on the other hand this might be reasonable.

What is the problem you are solving by having a NSEC-only key ?
is it key management,  sharing keys with DNS operators, or something else.


At Cloudflare we sign a all DNSEC answers on the fly with the exception of
DNSKEY/CDS/CDNSKEY which we have to do centrally.
This is working and we do not worry too much about ZSK compromise, as we
can roll them when we need.
 We just use Minimally covering NSEC records (no need to do NSEC3),
we are looking into adoption that on the fly when under random prefix DDoS
attacks, to resolvers that we know support agressive NSEC processing.


> This way, you can deploy this solution today using white lies, and as
> resolvers are updated, this reduces the potential negative consequence of a
> key compromise to “attacker can only fake an NXDOMAIN”, allowing everything
> else to still use offline signatures.
>
>
Why is key compromise in DNS more worrying than in HTTPS ?
HTTP servers have keys online all the time.


> Combine with caching of the white lies to resist DOS attacks and you have
> a workable solution that prevents zone enumeration that is deployable today
> and has improved security (key can only fake NXDOMAIN) tomorrow.
>
>
The problem with a FLAG is that it will require
a) validator/resolver support
b) have a workable key management

I think we can do this w/o the flag

Regards,
Olafur