On Tue, Apr 15, 2025 at 07:30:25PM -0700, Eric Rescorla wrote:
> On Tue, Apr 15, 2025 at 7:02 PM Viktor Dukhovni
> wrote:
>
> > On Tue, Apr 15, 2025 at 01:55:35PM -0700, Andrey Jivsov wrote:
> >
> > > I don't think that standalone ML-DSA should be adopted.
> > >
> > > There is time to move to a n
On Tue, Apr 15, 2025 at 7:58 PM Viktor Dukhovni
wrote:
> On Tue, Apr 15, 2025 at 07:30:25PM -0700, Eric Rescorla wrote:
> > On Tue, Apr 15, 2025 at 7:02 PM Viktor Dukhovni
> > wrote:
> >
> > > On Tue, Apr 15, 2025 at 01:55:35PM -0700, Andrey Jivsov wrote:
> > >
> > > > I don't think that standal
Using EdDSA as an example, we know that CA's don't just blindly sign EE
certificates. They are in control of what public keys are allowed in a PQ
cert, including for EE certs, and if they choose that it is standalone
ML-DSA, this will have profound implications on TLS and other protocols, in
a way
On Wed, Apr 16, 2025 at 02:15:03AM +, Salz, Rich wrote:
> > If "move to PQ" meant no hybrid stuff for TLS, I'd really wonder why.
>
> That’s easy to answer: “many of our members have very
> hardware-constrained PoS devices.” Is that okay?
It might be possible to design the key exchange such
On Tue, Apr 15, 2025 at 9:06 PM Bas Westerbaan wrote:
> This working group has wisely focussed its efforts on post-quantum key
> agreements for the last five years. It's basically done. I have no doubt
> that if any unforeseen issues might arise in the final stretch, we'll rise
> to the occasion.
This working group has wisely focussed its efforts on post-quantum key
agreements for the last five years. It's basically done. I have no doubt
that if any unforeseen issues might arise in the final stretch, we'll rise
to the occasion.
I suppose adoption of the draft.
Best,
Bas
On Tue, Apr 15,
The TLS WG has placed draft-tls-westerbaan-mldsa in state
Call For Adoption By WG Issued (entered by Sean Turner)
The document is available at
https://datatracker.ietf.org/doc/draft-tls-westerbaan-mldsa/
___
TLS mailing list -- tls@ietf.org
To unsubsc
We are continuing with our WG adoption calls for the following I-D:
Use of ML-DSA in TLS 1.3 [1]; see [2] for more information about this tranche
of adoption calls. If you support adoption and are willing to review and
contribute text, please send a message to the list. If you do not support
ado
Hi! It looks like we have consensus to adopt this draft as a working group
item. There were concerns raised about signaling with this draft as it relates
to draft-ietf-tls-ecdhe-mlkem, but we can address those via the Recommended
column values, publishing one and holding the other, etc.; and, we
SSLKEYLOGFILE doesn't contain any of the asymmetric keys, but just the
computed symmetric keys.
However, because ML-KEM acts like ECDHE as far as TLS 1.3 is concerned,
connections protected with ML-KEM or hybrid will also be decryptable via
SSLKEYLOGFILE.
-Ekr
-Ekr
On Tue, Apr 15, 2025 at 10:
I support adoption, and I will be willing to review
> -Original Message-
> From: Sean Turner
> Sent: Tuesday, April 15, 2025 1:32 PM
> To: TLS List
> Subject: [TLS] WG Adoption Call for Use of ML-DSA in TLS 1.3
>
> We are continuing with our WG adoption calls for the following I-D:
> Us
I support adoption, and I will review.
I agree with EKR that key management is more urgent, but I do not think that
should block adoption.
Russ
> -Original Message-
> From: Sean Turner
> Sent: Tuesday, April 15, 2025 1:32 PM
> To: TLS List
> Subject: [TLS] WG Adoption Call for Use of
I do not think we should adopt this draft at this time. I would prefer the
WG focus its effort on key establishment.
Once those documents are complete, we can reconsider signature.
-Ekr
On Tue, Apr 15, 2025 at 10:34 AM Sean Turner wrote:
> We are continuing with our WG adoption calls for the f
> Hi! At IETF 122, the chairs took a sense of the room about whether to
> progress draft-ietf-tls-keylogfile. There was consensus to do so [0]. We need
> to confirm that on-list. If you disagree with the consensus please let us
> know, and why. We close this call at 1159 UTC on 29 April 2025.
I
On 15/04/2025 18:38, Eric Rescorla wrote:
I do not think we should adopt this draft at this time. I would prefer the
WG focus its effort on key establishment.
Once those documents are complete, we can reconsider signature.
+1 to waiting 'till at least then or later, e.g. after we
have more ex
Sean Turner writes:
> Hi! It looks like we have consensus to adopt this draft as a working
> group item.
Um, what? There were several people (including me) raising objections on
list to basic flaws in this draft, such as (1) the failure to provide an
ECC backup to limit the damage from further sec
Hi TLS co-chairs,
I support adoption and am willing to review.
Regards,
Quynh.
On Tue, Apr 15, 2025 at 1:34 PM Sean Turner wrote:
> We are continuing with our WG adoption calls for the following I-D:
> Use of ML-DSA in TLS 1.3 [1]; see [2] for more information about this
> tranche of adoption
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:34 PM Sean Turner wrote:
> We
The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'The SSLKEYLOGFILE Format for TLS'
as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive
I believe I have already set that I am opposed to adopting pure PQ algorithms
at this time.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
Hi All,
What about new PQC algorithms ML-KEM decryption keys ?
Regards,
Sajeev
On Tue, Apr 15, 2025 at 9:51 PM The IESG wrote:
>
> The IESG has received a request from the Transport Layer Security WG (tls)
> to
> consider the following document: - 'The SSLKEYLOGFILE Format for TLS'
>as Inf
On Sat, 12 Apr 2025, S Moonesamy wrote:
I will note this draft uses the procedures from RFC 8447, a product of this
WG. I will not comment on the meta question of whether an Internet-Draft is
a formal specification of the IETF, but in some of the TLS registries an
Internet-Draft is sufficient
For everyone's convenience:
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/RsQbm_AQfzs/m/19o76lsyCwAJ
On Tue, Apr 15, 2025 at 11:55 AM D. J. Bernstein wrote:
> A message has just appeared on pqc-forum claiming yet another attack
> improvement against lattices---improving what are calle
I also do not think there is a rush or need to implement PQC authentication
algorithms for TLS at this point.
From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Tuesday, April 15, 2025 1:38 PM
To: Sean Turner
Cc: TLS List
Subject: [TLS] Re: WG Adoption Call for Use of ML-DSA in TLS 1.3
I
ZjQcmQRYFpfptBannerEnd
I do not think we should adopt this draft at this time. I would prefer the WG
focus its effort on key establishment.
Once those documents are complete, we can reconsider signature.
I strongly agree.
It might be interesting to see how often the signature algorithm doesn’t
I support adoption and am willing to review.
Rebecca Guthrie
she/her
Center for Cybersecurity Standards (CCSS)
Cybersecurity Collaboration Center (CCC)
National Security Agency (NSA)
-Original Message-
From: Sean Turner
Sent: Tuesday, April 15, 2025 1:32 PM
To: TLS List
Subject: [TLS]
I support adoption. We ultimately will need some form of support for this
in browsers.
On Tue, Apr 15, 2025 at 2:05 PM Rebecca Guthrie wrote:
> I support adoption and am willing to review.
>
> Rebecca Guthrie
> she/her
> Center for Cybersecurity Standards (CCSS)
> Cybersecurity Collaboration Ce
Hi,
I support adoption of this draft and am happy to review.
Flo
fl...@ncsc.gov.uk
UK National Cyber Security Centre
-Original Message-
From: Sean Turner
Sent: 14 April 2025 05:02
To: TLS List
Subject: [TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for
TLS 1.3
Ju
A message has just appeared on pqc-forum claiming yet another attack
improvement against lattices---improving what are called "dual" attacks
and breaking earlier claims about those attacks not working; concretely,
reducing "the security of Kyber-512/768/1024 by approximately
3.5/11.9/12.3 bits" bel
I understand that due to FIPS requirements, this is needed. However, I'm also
going through this:
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/RsQbm_AQfzs/m/19o76lsyCwAJ
Personally, hybrids should be the recommended choice.
I think that the I-D draft-connolly-tls-mlkem-key-agreement sho
Sean Turner writes:
> Hi! It looks like we have consensus to adopt this draft as a working
> group item.
Um, what? There were several people (including me) raising objections on
list to basic flaws in this draft
“Consensus” is not about reaching no dissenters. It’s about the “prevailing”
opini
I don't think that standalone ML-DSA should be adopted.
There is time to move to a non-hybrid X.509 and digital signatures in the
future.
This topic has implications to availability of X.509 certificates, as there
is a real risk that CAs will prefer standalone ML-DSA to ethe exclusion of
hybrids,
Hiya,
On 16/04/2025 00:02, Benjamin Kaduk wrote:
I can see a case being made that this draft does improve the deployability of
TLS if we start with a baseline of draft-ietf-tls-ecdhe-mlkem and note that
that mechanism is not deployable in some environments (I guess, ones with some
kind of stri
On Tue, Apr 15, 2025 at 4:32 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 16/04/2025 00:02, Benjamin Kaduk wrote:
> >
> > I can see a case being made that this draft does improve the
> deployability of
> > TLS if we start with a baseline of draft-ietf-tls-ecdhe-mlkem and note
> that
> > that mechan
Combining posts from two people into one answer.
On 16/04/2025 00:02, Benjamin Kaduk wrote:
>
> I can see a case being made that this draft does improve the deployability of
> TLS if we start with a baseline of draft-ietf-tls-ecdhe-mlkem and note that
> that mechanism is not deployable in some
Hiya,
On 16/04/2025 01:38, Blumenthal, Uri - 0553 - MITLL wrote:
Because our experts evaluated all the relevant risks, and concluded
that while in theory indeed
Crypto_Strength(Hybrid) = max(Crypto_Strength(ECC),
Crypto_Strength(ML_KEM)),
in practical deployments there are other factors to co
I would support adoption, even as experimental.
On Tue, 15 Apr 2025 at 21:38, Scott Fluhrer (sfluhrer)
wrote:
>
> I support adoption, and I will be willing to review
>
> > -Original Message-
> > From: Sean Turner
> > Sent: Tuesday, April 15, 2025 1:32 PM
> > To: TLS List
> > Subject: [T
> that mechanism is not deployable in some environments (I guess, ones with some
> kind of strict FIPS-only requirement, though I'm not conversant in the details
> of such an environment).
A question (not necessarily for Ben): Are there any concrete/specific
environments that we know about that wi
On Tue, Apr 15, 2025 at 01:55:35PM -0700, Andrey Jivsov wrote:
> I don't think that standalone ML-DSA should be adopted.
>
> There is time to move to a non-hybrid X.509 and digital signatures in the
> future.
>
> This topic has implications to availability of X.509 certificates, as
> there is a
Hiya,
On 16/04/2025 02:53, Salz, Rich wrote:
I don’t know of any, especially since NIST has clarified/changed the
rules so that hybrid key agreement schemes AB are valid for FIPS if
either A or B is valid, and also if it’s BA.
Right, that kind of external tweaking/changing, as to what's ok o
> Suppose the payment card industry standards (PCI-DSS) says they want
> all terminals to move to PQ, and in particular MLKEM. Would that
> bother you?
Well, you know I'm easily bothered:-)
If "move to PQ" meant no hybrid stuff for TLS, I'd really wonder why.
That’s easy to answer:
On Tue, Apr 15, 2025 at 7:02 PM Viktor Dukhovni
wrote:
> On Tue, Apr 15, 2025 at 01:55:35PM -0700, Andrey Jivsov wrote:
>
> > I don't think that standalone ML-DSA should be adopted.
> >
> > There is time to move to a non-hybrid X.509 and digital signatures in the
> > future.
> >
> > This topic ha
I support adoption and will review.
-Original Message-
From: Sean Turner
Sent: Tuesday, April 15, 2025 1:32 PM
To: TLS List
Subject: [EXTERNAL] [TLS] WG Adoption Call for Use of ML-DSA in TLS 1.3
CAUTION: This email originated from outside of the organization. Do not click
links or
I should have mentioned that I am willing to review...
> -Original Message-
> From: Sean Turner
> Sent: Monday, April 14, 2025 12:02 AM
> To: TLS List
> Subject: [TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key
> Agreement for TLS 1.3
>
> Just a reminder that this WG adoption call
This draft is being progressed now that -rfc8447bis, which creates “D” for the
Recommended column, has completed WGLC.
spt
> On Apr 14, 2025, at 3:11 PM, The IESG wrote:
>
>
> The IESG has received a request from the Transport Layer Security WG (tls) to
> consider the following document: - 'D
I am opposed to the adoption of ML-KEM at this time.
The main stated benefit of using a standalone ML-KEM is complexity
reduction, but with the current progress in the deployment of the ML-KEM +
ECC hybrid method, a standalone ML-KEM method actually increases overall
complexity in software stacks.
On Tue, Apr 15, 2025 at 10:33:23PM -, D. J. Bernstein wrote:
> Nico Williams writes:
> > there were no objections with technical reasons that were fatal to the
> > work in question
>
> I disagree. For example, the draft's regression from ECC+PQ to just PQ
> is certainly a technology issue; and
I think that Nico is right to identify that at its core the question for the WG
is one of policy, and Dan is right to look to the WG charter for guidance.
I see two parts of the charter that could cover this work -- "[t]his goal also
includes protocol changes that reduce TLS resource consumption w
To begin with, the call for adoption has not ended yet as there are
still a couple of hours left.
On Tue, Apr 15, 2025 at 08:57:47PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> “Consensus” is not about reaching no dissenters. It’s about the
> “prevailing” opinion of majority, which in this case
Hi Dan,
Draft adoption is based on rough consensus, not unanimous consent. As I'm
sure you're aware, RFC 7282 states that all objections do not need to be
accommodated for rough consensus to be achieved. In particular, the IETF
values running code, which this draft represents. It sounds like you'r
Blumenthal, Uri - 0553 - MITLL writes:
> âConsensusâ is not about reaching no dissenters.
Consensus doesn't require unanimity, but it does require fairly
considering and trying to resolve each objection---which is exactly what
the list records show didn't happen here.
Also, _if_ resolution fa
DJB's numbered points are fair.
There should be an answer for (1) (2) and (3) even if there isn't agreement.
thanks,
Rob
On Tue, Apr 15, 2025 at 3:18 PM D. J. Bernstein wrote:
> Blumenthal, Uri - 0553 - MITLL writes:
> > “Consensus” is not about reaching no dissenters.
>
> Consensus doesn't r
Nico Williams writes:
> there were no objections with technical reasons that were fatal to the
> work in question
I disagree. For example, the draft's regression from ECC+PQ to just PQ
is certainly a technology issue; and this is fatal, as a contravention
of the "improve security" goal in the WG c
Thank you, Bas! And to save time for those who don’t want to follow the NIST
mailing list trail – here’s the response from Leo Ducas posted there:
Dear All,
Thank you, Kevin, Charles, Yixin, Jean-Pierre for your careful analysis and
report.
While most of the points below are acknowledged in
54 matches
Mail list logo
