Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
On Mon, Sep 28, 2015 at 9:53 PM, Mukund Sivaraman wrote: > Hi Paul > > On Mon, Sep 28, 2015 at 02:36:25PM -0400, Paul Wouters wrote: > > On Mon, 28 Sep 2015, Paul Vixie wrote: > > > > >those things should also be done in the short term. > > > > > >but it's the internet. it'll outlive us all. we ought to have a long > > >term plan as well. > > > > It's called DNSSEC. > > Zone data validation and DNS message validation are two different > concepts. DNSSEC will not protect against DNS message modifications. > > DNSSEC provides support for end-to-end security (complete chain-of-trust > signature verification), something that a DNS message checksum/signature > cannot provide. On the other hand, DNSSEC requires signatures for each > RRset bloating messages, whereas a DNS message checksum/signature is > usually smaller as there is 1 per message. > > Anyway, I'll explain with an example why DNSSEC is not sufficient to > protect against DNS message modifications. Assume a company provides a > service in different countries. They want users in each country to use > the local CDN only, let's assume because users have no route to other > CDNs outside the country or because it's too expensive to service data > from other countries. They use views in DNS, each serving a different > country and the A/ records returned by the authoritative server > provides the correct IP address for that country. Assume that zones in > these views are signed using the same KSK/ZSK. > > This will work fine, but an attacker who has access to country A's > response may succeed in poisoning a message in country B with A's data > and DNSSEC validation will not catch it. DNSSEC protects each RRset, but > not the DNS message. > This is accepted risk signatures can be reused for the interval specified, for any purpose. > Also, there are other items in a DNS message aside from just signed zone > data. > > As your schema is useless against on-path attacker I recommend you take a look at making TKEY +TSIG easier to use, then we get the good property of message integrity. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Hi Paul On Tue, Sep 29, 2015 at 01:33:57AM -0400, Paul Wouters wrote: > On Tue, 29 Sep 2015, Mukund Sivaraman wrote: > > >On the other hand, DNSSEC requires signatures for each RRset bloating > >messages > > Just like TLS is bloating HTTP? :) TLS and HTTP are irrelevant here, no? The bloat by RRSIGs, considering just sizes, would be worse than that of TLS and HTTP per amount of data. > >Anyway, I'll explain with an example why DNSSEC is not sufficient to > >protect against DNS message modifications. Assume a company provides a > >service in different countries. They want users in each country to use > >the local CDN only, let's assume because users have no route to other > >CDNs outside the country or because it's too expensive to service data > >from other countries. They use views in DNS, each serving a different > >country and the A/ records returned by the authoritative server > >provides the correct IP address for that country. Assume that zones in > >these views are signed using the same KSK/ZSK. > > > >This will work fine, but an attacker who has access to country A's > >response may succeed in poisoning a message in country B with A's data > >and DNSSEC validation will not catch it. DNSSEC protects each RRset, but > >not the DNS message. > > Such a powerful attacker can also just reroute or NAT the IP addresses > of the one CDN to the other. Sure, it might be annoying to you but since > it is still using DNSSEC validated data that you deem valid for some > clients, it shouldn't be the end of the world either. The example I mentioned is still the case of an off-path attacker. For an attacker in country B, just having a shell account in country A will be sufficient to gather signed A/ records for country A. It would be the end of the world if the poisoned address is not routable in that location. The point is that zone data validation doesn't automatically guarantee that the DNS message is trustworthy. > I'm not convinced this draft is worth doing. But I don't see it causing > much harm either. > > Paul > Mukund pgp5lRl7Yngio.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
On Tue, 29 Sep 2015, Mukund Sivaraman wrote: On the other hand, DNSSEC requires signatures for each RRset bloating messages Just like TLS is bloating HTTP? :) Anyway, I'll explain with an example why DNSSEC is not sufficient to protect against DNS message modifications. Assume a company provides a service in different countries. They want users in each country to use the local CDN only, let's assume because users have no route to other CDNs outside the country or because it's too expensive to service data from other countries. They use views in DNS, each serving a different country and the A/ records returned by the authoritative server provides the correct IP address for that country. Assume that zones in these views are signed using the same KSK/ZSK. This will work fine, but an attacker who has access to country A's response may succeed in poisoning a message in country B with A's data and DNSSEC validation will not catch it. DNSSEC protects each RRset, but not the DNS message. Such a powerful attacker can also just reroute or NAT the IP addresses of the one CDN to the other. Sure, it might be annoying to you but since it is still using DNSSEC validated data that you deem valid for some clients, it shouldn't be the end of the world either. I'm not convinced this draft is worth doing. But I don't see it causing much harm either. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Hi Paul On Mon, Sep 28, 2015 at 02:36:25PM -0400, Paul Wouters wrote: > On Mon, 28 Sep 2015, Paul Vixie wrote: > > >those things should also be done in the short term. > > > >but it's the internet. it'll outlive us all. we ought to have a long > >term plan as well. > > It's called DNSSEC. Zone data validation and DNS message validation are two different concepts. DNSSEC will not protect against DNS message modifications. DNSSEC provides support for end-to-end security (complete chain-of-trust signature verification), something that a DNS message checksum/signature cannot provide. On the other hand, DNSSEC requires signatures for each RRset bloating messages, whereas a DNS message checksum/signature is usually smaller as there is 1 per message. Anyway, I'll explain with an example why DNSSEC is not sufficient to protect against DNS message modifications. Assume a company provides a service in different countries. They want users in each country to use the local CDN only, let's assume because users have no route to other CDNs outside the country or because it's too expensive to service data from other countries. They use views in DNS, each serving a different country and the A/ records returned by the authoritative server provides the correct IP address for that country. Assume that zones in these views are signed using the same KSK/ZSK. This will work fine, but an attacker who has access to country A's response may succeed in poisoning a message in country B with A's data and DNSSEC validation will not catch it. DNSSEC protects each RRset, but not the DNS message. Also, there are other items in a DNS message aside from just signed zone data. Mukund pgpcnsqYauEkq.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Hi Robert On Mon, Sep 28, 2015 at 02:20:04PM -0400, Robert Edmonds wrote: > Mukund Sivaraman wrote: > > Hi Robert > > > > On Mon, Sep 28, 2015 at 01:30:28PM -0400, Robert Edmonds wrote: > > > 16 bits is an awful lot of space for the ALGORITHM field. Compare to > > > the DNSSEC algorithm number field, which is only 8 bits. > > > > Do you suggest changing it to 8 bits too? > > If you keep an algorithm field, yes, I suggest changing it to 8 bits. OK. I'll make this change. :) > It seems unlikely more than one or two algorithms would ever be > implemented. Is algorithm agility really needed, though, given that > there are ~65000 unused EDNS0 option codes? If I follow correctly, what you're suggesting is that if an algorithm becomes weak, we jump to a new EDNS option which has a different EDNS option code assigned. This seems like a bad idea to me, because as such option codes get assigned, they will be spread out and the code in DNS implementations which handle it will look dirty. It's better to keep it all under one option code, even if it occupies 1 more byte. > I am also curious why a cryptographic hash function (SHA-1) is needed > for this. Is a fast non-cryptographic checksum not suitable (e.g., > CRC-32C, which can be computed in hardware on x86 CPUs)? SHA-1 was chosen without too much consideration for anything. Appendix A was empty initially and SHA-1 was added as a placeholder to fill that section. The list of algorithms is best decided by discussion here, and SHA-1 can be removed if it is unsuitable. On the topic, I'll add a penny: checksum algorithms (as we want them here) have two extremes, one of which is to protect against accidental modifications of data, and another which is to protect against malicious/intentional modification of data. There are also others such as hashing functions (uniform distribution in the mapped output range, or something more specific). All these have different performance characteristics. CRCs serve towards the "accidental modifications" category, and SHA-1 towards the "intentional modification" one. We want something suitable in the latter category, a cryptographic hash function, though the level of security it provides need not be as high as that expected for a long-lived signature. Mukund pgpOklYowU4Y_.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
On Mon, 28 Sep 2015, Paul Vixie wrote: those things should also be done in the short term. but it's the internet. it'll outlive us all. we ought to have a long term plan as well. It's called DNSSEC. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
On 28 Sep 2015, at 11:25, Paul Vixie wrote: Robert Edmonds wrote: ... I am also curious why a cryptographic hash function (SHA-1) is needed for this. Is a fast non-cryptographic checksum not suitable (e.g., CRC-32C, which can be computed in hardware on x86 CPUs)? in currently theorized attacks, the udp checksum is fooled by altering two parts of a fragment: first, alter the part you want to use to inject poison into a cache. second, alter something else to fix up the checksum based on the first alteration. if CRC-32C is immune to that attack, i havn't heard, but i'd believe. Note that he said "e.g.". There are other algorithms much faster than SHA-1 that would work as well, such as the one in draft-eastlake-fnv. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Robert Edmonds wrote: > ... > > I am also curious why a cryptographic hash function (SHA-1) is needed > for this. Is a fast non-cryptographic checksum not suitable (e.g., > CRC-32C, which can be computed in hardware on x86 CPUs)? in currently theorized attacks, the udp checksum is fooled by altering two parts of a fragment: first, alter the part you want to use to inject poison into a cache. second, alter something else to fix up the checksum based on the first alteration. if CRC-32C is immune to that attack, i havn't heard, but i'd believe. > Also, there is a long deployment tail for new EDNS options. If it's > urgent to deploy a countermeasure against off-path fragment spoofing, > why not something like Unbound's "referral path hardening", or > advertising a smaller EDNS buffer size which is much less likely to > result in fragmentation? (E.g., I believe OpenDNS advertises a ~1.4 > Kbyte EDNS buffer size.) Those countermeasures can be deployed > unilaterally by the resolver, and on a shorter time scale than a new > EDNS option. > those things should also be done in the short term. but it's the internet. it'll outlive us all. we ought to have a long term plan as well. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Mukund Sivaraman wrote: > Hi Robert > > On Mon, Sep 28, 2015 at 01:30:28PM -0400, Robert Edmonds wrote: > > 16 bits is an awful lot of space for the ALGORITHM field. Compare to > > the DNSSEC algorithm number field, which is only 8 bits. > > Do you suggest changing it to 8 bits too? If you keep an algorithm field, yes, I suggest changing it to 8 bits. It seems unlikely more than one or two algorithms would ever be implemented. Is algorithm agility really needed, though, given that there are ~65000 unused EDNS0 option codes? I am also curious why a cryptographic hash function (SHA-1) is needed for this. Is a fast non-cryptographic checksum not suitable (e.g., CRC-32C, which can be computed in hardware on x86 CPUs)? Also, there is a long deployment tail for new EDNS options. If it's urgent to deploy a countermeasure against off-path fragment spoofing, why not something like Unbound's "referral path hardening", or advertising a smaller EDNS buffer size which is much less likely to result in fragmentation? (E.g., I believe OpenDNS advertises a ~1.4 Kbyte EDNS buffer size.) Those countermeasures can be deployed unilaterally by the resolver, and on a shorter time scale than a new EDNS option. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
On Mon, Sep 28, 2015 at 09:56:38AM -0700, Paul Vixie wrote: > so i think there's good cause to add a DNS-level checksum even as we add > DNS-level cookies. +1 I would prefer to use checksum and cookies in parallel rather than have the checksum option recapitulate cookie functionality, though. Unless I'm overlooking something, the NONCE field in Mukund's proposal becomes unnecessary if cookies are in use. Otherwise it seems like a very good idea. (It's a pity there's no version field in the COOKIE option format; COOKIE version 1 could have been extended to include a checksum.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Hi Robert On Mon, Sep 28, 2015 at 01:30:28PM -0400, Robert Edmonds wrote: > 16 bits is an awful lot of space for the ALGORITHM field. Compare to > the DNSSEC algorithm number field, which is only 8 bits. Do you suggest changing it to 8 bits too? Mukund pgpB1vCaaZvZT.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Mukund Sivaraman wrote: > This is a new draft on DNS message checksums. I look forward to hearing > review comments. Hi, Mukund: 16 bits is an awful lot of space for the ALGORITHM field. Compare to the DNSSEC algorithm number field, which is only 8 bits. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Mukund Sivaraman wrote: > Hi Paul > > On Mon, Sep 28, 2015 at 10:39:04AM -0400, Paul Wouters wrote: >> On Sun, 27 Sep 2015, Mukund Sivaraman wrote: >> >>> UDP has a header checksum that can notice message modification when in >>> use. Sometimes this may be 0 if the sender host did not generate a >>> checksum. This draft adds one in the application layer alongside a nonce >>> known to the client. Together they are meant to thwart any possibility >>> of different kinds of off-path cache-poisoning attacks. >> There is other work happening that accomplishes the same. The DPRIVE >> work to add TLS and longlived TCP, the dns cookies, and of course >> DNSSEC itself. I don't really see the need to add another mechanism to >> help against non-DNSSEC spoofing attacks. > > DNS cookies do not protect against IP fragmentation - they do not check > the message contents. These same things above can be said for DNS > cookies too. This draft intends to provide a method without the use of > additional roundtrips. noone has ever regretted adding an end-to-end checksum to any system. many have regretted trusting the lower-level network to deliver things perfectly. so i think there's good cause to add a DNS-level checksum even as we add DNS-level cookies. for extra credit, make it work on IXFR and AXFR as well (for the whole session, not just per-message.) -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Hi Paul On Mon, Sep 28, 2015 at 10:39:04AM -0400, Paul Wouters wrote: > On Sun, 27 Sep 2015, Mukund Sivaraman wrote: > > >UDP has a header checksum that can notice message modification when in > >use. Sometimes this may be 0 if the sender host did not generate a > >checksum. This draft adds one in the application layer alongside a nonce > >known to the client. Together they are meant to thwart any possibility > >of different kinds of off-path cache-poisoning attacks. > > There is other work happening that accomplishes the same. The DPRIVE > work to add TLS and longlived TCP, the dns cookies, and of course > DNSSEC itself. I don't really see the need to add another mechanism to > help against non-DNSSEC spoofing attacks. DNS cookies do not protect against IP fragmentation - they do not check the message contents. These same things above can be said for DNS cookies too. This draft intends to provide a method without the use of additional roundtrips. > >There are practical issues with TCP which are still currently prevelant: > > > >1. The 3 way handshake doubles the number of roundtrips necessary before > >an answer is received. > > But with clarifications like edns-tcp-keepalive, we are hoping that > clients can keep TCP connections to resolvers open for much longer, > so that TCP does not really have more overhead than UDP. It is not the connection between a client to resolver, but the connections between a resolver and authoritative servers that is a bottleneck during iteration. Keepalive doesn't help the initial connection establishment time. One can make a similar argument that once the data is cached, it's a lot faster. I mention the case of initial iteration during lookup of any new website, which is often the case with smaller local resolvers. > This draft also does nothing for on-path attackers. I have been considering this case ever since you mentioned it (in direct email). It is difficult to achieve this without using some kind of shared secret or public key method. 1. If any method used involves additional roundtrips for things like key retrival, TCP is a better bet. It will likely become a better option anyway one day. 2. If the zone is DNSSEC signed, then that is a better way to protect against forgery rather than using DNS message signatures. For unsigned zones, if it's possible to protect against forgery without additional roundtrips with a light-weight signature, it would definitely help and prevent on-path attackers. I have a scheme in mind for this, and I'll come back with an update once it settles down, but this would involve a chain-of-trust (where DNSSEC can be re-used where available). For unsigned zones and vanilla serving, I think the checksum draft is relevant as long as they exist. Mukund pgpp_K_EbqeNQ.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
On Sun, 27 Sep 2015, Mukund Sivaraman wrote: UDP has a header checksum that can notice message modification when in use. Sometimes this may be 0 if the sender host did not generate a checksum. This draft adds one in the application layer alongside a nonce known to the client. Together they are meant to thwart any possibility of different kinds of off-path cache-poisoning attacks. There is other work happening that accomplishes the same. The DPRIVE work to add TLS and longlived TCP, the dns cookies, and of course DNSSEC itself. I don't really see the need to add another mechanism to help against non-DNSSEC spoofing attacks. There are practical issues with TCP which are still currently prevelant: 1. The 3 way handshake doubles the number of roundtrips necessary before an answer is received. But with clarifications like edns-tcp-keepalive, we are hoping that clients can keep TCP connections to resolvers open for much longer, so that TCP does not really have more overhead than UDP. This draft also does nothing for on-path attackers. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Hi Paul I'm CC'ing this reply to the dnsop@ list as it is relevant info for others to read too. So I've not quoted your email. UDP has a header checksum that can notice message modification when in use. Sometimes this may be 0 if the sender host did not generate a checksum. This draft adds one in the application layer alongside a nonce known to the client. Together they are meant to thwart any possibility of different kinds of off-path cache-poisoning attacks. It is a simpler lesser form of DNS cookies that goes a little further from the client's perspective. If some countermeasures such as source port randomization are either turned off (perhaps when DNS cookies are in use; typically source port randomization has a significant performance penalty) or ineffective perhaps due to NAT, there is a remote possibility of poisoning with IP fragmentation. Note that this draft still cannot prevent some kinds of attack such as response and NS blocking and NS pinning as described in Herzberg and Shulman's paper (cited in the draft). There are practical issues with TCP which are still currently prevelant: 1. The 3 way handshake doubles the number of roundtrips necessary before an answer is received. With iteration, it can result in conspicuously increased average turnaround time in applications such as web-browsing as DNS is the starting point. This becomes noticable in a location such as where I live (India) from where the RTT to many of the mediumly-popular websites' DNS nameservers is quite high. There are some efforts to solve this such as TCP fast open, but not widely deployed. Once the records are cached everything is faster, but a delay is still a delay. RTT to almost everywhere significant is high from here. Also, OTOH, use of DNS cookies with UDP itself may require additional roundtrips. 2. There are concerns on whether using TCP is scalable for DNS. The dns-dev-coord list was setup to discuss this topic and try to improve TCP performance across implementations. But I agree, TCP-only is becoming more and more appealing/relevant with the number of issues in using UDP. Mukund pgpIB6r6jrTol.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
On Sun, Sep 27, 2015 at 12:45:52AM +0530, Mukund Sivaraman wrote: > > Abstract: > >This document describes a method for a client to be able to verify > >that IP-layer PDU fragments of a UDP DNS message have not been > >spoofed by an off-path attacker. The NONCE-COPY field seems redundant now as the checksum computation includes the NONCE field. It was added in an earlier form of the draft when the computation didn't include the nonce. Perhaps it can be removed and the NONCE field doubled in size. Mukund pgppHHhqMrIbn.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt
Hi everybody On Sat, Sep 26, 2015 at 12:10:09PM -0700, internet-dra...@ietf.org wrote: > > A new version of I-D, draft-muks-dns-message-checksums-00.txt > has been successfully submitted by Mukund Sivaraman and posted to the > IETF repository. > > Name: draft-muks-dns-message-checksums > Revision: 00 > Title:DNS message checksums > Document date:2015-09-27 > Group:Individual Submission > Pages:7 > URL: > https://www.ietf.org/internet-drafts/draft-muks-dns-message-checksums-00.txt > Status: > https://datatracker.ietf.org/doc/draft-muks-dns-message-checksums/ > Htmlized: > https://tools.ietf.org/html/draft-muks-dns-message-checksums-00 > > > Abstract: >This document describes a method for a client to be able to verify >that IP-layer PDU fragments of a UDP DNS message have not been >spoofed by an off-path attacker. This is a new draft on DNS message checksums. I look forward to hearing review comments. Mukund pgpanDjjhrytv.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
