Subject: [dns-privacy] Fwd: New Version Notification for draft-dkgjsal-dprive-unilateral-probing-01.txt

From: Joey Salazar <[email-masked]>
Date: Thu, 9 Dec 2021 13:49:07 +0100

Hi dprive,

Here's a list of changes introduced in version -01 regarding the use of SNI:

   - SNI guidance for authoritative servers on two scenarios;
      - using SNI for alternate server credentials
      - serving different records based on SNI
      - SNI guidance for recursive resolvers
   - added SNI privacy considerations

Do these changes resolve the concerns of the group enough to reach
consensus on the topic?

All thoughts, concerns, suggestions, and questions most welcome,
--
dkg and Joey

---------- Forwarded message ---------
From: <[email-masked]>
Date: Thu, Dec 9, 2021 at 1:22 PM
Subject: New Version Notification for
draft-dkgjsal-dprive-unilateral-probing-01.txt
To: Daniel Kahn Gillmor <[email-masked]>, Joey Salazar <
[email-masked]>

A new version of I-D, draft-dkgjsal-dprive-unilateral-probing-01.txt
has been successfully submitted by Joey Salazar and posted to the
IETF repository.

Name:           draft-dkgjsal-dprive-unilateral-probing
Revision:       01
Title:          Unilateral Opportunistic Deployment of Encrypted
Recursive-to-Authoritative DNS
Document date:  2021-12-09
Group:          Individual Submission
Pages:          23
URL:
https://www.ietf.org/archive/id/draft-dkgjsal-dprive-unilateral-probing-01.txt
Status:
https://datatracker.ietf.org/doc/draft-dkgjsal-dprive-unilateral-probing/
Html:
https://www.ietf.org/archive/id/draft-dkgjsal-dprive-unilateral-probing-01.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dkgjsal-dprive-unilateral-probing
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dkgjsal-dprive-unilateral-probing-01

Abstract:
   This draft sets out steps that DNS servers (recursive resolvers and
   authoritative servers) can take unilaterally (without any
   coordination with other peers) to defend DNS query privacy against a
   passive network monitor.  The steps in this draft can be defeated by
   an active attacker, but should be simpler and less risky to deploy
   than more powerful defenses.  The draft also introduces (but does not
   try to specify) the semantics of signalling that would permit defense
   against an active attacker.

   The goal of this draft is to simplify and speed deployment of
   opportunistic encrypted transport in the recursive-to-authoritative
   hop of the DNS ecosystem.  With wider easy deployment of the
   underlying transport on an opportunistic basis, we hope to facilitate
   the future specification of stronger cryptographic protections
   against more powerful attacks.

The IETF Secretariat

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 9 Dec 2021 16:14:36 -0500

The SNI guidance looks good to me.

I find it confusing to mention ECH in this draft.  ECH can never be used
with this specification, because there is (by definition) no SVCB record to
provide the ECH keys.  (If there is a SVCB record in play, then we are no
longer in "unilateral probing".)

I did notice one issue with -01:

      To avoid incurring additional minor timeouts for such a recursive
>     resolver, the pool operator SHOULD either:
>
>     *  ensure that all members of the pool enable the same encrypted
>        transport(s) simultaneously, or
>
>     *  ensure that the load balancer maps client requests to pool members
>        based on client IP addresses.

The first option seems a bit unrealistic.  I would replace it with "ensure
that any members of the pool return an explicit rejection packet (e.g. TCP
RST) if they do not support the encrypted protocol, or".

On Thu, Dec 9, 2021 at 7:47 AM Joey Salazar <[email-masked]> wrote:

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 10 Dec 2021 23:58:46 +0200

Hi Ben--

Thanks for the prompt review and feedback!

> longer in "unilateral probing".)

given that we haven't established what the signalling mechanism
is/should be for authoritative dprive, i'm not entirely sure that we're
out of the realm of unilateral probing here.  (for example, does the
mere presence of SVCB indicate a hard-fail condition?)  I think that's
up to the other draft. ☺

That said, i don't think i'd have an objection to removing the ECH
reference (or at least trimming it down to only be relevant for the
discussion of potential leak due to SNI in the privacy considerations
section)

> The first option seems a bit unrealistic.

It might be unrealistic for some pool operators, but it's surely not
unrealistic to all pool operators (for some plausibly-fuzzy definition
of "simultaneously")

> I would replace it with "ensure that any members of the pool return an
> explicit rejection packet (e.g. TCP RST) if they do not support the
> encrypted protocol, or".

While this is good guidance in general for authoritative servers (i'd
include "ICMP port unreachable" in list alongside TCP RST, and maybe
some QUIC-specific signalling?), i'm not convinced it belongs in this
section about authoritatives behind a pool.

In particular, i don't think the consequences of this approach would
yield a healthy pool, which is why i didn't include it in the list
initially.

First, if a pool's load balancer can't reliably map traffic from the
client at IP address X to pool member Y at all, then any sort of
stream-based protocol (whether that's DoT or DoQ or even Do53 over TCP)
is going to fail in pretty terrible ways.

If we assume that the load balancer is capable of allocating persistent
stream-like flows (including QUIC sessions if DoQ is in the mix?) to
specific pool members, but randomly allocates stream-initiating packets
from the same client IP address to different pool members, then we'll
have the problem that a client will "learn" that an encrypted transport
is available to that authoritative, and upon the next stream initiation
might land on a pool member that doesn't implement that encrypted
transport.

In effect, the presence of encrypted transport will "flap" for any given
client.

While the consequences will be relatively small (even if the RST or port
unreachable messages are swallowed by the network, the default `timeout`
parameter for establishing the encrypted transport has fast expiry),
clients will still incur at least an extra serialized round-trip on each
"flap", and if the allocations are truly random they'll be frequently
"damped" into not trying encrypted transport for a full day.

How would you feel about adding the guidance you suggested more
generally to the overall guidance for authoritative servers?

         --dkg

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 13 Dec 2021 08:34:22 -0800

> mere presence of SVCB indicate a hard-fail condition?)  I think that's

