Hello,
All changes regarding error handling and input validation merged.
Thank you for your contribution.
--
Kris Kwiatkowski
Cryptography Dev
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
On Wed, Oct 16, 2024, at 13:15, Paul Wouters wrote:
>> Suppose that the server was using key A and publishes an appropriate
>> record. It then loses the key and starts using B. If a client comes
>> in using key A, the server is supposed to follow the ECH configuration
>> correction procedure in S
On Tue, Oct 15, 2024 at 7:15 PM Paul Wouters wrote:
> On Fri, 11 Oct 2024, Eric Rescorla wrote:
>
> > Thanks you for your review. I have created a PR that addresses a number
> of these.
> >
> > https://github.com/tlswg/draft-ietf-tls-esni/pull/632
>
> That looks fine, other than the accidental ty
On Fri, 11 Oct 2024, Eric Rescorla wrote:
Thanks you for your review. I have created a PR that addresses a number of
these.
https://github.com/tlswg/draft-ietf-tls-esni/pull/632
That looks fine, other than the accidental typo introduction I pointed out.
[ deleted agreements, thanks for prop
The following errata report has been submitted for RFC9147,
"The Datagram Transport Layer Security (DTLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8141
--
Type: Te
I think we’re still missing a code point for secp384r1mlkem1024:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
https://www.ietf.org/archive/id/draft-kwiatkowski-tls-ecdhe-mlkem-02.html#name-iana-considerations
Cheers,
Andrei
From: Blumenthal, Uri - 0553 -
On Tue, Oct 15, 2024 at 4:50 PM Jan Schaumann wrote:
> Bas Westerbaan wrote:
> > As of today, we support X25519MLKEM768 (0x11ec) on essentially all
> websites
> > served through Cloudflare.
>
> To clarify: this is for traffic from clients to
> Cloudflare
Yes.
> or is this also enabled for tr
Bas Westerbaan wrote:
> As of today, we support X25519MLKEM768 (0x11ec) on essentially all websites
> served through Cloudflare.
To clarify: this is for traffic from clients to
Cloudflare (and I suppose interally within Cloudflare
systems), or is this also enabled for traffic to the
origin (provi
I second the request to add support for secp384r1mlkem1024, as that’s the only
hybrid KEX that makes sense for us.
Thank you!
--
V/R,
Uri
There are two ways to design a system. One is to make it so simple there are
obviously no deficiencies.
The other is to make it so complex there are n
On Tuesday, 15 October 2024 14:49:06 CEST, Bas Westerbaan wrote:
On Tue, Oct 15, 2024 at 1:52 PM Alicja Kario wrote:
Do you plan to add support for secp256r1mlkem768 and secp384r1mlkem1024?
Not at this time. We want clients to guess correctly which PQ kex the
server supports, and that's eas
On Tue, Oct 15, 2024 at 1:52 PM Alicja Kario wrote:
> Do you plan to add support for secp256r1mlkem768 and secp384r1mlkem1024?
>
Not at this time. We want clients to guess correctly which PQ kex the
server supports, and that's easier if there are fewer deployed. Hopefully
clients will adopt
http
Do you plan to add support for secp256r1mlkem768 and secp384r1mlkem1024?
Running the tlsfuzzer script against pq.cloudflareresearch.com I see
that it doesn't handle the errors correctly: it sends decode_error
instead of illegal_parameter for malformed client key shares.
Also, it looks to me like
Felix,
Thank you for your reply and sorry for taking so long to respond.
I do realise that you are not arguing via IND-CCA security. I was trying
to use the hybrid KEM setting as (I thought) a simpler way of illustrating
my point. Clearly that didn't work!
Nevertheless, in your setting the pre
As of today, we support X25519MLKEM768 (0x11ec) on essentially all websites
served through Cloudflare.
Best,
Bas
On Fri, Sep 6, 2024 at 1:02 PM Bas Westerbaan wrote:
> Hi all,
>
> We are planning to replace X25519Kyber768Draft00 (0x6399)
> with X25519MLKEM768 (0x11ec) [1], a hybrid of ML-KEM-
14 matches
Mail list logo
