Subject: [Doh] On today's resolverless DNS meeting

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 6 Nov 2018 17:27:31 +0700

Hi all

It seemed that the objective (or an objective) of what is desired is for
a webpage to have an <img src=""> and also push an address record for
the hostname in the src URL.

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?

Why can't the webpage contain the addresses of the hostname in the URL,
in another attribute of that element? Does it have to be separately
signed via DNSSEC and certificates? The webpage can tell the browser to
fetch the img resource from anyplace it wants to - it can very well
specify an IP address instead of the hostname - the webpage controls
it. Why can't it, for *that* element, provide the target address in an
attribute without any additional signatures, given that the webpage's
content itself is authenticated via TLS?

		Mukund

---

From: Joe Abley <[email-masked]>
Date: Tue, 6 Nov 2018 06:39:30 -0800

> On Nov 6, 2018, at 17:27, Mukund Sivaraman <[email-masked]> wrote:
>

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

---

From: Justin Henck <[email-masked]>
Date: Tue, 6 Nov 2018 21:44:55 +0700

Briefly jumping in to add [email-masked], which was set up after
the last meeting for discussion of this specific topic.  Direct link:
https://www.ietf.org/mailman/listinfo/resolverless-dns

I also just sent the notes to that mailing list.

Justin Henck
Product Manager
212-565-9811
google.com/jigsaw

PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B

On Tue, Nov 6, 2018 at 9:39 PM Joe Abley <[email-masked]> wrote:

> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 6 Nov 2018 13:58:33 -0500

DOH and dnsop to bcc.

On Tue, Nov 6, 2018 at 9:45 AM Justin Henck <henck=
[email-masked]> wrote:

> Briefly jumping in to add [email-masked], which was set up
> after the last meeting for discussion of this specific topic.  Direct link:
I don't see any way to do this in the web security model.  For example, if
two web applications both use subresources from the same origin, then
cookies loaded for that origin from one application will be included in
requests to the other.  Similarly, subresource cache entries populated by
one application will be reused by other applications.  Web security is
scoped to the domain of each request, not the domain of the page.
Additionally, most browsers perform connection coalescing for resources on
the same origin, even if the requests are from different tabs.

I'm very interested in finding a solution here, but I don't think it will
be so simple.  For example, there may be a nontrivial interaction with the
iframe "sandbox" attribute.

Some of these problems become easier if we imagine an https-only world.
However, many browser engineers believe that DNS integrity acts as an
important barrier to utilization of stolen WebPKI private keys.  If you
accept this threat model, using unsigned DNS records from untrusted parties
could enable more stolen-key attacks.

There is a complex intersection of web and DNS problems, and IMHO too
speculative for dnsop (and out of scope for doh's current charter), so I
would encourage interested parties to join the resolverless-dns list.