Subject: [dns-privacy] DPRIVE over UDP or TCP

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 22 Apr 2015 10:15:25 -0700

During the DPRIVE meeting in Dallas, several questions came up about UDP versus TCP.  We had previously submitted a "DNS over DTLS" document which predated DPRIVE.  We re-submitted the document with a few edits and a filename that makes it easier to find, https://tools.ietf.org/html/draft-wing-dprive-dnsodtls, diffs at https://tools.ietf.org/rfcdiff?url1=draft-wing-dnsop-dnsodtls-01&url2=draft-wing-dprive-dnsodtls-00

The working group may want to consider the advantages of DNS over DTLS over UDP compared to using TCP:

 * No reliance on operating system support of TCP Fast Open [RFC7413] to achieve same number of round trips.
 * Avoidance of TCP's network head of line blocking.

-d

---

From: Ted Hardie <[email-masked]>
Date: Wed, 22 Apr 2015 15:24:10 -0700

On Wed, Apr 22, 2015 at 10:15 AM, 🔓Dan Wing <[email-masked]> wrote:

> During the DPRIVE meeting in Dallas, several questions came up about UDP
> versus TCP.  We had previously submitted a "DNS over DTLS" document which
> predated DPRIVE.  We re-submitted the document with a few edits and a
> filename that makes it easier to find,
> https://tools.ietf.org/html/draft-wing-dprive-dnsodtls, diffs at
> https://tools.ietf.org/rfcdiff?url1=draft-wing-dnsop-dnsodtls-01&url2=draft-wing-dprive-dnsodtls-00
>
​Just to confirm my understanding, with DTLS plus anycast, you'd have
similar issues for restart as TCP (state being associated with a single
endpoint, timeout required for flushing state).  Is that your thinking as
well?​

regards,

Ted

> -d
>
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Apr 2015 22:25:37 -0400

On Wed, Apr 22, 2015 at 6:24 PM, Ted Hardie <[email-masked]> wrote:

> On Wed, Apr 22, 2015 at 10:15 AM, Dan Wing <[email-masked]>
> wrote:
>

I am not an expert on DTLS but that was the concern that made me avoid
using it. I want a completely stateless resolver, not just UDP.

That means using either a very fast ECC scheme for authentication or some
sort of kerberos ticket.

There are TLS features that may be sufficient but I worry about the number
of framing bytes.

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 23 Apr 2015 12:58:19 -0700

On 22-Apr-2015 03:24 pm, Ted Hardie <[email-masked]> wrote: 
> On Wed, Apr 22, 2015 at 10:15 AM, 🔓Dan Wing <[email-masked] <mailto:[email-masked]>> wrote:
> During the DPRIVE meeting in Dallas, several questions came up about UDP versus TCP.  We had previously submitted a "DNS over DTLS" document which predated DPRIVE.  We re-submitted the document with a few edits and a filename that makes it easier to find, https://tools.ietf.org/html/draft-wing-dprive-dnsodtls <https://tools.ietf.org/html/draft-wing-dprive-dnsodtls>, diffs at https://tools.ietf.org/rfcdiff?url1=draft-wing-dnsop-dnsodtls-01&url2=draft-wing-dprive-dnsodtls-00 <https://tools.ietf.org/rfcdiff?url1=draft-wing-dnsop-dnsodtls-01&url2=draft-wing-dprive-dnsodtls-00>
> 
> ​Just to confirm my understanding, with DTLS plus anycast, you'd have similar issues for restart as TCP (state being associated with a single endpoint, timeout required for flushing state).  Is that your thinking as well?​

They are different, notably around a 'synchronized' TCP session.  See my other email about anycast, subject was Anycast and TCP-based DPRIVE queries, http://www.ietf.org/mail-archive/web/dns-privacy/current/msg00729.html

-d

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>
>

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 23 Apr 2015 13:21:46 -0700

