Re: Skipping DNS resolutions with ORIGIN frame

DNS-over-HTTPS would require _clients_ to make the DNS query (most
likely to a different server), instead of receiving cached DNS
response from the server that can send it to many clients, so you'd be
losing some of the properties that you care about.

Best regards,
Piotr Sikora

On Wed, Jul 19, 2017 at 4:41 PM, Martin Thomson
<> wrote:
> I would not modify the protocol in that way.  I would prefer to leave
> ORIGIN alone.  DOH is a much a better way to get that information to
> the client, for example.
> On 19 July 2017 at 10:00, Piotr Sikora <> wrote:
>> Yes, DNSSEC staple in ORIGIN frame is definitely a good option.
>> It doesn't solve _all_ problems, e.g. GeoDNS, since we don't know that
>> the same DNS response would be sent for a query issued by this
>> particular client, but none of the suggested alternatives solve this
>> anyway (other than the SkipDNS X509 extension, which doesn't have many
>> fans here), so we shouldn't dismiss DNSSEC staple because of that.
>> Best regards,
>> Piotr Sikora
>> On Tue, Jul 18, 2017 at 8:38 PM, Ryan Hamilton <> wrote:
>>> On Fri, Jul 14, 2017 at 11:30 PM, Patrick McManus <>
>>> wrote:
>>>> Hey Ryan, thanks for the comments.
>>>> On Fri, Jul 14, 2017 at 3:18 PM, Ryan Hamilton <> 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.
>>> Interesting point. It's a bit of a tradeoff between privacy and security
>>> then, I suppose.
>>>> 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.
>>> I think that'd definitely a step in the right direction, but I heard some
>>> real security concerns about "blindly" skipping resolution in this case, so
>>> I'm interested to hear what the group things about the advisability of doing
>>> this.
>>>> 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..
>>> It does seem like a stapled DNSSEC response is a plausible option here!
>>>> I'm not sure I fully understand what you're thinking of wrt expect-ct
>>>> -does it fit that model?
>>> I don't think I was thinking about expect-ct per-se. Instead, folks were
>>> thinking that we could consider skipping DNS resolutions when the
>>> certificate is valid according to the CT logs that the client has access
>>> too. This is a different sort of assertion from a second source that helps
>>> mitigate the impact of a mis-issued certificate, which is the main fear of
>>> skipping DNS.

Received on Wednesday, 19 July 2017 15:33:51 UTC