I do not support ML-KEM only.
On Mon, 11 Nov 2024 at 22:03, Deirdre Connolly wrote:
>
> OK; what about ML-KEM only?
>
> On Mon, Nov 11, 2024, 9:58 AM Bas Westerbaan wrote:
>>
>> That was before the release of FIPS 203.
>>
>> On Mon, 11 Nov 2024 at 18:29, Deirdre Connolly
>> wrote:
>>>
>>> Tw
I support adoption. The question of explicitly prohibiting key share reuse is
orthogonal; this can be done in a separate document.
* If someone want to do reuse, I think that should be visible…
Ephemeral key reuse by the server is already visible by observing server key
shares across connec
Hi,
I expressed my view before this thread
https://mailarchive.ietf.org/arch/msg/tls/tx0fEKDEWDYuLJlmQC8elAjW5YM/
- Note that RECOMMENDED=Y requires IETF Standards Action. I don't think any new
"Supported Groups" that allows an ephemeral key to be reused in more than one
key-establishment in v
Respectfully disagree with Alicja. There is no need to steer people towards
hybrids.
For example, we don’t need hybrids (based on our understanding of
cryptography/math and the quality of our crystal balls ;) and don’t intend to
employ them. Others may prefer hybrids, and it’s fine with me. ;-
I'd vote for "N": I worry about the security of implementations.
And I think we should steer people towards hybrids.
On Monday, 11 November 2024 19:00:01 CET, Deirdre Connolly wrote:
OK; what about ML-KEM only?
On Mon, Nov 11, 2024, 9:58 AM Bas Westerbaan wrote:
That was before the release o
OK; what about ML-KEM only?
On Mon, Nov 11, 2024, 9:58 AM Bas Westerbaan wrote:
> That was before the release of FIPS 203.
>
> On Mon, 11 Nov 2024 at 18:29, Deirdre Connolly
> wrote:
>
>> Two meetings ago there was a consistent vibe in the room that
>> Recommend'ing any PQ parameters, hybrid or
That was before the release of FIPS 203.
On Mon, 11 Nov 2024 at 18:29, Deirdre Connolly
wrote:
> Two meetings ago there was a consistent vibe in the room that
> Recommend'ing any PQ parameters, hybrid or no, was premature; has that
> changed?
>
> On Mon, Nov 11, 2024 at 9:00 AM Alicja Kario wro
Two meetings ago there was a consistent vibe in the room that
Recommend'ing any PQ parameters, hybrid or no, was premature; has that
changed?
On Mon, Nov 11, 2024 at 9:00 AM Alicja Kario wrote:
> On Sunday, 10 November 2024 13:38:38 CET, Kris Kwiatkowski wrote:
> > Hello,
> >
> > As discussed du
On Sunday, 10 November 2024 13:38:38 CET, Kris Kwiatkowski wrote:
Hello,
As discussed during the TLS session at IETF 121, we would like
to propose the adoption of draft-kwiatkowski-tls-ecdhe-mlkem.
Very much in favour of adopting this draft.
There are a few open questions that need to be ad
Just a quick update/reminder on this:
The authors acknowledged that their implementation of key schedule in
ProVerif was incorrect [5-6]. So this part of the mystery was resolved.
However, it is still unclear whether there are any /practical/ attacks
if Derive-Secret is skipped in generating
On Sun, Nov 10, 2024, 12:24 PM Christian Huitema
wrote:
> I am reading the "bytes server -> client" thread, and I think that the
> evaluation misses a point regarding QUIC, and probably other UDP based
> protocols as well.
>
> The QUIC handshake embeds a TLS 1.3 handshake. The client sends the
>
Nit: we have two HPKE IDs registered. (X25519Kyber768Draft00 at KEM id
0x0030 and X-Wing at 0x647a).
Otherwise I agree with Eric and Rich.
Best,
Bas
On Mon, Nov 11, 2024 at 2:15 PM Eric Rescorla wrote:
> Unlike TLS itself defines cipher suites, ECH just depends on the HPKE
> registry from RF
On 11/11/2024 09:47, Gianpaolo Angelo Scalone, Vodafone wrote:
> Would it make sense to have a specific section on making ECH quantum
> safe and provide privacy also in perspective?
> IMO, no. That's mostly an issue for HPKE.
Strongly agree.
___
TLS m
On Mon, Nov 11, 2024 at 12:51 PM Michael Richardson
wrote:
>
> Christian Huitema wrote:
> > To summarize, the QUIC handshake will require an extra RTT:
>
> > * if the server flight is larger than 3 times the Client Hello,
> > * if the Client Hello is larger than 12,000 bytes,
> >
Unlike TLS itself defines cipher suites, ECH just depends on the HPKE
registry from RFC 9180 (
https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids). While
there aren't currently any PQ-safe HPKE IDs registered, we do have
proposals for them (
https://www.ietf.org/archive/id/draft-connoll
On 11/11/2024 09:47, Gianpaolo Angelo Scalone, Vodafone wrote:
Would it make sense to have a specific section on making ECH quantum
safe and provide privacy also in perspective?
IMO, no. That's mostly an issue for HPKE. Let's get the ECH
RFC out (so that code can be upstreamed to projects tha
Christian Huitema wrote:
> To summarize, the QUIC handshake will require an extra RTT:
> * if the server flight is larger than 3 times the Client Hello,
> * if the Client Hello is larger than 12,000 bytes,
> * if the Server Hello is larger than 12,000 bytes.
> If would be ve
Hi, not sure if this has to go under ECH or under DNS SVCB/HTTPS RR, but given
current status ECH will provide E2E privacy today , but is not Quantum Safe.
Would it make sense to have a specific section on making ECH quantum safe and
provide privacy also in perspective?
C2 General
_
18 matches
Mail list logo
