https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-03 defines the `X25519Kyber768Draft00` `NamedGroup` as 0x6399 https://datatracker.ietf.org/doc/html/draft-kwiatkowski-tls-ecdhe-kyber-01 defines the `SecP256r1Kyber768Draft00` `NamedGroup` as 0x639A
On Mon, Nov 6, 2023 at 11:42 AM Watson Ladd <watsonbl...@gmail.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
