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
FWIW and probably not relevant, DoD CAC has never used DSA.
FORTEZZA used DSA.
-Original Message-
From: Alicja Kario [mailto:hka...@redhat.com]
Sent: Monday, December 9, 2024 2:23 PM
To: D. J. Bernstein
Cc: tls@ietf.org
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
On Satur
+1
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Friday, November 15, 2024 11:41 AM
To: Bas Westerbaan ; tls@ietf.org
Subject: [TLS] Re: ML-DSA in TLS
On 15/11/2024 10:51, Bas Westerbaan wrote:
> We have posted a -00.
>
> https://datatracker.ietf.or
+1. I almost sent an e-mail largely saying the same over the weekend.
Russ’s draft had a flaw which he agreed to fix if there was further interest.
And that never came about. I do not exactly remember what the problem was, but
I will be happy to review what the authors write to recall if t
I do not think you can change an extension syntax or semantic. It is three
tuple: extn ID, criticality flag, and value.
You can add the syntax and semantics within the extension value as to what
it means. That may not help those who do not understand the extension and
cannot process the val
To me it seems that both of these wordings could be interpreted by someone
that if you do not have a trust anchor and you get it in the TLS handshake,
you can use it and trust it.
That sounds dangerous.
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett
S
