On Tue, Mar 24, 2015 at 9:56 AM, Jan Včelák <jan.vce...@nic.cz> wrote:
> On 24.3.2015 13:57, Paul Hoffman wrote:
>> On Mar 23, 2015, at 6:23 PM, Jan Včelák <jan.vce...@nic.cz> wrote:
>>>> This proposal continues to have fundamental problems that are not
>>>> documented in the draft.
>>>>
>>>> - The statement about NSEC3 "offline dictionary attacks are still possible
>>>> and have been demonstrated" doesn't take into account trivial changes that
>>>> an operator can choose to take if they are really concerned about offline
>>>> dictionary enumeration (with the trade-off being zone size).
>>>
>>> Please, can you clarify which trivial solution in particular do you mean?
>>
>> Sure. When signing the zone, instead of creating one NSEC3 record for a gap,
>> you create 10 or 100 with random intervals between the two hashes. That way
>> an attacker is more likely to get results that will not match dictionary
>> entries.
>
> This is described in the mentioned paper as "NSEC3 with dummy records".
> It's not a good solution - the cost for the name server is higher than
> the cost for the attacker.
>
>>> There is a paper "Stretching NSEC3 to the Limit: Efficient Zone
>>> Enumeration Attacks on NSEC3 Variants" by Sharon Goldberg et al, which
>>> covers some of the trivial solutions and explains why it won't work:
>>>
>>> http://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf
>>>
Yes, this was presented at (IIRC) DNS-OARC in Los Angeles. While the
paper is correct, my view of the response was "shrug", and "this is
not a problem worth spending resources to solve". While some zone
operators want to minimize zone enumeration, it's not really viewed as
a huge issue. This is like buying a triple hardened bank vault door to
protect a slice of cake.
>>>> - The draft does not discuss the increased CPU resources needed on every
>>>> authoritative server to respond to non-existent queries relative to simply
>>>> serving NSEC or NSEC3 directly.
>>>
>>> Yes, that's right. We would like to cover this in the "Performance
>>> Considerations" section, which is not ready at the moment.
>>
>> NSEC5 has significant operational consequences. Deferring the description of
>> them until later doesn't help the WG evaluate whether or not this proposal
>> is worth considering.
>
> Sure. We just wanted some early feedback.
>
>>>> - Section 2 says "The zones signed according to this specification MUST
>>>> use only these [NSEC5-based] algorithm identifiers, thus NSEC5-unaware
>>>> resolvers will treat the zone as insecure" without acknowledging that such
>>>> a tradeoff is unneeded if the operator uses NSEC3 obfuscation instead.
>>>
>>> I'm not sure if I understand this correctly. If the zone uses NSEC5 for
>>> authenticated denial ("zones signed according to this specification"),
>>> then it must use only NSEC5 capable algorithms ("these algorithm
>>> identifiers"). Otherwise an NSEC5-unaware resolver would treat the
>>> denying responses from the server as bogus. Does it make sense?
>>
>> No. As a zone administrator, you decide whether to sign your zone with NSEC
>> or NSEC3. You are prosing to make that decision "NSEC or NSEC3 or NSEC5",
>> but without acknowledging tradeoffs.
>
> OK.
>
>>>> - Section 10, "Resolver Considerations", doesn't mention that the NSEC5
>>>> private keys must be securely distributed out-of-band when the NSEC5KEY RR
>>>> is updated, nor that the private key must be atomically updated when the
>>>> NSEC5KEY is updated.
>>>
>>> Does it fit the "Resolver Considerations"?
>>
>> Sorry, my fault. I should have said: Section 9.4, Secondary Servers,
>> doesn't mention that the NSEC5 private keys must be securely distributed
>> out-of-band when the NSEC5KEY RR is updated, nor that the private key must
>> be atomically updated when the NSEC5KEY is updated. Instead, it only says
>> "This document does not define mechanism to distribute NSEC5 private keys".
>>
>>> Yes, we don't define any mechanism to distribute the private keys to
>>> other authoritative servers. I think this is out of the scope of the draft.
>>
>> This protocol is an operational change to the way that DNSSEC is provided.
>> Having a critical piece of that operation be out of scope for your proposal
>> is inappropriate.
>
> I disagree. This can be implementation specific. From the same reason we
> don't define format for NSEC5 private keys. This is a general problem of
> DNS provisioning. I'm persuaded that defining some provisioning protocol
> within NSEC5 is a bad idea.
>
>>> We can provide more details about the private key exchange during the
>>> NSEC5 key rollover. The key itself is bound to one NSEC5 chain - so
>>> during the rollover, when the NSEC5 chain is replaced, the new private
>>> key is started to be used.
>>
>> That part is clear: what isn't clear is the importance of getting that on
>> all secondaries.
>
> OK.
>
>>>> - There is no discussion of how many queries an attacker needs to send to
>>>> enumerate a zone with NSEC5. In the real world, it is pretty easy to send
>>>> queries for each string in a dictionary, making NSEC5 just as vulnerable
>>>> as NSEC3, yet at a much higher operational cost.
>>>
>>> To enumerate the zone, you will need approximately the same amount of
>>> queries you will need to enumerate a plain unsigned zone. (Assuming that
>>> the server responds to ANY. And ignoring wildcards, which are easily
>>> recognizable in DNSSEC.)
>>
>> Yes, exactly.
>>
>>>
>>>> Overall, this seems like a novel idea that comes with a huge operational
>>>> overhead and no actual demand.
>>>
>>> Yes, it comes at a price. People who don't want to disclose content of a
>>> zone may already use online signing and the overhead is huge as well.
>>> NSEC5 just makes it possible to have the zone signing key offline.
Sure, you might not want folk to just download your zone and walk off
with it, but ... If you put something in a zone, and expect that to
remain secret, you are in for a bad day.
The contents of zones quickly becomes visible, what with passive DNS,
DITL, people who connect in place X, and then reopen their laptop in
place Y, etc.
>>
>> People who don't want to disclose the content of a zone don't serve the
>> zone. That is not the operational tradeoff that NSEC3 addresses.
>
> That's more a philosophical question. Depends if you think that the data
> in the zone are public.
It is -- or, at least, it soon becomes so.
> If you are an attacker, the first think you will
> probably do is to determine attack vectors on a target system. And the
> DNS zone may provide a lot of useful information about the system
> architecture.
Perhaps not naming your NEC Point of Sale terminal as
nec-cashregister-running-nOS3-14.example.com would be a better idea
than assuming that this will remain "secret". If you really want,
there is split dns, etc, but if you stick things in a publicly
accessible zone, you should expect it will become public....
W
>
>>> Thank you for the feedback.
>>
>> I hope the above helps you improve the proposal or, possibly, abandon it.
>
> Both is possible. :-)
>
> Jan
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
