Re: [Int-area] various approaches to dns channel secrecy
Hi Hannes, On 7/7/14, 8:23 AM, Hannes Tschofenig wrote: Just a minor note on this paragraph: On 07/07/2014 06:48 AM, Eliot Lear wrote: because HTTPS currently depends on X.509 keys, other I didn't write the above, Paul did. But to your point below... 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). Yes. This is something you might know something about ;-) It would be funny if the precondition using using DANE would be to require a PKI as currently used on the Web... 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. Eliot ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [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. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] various approaches to dns channel secrecy
On 7/7/14, 1:14 PM, Hannes Tschofenig wrote: 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. That's a matter of service selection and orthogonal to Paul's proposal. Eliot ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [DNSOP] 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- ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [DNSOP] 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: dn...@ietf.org; Int-area@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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [DNSOP] 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [DNSOP] 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
