Re: Skipping DNS resolutions with ORIGIN frame

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