[dns-privacy] draft-ietf-dprive-unilateral-probing support/implementation

2022-12-01 Thread Peter Thomassen
Dear WG, deSEC has been observing the development of draft-ietf-dprive-unilateral-probing, and we think that opportunistic encryption is very much worthwhile doing. Of course we hope for a long-term solution for defending against active attackers as well, but in the meantime, this is great.

Re: [dns-privacy] [Ext] Roman Danyliw's No Objection on draft-ietf-dprive-unilateral-probing-12: (with COMMENT)

2023-09-20 Thread Peter Thomassen
Paul, On 9/20/23 14:41, Paul Hoffman wrote: I also do find the value of using selfsigned certs over ACME certs on the auth server pretty low. It's pretty easy to give a nameserver with a static name an automatic ACME based certificate. With the "opportunistic" part being that if the cert fails,

[dns-privacy] Re: Verisign's RFC 9539 Experiment

2025-06-13 Thread Peter Thomassen
Hi Scott, On 6/12/25 21:36, Hollenbeck, Scott wrote: Earlier today I added text describing Verisign's RFC 9539 Experiment to GitHub: https://github.com/ietf-wg-dprive/9539-data/blob/main/Verisign's%20RFC%209539%20Experiment Interesting. Are you also conducting / planning to conduct DoQ exper

[dns-privacy] Re: [DNSOP] Re: Proposal for opportunistic transport signaling from authoritative servers

2025-07-08 Thread Peter Thomassen
On 6/24/25 21:37, Ben Schwartz wrote: 1. An attacker could strip the SVCB record and its RRSIG, resulting in an ordinary delegation response that would be accepted and used without encryption. While that is true, the same attacker can also prevent RFC9539-style opportunistic probing, by blo