Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt

From: Sara Dickinson <[email-masked]>
Date: Thu, 7 Apr 2022 16:47:02 +0100

Hi All, 

As promised some time ago, here is my review of the current probing draft. I think the draft is in good shape and have the following general comments.

1) The DNS-over-QUIC draft has now passed IESG last call so one question is whether the document should be updated to treat DoT and DoQ equally (or even just reference DoQ)? Deployment of DoQ is still in the very early stages but the WG may want to consider this change now or in the near future.

2) I wonder if some sort of diagram would go a long way to conveying the basic guidance proposed here (and enable simplifying some of the detailed text)? It seems this could actually be 2 diagrams - there is one set of logic that applies to selecting the transport to use, and a second set of processing logic when receiving responses (based on what transport gets the response and what else is queued)?  I’ll share my hacky attempts at this off-list with the authors to see if they think they it adds any value but it might allow readers to quickly grasp the overall guidance and also lead to more consistent implementation? 

3) The issue of signalling… I agree there is still work to do to mange this. From this reading:
- from a client perspective the concept of unilateral probing is pretty clear. There is a defined behavior for direct probing, which will be different from the behavior if 'external coordination' is available. 
- however servers can't know for sure how the client discovered them or how/if they are authenticating the connection. This document doesn't prescribe a way to know that a server is 'only' doing unilateral deployment and/or something else, hence the potential future issues with signalling.
- given this draft is Informational and is designed to enable experiments I can't remember if there has already been discussion of using an 'alternative' ALPN for this initial deployment? By that I mean, use something like 'doq-p01’(DoQ probing 01) for these kind on connections (in the same way I-D tagged ALPNs are used during protocol development)? That way each side knows explicitly how to behave and statements like "An authoritative DNS server that wants to handle unilateral queries' would have clear meaning. Whilst this is taking liberties with ALPN and may have already been dismissed as an option, it does solve a number of problems in the short term and enable negotiation and evolution. Just asking :-) 

4) Would it be worth adding an additional section or appendix trying to model the likelihood of queries being encrypted for a given parameter choice vs authoritative server query interval? Assuming successful connections, it seems that for servers queried infrequently (interval is longer than the ‘persistence' parameter) their initial queries after this period will be cleartext so the choice of that parameter compared to the average query interval is quite key and likely to be the main parameter tuned? This might allow the fixed numbers given in 4.1 to be replaced by numbers relative to the average query internal for a given auth (and the resolvers desired level of encrypted connections/re-probing actions).

Minor comments:

Section 1.2:  Have you considered using a shorthand like DoE (DNS-over-Encrypted-transport) instead of 'encrypted transport'? I think it might make the text read more clearly.

Section 3.2: If discussion of possible auth mechanisms remains, then in the second bullet point referencing DANE I presume the text in parenthesis is indicating use of the DNSSEC Chain extension? If so then a reference should probably be added.

Section 4.3 (and 4.5.1) Clients may also want to also track support for 0-RTT data as with DoQ servers may return a 'Too early' EDE code if they choose not to support it.

Section 4.3: There might also be cases where the handshake succeeds but where every request on the connection times out. It might be worth adding additional state relating to that or changing 'completed' to be a successful connection attempt (handshake) followed by a query that didn't timeout. In Stubby we backoff off from servers where the number of timeouts on recent connections exceeds a certain threshold even when the handshakes succeed.

Section 4.5: "The recursive resolver must know to decide whether to initially send a query over Do53, or over any of the supported encrypted transports (DoT or DoQ)." Reads a bit strangely to me. Can this text be clarified a little? "should use the following guidance as a basis for deciding whether to"

Section 4.5.1: I believe 'T -E-completed' is the lifetime of the connection, not the idle time? If so, this is probably worth spelling out as other mechanisms e.g. edns0-tcp-keepalive are based around idle times. This is linked to the 'persistence' parameter which might be better renamed to something like e.g. ‘reuse-interval'? I'm more familiar with thinking of persistence in this context as re-using single connections for multiple queries (RFC7766) as opposed to remembering a successfully probed capability.

4.5.8.3 - As written it only applies to DoT (DoQ uses 0 for all MessageIDs). Perhaps just reference RFC7766 and the DoQ draft here?

Nits:

Section 4.1 s/authoritative resolver/authoritative server/

Section 4.5 s/whether the IP address X is capable of corresponding on the relevant transport/whether the IP address X is capable of communicating on the relevant transport/

Section 4.5.1. uses T, but only T0 is defined prior to that.

Section 4.5.3: s/If any E-session[X] is in the established,/If any E-session[X] is in the established state,/

Section 4.5.8:  s/should consider the following guidance:/should consider the guidance in the following sections./

Sections 4.5.2 and 4.5.9 are describing very similar things but do not use consistent language or ordering. Perhaps they can be aligned better? 

Regards

Sara. 

> On 7 Mar 2022, at 17:54, [email-masked] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the DNS PRIVate Exchange WG of the IETF.
> 
>        Title           : Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS
>        Authors         : Daniel Kahn Gillmor
>                          Joey Salazar
> 	Filename        : draft-ietf-dprive-unilateral-probing-00.txt
> 	Pages           : 23
> 	Date            : 2022-03-07
> 
> 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 datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-unilateral-probing/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dprive-unilateral-probing-00.html
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 10 Apr 2022 09:08:39 -0700

Hi Sara--

Thanks for this thoughtful and detailed review!  I'm trying to do it
justice, but i haven't gotten through it all yet.  It's triggered a
bunch of changes in the editor's copy, but I've also focused on the easy
stuff first because i'm lazy :P

If anyone wants to offer concrete suggestions for textual changes for
the parts i haven't yet addressed, i'd welcome those suggestions!

Notes below, inline, for things that i haven't tackled yet:

On Thu 2022-04-07 16:47:02 +0100, Sara Dickinson wrote:
> 2) I wonder if some sort of diagram would go a long way to conveying
> the basic guidance proposed here (and enable simplifying some of the
> detailed text)?

