On Sun, 13 Feb 2022, IETF Secretariat wrote:
The DPRIVE WG has placed draft-dkgjsal-dprive-unilateral-probing in state
Call For Adoption By WG Issued (entered by Tim Wicinski)
The document is available at
https://datatracker.ietf.org/doc/draft-dkgjsal-dprive-unilateral-probing/
I'm in favour of adoption, but I do feel that perhaps the document could
be shorter and clearer by leaving out some implementation details that I
think are likely not to be implemented by existing implementations that
already have their caching strategy of various name server properties
(eg remembering EDNS options). For example, the timing information seems
a bit arbitrary and unlikely to be blindly followed. Where as the "don't
fail if certificate does not verify" _is_ very useful and not
immediately obvious advise.
some comments from a quick read follows,
Paul
I think section 2.1 should have a bullet point of latency and perhaps a
section about design choices vs latency.
s/the pool operator SHOULD either:/the pool operator SHOULD at least
support one of:/
[but still weird because the 2nd bullet point is kind of mandatory for TCP]
Section 3.2: if selfsigned, why "regularly updated" ?
Based on today's ease of ACME, I still see no real need for self-signed at all.
3.3 I think is about cnames/multi A/AAAA records of a single IP address?
Could be clarified.
I think section 3.4 has some controversial advise. Also what is
"unanticipated resource exhaustion". IS there "anticipated resource exhaustion"
?
I'm interested in the motivation behind the values in section 4.1
4.3 talks about a "stack of resumption tickets". Why would there be more
than one? If doing more that one, should something be said about
resource exhaustion? What about lifetime of tickets vs section 4.1 values?
A timeout (accidental delay) is most likely to happen when the
recursive client believes that the authoritative server offers
encrypted transport, but the actual server reached declines encrypted
transport (or worse, filters the incoming traffic and does not even
respond with an ICMP port closed message).
Should such an ICMP message be believed? That's a very easy downgrade
path for an attacker, even for opportunistic. More robust would be to
ignore the ICMP and wait for a possible real reply.
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
