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

[Christian Huitema <[e-mail]>]

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

>> - 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?

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