Re: [dns-privacy] DPRIVE over UDP or TCP
Not all: see my message from Friday: http://www.ietf.org/mail-archive/web/dns-privacy/current/msg00758.html I assume other large anycast TLS providers have similar setups to Cloudflare. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at On 27 Apr 2015, at 21:17, Paul Hoffman paul.hoff...@vpnc.org wrote: There is a third solution to the anycast problem, which is what is done today in all systems that use anycast: assume that it happens so rarely, that a rare reset is just fine. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DPRIVE over UDP or TCP
On Apr 27, 2015, at 12:50 PM, Christian Huitema huit...@huitema.net wrote: Which is why I propose what is in effect a STLS (Staleless TLS) in which each UDP request packet (optionally) contains the full state required to decrypt it at the server. Without going in the details, there are two types of solution to the anycast problem: either some form of pinning, so requests from a given context are guaranteed to arrive at the server with that context; or, somehow ensuring that the requests carry enough state that they can be understood by any server in the pool. I understand how to do pinning: a first transaction to the anycast address returns the unicast address of the relevant server. Not perfect, because it adds a roundtrip during the initial setup, but easy to understand. I am not sure about the way to carry enough state in each request. Especially if we want to do PFS, which means negotiating different session keys over time. I assume that the client could learn a temporary key that is understood by all servers in the pool, and use that to encrypt the messages. But then that requires a fair bit of coordination between the servers in the anycast pool. There is a third solution to the anycast problem, which is what is done today in all systems that use anycast: assume that it happens so rarely, that a rare reset is just fine. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DPRIVE over UDP or TCP
On Tue, Apr 28, 2015 at 12:16 AM, Christian Huitema huit...@huitema.net wrote: On Monday, April 27, 2015, at 5:22 PM, Warren Kumari wrote On Mon, Apr 27, 2015 at 4:17 PM, Paul Hoffman paul.hoff...@vpnc.org There is a third solution to the anycast problem, which is what is done today in all systems that use anycast: assume that it happens so rarely, that a rare reset is just fine. ... Many (most?) of these properties run HTTPS. From what I hear, fastly customers are happy chappies -- TCP anycast works... OK. Let's put this anycast/UDP/TCP thread to rest, and agree that this is not a problem in practice. And if that's true, then we should just pick UDP/TLS/TCP and be done with it. Having it work for content and DNS are two different things. The routing tables only need to be constant for a few minutes to support TCP content download. For DNS to be viable they have to be stable much longer. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Call for Adoptions on the 3 documents.
Ilari Liusvaara ilari.liusva...@elisanet.fi writes: I'll update my position on WG adoption a bit: I support adopting DNS-over-TLS but urges the WG to adopt DNS-over-DTLS at the same time, and make consistency between them a requirement. Having both with different TLS-related security semantics would be a disaster. In fact, I would suggest that these two documents are merged into one. There is (or, rather, should be) more in common between these documents than what separates them. - Can one resume sessions across protocols (resume UDP session as TCP session or vice versa)? I don't think anyone has implemented something like that. - Does DNS-over-DTLS need some sort of channel identifier in queries (taking place of the 5-tuple)? To deal with things like client IP address/portrange changes or client socket being dropped[1]. If I understand correctly, I don't believe DTLS has this, nor that it is something you want -- if something is messing with the traffic, you wan't detect/reject it not work around it. - Also, whereas 53/TCP is surprisingly clean[2], 53/UDP has lots of bad stuff going on, sometimes even with packets not destined to the middle- boxes.[3][4] How bad is that problem? I have no idea. Isn't that part of the problem? Also, some problems with (D)TLS: - No length hiding: There is no defined mechanism for length hiding (which is needed unless one can pad at DNS level). I think there have been at least one proposal tho. (D)TLS has message padding to mitigate packet length analysis. Addmittedly, you can't pad more than 255 bytes. - Complexity: Enormously complicated. TLS libraries are almost invariably junk for one reason or another. - Insecure configs: Most of TLS usage is insecure due to usage of legacy junk. One could address this by aggressively profiling down the usage. Sure, but you could say the same for DNS. I doubt that we can design a security protocol better than TLS here though. /Simon signature.asc Description: PGP signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Call for Adoptions on the 3 documents.
On Mon, Apr 27, 2015 at 05:15:32PM +0200, Simon Josefsson wrote: Ilari Liusvaara ilari.liusva...@elisanet.fi writes: - Does DNS-over-DTLS need some sort of channel identifier in queries (taking place of the 5-tuple)? To deal with things like client IP address/portrange changes or client socket being dropped[1]. If I understand correctly, I don't believe DTLS has this, nor that it is something you want -- if something is messing with the traffic, you wan't detect/reject it not work around it. This is about dealing with things like: - ISP suddenly renumbering connection. - NAT dropping state. The DTLS itself does not specify how to associate packets with connection state. Some of the ways seen: 5-tuples, in-band connection identifiers, out- of-band designation. Also, some problems with (D)TLS: - No length hiding: There is no defined mechanism for length hiding (which is needed unless one can pad at DNS level). I think there have been at least one proposal tho. (D)TLS has message padding to mitigate packet length analysis. Addmittedly, you can't pad more than 255 bytes. Only in block modes, which have number of problems (Chrome actually warns about obsolete cryptography if those are used). -Ilari ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DPRIVE over UDP or TCP
On Mon, Apr 27, 2015 at 3:50 PM, Christian Huitema huit...@huitema.net wrote: Which is why I propose what is in effect a STLS (Staleless TLS) in which each UDP request packet (optionally) contains the full state required to decrypt it at the server. Without going in the details, there are two types of solution to the anycast problem: either some form of pinning, so requests from a given context are guaranteed to arrive at the server with that context; or, somehow ensuring that the requests carry enough state that they can be understood by any server in the pool. I understand how to do pinning: a first transaction to the anycast address returns the unicast address of the relevant server. Not perfect, because it adds a roundtrip during the initial setup, but easy to understand. I am not too bothered about the initial setup. That is a one off thing that can happen as soon as the IP stack is initialized. Even doing it in application space there is usually a gap between someone starting a browser and clicking on a link. I am not sure about the way to carry enough state in each request. Kerberos tickets, or rather an opaque blob that the service can put whatever format ticket it likes. Especially if we want to do PFS, which means negotiating different session keys over time. I assume that the client could learn a temporary key that is understood by all servers in the pool, and use that to encrypt the messages. But then that requires a fair bit of coordination between the servers in the anycast pool. How much PFS do you want? Easy enough to rotate a kerberized ticket on an hourly basis or so. -- Christian Huitema ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DPRIVE over UDP or TCP
On Mon, Apr 27, 2015 at 4:17 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Apr 27, 2015, at 12:50 PM, Christian Huitema huit...@huitema.net wrote: Which is why I propose what is in effect a STLS (Staleless TLS) in which each UDP request packet (optionally) contains the full state required to decrypt it at the server. Without going in the details, there are two types of solution to the anycast problem: either some form of pinning, so requests from a given context are guaranteed to arrive at the server with that context; or, somehow ensuring that the requests carry enough state that they can be understood by any server in the pool. I understand how to do pinning: a first transaction to the anycast address returns the unicast address of the relevant server. Not perfect, because it adds a roundtrip during the initial setup, but easy to understand. I am not sure about the way to carry enough state in each request. Especially if we want to do PFS, which means negotiating different session keys over time. I assume that the client could learn a temporary key that is understood by all servers in the pool, and use that to encrypt the messages. But then that requires a fair bit of coordination between the servers in the anycast pool. There is a third solution to the anycast problem, which is what is done today in all systems that use anycast: assume that it happens so rarely, that a rare reset is just fine. Yup, a number of content delivery networks do this, including Faslty and Cachefly (http://www.cachefly.com/2014/07/11/measuring-throughput-performance-dns-vs-tcp-anycast-routing/ ) Fastly doesn't seem to have much published about this, but you can test this easily yourself. foursquare.com (and fastly.com and ronpaulinstitute.org and aclu.org and gizmodo.com and about 3,000 other properties) all resolve to something in the 23.235.33.0/24 subnet. Using RIPE Atlas probes and ping you can see that this is ~4ms from Strasbourg (FR), 1ms from Dallas (USA), 1ms from Ashburn (USA), 4ms from Hong Kong, 4ms from London, and 3ms from Universitat Heidelberg (DE). As a rough estimation, signals propagate about 200km per ms, and the above numbers are RTT (and we'll ignore CPU, routing, etc.) This means that fastly is within 400km of Strasbourg, HK, London, less than 200km from Dallas, and 300km from Heidelberg. Obviously there is no way this could be a single location (Strasbourg and Heidelberg are ~130km apart, and so may be a single node), and so this subnet is (widely) anycast. Many (most?) of these properties run HTTPS. From what I hear, fastly customers are happy chappies -- TCP anycast works... W --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