This is a great idea.

Thanks for sharing your flowchart sketch, Sara!  I think a flowchart
typically represents a branching-yet-linear workflow, where the choice
points and observations are all initiated by the primary actor.

In this case, we have a lot of events that can happen asynchronously
from outside the primary actor, so a flowchart kind of struggles to
represent it.

i've spent the last day puzzling this over, and of the ideas i've
stumbled onto, the one i like the most is a state transition diagram for
a single <client IP, server IP> tuple given one encrypted transport and
Do53.

It'd be more accurate to cover state of *both* encrypted transports for
the <client IP, server IP> tuple (that is, to observe the subtle
interactions between multiple encrypted transports and Do53), but that
diagram seems like it might be more complicated and less clarifying.

Any suggestions for a better kind of visualization?

I've opened https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/20
to track this.

> - from a client perspective the concept of unilateral probing is
> pretty clear. There is a defined behavior for direct probing, which
> will be different from the behavior if 'external coordination' is
> available.
>
> - however servers can't know for sure how the client discovered them
> or how/if they are authenticating the connection. This document
> doesn't prescribe a way to know that a server is 'only' doing
> unilateral deployment and/or something else, hence the potential
> future issues with signalling.
>
> - given this draft is Informational and is designed to enable
> experiments I can't remember if there has already been discussion of
> using an 'alternative' ALPN for this initial deployment? By that I
> mean, use something like 'doq-p01’(DoQ probing 01) for these kind on
> connections (in the same way I-D tagged ALPNs are used during protocol
> development)? That way each side knows explicitly how to behave and
> statements like "An authoritative DNS server that wants to handle
> unilateral queries' would have clear meaning. Whilst this is taking
> liberties with ALPN and may have already been dismissed as an option,
> it does solve a number of problems in the short term and enable
> negotiation and evolution. Just asking :-)

This is an interesting question: the proposal to play games with ALPN
hasn't yet been raised to my knowledge.

Due to ALPN's transport in the clear for a normal TLS handshake, i'd be
reluctant to endorse that use here.  I don't think we want a network
observer to know which encrypted transports are opportunistic and which
are due to signalled information.

I'm also trying to get my head around what such an indicator would be
useful for.  Presumably the authoritative server would behave
differently based on that indicator, but i'm having a hard time
imagining what the authoritative server should do differently.  Is it
just for statistics/accounting?  Can you explain what you think the
purpose of such an indicator would be?

As a related side note, in the editor's copy i've touched briefly on the
"reporting" aspects that would be useful for an operator deciding
whether to signal:

   https://dkg.gitlab.io/dprive-unilateral-probing/#name-signalling-mechanism-proper

Maybe the need for such an indicator would depend on the semantics and
syntax of the signal that is ultimately selected?  if so, perhaps that
additional indicator belongs in whatever future signalling work we do,
rather than in this document

