On Tuesday, 20 May 2025 21:08:51 CEST, Viktor Dukhovni wrote:
On Tue, May 20, 2025 at 07:31:23PM +0200, Alicja Kario wrote:
I would like to point out that we need the same kind of
codepoints no matter
if we want to use SLH-DSA in the end entity certificates or in CA
certificates.
This
uld still afford plenty of time for software
updates to make these available when needed.
--
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
re and how quickly
implementers want them deployed/available.
At Red Hat we have a general policy of _not_ shipping features until they
are
frozen as RFC documents. PQC is very much an exception to this process.
--
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: w
to do with
picking the mandatory-to-implement cipher suites in TLS.
Cheers,
Joe and Sean
[1] https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
[2] https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/
--
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto
---
RFC8446 (draft-ietf-tls-tls13-28)
--
Title : The Transport Layer Security (TLS)
Protocol Version 1.3
Publication Date: August 2018
Author(s) : E. Rescorla
Category: PROPOSED STANDARD
Source
pport adoption of this
draft, please send a message to the list and indicate why. This
call will close at 2359 UTC on 29 April 2025.
Reminder: This call for adoption has nothing to do with
picking the mandatory-to-implement cipher suites in TLS.
Cheers, ...
--
Regards,
Alicja Kario
Prin
://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/
--
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
TLS mailing list -- tls
his big in
TLS... (reminder: 4.4 kiB, 8.8 kiB, and 14.1 kiB for 128, 192 and 256
bit level of security respectively)
--
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_
cdhe-mlkem/
[1] Link to slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-tls-post-quantum-hybrid-ecdhe-mlkem-key-agreement-for-tlsv13-00
[2] Link to information gather thread:
https://mailarchive.ietf.org/arch/msg/tls/yGZV5dBTcxHJhG-JtfaP6beTd68/
--
Regards,
Alicja K
ontain confidential or proprietary information. If you
are not the designated recipient, you may not review, copy or
distribute this message. If you have mistakenly received this
message, please notify the sender by a reply e-mail and delete
this message. Thank you.
--
Regards,
Alicja Kari
On Friday, 21 February 2025 22:15:06 CET, Muhammad Usama Sardar wrote:
On 20.02.25 13:36, Alicja Kario wrote:
if you can't trust the system you're running an application on, you
*definitely* can't trust any network connections from it
It depends on how you define "system
oject will almost certainly be able to remidy it
faster than the IETF.
--
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
On Thursday, 20 February 2025 13:12:48 CET, Bellebaum, Thomas wrote:
The connection is secure. TLS doesn't defend against compromised devices.
I disagree. While the *network* connection itself may inhibit
the rather technical notions of confidentiality and integrity,
this is not what the aver
On Wednesday, 15 January 2025 18:37:58 CET, Quynh Dang wrote:
On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein wrote:
Quynh Dang writes: ...
As discussed previously, "what's best from an engineering perspective", is
there the decision maker such as a judge to say A is the right one, not B
or
(I originally proposed PR that added that codepoint, together with the
secp384r1mlkem1024, so I'm really not against it, but...)
Can you point to examples of people actually using x448 (TLS group ID 30)
in
practice?
If you want to experiment, then there's the whole private range, what would
ma
On Monday, 6 January 2025 11:35:57 CET, John Mattsson wrote:
I also have a hard time too see why it is needed.
MLKEM1024 is the CNSA 2.0 approved key exchange
https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html
secp384r1 is the CNSA 1.0 approved key exchange
https://www.rfc-e
On Monday, 6 January 2025 09:49:35 CET, Viktor Dukhovni wrote:
On Mon, Jan 06, 2025 at 08:00:04AM +, Kris Kwiatkowski wrote:
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 a
Agreed, accepting the drafts as WG documents says nothing about which
will proceed to RFC status first.
On Tuesday, 24 December 2024 18:47:22 CET, Scott Fluhrer (sfluhrer) wrote:
I would humbly disagree. I believe this working group has
enough bandwidth to handle a couple of postquantum drafts
On Monday, 16 December 2024 22:59:50 CET, Sean Turner wrote:
Ask:
Is the WG consensus to run four separate adoption calls for the
individual I-Ds in question?
I'm FOR adoption of all of the four mentioned drafts.
I don't have a strong opinion if they should be considered separately or
not.
No, the specification definitely can, and should, specify behaviours that
are unenforcable.
When there are preferred or recommended ways of doing something, we should
absolutely put that in writing.
On Thursday, 12 December 2024 21:07:03 CET, Christian Huitema wrote:
I like keeping as they are.
an that no new *features* (e.g.
new TLS messages) will be added, but that the “extension points”
(e.g. new ciphersuites) continue to be available.
Thanks,
Yaron
On 09/12/2024, 21:01, "Alicja Kario" wrote:
I think it's ready for publication.
On Tuesday, 3
On Saturday, 7 December 2024 23:32:03 CET, D. J. Bernstein wrote:
Watson Ladd writes:
Having MLKEM without a hybrid as an option in TLS when the interoperable
choice is a hybrid
Some previous messages claim that there's a split between customers
demanding hybrids and customers demanding non-hy
+1 for adoption
While I'm stronly against wide deployment of pure ML-KEM at this moment in
time, I'm very much in favour of adoption of this document, having
stable definitions for such codepoints, even if they will get doployed only
in closed networks is still useful.
On Thursday, 5 December 20
I think it's ready for publication.
On Tuesday, 3 December 2024 22:26:30 CET, Sean Turner wrote:
This is the working group last call for TLS 1.2 is in Feature
Freeze. Please review draft-ietf-tls-tls12-frozen [1] and reply
to this thread indicating if you think it is ready for
publication or n
On Tuesday, 26 November 2024 03:51:20 CET, Watson Ladd wrote:
On Mon, Nov 25, 2024, 8:47 PM Salz, Rich
wrote:
Could you explain why thiis way is better than changing to TLS 1.3?
It is often the case that organizations will find it easy to
make a fairly minor change rather than installing
On Thursday, 21 November 2024 22:02:45 CET, Stephen Farrell wrote:
Hiya,
Without going into the details, I'm generally sympathetic to djb's
argument here, but also do recognise ekr's "we allow anyone to get
a RECOMMENDED=N code point" as valid.
That said, if the WG adopt *anything* with RECOMME
On Thursday, 21 November 2024 19:23:12 CET, Tim Hollebeek wrote:
Yes, the thread on this draft got hijacked by a completely
off-topic discussion about composite and hybrid.
To be clear, the draft says absolutely nothing about either of
those two topics, and to be even more clear, does not at a
On Tuesday, 19 November 2024 12:19:06 CET, D. J. Bernstein wrote:
Alicja Kario writes:
We can't use hybrid if we don't have a specification how to put hybrid
keys into X.509 certificates.
Take a specification of how to put a Dilithium key into certificates.
Modify the spec as follow
On Tuesday, 19 November 2024 15:27:03 CET, D. J. Bernstein wrote:
Alicja Kario writes:
Or:
Auditor sees that P + Q system is more complex to implement and validate
than a simple Q system, therefore ML-DSA security >
ML-DSA+Ed25519 security.
Therefore the deployment of CECPQ2b = ECC+S
On Monday, 18 November 2024 23:24:51 CET, D. J. Bernstein wrote:
Alicja Kario writes:
Unfortunately, I don't think we have a rough consensus in
LAMPS on how hybrid signatures should be done just yet, and without that,
we can't standardise it for TLS.
It's trivial to build a s
Thanks for the work on this document, it's highly appreciated!
Few comments:
- If we allow for pkcs#1v1.5 sig schemes in signatures_algorithms_cert but
not in signatures_algorithms I think we should, at the very least,
ask IANA to add a column to the SignatureScheme namespace that
includes
Answering to the broader thread: when I said "uncontroversial" I was
thinking
more about _how_ it should be done, not _if_ it should be used.
Answer to email below follows.
On Saturday, 16 November 2024 09:57:03 CET, D. J. Bernstein wrote:
Watson Ladd writes:
Authentication is not like encryp
On Friday, 15 November 2024 18:33:27 CET, Stephen Farrell wrote:
Hiya,
On 15/11/2024 17:12, John Mattsson wrote:
WebPKI might want to wait but the many infrastructure use cases of
TLS, DTLS, and QUIC need to migrate very soon. US government new
requirement is that pure RSASSA, ECDSA, and EdDSA
On Friday, 15 November 2024 18:12:28 CET, John Mattsson wrote:
I'm unenthusiastic but don't strongly oppose adoption of this and
similar drafts, mostly because I think we should try get some WG
consensus on guidance for when these things may be needed (if ever)
and what the consequences might be
On Friday, 15 November 2024 18:38:56 CET, Andrey Jivsov wrote:
I am curious why this draft exclusively proposes ML-DSA,
instead of adopting a composite signature approach as outlined
in draft-ounsworth-pq-composite-sigs, at least as an option. For
instance, id-MLDSA87-ECDSA-P384-SHA512 defined
Very happy to see it.
I'm for workgroup adoption of it.
On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan wrote:
We have posted a -00.
https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00
On Wed, Oct 23, 2024 at 7:29 PM Bas Westerbaan wrote:
Hi all,
Unless I overlook
ore 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 wrote:
On Sunday,
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
On Thursday, 7 November 2024 14:58:02 CET, Peter Gutmann wrote:
The current late-to-the-party response seems to be mostly a
chorus of "I haven't read it but I know I don't like it".
There is no need for personal attacks.
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Cry
I do not support adoption.
On Tuesday, 5 November 2024 17:25:16 CET, Sean Turner wrote:
REQUEST: Let’s not rehash all the context. It is provided for
those who might not remember or those that were not around for
the duration.
CONTEXT: Way back in 2016 after the WG had embarked on
developin
Hello,
I don't think we should go back to signing with PKCS#1 v1.5 in TLSv1.3.
I'm opposed to including those two IDs:
mldsa44_rsa_pkcs1_sha256 (0x090C),
mldsa65_rsa_pkcs1_sha384 (0x090D),
Theoretically we could require the RSA part to still make PSS signatures
but I think that would b
On Monday, 4 November 2024 14:39:12 CET, Peter C wrote:
Tirumal Reddy wrote:
SLH-DSA is not proposed for the end-entity certificates, it is preferred
for CA certificates (please see the 3rd paragraph in
https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.html#section-2)
Yes, except the
On Sunday, 3 November 2024 22:22:52 CET, Peter C wrote:
John Mattsson wrote:
”Conversely, the fast version prioritizes speed over
signature size, minimizing the time required to generate
and verify signatures.”
This is incorrect. The “f” versions only have faster key
generation and signing. The
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
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
On Friday, 25 October 2024 16:31:17 CEST, Eric Rescorla wrote:
On Thu, Oct 24, 2024 at 12:38 AM Bas Westerbaan wrote:
Today for the WebPKI there is no security benefit to enabling
post-quantum certificates (in stark contrast with post-quantum
key agreement.) On the other hand, there is a big
x27;s supposed to be used only on networks fully controlled by
operator,
why "Recommended = Y"?
Could be an option to restrict things to 2^24 byte, but we felt
it was more natural to support sizes up to 2^32.
Cheers,
John
From: Alicja Kario
Date: Friday, 25 October 2024 at
While I'm sceptical of a need to send nearly 2^32 byte records, or
that it would increase performance, the draft is well thought out
and detailed enough. I wouldn't be opposed to it.
Not being compatible with TLS 1.2 middleboxes is a problem too...
I think that precludes it from being "Recommende
On Thursday, 24 October 2024 17:58:18 CEST, Watson Ladd wrote:
On Thu, Oct 24, 2024 at 8:52 AM Tim Hollebeek
wrote:
My personal feelings on pure vs composite are actually the
union of several
previous comments:
1. Like EKR, I actually have a weak preference for composite, all other
things
On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote:
Hi all,
Unless I overlooked something, we don't have a draft out to
assign a SignatureAlgorithm to ML-DSA for use in TLS.
It's two days past the I-D submission deadline, but I wanted to
point you to a short draft we put toget
n Mattsson
wrote:
Let’s have an adoption call asap.
I made some minor suggestions
https://github.com/bwesterb/tls-mldsa/pull/3
John
From: Alicja Kario
Date: Wednesday, 23 October 2024 at 19:59
To: Bas Westerbaan
Cc:
Subject: [TLS] Re: ML-DSA in TLS
Hi,
Thanks for the d
n go wrong with this
draft is scope creep.
-Tim
From: Deirdre Connolly
Sent: Wednesday, October 23, 2024 3:22 PM
To: Alicja Kario
Cc: Bas Westerbaan ;
Subject: [TLS] Re: ML-DSA in TLS
I would rather have a separate I-D for anything beyond ML-DSA
(and thanks, this is great!)
H-DSA
codepoints as those may be used by the CA certs, even if the EE use
ML-DSA...
or make it a separate I-D?
John
From: Alicja Kario
Date: Wednesday, 23 October 2024 at 19:59
To: Bas Westerbaan
Cc:
Subject: [TLS] Re: ML-DSA in TLS
Hi,
Thanks for the draft, will definitely be helpful.
Hi,
Thanks for the draft, will definitely be helpful.
Few issues:
* The range 0x0900-0x0903 is reserved for backwards compatibility
I think it will be better to continue the numbering in the 0x08.. space
* the must in "must use id_ML-DSA(...)" probably should be capitalised, as
if it doesn't
On Thursday, 17 October 2024 18:31:05 CEST, John Mattsson wrote:
We should have a consistent ordering of [EC, PQ] in both the
names and the key schedule. I.e., the code should be
>consistent with the naming and either the EC or the PQC ought
to always come first.
+1
(if FIPS leads to weird
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&#
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
I've been working on support for the ML-KEM hybrid key exchanges in
tlsfuzzer[1,2], and I've noticed that the error handling is underspecified:
both key shares (client and server) and both constituent parts (pqc and
classic)
can have key shares are are invalid.
Also, the ECDH key exchange can e
On Tuesday, 10 September 2024 16:05:51 CEST, 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 i
wards National Security Algorithm Suite. Also, isn't X448 TLS
deployment nearly non-existent?
2024-09-09 15:16 GMT+02:00 Alicja Kario :
Not explicitly, but it is definied in other protocols, like CMS where it
was asked for explicitly.
I can remove it, but I think that omiting it wil
On Monday, 9 September 2024 14:49:08 CEST, D. J. Bernstein wrote:
Alicja Kario writes:
We haven't actually performed
an attack in which we extracted the private key.
[ ... ]
In practice, what we've shown is that the implementation is _likely_
vulnerable to microarchitectural si
:
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 is an interest I propose we add it to existing draft,
publish version -03 and request a code p
aphy/draft-kwiatkowski-tls-ecdhe-mlkem
Feel free to open PR
done:
https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/22
Cheers,
Kris
From: Alicja Kario
Sent: Saturday, September 7, 2024 12:39:30 AM
To: kris; tls@ietf.org
Subject: draft-kwiatkowski-tls-ecdhe-mlkem
On Monday, 9 September 2024 08:44:46 CEST, D. J. Bernstein wrote:
John Mattsson writes:
ignoring the mandatory point validation
Exactly! That's how the real world works. The NSA/NIST approach fills
ECDH and signatures with traps for the implementors; implementors fall
into the traps; the NSA/N
Hello,
What's the situation with other groups for TLS 1.3?
Specifically, are there any plans to specify SecP384r1MLKEM1024?
As mentioned in multiple emails already, high security system
already have a strict requirement to use P-384 curve exclusively.
Similarly, for post-quantum resistance they
65 matches
Mail list logo
