Re: [DNSOP] Comments regarding the NSEC5
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. 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 - 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. - 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. - 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. 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. - 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. 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. Thank you for the feedback. I hope the above helps you improve the proposal or, possibly, abandon it. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 24.3.2015 21:25, Paul Wouters wrote: On Tue, 24 Mar 2015, Jan Včelák wrote: 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. Not quite. DPRIVE is about anonymity of the querier, not anonymity of the zone data. As per Charter: The primary focus of this Working Group is to develop mechanisms that provide confidentiality between DNS Clients and Iterative Resolvers, but it may also later consider mechanisms that provide confidentiality between Iterative Resolvers and Authoritative Servers, or provide end-to-end confidentiality of DNS transactions. OK, right. Anyway, the trend is obvious. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNS terminology draft
Paul, would you consider adding something like these, with whatever modifications seem necessary? Maybe under Resource Records, since that is where OPT is. One thing that has been experience by many of us in different organizations, and which actually has shown its head within discussions with IETF people this week who are not in the DNS community, is that they very, very commonly think of the EDNS client-subnet option as being EDNS0. Those of us involved with ECS constantly try to educate people about this, especially since there are currently very few EDNS options and this is the only one that seems to be known by people outside of the DNS community. EDNS / EDNS0 -- The Extension Mechanisms for DNS, defined by [RFC6891], are an addition to the original message format to allow DNS agents [which I acknowledge is not defined, but by which I mean to indicate any software which speaks DNS] to specify message sizes larger than the original 512 octet limit, to expand the response code space, and to potentially carry additional options that affect the handling of a query. EDNS can be versioned, but currently the only version in public use is EDNS0. ECS / EDNS client-subnet -- An EDNS option principally for carrying information from a resolver to an authoritative server about the general network location of a client of the resolver. This is generally used by full service resolves who serve clients from a diverse network topography to get response from authoritative servers that tailor their responses based on client location. [This also seems to be missing as a commonly seen token:] RRTYPE [RRType?] -- A mnemonic or numeric value representing the type of data carried in an RR, as defined in [RFC1035] section 3.2, which impacts how its RDATA is interpreted. The full set of assigned values is listed at [IANA reference]. RDATA -- The data portion of an RR, as defined in [RFC1035]. Its format and semantics varies by RRTYPE. PS: I tend to use NXRRSET as slightly more expressive than NODATA, though it is an extended rcode for dynamic update. Worth mentioning along with the NODATA definition, or am I pretty much solo in using the term this way? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
i'm replying to several messages here, all from francis dupont. Francis Dupont mailto:francis.dup...@fdupont.fr Tuesday, March 24, 2015 1:39 PM ... A 2mn timeout simply has no chance to scale. i agree. it cannot scale. in addition, it's exceedingly easy to attack responders which implement [RFC 1035 4.2.2] by repeatedly connecting and doing nothing. however, for servers not at that moment under attack, the responders who implement the specification's two minute timeout is adequate for the limited volume of TCP traffic a server will see from clients who fail over to TCP after trying UDP. this means that while it's not ideal, it's not as broken as it could be. with changes to recommended initiator behaviour, we could make these existing servers more broken, or we could preserve their present level of brokenness, but we cannot make them less broken. i'm going to argue, below, for preserving their present level of brokenness. So I propose: - make clear that TCP support is mandatory. - allow servers to use the timeout they like, even a zero timeout (the last point should be discussed). Note a zero timeout doesn't mean send the response and close but send the response, check there is not pending query, and close. i am comfortable with this approach, but i would like to also specify (in one of the tcp related documents now circulating, or in a new one, that's a detail) that initiators SHOULD NOT remain connected and idle unless they are acting under some later specification under which idleness has been explicitly negotiated. obviously, any existing initiators will not obey the SHOULD NOT, but i would like to preserve the responders' present level of brokenness by not adding any new TCP connection idlers until and unless there is a protocol change by which a responder can signal its willingness to participate in an idle mesh. note that http://tools.ietf.org/html/draft-ietf-dnsop-edns-tcp-keepalive-01 is an example of a protocol revision by which idleness could be explicitly negotiated. i think a simpler approach could work, like adding one bit of the EDNS extended-flags mask to say the sender of this message would be happy about remaining connected but idle. my reason for thinking this would be enough is, there's no way to reliably tune specific idle periods, and a TCP speaker who signals their willingness to remain idle must also be prepared to close least-recently-used connections when the pool of potential connections is running dry. Francis Dupont mailto:francis.dup...@fdupont.fr Tuesday, March 24, 2015 2:26 PM In previous mail [Paul Wouters] wrote: If signaling for this is needed, then a separate document would be good. = not needed but very useful: the idea is not to allow servers to use short timeouts with clients which express they don't matter, but to allow them with all clients. Note this is why it is a protocol change... i believe that the last of the old-style initiators who treated premature closure by the responder as an urgent condition warranting a message to the console or the system log file have diminished to the level of noise, but that the change francis is asking for here, along with the clarification i'm asking for above as to non-idleness, along with a clarification to the effect that initiators SHOULD NOT treat premature closure by the responder as an urgent condition, reaches the level of protocol change not clarification. Francis Dupont mailto:francis.dup...@fdupont.fr Tuesday, March 24, 2015 2:42 PM In previous [Duane Wessels] wrote: I believe 5966bis already addresses your first point quite clearly. (note: first point is to make TCP support mandatory) For example, it says: This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. = but has this statement got a consensus? If it is the case of course there is no reason to write twice the same thing. because of the installed base, i think we should say RECOMMENDED rather than REQUIRED. we cannot reasonably redefine existing working systems as unfit for duty. note, i do not know if we have consensus on this general approach, nor do i know whether the strength of that consensus would be higher for RECOMMENDED than for REQUIRED. however, i do know that i would lodge an objection if the REQUIRED form were to reach consensus. i realize that this language is already in RFC 5966 (August 2010), so, that document was a protocol change not a clarification. Regarding your second point, Paul already pointed you to draft-ietf-dnsop-edns-tcp-keepalive, which I quite liked myself, but I think others felt it was unnecessarily complex. Here's what 5966bis says: DNS currently has no connection signaling mechanism. Clients and servers may close a connection at any time. Clients MUST be prepared to retry failed queries on broken connections. = unfortunately
Re: [DNSOP] go further about DNS over TCP?
In your previous mail you wrote: I believe 5966bis already addresses your first point quite clearly. (note: first point is to make TCP support mandatory) For example, it says: This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. = but has this statement got a consensus? If it is the case of course there is no reason to write twice the same thing. Regarding your second point, Paul already pointed you to draft-ietf-dnsop-edns-tcp-keepalive, which I quite liked myself, but I think others felt it was unnecessarily complex. Here's what 5966bis says: DNS currently has no connection signaling mechanism. Clients and servers may close a connection at any time. Clients MUST be prepared to retry failed queries on broken connections. = unfortunately this is a change in the protocol the document is not supposed to do here even it both makes sense and follows the real world situation. I agree with Paul Hoffman that connection signaling should be done in a separate document. = we have one (in fact the problem is we have two). Thanks francis.dup...@fdupont.fr PS: I note your opinion is to improve 5966bis. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS terminology draft
On Tue, Mar 24, 2015 at 06:02:34PM -0400, Dave Lawrence wrote: ECS / EDNS client-subnet -- An EDNS option principally for carrying information from a resolver to an authoritative server about the general network location of a client of the resolver. This is generally used by full service resolves who serve clients from a diverse network topography to get response from authoritative servers that tailor their responses based on client location. +1. If it stops one person from coming up and asking me when BIND is going to implement EDNS (when they mean ECS), it will all have been worthwhile. :) PS: I tend to use NXRRSET as slightly more expressive than NODATA, though it is an extended rcode for dynamic update. Worth mentioning along with the NODATA definition, or am I pretty much solo in using the term this way? You're not the only one. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] negative-trust-anchors-02
ajs I have read draft-ietf-dnsop-negative-trust-anchors-02. I have ajs some comments. Thanks. These seem like reasonably comments and I'll fold them into the doc. Hope to have a new version out next week. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
In your previous mail you wrote: So I propose: - make clear that TCP support is mandatory. - allow servers to use the timeout they like, even a zero timeout (the last point should be discussed). Note a zero timeout doesn't mean send the response and close but send the response, check there is not pending query, and close. Are you aware of draft-ietf-dnsop-edns-tcp-keepalive-01 ? = yes and I agree it will be nice to have a way to negociate the timeout between the client and the server. But unfortunately this won't apply to the current deployed base. Now there are the not technical questions to solve first: - is DNSOP chartered to do this? Point 4 says protocol maintenance and point 5 allows more if the area director agree. I believe that was specifically changed to accomodate for this, yes. = I think so too.a - is 5966bis the right place? I don't think so but another document means the 5966bis will be delayed... If signaling for this is needed, then a separate document would be good. = not needed but very useful: the idea is not to allow servers to use short timeouts with clients which express they don't matter, but to allow them with all clients. Note this is why it is a protocol change... Thanks francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
On Mar 24, 2015, at 4:42 PM, Francis Dupont francis.dup...@fdupont.fr wrote: For example, it says: This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. = but has this statement got a consensus? If it is the case Sorry, I should have realized that RFC 5966 (August 2010) already says exactly the same thing. DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/23/15 10:31, Andrew Sullivan wrote: if somehow the onion name leaked and ended up in the DNS, it's not a big deal *** Well, although you're right as far as *applications* are concerned, this is still a big deal because humans are using these appplications, and that's the prime interest of having such a TLD reserved in the first place, that the DNS does not propagate any leak. So I agree with your amendment, but not with the not a big deal statement, which completely ignores the fundamental privacy implications of such leaks to the DNS. == hk -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJVEejFXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg91bEP/j112GQesXFel7AOtPEV++jo gtTA2k8maagKs5hjJTpw9dq7Oi0U1CEKTq8ZSoizIoQTAmgtMUZZNnRqOE6Tszhu VhMnhBP9xC75nEHrjQQOZC8A/mmOxTnSDkxX5/46wTP+4CVQ9ZbjLhVTHClf3ipf wZpqwCsmC8h0lvefw663jbEtU0wnOX+e1JnzKN8Snsoap/989uYBVfCzD9Xrykld 3MTGLgMiPmv1qqejPeM+yqqoqeL/VxeQDXsaHi40HUnDQDQCGQNXqboSKPbEuUg3 VxLMEqPKXd762RRsWQznDqG23H1S/DY59FG+U4GQ0AzcS5FYxM4Moito/WW2LLk6 JLDXFQt0XcW5OMZbxhz6LuZwzpVCkCNf6wnEcLT7CQFDCKs0O0K8sg61PNeOKwyP Ps0igpjuJ1hfjZIX8iEI6QoG9ktnY0tVtqw1k7aA4lRcuU8nxyflGANPwtE8KDTt pUGFOXjL5hH0iC+ufv1pmNJCSvKhSprifvb+hMPZt3gksJeJYO62RqrZR7dXl4HU CXO1FvNuCIoqhjZ/8n86JBLjpZ69TPq7zchJ2OFAeW7TY10/FSHqLrTiMFWyOJ6l XyHbg6mU2Av5osSKVMzQNZhY3HaOnrnlpOrn4Tv58si/M8pMK+VE1lxfgDcnV9dH mOEcz8LrmOB67pC0Dl5o =E7vq -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
In your previous mail you wrote: This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. Sorry, I should have realized that RFC 5966 (August 2010) already says exactly the same thing. = and it seems it is not very applied (e.g., my home ISP doesn't support DNS over TCP), perhaps because of [5966/5966bis]: Whilst this document makes no specific recommendations to operators of DNS servers, it should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) may result in resolution failure and/or application-level timeouts. = so IMHO there are still things to do, even in the 5966bis intro... Thanks francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/24/15 20:03, Alec Muffett wrote: Hi Hellekin! I would agree that leak avoidance is “a major” rather than “the prime” point of having .onion reserved as a TLD. *** Agreed. I came from the privacy side of the arguments, which tends to consider human life as more valuable to data retention. Alec, would you care to explain the differences on the IANA considerations between this draft and the P2PNames draft for the same section? I found more than I can process now, but I guess you already know about them, and I'd like to hear your reasons. == hk -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJVEe+qXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg91PgP+wf57qp4wYL3Tdun3ntRI/Ik KUBYuBoJkO1bzVHk3Eq+Nc2zbAMLja8qLm75LF1Q/2Onae3QTRatathQis3M2H+O aZZLKZZ9mI5fOtqEmRoFa4Hl9rOUdcY4hDMdU7rAQ7EZnzK6KQIOYrxa4PMbUVf8 X21qz/UWtD8jDezPv64QksksLfNQrivjlDI/ecD/mWAT+mPW7Df8cQnQ6dEE/fMr EdWEOfo8BE9ARJJ9M1LMzCcObQq1T2eoDLe0HXu8SID4+JHtLqbF15vQ9BILXHIX jeEFIQeGsBlPaMYl8ZJffHGmEqCT5CtkZUTm/m2oJtU7VZ3zLu+p7J6A9UV7p3n6 PR6JQdya2Mikd3FAUTV5gOA+fKbKB40UXdZ7juMIJz2riqm0c1gHbS0/wzTDadqE IVGMQbl+ngjs6VKI0l7fuz6AW9vwk9IheS77RCa2sNAv6XpnUgCGlTHBr2Ymnldf MkeWPQWZI44fGEPQC7jTI9KonpxvqTpfFGSqKV9VpzIDNGX0Bsov0ixQCz01ZlVZ PxrLLv3MjN1deDrgi4rgT8Qo+3roed9MlPzfyMPUDKXJIX3OP4uu+ZroYk1t6ddz mqVUWdBwN00n01leRAkadqMrdq9wamO4mRd8hREA0S1mxAZqG52E//yxssg1KNUM RFL3ZdFKS+A/0zgYyYrY =kDtq -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
On Mar 24, 2015, at 3:39 PM, Francis Dupont francis.dup...@fdupont.fr wrote: So I propose: - make clear that TCP support is mandatory. - allow servers to use the timeout they like, even a zero timeout (the last point should be discussed). Note a zero timeout doesn't mean send the response and close but send the response, check there is not pending query, and close. Now there are the not technical questions to solve first: - is DNSOP chartered to do this? Point 4 says protocol maintenance and point 5 allows more if the area director agree. - is 5966bis the right place? I don't think so but another document means the 5966bis will be delayed... I believe 5966bis already addresses your first point quite clearly. For example, it says: This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. Regarding your second point, Paul already pointed you to draft-ietf-dnsop-edns-tcp-keepalive, which I quite liked myself, but I think others felt it was unnecessarily complex. Here's what 5966bis says: DNS currently has no connection signaling mechanism. Clients and servers may close a connection at any time. Clients MUST be prepared to retry failed queries on broken connections. I agree with Paul Hoffman that connection signaling should be done in a separate document. DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
Hi Hellekin! I would agree that leak avoidance is “a major” rather than “the prime” point of having .onion reserved as a TLD. There are many good reasons for reserving “.onion” as a TLD, including but not limited to: - avoiding leaks (above) - not wasting resource on trying to resolve the “.onion” special use domain name (flipside of above) - SSL/TLS EV certificate issuance per CA/B Forum Ballot 144 - ...meaning that sites can adopt a “.onion” address without reworking their HTTPS code - ...and also that EV site attestation works, to the extent that that may be valuable (eg: SecureDrop site for NEWSPAPER) - generally putting “.onion” on an official footing / erasing doubt Folk more creative than I can certainly add to this list, though as you say privacy (esp: organisations watching for people doing errant onion lookups) are a risk to the privacy of individual users! - alec On 3/24/15, 10:45 PM, hellekin helle...@gnu.org wrote: *** Well, although you're right as far as *applications* are concerned, this is still a big deal because humans are using these appplications, and that's the prime interest of having such a TLD reserved in the first place, that the DNS does not propagate any leak. So I agree with your amendment, but not with the not a big deal statement, which completely ignores the fundamental privacy implications of such leaks to the DNS. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
Alec, would you care to explain the differences on the IANA considerations between this draft and the P2PNames draft Woo! I'm honoured, but I am a considerably less IANA-informed schmuck than you take me for. :-) I've been heads-down in Tor and the wider Tor community for some time now, and I see the .onion TLD as something small and focused which is sensible and doable, and my grasp of the ramifications is that adoption of .onion as a special use domain name presents no obvious harm, quite a lot of good (and opportunity) plus might help shape a wider consideration. What happens/ed in consideration in other committees, I am not fit to speculate. -a ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
* Paul Hoffman [2015-03-24 13:57]: On Mar 23, 2015, at 6:23 PM, Jan Včelák jan.vce...@nic.cz wrote: - 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 slows down the online hash collection but not the offline dictionary enumeration. The attacker will have to send 10 or 100 times as many queries (which of course the server administrator pays by having to send 10 or 100 times as many negative responses). In the offline attack, the performance is dominated by the effort for hashing the input dictionary. Whether you're matching the output against 1000 or 10 hash values has little influence on the total performance. Regards, Matt smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
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 - 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
Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case
On Thursday, January 15, 2015, Matthijs Mekking matth...@pletterpet.nl wrote: Hi wg, IXFR with DNSSEC is suddenly not so small anymore. Do you recognize this? Olafur and I have some ideas on keeping those zone transfers small. Your feedback is appreciated. http://www.ietf.org/internet-drafts/draft-mekking-mixfr-01.txt I support this draft. One thing that jumped out to me was there appears to be no mention of NSEC/NSEC3 chain management when adding/removing records. regards John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-root-loopback-01
Sorry for most of the following comments on draft-ietf-dnsop-root-loopback-01 applicable to its appendices. It is better to describe that the update of the zone can be delayed a little bit as no NOTIFY message is sent to the root-on-loopback. In Appendix A, the root servers listed allow AXFR currently, but I am afraid they don't guarantee it in the future. It may be necessary to confirm it with the operator of each root server listed. In Appendix B, most of the IP addresses of the root DNS servers are anycasted. They are not suitable for the target to pull the zone data in AXFR over TCP. Also it must be noted that these addresses may change over time (while the frequency is not high), it may need to give a warning to periodically check if the addresses are valid. Generating the configuration after priming query? (this is a joke) IMHO, it may necessary to establish an infrastructure to distribute root zone in scalable/reliable manner. -- Akira Kato ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On Mar 24, 2015, at 11:11 AM, Warren Kumari war...@kumari.net wrote: 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. And if you REALLY want this, TODAY, get a HSM (optional), program it to ONLY sign NSEC3 records, and just dynamically sign (and cache) NSEC3 records for your NXDOMAINs. You use the HSM to protect the key if you are paranoid, and you get no enumeration records. By caching the responses, you prevent a DOS from preventing you from serving up common NXDOMAIN records, and the DOS only affects the NXDOMAIN side anyway: you can probably get the same results in most cases by serving up an NXDOMAIN without an NSEC3 RRSET, as the resolver will go this doesn't validate and give a servfail anyway. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
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
Re: [DNSOP] Comments regarding the NSEC5
On Mon, Mar 23, 2015 at 6:38 PM, Jan Včelák jan.vce...@nic.cz wrote: On 23.3.2015 18:26, Bob Harold wrote: I think we might need to allow for more than one NSEC5 key and chain, during a transition. Otherwise it might be impossible to later create a reasonable transition process. This might require us to tag the NSEC5 records with an id, so that the chains and matching keys can be distinguished. Better to do this now than to try to retrofit later. Please, can you clarify which transition process do you mean? Transitioning from one NSEC5 key to another. I think the process would need to be: - add new NSEC5 key RR, but not used yet. Also add new private to all authoritative servers. - wait for new key to reach everywhere (propagation + ttl) - change all NSEC5 records in the zone. - wait for new records to reach everywhere - remove old NSEC5 key record. Also remove old private key from all authoritative servers. But for the servers and public to know which key to use, there will need to be some id that matches NSEC5 records to the matching NSEC5 key. That requires changing the format of the NSEC5 records, so it cannot be done later. A few minor corrections or suggestions: Thank you. These will be fixed in the next version. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 24.3.2015 20:08, Bob Harold wrote: On Mon, Mar 23, 2015 at 6:38 PM, Jan Včelák wrote: On 23.3.2015 18:26, Bob Harold wrote: I think we might need to allow for more than one NSEC5 key and chain, during a transition. Otherwise it might be impossible to later create a reasonable transition process. This might require us to tag the NSEC5 records with an id, so that the chains and matching keys can be distinguished. Better to do this now than to try to retrofit later. Please, can you clarify which transition process do you mean? Transitioning from one NSEC5 key to another. I think the process would need to be: - add new NSEC5 key RR, but not used yet. Also add new private to all authoritative servers. - wait for new key to reach everywhere (propagation + ttl) - change all NSEC5 records in the zone. - wait for new records to reach everywhere I don't think we need to wait till updated NSEC5 records get everywhere. Also with NSEC3, the two servers can answer from different NSEC3 chains as far as the chains are signed correctly. The server must switch to a new private key at the moment, when it gets an updated NSEC5 chains and drops the old one. Right, that's one of the things which should be clarified. - remove old NSEC5 key record. Also remove old private key from all authoritative servers. But for the servers and public to know which key to use, there will need to be some id that matches NSEC5 records to the matching NSEC5 key. That requires changing the format of the NSEC5 records, so it cannot be done later. You should never get a zone with NSEC5 records mixed from two different chains. The change of the NSEC5 chain must be atomic. That is required by the draft. What is missing in the draft is, how to determine a correct NSEC5 private key to use to compute the NSEC5 proofs. What comes to my mind is that when the zone is loaded (or the chain is updated), the server could just compute the NSEC5 hash of the zone apex and determine, which key is in use. That could work even without the id. But this is definitely a good point. I will think about it. Thank you. Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 24.3.2015 19:20, Paul Hoffman wrote: Again: a proposal for an operational change to DNSSEC needs to be explicit about the tradeoffs, particularly when one of the options is you will be considered unsigned by some resolvers when you implement this. The current draft is not have this. That's right. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] go further about DNS over TCP?
As we have more and more DNS over TCP (large responses, response rate limitation, even TLS for privacy) I think we should fix the way DNS over TCP is supposed to be handled by servers. Quoting RFC 1035 4.2.2 TCP usage: - The server should assume that the client will initiate connection closing, and should delay closing its end of the connection until all outstanding client requests have been satisfied. - If the server needs to close a dormant connection to reclaim resources, it should wait until the connection has been idle for a period on the order of two minutes. In particular, the server should allow the SOA and AXFR request sequence (which begins a refresh operation) to be made on a single connection. Since the server would be unable to answer queries anyway, a unilateral close or reset may be used instead of a graceful close. A 2mn timeout simply has no chance to scale. So I propose: - make clear that TCP support is mandatory. - allow servers to use the timeout they like, even a zero timeout (the last point should be discussed). Note a zero timeout doesn't mean send the response and close but send the response, check there is not pending query, and close. Now there are the not technical questions to solve first: - is DNSOP chartered to do this? Point 4 says protocol maintenance and point 5 allows more if the area director agree. - is 5966bis the right place? I don't think so but another document means the 5966bis will be delayed... Regards francis.dup...@fdupont.fr PS: I'll try to raise this at the mic if there is still enough time (as this message is sent during the DNSOP session at the 92th IETF). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
On Tue, 24 Mar 2015, Francis Dupont wrote: So I propose: - make clear that TCP support is mandatory. - allow servers to use the timeout they like, even a zero timeout (the last point should be discussed). Note a zero timeout doesn't mean send the response and close but send the response, check there is not pending query, and close. Are you aware of draft-ietf-dnsop-edns-tcp-keepalive-01 ? http://tools.ietf.org/html/draft-ietf-dnsop-edns-tcp-keepalive-01 Now there are the not technical questions to solve first: - is DNSOP chartered to do this? Point 4 says protocol maintenance and point 5 allows more if the area director agree. I believe that was specifically changed to accomodate for this, yes. - is 5966bis the right place? I don't think so but another document means the 5966bis will be delayed... If signaling for this is needed, then a separate document would be good. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] comments on DNS terminology draft
Some comments on draft-hoffman-dns-terminology NODATA -- This is not an actual response code, but instead is the combination of an RCODE of 0 (NOERROR) and an Answer section that is empty. That is, it indicates that the response is no answer, but that there was not supposed to be one. [72]Section 1 of [RFC2308] defines it as a pseudo RCODE which indicates that the name is valid, for the given class, but are no records of the given type. I don't think this definition is precise enough. Under this stated definition, referral responses from authority servers qualify to be called NODATA responses, because they also have a combination of RCODE 0 and an empty answer section. Referrals can be excluded from this definition by adding the constraint that NODATA responses from authority servers have the AA bit set. I'd also recommend starting the definition with a clear statement of what it means first, followed by how it is represented in terms of packet attributes. The current definition is in the reverse order which is more difficult to read (at least for me). Here's my suggested rewrite: NODATA -- This is not an actual response code, but is a particular type of response from a server that indicates that the queried domain name exists for the given class, but the resource record type being queried for doesn't exist. They are a combination of an RCODE of 0 (NOERROR) and an Answer section that is empty. In addition, NODATA responses from authoritative servers have the authoritative answer (AA bit) set to one. Section 1 of [RFC2308] defines it as a pseudo RCODE which indicates that the name is valid, for the given class, but are no records of the given type. Should we also mention that NODATA responses usually include a SOA record in the authority section to indicate to resolvers how long to do negative caching for? [73]5. Resource Records RR -- A short form for resource record. ([74]RFC 1034, section 3.6.) RRset -- A set of resource records with the same label, class and type, but with different data. (Definition from [75]RFC 2181) Also spelled RRSet in some documents. As a clarification, same label in this definition means same owner name. I think the 'same TTL' constraint is important enough to restate specifically as part of this definition. I suggest adding: In addition, RFC 2181 states that the TTLs of all RRs in an RRSet must be the same. SOA field names -- DNS documents, including the definitions here, often refer to the fields in the RDATA an SOA resource record by field name. Those fields are defined in [78]Section 3.3.13 of RFC 1035. The names (in the order they appear in the SOA RDATA) are MNAME, RNAME, SERIAL, REFRESH, RETRY, and EXPIRE, MINIMUM. Note that the meaning of MINIMUM field is updated in [79]Section 4 of RFC 2308; the new definition is that the MINIMUM field is only the TTL to be used for negative responses. Negative responses is used here without a clear definition anywhere earlier (or later) in the document. I think that definition needs to be added. Is it only NXDOMAIN and NODATA responses? Or does it also include failure responses (SERVFAIL, NOTIMP, or any of the extended response codes)? The Negative Caching definition provided later in the document, quoting RFC 2308 (The storage of knowledge that something does not exist, cannot give an answer, or does not give an answer) seems to imply that negative responses include SERVFAIL, NOTIMP, etc. [80]6. DNS Servers DNS Servers and Clients - immediately below we state that the section talks about both. This section defines the terms used for the systems that act as DNS clients, DNS servers, or both. Some terms about servers describe servers that do and do not use DNSSEC; see [81]Section 8 for those definitions. [[ There is a request to first describe the iterative and recursive resolution processes, and mention the expected values of the RD,RA,AA bits. Then you can describe the distinctions between recursive and iterative clients, and between recursive and authoritative servers, in terms of the roles they play in the different resolution processes. This would require the section to be quite different than the other sections in the document. ]] That is one approach. I agree this section probably needs a significant rewrite for clarity and precision. I find the current definitions of the family of resolvers to be quite convoluted. [...] Authoritative server -- A system that responds to DNS queries with information about zones for which it has been configured to answer with the AA flag in the response header set to 1. It is a server that has authority over one or more DNS zones. Note that it is possible for an authoritative server to respond to a query without the parent zone delegating authority to that server. Missing
Re: [DNSOP] Comments regarding the NSEC5
On Tue, Mar 24, 2015 at 3:27 PM, Jan Včelák jan.vce...@nic.cz wrote: On 24.3.2015 20:08, Bob Harold wrote: On Mon, Mar 23, 2015 at 6:38 PM, Jan Včelák wrote: On 23.3.2015 18:26, Bob Harold wrote: I think we might need to allow for more than one NSEC5 key and chain, during a transition. Otherwise it might be impossible to later create a reasonable transition process. This might require us to tag the NSEC5 records with an id, so that the chains and matching keys can be distinguished. Better to do this now than to try to retrofit later. Please, can you clarify which transition process do you mean? Transitioning from one NSEC5 key to another. I think the process would need to be: - add new NSEC5 key RR, but not used yet. Also add new private to all authoritative servers. - wait for new key to reach everywhere (propagation + ttl) - change all NSEC5 records in the zone. - wait for new records to reach everywhere I don't think we need to wait till updated NSEC5 records get everywhere. Also with NSEC3, the two servers can answer from different NSEC3 chains as far as the chains are signed correctly. The server must switch to a new private key at the moment, when it gets an updated NSEC5 chains and drops the old one. Right, that's one of the things which should be clarified. - remove old NSEC5 key record. Also remove old private key from all authoritative servers. But for the servers and public to know which key to use, there will need to be some id that matches NSEC5 records to the matching NSEC5 key. That requires changing the format of the NSEC5 records, so it cannot be done later. You should never get a zone with NSEC5 records mixed from two different chains. The change of the NSEC5 chain must be atomic. That is required by the draft. What is missing in the draft is, how to determine a correct NSEC5 private key to use to compute the NSEC5 proofs. What comes to my mind is that when the zone is loaded (or the chain is updated), the server could just compute the NSEC5 hash of the zone apex and determine, which key is in use. That could work even without the id. That's simpler, and removes the need for the id. (That's why you are designing this and not me.) Then the process becomes: - add new private key to all authoritative servers. - change NSEC5 key and all NSEC5 records in the master zone - wait for zone to reach all slaves - each time the NSEC5 key record changes, the servers test to see which private key it uses. - remove old private key from all authoritative servers. But this is definitely a good point. I will think about it. Thank you. Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On Mar 24, 2015, at 10:41 AM, Matthäus Wander matthaeus.wan...@uni-due.de wrote: * Paul Hoffman [2015-03-24 13:57]: On Mar 23, 2015, at 6:23 PM, Jan Včelák jan.vce...@nic.cz wrote: - 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 slows down the online hash collection but not the offline dictionary enumeration. The attacker will have to send 10 or 100 times as many queries (which of course the server administrator pays by having to send 10 or 100 times as many negative responses). In the offline attack, the performance is dominated by the effort for hashing the input dictionary. Whether you're matching the output against 1000 or 10 hash values has little influence on the total performance. Completely true. However, the existence of NSEC5 is predicated on the idea that a zone admin cares so much about zone enumeration that they are willing to risk having their zone appear unsigned to resolvers that do not implement NSEC5. If that zone admin finds that cost too high, but has lots of CPU available during signings, they should know that they have that alternative. Again: a proposal for an operational change to DNSSEC needs to be explicit about the tradeoffs, particularly when one of the options is you will be considered unsigned by some resolvers when you implement this. The current draft is not have this. --Paul Hoffman signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Status of current WG Documents
Status of current WG Documents In an effort to expedite the agenda along during the DNSOP meeting, we wanted to give an update of Working Group Documents and where they stand. draft-ietf-dnsop-child-syncronization Now RFC 7477, complete with Errata! draft-ietf-dnsop-as112-dname - In RFC Edit state draft-ietf-dnsop-rfc6304bis - In RFC Edit draft-ietf-dnsop-rfc6598-rfc6303 - WG Chair write up draft-ietf-dnsop-dnssec-key-timing Need final discussion on updating Figure 5. draft-ietf-dnsop-resolver-priming Revived!! and ready for reviews draft-ietf-dnsop-cookies Decision needed: Error Code in the option field or not? draft-ietf-dnsop-edns-chain-query Ready to move to WGLC, only pushback from one reviewer draft-ietf-dnsop-edns-tcp-keepalive Chair need to summarize the discussion from last month and determine next steps (this week) Drafts that are being actively edited: draft-ietf-dnsop-5966bis draft-ietf-dnsop-negative-trust-anchors draft-ietf-dnsop-edns-client-subnet Actively edited but some operational questions Question of adding another EDNS option draft-ietf-dnsop-dnssec-roadblock-avoidance Needs a kick from the authors. Discussion Time during the meeting: draft-ietf-dnsop-qname-minimisation draft-ietf-dnsop-root-loopback ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
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
