> 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