> 4) Would it be worth adding an additional section or appendix trying
> to model the likelihood of queries being encrypted for a given
> parameter choice vs authoritative server query interval? Assuming
> successful connections, it seems that for servers queried infrequently
> (interval is longer than the ‘persistence' parameter) their initial
> queries after this period will be cleartext so the choice of that
> parameter compared to the average query interval is quite key and
> likely to be the main parameter tuned? This might allow the fixed
> numbers given in 4.1 to be replaced by numbers relative to the average
> query internal for a given auth (and the resolvers desired level of
> encrypted connections/re-probing actions).

I welcome proposed text for an appendix like this.  Some things that
such a section would probably want to cover:

- specific statistics that an implementation might want to aggregate for
  reporting

- strategies for prefetching/etc that would increase the percentage of
  opportunistically-encrypted traffic

I've opened https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/21
to track this.

> Section 1.2: Have you considered using a shorthand like DoE
> (DNS-over-Encrypted-transport) instead of 'encrypted transport'? I
> think it might make the text read more clearly.

I think this would make it sound like "DoE" is a specific protocol.  And
it makes it harder to talk about "one of the encrypted transports" or "a
different encrypted transport" ("one of the DoEs" or "a different DoE"
both seem weird to me).

I don't personally mind "encrypted transport" much, but i'm open to
suggestions for other terms for describing the concept without .

> Section 4.3 (and 4.5.1) Clients may also want to also track support
> for 0-RTT data as with DoQ servers may return a 'Too early' EDE code
> if they choose not to support it.
>
> Section 4.3: There might also be cases where the handshake succeeds
> but where every request on the connection times out. It might be worth
> adding additional state relating to that or changing 'completed' to be
> a successful connection attempt (handshake) followed by a query that
> didn't timeout. In Stubby we backoff off from servers where the number
> of timeouts on recent connections exceeds a certain threshold even
> when the handshakes succeed.

These are really useful suggestions that i haven't dealt with yet.  I've
noted them as:

  https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/18

> Section 4.5.1: I believe 'T -E-completed' is the lifetime of the
> connection, not the idle time? If so, this is probably worth spelling
> out as other mechanisms e.g. edns0-tcp-keepalive are based around idle
> times. This is linked to the 'persistence' parameter which might be
> better renamed to something like e.g. ‘reuse-interval'? I'm more
> familiar with thinking of persistence in this context as re-using
> single connections for multiple queries (RFC7766) as opposed to
> remembering a successfully probed capability.

I don't think the described measurement is the connection lifetime: if
the connection is still in the established state, then we don't even
look at that metric. But if the connection was closed cleanly by either
side, we're measuring back to the start of the connection, rather than
the last time the connection was successfully initiated, rather than the
last time it was successfully used.

I think the right way to fix this is to try to record the last
successful use.  Maybe we should change the definition of `E-completed`
to be last successful use, and tweak "Receiving a response over
encrypted transport" to update it.

I've recorded this as an outstanding concern at:

https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/19

> Sections 4.5.2 and 4.5.9 are describing very similar things but do not
> use consistent language or ordering. Perhaps they can be aligned
> better?

I haven't gotten to this, but i noted it as:

https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/17

Thanks again for the review, this is really useful!

       --dkg

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 10 Apr 2022 19:23:21 +0300

> purpose of such an indicator would be?

Perhaps there could be separate ALPNs for recursive and authoritative
DNS service, with no distinction if authoritative service is
opportunistic or not?

-Ilari

---

From: Christian Huitema <[email-masked]>
Date: Sun, 10 Apr 2022 11:57:40 -0700

On 4/10/2022 9:08 AM, Daniel Kahn Gillmor wrote:

>> negotiation and evolution. Just asking:-)

I am not convinced that clients doing unilateral probing should signal 
it. After all, the goal of unilateral probing is to "just use 
encryption" without requiring specific signaling. Plus, in general, 
servers do not know why a specific request is sent to them, which 
specific NS record was accessed, whether a CNAME was involved, etc. Like 
DKG, I would be very reluctant to change the wire image and have visible 
differences between opportunistic and regular connections. This would 
invite differentiated treatment in routers and firewalls, which breaks 
the whole point of opportunistic discovery. But Sara has a point, we 
should give servers a way to control the deployment.

Servers could very well be flooded with queries just after starting to 
test DoT and DoQ. We should address that by changing the server 
responses, not the client queries. For example, we might want to define 
an extended DNS error message rejecting a query because the capacity to 
process encrypted requests is exceeded. And we might want to specify 
that clients receiving such messages should stop unilateral attempts to 
use that server for a while. DoT or DoQ servers could use that to 
progressively enable the service for a fraction of their clients, maybe 
using some kind of filter based on the client's IP.

-- Christian Huitema

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 10 Apr 2022 14:19:03 -0700

> DNS service, with no distinction if authoritative service is

What would be the advantage of that distinction?  would it be
actionable by either party in a communication?

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 10 Apr 2022 15:00:03 -0700

On Sun 2022-04-10 11:57:40 -0700, Christian Huitema wrote:
> But Sara has a point, we should give servers a way to control the
> deployment.

