Those are all fascinating responses, thanks. But my main point was that I was
asking Stephen if he considers government regulations to be somehow different
from, say, industry ones.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to t
Paul Wouters writes:
> Responding as AD
Hmmm. I thought that a "person who disagrees with a Working Group
recommendation shall always first discuss the matter with the Working
Group's chair(s)", whereas AD involvement is only if "the disagreement
cannot be resolved in this way". This provides mult
>> “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.
I, for one, considered (I daresay) fairly your objections,
Hi Sean,
Thank you for considering my comments.
The proposed changes are ok for me.
I’m also ok with the last points given that these are only suggestions.
Regards,
Giuseppe
From: Sean Turner
Sent: Friday, April 11, 2025 6:10 PM
To: Giuseppe Fioccola
Cc: ops-...@ietf.org; draft-ietf-tls-rfc844
I support the adoption. Might be able to review it.
--
V/R,
Uri
From: tirumal reddy
Date: Wednesday, April 16, 2025 at 04:22
To: Sean Turner
Cc: TLS List
Subject: [EXT] [TLS] Re: WG Adoption Call for Use of ML-DSA in TLS 1.3
I support adoption and I will review it. -Tiru On Tue, 15 Apr
What I would like even more than WG adoption is code point registration in the
TLS SignatureScheme registry of ML-DSA and SLH-DSA. OpenSSL 3.5 Long-Term
Support (LTS) which shipped a week ago already implement all the algorithms
below. What are we waiting for?
Thank to the OpenSSL team for acti
I support adoption and am willing to review.
---
Mike Ounsworth
From: Watson Ladd
Sent: Wednesday, April 16, 2025 11:24:56 AM
To: Sean Turner
Cc: TLS List
Subject: [EXTERNAL] [TLS] Re: WG Adoption Call for Use of ML-DSA in TLS 1.3
I support adoption and will be
Internet-Draft draft-ietf-tls-mlkem-00.txt is now available. It is a work item
of the Transport Layer Security (TLS) WG of the IETF.
Title: ML-KEM Post-Quantum Key Agreement for TLS 1.3
Author: Deirdre Connolly
Name:draft-ietf-tls-mlkem-00.txt
Pages: 11
Dates: 2025-04-16
> Sure. On the same note – how do we know that there will be no new research
findings about ECC? (Besides the fact that once CRQC is built, it becomes
useless.)
Not useless. It would still be a good anti-ddos / cookies technique until each
phone is a CRQC.
The truth is probably somewhere in
> This is misleading. There are many implementations of Kyber that require
> much less memory. See eg [1] from 2019 where Kyber-512 only requires 2736
> bytes.
Thank you. Somehow I missed this, although the use of a reference
implementation seemed suspicious.
> By the way, for key agreement,
On Wed, Apr 16, 2025 at 10:38 AM Bellebaum, Thomas <
thomas.belleb...@aisec.fraunhofer.de> wrote:
> > This is misleading. There are many implementations of Kyber that
> require
> > much less memory. See eg [1] from 2019 where Kyber-512 only requires
> 2736
> > bytes.
>
> Thank you. Somehow I misse
> It might be fine to adopt this only for publication as Experimental.
There is actually another option for those that just want a stable reference.
Quoting from draft-ietf-tls-rfc8447bis:
> D: Indicates that the item is discouraged. This marking could be
> used to identify mechanisms that
I strongly support adoption. OpenSSL 3.5 LTS already support
draft-tls-westerbaan-mldsa. TLS is far more than the Web and the WebPKI. And
PKI is far more than CABF Baseline Requirements. Critical infrastructure like
telecom and national security systems will deploy PQC authentication soon.
Chee
[ Responding as AD, omitting disfunctional direct email address ]
On Tue, 15 Apr 2025, D. J. Bernstein wrote:
Date: Tue, 15 Apr 2025 15:53:51
From: D. J. Bernstein
To: tls@ietf.org
Subject: [TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for
TLS 1.3
Sean Turner writes:
I support adoption and will be willing to review.
On Tue, Apr 15, 2025 at 1:35 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 calls. If you support adoptio
Will the authors consider a section 6.4 on risks involved with
lattice-based structures ?
I like what Simon Josefsson used in one of his drafts:
"new research findings may be published at any time that may warrant
implementation reconsiderations".
Sure. On the same note – how do we know that the
On Wed, 16 Apr 2025 at 20:38, wrote:
>
> Internet-Draft draft-ietf-tls-mlkem-00.txt is now available. It is a work item
> of the Transport Layer Security (TLS) WG of the IETF.
>
>Title: ML-KEM Post-Quantum Key Agreement for TLS 1.3
>Author: Deirdre Connolly
>Name:draft-ietf-tls-
On Wed, Apr 16, 2025 at 10:57 AM Loganaden Velvindron
wrote:
> On Wed, 16 Apr 2025 at 20:38, wrote:
> >
> > Internet-Draft draft-ietf-tls-mlkem-00.txt is now available. It is a
> work item
> > of the Transport Layer Security (TLS) WG of the IETF.
> >
> >Title: ML-KEM Post-Quantum Key Agree
On Wed, 16 Apr 2025, Blumenthal, Uri - 0553 - MITLL wrote:
Sure. On the same note – how do we know that there will be no new research
findings about ECC? (Besides the fact that once CRQC is built, it becomes
useless.)
Not uselesss. It would still be a good anti-ddos / cookies technique until
> That’s easy to answer: “many of our members have very hardware-constrained
> PoS devices.” Is that okay?
Some context:
Kyber requires several KB of RAM space according to [1], figure 1:
KG = KeyGen, E=Encaps, D=Decaps, H=Heap, S=Stack
Alg | KG(H) | KG(S) | E(H) | E(S) | D(H) | D(S)
> For comparison, [2] is an implementation of Curve25519 using no heap space.
> On an ATmega128, it uses 462 bytes of stack space for a curve multiplication.
Small correction: Almost no heap space :)
It uses three 32-byte constants which could be reconstructed dynamically.
Those being: The numbe
On Wed, Apr 16, 2025 at 10:15 AM Bellebaum, Thomas <
thomas.belleb...@aisec.fraunhofer.de> wrote:
> > That’s easy to answer: “many of our members have very
> hardware-constrained PoS devices.” Is that okay?
>
> Some context:
>
> Kyber requires several KB of RAM space according to [1], figure 1:
>
I support adoption and I will review it.
-Tiru
On Tue, 15 Apr 2025 at 23:04, 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 calls. If you support adoption and
On Wed, 16 Apr 2025, D. J. Bernstein wrote:
Hmmm. I thought that a "person who disagrees with a Working Group
recommendation shall always first discuss the matter with the Working
Group's chair(s)", whereas AD involvement is only if "the disagreement
cannot be resolved in this way". This pro
24 matches
Mail list logo