The terminology section says

   *  "unilateral" means capable of opportunistic probing deployment
      without external coordination with any of the other parties

To my eye, that excludes any way of delivering ECHConfigs, whether or not
SVCB becomes the preferred mechanism for that.

In general, I think this draft should try to be clear that it is restricted
to the case where no additional DNS queries are performed.

> unrealistic to all pool operators (for some plausibly-fuzzy definition

Perhaps "within the span of a few seconds" would be clearer.

> is going to fail in pretty terrible ways.

I'm not sure this is true.  A 5-tuple load balancer, for example, would
preserve stream continuity but fail for the purpose of this section.

I also don't think IP-based load balancing is technically sufficient.  For
large resolvers with multiple "exit" IPs, there is (currently) no
requirement that the state estimate for a given destination IP be
partitioned by the resolver's exit IP.

> "flap",

Yes, but this is no worse than the handshake of the encrypted transport we
are seeking to bootstrap, so it's a performance cost that will be borne
anyway.

and if the allocations are truly random they'll be frequently
> "damped" into not trying encrypted transport for a full day.

This is interesting.  Maybe the long damping should only apply if the
request timed out, as opposed to being rejected within a few milliseconds.

> generally to the overall guidance for authoritative servers?

I don't have specific thoughts on how to structure the guidance yet.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 13 Dec 2021 22:27:31 +0200

Hi Ben--

> to the case where no additional DNS queries are performed.

I'd be game for such a clarification, but i'm not sure how to define
what "additional" means here.  Surely this draft is not going to
encourage any draft-specific DNS queries, but it's also not going to
prohibit any DNS queries which might otherwise take place, right?

For example, imagine a TLS client stack that automatically checks for
ECHConfigs (assuming that mechanism has been specified, as i hope it
will be soon).  This draft isn't going to explicitly require that such a
feature be disabled, right?

Do you want to propose some text that makes this adjustment?

> Perhaps "within the span of a few seconds" would be clearer.

Fixed in git, thanks.

> preserve stream continuity but fail for the purpose of this section.

right, that's a good point.

> partitioned by the resolver's exit IP.

The section "Separate State for Each of the Recursive Resolver's Own IP
Addresses" is intended to address this concern.  If you think it's
insufficient, i'd be happy to hear suggestions for improvement!

> are seeking to bootstrap, so it's a performance cost that will be borne

well, it incurs that specific performance cost on each query above and
beyond what would have been done for a cleartext connection, without
gaining any extra defense against a passive monitor.  This seems like
something we'd like to minimize where possible.

> request timed out, as opposed to being rejected within a few milliseconds.

Maybe there should be two different damping values: a long one when
something times out, and shorter one when there is a rapid failure?

My concern is that if a quick failure (e.g. ICMP Port Unreachable)
results in a more rapid request to reestablish an encrypted session,
then we're encouraging authoritative server operators who *don't* plan
to enable encrypted transport to let attempted encrypted transports time
out, since that will reduce the number of attempts to establish an
encrypted connection.

Do you have a sense of how to tune such a distinction that wouldn't
create that incentive?

          --dkg

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 16 Dec 2021 10:37:53 -0800

> feature be disabled, right?

In my view, a correct implementation here would simply provide the TLS
stack with an IP address and no validation identity, so there is no way for
the TLS stack to retrieve an ECHConfig.  (Unless you're talking about a
client stack that deliberately provokes the fallback mechanism to retrieve
the ECHConfig in-band???)

I think it's basically already there.

...

> Do you have a sense of how to tune such a distinction that wouldn't

How about if the resolver waits for deltaT * damping /  timeout after each
failure?  Then the average delay is the same either way, but returning RST
reduces tail latency.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 17 Dec 2021 20:58:44 +0200

On Thu 2021-12-16 10:37:53 -0800, Ben Schwartz wrote:
> stack with an IP address and no validation identity, so there is no
> way for the TLS stack to retrieve an ECHConfig.

That would be a reasonable implementation, for sure.  But i don't see
why it wouldn't *also* be reasonable to supply a TLS stack with the NS
name and a flag that says not to treat authentication failure as fatal.

> (Unless you're talking about a client stack that deliberately provokes
> the fallback mechanism to retrieve the ECHConfig in-band???)

I don't know of any such stack currently, but if it exists, i wouldn't
see using it as in any way a contradiction to this unilateral probing
strategy for recursive resolvers.

> I think it's basically already there.

ok, great :)  if you have any concrete suggestions after chewing it
over, please don't hesitate to propose on the list.

> failure?  Then the average delay is the same either way, but returning RST

I'm not sure i know what deltaT means in the proposal here -- does it
mean time from the connection attempt to the observed failure?

If that's what it means, then a prompt response (RST, ICMP port
unavailable, or other immediate failure indicators) would mean a sooner
retry, right?  This seems like it still creates the negative incentive
that i was concerned about: the admin of an authoritative server that
isn't offering encrypted transport, who wants to reduce the number of
attempts it sees, might then be inclined to *disable* failure
indicators, because it would increase the delay that each unilateral
probing client takes between retries.

Am i misunderstanding your proposal?

      --dkg