On 22-Apr-2015 07:25 pm, Phillip Hallam-Baker <[email-masked]> wrote: 
> 
> 
> On Wed, Apr 22, 2015 at 6:24 PM, Ted Hardie <[email-masked] <mailto:[email-masked]>> wrote:
> On Wed, Apr 22, 2015 at 10:15 AM, Dan Wing <[email-masked] <mailto:[email-masked]>> wrote:
> I am not an expert on DTLS but that was the concern that made me avoid using it. I want a completely stateless resolver, not just UDP.
> 
> That means using either a very fast ECC scheme for authentication or some sort of kerberos ticket.

I believe "Transport Layer Security (TLS) Session Resumption without Server-Side State", https://tools.ietf.org/html/rfc5077 <https://tools.ietf.org/html/rfc5077> solves that problem.  It works with TLS and with DTLS.

> There are TLS features that may be sufficient but I worry about the number of framing bytes.

The DTLS 1.2 record format has 13 bytes of framing, https://tools.ietf.org/html/rfc6347#page-26 <https://tools.ietf.org/html/rfc6347#page-26>.  Content Type is 8 bits and version is 16 bits.

      struct {
        ContentType type;
        ProtocolVersion version;
        uint16 epoch;                                     // New field
        uint48 sequence_number;                           // New field
        uint16 length;
        select (CipherSpec.cipher_type) {
          case block:  GenericBlockCipher;
          case aead:   GenericAEADCipher;                 // New field
        } fragment;
      } DTLSCiphertext;

