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

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 27 Jan 2022 16:43:50 -0500

Hi folks, just a note explaining what's changed in the
unilateral-probing draft:

On Wed 2022-01-26 08:28:34 -0800, [email-masked] wrote:
> A new version of I-D, draft-dkgjsal-dprive-unilateral-probing-02.txt
> has been successfully submitted by Joey Salazar and posted to the
> IETF repository.
>
> Name:		draft-dkgjsal-dprive-unilateral-probing
> Revision:	02
> Title:		Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS
> Document date:	2022-01-26
> Group:		Individual Submission
> Pages:		24
> URL:            https://www.ietf.org/archive/id/draft-dkgjsal-dprive-unilateral-probing-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-dkgjsal-dprive-unilateral-probing/
> Html:           https://www.ietf.org/archive/id/draft-dkgjsal-dprive-unilateral-probing-02.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-02
>
> 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.

From the changelog:

--------
### Substantive changes from -01 to -02

- Clarify that deployment to a pool does not need to be strictly simultaneous
- Explain why authoritatives need to serve the same records regardless of SNI
- Defer to external, protocol-specific references for resource management
- Clarify that probed connections must not fail due to authentication failure
--------

Joey and I think this represents reasonably clear guidance that is
plausible to implement today.  It should work for both authoritative
server operators and recursive resolvers.

It does *not* solve the harder problem with signalling, but that's a
deliberate choice.  The goal here is just a non-signalled baseline.

There are a few FIXMEs left in the draft, and we'd both welcome review
and suggestions from other WG participants, implementers, operators,
etc.

        --dkg