Hi folks, just a note explaining what's changed in the unilateral-probing draft:
On Wed 2022-01-26 08:28:34 -0800, [email protected] 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
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
