> On Nov 6, 2018, at 17:27, Mukund Sivaraman <m...@mukund.org> wrote:
>
> We talked about DNSSEC and certificate signing and such. If the host
> serving this webpage to the browser has control over the webpage's
> content (e.g., the contents of that src attribute), and the webpage's
> contents are already authenticated by TLS, then why does an address
> record have to be separately authenticated?

I think this is an easy one. It doesn't.

The names that it is permissible for a server to push information
about (and the names that a client should be allowed to accept) must
be constrained such that the names supplied for use in one web
application can't influence the operation of another.

(For example, it would be bad if some generic and otherwise benign web
page could feed the browser high-TTL DNS messages for names under
online retailer domains that accept credit cards or component APIs
used within genuine web apps.)

The obvious analogy to me is the logic that controls what cookies a
browser should accept. Maybe exactly the same rules are appropriate. I
realise that managing those rules using mechanisms like the public
suffix list is not without challenges.

If we accept that these constraints are necessary, then the presence
or absence of DNSSEC signatures doesn't matter. The DoH objects are
within the same security perimeter as the URIs that make use of them
and don't benefit from additional integrity protection; the transport
security for all the other objects being sent from server to client
provides the right coverage.


Joe

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to