Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

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 <watsonbladd@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 <thom@thomwiggers.nl> wrote:
> >
> > Hi,
> >
> > Op 6 nov 2023, om 14:24 heeft Tim Hollebeek <tim.hollebeek=
> 40digicert.com@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.com@dmarc.ietf.org>
> > Sent: Monday, November 6, 2023 1:14 PM
> > To: Tim Hollebeek <tim.hollebeek@digicert.com>
> > Cc: John Mattsson <john.mattsson@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
>