Re: [DNSOP] Should root-servers.net be signed
On Mar 20, 2010, at 1:50 AM, George Barwood wrote: Enshrining tho shalt never fragment into the Internet Architecture is dangerous, and will cause far MORE problems. Having something which regularly exercises fragmentation as critical to the infrastructure and we wouldn't have this problem where 10% of the resolvers are broken WRT fragmentation. I'm not suggesting that. If the higher level protocol has definite security checks, or security is not important, fragmentation is ok. But for DNSSEC neither of these is true. Then what you're arguing here is don't request stuff with DO unless you are willing to validate. Given the exercise of DO requesting is done (the firewalls have figured it out), drop DO on unvalidated traffic, don't drop fragmentation. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
- Original Message - From: Nicholas Weaver nwea...@icsi.berkeley.edu To: George Barwood george.barw...@blueyonder.co.uk Cc: Nicholas Weaver nwea...@icsi.berkeley.edu; dnsop@ietf.org Sent: Saturday, March 20, 2010 2:26 PM Subject: Re: [DNSOP] Should root-servers.net be signed On Mar 20, 2010, at 1:50 AM, George Barwood wrote: Enshrining tho shalt never fragment into the Internet Architecture is dangerous, and will cause far MORE problems. Having something which regularly exercises fragmentation as critical to the infrastructure and we wouldn't have this problem where 10% of the resolvers are broken WRT fragmentation. I'm not suggesting that. If the higher level protocol has definite security checks, or security is not important, fragmentation is ok. But for DNSSEC neither of these is true. Then what you're arguing here is don't request stuff with DO unless you are willing to validate. Given the exercise of DO requesting is done (the firewalls have figured it out), drop DO on unvalidated traffic, don't drop fragmentation. What I'm suggesting is that there is currently a real security problem (worse than Kaminsky), and the most practical way to fix it is for servers not to send UDP responses that will fragment. For example, the recently signed UK zone, which is an immediate concern for me. There is no practical reduction in performance for zones that mostly issue referrals. Normal responses will easily fit into 1450 byte packets for sensible key sizes ( actually much less - about 800 bytes should be sufficient, maybe a bit more during key rollover ). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
- Original Message - From: Nicholas Weaver nwea...@icsi.berkeley.edu To: Matt Larson mlar...@verisign.com Cc: dnsop@ietf.org; Nicholas Weaver nwea...@icsi.berkeley.edu Sent: Tuesday, March 09, 2010 3:31 PM Subject: Re: [DNSOP] Should root-servers.net be signed On Mar 9, 2010, at 7:17 AM, Matt Larson wrote: On Mon, 08 Mar 2010, George Barwood wrote: It's interesting to note that currently dig any . @a.root-servers.net +dnssec truncates, leading to TCP fallback but dig any . @l.root-servers.net +dnssec does not truncate ( response size is 1906 bytes ). a.root-servers.net's six anycast instances currently all run BIND 9 configured with max-udp-size 1472 to avoid sending responses larger than the Ethernet MTU. This was a conscious conservative choice and the infrastructure is capable of handling the resulting increased TCP load. I'd set it at 1450 personally, because you do have some encapulation over ethernets (eg, PPPoE, IPSEC) which occur, so if the goal is almost guarenteed no fragments, you need to leave a little additional headroom. +1 But given the current observed difficulty that resolvers have with fragments, this is, IMO, a very good decision. +1 I suggest the default value in BIND for max-udp-size should be 1450. This appears to be best practice. Since few zones are currently signed, it's not too late to make this change. Later on it may be more difficult. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mar 19, 2010, at 12:21 AM, George Barwood wrote: I suggest the default value in BIND for max-udp-size should be 1450. This appears to be best practice. Since few zones are currently signed, it's not too late to make this change. Later on it may be more difficult. Actually, I'd say this ONLY for the root and TLDs. For the rest, the onus should be on the resolver to discover that it can't handle fragmentation and adjust the MTU appropriately. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
- Original Message - From: Nicholas Weaver nwea...@icsi.berkeley.edu To: George Barwood george.barw...@blueyonder.co.uk Cc: Nicholas Weaver nwea...@icsi.berkeley.edu; Matt Larson mlar...@verisign.com; dnsop@ietf.org Sent: Friday, March 19, 2010 12:33 PM Subject: Re: [DNSOP] Should root-servers.net be signed On Mar 19, 2010, at 12:21 AM, George Barwood wrote: I suggest the default value in BIND for max-udp-size should be 1450. This appears to be best practice. Since few zones are currently signed, it's not too late to make this change. Later on it may be more difficult. Actually, I'd say this ONLY for the root and TLDs. For the rest, the onus should be on the resolver to discover that it can't handle fragmentation and adjust the MTU appropriately. There are advantages besides messages being lost. It also prevents spoofing of fragments, and limits amplification attacks. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mar 19, 2010, at 6:09 AM, George Barwood wrote: - Original Message - From: Nicholas Weaver nwea...@icsi.berkeley.edu To: George Barwood george.barw...@blueyonder.co.uk Cc: Nicholas Weaver nwea...@icsi.berkeley.edu; Matt Larson mlar...@verisign.com; dnsop@ietf.org Sent: Friday, March 19, 2010 12:33 PM Subject: Re: [DNSOP] Should root-servers.net be signed On Mar 19, 2010, at 12:21 AM, George Barwood wrote: I suggest the default value in BIND for max-udp-size should be 1450. This appears to be best practice. Since few zones are currently signed, it's not too late to make this change. Later on it may be more difficult. Actually, I'd say this ONLY for the root and TLDs. For the rest, the onus should be on the resolver to discover that it can't handle fragmentation and adjust the MTU appropriately. There are advantages besides messages being lost. It also prevents spoofing of fragments, and limits amplification attacks. It doesn't limit amplification attacks by much if at all, and spoofing of fragments is not likely to be happening in large responses, because large responses will almost invariably be due to DNSSEC. Since 90% CAN handle fragments, those 90% SHOULD be able to use fragments, especially since the broken 10% will see higher lookup latency, NOT full failure to resolve. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
It cuts the response from 4K to 1.5K, and I think fragmentation that contributes to these attacks being damaging. All I need to do is find a set of open resolvers which don't have such limits to do juuust fine. Eventually the open resolvers will get updated, and thus these attacks will be effectively limited. I don't think anyone has conclusively proved they are not a risk. Actually, this doesn't apply, since the reason why ns.se is 2700B is all the RRSIGs in the additional section, which are after the A and records. So spoofing this part of the datagrams is pointless anyway, since that only has meaning if DNSSEC validation IS performed. Hold on - can't the spoofer can put whatever he likes in the fragment!? He is not limited to RRSIGs. George ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mar 19, 2010, at 12:20 PM, Nicholas Weaver wrote: HAHAHA. Not bloodly likely IMO: a lot of the open resolvers are broken end-user NATS and similar. Those will only be updated sometime around when hell freezes over. Stuff gets updated when its brokenness becomes obvious to the person who owns it. So revealing its brokenness is a mitzvah. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mar 19, 2010, at 12:01 PM, George Barwood wrote: Anyway, do we yet agree that 1450 is the best default for max-udp-size, and that higher values are dangerous?\ No: I agree it is the proper default for the TLD authorities and roots, but for everything else, the higher value should be what the resolver requests. Enshrining tho shalt never fragment into the Internet Architecture is dangerous, and will cause far MORE problems. Having something which regularly exercises fragmentation as critical to the infrastructure and we wouldn't have this problem where 10% of the resolvers are broken WRT fragmentation. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
From: Nicholas Weaver nwea...@icsi.berkeley.edu Date: Fri, 19 Mar 2010 12:48:24 -0700 ... Enshrining tho shalt never fragment into the Internet Architecture is dangerous, and will cause far MORE problems. Having something which regularly exercises fragmentation as critical to the infrastructure and we wouldn't have this problem where 10% of the resolvers are broken WRT fragmentation. +1. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On 3/19/10 8:32 AM, George Barwood wrote: There are advantages besides messages being lost. It also prevents spoofing of fragments, and limits amplification attacks. It doesn't limit amplification attacks by much if at all It cuts the response from 4K to 1.5K, and I think fragmentation that contributes to these attacks being damaging. and spoofing of fragments is not likely to be happening in large responses, because large .responses will almost invariably be due to DNSSEC. Resolvers may set DO=1 but not validate everything ( or even anything ). Taking .SE as an example, by sending an open resolver that doesn't/cannot randomize ports the query [ NS SE ] , if the .SE servers don't conceal the IP ID, only 1 spoof packet is needed, and poisoning is easy and certain, is it not? Note: the .SE example does not truncate, it's very unusual for a response to be truncated with a EDNS @ 1450. I think it's best to have a conservative value as the default setting, and that is 1450 bytes. 1450 is not a conservative value anymore. See RFC2460 Section 5. (dealing with IPv6/1280 - IPv4/1280) ,--- In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. '--- This should guide the recommended DNS message size fallback of say 1232 or less, depending upon other extension headers being used. Bill Manning suggested 1220B, see: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02996.html -Doug ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Tue, 09 Mar 2010, Wouter Wijngaards wrote: Also +1 for the consensus analysis about signing: not on the path of trust but still somewhat useful to do, but not add another TA for it. I have not seen any consensus emerge one way or another regarding signing root-servers.net. Even after .net is signed (in Q4 2010), I don't believe it's a given that root-servers.net should be signed. There is definitely a trade-off between increased response size and the incremental benefits of signing that needs to be weighed and evaluated. The answer is not obvious (to me, anyway). Personally, I currently lean against signing it. Matt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Tue, 09 Mar 2010, Tony Finch wrote: On Tue, 9 Mar 2010, Matt Larson wrote: Even after .net is signed (in Q4 2010) I note that Verisign's press releases say by Q1 2011 which I find rather hard to interpret. Why don't they say by the start of 2011? Do they mean in Q1 2011? Those are calendar quarters. When encountering by Q1 2011, I think it is safe to assume that what is meant is by the end of Q1 2011. That is the intent in this particular case. People on Twitter have been saying today that Verisign are planning to sign during the first half of 2011 though the link they are pointing to says by the first half of 2011. http://searchsecurity.techtarget.com/video/0,297151,sid14_gci1411162,00.html?track=sy160 What is the date of the actual deployment deadline? I don't know the source for the text on that web page, but the intent has been to consistently communicate that .net will signed during Q4 2010 and that .com will be signed during Q1 2011. There is definitely a trade-off between increased response size and the incremental benefits of signing that needs to be weighed and evaluated. In what situations is the larger response size a problem for root-servers.net? Why isn't it a problem for any other domain? I didn't mean to imply that it wasn't. If the address records corresponding to a zone's name servers do not in reside in the zone itself, I'd give strong consideration to not signing the zone containing those address records. For example, .com and .net are hosted on servers named in the gtld-servers.net zone, and we are not necessarily going to sign the gtld-servers.net zone (at least not right away): it's a question that needs careful weighing of the trade-offs. Admittedly, the root zone is special becase its apex NS RRset is queried for (./IN/NS priming queries), whereas other zones don't receive such queries as part of the normal resolution process. Matt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
In message 20100309145352.gb5...@dul1mcmlarson-l1-2.local, Matt Larson writes : On Tue, 09 Mar 2010, Wouter Wijngaards wrote: Also +1 for the consensus analysis about signing: not on the path of trust but still somewhat useful to do, but not add another TA for it. I have not seen any consensus emerge one way or another regarding signing root-servers.net. Even after .net is signed (in Q4 2010), I don't believe it's a given that root-servers.net should be signed. There is definitely a trade-off between increased response size and the incremental benefits of signing that needs to be weighed and evaluated. The answer is not obvious (to me, anyway). Personally, I currently lean against signing it. I would sign it at the DURZ stage so that you weed out the sites that will have problems at this stage with large priming queries not later. Matt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mon, 8 Mar 2010, Joe Abley wrote: Our[*] reasoning so far with respect to signing ROOT-SERVERS.NET can I think be paraphrased as follows: - if we sign ROOT-SERVERS.NET it will trigger large responses (the RRSIGs over the A and RRSets) which is a potential disadvantage Is it? Is DNSSEC that bad then? Why did we design it that way? - however, since the root zone is signed, validators can already tell when they are talking to a root server that serves bogus information How does that work without ROOT-SERVERS.NET being signed with a known trust anchor? How does my validating laptop know that the curent wifi is not spoofing a.ROOT-SERVERS.NET to some local IP? - signing ROOT-SERVERS.NET would result in potentially-harmful large responses with no increase in security If it is harmful, we should abandon DNSSEC? I also find Jim's point regarding NET rather compelling. If the NET zone is not signed, then validating responses from a signed ROOT-SERVERS.NET zone would require yet another trust anchor to be manually-configured. It's hard for me to agree that the aggregate operational complexity involved in those manual trust anchors, and the potential effects of a KSK-roll without synchronised updating of that static configuration, represents a smaller risk than leaving the zone unsigned, at least for now. If this logic is faulty then I'd love to hear about it. I agree about the trust anchor issue. Not so much with some of the statements above it. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
At 9:38 AM -0500 3/8/10, Joe Abley wrote: I also find Jim's point regarding NET rather compelling. If the NET zone is not signed, then validating responses from a signed ROOT-SERVERS.NET zone would require yet another trust anchor to be manually-configured. ...and to manually be removed in the future when the keys for root-servers.net are rolled. For bonus points, imagine the consequences of that happening after .net is signed. This list is DNSOP, not DNSEXT: we are tasked with thinking about the operational aspects of both doing and undoing a particular action, and the effects on the DNS for when that doing and undoing happens incorrectly. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mar 8, 2010, at 7:27 AM, Paul Wouters wrote: On Mon, 8 Mar 2010, Joe Abley wrote: Our[*] reasoning so far with respect to signing ROOT-SERVERS.NET can I think be paraphrased as follows: - if we sign ROOT-SERVERS.NET it will trigger large responses (the RRSIGs over the A and RRSets) which is a potential disadvantage Is it? Is DNSSEC that bad then? Why did we design it that way? - however, since the root zone is signed, validators can already tell when they are talking to a root server that serves bogus information How does that work without ROOT-SERVERS.NET being signed with a known trust anchor? How does my validating laptop know that the curent wifi is not spoofing a.ROOT-SERVERS.NET to some local IP? If your ISP is acting as a MitM on DNS, its acting as a MitM on everything, so DNSSEC buys you f-all if you are using it for A records, because any app using that A record either doesn't trust the net or is trivially p0owned by the ISP. DNSSEC is ONLY useful for things like TXT and CERT records fetched by a DNSSEC aware cryptographic application, and that would require a valid signature chain from the root(s) of trust (either preconfigured or on a path from the signed root) validated on the client, so an imitation a.root-servers.net won't matter, as it won't be able to provide improper data. So in your example, root-servers.net doesn't need to be signed, and buys no increase in trust WHETHER IT IS SIGNED OR NOT, because even if it IS signed, that coveys no value about the results returned from it, because the signatures are not along the trust heirarchy for DNSSEC, which follows the name path, not the lookup path. Remember, DNSSEC is a PKI, with only one path of trust which matches the name path (so, for *.foo.bar.com, the trust path is foo.bar.com, bar.com, .com, ., either to a signed root, a signed TLD, or a trust anchor configured for either bar.com or foo.bar.com) [1]. You MUST be able to validate along the path (the transitive trust of a PKI), but you ONLY need to validate along the path (the limited trust of a PKI). Thus although root-servers.net is a domain involved in the resolution of anything for *.foo.bar.com (its on the resolution path), it is not on the trust path, so whether it is signed or not has no impact on whether the chain up will validate cryptographically. QED: Signing root-servers.net should be done for completeness, but only AFTER .net is signed, because really, its a signature path that doesn't actually matter and SHOULDN'T actually be validated for normal lookups [2], but only when the values are directly requested by a cilent! [1] And this is why I want DNSSEC: it IS a PKI and should be used as such, but one with a much cleaner trust path than the SSL-model PKI, and without adding any NEW trust paths to the system as this is the same trust path needed for normal DNS. [2] I really don't like DNSSEC's reliance on the recursive resolver to do signature validations, because there really is no right answer for what the recursive resolver should do on cryptographic failures (contrast with the client where there are good answers). But if the recursive resolver IS validating DNSSEC, it MUST ONLY validate the path of trust for the names requested by the client, simply to minimize spurious and irrelevant cryptographic failures. If the recursive resolver is validating the signatures of root-servers.net for internal use, it is doing it wrong: something which reduces reliability but doesn't increase security. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mon, 8 Mar 2010, Nicholas Weaver wrote: If your ISP is acting as a MitM on DNS, its acting as a MitM on everything, so DNSSEC buys you f-all if you are using it for A records, because any app using that A record either doesn't trust the net or is trivially p0owned by the ISP. If I detect an in-path attacker, I can choose to disconnect from that network. That is not buying f-all. It's useful to know when you are under attack. DNSSEC is ONLY useful for things like TXT and CERT records fetched by a DNSSEC aware cryptographic application, and that would require a valid signature chain from the root(s) of trust (either preconfigured or on a path from the signed root) validated on the client, so an imitation a.root-servers.net won't matter, as it won't be able to provide improper data. I understand that :P So in your example, root-servers.net doesn't need to be signed, and buys no increase in trust WHETHER IT IS SIGNED OR NOT, because even if it IS signed, that coveys no value about the results returned from it, because the signatures are not along the trust heirarchy for DNSSEC, which follows the name path, not the lookup path. If it was signed (along with .net) or via DLV or manual trust anchor, again I could tell I am under attack and disconnect from the rogue network. There is a use for that. Though I agree with people who say this is better done when a full path of trust from the root down is in place to avoid more manual configuration. [1] And this is why I want DNSSEC: it IS a PKI and should be used as such, but one with a much cleaner trust path than the SSL-model PKI, and without adding any NEW trust paths to the system as this is the same trust path needed for normal DNS. No need to preach to the choir. We were the ones (ab)using KEY records for IPSEC-OE. [2] I really don't like DNSSEC's reliance on the recursive resolver to do signature validations, because there really is no right answer for what the recursive resolver should do on cryptographic failures (contrast with the client where there are good answers). That problem never goes away, see how browsers handle cert failures But if the recursive resolver IS validating DNSSEC, it MUST ONLY validate the path of trust for the names requested by the client, simply to minimize spurious and irrelevant cryptographic failures. If the recursive resolver is validating the signatures of root-servers.net for internal use, it is doing it wrong: something which reduces reliability but doesn't increase security. I don't agree with your in path view. If I need to validate a nameserver ns.foo.bar., then yes it needs to attempt to validate the path . - bar. - foo.bar. - ns.foo.bar.. Or instead of validate, at least needs to confirm not verifiably bogus in the absense of DNSSEC for certain parts if the tree. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mon, 8 Mar 2010, Joe Abley wrote: - signing ROOT-SERVERS.NET would result in potentially-harmful large responses with no increase in security Can't you deal with this by omitting the root-servers.net RRSIGs from the additional section of responses to queries to the root? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
Joe Abley wrote: On 2010-03-08, at 10:27, Paul Wouters wrote: On Mon, 8 Mar 2010, Joe Abley wrote: Our[*] reasoning so far with respect to signing ROOT-SERVERS.NET can I think be paraphrased as follows: - however, since the root zone is signed, validators can already tell when they are talking to a root server that serves bogus information How does that work without ROOT-SERVERS.NET being signed with a known trust anchor? Because validators are equipped with a trust anchor for the root zone's KSK. An unsigned ROOT-SERVERS.NET might leave validators talking to a bogus root server, but they won't believe any of the signed replies they get from it. That is a narrow view of what a bogus root server may do. It may also replicate every official root signatures (basically signed delegations) and spoof unsigned delegations. Your enemy may make a bogus signed TLD nameserver with the same strategy so that unsigned delegations to SLD can also be spoofed. If DNSSEC usage includes validation of A/, then signed A/ for nameservers at the root and TLD seem to provide some (arguably marginal but not null) integrity assurance for unsigned domains. That's just an observation on the above reasoning. A full pros and cons analysis is obviously more encompassing. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mar 8, 2010, at 9:31 AM, Thierry Moreau wrote: Joe Abley wrote: On 2010-03-08, at 10:27, Paul Wouters wrote: On Mon, 8 Mar 2010, Joe Abley wrote: Our[*] reasoning so far with respect to signing ROOT-SERVERS.NET can I think be paraphrased as follows: - however, since the root zone is signed, validators can already tell when they are talking to a root server that serves bogus information How does that work without ROOT-SERVERS.NET being signed with a known trust anchor? Because validators are equipped with a trust anchor for the root zone's KSK. An unsigned ROOT-SERVERS.NET might leave validators talking to a bogus root server, but they won't believe any of the signed replies they get from it. That is a narrow view of what a bogus root server may do. It may also replicate every official root signatures (basically signed delegations) and spoof unsigned delegations. Your enemy may make a bogus signed TLD nameserver with the same strategy so that unsigned delegations to SLD can also be spoofed. If DNSSEC usage includes validation of A/, then signed A/ for nameservers at the root and TLD seem to provide some (arguably marginal but not null) integrity assurance for unsigned domains. That's just an observation on the above reasoning. A full pros and cons analysis is obviously more encompassing. But in order to BECOME the bogus nameserver, the attacker is becoming a MitM, so the attacker can just directly spoof any non-valid reply, they don't need to spoof the reply to become the bogus nameserver, but the unsigned replies directly. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
- Original Message - From: Joe Abley jab...@hopcount.ca To: Tony Finch d...@dotat.at Cc: George Barwood george.barw...@blueyonder.co.uk; dnsop@ietf.org Sent: Monday, March 08, 2010 4:22 PM Subject: Re: [DNSOP] Should root-servers.net be signed On 2010-03-08, at 11:18, Tony Finch wrote: On Mon, 8 Mar 2010, Joe Abley wrote: - signing ROOT-SERVERS.NET would result in potentially-harmful large responses with no increase in security Can't you deal with this by omitting the root-servers.net RRSIGs from the additional section of responses to queries to the root? Are you suggesting that we implement a coordinated code change to all root servers in the name of security or stability? Diversity in operation and code base is usually thought to be a strength of the root server system. It's interesting to note that currently dig any . @a.root-servers.net +dnssec truncates, leading to TCP fallback but dig any . @l.root-servers.net +dnssec does not truncate ( response size is 1906 bytes ). George ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
In message 43fc3f50679f458a869f99d72ecd1...@localhost, George Barwood write s: - Original Message - From: Joe Abley jab...@hopcount.ca To: Tony Finch d...@dotat.at Cc: George Barwood george.barw...@blueyonder.co.uk; dnsop@ietf.org Sent: Monday, March 08, 2010 4:22 PM Subject: Re: [DNSOP] Should root-servers.net be signed On 2010-03-08, at 11:18, Tony Finch wrote: On Mon, 8 Mar 2010, Joe Abley wrote: - signing ROOT-SERVERS.NET would result in potentially-harmful large responses with no increase in security Can't you deal with this by omitting the root-servers.net RRSIGs from the additional section of responses to queries to the root? Are you suggesting that we implement a coordinated code change to all root servers in the name of security or stability? Diversity in operation and code base is usually thought to be a strength of the root server system. It's interesting to note that currently dig any . @a.root-servers.net +dnssec truncates, leading to TCP fallback but dig any . @l.root-servers.net +dnssec does not truncate ( response size is 1906 bytes ). George A.ROOT-SERVERS.NET would appeared to be configured to not send DNS responses that will result in fragmentation leading to a artificially higher TCP load. For named max-udp-size is what controls this. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
Nicholas Weaver wrote: DNSSEC is ONLY useful for things like TXT and CERT records fetched by a DNSSEC aware cryptographic application, and that would require a valid signature chain from the root(s) of trust (either preconfigured or on a path from the signed root) validated on the client, so an imitation a.root-servers.net won't matter, as it won't be able to provide improper data. DNSSEC is still not useful, because attackers can pretend that retail ISPs can't pass DNSSEC packets. Then, there is a choice of: 1) not to use the net with untrustworthy zones and ISPs 2) to use the net even with untrustworthy zones and ISPs and most people will use the net anyway. Note that DNSSEC dose not make untrustworthy zones trustable. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On 2010-03-08, at 17:08, George Barwood wrote: It's interesting to note that currently dig any . @a.root-servers.net +dnssec truncates, leading to TCP fallback but dig any . @l.root-servers.net +dnssec does not truncate ( response size is 1906 bytes ). A runs BIND9, as far as I know. L runs NSD 3.2.4. Different implementations behave differently. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Should root-servers.net be signed
I have been wondering about this. For a resolver behind a NAT firewall that removes port randomization, it is possible for an attacker to spoof the priming query ( only 16 bits of ID protection ). If root-servers.net is unsigned, it's not possible for the resolver to validate the set of root IP addresses, meaning that (a) An attacker can control every unsigned zone. (b) An attacker can monitor every request to a signed zone ( no privacy ). (c) An attacker can deny service to any zone, on a selective basis. Apparently there are currently no plans to sign root-servers.net The main argument against seems to be that the priming query response size (with DO=1) would be greatly increased. Any thoughts?___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On 7 Mar 2010, at 08:06, George Barwood wrote: If root-servers.net is unsigned, it's not possible for the resolver to validate the set of root IP addresses So what? If the served zones are signed, it simply doesn't matter if the address of a name server is spoofed or hijacked. The Bad Guy won't have the private keys, so will be unable to return answers which validate. In the context of a referral from the root, what matters is the signature over the TLD's RRset (and its KSKs), not the IP address of the root server or any signature that might or might not exist over its name. (a) An attacker can control every unsigned zone. (b) An attacker can monitor every request to a signed zone ( no privacy ). (c) An attacker can deny service to any zone, on a selective basis. It's not clear what point you're making or what your concerns are. None of these things listed above are remotely relevant. Apart from (a) which is hardly news: zones can be spoofed if they're not signed. [What next? Can we expect revelations about what bears do in the woods?] Privacy -- whatever that might mean -- has never been a design goal of DNS. Or Secure DNS for that matter. An eavesdropper can monitor *any* DNS request (signed or not) if they're close enough to the client or server. DoS attacks can and are mounted on any zone, whether or not they're signed. Meanwhile, in other news, water is discovered to be wet and fire is proven to be hot. Apparently there are currently no plans to sign root-servers.net There's no point doing that IMO until .net is signed and there's a single chain of trust from root-servers.net to the One True Trust Anchor, the signed root. If the zone was to be self-signed, that would mean yet another TA would need to be embedded and maintained in validator configurations. Which creates more failure modes and scope for errors. And since validating the answers for root-servers.net will rarely if ever matter, adding that TA would be a lot of risk for almost no reward. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
Jim Reid wrote: The Bad Guy won't have the private keys, Wrong. While the Bad Guy as an ISP administrator won't have the private keys, the Bad Guy as a zone administrator will have the private keys. That is, DNSSEC is not secure cryptographically, which is another reason why not to deploy DNSSEC. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On 7 Mar 2010, at 12:47, Masataka Ohta wrote: While the Bad Guy as an ISP administrator won't have the private keys, the Bad Guy as a zone administrator will have the private keys. True, but irrelevant. The original discussion was a theoretical, misplaced concern about spoofed priming queries. It was not about whether the Bad Guy had control over the zone being spoofed. Please don't confuse the two. That is, DNSSEC is not secure cryptographically, which is another reason why not to deploy DNSSEC. This claim is ridiculous. Unless someone uncovers a fundamental flaw in public key cryptography, DNSSEC is secure cryptographically provided the private key(s) remain private. Now some people may (or may not) trust a third party to manage their keys and zone signing for them. That's their choice. It's just one of the many trade-offs that have to be considered in any sort of security system. For some, a private key held by a third party may well meet or exceed their security requirements. It takes a wild leap of the imagination and powerful reality distortion to use that as justification for the claims you made. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
Jim Reid wrote: While the Bad Guy as an ISP administrator won't have the private keys, the Bad Guy as a zone administrator will have the private keys. True, Good enough. This claim is ridiculous. Unless someone uncovers a fundamental flaw in public key cryptography, The fundamental flow of public key cryptography for its, wrongly claimed, cryptographical security is that trusted third parties are not cryptographically secure, which you have already said True,. As you can see that the Bad Guy as a zone administrator will have the private keys, there is no cryptographical security, here. DNSSEC is secure cryptographically provided the private key(s) remain private. The provision is not cryptographical. Now some people may (or may not) trust a third party to manage their keys and zone signing for them. That's their choice. Have you ever heard about such thing as monopoly? With monopoly, consumers do not have any choice, which is the case with DNS. You are totally bound to . and many are to .com. It's just one of the many trade-offs that have to be considered in any sort of security system. For some, a private key held by a third party may well meet or exceed their security requirements. That there are many operational trade-offs means that the security is not cryptographic. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mar 7, 2010, at 4:47 AM, Masataka Ohta wrote: Jim Reid wrote: The Bad Guy won't have the private keys, Wrong. While the Bad Guy as an ISP administrator won't have the private keys, the Bad Guy as a zone administrator will have the private keys. That is, DNSSEC is not secure cryptographically, which is another reason why not to deploy DNSSEC. I don't see what your argument here is. DNSSEC is a PKI in disguise, and like ANY PKI, you still depend on trust up the heirarchy, as that is exactly how a PKI is supposed to work: One level up says something about the levels down. But DNS has ALWAYS depended on trust-up-the-heirarchy anyway, so this aspect of DNSSEC doesn't increase the level of trust required in DNS, it just only codifies it in cryptographic terms so there is no trust (that isn't made explicit) beyond the scope up the heirarchy. This is actually why DNSSEC is useful: it IS a PKI, who's heirarchical nature already matches the existing heirarchy on naming. In the end, signing A records is useless. But signing TXT and CERT records will be incredibly useful, if validated on the end-host application. Additionally, since it would be end-host application validating those signatures, it can enforce that there must exist a signature path from the root (aka, it is actually a PKI). [1] But since unless you manually or do some other finagling can't easily establish trust if you don't have trust above, root-servers.net should only sign after .net is signed at this point in the rollout. And any PROPER useage of DNSSEC won't rely on root-servers.net ever being signed at all, because its only on the name path for resolvers. [1] Thus, you don't have to worry about also needing the name path for the resolvers signed or the DOS attack by a MitM stripping signatures as part of their changing DNS results. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
Nicholas Weaver wrote: That is, DNSSEC is not secure cryptographically, which is another reason why not to deploy DNSSEC. I don't see what your argument here is. DNSSEC is a PKI in disguise, and like ANY PKI, you still depend on trust up the heirarchy, Yes, you do understand the problem. But DNS has ALWAYS depended on trust-up-the-heirarchy anyway, so this aspect of DNSSEC doesn't increase the level of trust required in DNS, The problem is that DNSSEC was wrongly advertised to increase the level of security. The reality, however, is that ISPs are as secure/reliable/trustable as zones, which means DNSSEC does not increase the level of security. it IS a PKI PKI is broken, of course. So? Additionally, since it would be end-host application validating those signatures, it can enforce that there must exist a signature path from the root (aka, it is actually a PKI). [1] The meaningful security for end hosts is that the security is broken only if one of the end hosts is compromised, which means fate sharing, whereas, with DNSSEC, end hosts can do nothing if intermediate zones are compromised. [1] Thus, you don't have to worry about also needing the name path for the resolvers signed or the DOS attack by a MitM stripping signatures as part of their changing DNS results. MitM of a zone chain can easily change DNS results. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On 8/03/2010, at 8:03 AM, Masataka Ohta wrote: The problem is that DNSSEC was wrongly advertised to increase the level of security. I think you are picking your own definition of security to suit your argument. Those promoting DNSSEC have only ever said that the security it provides is basic validation of a) message originator and b) message integrity. The reality, however, is that ISPs are as secure/reliable/trustable as zones, which means DNSSEC does not increase the level of security. I don't understand what that means. Are you suggesting that DNSSEC should have some how dealt with insecure/unreliable/untrustworthy ISPs? it IS a PKI PKI is broken, of course. So? That is a bit like saying that all cars are broken because of a few problems Toyota are having. In other words it is a totally unsupported generalisation. Additionally, since it would be end-host application validating those signatures, it can enforce that there must exist a signature path from the root (aka, it is actually a PKI). [1] The meaningful security for end hosts is that the security is broken only if one of the end hosts is compromised, which means fate sharing, whereas, with DNSSEC, end hosts can do nothing if intermediate zones are compromised. DNS is largely asymmetric. On the whole I produce, others consume. So why would I need to fate-share with any consumer of my DNS messages? Your vision of security is for something quite different. Is this the essence of your grievance - DNSSEC has a chain of trust so any zone operator is dependent on another, thereby making a zone operator vulnerable to bad actors amongst those they depend on? If so then please explain how you can reliably get keys for my zones 1. without a relying on others in a chain of trust 2. in a way that scales kind regards Jay [1] Thus, you don't have to worry about also needing the name path for the resolvers signed or the DOS attack by a MitM stripping signatures as part of their changing DNS results. MitM of a zone chain can easily change DNS results. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mar 7 2010, George Barwood wrote: The dependency on .net for the root name servers seems strange to me. Intuitively, I should not have to trust .net to get a validated set of root name servers. The names of the root name servers are somewhat arbitrary, and since they are very integral to the root zone, it would seem more straight- forward to not put them into a public registry TLD, but rather to use a special TLD ( e.g. root-servers or possibly a sub-domain of ARPA ). I don't see any reason to use a sub-zone, the records may as well go in the root I think ( allows a secure resolver to start up slightly faster ). I have a lot of sympathy with that PoV. It's notable that draft-jabley-reverse-servers intends to put nameservers for the arpa sub-domains in matching sub-domains of arpa (but still seems to mandate more zone cuts than seem advisable to me). I note that .se does sign it's name servers. And indeed ns.se is in the se zone (no zone cut). But the consequence is that a DO=1 priming query for se returns 2706 bytes while one for . from the (DURZ-signed) root servers returns only 801 bytes. -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
In message 4b946242.7020...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Jay Daley wrote: I think you are picking your own definition of security to suit your argument. If you can deny the following reality: The reality, however, is that ISPs are as secure/reliable/trustable as zones, which means DNSSEC does not increase the level of security. feel free to deny me. Otherwise, accept the reality. Are you suggesting that DNSSEC should have some how dealt with insecure/unreliable/untrustworthy ISPs? DNS is dealt with zones as insecure/unreliable/untrustworthy as ISPs. There is plenty of evidence for ISPs modifying DNS responses to queries directed to their recursive servers without notifying the client population before doing so. There are also reports of ISPs modifying DNS responses not directed to their recursive servers. If you wish to include hotels in the ISP category (which they are for the duration of your stay at the hotel) then there is ample evidence of this happening. So yes I don't trust ISPs. DNS is largely asymmetric. On the whole I produce, others consume. So why would I need to fate-share with any consumer of my DNS messages? DNS? Fate sharing security is required for applicaitons running on end hosts. DNS security itself is abstract and is no goal. If so then please explain how you can reliably get keys for my zones 1. without a relying on others in a chain of trust I can't, which is why DNSSEC is as insecure as plain DNS. 2. in a way that scales It seems to me that cryptographic, end to end, or fate sharing security is not scalable. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
Nicholas Weaver wrote: And PKI, dispite what you say, is not broken. Heirarchical trust OR web of trust, you have to have some transitive trust to make a usable system. As the Internet (and telco net, too, which has been used for more than 100 years with moderate security) is the hierarchical trust OR the web of trust, to which PKI adds nothing, which is how PKI is broken. you have to have some transitive trust to make a usable system. Sure. We already have the transitive trust between ISPs of the Internet and plain old DNS is the usable system. DNSSEC adds nothing to it. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
Mark Andrews wrote: There is plenty of evidence for ISPs modifying DNS responses to queries directed to their recursive servers without notifying the client population before doing so. There are also reports of ISPs modifying DNS responses not directed to their recursive servers. If you wish to include hotels in the ISP category (which they are for the duration of your stay at the hotel) then there is ample evidence of this happening. Are you saying the ISPs and the hotel are phishing their customers? Or, are you just saying DNSSEC can not be used by customers of the ISPs and the hotel? So yes I don't trust ISPs. For doing (or not doing) what? I don't think ilegally behaving ISPs can continue thier business. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
