Blumenthal, Uri - 0553 - MITLL writes: > Sorry, I canât accept the answer youâre giving.
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? > 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. > or youâre > certain âenoughâ (in whatever is your definition of âenoughâ) that PQ > DSA is strong/resilient âenoughâ. This criterion gives wildly different results depending on who you ask, and in any case I don't see how it's supposed to be managing the security risks under discussion. NSA, for example, claims that a PQ break would be a "breakthrough" and generally gives the impression of claiming that Dilithium has negligible risk, meaning that this criterion would say upgrade immediately---which, of course, is a disaster if Dilithium is actually breakable. In the opposite direction, organizations paying attention to SIKE and Rainbow and KyberSlash and so on would take this criterion as saying not to deploy until the attack picture has settled down. But that's failing to address the quantum threat. The sensible way forward is to go ahead with PQ as an extra layer of security on top of the existing ECC layer. Then we're _trying_ to stop quantum attacks, while at the same time not making security _worse_ in case of further PQ breaks. > To (2) â what makes you think thereâs no ECC attack that simply hasnât > been announced yet? Perhaps, your whole reliance on ECC is misplaced? See https://cr.yp.to/papers.html#safecurves for an ECC risk analysis. I have no idea how this is supposed to be an argument for switching from ECC to PQ instead of from ECC to ECC+PQ. ---D. J. Bernstein
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