Authoritative servers do have a way to control deployment: they can
simply refuse connections on encrypted transport.

Rather than refusing arbitrary connections haphazardly on the basis of
time of arrival (or some other unrelated feature), though, maybe we
should offer guidance on how to selectively refuse connections on the
basis of the client IP address (to avoid state-flapping on the recursive
resolver side).

I've noted this as
https://gitlab.com/dkg/dprive-unilateral-probing/-/issues/22

> using some kind of filter based on the client's IP.

I'd be game to use this document to define such an extended error
message, but i don't understand how its semantics would differ from
merely rejecting the connection attempt with an ICMP Port Unreachable
message (which non-implementing authoritative servers will send anyway).

In a strongly-authenticated protocol, the difference between an extended
DNS error code and ICMP Port Unreachable would be that the client could
rely on the authenticity of the DNS error code (ICMP Port Unreachable is
of course always spoofable by the network path).  But in this
opportunistic deployment, both signals are spoofable.

Maybe the concern is that the authoritative server implementation might
not have control over the full stack enough to respond ICMP Port
Unreachable to a specific subset of client IP addresses.

In that case, i can imagine two distinct modes of operation:

- the server only has the opportunity to respond after the TLS/QUIC
  handshake is complete.  In this case, i don't see why the server
  shouldn't just go ahead and handle the query; some part of the stack
  has already borne the connection setup costs.

- the server can respond early during the TLS/QUIC handshake.  In this
  case, we'd want to define an error at that layer, so that the
  authoritative server can signal failure without incurring any
  additional connection costs.

Does this analysis seem right to you?  Or is there a reason that i'm
missing that an authoritative server would want to have the signal at
the layer where a extended DNS error message would make sense?

     --dkg

---

From: Christian Huitema <[email-masked]>
Date: Mon, 11 Apr 2022 15:21:26 -0700

> Unreachable to a specific subset of client IP addresses.
Yes. Something done by the application is much easier than messing with 
ICMP.
>    has already borne the connection setup costs.
True. But this is easy to spoof.
>    additional connection costs.
That could work. It would be similar to "ALPN negotiation failed". But I 
am not sure that's easy to implement, giving different TLS answers to 
different clients. It is essentially a layer violation. Architecture 
considerations aside, that requires a pretty tight coupling between TLS 
and Application implementation. Not always possible. Also, not 
authenticated. The bad guys recipe book is going to say, "spoof this 
message if you want to force a client to stop unilateral probing for 24 
hours."
> the layer where a extended DNS error message would make sense?

I like it because it can be entirely done at the DNS layer. The message 
is authenticated by TLS, which does cost the server some cycles but 
protects the client against spoofs.

-- Christian Huitema

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 11 Apr 2022 18:39:04 -0700

Hi Christian--

> True. But this is easy to spoof.

right, but it's even easier to spoof an ICMP Port Unreachable, which
will undoubtably have the same effect on an opportunistic recursive
resolver.

> message if you want to force a client to stop unilateral probing for 24 

I really don't think "not authenticated" or "spoofable" is a valid
objection in this particular use case, but i hear you about the
difficulties for an implementation based on different layers of the
stack that are typically accessible to the DNS server implementer.

I'm just wondering what the motivation is for the authoritative server
to emit this response if it can *only* be done at the DNS layer.  Aren't
all the resources you're worried about already being consumed at that
point?

If we define semantics for some future signalled protocol that depends
on proper authentication, and those semantics could tell the recursive
resolver to limit itself somehow (and for some particular reason?), then
that'd definitely be interesting.  But any response from the server that
requires the server to be properly authenticated doesn't seem like it
belongs in this draft, regardless of its semantics.

I'd be happy to include a definition/declaration of a "please back off"
response at the DNS layer into this draft, if we can be clear about:

 - What specifically is the server expecting the client to do -- does it
   differ from the client's response to, for example, an ICMP Port
   Unreachable message?  (no difference is fine, but we should be clear)

   In particular, i'd be reluctant to imply or encourage that such a
   signal would cause the recursive resolver to back off even more
   strongly than it would back off if it received any other error,
   includng ICMP Port Unreachable, a TLS handshake negotiation failure,
   etc.  Given that this signal is guaranteed to be just as spoofable as
   these other network-inflicted failure modes, it would be unfortunate
   if an interfering network attacker could cause *more* cleartext to
   flow over time just because of the layer at which the response
   appeared.

 - What does the authoritative server gain from such a response?  When
   should a reasonable authoritative server deploy this response?

Would you be up for taking a crack at suggesting some text?

Thanks for talking this over!

       --dkg