Re: [dns-operations] Massive DNS poisoning attacks in Brazil
Paul Vixie p...@redbarn.org wrote: in http://www.ietf.org/mail-archive/web/dnsext/current/msg11700.html i was thinking that we'd add send chain as an edns option, and then add generic edns tunneling over tcp/80 and tcp/443 using distinctive URI patterns to make sure to plug into the dns responder in the remote web server. there's no reason to add 'send chain' just to the tunnel. and once the tunnel is open it should be able to remain open until a quiet period, so maybe a two second client-initiated timeout. I like this plan. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
From: Tony Finch d...@dotat.at To: Paul Vixie p...@redbarn.org Paul Vixie p...@redbarn.org wrote: in http://www.ietf.org/mail-archive/web/dnsext/current/msg11700.html i was thinking that we'd add send chain as an edns option, and then add I like this plan. All of those DNS tunneling, triggering, alternate port, and other varient protocol schemes for dealing with hotels and public access points attacks on DNS are either unnecessary in the long run or depend on practically no one ever using them. They are like the ad hoc schemes subscribers to this mailing list use to tunnel other protocols home. Any popular scheme that works around DNS, HTTP, ssh, etc. man-in-the-middle attacks that become popular will be blocked, proxied, or hijacked unless most users normally use tools that detect and refuse to work with men in the middle. If the browsers and stubb DNS servers of most users did DNSSEC, DANE, and HSTS, then any men in the middle will be obvious and won't be installed except for purposes that users tolerate including access point login, employment behind corporate firewalls, and living under authoritative regimes. In addition, those tunneling schemes will not unnecessary. To put it another way, if HTTP replaced IP as the Internet protocol without any real improvements in end to end security, then the censors and hijackers would apply their tools to HTTP. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
Vernon,
On Oct 3, 2012, at 6:38 AM, Vernon Schryver v...@rhyolite.com wrote:
Any popular scheme that works around DNS, HTTP, ssh, etc.
man-in-the-middle attacks that become popular will be blocked,
proxied, or hijacked unless most users normally use tools that
detect and refuse to work with men in the middle.
You're assuming the MITM attacks are intentional. My impression is that the
majority of the issues in getting EDNS0-requiring protocols to work are due to
ignorance, e.g., valid DNS responses are always UDP512bytes or valid DNS types
are {A,MX,SOA,NS,PTR,TXT}. If this is true, than egregious hack workarounds
like using HTTP/S as a transport will solve most of the problem (not that I
think this is the best solution).
Regards,
-drc
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Oct 3, 2012, at 6:38 AM, Vernon Schryver v...@rhyolite.com wrote: From: Tony Finch d...@dotat.at To: Paul Vixie p...@redbarn.org Paul Vixie p...@redbarn.org wrote: in http://www.ietf.org/mail-archive/web/dnsext/current/msg11700.html i was thinking that we'd add send chain as an edns option, and then add I like this plan. All of those DNS tunneling, triggering, alternate port, and other varient protocol schemes for dealing with hotels and public access points attacks on DNS are either unnecessary in the long run or depend on practically no one ever using them. They are like the ad hoc schemes subscribers to this mailing list use to tunnel other protocols home. Any popular scheme that works around DNS, HTTP, ssh, etc. man-in-the-middle attacks that become popular will be blocked, proxied, or hijacked unless most users normally use tools that detect and refuse to work with men in the middle. If the browsers and stubb DNS servers of most users did DNSSEC, DANE, and HSTS, then any men in the middle will be obvious and won't be installed except for purposes that users tolerate including access point login, employment behind corporate firewalls, and living under authoritative regimes. In addition, those tunneling schemes will not unnecessary. To put it another way, if HTTP replaced IP as the Internet protocol without any real improvements in end to end security, then the censors and hijackers would apply their tools to HTTP. I fully agree with all of this, but it leaves the question: what about tunneling DNS in TLS-over-HTTP? The earlier statement about why this would not work (corporations getting MITM certificates from bad actors in the root pile) doesn't actually apply because the client will have a single TLS trust anchor, possibly even one not even in the root pile. --Paul Hoffman ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Wed, 3 Oct 2012, Paul Hoffman wrote: I fully agree with all of this, but it leaves the question: what about tunneling DNS in TLS-over-HTTP? The earlier statement about why this would not work (corporations getting MITM certificates from bad actors in the root pile) doesn't actually apply because the client will have a single TLS trust anchor, possibly even one not even in the root pile. Why would the client even need a single trust anchor for this? Current unbound dns-over-tls completely ignores the TLS. It is only used to get out, not for any type of authentication of transport or data. Paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Oct 3, 2012, at 7:42 AM, Paul Wouters p...@cypherpunks.ca wrote: On Wed, 3 Oct 2012, Paul Hoffman wrote: I fully agree with all of this, but it leaves the question: what about tunneling DNS in TLS-over-HTTP? The earlier statement about why this would not work (corporations getting MITM certificates from bad actors in the root pile) doesn't actually apply because the client will have a single TLS trust anchor, possibly even one not even in the root pile. Why would the client even need a single trust anchor for this? For non-validating stubs. Current unbound dns-over-tls completely ignores the TLS. It is only used to get out, not for any type of authentication of transport or data. Right: a validating stub who is using HTTP-over-TLS only as tunneled DNS transport has no need to known the identity of the other party. --Paul Hoffman ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
From: Tony Finch d...@dotat.at You are right about dicking around with port numbers and TLS or HTTP framing. However the send chain EDNS option would be a widely useful operation for validating stubs. A stub validator could perhaps send DS and DNSKEY queries for all the truncated versions of the name between the target name and the root, which it would have to do concurrently to avoid latency pain, but then it will have to iterate this to deal with CNAME and/or DNAME chains. The recursor has already done all the work so it would be nice to get all the results back in one go. That's a good point, except I can only go with somewhat useful. On http://www.cnn.com/ just now I see only www.cnn.com, i.cdn.turner.com, i2.cdn.turner.com among about 33 images and icons. Getting the DNSSEC chains for those half dozen DNS names (I probably missed some and I disable most javascript) would save only a trivial few round trips for a stub with a cache given the round trips to fetch those images (and javascript). Besides, the saved round trips would be to the nearby trusted server that should be answering within 50 millseconds and closer and faster than the CDN box serving the content, not to mention web sites not served by the CDN box. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
From: David Conrad d...@virtualized.org
Any popular scheme that works around DNS, HTTP, ssh, etc.
man-in-the-middle attacks that become popular will be blocked,
proxied, or hijacked unless most users normally use tools that
detect and refuse to work with men in the middle.
You're assuming the MITM attacks are intentional.
No, I assume only either that the men in the middle will back off if
they irritate enough users or that they can be detected.
(Never mind corrupt DNS registrars or registries attacking DNSSEC.)
My impression
is that the majority of the issues in getting EDNS0-requiring
protocols to work are due to ignorance, e.g., valid DNS responses
are always UDP512bytes or valid DNS types are {A,MX,SOA,NS,PTR,TXT}.
If this is true, than egregious hack workarounds like using HTTP/S
as a transport will solve most of the problem (not that I think
this is the best solution).
If DNS/TLS/HTTP became popular, then the same actors that filter
DNS/UDP for 512 bytes or less common types would have the same
motives to do the same to DNS/TLS/HTTP. To filter 512 bytes or
RRSIG or TLSA records, you must be looking at the bits. Breaking
DNS is not accidental, not even with NAT. The reasons that require
or allow you to do whatever you're doing to DNS/UDP/IP would apply
to DNS/TLS/HTTP if DNS/TLS/HTTP were popular.
On the other hand, if many user computers have validating stubs that
compute SERVFAIL for broken DNSSEC and so make gethostbyname() in
applications fail, then many users will yell at hotel concierges for
$15/day WiFi that doesn't work and use LTE instead of paying $15/day.
Many hotels would change and allow EDNS0 after the sign-on. Employers
would either do the same or point to conditions of employement. State
actors would either do the same or send whiners to gulags.
} From: Andrew Sullivan a...@anvilwalrusden.com
} I see. So your model is that the application asks for a TLSA record,
} and if it gets one then it can infer that the record also passed
} validation?
} How can the application be sure the resolver is
} DNSSEC-aware?
The important answer is the same way the application can be sure
the resolver is not some other kind of malware.
The trivial answer is in the API used by the application to get TLSA
records. For gethostbyname(), HOST_NOT_FOUND in h_herrno is plenty
good enough for the SERVFAIL that comes from failure to validate A or
records. For other record types, you need either the record set,
the empty record set, or a half bit of a failure flag. Applications
do not now and will never care whether a failure is due to any of the
myriad of reasons for getting a SERVFAIL or REFUSED DNS DNS response,
including the new reason of failure to validate.
Vernon Schryverv...@rhyolite.com
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
Vernon, On Oct 3, 2012, at 8:57 AM, Vernon Schryver v...@rhyolite.com wrote: You're assuming the MITM attacks are intentional. No, I assume only either that the men in the middle will back off if they irritate enough users or that they can be detected. They can only back off if they're aware they are doing it. (Never mind corrupt DNS registrars or registries attacking DNSSEC.) Not corrupt, just inept. Which is, of course, a much more significant threat today than anything DNSSEC can protect against, but that's a rant for a different thread. Breaking DNS is not accidental, not even with NAT. Sure it is. CPE/firewall vendors have a long history of implementing the absolute minimum they can get away with that still sort of works (which, from a business perspective). In the past, DNS UDP512 (for CPE) and limited types (for firewalls) sort of worked. Then those evil greedy DNSEXT bastards went and modified the protocol, thereby breaking simplistic implementation assumptions. However, there is a lot of CPE/firewalls out there that needs to be upgraded. Hence suggestions like Paul's of egregious hacks like DNS/TLS/HTTP. On the other hand, if many user computers have validating stubs that compute SERVFAIL for broken DNSSEC and so make gethostbyname() in applications fail, then many users will yell at hotel concierges for $15/day WiFi that doesn't work and use LTE instead of paying $15/day. Many hotels would change and allow EDNS0 after the sign-on. Employers would either do the same or point to conditions of employement. State actors would either do the same or send whiners to gulags. I want to live in your world. In my world, the vast majority of users would simply turn off the features that caused their laptops/phones/etc. to not work and would rarely (if ever) complain to their service provider (even if they knew what to complain about). Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Wed, 3 Oct 2012, Andrew Sullivan wrote: If the application gets a TLSA record, it must have passed DNSSEC validation I see. So your model is that the application asks for a TLSA record, and if it gets one then it can infer that the record also passed validation? Hrm. That's an interesting answer, and it hadn't occurred to me before that the application could rely on such an inference. How can the application be sure the resolver is DNSSEC-aware? You are right that is a little complicated. There are a few options, - Trust the OS (not a very good option) - Trust the AD bit (marginally better) - Require localhost or specified (VPN protected) validators (i.e. like unbound+dnssec-trigger) but the best option for now seems to be: - Trust the OS for providing a root key - Use whatever resolver the OS has configured, but do validation within the application (i.e. libunbound, lwres, libval) In all scenarios, ignore TLSA records that are not protected by DNSSEC. And hopefully one day, the validation can be moved out of the applications and into glibc. Augment these with obtaining dnssec chains via different transports, feedomg these into the local resolver, which will validate the data before adding it to the cache. These could be blobs on some standard url (http://www.example.com/.dnssec.obj) that the owner of example.com could tailor to their requirements (eg add the required lookups for their advertisement provides, etc etc) It would be great if we could also do more aggressive pre-fetching of data too, so we could leave our house with preloaded DNS data for our most commonly used lookups. Although the TTL=0 people think otherwise. Paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Mon, Nov 07, 2011 at 02:01:14PM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 17 lines which said: http://www.securelist.com/en/blog/208193214/Massive_DNS_poisoning_attacks_in_Brazil A long article about DNS poisoning without even a dig output, bad. One sentence at the end seems to indicate it has nothing to do with DNS poisoning but that the cracker was able to hijack the router (in which cas all your bets are off). Much better and very detailed analysis (by the same author!) So, it was not DNS poisoning at all but a change in the DNS settings of the router, after the box was cracked. (DNSchanger-style) http://www.securelist.com/en/blog/208193852/The_tale_of_one_thousand_and_one_DSL_modems ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
Much better and very detailed analysis (by the same author!) So, it was not DNS poisoning at all but a change in the DNS settings of the router, after the box was cracked. (DNSchanger-style) http://www.securelist.com/en/blog/208193852/The_tale_of_one_thousand_and_one_DSL_modems __ DNSSEC alone wouldn't have provided much relief on this, but DNSSEC+DANE+HSTS could. Most of it due to HSTS, but we need to cover the rogue CA attack-vector. Rubens ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Oct 2, 2012, at 7:59 AM, Rubens Kuhl rube...@nic.br wrote: Much better and very detailed analysis (by the same author!) So, it was not DNS poisoning at all but a change in the DNS settings of the router, after the box was cracked. (DNSchanger-style) http://www.securelist.com/en/blog/208193852/The_tale_of_one_thousand_and_one_DSL_modems __ DNSSEC alone wouldn't have provided much relief on this, but DNSSEC+DANE+HSTS could. Most of it due to HSTS, but we need to cover the rogue CA attack-vector. DNSSEC on the *host / stub* would have though. W Rubens ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
dnssec-trigger is your friend. Roy Sent from my iPhone On 2 Oct 2012, at 20:54, Paul Vixie p...@redbarn.org wrote: On 2012-10-02 7:48 PM, Warren Kumari wrote: DNSSEC on the *host / stub* would have though. this doesn't work at the moment, even when there's code on the stub that supports it, which is rare and experimental. i occasionally turn on a recursive name server on my laptop, but it's very rare that udp/53 is allowed through a wireless gateway in a hotel or coffee shop, and when it is, edns usually triggers an immune response because the gateway knows that additional data sections of queries are empty. when this doesn't fail, the multipacket response is damaged by dropping all fragments after the first one. if ietf hadn't declared the dns protocol finished, and were not even now working to close up the dnsext working group, i'd propose that we develop a standard for carrying edns over tcp/80 and/or tcp/443, which is for most mobile users what the internet consists of. i'm not sure how we expect DANE to make any difference when we don't have working last mile DNSSEC. paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On 2012-10-02 8:01 PM, Roy Arends wrote: dnssec-trigger is your friend. i looked at http://www.nlnetlabs.nl/projects/dnssec-trigger/. it says: Dnssec-trigger reconfigures the local unbound DNS server. This unbound DNS server performs DNSSEC validation, but dnssec-trigger will signal it to to use the DHCP obtained forwarders if possible, and fallback to doing its own AUTH queries if that fails, and if that fails prompt the user via dnssec-trigger-applet the option to go with insecure DNS only. and: One of the last resorts of dnssec-trigger is to use SSL port 443 for DNSSEC. If that fails, it is unlikely that DANE (https, also SSL port 443) can work. Thus, logically, this service is very likely to provide DNSSEC when DANE must have it. has the ssl format been submitted as an internet-draft, or is this a private standard? (if we're expecting tablets, cell phones, and factory fresh osx and windows to do this, it has to be the former.) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Tue, 2 Oct 2012, Paul Vixie wrote: if ietf hadn't declared the dns protocol finished, and were not even now working to close up the dnsext working group, i'd propose that we develop a standard for carrying edns over tcp/80 and/or tcp/443, which is for most mobile users what the internet consists of. unbound via dnssec-trigger does this. The problem here is that it still does 1 query/answer per TCP connection. That has to be fixed, and we should use a dnssec chains format for it. Ideally, I'd like to say something like give me the proof from .ca to IN A www.nohats.ca, and receive one blob back. I haven't encountered a hotspot that, after authentication, breaks port 80. This setup will work tremendously well. But currently, using port just causes timeouts. i'm not sure how we expect DANE to make any difference when we don't have working last mile DNSSEC. +1 Paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Tue, 2 Oct 2012, Paul Vixie wrote: One of the last resorts of dnssec-trigger is to use SSL port 443 for DNSSEC. If that fails, it is unlikely that DANE (https, also SSL port 443) can work. Thus, logically, this service is very likely to provide DNSSEC when DANE must have it. has the ssl format been submitted as an internet-draft, or is this a private standard? This works less reliable then port 80 in my experience. Even hotspots seem to detect this is different from real 443 traffic and dropping it, possibly various porn filter softare and the like. AFAIK, Wouter did not submit it as a draft, and (see previous email) I would prefer to develop something that can do HTTP or HTTPS for dnssec-chains. If we are making anything that does 1 query per TCP connect, or worse, 1 query per TLS connection, it will just not work. Paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Tue, Oct 02, 2012 at 08:07:09PM +, Paul Vixie p...@redbarn.org wrote a message of 30 lines which said: has the ssl format been submitted as an internet-draft, or is this a private standard? AFAIK, no, but it is very simple and build over the existing DNS: it is the same format as DNS-over-TCP, just over TLS+TCP. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On 2012-10-02 8:24 PM, Stephane Bortzmeyer wrote: AFAIK, no, but it is very simple and build over the existing DNS: it is the same format as DNS-over-TCP, just over TLS+TCP. i don't think so. too many middleboxes unpack the tcp/443 stream using a wildcard certificate, and they know the format of the underlying stream. it has to look like HTTP. that means POST or GET. i prefer POST, for the reasons previously stated (http://www.ietf.org/mail-archive/web/dnsext/current/msg11700.html). TLS-PSK looks too much like censorship avoidance, which this is not, but it would suffer the same fate. TLS where you negotiate one certificate but use another, likewise. paul -- It seems like the rules for automagic completion of incomplete names typed into browsers are going to start to look like those for the game of fizbin. --rick jones ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On 2012-10-02 8:49 PM, Stephane Bortzmeyer wrote: On Tue, Oct 02, 2012 at 08:34:36PM +, Paul Vixie p...@redbarn.org wrote a message of 19 lines which said: i don't think so. too many middleboxes unpack the tcp/443 stream using a wildcard certificate, ??? If you are on a network where the router/proxy/middlebox managed to obtain a wildcard certificate from a CA you trust (is there a CA which seels that?), you're toasted anyway. DNSSEC is useless because the middlebox can hack you at will. actually, not. dnssec+dane can tell you that you're being MiTM's at the later SSL session. or, put another way, we're all mostly toast, but i'd like to know when and where. paul -- It seems like the rules for automagic completion of incomplete names typed into browsers are going to start to look like those for the game of fizbin. --rick jones ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Tue, Oct 02, 2012 at 07:54:04PM +, Paul Vixie wrote: this doesn't work at the moment, even when there's code on the stub that supports it, which is rare and experimental. DNSSEC Trigger mostly works for me. It even has a hotel sign on mode, and it probes for all the failure modes you're talking about. if ietf hadn't declared the dns protocol finished, and were not even now working to close up the dnsext working group, i'd propose that we develop a standard for carrying edns over tcp/80 and/or tcp/443, which is for most mobile users what the internet consists of. There is nothing at all that prevents someone from getting together a BoF session in order to set up such a protocol effort. If you think you can get the interest, hold such a BoF. DNSEXT is closing because what you're talking about is not DNS, but a new protocol that looks kinda like DNS but runs on a different port. So's mDNS. But that aside, i'm not sure how we expect DANE to make any difference when we don't have working last mile DNSSEC. I don't think this is the problem at all. The problem is that even if you can get that out at the end point (and I can, using DNSSEC Trigger), it does you no good because your application _can't tell_ what happened. If I'm a web browser programmer, I want to be able to know whether the DNSSEC validation worked before I start using the TLSA record. Today, that is too much work (and probably reduces to implement a resolver in the browser). Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Oct 2, 2012, at 12:54 PM, Paul Vixie p...@redbarn.org wrote: if ietf hadn't declared the dns protocol finished, and were not even now working to close up the dnsext working group, i'd propose that we develop a standard for carrying edns over tcp/80 and/or tcp/443, which is for most mobile users what the internet consists of. What's stopping you from proposing a BOF at the next IETF (with the intent of spinning up a new WG if the BOF suggests that would be a good idea)? I thought killing off DNSEXT was to move away from the omnibus working group model and back to the topic-of-interest WG model? Did the IETF Illuminati declare a moratorium on all new DNS work when I wasn't looking? Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
From: Andrew Sullivan a...@anvilwalrusden.com I don't think this is the problem at all. The problem is that even if you can get that out at the end point (and I can, using DNSSEC Trigger), it does you no good because your application _can't tell_ what happened. If I'm a web browser programmer, I want to be able to know whether the DNSSEC validation worked before I start using the TLSA record. Today, that is too much work (and probably reduces to implement a resolver in the browser). Browsers are certainly not the only application, even if it is true as Paul Vixie recently said that the Internet is little more than the web for most connected computers (e.g. phones). Writing DNSSEC validation code for every application that depends on accurate DNS data would be as crazy as not using libraries and daemons for other local authentication and authorization. The only reasonable solution is to give stub resolvers some of the features of recursive resolvers including DNSSEC validation and caching to make the costs of DNSSEC tolerable. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Tue, 2 Oct 2012, Andrew Sullivan wrote: I don't think this is the problem at all. The problem is that even if you can get that out at the end point (and I can, using DNSSEC Trigger), Andrew, please have a drink at Second Cup next week when you're at ICANN. In fact, I'll buy it, you use the wifi to browse around :) The resolvers are broken for dnssec, other port 53 is blocked. You're on TCP only. You will see many timeouts and failures and trust me you will enable insecure within 5 minutes. it does you no good because your application _can't tell_ what happened. If I'm a web browser programmer, I want to be able to know whether the DNSSEC validation worked before I start using the TLSA record. Why? Are you going to ignore the TLSA record only when DNSSEC fails? In which case, an attacker will just trigger that. DNSSEC has to always come in, via port 53, port 80, or via x509 blobs. Paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Oct 2, 2012, at 5:49 PM, Vernon Schryver v...@rhyolite.com wrote: The only reasonable solution is to give stub resolvers some of the features of recursive resolvers including DNSSEC validation and caching to make the costs of DNSSEC tolerable. Why not get rid of stub resolvers completely and simply use recursive resolvers? Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On 2012-10-03 12:55 AM, David Conrad wrote: On Oct 2, 2012, at 5:49 PM, Vernon Schryver v...@rhyolite.com wrote: The only reasonable solution is to give stub resolvers some of the features of recursive resolvers including DNSSEC validation and caching to make the costs of DNSSEC tolerable. Why not get rid of stub resolvers completely and simply use recursive resolvers? there's an urban legend about how the authority servers depend on caching by intermediate recursives and that if every end system had its own recursive server on board the authorities would melt. the actual truth is that 98.9% of the traffic coming to the roots, and likely 90% of the traffic coming to authority servers overall, is dreck. for which they are amply overprovisioned. if we dilute that with more real traffic it might get the dreck percentage down to 80% but it wouldn't melt anything. paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Wed, Oct 03, 2012 at 12:49:20AM +, Vernon Schryver wrote: web for most connected computers (e.g. phones). Writing DNSSEC validation code for every application that depends on accurate DNS data would be as crazy as not using libraries and daemons for other local authentication and authorization. Just in case it wasn't plain (I guess it wasn't), I am not arguing that this is a good state of affairs. I was merely arguing that Paul's description of the problem is the wrong one. There is no validation at the edge at least in part because applications can't consume it, so there's no point. I have no idea whether the ability to consume that validation information would change the state of affairs, but it's certainly a necessary condition for TLSA use. A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
On Tue, Oct 02, 2012 at 08:55:12PM -0400, Paul Wouters wrote: The resolvers are broken for dnssec, other port 53 is blocked. You're on TCP only. You will see many timeouts and failures and trust me you will enable insecure within 5 minutes. Yep, I know. But my point (which I apparently stated so badly that it was impossible to understand) is that it _doesn't matter_ if you can get DNSSEC out at the edge, if the application can't tell. know whether the DNSSEC validation worked before I start using the TLSA record. Why? Are you going to ignore the TLSA record only when DNSSEC fails? In which case, an attacker will just trigger that. No. Rather, if I'm going to consume the TLSA record, I need some sort of confidence that the record was obtained securely. A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
From: Paul Vixie p...@redbarn.org
To: David Conrad d...@virtualized.org
CC: Vernon Schryver v...@rhyolite.com, dns-operations@lists.dns-oarc.net
The only reasonable solution is to give stub resolvers some of the
features of recursive resolvers including DNSSEC validation and caching
to make the costs of DNSSEC tolerable.
Why not get rid of stub resolvers completely and simply use recursive
resolvers?
I think the code to parse the BIND9 configuration grammar and nothing
more would be excessive and grotesque.The code to support all of
that stuff would be obscene.
As far as only DNSSEC is concerned, you don't need a lot of the
complications that a real authority server needs. (e.g. special NSEC3
database trees or lists to make big zones less slow.)
Of course, if the only available code for your situation is BIND, then
you could use BIND with a tiny configuration file. The package would
be smaller than current Firefox binaries that send me running and
screaming in horror.
there's an urban legend about how the authority servers depend on
caching by intermediate recursives and that if every end system had its
own recursive server on board the authorities would melt.
real traffic it might get the dreck percentage down to 80% but it
wouldn't melt anything.
No matter how over-provisioned authority servers are, I don't understand
why making stubbs more like real resolvers should increase traffic to
authority servers. Why couldn't you do the equivalent of moving the
DNS servers named in the system's equivalent of /etc/resolv.conf to
the equivalent of a BIND forwarders{} statement and putting localhost
into resolv.conf?
A full featured DNS server can't bypass men in the middle any more
than a bare bones DNSSEC validating caching forwarder. There's no
security reason to go to the real authority servers if your local DNS
servers are corrupt. The bad guys who corrupted them can attack your
DNS traffic going outside. All you can reliably do is detect evil,
and only if you can somehow get the root key. Detecting evil is often
enough of the battle. In many (but certainly not all) cases, the bad
guys react to sunshine like other vampires. In the other cases,
you can choose to not play the game by their rules or at all.
Vernon Schryverv...@rhyolite.com
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Massive DNS poisoning attacks in Brazil
In message 20121003011832.gc27...@mx1.yitter.info, Andrew Sullivan writes: On Tue, Oct 02, 2012 at 08:55:12PM -0400, Paul Wouters wrote: The resolvers are broken for dnssec, other port 53 is blocked. You're on TCP only. You will see many timeouts and failures and trust me you will enable insecure within 5 minutes. Yep, I know. But my point (which I apparently stated so badly that it was impossible to understand) is that it _doesn't matter_ if you can get DNSSEC out at the edge, if the application can't tell. Which is just a matter of adding a secure/insecure flag to struct addrinfo which is defined to be extended. ai_flags is currently undefined on return[1], but it could be used to return whether the answer was secure or not. Application that care would check. e.g. #define AI_SECURE unused bit #ifdef AI_SECURE if (addrinfo-flags AI_SECURE) secure; else insecure; #else insecure; #endif This is all about defining / extending APIs. BIND 9 has shipped with a API for looking up arbitary rrsets for a decade now, getrrsetbyname(), and it returns whether the rrset was secure or not. [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/getaddrinfo.html know whether the DNSSEC validation worked before I start using the TLSA record. Why? Are you going to ignore the TLSA record only when DNSSEC fails? In which case, an attacker will just trigger that. No. Rather, if I'm going to consume the TLSA record, I need some sort of confidence that the record was obtained securely. Code exists to do this. A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
