Re: [DNSOP] Comments regarding the NSEC5
On 24.3.2015 21:04, Bob Harold wrote: 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. I agree. I will update the draft to clarify the replacement of the private key during the rollover process. Thank you, Bob. Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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
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] 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
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
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
Re: [DNSOP] Comments regarding the NSEC5
Hi, I just submitted an updated NSEC5 draft into the data tracker. The most significant change is fixing the NSEC5 key rollover mechanism; the rest are just typo fixes and small clarifications in terminology. http://datatracker.ietf.org/doc/draft-vcelak-nsec5/ Also, I will have a 10 minute talk about the draft on the Security Area Open Meeting on Thursday. You are welcome to come. Regards, Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On Mar 23, 2015, at 10:15 AM, Jan Včelák jan.vce...@nic.cz wrote: I just submitted an updated NSEC5 draft into the data tracker. The most significant change is fixing the NSEC5 key rollover mechanism; the rest are just typo fixes and small clarifications in terminology. 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). - 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. - 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. - 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. - 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. Overall, this seems like a novel idea that comes with a huge operational overhead and no actual demand. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
Paul Hoffman mailto:paul.hoff...@vpnc.org Monday, March 23, 2015 12:08 PM This proposal continues to have fundamental problems that are not documented in the draft. ... Overall, this seems like a novel idea that comes with a huge operational overhead and no actual demand. +1. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 3/23/15, 14:08, Paul Hoffman paul.hoff...@vpnc.org wrote: On Mar 23, 2015, at 10:15 AM, Jan Včelák jan.vce...@nic.cz wrote: I just submitted an updated NSEC5 draft into the data tracker. The most significant change is fixing the NSEC5 key rollover mechanism; the rest are just typo fixes and small clarifications in terminology. This proposal continues to have fundamental problems that are not documented in the draft. Missing in 14.5 - remember that for NSEC3, we had to create new dnssec-algorithm numbers (well, one) for RSA-SHA-1 (algorithms 5 and 7) to ensure that the validator was new enough to understand NSE3 (or treat the zone as unsigned). Regardless of the other features of NSEC5, if there's no way to signal that a zone only uses NSEC5 then the proposal will never get deployed. It doesn't mean a new set of algorithm numbers (RSA-SHA1, RSA-SHA256, that elliptic curve thing, GOST, etc.), although it might, but it could be some other new, novel means. Yes, a new round of algorithm numbers without a new round of algorithms isn't very palatable. (Kind of puts a damper on innovating in this space, huh?) Overall, this seems like a novel idea that comes with a huge operational overhead and no actual demand. I agree. More interesting to me than stopping enumeration (I'm a NSEC'r anyway) is 1) coming up with a smaller response payload in negative responses (NSEC3 needs up to 3 sets, NSEC needs up to 2 sets) and 2) coming up with a more explainable response. (You try understanding what a NSEC3 proof is stating.) 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
The completed sections of draft looks good to me, with one exception. 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. A few minor corrections or suggestions: section 1.1 Rationale As side-effect, however, the NSEC chain existence allows for the enumeration of the zone's contents by querying for names immediately individual RRs in the chain; -- Seems to be missing a word between immediately and individual section 1.1 Rationale The NSEC5 is not intended to replace NSEC or NSEC3. It is designed as an alternative mechanisms for authenticated denial of existence. -- I think mechanisms should be mechanism (singular, not plural). section 4 NSEC5 Algorithms The algorithms used for NSEC5 authenticated denial are independent on the algorithms used for DNSSEC signing. -- Change independent on to independent of ? -- Bob Harold hostmaster, UMnet, ITcom Information and Technology Services (ITS) rharo...@umich.edu 734-647-6524 desk On Mon, Mar 23, 2015 at 11:15 AM, Jan Včelák jan.vce...@nic.cz wrote: Hi, I just submitted an updated NSEC5 draft into the data tracker. The most significant change is fixing the NSEC5 key rollover mechanism; the rest are just typo fixes and small clarifications in terminology. http://datatracker.ietf.org/doc/draft-vcelak-nsec5/ Also, I will have a 10 minute talk about the draft on the Security Area Open Meeting on Thursday. You are welcome to come. Regards, Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
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? 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
Hi Paul, 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? 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. - 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? - 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? 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. 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. - 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.) 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. Thank you for the feedback. Cheers, Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On Thursday, March 12, 2015 12:39:17 PM Florian Weimer wrote: On 03/12/2015 11:36 AM, Jan Včelák wrote: And does anyone actually use opt out with NSEC3? Yes, .com for example. My impression was that Opt-Out was the selling point of NSEC3, not the domain name hashing. Okay. Are they interested in switching to NSEC5? I was trying to say that TLDs use NSEC3 because of Opt-Out. This seems to be true, based on the information Edward sent in the Using NSEC3 for opt-out thread. The target audience for NSEC5 are people, who care about the zone enumeration. They could be using Minimally Covering NSEC Records or NSEC3 White Lies at the moment. Both of these mechanisms already require on-line signing and private zone signing keys on all authoritative servers. NSEC5 just removes the necessity to have keys on the servers. Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
JFTR I don't think the target audience is TLDs, but I have heard a several times speaking to me that they won't implement DNSSEC because of enumeration (citing djb's paper on NSEC3 offline enumeration). Those folks are the target audience for the cryptographically proven anti-enumeration solution. Cheers, Ondrej -- Ondřej Surý -- Chief Science Officer CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Original Message - From: Florian Weimer fwei...@redhat.com To: Jan Včelák jan.vce...@nic.cz Cc: dnsop@ietf.org, Nicholas Weaver nwea...@icsi.berkeley.edu Sent: Thursday, March 12, 2015 12:39:17 PM Subject: Re: [DNSOP] Comments regarding the NSEC5 On 03/12/2015 11:36 AM, Jan Včelák wrote: And does anyone actually use opt out with NSEC3? Yes, .com for example. My impression was that Opt-Out was the selling point of NSEC3, not the domain name hashing. Okay. Are they interested in switching to NSEC5? -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On Mar 11, 2015, at 9:39 AM, Jan Včelák jan.vce...@nic.cz wrote: NSEC5 proof is the FDH of domain name. NSEC5 hash is SHA-256 of NSEC5 proof. I will clarify that. Why not just do something simpler? The only thing NSEC5 really differs in a way that counts is not in the NSEC record but really just the DNSKEY handling, having a separate key used for signing the NSEC* records. So why define NSEC5 at all. Instead, just specify a separate flag for the DNSKEY record, NSEC-only, sign the NSEC3 dynamically, bada bing, bada boom, done! For old resolvers, they just ignore the flag and treat it like any other DNSKEY record, and since the valid names are signed with the other key, while the NSEC* are signed with this key, it works just fine. For upgraded resolvers, they follow the convention and only will accept RRSIGs for NSEC/NSEC3 with that DNSKEY record. And then on the authority side, you just dynamically generate and sign the NSEC3 record that says H(name)-1 to H(name)+1 has no valid record and sign that with the NSEC-only key. This way, you gain the protection against enumeration and the limited damage on key compromise property when validated by upgraded resolvers, and you still get the protection against enumeration when the resolver isn't upgraded, and you don't need to upgrade the resolver in order for this to be deployed. -- 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 Wednesday, March 11, 2015 09:52:55 AM Nicholas Weaver wrote: Why not just do something simpler? The only thing NSEC5 really differs in a way that counts is not in the NSEC record but really just the DNSKEY handling, having a separate key used for signing the NSEC* records. So why define NSEC5 at all. Instead, just specify a separate flag for the DNSKEY record, NSEC-only, sign the NSEC3 dynamically, bada bing, bada boom, done! This would not work. Anyone holding the NSEC-only private key could fake denying answers for the zone. So if your zone is slaved by a less-trusted party, they could still manipulate your zone. This is not possible with NSEC5. Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 03/12/2015 11:15 AM, Jan Včelák wrote: On Wednesday, March 11, 2015 09:52:55 AM Nicholas Weaver wrote: Why not just do something simpler? The only thing NSEC5 really differs in a way that counts is not in the NSEC record but really just the DNSKEY handling, having a separate key used for signing the NSEC* records. So why define NSEC5 at all. Instead, just specify a separate flag for the DNSKEY record, NSEC-only, sign the NSEC3 dynamically, bada bing, bada boom, done! This would not work. Anyone holding the NSEC-only private key could fake denying answers for the zone. So if your zone is slaved by a less-trusted party, they could still manipulate your zone. This is not possible with NSEC5. They can still respond with SERVFAIL instead of supplying a signed answer, achieving roughly the same result. A better argument would be support for opt out, where signatures from the online key could introduce unauthorized positive answers. It's still not a very strong argument, admittedly. The DNS software itself is likely signed by a key which is kept online (more or less). Online keys are less threatening than they used to be, and we aren't even talking about long-term keys baked into software, but short/medium-term keys which are easily replaced. And does anyone actually use opt out with NSEC3? -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 11.3.2015 17:30, Florian Weimer wrote: On 03/11/2015 05:19 PM, Jan Včelák wrote: It's not clear if the security goals make sense. What do zone operators gain if zone enumeration attacks are moved from offline to online, other than a need to provision additional server capacity? It's not that they can block resolution requests from large resolvers if a part of their client population participates in aggressive enumeration. It dependes whether you see zone enumeration as a problem. If I really want to enumerate a zone, I will just send my dictionary as queries, possibly through open resolvers. People are reckless like that. At least with NSEC3, polite attackers can do some of the processing off-line, without punishing authoritative servers or resolvers. NSEC5 takes away that option. Do the existing enumerators care? Who knows. I really can't tell. I don't know. Section 4 says, “NSEC5 hash is an SHA-256 hash function as specified in [RFC6234].” Are you sure that's right? You mean the reference to the RFC? Yes, I think it's right. Or am I missing something? I'm guessing, but “NSEC5 hash” is probably what involves FDH. Based on your comment,s it's clearly *not* SHA-256, contrary to what I quoted above. NSEC5 proof is the FDH of domain name. NSEC5 hash is SHA-256 of NSEC5 proof. I will clarify that. We deal with NSEC5 proofs and NSEC5 hashes (see the Terminology section). The NSEC5 proof is the FDH (can be comptuted only by the holder of the NSEC5 private key); the NSEC5 hash is an SHA-256 hash of the NSEC5 proof (everyone can compute it, if they know the NSEC5 proof). So in your notation, an NSEC5 RR owner name should be: Base32hex(SHA-256(FDH(Wire-Encode(owner name), privkey))) And the inner part (without the Base32 encoding) is the NSEC5 hash? Or is the SHA-256 hash skipped? Yes, the SHA-256(...) is the NSEC5 hash. The input is NSEC5 proof. Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 03/11/2015 05:19 PM, Jan Včelák wrote: It's not clear if the security goals make sense. What do zone operators gain if zone enumeration attacks are moved from offline to online, other than a need to provision additional server capacity? It's not that they can block resolution requests from large resolvers if a part of their client population participates in aggressive enumeration. It dependes whether you see zone enumeration as a problem. If I really want to enumerate a zone, I will just send my dictionary as queries, possibly through open resolvers. People are reckless like that. At least with NSEC3, polite attackers can do some of the processing off-line, without punishing authoritative servers or resolvers. NSEC5 takes away that option. Do the existing enumerators care? Who knows. Section 4 says, “NSEC5 hash is an SHA-256 hash function as specified in [RFC6234].” Are you sure that's right? You mean the reference to the RFC? Yes, I think it's right. Or am I missing something? I'm guessing, but “NSEC5 hash” is probably what involves FDH. Based on your comment,s it's clearly *not* SHA-256, contrary to what I quoted above. We deal with NSEC5 proofs and NSEC5 hashes (see the Terminology section). The NSEC5 proof is the FDH (can be comptuted only by the holder of the NSEC5 private key); the NSEC5 hash is an SHA-256 hash of the NSEC5 proof (everyone can compute it, if they know the NSEC5 proof). So in your notation, an NSEC5 RR owner name should be: Base32hex(SHA-256(FDH(Wire-Encode(owner name), privkey))) And the inner part (without the Base32 encoding) is the NSEC5 hash? Or is the SHA-256 hash skipped? You really need to make this explicit. I agree that the description is insufficient. We will fix that. Thanks. -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
Hello Florian, On 11.3.2015 12:01, Florian Weimer wrote: do you plan to submit this to an IETF working group, or as an individual submission? We plan to submit the draft as an individual submission. It's not clear if the security goals make sense. What do zone operators gain if zone enumeration attacks are moved from offline to online, other than a need to provision additional server capacity? It's not that they can block resolution requests from large resolvers if a part of their client population participates in aggressive enumeration. It dependes whether you see zone enumeration as a problem. NSEC5 is designed as an alternative to NSEC/NSEC3, not a replacement. If you consider the data in your zone public, use NSEC. If you need Opt-Out, use NSEC3. If you don't want attackers to enumerate your zone, use NSEC5 (or disable DNSSEC [sic]). And you are right, NSEC5 creates additional performance capacity requirement. Everything comes at a price. Section 4 says, “NSEC5 hash is an SHA-256 hash function as specified in [RFC6234].” Are you sure that's right? You mean the reference to the RFC? Yes, I think it's right. Or am I missing something? In any case, most references to “NSEC5 hash” are underspecified. For example, in section 9.1, “The owner name of the NSEC5 RR is the NSEC5 hash of the original owner name encoded in Base32hex without padding, prepended as a single label to the zone name”, could be read in various different ways. It seems that Base32hex(SHA-256(Wire-Encode(owner name))) is meant, but it could also be read as SHA-256(Base32hex(owner name)) or something like that. OK. You are right. It is underspecified. In addition, there is an error in the quoted text. Therefore both of your interpretations are incorrect. I will fix that. We deal with NSEC5 proofs and NSEC5 hashes (see the Terminology section). The NSEC5 proof is the FDH (can be comptuted only by the holder of the NSEC5 private key); the NSEC5 hash is an SHA-256 hash of the NSEC5 proof (everyone can compute it, if they know the NSEC5 proof). So in your notation, an NSEC5 RR owner name should be: Base32hex(SHA-256(FDH(Wire-Encode(owner name), privkey))) There does not seem to be anything in the draft that describes how the RDATA of the NSEC5PROOF is computed. I think the intent is that it contains SHA-256(Wire-Encode(NSEC5 owner name)), and the validation is performed using a separate RRSIG record, signed with the NSEC5KEY public key. However, section 9.2 does not mention that the NSEC5PROOF record is accompanied by an RRSIG RRset. A few sentences are in 7.1. (NSEC5PROOF RDATA Wire Format): Owner Name Hash is a variable sized sequence of binary octets encoding the NSEC5 proof corresponding to the owner name. It's the NSEC5 proof. Again, in your notation: FDH(Wire-Encode(owner name), privkey)) I agree that the description is insufficient. We will fix that. The rollover mechanism in section 9.3 does not work reliably. The old public key must be kept around until the TTL on the old NSEC5 and NSEC5PROOF RRs have expired (after the authoritative servers stopped serving them). The old public key cannot be removed immediately. It must be possible to re-fetch it in case a caching resolver expired it for some reason. You are right. This is wrong. I will fix that. In Section 11.1, “at least one of the keys MUST validate”: This MUST is misleading because the section is about validator behavior, it needs to be lower case because this section cannot establish constraints on validator input. There needs to be some discussion regarding the TTL on the NSEC5PROOF record, the validator should not accept arbitrary values there. Good point. These days, online signatures should really use a non-deterministic signature scheme. The deterministic FDH algorithm is very difficult to implement correctly. But it is not actually referenced in the draft, there are no protocol elements that use FDH values. NSEC5 relies on deterministic signature scheme for NSEC5 proofs. We can't really use non-deterministic scheme, because we need exactly one valid signature for a domain name and a key. If the signature scheme allowed to issue two different valid signatures for one input, the slave servers could cheat on the client. Because that would render different NSEC5 hashes and thus different positions in the NSEC5 chain. Why is the FDH difficult to implement? Take a look at Appendix A. in our draft. I also wrote a reference implementation for FDH in OpenSSL and GnuTLS/Nettle. You can take a look at it and review the code (nobody did it yet): https://gitlab.labs.nic.cz/knot/nsec5-crypto As specified in the draft, the NSEC5 protocol still exposes the chain of SHA-256 hashes of owner names. It does not offer better protection against offline dictionary attacks than NSEC3. Not really. The chain is build from NSEC5 hashes. And the client cannot compute the NSEC5 hash without having the NSEC5 proof. And
Re: [DNSOP] Comments regarding the NSEC5
On Mar 11, 2015, at 9:39 AM, Jan Včelák jan.vce...@nic.cz wrote: On 11.3.2015 17:30, Florian Weimer wrote: On 03/11/2015 05:19 PM, Jan Včelák wrote: It's not clear if the security goals make sense. What do zone operators gain if zone enumeration attacks are moved from offline to online, other than a need to provision additional server capacity? It's not that they can block resolution requests from large resolvers if a part of their client population participates in aggressive enumeration. It dependes whether you see zone enumeration as a problem. If I really want to enumerate a zone, I will just send my dictionary as queries, possibly through open resolvers. People are reckless like that. At least with NSEC3, polite attackers can do some of the processing off-line, without punishing authoritative servers or resolvers. NSEC5 takes away that option. Do the existing enumerators care? Who knows. I really can't tell. I don't know. Proposal: until there is evidence that there is a community that needs the features of NSEC5 that cannot be easily replicated in NSEC3, this WG does not consider a protocol change that would require every resolver to be updated. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
