On Mon, 25 Nov 2024 at 06:55, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote:
> > To clarify, are you continuing to claim that there's "no damage possible > > (at least, in the TLS context) caused by PQ DSA break", despite the > > facts that (1) upgrades often take a long time and (2) attackers aren't > > going to announce their secret attacks? > > For (1) I call it not an “upgrade” (i.e., to something new and often > untested yet), but a “downgrade” – reverting to the “old mature and > well-tested ECC code”. Shouldn’t take long at all. > > For (2) – why do you assume there are no secret attacks against ECC? > Merely because you couldn’t find one, and nobody announced it yet? > > > >> then don’t move to PQ DSA until either CRQC is announced > > > > That would be too late. It completely fails to address the large risk of > > quantum attacks happening before the first public attack demos, plus it > > leaves users vulnerable during the upgrade period. > > You don’t really need PQ DSA until CRQC is here. At this point, everybody > seems to agree that there is time before CRQC arrives. So, keep > studying/exploring/attacking PQ DSA, and prepare code and infrastructure to > deploy it – but use ECC for now. It will also > The deployment timeline for new algorithms and standards is lengthy. For instance, once an IETF specification is standardized, it typically takes around 1.5 years for 3GPP to incorporate it into their release cycle. After that, product teams require several months for development and testing. Additionally, operators often adopt these updates gradually, which extends the timeline further. Moreover, it may not always be feasible to easily tweak configurations to enable/disable algorithms dynamically when CRQCs become publicly known. We would like to also consider the potential impact of zero-day vulnerabilities, where exploits are discovered and used before vulnerabilities are publicly disclosed. Proactive preparation and deployment of hybrid signature schemes reduces the risk of being caught unprepared in such deployments. -Tiru > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
