Re: [DNSOP] [Int-area] various approaches to dns channel secrecy
this is extremely narrow but i can envision activists and dissidents who rightly fear for their safety based on this narrowly defined threat [BA] Presumably protection would only be from an attacker that can snoop on the wire, but not have access to the logs? Is the assumption that the DNS server is hosted out of country, and that measures are used to avoid identification of DNS traffic? I am trying to understand the scenario in which this actually would have a plausible chance of making a difference. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Toronto
Hi Tim, I’d like to request 15 minutes to talk about the issue on optimizing the geographical placement of DNS authority servers. For more information on this topic, please read our draft — https://datatracker.ietf.org/doc/draft-deng-dns-authority-server-placement/ Thanks a lot! Cheers, Ning 在 2014年7月2日 下午11:46:55, Tim Wicinski (tjw.i...@gmail.com) 写到: We've been scheduled for Tuesday morning at 9am this time: dnsop Session 1 (2:00:00) Tuesday, Morning Session I 0900-1130 Room Name: Ballroom size: 350 - This is also your notification to put in your requests for time for presenting. Please drop us a note on what you wish to talk about, and we'll work things in. Also, just to give people a heads up, the cut off for draft submission is Friday, July 4th. Please get things in if you have not. tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Int-area] various approaches to dns channel secrecy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 7/7/2014 12:14 AM, Eliot Lear wrote: Unless what you're using ISN'T a PKI. Any DNS mechanism must be free and clear of dependency loops. While that may be theoretically possible with a PKI, I'd hazard a guess (perhaps worth a drink at a bar) that the number of dependencies explodes, making such a loop more likely in an operational environment. In fact, some sort of PKI-free framework might even be more preferable for some folks. The problem with a PKI is not necessarily a technical problem -- a trust anchor has to be established somewhere with a PKI scheme, and politically that presents a lot of problems in this day age. That is *not* to say that DANE is not a desirable thing to deploy/accomplish. Just sayin'. $.02, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlO6usYACgkQKJasdVTchbLc5wD+JbF8M+J3XsIGIIaE/p/dJ5Ba iUR40V2U/OGlKKdT2VEBAIy+TrcgsVdxqKj1/DFdYWqPmGGVcuKK549kkOxWCeNp =+WAw -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
On Fri, 04 Jul 2014 20:04:02 -0700 Paul Vixie p...@redbarn.org wrote: first, dns data itself is public -- the data is there for anybody to query for it, if you know what to query for. only the question, questioner, and time can be kept secret. answers are only worth keeping secret because they identify the question, questioner, and time. Hi Paul, This may traditionally be true and ideally in the coherent name space world be true, but is not necessarily true. Thanks to views and other so-called DNS tricks, particularly those that in essence or a weak form of authentication (or even stronger form such as when attaching TSIG to them), answers that may never otherwise be seen by some subset of clients, or perhaps more correctly synthesized for some clients, may be candidates for enhanced secrecy. I wouldn't necessarily optimize for or argue to support such uses, just pointing out that they do exist in some corner cases. by implication, then, the remainder of possible problem statement material is hide question from on-wire surveillance, there being no way to hide the questioner or the time. to further narrow this, the prospective on-wire surveillance has to be from third parties who are not also operators of on-path dns protocol agents, because any second party could be using on-wire surveillance as part of their logging solution, and by (2) above there is no way to hide from them. so we're left with hide question from on-wire surveillance by third parties. This sounds like DNSCurve's approach. John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Int-area] various approaches to dns channel secrecy
On 07/07/2014 01:09 PM, Bernard Aboba wrote: [BA] Presumably protection would only be from an attacker that can snoop on the wire, but not have access to the logs? Is the assumption that the DNS server is hosted out of country, and that measures are used to avoid identification of DNS traffic? I am trying to understand the scenario in which this actually would have a plausible chance of making a difference. I also struggle to see the significant improvement for the cases that had been discussed on the list. I would say that they go close to zero when one uses DNS servers provided by the local network operator. signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Int-area] various approaches to dns channel secrecy
-Original Message- From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Matthäus Wander Sent: Sunday, July 06, 2014 5:56 PM To: Paul Vixie Cc: dnsop@ietf.org; int-a...@ietf.org Subject: Re: [Int-area] [DNSOP] various approaches to dns channel secrecy * Paul Vixie [7/5/2014 7:47 PM]: Matthäus Wander wrote: DTLS works on top of UDP (among others) and thus can pass CPE devices. no, it cannot. DTLS does not look something that the CPE was programmed to accept; thus in many cases it is silently dropped. DTLS can be used on top of UDP. CPE devices allow outgoing UDP sessions to arbitrary ports. If they didn't, many online games and VoIP applications would not work. Here's an example DTLS session passing my DSL router at home: https://www.cloudshark.org/captures/7d2ae4cfe155 Source code found here: http://marc.info/?l=openssl-usersm=113009464321966w=3 WebRTC enabled browsers already use DTLS to secure media. -Tiru Regards, Matt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
On Jul 7, 2014, at 8:24 AM, John Kristoff j...@cymru.com wrote: by implication, then, the remainder of possible problem statement material is hide question from on-wire surveillance, there being no way to hide the questioner or the time. to further narrow this, the prospective on-wire surveillance has to be from third parties who are not also operators of on-path dns protocol agents, because any second party could be using on-wire surveillance as part of their logging solution, and by (2) above there is no way to hide from them. so we're left with hide question from on-wire surveillance by third parties. This sounds like DNSCurve's approach. One important observation: ONLY the path between the client and the recursive resolver in the classic model substantially benefits from channel security. Even if you wave a magic wand and all resolver-authority communication becomes protected with 0-cost, 100% perfect data encryption, basic traffic analysis will largely be able to determine which domains are being looked up. Individual names within the domain are protected, but that is relatively minor. The other problem is DNS is used to guide endpoint communication. Between the resolver-authority information leak, and the actual IP selected by the endpoint itself for communication, this allows a nation-state observer adversary to pretty much recover what the hostname was in question in many cases, and at least the domain in almost all cases. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Int-area] various approaches to dns channel secrecy
Hannes Tschofenig wrote: Just a minor note on this paragraph: because HTTPS currently depends on X.509 keys, other groups in the IETF world are already working to make HTTPS proof against on-path surveillance. (google for perfect forward secrecy to learn more), and others are working to defend the internet user population against wildcard or targeted SSL certificates issued by governments and other anti-secrecy agents with on-path capabilities. TLS has this ciphersuite concept and allows you to more than just X.509 certificates. As such, you have more freedom than you think (if you know what you want). you are right of course. we would use TLS PSK for this, avoiding the X.509 system entirely. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Int-area] various approaches to dns channel secrecy
Bernard Aboba wrote: this is extremely narrow but i can envision activists and dissidents who rightly fear for their safety based on this narrowly defined threat [BA] Presumably protection would only be from an attacker that can snoop on the wire, but not have access to the logs? yes. which i said explicitly: by implication, then, the remainder of possible problem statement material is hide question from on-wire surveillance, there being no way to hide the questioner or the time. to further narrow this, the prospective on-wire surveillance has to be from third parties who are not also operators of on-path dns protocol agents, because any second party could be using on-wire surveillance as part of their logging solution, and by (2) above there is no way to hide from them. so we're left with hide question from on-wire surveillance by third parties. so, to your question: Is the assumption that the DNS server is hosted out of country, and that measures are used to avoid identification of DNS traffic? I am trying to understand the scenario in which this actually would have a plausible chance of making a difference. there are two kinds of channel in dns queries. (i'm not going to account for updates or zone transfers here.) one channel is from the stub to the recursive. it's pointless to add secrecy to that unless a stub wants to use a very distant name server, like opendns or googledns, or as in your example, one in another country. however, these long stub/recursive paths do exist and are becoming more common, either to avoid poisoning by the local recursive operator (typosquatting and so on) or to avoid surveillance by the local recursive operator or to access poisoning by a distant local recursive operator (opendns for example is actually a security company, and they deliberately filter out dns results to known-dangerous locations, as a service.) the other channel is from the recursive to the authoritative. these transactions contain very little PII, since the IP address of the end-user is not present, and since cache re-use events are not present, only cache-miss events. however, this channel is frequently intercepted (see china's GFW) and frequently observed/logged. (my $DAYJOB does this kind of observation/logging, but only with the explicit permission of the recursive operator who must deliberately install our sensor software, and only with the implicit permission of their stub population, which we can't ourselves verify, but we require be attested.) secrecy on either of these channels is only rarely important, but in order to avoid exceptional appearance (standing out like a sore thumb) it's going to be necessary to make secrecy on both of these channels ubiquitous. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Int-area] various approaches to dns channel secrecy
Paul Ferguson wrote: ... That is *not* to say that DANE is not a desirable thing to deploy/accomplish. DANE relies on DNSSEC which relies on EDNS. the placement of a DNS-over-HTTPS channel would have to be below EDNS in the stack, and non-reliant. therefore my correction up-thread -- this HTTPS session would rely on PSK for keying information, not X.509. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
Nicholas Weaver wrote: ... One important observation: ONLY the path between the client and the recursive resolver in the classic model substantially benefits from channel security. if i were proposing a secrecy scheme that was easy to do on stub-to-recursive but hard to do on recursive-to-authority, then i'd be looking very much harder at the benefits of recursive-to-authority. however, what i'm proposing is no easier to do in one case than the other, and so any purported difference in benefit is outweighed by the lack of difference in the cost. pay once, benefit twice, is good engineering economics as far as i'm concerned. ... Even if you wave a magic wand and all resolver-authority communication becomes protected with 0-cost, 100% perfect data encryption, basic traffic analysis will largely be able to determine which domains are being looked up. Individual names within the domain are protected, but that is relatively minor. The other problem is DNS is used to guide endpoint communication. Between the resolver-authority information leak, and the actual IP selected by the endpoint itself for communication, this allows a nation-state observer adversary to pretty much recover what the hostname was in question in many cases, and at least the domain in almost all cases. i wish it noted that i am responding to the general post-snowden call for channel secrecy, and that i don't myself see much need for it in the case of DNS, but that the proposals i've seen come out of the security community for how to add channel secrecy to DNS are alarming in their lack of understanding of what DNS is, how large DNS is, and how DNS works. therefore, i'm attempting to isolate the cases which might be relevant to somebody, i am drumming up a definition of dissident, and crafting a proposal that would protect that mythical person's interests. the fact that the QNAME can be recovered in many cases by a well resourced nation-state actor is meaningless here, since that surveillance would have to be targeted, and would be both inaccurate and expensive; whereas the surveillance i'm solving for is the ubquitous kind, which is presently very accurate and very cheap. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
* Paul Vixie [2014-07-06 19:29]: Matthäus Wander wrote: * Paul Vixie [7/5/2014 7:47 PM]: Matthäus Wander wrote: DTLS works on top of UDP (among others) and thus can pass CPE devices. no, it cannot. DTLS does not look something that the CPE was programmed to accept; thus in many cases it is silently dropped. DTLS can be used on top of UDP. CPE devices allow outgoing UDP sessions to arbitrary ports. If they didn't, many online games and VoIP applications would not work. it's possible to find single counter examples to almost any assertion. My point is that for a significant portion of Internet users, e.g. residential, HTTPS tunneling is not necessary. HTTPS tunneling should not be mandatory if it comes with disadvantages to a large user base who don't need it. The extra HTTPS layer suggests negative performance implications compared to a tailored protocol (maybe negligible, maybe not). Requiring TCP/443 is a dealbreaker when the port is already occupied by a small business web server or by an administration interface on a plastic device. however, consider RFC 2671 (EDNS), published fifteen years ago. because it changes the format of a UDP/53 datagram, there is silent loss across most CPE boundaries. [...] that fix is not going into the O(10^9) CPE devices now in place, ever. if we can't get this right for EDNS in 15 years, my bet is that another 15 (or 150) years of trying won't produce better results. in fact, by jim gettys and dave taht i've been made to understand that the world's CPE problem is much worse than i knew. we might be able to fix it for the next billion devices some day, but the devices shipping today are still crippled. Agreed. incentives are such that a CPE provider hopes to sell web access, not internet access. your counter-example of DNS gaming does not change the treatment now accorded UDP/53 at the internet edge. if you seriously think that a DTLS solution can be universally deployed, including in hotel rooms, home CPE environments, coffee shops, and mobile, then you and i are having a same planet, different worlds experience, and i wish you well on your walk. I didn't mean to imply that a DTLS solution can be universally deployed. I'm just not convinced that mandatory HTTPS tunneling built into a new DNS protocol is the appropriate solution here. My experience is that HTTPS tunneling is unnecessary in most (not all) networks. If I want to use SSH or VoIP in one of those crippled networks, I need a generic tunneling solution anyway. Admittedly, if I only need the web in a crippled network then encrypted DNS over HTTPS is a plus. That use case seems very narrow. Regards, Matt smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
Matthäus Wander wrote: ... I didn't mean to imply that a DTLS solution can be universally deployed. because the dns is a map to the territory known as the internet, and because most internet packet flows begin with a dns transaction, i'm dismissing out of hand anything that will almost universally not work for some class of user, such as those in hotel room wireless networks, or behind CPE that either can't pass new protocols or would require above-average skill to configure for such. in my own configuration i'd set EDNS to be the primary protocol, and add HTTPS as the first fallback to be tried, so that the fallback to plain DNS on UDP/53 can be as rare as possible. this may even be a reasonable default. but we can't spend any of our time pretending that the internet architecture isn't a hostage to a billion poorly built CPE devices, no matter how hopeful we are as to the future, and no matter how many personal counter-examples we can cite. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Joe, I was in the middle of a long, extremely eloquent point-by-point rebuttal when I realized it was pointless: we're approaching the draft from completely different directions and I strongly doubt anything I might say might change your mind. However, I did want to focus on one point. To quote a bit of your message: There's no obvious operational benefit to root server operators [...] I do not believe the draft is about improving life for the root server operators. That might be a side benefit in that it would reduce the noise root server operators have to wade through, but it isn't the primary goal. I see the primary benefit being a way of addressing what I consider a fundamental flaw in the historical DNS operational architecture. Specifically, the DNS operational infrastructure is a bit like 6to4: it relies on the kindness of strangers who may or may not have any incentive to ensure the service is provided in the best possible way. This draft attempts to document a way in which organizations can choose to be the masters of their own fate when it comes to root name service instead of relying on a set of 12 (or 11, depending on your point of view) volunteers who upgrade or not, buy capacity or not, deploy IPv6 or not, deploy anycast or not, etc., based on their own internal rationales and justifications. Further, it is opt-in: if you're perfectly happy with the existing system, no one is forcing you, as a resolver operator, to slave the root zone. In my mind, this is a much more scalable, resilient, robust, and even rational (from the perspective of the operation of critical infrastructure) system that the current root service architecture. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Hi, On Mon, Jul 07, 2014 at 12:27:36PM -0700, David Conrad wrote: This draft attempts to document a way in which organizations can choose to be the masters of their own fate when it comes to root name service instead of relying on a set of 12 (or 11, depending on your point of view) volunteers who upgrade or not, buy capacity or not, deploy IPv6 or not, deploy anycast or not, etc., based on their own internal rationales and justifications. Further, it is opt-in: if you're perfectly happy with the existing system, no one is forcing you, as a resolver operator, to slave the root zone. In my mind, this is a much more scalable, resilient, robust, and even rational (from the perspective of the operation of critical infrastructure) system that the current root service architecture. Perhaps. I haven't myself made up my mind about this draft, partly because I think the situation is somewhat more complicated than you suggest above. It's true that the draft sort of allows an operator to be master of its own fate. But it does require -- and indeed, the coherence (however loose) of the DNS requires -- that one fall back to asking a real root server in the event one isn't up to date. Now, the problem is that the root server operations are organized according to the work needed. That is, many of the server operators seem to do a pretty good job of ensuring capacity for their actual loads. If the proposals in this draft are widely adopted, that will by definition change the profile of the traffic the root servers see, and that will mean that such potential traffic will not be considered in the planning by root server operators. This may not be a fatal flaw (probably it isn't), but it does worry me a little. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Paul, On Jul 6, 2014, at 9:14 PM, Paul Vixie p...@redbarn.org wrote: there are far more errors encountered below .com or .de than by their siblings in the root. any argument in favour of wide scale slaving of the root zone begs the question, why not every tld and every pseudo-tld (such as no-ip.org)? the root isn't special in regards to a goal of preventing junk queries. The operators of the authorities for .com and .de and others have a natural incentive to augment their systems to deal with issues such as errors or DDoS or whatever. As we have seen multiple times in the past, most individual root operators simply do not have this incentive. that's why query minimization is the preferred solution to this problem. This isn't either/or. right now, root name servers are part of an explicit, hand-maintained NOTIFY tree. thus, all internet actions depending on root zone content have up-to-the-minute data if not up-to-the-second data in many cases. we should treat this as an invariant, I'm a bit (ok, a lot) skeptical of this claim, particularly given arguments made by some root server operators during the ICANN root scaling discussions about having instances at the end of long, thin, and fragile pipes and thus the size of the root zone must be limited. However, ignoring that, one key point of slaving the root is that folks who do slave the root are accepting the responsibility to keep it up to date. Failure to do so only impacts their own customer base. This is a self-correcting problem -- get too stale and your (presumably paying) customer scream at you (cue Vijay Gill's talk on the cost of customer calls in relation to the profit that customer will bring over their lifetime of being a customer). As a customer, you can also always choose to run your own resolver (which is, of course, the right answer for other reasons). Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
On Jul 7, 2014, at 9:52 AM, Paul Vixie p...@redbarn.org wrote: i wish it noted that i am responding to the general post-snowden call for channel secrecy, and that i don't myself see much need for it in the case of DNS, but that the proposals i've seen come out of the security community for how to add channel secrecy to DNS are alarming in their lack of understanding of what DNS is, how large DNS is, and how DNS works. therefore, i'm attempting to isolate the cases which might be relevant to somebody, i am drumming up a definition of dissident, and crafting a proposal that would protect that mythical person's interests. the fact that the QNAME can be recovered in many cases by a well resourced nation-state actor is meaningless here, since that surveillance would have to be targeted, and would be both inaccurate and expensive; whereas the surveillance i'm solving for is the ubquitous kind, which is presently very accurate and very cheap. No, its ubiquitous and cheap, and reasonably accurate. This type of traffic analysis correlation is bread and butter for a nation-state adversary running a pretty conventional real-time or even near real time IDS. Doing it on the backbone is not hard, and overall, its no more complex than analysis we know they do like identify ALL users based on cookies and HTTP replies. It is AMAZING the IDS analyses you can run on a 10 Gbps link when you are using a 20-system cluster. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Int-area] various approaches to dns channel secrecy
On Mon, Jul 7, 2014 at 12:42 PM, Paul Vixie p...@redbarn.org wrote: there are two kinds of channel in dns queries. (i'm not going to account for updates or zone transfers here.) one channel is from the stub to the recursive. it's pointless to add secrecy to that unless a stub wants to use a very distant name server, Not at all. Trying to get any sort of privacy guarantee while sending your DNS queries to any agent or service that you have not carefully selected and decided to trust is the futile quest. If we are going to have privacy then the DNS queries are going to be directed at a trusted resolver and not the closest resolver on the network. the other channel is from the recursive to the authoritative. these transactions contain very little PII, since the IP address of the end-user is not present, and since cache re-use events are not present, only cache-miss events. Agreed. However that is based on a lot of assumptions on how the DNS works that are currently true but need not be true in the future. If you have a DNS server that is advertising names that are geolocation dependent then the caching assumption breaks down and you start to leak privacy sensitive information. It would be a mistake to accept a DNS privacy solution that unnecessarily boxes the protocol in for future developments. You might want to make use of a PKI to set up credentials for the stub-resolver case. And you might well want to make use of the WebPKI etc. to achieve that in a convenient way without falling into an infinite regression trap of 'what is this anyway'. But that approach does not meet every use case. Once the credentials are set up you don't need that PKI any more because the trust relationship is now a binding between the end user's client and the service. In sxs-connect the original design brief was to support omnibroker which (among other things) allows the broker to advise on choice of WebPKI roots rather than rely on the browser choice. So there are mechanisms that don't rely on PKI to establish that binding which might well be preferred in an enterprise. In fact the reason I split that part out was that I realized that almost all the complexity in the problem was setting up that initial relationship and that the problem was much more general. The resolver to authoritative loop is very different. You probably do want to ground that in DNSSEC or else what is it for? Now you can't necessarily use DANE for that directly because the TLSA record is specified for TLS and the authors decided (against advice) to make it more than just a publication mechanism for keys. But you could certainly adapt the spec without much trouble and you might just want to publish raw keys. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Andrew, On Jul 7, 2014, at 12:44 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: It's true that the draft sort of allows an operator to be master of its own fate. But it does require -- and indeed, the coherence (however loose) of the DNS requires -- that one fall back to asking a real root server in the event one isn't up to date. If you're defining a real root server to include the zone delivery servers, I'd agree, however I feel the zone delivery servers have sufficiently different performance requirements as to put them in a different class than the name servers that respond to non-XFR queries. Now, the problem is that the root server operations are organized according to the work needed.[...] If the proposals in this draft are widely adopted, that will by definition change the profile of the traffic the root servers see, and that will mean that such potential traffic will not be considered in the planning by root server operators. This may not be a fatal flaw (probably it isn't), but it does worry me a little. Joe has already indicated that the normal query flow is essentially inconsequential in relation to capacity planning for the root server operators since they have to build based on DDoS/flash crowd loads, not on steady state. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
David Conrad wrote: Paul, ... that's why query minimization is the preferred solution to this problem. This isn't either/or. are you proposing to solve problem A (junk queries at the root) and problem B (junk queries at tld's and pseudo-tld's) using different mechanisms? why is the cost of a second mechanism worth paying, if a single mechanism would solve both problems? granted, we can solve any given problem in any number of ways including one, or more than one. but what's our incentive to pay more than we have to? ... one key point of slaving the root is that folks who do slave the root are accepting the responsibility to keep it up to date. Failure to do so only impacts their own customer base. This is a self-correcting problem -- get too stale and your (presumably paying) customer scream at you ... my experience has been that when dns doesn't work the call reporting this can go just about anywhere. if i could be sure that the first call from most users would go to the actual person who had the power to fix whatever caused the call, i'd certainly make that a primary design assumption. put it the other way. as a domain holder, i'd like the system recommended by IETF whereby my delegation data is distributed to be as error-unlikely as possible. if you give me a vote, wearing my domain holder hat, i will pick please tell the small number of people who want to run root anycast nodes to do so rather than please tell the large number of RDNS operators to slave the root. this is me wanting, selfishly, uptime and a low number of dependencies and state-permutations. but i consider myself to be representative of other domain holders in this regard, so it could be worth paying attention to my selfish desires this time. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
On Jul 7, 2014, at 4:36 PM, Paul Vixie p...@redbarn.org wrote: that's why query minimization is the preferred solution to this problem. This isn't either/or. are you proposing to solve problem A (junk queries at the root) and problem B (junk queries at tld's and pseudo-tld's) using different mechanisms? why is the cost of a second mechanism worth paying, if a single mechanism would solve both problems? Query minimization and slaving the root focus on solving different problems. For example, query minimization does nothing to reduce systemic vulnerability to DoS. Both should probably be done. put it the other way. as a domain holder, i'd like the system recommended by IETF whereby my delegation data is distributed to be as error-unlikely as possible. As a user of the Internet, I'd like the system recommended by the IETF to scale in the face of ISPs being unable to address DoS in any effective way. The root of the DNS, concentrated in the hands of 24 (still not 26, sigh) IP addresses, is and always has been non-scalable -- we just didn't have a zillion botnet zombies rubbing our noses in it. Worse the existing system relies on the goodwill and potentially unbounded donation of resources from folks who aren't paid to provide the service. When you, I, and the Internet were younger, this (arguably) made sense but the Internet has changed (not to mention you and I). Slaving the root means the folks who are getting paid to provide domain resolution service to their customers are no longer dependent on the kindness of strangers, the single point of failure represented by the real-time query response requirement of root servers can be avoided, latency is reduced for queries for non-existant names, and information leakage can be minimized. The main argument against slaving the root I've seen appears to me to be FUD: people running resolvers are too stupid to configure slaving the root correctly so root data will go stale! (paraphrased). I've no doubt some folks will get it wrong, however again, this is a self-correcting problem that impacts a fraction of the Internet at large. If nothing else, repeated failure of a resolver operator to fix their slave configuration will result either in migration to folks who can get it right or people running their own resolvers. Seems like a win to me. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
Personally I would use a new opcode and fall back to query on NOTIMP. The payload of the new OPCODE does not have to be decodable by existing servers. This is also how EDNS should have been done. Since it is next to impossible to hide that you are talking to a server use unencrypted DNS w/ DNSSEC to get a public key for authoritative servers stored in its own type. This signals support for the new OPCODE. Use that key to encrypt the payload the payload to the server using the new OPCODE. With a session key returned for followup transactions. For recursive server add a DHCP and RA options which distribute the public keys of the recursive nameservers. This should work through pure DNS proxies. 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] draft-wkumari-dnsop-dist-root-01.txt
On 8 jul 2014, at 02:55, David Conrad d...@virtualized.org wrote: The main argument against slaving the root I've seen appears to me to be FUD: people running resolvers are too stupid to configure slaving the root correctly so root data will go stale! (paraphrased). I am a bit disappointed that you David do summarize the arguments against this proposal in this way. Several various weaknesses of the proposal have been explained at several occasions (although of course also them with a bit of hand waving), and they are definitely not fud and definitely not limited to people making mistakes. What I have recommended Warren to do is to properly list the arguments, make a proper analysis (an attack tree would be one good start) because my largest fear is that the various issues that might look like weaknesses of the proposal must be analyzed, and that they are not. I have at least heard: - Recovery process when bad data end up in the resolver (cache v.s. auth) - Routing issues (which is what I see the largest burden of a root server operator) - Lack of DNSSEC validation - The fact not all data in the root zone is signed - Political/regulative implications (to ensure a different TA is used than ICANN) - Lack of legal protection of the root zone itself ...and possibly more. ...and of course a combination of these. Once again, this is such a large issue that I would prefer a bit better arguments than what is demonstrated here. Yes, I know you wrote in affection, but let this remind all of us that we can do better. Ok? Patrik signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
