Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
Hi Andrew, If I understand your question correctly, you are asking whether in the instance that a DNS server receives and caches a NXDOMAIN for some/all .onion, whether that could impact software which uses Tor? Software which uses Tor does so via a proxy which internally performs the resolution of the target “.onion” address (or any website, via Tor) into a TCP-like circuit which connects to the destination server. Thus the situation should be that either: a) the software in question is talking to a Tor proxy which acts as a gateway to the Tor network (and to the rest of the internet-via-Tor) which resolves .onion” addresses meaningfully, or else: b) the software in question is *not* talking to a Tor proxy, and therefore cannot meaningfully resolve or communicate with onion addresses, nor use the Tor network. If the software is somehow both talking and bypassing the proxy, my sense is that it would be the software's responsibility to deal with the self-imposed complex situation in a sane manner; an example of this might be http://en.wikipedia.org/wiki/Tor2web -a On 3/21/15, 11:12 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: In section 4, 3-5, what if a synthetic NXDOMAIN gets generated and cached? Will that have any effect on .onion resolution? If this is explained in detail in some thing I've failed to follow, a simple reference would be enough. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
First, sorry, I don't know why I wrote section 4; this is section 2, but I think you understood me. On Mon, Mar 23, 2015 at 12:57:53PM +, Alec Muffett wrote: a) the software in question is talking to a Tor proxy which acts as a gateway to the Tor network (and to the rest of the internet-via-Tor) which resolves .onion” addresses meaningfully, or else: b) the software in question is *not* talking to a Tor proxy, and therefore cannot meaningfully resolve or communicate with onion addresses, nor use the Tor network. This is what I assumed. The key point is that it doesn't break anything that ought to be depending on those onion addresses, so even if somehow the onion name leaked and ended up in the DNS, it's not a big deal because it won't negatively affect correctly-implemented onion-using clients and it won't negatively affect anyone trying to use onion in the DNS (because there shouldn't be any such person). It might be worth adding a sentence or two after the list in section 2 to that effect. Perhaps, It is important to note that any contamination of DNS caches with onion names cannot have a negative affect on any correctly-operating software. No application implementing Tor should be looking these names up in the DNS and no Tor-unaware application should expect to look up these names successfully. (I once before had someone claim to me that the latter isn't actually true, but I think it must be or the description of onion in this draft is completely wrong.) Best regards, A If the software is somehow both talking and bypassing the proxy, my sense is that it would be the software's responsibility to deal with the self-imposed complex situation in a sane manner; an example of this might be http://en.wikipedia.org/wiki/Tor2web -a On 3/21/15, 11:12 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: In section 4, 3-5, what if a synthetic NXDOMAIN gets generated and cached? Will that have any effect on .onion resolution? If this is explained in detail in some thing I've failed to follow, a simple reference would be enough. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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] RFC 7477 on Child-to-Parent Synchronization in DNS
Bob Harold rharo...@umich.edu writes: My apologies for not seeing this sooner. In section 5. Security Considerations: Hi Bob, I've been stewing over this one in my head for a few days since I saw your message. In short: I agree with you and am now slapping myself silly. I suspect as is it's not awful, but not ideal. I'm not sure an errata would be sufficient for such a change and if it'd be allowed for such a major processing change. I'll speak to some people about it this week and see what others say. -- Wes Hardaker Parsons ___ 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
