<div dir="ltr"><div dir="ltr">On Tue, Dec 17, 2024 at 3:55 PM Joe Abley <<a href="mailto:jabley@strandkip.nl">jabley@strandkip.nl</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><br></div><div dir="ltr">I agree that it is very possible to roll algorithms safely, without going insecure, and that this has been demonstrated successfully many times. However, going insecure is also a perfectly valid way to do an algorithm change, as far as DNSSEC is concerned. </div></div></blockquote><div><br></div><div>Love you Joe, but I have to quibble with this stance a bit. In my view, going insecure seems valid only because there is a prevailing perception that nothing critically depends on DNSSEC (your observation of DANE notwithstanding). That's something I hope will change in the future (both the perception and the reality). The parties involved in the recent GOV TLD provider+algorithm transition went to great pains to ensure that they did not go insecure. I hope that other TLDs will follow suit.</div><div><br></div><div>My more detailed arguments against going insecure can be found in this short presentation:</div><div><br></div><div>    <a href="https://static.sched.com/hosted_files/icann79/4b/2.4%20Huque%20-%20DoNotGoInsecure-v3.pdf">https://static.sched.com/hosted_files/icann79/4b/2.4%20Huque%20-%20DoNotGoInsecure-v3.pdf</a></div><div><br></div><div>Shumon.</div><div><br></div><div><br></div></div></div>