[dns-privacy] review of dprive-unilateral-probing

[Alexander Mayrhofer <[e-mail]>]

Hello dkg, all,

as requested by the WG chairs, I've reviewed draft-ietf-dprive-unilateral-probing. Here are my comments:


- I think the "DNS camel" comment in the introduction would be hard to understand for any uninitiated person. While it fits the text perfectly now, I think it should be reworded (or a reference should be added) once we move towards publication.
- In minimizing negative impacts, the third bullet should probable be "the potential for amplification attacks.. ", and the second "excessive use of computational..." (NIT). I think many implementors are concerned about excessive requirements to keep state, but I guess that's covered by the mem/CPU bullet, even on intermediaries (Firewalls, etc.)
- I agree to the prococol choices considerations. Towards publication, we should shorten the paragraph about the DoH path problem.
- As noted in the WG discussion, the X.509 certificate with common names of all the names an authoritative server is known under could be problematic, because customers are usually "creating" their own nameserver names without necessarily informing the op of the nameserver. Side note - this might be an interesting research topic - to look at the names requested in SNI to the DoT port of such servers ... (once we have deployment!)
- I guess implementors have more to say about the client-side probing strategy proposed, but it does look very reasonable to me. Maybe we can get feedback from early implementations on optimizing the resource-use of state information required.
- The ALPNs under section 4.2 should be quoted.
- The description of the connection state (4.3, first section, and the state mangling in 4.5.*) is very close to implementation specifications - do we really need that great detail for the protocol to be interopable? Given the connection to the requirements in 4.5.1, I do admit it's tricky. Maybe we should move that to an Appendix? Section 4.3.1, though, is more like an abstract requirement, and should be kept in. Maybe re-order? I agree on the 4.4. "per IP address" recommendation. It might even be worse for v4/v6 deployments.
- in 4.5.3, regarding the FIXME, I think the client SHOULD keep using the existing connection for the non-preferred transport, but MAY re-probe for the preferred transport, and upgrade to that if probing succeeds - (maybe pretty complicated to implement, though?)
- All the "identifier" strings in the draft should be quoted. (such as "early", "unsent", etc..) - maybe personal preference, but I find it clearer. Latest, the RFC editors will comment on that anyways.
- For the Padding - as with DoQ I would recommend that the server SHOULD use padding according to RFC 7830, and may (lowercase) use the experimental policies set in RFC 8467. However, the individual transports may override this - DoQ eg. recommends QUIC-based padding over EDNS level padding.

To sum it up - my comments are minor tweaks. It's a structurally good protocol and draft, thanks for the work!

Best,
Alex