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 protected]> wrote:
> 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 protected]>
> 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 protected]>, Joey Salazar <
> [email protected]>
>
>
>
> 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
>
>
> _______________________________________________
> dns-privacy mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
