Subject: [Add] Review of draft-pauly-add-deer-00.txt+

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Nov 2020 16:12:50 -0800

Document: draft-pauly-add-deer-00.txt

This seems overall like a fairly sensible mechanism if we
assume that HTTPSVC is viable for this purpose. We're working
on how to gather some data here and will hopefully have
something soon; would be great to hear what others have.

Some comments below.

S 2.
   Equivalent Encrypted Resolver:  An Encrypted Resolver which is
      considered to provide answers equivalent to a given resolver.
      This equivalency can be authenticated with TLS certificates.

This has the same problem as with draft-box. If the attacker
stands up a resolver that proxies to the given resolver, it would
meet this definition, but would not provide confidentiality,
which is one of the prime motivators for this work.

I know this kind of thing is difficult to formalize, but I think
we actually need to. There are two properties we need to capture
(1) that your data is only going to the EER (2) that the answers
are somehow similar. Perhaps.

   An Equivalent Encrypted Resolver is one in which (1) the client
   receives equivalent answers to and (2) the attacker learns no more
   information than if the client's queries/responses were delivered
   directly to/from the given resolver without any access by the
   attacker.

Note that the definition of equivalent answers is still somewhat
problematic. Ideally we would like to say that the attacker cannot
influence the answers at all, but consider the case where the
EER is located in some different part of the network topology
then an attacker can influence your responses by sending you to
an EER or not.

S 7.
I think it would be useful to clarify what you think the security
implications of the opportunistic versus non-opportunistic approaches
are. I think I know, but you should lay it out.

S 8.1.
I think it would be useful to specify some sort of draft SUDN
so that we can experiment.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Nov 2020 17:04:54 -0800

> then an attacker can influence your responses by sending you to

Following up on this point. Consider the case where we have a Do53 resolver
at 192.1.2.1 The ISP operates a DoT resolver at 192.1.2.2, so it would
have the record:

   _dns.example.net  7200  IN SVCB 1 dot.example.net (
        alpn=dot port=8530 ipv4hint=192.1.2.2 )

Now, if that DoT resolver provides different responses based on the client's
apparent IP address, then an on-network attacker can serve their own record:

   _dns.example.net  7200  IN SVCB 1 dot.example.net (
        alpn=dot port=8530 ipv4hint=203.1.113.1)

Where the ipv4hint refers to something they control. They then proxy the
TLS connection to the true DoT server. Because the SAN only needs to
contain the Unencrypted Resolver address and *not* the Encrypted Resolver
address, then this will succeed, with the result that the client gets
different
data than it would if the attacker had not been present. This raises several
questions:

1. Do we think this is bad?
2. If the answer to (1) is yes, how do we redefine equivalence to cover it?
3. What does DEER need to do to stop it? [Off the top of my head,
    perhaps have the ER's address also be in the SAN field of the cert and
   check that]

-Ekr

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 14 Nov 2020 20:34:13 -0800

Hi Ekr,

Thanks for the review! Some initial responses inline.

> On Nov 14, 2020, at 5:04 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
> On Sat, Nov 14, 2020 at 4:12 PM Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:

Happy to hear how your SVCB measurements look. Now that iOS and macOS are sending out HTTPS SVCB queries on all DNS queries for HTTP sites, we’ve been able to get some more data at scale.

Worldwide, I’m seeing that 1.53% of domains are currently getting SVCB responses—that’s largely because the record type is quite new, and mainly only Cloudflare has been adding the records. A rate of 1-2% of domains seems quite consistent across different network providers and geographic regions. There are a few networks that seem to be filtering the responses (they get 0%), but these seem to be exceptional.

Importantly, we aren't seeing functional breakage due to sending the queries.

> are somehow similar.

The definition here is indeed similar to the one in the requirements draft, and I agree that both definitions of equivalency ought to be formalized to be more clear about these kinds of attacks.

A scenario where the attacker is able to intercept all the DNS messages should indeed not be deemed equivalent.

> Perhaps.
>    _dns.example.net <http://dns.example.net/>  7200  IN SVCB 1 dot.example.net <http://dot.example.net/> (
>    _dns.example.net <http://dns.example.net/>  7200  IN SVCB 1 dot.example.net <http://dot.example.net/> (
> address, then this will succeed, with the result that the client gets different

Thanks for bringing up this point.

Our initial version of the DEER draft did require that the certificate cover both the original Do53 resolver’s IP address and the EER’s IP address. However, we were having trouble articulating the scenario that required including the EER’s IP address. (One thing to note for this list is that if the Do53 and EER are both on the same IP address, this is already covered).

Specifically, we did consider that it would be possible for an attacker to proxy TCP connections to a TLS-protected EER, but that alone didn't allow the attacker to observe or directly modify the DNS messages. If that is the extent of the attack (being a transparent TCP proxy), I think we can argue that this might not be bad.

The point you bring up here that we didn’t consider was the fact that such a proxy would be changing the client IP address that the EER would observe, and thus might change the actual DNS answers if they are based on the client IP address or client subnet.

I think the main question is if the definition of using an equivalent resolver means that the DNS answers need to take the same client IP address into account. This may be good to discuss in the WG meeting.

Thanks,
Tommy

> 
> -Ekr
> -- 
> Add mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 15 Nov 2020 19:50:44 -0500

> data than it would if the attacker had not been present. This raises several

So the TLS connection is intact.
The client is connected to the correct destination, but resolver sees the
attacker's origin IP rather than the client's address.

    > 1. Do we think this is bad?

It sounds like classic NAPT to me.

    > perhaps have the ER's address also be in the SAN field of the cert and

That would work.

Another possibility is that the server should never believe the origin IP,
but rather the client should tell the server of it's address inband.

I believe that the is a spec for this, but I don't have the dns-fu anymore to
remember which one it is.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Nov 2020 16:55:38 -0800

> attacker's origin IP rather than the client's address.

Correct.

> It sounds like classic NAPT to me.

Well, sort of. In non-adversarial NAPT, the client's apparent address
reflects its position in the network but that's not true here.

> remember which one it is.

Hmm... Absent something like STUN, clients don't necessarily know their
apparent (server reflexive) address but only their local (host) address.
And even if you use STUN, there's no guarantee that the NAT will have
consistent address bindings. It might have an address-dependent mapping.

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Nov 2020 02:32:59 -0500

> reflects its position in the network but that's not true here.

That's an interesting term, "non-adversarial NAPT".

    > consistent address bindings. It might have an address-dependent mapping.

Noting that this is all IPv4-specific, and such a case, the non-adversarial
NAPT and/or ISP provided CGN could be moving the apparent client IP all over
the place.

So I don't really think it is an issue in IPv4: it's all fiction anyway.
The same is not true in IPv6: we could reasonably detect such adversarial NAPT.