TLS 1.2 has 5 bytes of framing (because it doesn't have the epoch and sequence_number).

-d

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Apr 2015 16:52:30 -0400

On Thu, Apr 23, 2015 at 4:21 PM, 🔓Dan Wing <[email-masked]> wrote:

> I am not an expert on DTLS but that was the concern that made me avoid using
> it. I want a completely stateless resolver, not just UDP.
>
> I believe "Transport Layer Security (TLS) Session Resumption without
> Server-Side State", https://tools.ietf.org/html/rfc5077 solves that problem.
> It works with TLS and with DTLS.

That is an option in DTLS.

For a DTLS based scheme to be acceptable, client support has to be mandatory.

If we do that, I have no problem with the additional overhead.

The question then is whether we can profile DTLS without in effect
requiring a new implementation library.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 23 Apr 2015 17:57:42 -0700

On Apr 23, 2015 1:52 PM, "Phillip Hallam-Baker" <[email-masked]>
wrote:
>
> On Thu, Apr 23, 2015 at 4:21 PM, Dan Wing <[email-masked]>
> > I am not an expert on DTLS but that was the concern that made me avoid
using
> requiring a new implementation library.

This doesn't solve the actual problem, as compared with DNS/UDP.

DTLS resumption requires a round trip: the server keeps that state alive as
a new DTLS connection, and then the client or server closes it after using
it. So if you have 10,000 clients, even if only 100 of them issue queries a
second, but over two minutes they all do, you will either force them all to
pay the latency price of reopening the connection or store state for 10,000
DTLS sessions.

Another problem is with anycast. Ordinarily failover is completely
transparent to users: the packets go somewhere else, and get responded to.
I don't see how this works with TLS, unless you do fancy stateful failover
tricks.

The easiest solution is to encrypt packets with a public key that the
servers have, or force every packet to contain something equivalent to
resumption data. But that requires not using TLS/DTLS.

Sincerely,
Watson Ladd

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Apr 2015 21:37:35 -0400

On Thu, Apr 23, 2015 at 8:57 PM, Watson Ladd <[email-masked]> wrote:

> DTLS resumption requires a round trip: the server keeps that state alive
> as a new DTLS connection, and then the client or server closes it after
> using it. So if you have 10,000 clients, even if only 100 of them issue
> queries a second, but over two minutes they all do, you will either force
> them all to pay the latency price of reopening the connection or store
> state for 10,000 DTLS sessions.
>

Ah, then it doesn't work.

I can't see why people are so insistent on clinging to a familiar label. Is
it because it is easier to put blind faith in TLS than consider how it
works?

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 24 Apr 2015 07:07:37 +0000

From: dns-privacy [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Friday, April 24, 2015 6:28 AM
To: Phillip Hallam-Baker
Cc: Ted Hardie; [email-masked]; Dan Wing (dwing)
Subject: Re: [dns-privacy] DPRIVE over UDP or TCP

On Apr 23, 2015 1:52 PM, "Phillip Hallam-Baker" <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Thu, Apr 23, 2015 at 4:21 PM, [🔓] Dan Wing <[email-masked]<mailto:[email-masked]>> wrote:
>

DTLS resumption requires a round trip: the server keeps that state alive as a new DTLS connection, and then the client or server closes it after using it. So if you have 10,000 clients, even if only 100 of them issue queries a second, but over two minutes they all do, you will either force them all to pay the latency price of reopening the connection or store state for 10,000 DTLS sessions.

[TR]The size of the ticket for session resumption in [D]TLS is small as explained in https://tools.ietf.org/html/rfc4507#section-1; The two main benefits as discussed are

   3.  ability to load balance requests across servers

     4.  embedded servers with little memory

#3 makes it work across servers with anycast.

Another problem is with anycast. Ordinarily failover is completely transparent to users: the packets go somewhere else, and get responded to. I don't see how this works with TLS, unless you do fancy stateful failover tricks.

[TR]  The cryptographic context need not to synced. The servers could share the keying material to decrypt and authenticate the ticket sent by the client. However with TCP, its state need to be synced.

-Tiru

The easiest solution is to encrypt packets with a public key that the servers have, or force every packet to contain something equivalent to resumption data. But that requires not using TLS/DTLS.

Sincerely,
Watson Ladd

> [email-masked]<mailto:[email-masked]>

---

From: Tony Finch <[email-masked]>
Date: Fri, 24 Apr 2015 10:37:05 +0100

> I don't see how this works with TLS, unless you do fancy stateful failover

It is worth looking at what the anycast web providers do, e.g.
https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/

There's no attempt to keep TCP connections working in the event of
failover. TLS session IDs are only distributed within a POP so if anycast
failover happens the client will have to do a full 2RTT handshake. TLS
session tickets are encrypted with globally-distributed keys, so these
sessions can survive anycast failover.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: South or southwest 4 or 5, occasionally 6. Moderate or rough. Rain
or showers. Moderate or good.

---

From: 🔓Dan Wing <[email-masked]>
Date: Fri, 24 Apr 2015 09:21:46 -0700

On 23-Apr-2015 06:37 pm, Phillip Hallam-Baker <[email-masked]> wrote: 
> 
> 
> On Thu, Apr 23, 2015 at 8:57 PM, Watson Ladd <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Apr 23, 2015 1:52 PM, "Phillip Hallam-Baker" <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > On Thu, Apr 23, 2015 at 4:21 PM, Dan Wing <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > > Server-Side State", https://tools.ietf.org/html/rfc5077 <https://tools.ietf.org/html/rfc5077> solves that problem.
> I can't see why people are so insistent on clinging to a familiar label. Is it because it is easier to put blind faith in TLS than consider how it works? 

Hugs and kisses, Phillip.

It is time to write down requirements.

-d

---

From: Watson Ladd <[email-masked]>
Date: Sun, 26 Apr 2015 20:27:30 -0700

On Fri, Apr 24, 2015 at 9:21 AM, 🔓Dan Wing <[email-masked]> wrote:
>> > On Thu, Apr 23, 2015 at 4:21 PM, Dan Wing
>> > <[email-masked]> wrote:
>> >
>> them all to pay the latency price of reopening the connection or store state
>> for 10,000 DTLS sessions.
>>
>> transparent to users: the packets go somewhere else, and get responded to. I
>> don't see how this works with TLS, unless you do fancy stateful failover
>> tricks.
>>

If you actually want to ensure that all devices using DNS can
transition to the new protocol, you need to not change how the packet
flows work or require massive handling of state. Only DNSCrypt-like
solutions can do this: TLS can't. Now, maybe it's enough to get almost
all the ISPs and browser vendors on board. But unless you are a
browser vendor, or a DNS cache appliance vendor, you don't know what
the actual constraints on latency and state are.

We know that approaches similar to DNSCrypt don't have these problems.
That they haven't been written up is regrettable, but we should be
sure that before committing to a solution, we make sure that either
solves the problem, or if it doesn't, that we come back and go for one
that does. What we shouldn't do is ignore issues we've been told about
because "we solved the problem! (TM)".

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: 🔓Dan Wing <[email-masked]>
Date: Sun, 26 Apr 2015 20:33:51 -0700

On 26-Apr-2015 08:27 pm, Watson Ladd <[email-masked]> wrote:
> solutions can do this: TLS can't.

Not even TLS early data (https://tools.ietf.org/html/draft-ietf-tls-tls13-05#section-7.3.2.5.3)?

> Now, maybe it's enough to get almost

-d

---

From: Watson Ladd <[email-masked]>
Date: Sun, 26 Apr 2015 20:41:02 -0700

> Not even TLS early data (https://tools.ietf.org/html/draft-ietf-tls-tls13-05#section-7.3.2.5.3)?

0-RTT is an upcoming feature in TLS 1.3. It's pretty gory, and amounts
to doing what DNSCrypt does now, only doesn't exist or is implemented
yet. Furthermore, TLS 1.3 opens connections, even with early data.

If what we end up with is doing the same crypto operations as
DNSCrypt, but with the extra complexity of managing connections
(opening, closing, resuming, etc), what is the advantage?

---

From: 🔓Dan Wing <[email-masked]>
Date: Sun, 26 Apr 2015 20:48:27 -0700

> (opening, closing, resuming, etc), what is the advantage?

TLS has an engaged community.  The TLS protocol and its implementations have been attacked and improved through the years -- "better the devil you know."

-d

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Apr 2015 09:22:48 -0400

> TLS has an engaged community.  The TLS protocol and its implementations have been attacked and improved through the years -- "better the devil you know."

As the person who broke SSL/1.0, I find that a rather weak argument.

SSL could have been fixed much earlier if Andressen had handled things
differently. If they had been willing to circulate the design prior to
shipping
the bits we could have gone straight to TLS/1.0 in 1995. Simon Spero and
myself were both willing to work on it at no cost to Netscape.

A lot of the difficulty since has been working within the limitations
of some bad design decisions taken before anyone with crypto
experience could
comment on the design.

I am not proposing to replace the key agreement part of TLS which is the
complex part. All I propose to change is the framing part which TLS does
in the opposite fashion to current best practice in any case.

In effect I am proposing a different DTLS variation that is better suited to
DNS traffic patterns by being completely stateless.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 27 Apr 2015 10:04:32 -0400 (EDT)

> (opening, closing, resuming, etc), what is the advantage?

I've said this before......

My understanding of dnscrypt is that it is just a static preconfigured
VPN using some custom way of sending an X.509 certificate over TXT
records, using some adhoc headers thrown in. The closest thing to a
specification I can find is:

https://github.com/jedisct1/dnscrypt-proxy/blob/master/TECHNOTES

which states:

 	One or more TXT records are returned, each containing a signed
 	certificate.
 	The provider public key is only used to verify a certificate, never for
 	authenticating/encrypting queries.
 	Certificates have the following header:
 	- 4 byte magic header DNSC
 	- 2 byte major version
 	- 2 byte minor version
 	Followed by signed content (the signature adds 512 bits to the payload):
 	- server 256-bit public key
 	- 8 byte magic header to use for queries using this specific key
 	- 4 byte serial number
 	- 4 + 4 byte validity period (two timestamps)

I'm unsure why we need a new way to authenticate that shoves certs in
adhoc TXT recods. Why not use TLS on some other port, even if we then
later to DNS on port 53 with whatever dnscrypt magic? If this is a
really cool way of doing things (which I don't think it is) than we
should not be using TXT records but a new RRTYPE.

It also seems rather hardcoded with odd values, very un-agile and
centered on The One True Encryption Protocol.

And dnscrypt is then topped of with:

 	This is the current structure of the second version of the protocol.
 	Don't assume anything about its length, it is very likely to change
 	after a version bump.

So the designers have no idea if they are going to completely rewrite
this. Does not sound like it is anywhere near ready for standardization.

Which is why dnscrypt is not a real contender and we should steer this
discussion back to the 3 considered proposals.

>>> We know that approaches similar to DNSCrypt don't have these problems.

So this seems to be a statement that cannot be translated into technical
terms. What is this "similar approach" that is missing from the other
proposals that supposedly makes dnscrypt so much different and better?

In fact, I see nothing that makes dnscrypt any better that using a
preconfigured X.509 based IPsec VPN possibly limited to udp/tcp 53
traffic selectors.

dnscrypt might be a nice hack to solve a short term issue in light of
hostile and/or never-upgraded networks with some success of bypassing
the network administrator restrictions. But it is not an architecture
for future deployment.

Paul

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 27 Apr 2015 11:03:12 -0700

> This doesn't solve the actual problem, as compared with DNS/UDP.

For all practical purposes, DNS/DTLS/UDP is close to DNS/TLS/TCP than DNS/UDP. This is particularly true when using anycast.

DNS/UDP is pretty much stateless. If we assume that an anycast address is served by a pool of servers, any server in the pool can answer the request. The responses will be identical, and the client will not see any difference. 

Both DNS/DTLS/UDP and DNS/TLS/TCP are different. The servers can only answer a query if they have previously completed a TLS handshake with the client. If anycast routes a query to a different server in the pool, that different server will have to repeat the TLS handshake before answering.

DTLS/UDP may have a slightly lower overhead than TLS/TCP, in the sense that it will not require the TCP "ACK." But that comes at the price of less efficient error handling, and also less efficient transmission if the DNS messages happen to be larger than the MTU. If a NAT is involved, UDP will also require keep-alive traffic to "pin" the port mappings, something that is not needed nearly as much with TCP. 

Bottom line, DNS/DTLS/UDP does not have much of an advantage over DNS/TLS/TCP. It looks more like gratuitous complexity.

-- Christian Huitema

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Apr 2015 14:28:35 -0400

> Bottom line, DNS/DTLS/UDP does not have much of an advantage over DNS/TLS/TCP. It looks more like gratuitous complexity.

Agreed

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.

I use TLS over TCP to establish the STLS state however.

If TLS/1.3 or TLS/2.0 was in a different situation then building DPRIV
on that would make more sense to me. But I think those are quite a way
off and for TLS/2.0 I would really like to adopt the same approach I
am proposing here.

95% of the complexity in IPSEC and TLS is in the negotiation of the
key agreement and there is absolutely no reason why we could not use
the same key agreement mechanism for both. That is the point where PKI
is involved, etc.

DPRIV is only one half of the problem we have to solve here. If the
solution to DPRIV is going to be any use, we also have to address the
TLS SNI issue.

I have a plan to solve the full problem. I don't think the folk saying
'yeah lets stick to what we know' do.

My plan is:

1) Encrypt and Authenticate the client-resolver loop in a fashion that
makes multiple DNS resource record queries practical.

2) Distinguish between keys for services 'www.example.com' from keys
for hosts 'host23.colocation.com'. Publish ECC keys for the latter in
the DNS

3) Rewrite the TLS handshake so that the initial exchange takes place
under the host key. Thus SNI is always encrypted to the host.

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 27 Apr 2015 12:50:53 -0700

> 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.

-- Christian Huitema

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 27 Apr 2015 12:59:44 -0700

> Both DNS/DTLS/UDP and DNS/TLS/TCP are different. The servers can only answer a query if they have previously completed a TLS handshake with the client. If anycast routes a query to a different serv…

That problem is fixed if we have "Transport Layer Security (TLS) Session Resumption without Server-Side State" (RFC5077) and the emerging TLS 1.3 early data extension.

> DTLS/UDP may have a slightly lower overhead than TLS/TCP, in the sense that it will not require the TCP "ACK." But that comes at the price of less efficient error handling, and also less efficient transmission if the DNS messages happen to be larger than the MTU.

Large responses exceeding MTU are already a problem with DNS over UDP.  I agree that if we want to fix that problem, abandoning DNS over UDP entirely is a viable approach.  However, based on the comments at the microphone that I heard in Dallas, I did not get the feeling there was consensus to abandon UDP.  But I am not a chair, and I can't call consensus on that point.

> If a NAT is involved, UDP will also require keep-alive traffic to "pin" the port mappings, something that is not needed nearly as much with TCP. 

Keepalive isn't necessary (even with UDP) as long as the packet is self-contained, as it would be with RFC5077 and with TLS early data.

-d

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Apr 2015 13:17:30 -0700

> 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…

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

---

From: Tony Finch <[email-masked]>
Date: Mon, 27 Apr 2015 21:30:48 +0100

How is your idea different from TLS session tickets?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

> On 27 Apr 2015, at 19:28, Phillip Hallam-Baker <[email-masked]> wrote:
>

---

From: Tony Finch <[email-masked]>
Date: Mon, 27 Apr 2015 21:33:42 +0100

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.

> On 27 Apr 2015, at 21:17, Paul Hoffman <[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Apr 2015 19:32:55 -0400

> 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…

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.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 27 Apr 2015 20:21:36 -0400

> 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

-- 
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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 28 Apr 2015 01:54:24 +0000

Yup and it looks dnscrypt could be used to launch DDOS attack on victim.

-Tiru

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of Paul
> Wouters
> Sent: Monday, April 27, 2015 7:35 PM
> To: Watson Ladd
> Cc: [email-masked]; Dan Wing (dwing)
> My understanding of dnscrypt is that it is just a static preconfigured VPN
> using some custom way of sending an X.509 certificate over TXT records,
> using some adhoc headers thrown in. The closest thing to a specification I
> can find is:
> 
> adhoc TXT recods. Why not use TLS on some other port, even if we then later
> to DNS on port 53 with whatever dnscrypt magic? If this is a really cool way
> of doing things (which I don't think it is) than we should not be using TXT
> records but a new RRTYPE.
> 
> It also seems rather hardcoded with odd values, very un-agile and centered
> on The One True Encryption Protocol.
> 
> So the designers have no idea if they are going to completely rewrite this.
> Does not sound like it is anywhere near ready for standardization.
> 
> preconfigured X.509 based IPsec VPN possibly limited to udp/tcp 53 traffic
> selectors.
> 
> dnscrypt might be a nice hack to solve a short term issue in light of hostile
> and/or never-upgraded networks with some success of bypassing the
> network administrator restrictions. But it is not an architecture for future
> deployment.
> 
> Paul
>

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 27 Apr 2015 21:16:56 -0700

On Monday, April 27, 2015, at 5:22 PM, Warren Kumari wrote
> On Mon, Apr 27, 2015 at 4:17 PM, Paul Hoffman <[email-masked]>
> > 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.
> 
> ...

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.

-- Christian Huitema

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Apr 2015 00:34:06 -0400

> 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.

---

From: Tony Finch <[email-masked]>
Date: Tue, 28 Apr 2015 10:04:02 +0100

> TCP content download. For DNS to be viable they have to be stable much

Why?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Cyclonic becoming northeasterly 6 to gale 8, occasionally
severe gale 9 at first. Very rough or high, becoming rough or very rough.
Wintry showers. Good, occasionally poor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Apr 2015 07:29:26 -0400

>> TCP content download. For DNS to be viable they have to be stable much

Because when downloading content, what matters is throughput.The
byterange extensions in http mean that it is possible to resume a
session interrupted part way through if it is static content.

For DNS the pattern is a tiny number of one packet interactions per
hour with exceptionally tight latency. If the anycast changes then you
are going to have to timeout and resume.

---

From: Tony Finch <[email-masked]>
Date: Tue, 28 Apr 2015 12:34:50 +0100

Phillip Hallam-Baker <[email-masked]> wrote:
> The byterange extensions in http mean that it is possible to resume a

Most HTTP interactions aren't resumable in this way, so this observation
does not suggest to me that HTTP needs less routing stability than DNS.

> If the anycast changes then you are going to have to timeout and resume.

This is also true for HTTP. I still don't see why DNS needs more routing
stability than HTTP.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides, Bailey: West or northwest, becoming cyclonic 5 to 7,
occasionally gale 8, except in Hebrides. Rough or very rough, occasionally
high at first in Bailey. Rain or showers. Good, occasionally moderate.

---

From: "Guangqing Deng" <[email-masked]>
Date: Tue, 28 Apr 2015 23:35:19 +0800

Maybe we can consider this topic (anycast in content download and DNS) in another angle. For content download, the focus is throughput, and the freezing time caused by the anycast interruption is OK since the freezing time (which is usually several or tens or hundreds of milliseconds) can be omitted compared with the whole content download time which may be several or tens of minutes. While for DNS, the focus is the latency but not throughput, and the freezing time cannot be omitted since one normal DNS resolution latency is usually one RTT. So DNS is different from other applications like content download in the traffic pattern and QoS (Quality of Service) metric.

Guangqing Deng
CNNIC 
 
From: Tony Finch
Date: 2015-04-28 19:34
To: Phillip Hallam-Baker
CC: Warren Kumari; [email-masked]; Christian Huitema; Paul Hoffman
Subject: Re: [dns-privacy] DPRIVE over UDP or TCP

 
 
Tony.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 30 Apr 2015 21:21:04 -0700

> This is also true for HTTP. I still don't see why DNS needs more routing

DNS doesn't. But proposals like DNS over TLS rely on extremely long
lived connections. Most HTTP traffic goes over short connections that
end quickly. If we decide to shorten the connection length, even with
features like TLS 1.3's 0-RTT, the traffic quantity and computational
load will still increase. That's on top of the increased computation
of TLS vs DNSCrypt.

HTTP sends lots of packets over a short time, DNS few packets, long
time, very fast response required. That's on top of different
placements in networks. Maybe this isn't an issue, but I see some
evidence it will be, and not much it won't be.

Sincerely,
Watson Ladd

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 1 May 2015 04:40:15 +0000

> Sent: Friday, May 01, 2015 9:51 AM
> To: Tony Finch
> Cc: Christian Huitema; [email-masked]; Phillip Hallam-Baker; Warren
> Kumari; Paul Hoffman
> >> >> 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.
> >> >
> >> > Why?
> >>
> > Most HTTP interactions aren't resumable in this way, so this
> > observation does not suggest to me that HTTP needs less routing stability
> than DNS.
> >
> > This is also true for HTTP. I still don't see why DNS needs more
> > routing stability than HTTP.
> 
> DNS doesn't. But proposals like DNS over TLS rely on extremely long lived
> connections. Most HTTP traffic goes over short connections that end quickly.

WebPush already uses long-lived HTTPS session to push events to applications on the endpoint. 

-Tiru

> If we decide to shorten the connection length, even with features like TLS
> 1.3's 0-RTT, the traffic quantity and computational load will still increase.
> That's on top of the increased computation of TLS vs DNSCrypt.
> 
> HTTP sends lots of packets over a short time, DNS few packets, long time,
> very fast response required. That's on top of different placements in
> networks. Maybe this isn't an issue, but I see some evidence it will be, and
> not much it won't be.
> 
> Sincerely,
> Watson Ladd
> >
> > Tony.
> > --
> > f.anthony.n.finch  <[email-masked]>  http://dotat.at/ Rockall, Malin,
> > Hebrides, Bailey: West or northwest, becoming cyclonic 5 to 7,
> > occasionally gale 8, except in Hebrides. Rough or very rough,
> > occasionally high at first in Bailey. Rain or showers. Good, occasionally
> moderate.
> >