Re: Skipping DNS resolutions with ORIGIN frame

If this uses DNSSEC, then there is a possibility that it is sufficient
for this purpose (though perhaps not generally useful).

On 19 July 2017 at 17:33, Piotr Sikora <> wrote:
> 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:38:39 UTC