- From: Piotr Sikora <piotrsikora@google.com>
- Date: Sun, 16 Jul 2017 13:18:29 +0200
- To: Nick Sullivan <nicholas.sullivan@gmail.com>
- Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, Erik Nygren <erik@nygren.org>, Patrick McManus <mcmanus@ducksong.com>, Ryan Hamilton <rch@google.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
As mentioned on GitHub [1], where we also discussed this, I believe that the "skip DNS" extension makes sense, provided that it's used together with CT. But if we go that route, then that extension might be a bit more generic and perhaps not restricted to the ORIGIN frame, in which case the ORIGIN frame draft should re-focus on restricting the scope of the origin-set and not bypassing DNS, as suggested by Erik. [1] https://github.com/httpwg/http-extensions/issues/330 Best regards, Piotr Sikora On Sun, Jul 16, 2017 at 12:15 PM, Nick Sullivan <nicholas.sullivan@gmail.com> wrote: > There is merit to both sides. Requiring DNS adds a weak second factor for > routing decisions, which is useful in multi-CDN situations, or extra-broad > certificates, where you want to prevent a CDN from routing extra traffic via > ORIGIN. On the other hand, skipping DNS is a big step forward for both > performance and privacy, it basically solves the encrypted SNI issue. > > The question we should ask is: who should make the determination of whether > or not the user agent should check DNS given an origin frame? This > discussion shows there is no consensus that the answer is that the ORIGIN > proposal makes this explicit. Given differing views from browser > representatives, the answer might be that it's up to the user agent to > decide. However, server operators don't seem too happy about dealing with > divergent client behaviors, so it doesn't seem that letting the UA decide is > feasible. > > I think the answer that makes sense is to allow the site owner decide if > content for its domain should require a DNS check or not. Martin Thomson was > on to something with his certificate extension idea in the Github > discussion. The policy around the requirement for DNS can be set in the > certificate. > > How do people feel about adding a certificate extension with a meaning along > the lines of "require DNS"? Site owners with multi-CDN setups could give > such a cert to third parties they want to handle direct traffic, but not be > able to coalesce into an existing connection. > > Alternatively there could be a "skip DNS" extension, which tells the browser > that the site owner has delegated routing from DNS to the cert holder, and > that DNS checks are superfluous. > > Thoughts? > > Nick > > > > > On Sat, Jul 15, 2017 at 8:04 PM Ilari Liusvaara <ilariliusvaara@welho.com> > wrote: >> >> On Sat, Jul 15, 2017 at 12:47:49PM -0400, Erik Nygren wrote: >> > My concerns align with Ryan and Mike's. My preference would be to >> > remove >> > the current language about not consulting DNS from the ORIGIN draft >> > (having >> > it focus on restricting scope with hooks for future expansion). >> > >> > Separately we can start collaborating on a draft that finds a good set >> > of >> > controls to give the balance of security and privacy and performance >> > properties. Alt-Svc (perhaps with an extension attribute?) does seem >> > like >> > a good starting point as it gives positive control from an Origin. The >> > other ideas (eg, something CT like) seem intriguing but need more >> > exploration. >> >> Let's take four schemes: >> >> 1) No checks (beyond usual certificate checks) >> 2) Require CT qualification (and possibly OCSP). >> 3) ALT-SVC (not entierely clear to me, but I can guess) >> 4) Consult DNS >> >> >> For privacy and speed, 1) and 2) have big advantage over 3) and 4) >> (and 3) is even worse than 4) in both).. >> >> For security using standard assumptions, all are very close to one >> another. >> >> >> The main problem with not giving control seems to be servers that have >> overly wide certificates and then mishandle requests (through sadly >> most servers do mishandle requests). >> >> >> >> -Ilari >> >
Received on Sunday, 16 July 2017 11:18:58 UTC