I'm most interested in Level I which I think is what the current browser deployments have targeted. Higher security levels are much less relevant at least for now, and I think the platforms will likely look different.
I think ML-KEM-768 codepoint and a hybrid one make sense to grab now: AFAIK it's easy to do. Happy to contribute to drafts, but I think we have some floating around. KEMTLS is a great idea, but I think for now we can make do without: it's ok for the PKI to evolve slower. On Mon, Nov 6, 2023 at 5:32 AM Thom Wiggers <t...@thomwiggers.nl> wrote: > > Hi, > > Op 6 nov 2023, om 14:24 heeft Tim Hollebeek > <tim.hollebeek=40digicert....@dmarc.ietf.org> het volgende geschreven: > > I’m fine if the cocktail napkin says “we’ll either do A or B, we’re still > figuring that out”. > > > I’m not sure if we will be able to say this as strictly as “A xor B”, we > might need to do A and B in different environments. CNSA 2.0’s requirement of > level-V parameters results in very different behaviour than what we see at > NIST level I, for example. The platforms on which we deploy things are also > subject to wildly varying constraints. > > Cheers, > > Thom > > > > > > 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/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
