+last-call On Mon, Jan 20, 2020 at 2:37 PM Eric Rescorla <[email protected]> wrote:
> Review comments attached: > > > COMMENTS > S 3.1. > > described above, and may not have any confidentiality requirements.. > > However, the same is not true of a single transaction or a sequence > > of transactions; that transaction is not / should not be public. A > > typical example from outside the DNS world is: the web site of > > Alcoholics Anonymous is public; the fact that you visit it should > not > > be. > > Well, technically what you want to conceal is the origin of the > transaction or its linkage to other transactions. The existence of the > query for that A record isn't secret. > > > > > > S 3.4.2. > > fingerprint [2] values can be used to fingerprint client OS's or > that > > various techniques can be used to de-NAT DNS queries dns-de-nat [3]. > > > > Note that even when using encrypted transports the use of clear text > > transport options to decrease latency can provide correlation of a > > users' connections e.g. using TCP Fast Open [RFC7413] with TLS 1.2. > > Why does this say TLS 1.2? Any use of TFO will have the same > properties. > > Perhaps you are thinking of TLS session tickets here? > > > > > S 3.4.2. > > services available. Given this, the choice of a user to configure a > > single resolver (or a fixed set of resolvers) and an encrypted > > transport to use in all network environments can actually serve to > > identify the user as one that desires privacy and can provide an > > added mechanism to track them as they move across network > > environments. > > I don't understand this paragraph. It's not the choice of specific > resolvers that leaks data, but the choice to turn on encryption, In > fact, from an identification purpose, the more resolvers that support > encrypted transport, the better signal this is. > > > S 3.4.2. > > identify the user as one that desires privacy and can provide an > > added mechanism to track them as they move across network > > environments. > > > > Implementations that support encrypted transports also commonly re- > > use sessions for multiple DNS queries to optimize performance (e.g.. > > Note: session is a technical term in TLS that refers to the > association not the connection. I would say "connection" > > > S 3.5.1.1.2. > > > > o communicate clearly the change in default to users > > > > o provide configuration options to change the default > > > > o provide configuration options to always use the system resolver > > I get that you think this is neutral, but all of this is equally true > about dynamic discovery via DHCP, it's just that that's the status > quo, so you don't notice it. In this context, this text is tendentious. > > > S 3.5.1.1.2. > > > > Application-specific changes to default destinations for users' DNS > > queries might increase or decrease user privacy - it is highly > > dependent on the network context and the application-specific > > default. This is an area of active debate and the IETF is working > on > > a number of issues related to application-specific DNS settings. > > This, too, could be said about the current situation. > > On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) <[email protected]> > wrote: > >> Thanks to Sara and Stéphane for the -04 revised I-D. >> >> After reading the -04, I think that most of the IETF Last Call comments >> are addressed (and consensus needs to be balanced -- even for informational >> document) and that the document sticks to facts. >> >> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of >> discussions during the first IETF Last Call, and as the authors reacted to >> those comments by deep changes in the text, let's have a new IETF Last Call >> before proceeding with IESG evaluation. >> >> Again, thank you to the reviewers and the authors >> >> Regards, >> >> -éric >> >> >> On 20/01/2020, 22:34, "IETF Secretariat" < >> [email protected]> wrote: >> >> IESG state changed: >> >> New State: Last Call Requested >> >> (The previous state was Waiting for AD Go-Ahead::AD Followup) >> >> The previous last call raised several points. The authors have worked >> on those points and this new informational IETF draft has substantive >> changes; enough to go trigger a new IETF Last Call. >> >> -éric >> >> Datatracker URL: >> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/ >> >> >> >> _______________________________________________ >> 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
