Hi,
I'm opposed to adoption.
I share the same concern with Stephen.
The conservative hybrid key exchange way should be preferred.
Cheers,
Shuzhou
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
Hi TLS co-chairs,
I support adoption.
Regards,
Quynh.
On Wed, Apr 2, 2025 at 12:09 AM Loganaden Velvindron
wrote:
> I share the same view as Martin. I also support adoption but we should
> be very careful proceeding forward.
>
> On Wed, 2 Apr 2025 at 05:00, Martin Thomson wrote:
> >
> > Like
On Tue, 1 Apr 2025 at 19:30, David Adrian wrote:
>
> I support adoption of this document.
>
> - I suspect we will eventually need pure ML-KEM-1024 in browsers.
What's the time frame ?
> - I find the argument that we must use hybrids extremely non-compelling.
> Lattice cryptography is "boring" cr
I share the same view as Martin. I also support adoption but we should
be very careful proceeding forward.
On Wed, 2 Apr 2025 at 05:00, Martin Thomson wrote:
>
> Like other pure ML-KEM uses, I am OK with adoption, though I might oppose
> Recommended: Y when it comes to that. I also share John's
Like other pure ML-KEM uses, I am OK with adoption, though I might oppose
Recommended: Y when it comes to that. I also share John's concerns about key
reuse, but would prefer to litigate that in the working group, rather than
during adoption.
On Tue, Apr 1, 2025, at 23:58, Sean Turner wrote:
>
I think that adoption is fine. I might oppose the registration of a codepoint
that was Recommended: Y for reasons similar to what Stephen described, but we
can talk about that.
On Tue, Apr 1, 2025, at 23:58, IETF Secretariat wrote:
> The TLS WG has placed draft-connolly-tls-mlkem-key-agreement
I had to go look too. One day I'll have all manner of important stuff
memorized.
Deb
On Tue, Apr 1, 2025 at 1:10 PM Ketan Talaulikar
wrote:
> Thanks Rich and Deb !
>
>
> On Tue, Apr 1, 2025 at 10:22 PM Salz, Rich wrote:
>
>> I should probably have a tattoo made somewhere that lists the BCP 14
SIKE was applied to large volumes of user data as part of the CECPQ2
experiment in 2019. SIKE was publicly broken in 2022.
The _only_ reason that this didn't immediately give away the user data
to attackers is that CECPQ2 was ECC+SIKE, rather than just SIKE.
Should we keep rolling out post-quantu
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-announced tranche of WG adoption c
Orie Steele has entered the following ballot position for
draft-ietf-tls-tls12-frozen-07: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://w
> A question to the authors:
> The draft talks about "users that need to be fully post-quantum".
> Can you please give a specific example of such users and their motivation?
A specific example is moving to a compute / dependency base that is
minimalist to only PQ primitives they wish to maintain,
Hiya,
I'm opposed to adoption, at this time.
- I think we ought to encourage hybrids but not pure PQ KEMs
and so adopting documents on hybrid KEMs can make sense so
we can more easily get to a reommended="Y" in the IANA
registry when the WG wants to
- I don't see what criteria we might us
### Section 2
Thanks for prefixing NIST with US in `US National Institute of Standards and
Technology` but you forgot to introduce the NIST acronym ;-)
Already fixed via Med’s recommendations in a later draft.
Any reason why BCP14-like notation is used in `TLS 1.2 WILL NOT be supported` ?
Rather
Thanks Rich and Deb !
On Tue, Apr 1, 2025 at 10:22 PM Salz, Rich wrote:
> I should probably have a tattoo made somewhere that lists the BCP 14
> words. As WILL NOT has no standing, I will gladly change it to lowercase.
> Thank you.
>
>
>
> *From: *Deb Cooley
> *Date: *Tuesday, April 1, 2025 a
I should probably have a tattoo made somewhere that lists the BCP 14 words. As
WILL NOT has no standing, I will gladly change it to lowercase. Thank you.
From: Deb Cooley
Date: Tuesday, April 1, 2025 at 12:30 PM
To: Salz, Rich
Cc: Ketan Talaulikar , The IESG ,
draft-ietf-tls-tls12-fro...@iet
>I think we ought to encourage hybrids
>I think following the old practice of telling the ISE we have no objection to
>this ending up as an
independent stream RFC is the better approach for this one
I think reuse of ephemeral keys is a much bigger practical security problem
than not using hybrid
I think the question may be why 'WILL NOT' vice 'will not' especially
since 'will' and 'will not' isn't listed in BCP 14 as 'special'.
will not is just as normative as WILL NOT without the BCP 14 baggage
Deb
On Tue, Apr 1, 2025 at 10:59 AM Salz, Rich wrote:
>
>
> Work on post-quantum c
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-announced tranche of WG adoption calls; see
> [0] for more information. This time we are issuing a WG adoption call for
> the ML-KEM Post-Quant
I support adoption of this document.
- I suspect we will eventually need pure ML-KEM-1024 in browsers.
- I find the argument that we must use hybrids extremely non-compelling.
Lattice cryptography is "boring" crypto at this point, and I find it to be
cognitive dissonance to simultaneously argue th
I support adoption
> -Original Message-
> From: IETF Secretariat
> Sent: Tuesday, April 1, 2025 8:58 AM
> To: draft-connolly-tls-mlkem-key-agreem...@ietf.org; tls-cha...@ietf.org;
> tls@ietf.org
> Subject: [TLS] The TLS WG has placed draft-connolly-tls-mlkem-key-agreement
> in state "Call
I agree with Stephen on this one and would not support adoption of non-hybrids.
There is no reason to not work on things like preventing key reuse at the ISE.
A question to the authors:
The draft talks about "users that need to be fully post-quantum".
Can you please give a specific example of suc
Work on post-quantum cryptography for TLS 1.2 SHOULD NOT be undertaken (see
Section 4) in the IETF and anyone wishing to deploy post-quantum cryptography
is expected to use TLS 1.3 (or newer). Related work MAY be taken up by the TLS
WG consensus in exceptional scenarios.
The consensus of the W
I support adoption.
I agree with John that reuse of ephemeral keys is a far bigger security
problem, in theory and even more so in practice.
Coincidentally, I disagree with Stephen – there’s no need to encourage or
discourage either hybrids or pure KEMs.
--
V/R,
Uri
From: John Mattsson
Date:
I was all set to say that I am in favor of adoption, but Stephen’s post changed
my mind.
The conservative and safe thing is to stick to hybrids and that is what the
IETF should do for now. Codepoints can be assigned, and an ISE RFC is fine. The
only thing that is missing is the IETF recommendat
I support adoption
Ms. Rebecca Guthrie
Center for Cybersecurity Standards (CCSS)
Cybersecurity Collaboration Center (CCC)
National Security Agency (NSA)
-Original Message-
From: Sean Turner
Sent: Tuesday, April 1, 2025 8:58 AM
To: TLS List
Subject: [TLS] WG Adoption Call for ML-KEM Pos
I support adoption.
Russ
> On Apr 1, 2025, at 8:58 AM, Sean Turner wrote:
>
> We are continuing with our pre-announced tranche of WG adoption calls; see
> [0] for more information. This time we are issuing a WG adoption call for the
> ML-KEM Post-Quantum Key Agreement for TLS 1.3 I-D [1]. If
On Tue, Apr 01, 2025 at 01:12:54PM +, John Mattsson wrote:
> I support adoption as long as reuse of ephemeral keys is normatively
> forbidden, i.e. MUST NOT reuse.
Preëmptive conditions in calls for adoption seem meaningless to me. You
either support adoption, or you don't. Once the documen
Hi,
I supported adoption of draft-kwiatkowski-tls-ecdhe-mlkem in the belief that
reuse of ephemeral keys were forbidden, which aligns with NIST requirements for
ECDHE and DHE. I am strongly against any reuse of ephemeral private keys [1].
The reasons to not reuse ephemeral keys is much stronger
The TLS WG has placed draft-connolly-tls-mlkem-key-agreement in state
Call For Adoption By WG Issued (entered by Sean Turner)
The document is available at
https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
___
TLS mailing list --
>
>
> KT> Suggest:
>
>
>
> Work on post-quantum cryptography for TLS 1.2 MUST NOT be undertaken (see
> Section 4) in the IETF and anyone wishing to deploy post-quantum
> cryptography is expected to use TLS 1.3 (or newer).
>
>
>
> I don’t like this rephrasing. MUST NOT is stronger to me, than saying
Hi! Did you know the TLS WG has a FAQ? Well, we do; see [0]. Please consult it
before:
• Bringing new work to the WG
• Registering Specification Required code points for extensions, cipher
suites, exporter labels, etc.
• Requesting agenda time
Also, please note that you too can submit
As a scheduled reminder, and not in response to recent messages, this list is
governed by IETF’s Working Group Procedures [BCP25]. This document includes
Anti-Harassment Procedures, and by participating you agree to the Note Well
[NW] and to follow the Code of Conduct [CoC]. Thank you for contri
KT> Suggest:
This document specifies that outside of urgent security fixes (as determined by
TLS WG consensus), and the exceptions listed in Section 4, IETF will not
approve any changes for TLS 1.2.
I will add that, thanks.
KT> Suggest:
Work on post-quantum cryptography for TLS 1.2 MUST NOT
Hi Rich,
Please check inline below for response with KT where I have included some
suggestions:
On Mon, Mar 31, 2025 at 2:56 AM Salz, Rich wrote:
> Thank you for the review.
>
>
>
>
> 1) Section 1
>
> "This document specifies that outside of urgent security fixes, and the
> exceptions listed i
34 matches
Mail list logo
