Re: Skipping DNS resolutions with ORIGIN frame

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.

- Erik



On Jul 15, 2017 1:36 AM, "Patrick McManus" <mcmanus@ducksong.com> wrote:

> Hey Ryan, thanks for the comments.
>
> On Fri, Jul 14, 2017 at 3:18 PM, Ryan Hamilton <rch@google.com> wrote:
>
>> . It is crystal clear that saving DNS resolutions represents a real
>> performance win, especially for long-tail users.
>>
>>
> I want to re-emphasize here that I believe a perhaps larger win here is
> the privacy implication of a lookup never made - especially when combined
> with secondary certificates and exported authentiactors (still to come to
> h2). This achieves much of what encrypted SNI could do.
>
> My first question is would you be ok with just loosening the draft
> language a little bit.. i.e. instead of saying must not consult DNS, define
> this in a way that it is the client's decision.
>
> As I've said before, I don't think the DNS is providing any real value
> here now that ORIGIN is playing the role of traffic routing. Indeed it is
> creating a privacy cost - so I'm eager to get it out of the loop.
>
> If we can't get consensus on that I'd prefer some kind of stapled
> assertion that kept the perf and privacy properties of the current draft. I
> guess that could be dnssec though that would certainly limit use for imo
> limited value.. I'm not sure I fully understand what you're thinking of wrt
> expect-ct -does it fit that model?
>
> -Patrick
>