Subject: [Resolverless-dns] 103 Unofficial Side-meeting Notes

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

Hi all,
Thanks for attending the side-meeting today. Though there are clearly some
issues to resolve, there were three specific proposals put forward during
and after the meeting for pushing DNS records or similar information.
(Listed below in the order they were presented.) Since I'm a newcomer, what
seems like a good goal for 104?

Proposal 1: DNSSEC-signed: Any outbound link or resource from a site
Proposal 2: ??: CDN-local links or resources
Proposal 3: Within TLS: Any automatically loaded resource, perhaps in the
HTML

I've attached the complete notes captured as best I was able.  The lack of
attribution is more a consequence of the many new faces for me than
anything else, so please feel free to edit the etherpad (
http://etherpad.tools.ietf.org:9000/p/notes-ietf-103-unofficial-resolverless)
to attribute yourself or your organization and we can send the notes out
again later.

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

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

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 6 Nov 2018 15:14:37 -0500

> Proposal 1: DNSSEC-signed: Any outbound link or resource from a site

This still seems like the most promising option to me, particularly because
it preserves the DNS defense against stolen key attacks.

> What if we allow hostnames to opt-in or opt-out of having records for
their hostname pushed by other services?

I think this is an interesting idea.  You could roughly describe it as an
"anycast bit", identifying that this RRSET is good for any client, not
geotargeted or load-balanced.  However, it's not clear to me that it's
necessary.  The concern here seems to be about degradation and denial of
service from html that reaches large numbers of users (e.g. search engines,
ad networks).  However, if one of these systems were malicious it could
already mount a large DDOS attack, e.g. using XHR.

Rather than block while we consider this opt-in, I'd rather find a design
that allows us to do this in the future if it proves necessary.  One way I
can see would be to standardize a new HTTP request header, e.g.
"Accept-DNS".  The header value would indicate the client's policy for
accepting pushed records.  For example, we could start with a "dnssec"
policy (indicating records must be signed), and then define additional
policies in the future (e.g. "dnssec-global" for hypothetical
anycast-tagged RRSETs, "same-parent" for domains under the same eTLD+1,
etc.).

A new HTTP request header would also enable experimenting with Resolverless
without having to push DNS records to millions of existing clients that
will ignore them.

> Supercookies

Everybody should check out https://dnscookie.com/ for a demo of this.
DNSSEC doesn't help; a malicious authoritative could give unique signed
records to each user.  I think it should be sufficient to make the DNS
cache entries cookie-scoped (i.e. profile- or container-scoped, cleared
when cookies are cleared).

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 7 Nov 2018 08:51:34 -0500

Ben Schwartz writes:
> This still seems like the most promising option to me, particularly
> because it preserves the DNS defense against stolen key attacks.

It also keeps things well within our existing model of understanding
delegation of authority for Internet resources without relying on
third parties.  As a side benefit, maybe this is also another kick in
the pants for DNSSEC adoption.

> Everybody should check out https://dnscookie.com/ for a demo of

ERR_CONNECTION_REFUSED

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 7 Nov 2018 11:01:35 -0500

> > Everybody should check out https://dnscookie.com/ for a demo of

Argh, looks like it's ironically http-only.  http://dnscookie.com

-- 
> Resolverless-dns mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/resolverless-dns
>

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 8 Nov 2018 02:10:25 -0500

Ben Schwartz writes:
> http://dnscookie.com

This apparently has no relation to RFC 7873, "Domain Name System (DNS)
Cookies", correct?  Could it be renamed to avoid confusion?

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 08 Nov 2018 14:53:33 +0700

Moin!

> Proposal 1: DNSSEC-signed: Any outbound link or resource from a site
This has the problem that the information the http server has might be 
signed, but still could lead the user to a bad endpoint from a CDN 
perspective as the DNS query probably was done with the IP of the http 
server and not the client. Yeah I know there is ECS for this, but most 
authoritative servers only accept that when you are whitelisted.

> Proposal 2: ??: CDN-local links or resources
This is the only way that potentially could work, but even then you 
loose all the security properties your resolver normally provides you 
and it totally is possible for bad guys to serve traffic over a CDN.

> Proposal 3: Within TLS: Any automatically loaded resource, perhaps in 
Seems similar to 2, maybe a bit wider, but still could be used to attack 
you.

I think we have to recognise the case that an attacker controls the 
endpoint you connect to and can circumvent security measures you have in 
a your resolver which might be protection agains DNS rebinding (sneaking 
in a public name to point to your RFC1918) for homes and enterprises, or 
might start a phishing attack by sneaking in a IDN near identical name 
(goᴏgle.com. - look closely if you would have catched this real domain 
is xn--gogle-n29a.com. ) and then directing you there.

In both cases your security properties possibly get worse when using 
resolver less DNS.

So long
-Ralf
—--
Ralf Weber