Nottingham: Internet protocols are changing

Posted Dec 12, 2017 17:58 UTC (Tue) by flussence (guest, #85566)
Parent article: Nottingham: Internet protocols are changing

Now that I'm thinking about it, it's weird that browsers don't *already* have a “DNS stapling” mechanism (cf. OCSP stapling) to cut out the port 53 middleman. I could imagine it being useful for more than just obsessive reduction of round trips, like redirecting localhost dev environments to an internal mirror. It seems like such an obvious omission from the current state of things, so maybe I'm missing something obvious too?

Nottingham: Internet protocols are changing

Posted Dec 12, 2017 18:07 UTC (Tue) by epa (subscriber, #39769) [Link] (4 responses)

The URI specification should allow the hostname to be given as both IP address and name at the same time.

https://{google.com:172.217.23.46:ZLgE36lVHk}/

where the last bit is some cryptographic signature from the original nameserver (so if you trust that nameserver with DNSSEC, you will trust that the new name/address pair seen in the URI is correct). That would reduce round trips still further.

Nottingham: Internet protocols are changing

Posted Dec 13, 2017 10:59 UTC (Wed) by buchanmilne (guest, #42315) [Link] (3 responses)

The URI specification should allow the hostname to be given as both IP address and name at the same time. https://{google.com:172.217.23.46:ZLgE36lVHk}/ where the last bit is some cryptographic signature from the original nameserver (so if you trust that nameserver with DNSSEC, you will trust that the new name/address pair seen in the URI is correct). That would reduce round trips still further.

But now you've made the experience worse for everyone for whom the best Google PoP or Edge PoP (and of course any other CDN) isn't the same as yours. For example, for me, google.com is one of 6 addresses in 108.177.119/24, but from home it's a totally different range. For people who live 500ms away from you on a slow-ish link (e.g < 1Mbps), this could be the difference between the internet working, and not working (e.g. Youtube doesn't play, Netflix doesn't work, Google images take forever to load, Android App Updates fail).

Nottingham: Internet protocols are changing

Posted Dec 13, 2017 14:21 UTC (Wed) by epa (subscriber, #39769) [Link]

I agree, and perhaps google.com was not the best example. It would make more sense to use it only for hostnames that resolve to a single IP address (or a round-robin set where the particular one to use is arbitrary). Or else to extend it to list multiple addresses separated by commas.

I envisaged that if your machine already has a cached IP address for that hostname, you use that as normal. Only if you don't currently have the hostname resolved would you have the option of saving a round trip (or bypassing hostile DNS blocking) by using the address embedded in the URI.

Nottingham: Internet protocols are changing

Posted Jan 8, 2018 0:55 UTC (Mon) by immibis (subscriber, #105511) [Link] (1 responses)

To mitigate that, either the client could look up the host itself and validate the result using a key encode in the URL -or it could just ask the server at the specified IP whether there's a better IP (distributed DNS?).

Nottingham: Internet protocols are changing

Posted Jan 18, 2018 2:32 UTC (Thu) by flussence (guest, #85566) [Link]

This whole line of logic is going a bit off course, but there *is* a mechanism for suggesting different servers to clients (the Alt-Svc HTTP header, fairly recent addition too).

Nottingham: Internet protocols are changing

Posted Dec 13, 2017 9:53 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

I suspect the obvious thing you're missing is that this situation is nothing like either of the stapling mechanisms currently in play?

With OCSP stapling when I connect to a server, and it is going to show me the certificate saying "I'm server A" it can staple the OCSP response which says "I, the OCSP server, promise this certificate for server A is still good". It is trivially able to obtain this response because it has the certificate already, and the response is signed, so it doesn't matter how it is delivered [Yet despite this two of the world's most popular web servers can't get this right...]

With CT stapling when I connect to an OCSP server to ask about server A and it's going to provide an OCSP response "I, the OCSP server, promise this certificate for server A is still good" it can also staple the SCT which says "I, a CT log server promise this certificate was logged at a specific moment of time T", it knows the full set of certificates it cares about [that's what OCSP is for] and so it also has all the SCTs for them if it wants. This too is signed and so it doesn't matter how it's delivered [Although details of how exactly we ensure that bogus proofs are detected are still up in the air]

But with "Flussence DNS Stapling" how does this work? What's signed? Who am I connecting to that knows I need this?

The user just typed bimble.example.com into my browser. I want to use "Flussence DNS Stapling" which I've heard is great and will speed things up. What do I do now? I need to start sending a packet immediately. I don't know where to send it, what should I put in it - the "Flussence DNS Stapling" needs to have fast, reliable answers for both those things or it's useless, because in just a few milliseconds a traditional DNS would probably have an answer.