Re: [dnsoverhttp] New draft: draft-hoffman-dns-over-http-00.txt

[Ted Hardie <[e-mail]>]

On Tue, Sep 20, 2016 at 7:10 PM, Martin Thomson <[e-mail]>
wrote:

> On 21 September 2016 at 09:02, Ted Hardie <[e-mail]> wrote:
> > That can't be corrected by DNSSEC, since it is correctly signed.
>
> It can be corrected by making another request.
>
>
You'll get a different answer if you make another request using a different
method or DNS API server.


> I find the unstated point that you are pushing on quite interesting:
> DNSSEC doesn't authenticate all the things that might be important in
> the protocol.  Or maybe that there still remains some need for trust
> in the protocol when it comes to recursive resolvers.
>
> > For the server push case, I pretty much assume that the only trusted DNS
> > resources from https://blogplatform.example.com/ will be those related
> to
> > example.com (hello, public suffix list and dbound!)
>
> That would negate much of the value of having this sort of feature.  I
> can see several ways around this.  The easiest being to scope the use
> of the record until it can be independently verified.
>
>
Using a browser as an example, if you scope this such that server pushed
DNS records are only used in the same tab/browser context, then I agree
with you; the threat model I am concerned about is one where it gets
blended into the general name resolution pool.  That means the usual TTL
model of the DNS is not quite the same if you getting the records from this
method, and I think that has to be called out.


> The tracker can use alt-svc, or push its own records to update the
> client's view and correct any infidelity.
>
> If pushed record use is limited to the current site, then the tracker
> might be affected, but that only negatively affects the perception of
> the site that includes the tracker.
>

I tam note sure "site" is quite right here, but I agree with the
sentiment--if you push bad records, they should affect only the perception
of the site that pushed them.

Ted