RE: Skipping DNS resolutions with ORIGIN frame

The Alt-Svc is a name, but it's quite possible that it's a name you've already done DNS resolution for.  Or, worst case, you resolve the target hostname and the Alt-Svc name in parallel and check whether the currently-connected host is in either set.  You don't save the DNS resolution, but you get some evidence of shared control.  That's more important, in my book.

We share the same reservations about not doing the DNS lookups, FWIW.  I've also been looking at Alt-Svc as a middle ground here.  A collection of origins that have disjoint IPs but share a certificate and want to coalesce simply have to issue Alt-Svc records pointing to the same place.  Whether that's one of the hostnames being considered primary, or a "special" hostname that returns the union of the IP addresses (so whatever you're connected to already will be in that set), or simply a dedicated hostname that's used for Alt-Svc doesn't matter so much.  That means you'll have to connect to each origin once to get the Alt-Svc record, but thereafter you get the best of both worlds.  While that seems daunting for certificates that contain 70+ names including wildcards, the typical client doesn't actually connect to that full set of hostnames.

(A way to get the Alt-Svc records without having to make HTTP requests first might also help here, but doing so securely requires infrastructure that isn't practically available yet.)

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Friday, July 14, 2017 10:32 AM
To: Ryan Hamilton <rch@google.com>
Cc: ietf-http-wg@w3.org; Piotr Sikora <piotrsikora@google.com>
Subject: Re: Skipping DNS resolutions with ORIGIN frame

On 14 July 2017 at 23:18, Ryan Hamilton <rch@google.com> wrote:
> Before trusting a certificate for a connection, we'd like an assertion 
> from some other trusted source. This could be:
> * On-path presence, for example DNS resolution, or proxy configuration
> * A previous assertion from the origin itself (Alt-Svc)
> * CT logs, etc.
> Without such an assertion, we're not comfortable trusting the 
> connection and plan to continue consulting DNS when making use of the 
> ORIGIN frame in Chrome.

Hi Ryan,

It's good that you are sharing this, but I did want to clarify a few of these points.

I get that you believe that DNS resolution is valuable here, but I don't understand your point about "proxy configuration".  If you have a proxy configured, you generally don't do the DNS lookup directly, so are you saying that you would allow the coalescing for a CONNECT tunnel?

Can you verify that I understand your point about Alt-Svc: if the origin had been previously contacted and Alt-Svc identified an IP address that matches the current IP, then that could be a sufficient signal.  Usually Alt-Svc is a name though, so that wouldn't help.

Similarly, are you saying that CT could assert something that would cause you to skip the DNS lookup for a name?

Or is this list just to make a more general point about raising the bar for gaining the ability to use a name, and not something that is specific to this particular example of DNS lookups?

Cheers,
Martin

Received on Friday, 14 July 2017 22:28:20 UTC