I’m fine if the cocktail napkin says “we’ll either do A or B, we’re still figuring that out”.
What I’m trying to avoid is the situation where everyone has a different notional quantum-safe TLS design in their heads, but nobody realizes it because nobody has bothered to try to write down the details, even at a very high level. If it changes in the future due to new events or analysis, that’s ok too. -Tim From: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org> Sent: Monday, November 6, 2023 1:14 PM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: John Mattsson <john.matts...@ericsson.com>; TLS@ietf.org Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms? (3)-(5) are exactly the hard problems I’ve been thinking a lot about lately. I’d actually be tempted to say that AuthKEM vs signatures is something we should figure out ASAP. I read AuthKEM again this morning, and it has a lot of attractive features, but I’m not quite sure what the right answer is yet. I don't think we can settle the future of PQ authentication in TLS just yet — there are still many unknowns. To name a few: 1. What signature schemes are on the horizon? MAYO [1] from the NIST signatures on-ramp would be great, if it doesn't turn out to be broken. 2. How will the confidence in existing schemes develop? AuthKEM will look different depending on whether it can use Kyber-512 or Kyber-1024. Also, will it replace Dilithium5 or Dilithium2? 3. What other higher level changes is the ecosystem able to adopt? For instance Merkle Tree Certs [2]. These are all hard questions, and although I do not believe we can answer them now, we should be thinking about them right now. I think we should have different pots on the fire, so to say. Best, Bas [1] https://pqmayo.org/params-times/ [2] https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
