Hello,
I support adoption and willing to review.
--
Kris Kwiatkowski
Cryptography Dev
> On 15 Apr 2025, at 20:17, Quynh Dang wrote:
>
> Hi TLS co-chairs,
>
> I support adoption and am willing to review.
>
> Regards,
> Quynh.
>
> On Tue, Apr 15, 2025 at 1:
I support adoption.
Cheers,
Kris
> On 1 Apr 2025, at 16:53, Yaroslav Rosomakho
> wrote:
>
> I strongly support adoption of this document.
>
> Best Regards,
> Yaroslav
>
> On Tue, Apr 1, 2025 at 2:00 PM Sean Turner wrote:
> We are continuing with our pre-an
Perfect!
Thanks Sean. We will come back to chairs shortly.
- Kris
On March 20, 2025 5:01:31 PM GMT+07:00, Sean Turner wrote:
>Hi! It looks like we have consensus to adopt this draft as a working group
>item. Couple of things to note:
>
>1. Authors, please submit the draft named as
Hi John,
Thanks for reporting that (again). Indeed, I was hoping this text could be
added to draft-ietf-tls-hybrid-design.
Please, let me know if this text properly addresses your concern:
https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/35
Cheers,
Kris
>
Thanks.
Sounds real good.
On 07/03/2025 10:22, Tim Hudson wrote:
On Fri, Mar 7, 2025 at 7:01 PM Kris Kwiatkowski wrote:
May I know if you have a plan for FIPS certificaton for PQC after release?
Absolutely - OpenSSL-3.5 will be heading into a fresh FIPS140-3 validation
in April once
Indeed, that's very nice. I'm actually running OpenSSL built from a branch
vduc/hybrids on my server
and X25519MLKEM768 seems to work alright.
May I know if you have a plan for FIPS certificaton for PQC after release?
Cheers,
Kris
On 07/03/2025 04:02, Viktor Dukhovni wrote:
On T
Yes, it should be the case once SP800-56C is updated (which is a plan). See
this message:
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ST_yMzYyMl0/m/hFlrkW1CCgAJ
On 27/02/2025 19:05, Salz, Rich wrote:
I thought that I remember (sic) that NIST said that hybrid key exchange,
where on
Perfect!
Thank you Sean!
On 26/02/2025 14:59, Bas Westerbaan wrote:
Thank you Sean!
On Wed, Feb 26, 2025 at 3:41 PM Sean Turner wrote:
Hi! Just in case you missed it [0], your draft is up first in the PQ
wg-call-for-adoption-o-rama. I should have the message out later today.
spt
Sure, but for the record the same applies to SecP3841MLKEM1024
I think the main motivation for ECDH/P-384 is CNSA compliance, so I don't
think it is "the same applies". Yes,
it is slower than x25519 or ECDH/p256.___
TLS mailing list -- tls@ietf.org
To
On 06/01/2025 06:18, Viktor Dukhovni wrote:
it would be very unlikey to get
used.
The addition of that codepoint was previously discussed on this mailing list,
and as Victor says,
it is unlikely to be used.___
TLS mailing list -- tls@ietf.org
To unsub
Hello,
The code point for SecP384r1MLKEM1024 has been registered.
Please see
https://www.iana.org/assignments/tls-parameters
Happy New Year,
Kris
On December 11, 2024 2:38:59 PM GMT+01:00, Bas Westerbaan
wrote:
>Following the feedback from the last TLS meeting at IETF@121
I would like to see adoption of all four documents
andhttps://datatracker.ietf.org/doc/draft-tls-westerbaan-mldsa/ which was left
out. I assume the latter was merely an oversight.
Yes, it was an oversight on my part.
I support adoption of draft-tls-westerbaan-mldsa._
I also think it would be good to adopt MLKEM drafts (hybrid and pure).
No opinion on drafts for signature schemes.
On 16/12/2024 23:13, Russ Housley wrote:
+1. There are people that want to implement both hybrid and pure key exchange.
This action would allow a path to RECOMMENDED = Y for both
ext in draft-ietf-tls-hybrid-design. I
have opened this PR
https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/39.
With that I hope the draft is ready for adoption.
Any feedback is more then welcome.
Kind regards,
Kris
___
TLS mailing list
to register Secp384r1MLKEM1024, but I believe this
should only be done once we reach a consensus regarding
point 2.
Thank you!
--
Kris Kwiatkowski
Cryptography Dev
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
I support the adoption. I also think we will end up standardizing pure ML-DSA
anyway.
Modify the TLS protocol to rely on multiple certificates (one of which might
be a traditional RSA certificate and one an ML-KEM only certificate)?
+1. Composite signatures are also interesting, but since TLS a
Just to clarify Kris, you are _asking_ if there is a plan? I don't know
if Quynh can comment but
Yes, I was wondering if there is a concrete plan to relax the ordering
requirement. After yesterday's meeting, I understood
that this is something NIST may consider.
[1] See Mike'
n Thu, 17 Oct 2024 at 08:58, Kris Kwiatkowski wrote:
Yes, we switched the order. We want MLKEM before X25519, as that
presumably can be FIPS-certified.
According to
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf,
section 2,
certified SecP2561r1 crypto backend and not yet certified MLKEM?
This is precisely the problem we want to address with P-256.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
be just a name change, so the code point value should stay the same.
Cheers,
Kris
[1]
https://github.com/open-quantum-safe/oqs-provider/issues/503#issuecomment-2349478942
On 17/10/2024 08:24, Watson Ladd wrote:
Did we really switch the order gratuitously on the wire between them?
On Thu, Oct
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 10 Sep 2024, at 16:05, Salz, Rich wrote:
>
> • I assume draft-ietf-tls-hybrid-design will remove all mentioning of
> Kyber and only refer to the final standardized ML-KEM. I don't think TLS WG
> should publish anything with Kyber.
> In fact, the current unified draft has IANA instruc
is set to
N.
Hence, that’s the logic behind it.
Cheers,
Kris
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
09:45 CEST, Bas Westerbaan wrote:
> Did anyone ask for X448?
>
> On Mon, Sep 9, 2024 at 3:00 PM Alicja Kario wrote:
> On Monday, 9 September 2024 02:04:48 CEST, kris wrote:
>> Hello,
>>
>> I'm sorry, possibly I've missed some emails.
>> If there i
Sweet!
Does this migration includes also cloudflare->origin (egress) connections or
just eyeballs->cloudflare?
Cheers,
Kris
On 06/09/2024 12:02, Bas Westerbaan wrote:
Hi all,
We are planning to replace X25519Kyber768Draft00 (0x6399)
with X25519MLKEM768 (0x11ec) [1], a hybrid of ML-K
Hello,
I'm sorry, possibly I've missed some emails.
If there is an interest I propose we add it to existing draft, publish version
-03 and request a code point.
The repo is here:
https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem
Feel free to open PR
Ch
Hi Andrei,
We’re working on a codepoint for P256+MLEKM.
--
Kris Kwiatkowski
Cryptography Dev
> On 13 Aug 2024, at 16:37, Andrei Popov
> wrote:
>
> I think it would make sense to get new code points for hybrids based on the
> final ML-KEM spec, so that implementers don’t
cryptosystem, introduced already in 2010.
* There is a cost of 2-step migration (to hybrid and then pure PQ), I don’t
believe it’s good to force you to pay the cost.
Additionally, I think I would also get a codepoint for MLKEM-512.
--
Kris Kwiatkowski
Cryptography Dev
on-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf
[2]
https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282
Kind regards,
Kris
> On 6 Nov 2023, at 18:06, Bas Westerbaan
> wrote:
>
>
> On Mon, Nov 6, 2023 at 5:40 PM Kampanakis, Panos
> wro
However, the difference is stated to be UncompressedPointRepresentation
for P256 from TLS 1.3. AFACIT, that is 65 bytes (1 legacy_form byte,
32 bytes for x, 32 bytes for y).
Right, one byte for the legacy_form is missing. Let me fix it.___
TLS mailing
Hello,
The codepoint for P-256+Kyber768 has been just assigned by IANA. The value is
0x639A.
Thanks Rich for pointing to the request form.
Kind regards,
Kris
On 18/05/2023 22:00, Christopher Wood wrote:
Thanks, Rich!
On May 17, 2023, at 3:44 PM, Salz, Rich wrote:
* Can we get
On 23/08/2022 01:39, Martin Thomson wrote:
On Tue, Aug 23, 2022, at 00:11, Kris Kwiatkowski wrote:
As X25519 is not FIPS-approved, the lab won't be able to test it,
OK, hypothetical question, but maybe an important one.
Why would a certification lab care? We compose secrets with non-se
e hybrid construction in which both algorithms are properly
tested and certified by the FIPS lab.
Also, in that case, Z can be generated by either PQ or non-PQ as
both are FIPS-approved.
Kind regards,
Kris
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
there is no clear plan for
updating SP 800-56A with X25519 (opposite to SP 800-186).
Kind regards,
Kris
On 8/17/22 20:06, Scott Fluhrer (sfluhrer) wrote:
So that we get an initial answer to this (so we can put it into the draft - of
course, we can debate what's in the draft...)
I
34 matches
Mail list logo
