Re: [Doh] [DNSOP] On today's resolverless DNS meeting

[Ben Schwartz <[e-mail]>]

DOH and dnsop to bcc.

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

> Briefly jumping in to add [e-mail], 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 <[e-mail]> wrote:
>
>> > On Nov 6, 2018, at 17:27, Mukund Sivaraman <[e-mail]> 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.
>>
>
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.

(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
>>
>> _______________________________________________
>> Doh mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/doh
>>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>