On 24.3.2015 19:11, Warren Kumari wrote:
> 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.
Is the cake delicious?
>>>>> - 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.
I know and I completely agree.
On the other hand, there are efforts (DPRIVE) to make this data
collection more difficult.
>>> 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....
The reason why I started to write the draft was to find out, how the
theory is applicable in the real-world DNS. I really like the idea of
NSEC5. It's a proper way of preventing zone enumeration, while having
the zone signing key offline.
I know that the changes to the protocol are invasive and that the
performance degradation is significant. I want that to be documented. If
we quantify the benefits and trade-offs, the zone operators can decide
if NSEC5 is worthy.
Jan
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
