On Fri, Nov 1, 2024 at 11:30 AM John Mattsson wrote:
> >and would warmly welcome it being a MUST in the IETF specification of
> the ML-KEM TLS hybrids.
>
>
> +1
>
> Let’s try to make that happen
>
> https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/25
>
Is reus
Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but of
course it's not a group, it's a KEM scheme over which no Diffie-Hellman of any
kind can be done. Where do IANA preallocations start bumping up against "well
we're doing something completely different anyway"?
Your co-c
>and would warmly welcome it being a MUST in the IETF specification of the
ML-KEM TLS hybrids.
+1
Let’s try to make that happen
https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/25
___
TLS mailing list -- tls@ietf.org
On Fri, Nov 1, 2024 at 2:02 PM Alicja Kario wrote:
> On Friday, 1 November 2024 18:02:44 CET, David Benjamin wrote:
> >> Tangentially, this is registering a `NamedGroup` /
> >> `SupportedGroup`, but of course it's not a group, it's a KEM
> >> scheme over which no Diffie-Hellman of any kind can b
On Friday, 1 November 2024 18:02:44 CET, David Benjamin wrote:
Tangentially, this is registering a `NamedGroup` /
`SupportedGroup`, but of course it's not a group, it's a KEM
scheme over which no Diffie-Hellman of any kind can be done.
Where do IANA preallocations start bumping up against "wel
We (Go) also generate fresh keys for each handshake and would warmly welcome it
being a MUST in the IETF specification of the ML-KEM TLS hybrids.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
> The FFDH range isn't treated special because of naming but because of
some mistakes that RFC 7919 made where the implementation actually needs to
categorize codepoints.
Gotcha, cheers.
I'm definitely not advocating another name change, it's not worth it
On Fri, Nov 1, 2024, 1:03 PM David Benja
> Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but
of course it's not a group, it's a KEM scheme over which no Diffie-Hellman
of any kind can be done. Where do IANA preallocations start bumping up
against "well we're doing something completely different anyway"?
The decidin
If there's a choice to be made I favor the 512 513 514 choices
On Fri, Nov 1, 2024, 12:20 PM Deirdre Connolly
wrote:
> Ah, oops!
>
> Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but
> of course it's not a group, it's a KEM scheme over which no Diffie-Hellman
> of any kind
Ah, oops!
Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but of
course it's not a group, it's a KEM scheme over which no Diffie-Hellman of
any kind can be done. Where do IANA preallocations start bumping up against
"well we're doing something completely different anyway"?
O
I made a mistake and you're right " 261, 262, and 263 are assigne to the
MLKEM512, MLKEM768, and MLKEM1024" wrong.
We'll notify IANA to pick 512 513 514 or 4584 4585 4586. Or something.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email
Hi,
While I'm a bit surprised about the existence of the
draft-connolly-tls-mlkem-key-agreement-03[1] draft in the first place,
the primarily reason I'm writing is because of the values in
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
specifically:
261, 262
We are not planning on re-using MLKEM or Khyber keys for the key exchange.
Someone here is being obstinate, and I am looking for arguments to squelch him.
:)
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
On Fri, 1 Nov 2024 at 11:50, Bas Westerbaan wrote:
> Here we're not accounting for the new bottleneck on server upload which
> these post-quantum signatures add. But that's a bandwidth issue — not a
> compute one.
>
On top of that, the HRR/ClientHello Cookie extension already in TLS1.3 can
also
Bas Westerbaan wrote:
>BoringSSL (Chrome) generates a new keypair for each connection. We do
>too. ML-KEM keygen is quite cheap anyway.
That is great to hear! 👍
Hopefully most implementations follow this. Reusing ephemeral keys are bad for
several reasons. It relates the key material in differen
BoringSSL (Chrome) generates a new keypair for each connection. We do too.
ML-KEM keygen is quite cheap anyway.
On Fri, Nov 1, 2024 at 1:11 PM Salz, Rich
wrote:
> Are folks generating a new key every connection or just using a
> longer-lived keypair and not re-using the random?
> ___
Are folks generating a new key every connection or just using a longer-lived
keypair and not re-using the random?
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
This is a bit of a tangent, but PQC seems to have the opposite effect of
what you might think if you use fast implementations.
A typical ClientHello with X25519 is, say, about 350 bytes. A modern Intel
core can do about 20,000 X25519 keyshare and P-256 sign together per
second. That's 56 Mbit/s. T
I fully agree.
In addition to that wide enough adoption of any mandatory changes to TLS
handshake will take years and any public facing services will have to allow
clients that do not support puzzles for backwards compatibility for quite
some time.
On top of low-powered battery operated clients t
I would like to see more discussion and work on DoS protection. I think many
services are quite unprepared for massive DDoS attacks. Si vis pacem, para
bellum.
>so burning CPU on a hash puzzle in those contexts is unappealing
My understanding is that the server would only use the puzzle when it
20 matches
Mail list logo
