I recently reviewed the most recent TLS 1.3 draft, and I must say that I am
impressed; the protocol appears to be a significant improvement. In
particular, you simplify the protocol significantly, and as we all know,
complexity is the enemy of security. You also drop many of the weak options,
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett
> Sent: Wednesday, September 23, 2015 6:41 PM
> To: tls@ietf.org
> Subject: [TLS] Obscure ciphers in TLS 1.3
>
> https://tlswg.github.io/tls13-spec/#cipher-suites
> https://www.iana.org/assignments/tl
Might I enquire about the cryptographical reason behind such a limit?
Is this the limit on the size of a single record? GCM does have a limit
approximately there on the size of a single plaintext it can encrypt. For TLS,
it encrypts a record as a single plaintext, and so this would apply to
e
> -Original Message-
> From: Watson Ladd [mailto:watsonbl...@gmail.com]
> Sent: Tuesday, December 15, 2015 5:38 PM
> To: Scott Fluhrer (sfluhrer)
> Cc: Eric Rescorla; tls@ietf.org
> Subject: Re: [TLS] Data volume limits
>
> On Tue, Dec 15, 2015 at 5:01 PM,
t; > On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer)
> > mailto:sfluh...@cisco.com>> wrote:
> > The quadratic behavior in the security proofs are there for just
> > about any block cipher mode, and is the reason why you want to stay
> > well b
I would also suggest keeping PSK 0RTT.
On of the things I'm looking at is postquatum cryptography (that is,
cryptography that would still be secure even if someone manages to build a
large quantum computer). While this is not the most important issue that TLS
1.3 needs to deal with; it's proba
> -Original Message-
> From: TLS On Behalf Of Michael D'Errico
> Sent: Thursday, October 08, 2020 1:54 PM
> To: TLS List
> Subject: [TLS] DH generator 2 problem?
>
> Using finite-field Diffie-Hellman with a generator of 2 is probably not the
> best
> choice. Unfortunately all of the pu
I am glad that someone in the working group is looking at this. However, as I
reviewed this before the wg meeting, I was completely puzzled by this text
(from section 6.1):
3DH
C computes K = H(g^y ^ PrivU || PubU ^ x || PubS ^ PrivU || IdU || IdS )
S computes K = H(g^x ^ PrivS || PubS ^
Again, last minute reviews...
It would appear that the exact computations that both the client and the server
need to perform needs to be explicitly spelled out, as there are several
possibilities.
Here is the one I could see that appear to have the security properties that
you appear to be lo
On Tue, Mar 30, 2021 at 9:39 PM Joseph Salowey
mailto:j...@salowey.net>> wrote:
There is at least one question on the list that has gone unanswered for some
time [1].
[1] https://mailarchive.ietf.org/arch/msg/tls/yCBYp10QuYPSu5zOoM3v84SAIZE/
I've found most of the OPAQUE drafts are pretty con
> Was it wrong to generate server-side DH parameters?
The problem is that it is hard for the client to distinguish between a well
designed server vs a server that isn't as well written, and selects the DH
group in a naïve way.
For example, if the server just selects a random prime and a random
There are a number of postquantum algorithms (e.g. NTRU, Falcon, Dilithium)
that require considerably smaller key shares/signatures - we're talking about
the 1k-2k range. It would sounds reasonable that an MCU implementation might
want to consider those algorithms, if they are more suitable for
From: TLS On Behalf Of Eric Rescorla
Sent: Tuesday, January 11, 2022 4:01 PM
To: Douglas Stebila
Cc:
Subject: Re: [TLS] Revised hybrid key exchange draft
…
With that said, defense in depth is good. Does it help to have just a
structured input, e.g.,
opaque KeyInput<0..2^16-1>;
struct {
Now, we have done some initial work on postquantum extensions for TLS for
privacy; the (now expired, soon to be refreshed) draft
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
Might I suggest that any comments you make be in reference to that draft? I
don’t mind if you disagree
> -Original Message-
> From: TLS On Behalf Of Blumenthal, Uri - 0553 -
> MITLL
> Sent: Sunday, August 7, 2022 1:32 PM
> To: Phillip Hallam-Baker
> Cc: TLS@ietf.org
> Subject: Re: [TLS] Before we PQC... Re: PQC key exchange sizes
>
> > > I thought a Quantum Annoyance was someone who keeps
Sorry for the late response; I was going through old emails and came across
this; I thought it warranted a response
> -Original Message-
> From: TLS On Behalf Of Ilari Liusvaara
> Sent: Saturday, April 30, 2022 5:05 AM
> To: TLS@ietf.org
> Subject: Re: [TLS] WGLC for draft-ietf-tls-hybri
Again, this is late, however Stephen did ask this to be discussed in the
working group, so here we go:
> -Original Message-
> From: TLS On Behalf Of Stephen Farrell
> Sent: Saturday, April 30, 2022 11:49 AM
> To: Ilari Liusvaara ; TLS@ietf.org
> Subject: Re: [TLS] WGLC for draft-ietf-tls
Again, responding to old emails...
> -Original Message-
> From: TLS On Behalf Of Stephen Farrell
> Sent: Friday, April 29, 2022 8:25 PM
> To: TLS@ietf.org
> Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
>
> - section 2: if "classic" DH were broken, and we then depend on a PQ-K
at 06:13:38PM +0000, Scott Fluhrer (sfluhrer) wrote:
> > Again, this is late, however Stephen did ask this to be discussed in the
> working group, so here we go:
> >
> > > -Original Message-
> > > From: TLS On Behalf Of Stephen Farrell
> > > Sen
> -Original Message-
> From: TLS On Behalf Of Martin Thomson
> Sent: Wednesday, August 17, 2022 7:05 PM
> To: tls@ietf.org
> Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
>
> On Sat, Aug 13, 2022, at 04:13, Scott Fluhrer (sfluhrer) wrote:
> > Well,
It looks good; just one comment:
The current draft says (section 3.2)
A full validation according to Section 5.6.2.3.3 of
[SP-800-56A] can be achieved by also checking that 0 ≤ x < p and that
y^2 ≡ x^3 + a ⋅ x + b (mod p)
(emphasis added).
I believe such a validation check should be mandato
My opinion: since NIST has announced that “Kyber768 Rounds 3 != The final NIST
approved version”, we should keep codepoint 0x6399 with its current meaning,
and allocate a fresh one when NIST does public the Kyber FIPS draft (which is
likely, but not certainly, what will be the final FIPS approve
Message-
> From: Stephan Müller
> Sent: Monday, June 19, 2023 4:24 AM
> To: TLS List ; dsteb...@uwaterloo.ca; Scott Fluhrer (sfluhrer)
> ; shay.gue...@gmail.com
> Subject: CRYSTALS Kyber and TLS
>
> Hi,
>
> Post-quantum computing cryptographic algorithms a
Why would TLS require triple AES?
If you’re worried that Grover’s attack reduces the strength of AES-256 to 128
bits, well, yes it does – unless we are extremely impatient. If the attacker
insists that the attack succeeds before, say, the Sun turns into a red giant,
running Grover’s on a singl
The problem with the argument “X trusts Kyber, so we don’t need hybrid” (where
X can be “NIST” or “the speaker”) is that trust, like beauty, is in the eye of
the beholder. Just because NIST (or any other third party) is comfortable with
just using Kyber (or Dilithium) does not mean that everyon
mischaracterize one of them)?
If there is some demand and the cost is reasonable (albeit not “essentially
free”), I don’t see a reason not to include it as an option.
From: Yoav Nir
Sent: Tuesday, November 7, 2023 11:36 AM
To: Scott Fluhrer (sfluhrer)
Cc: Watson Ladd ; Kris Kwiatkowski
; Bas
We had that argument several IETF's ago (IETF 105?), and the clear consensus of
the working group was that explicit named hybrid combinations (e.g. one for
ML-KEM-512 + X25519) was the way to go.
Do we want to reopen that argument? Now, I was on the other side (and I still
think it would be a
Here's an issue I see with postquantum exchanges; Kyber (and most other
postquantum key exchanges) would have an issue with the current format. There
are distinct 'initiate key shares' and 'response key shares', and they're not
interchangeable; a 'response key share' must be generated for a spe
I can’t say I agree with this argument.
If we have a combiner with a proof that “if either of the primitives we have
meet security property A, then the output of the combiner meets security
property B”, and we have proofs that both our primitives meet security property
A”, then doesn’t that mea
First of all, I would say that this is excellent work, and I would support
making this a working group item.
As for my comments (both on the document itself, and my opinions on
alternatives that the document lists):
* 2.1. Negotiation of the use of hybridization in general and component
a
During the physical meeting in Montreal, we had a discussion about postquantum
security, and in particular, on how one might want to negotiate several
different 'groups' simultaneously (because there might not be one group that is
entirely trusted, and I put 'groups' in scarequotes because postq
From: Watson Ladd
> On Tue, Jul 30, 2019, 8:21 AM Scott Fluhrer (sfluhrer)
> <mailto:sfluh...@cisco.com> wrote:
>> During the physical meeting in Montreal, we had a discussion about
>> postquantum security, and in particular, on how one might want to negotiate
>
dful of options, regardless of the encoding..
On Tue, Jul 30, 2019 at 12:18 PM Watson Ladd
mailto:watsonbl...@gmail.com>> wrote:
On Tue, Jul 30, 2019, 8:21 AM Scott Fluhrer (sfluhrer)
mailto:sfluh...@cisco.com>> wrote:
During the physical meeting in Montreal, we had a discussion abou
about any other exchange); however the current proofs for TLS 1.3 make this
assumption, even if you use a private key only once.
From: Blumenthal, Uri - 0553 - MITLL
Sent: Tuesday, July 30, 2019 3:41 PM
To: Panos Kampanakis (pkampana) ; Scott Fluhrer (sfluhrer)
;
Subject: Re: [TLS] Options for
> -Original Message-
> From: Stephen Farrell
> Sent: Tuesday, July 30, 2019 3:53 PM
> To: Scott Fluhrer (sfluhrer) ; Watson Ladd
>
> Cc: TLS List
> Subject: Re: [TLS] Options for negotiating hybrid key exchanges for
> postquantum
>
>
> I'm neutral
See SRF
From: TLS On Behalf Of Pascal Urien
Sent: Tuesday, December 03, 2019 5:16 PM
To: tls@ietf.org
Subject: [TLS] DH security issue in TLS
I wonder if g**x , with x =(1-p)/2 is checked in current TLS 1.2 implementation
?
In RFC https://tools.ietf.org/html/rfc7919
"Negotiated Finite Field Di
> -Original Message-
> From: TLS On Behalf Of Russ Housley
> Sent: Friday, February 21, 2020 2:29 PM
> To: Martin Thomson
> Cc: IETF TLS
> Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-
> hybrid-design
>
>
>
> > On Feb 12, 2020, at 6:22 PM, Martin Thomson
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Nikos
> Mavrogiannopoulos
> Sent: Friday, March 04, 2016 3:10 AM
> To: Hanno Böck; Blumenthal, Uri - 0553 - MITLL; tls@ietf.org
> Subject: Re: [TLS] RSA-PSS in TLS 1.3
>
> On Thu, 2016-03-03 at 17:11 +0100, Hanno
> -Original Message-
> From: Hubert Kario [mailto:hka...@redhat.com]
> Sent: Monday, March 07, 2016 6:43 AM
> To: tls@ietf.org
> Cc: Scott Fluhrer (sfluhrer); Nikos Mavrogiannopoulos; Hanno Böck;
> Blumenthal, Uri - 0553 - MITLL
> Subject: Re: [TLS] RSA-PSS in TLS
> -Original Message-
> From: Nikos Mavrogiannopoulos [mailto:n...@redhat.com]
> Sent: Monday, March 07, 2016 8:42 AM
> To: Scott Fluhrer (sfluhrer); Hanno Böck; Blumenthal, Uri - 0553 - MITLL;
> tls@ietf.org
> Subject: Re: [TLS] RSA-PSS in TLS 1.3
>
> On Fri, 2
From: Tony Arcieri [mailto:basc...@gmail.com]
Sent: Monday, March 07, 2016 11:40 AM
To: Scott Fluhrer (sfluhrer)
Cc: Nikos Mavrogiannopoulos; Hanno Böck; Blumenthal, Uri - 0553 - MITLL;
tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3
On Mon, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluhrer
n
either our protocol or in our proofs) this additional functionality.
From: Rene Struik [mailto:rstruik....@gmail.com]
Sent: Monday, March 07, 2016 2:49 PM
To: Scott Fluhrer (sfluhrer); Tony Arcieri
Cc: tls@ietf.org
Subject: (TLS1.3 - algorithm agility support is enough; no need to crystal ball
> -Original Message-
> From: Hubert Kario [mailto:hka...@redhat.com]
> Sent: Monday, March 07, 2016 12:18 PM
> To: Scott Fluhrer (sfluhrer)
> Cc: tls@ietf.org; Nikos Mavrogiannopoulos; Hanno Böck; Blumenthal, Uri -
> 0553 - MITLL
> Subject: Re: [TLS] RSA-PSS in TLS
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Fedor Brunner
> Sent: Thursday, May 12, 2016 4:10 AM
> To: tls@ietf.org
> Subject: [TLS] removing 128-bit ciphers in TLS 1.3
>
> Because of this attacks:
>
> https://blog.cr.yp.to/20151120-batchattacks.html
>
>
Actually, a more correct way of viewing the limit would be 2^52 encrypted data
bytes. To come to the 2^38 record limit, they assume that each record is the
maximum 2^14 bytes. Of course, at a 1Gbps rate, it'd take over a year to
encrypt that much data...
> -Original Message-
> From: TL
> -Original Message-
> From: Paterson, Kenny [mailto:kenny.pater...@rhul.ac.uk]
> Sent: Tuesday, July 12, 2016 1:17 PM
> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; tls@ietf.org
> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
>
> Hi
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Hubert Kario
> Sent: Thursday, September 01, 2016 2:17 PM
> To: Benjamin Kaduk
> Cc:
> Subject: Re: [TLS] SHA-3 in SignatureScheme
>
> On Thursday, 1 September 2016 12:43:31 CEST Benjamin Kaduk wrote:
> > On 09/0
My question: in TLS 1.3, if the client inserts an extension of a type that the
server does not recognize, how must the server behave? Is it required that the
server just ignore the extension, or can it take some other action (e.g. ignore
the client hello)?
Background (why I'm asking): one of t
Here's how it would work:
- The server has a long term secret key K, which it never gives out
- When the server wants to give a token to a client, it picks a random
value R, and securely gives the client the values R and E_K(R)
- When the client wants to use the toke
E_K(R); that is, R is encrypted with the server's long term key.
(I meant to specify that...)
> -Original Message-
> From: Martin Thomson [mailto:martin.thom...@gmail.com]
> Sent: Tuesday, March 28, 2017 11:37 AM
> To: Scott Fluhrer (sfluhrer)
> Cc:
> Subject: Re
> -Original Message-
> From: Martin Thomson [mailto:martin.thom...@gmail.com]
> Sent: Tuesday, March 28, 2017 11:46 AM
> To: Scott Fluhrer (sfluhrer)
> Cc:
> Subject: Re: [TLS] The alternative idea I had for token buckets.
>
> On 28 March 2017 at 10:41, Scott Flu
Sorry, I wasn't aware that unlinkability was a requirement...
> -Original Message-
> From: Martin Thomson [mailto:martin.thom...@gmail.com]
> Sent: Tuesday, March 28, 2017 11:51 AM
> To: Scott Fluhrer (sfluhrer)
> Cc:
> Subject: Re: [TLS] The alternative idea
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Douglas Stebila
> Sent: Monday, April 17, 2017 2:24 PM
> To:
> Subject: [TLS] AdditionalKeyShare Internet-Draft
>
> Dear TLS mailing list,
>
> We have posted an Internet-Draft
> https://tools.ietf.org/html/d
Recently, Matt Campagna emailed the hybrid KEM group (Douglas, Shay and me)
about a suggestion about one way to potentially improve the performance (in the
'the server hasn't upgraded yet' case), and asked if we should add that
suggestion to our draft. It occurs to me that this suggestion is eq
I would disagree; it does have implications on the TLS protocol.
This working group does make the call as to which combinations it would like to
specify in an RFC and generate TLS code points for; be it:
* P256 + ML-KEM-768
* X25519 + MK-KEM-768
* Some other combination
And, as it
If we’re talking about CNSA, well CNSA 2.0 insists on ML-KEM-1024 (and would
prefer that alone) – I had been assuming that could be better handled by the
ML-KEM-only draft…
From: John Mattsson
Sent: Wednesday, June 5, 2024 1:56 AM
To: tls@ietf.org
Subject: [TLS]Re: [EXTERNAL] Re: Curve-populari
on hybrid crypto, they’d go along.
Hence, I don’t believe that CNSA 2.0 is taking quite as hard of a stand as the
summary states…
From: John Mattsson
Sent: Wednesday, June 5, 2024 11:52 AM
To: Watson Ladd ; Andrei Popov
Cc: Blumenthal, Uri - 0553 - MITLL ; Scott Fluhrer (sfluhrer)
; tls
Does X448 actually provide "a huge advantage" in security (practically
speaking) over X25519?
On a classical computer, the best known attack against X25519 requires circa
2^126 point addition operations - that is generally accepted as being
infeasible. Attacking X448 requires far more point ad
> -Original Message-
> From: ilariliusva...@welho.com
> Sent: Thursday, October 24, 2024 1:03 PM
> To:
> Subject: [TLS] Re: ML-DSA in TLS
>
> On Thu, Oct 24, 2024 at 03:51:50PM +, Tim Hollebeek wrote:
> > 3. Composite is slightly more complicated, though not as complicated as its
I've been called out on this, and so I need to apologize
> -Original Message-
> From: Scott Fluhrer (sfluhrer)
> Sent: Thursday, October 24, 2024 2:18 PM
> To: ilariliusva...@welho.com;
> Subject: [TLS] Re: ML-DSA in TLS
>
>
> Is there some complexity th
In my opinion, we’ll end up standardizing both. At the very least, I (Cisco)
have some customers who want ML-DSA only, and other customers that insist on
hybrid, and so we’ll need to support both.
Standardizing ML-DSA only appears to be straightforward – we just need to
assign some code words,
iginal Message-
> From: Scott Fluhrer (sfluhrer)
> Sent: Saturday, November 23, 2024 8:46 AM
> To: ilariliusva...@welho.com; tls@ietf.org
> Subject: [TLS] Re: [EXT] Re: ML-DSA in TLS
>
>
>
> > -Original Message-
> > From: ilariliusva...@welho.com
> >
Might I remind people the ML-KEM public key reuse is detectable?
The ML-KEM public key is in the client hello, which is either in the clear, or
(in the case of ECH) is readable by the server. Hence, if the same ML-KEM is
reused, then (in the worse case) the server can detect that.
And, if it i
can think of
that a client would want to do key reuse.
From: Richard Barnes
Sent: Monday, December 16, 2024 9:11 AM
To: Scott Fluhrer (sfluhrer)
Cc: Alicja Kario ; Christian Huitema ;
Andrei Popov ; IETF TLS
Subject: Re: [TLS] Re: [EXTERNAL] Disallowing reuse of ephemeral keys
You’re
Open questions about ephemeral key reuse (and I don't know the answers; that's
why they're open questions) - the answers to these questions may help us guide
us as to whether to forbid it or not:
- To what extent do the proofs of security for TLS 1.3 depend on the non-reuse
of key shares (eithe
> -Original Message-
> From: D. J. Bernstein
> Sent: Thursday, November 21, 2024 10:06 AM
> To: tls@ietf.org
> Subject: [TLS] Re: ML-DSA in TLS
>
> Scott Fluhrer (sfluhrer) writes:
> > Might I ask what are we arguing about?
>
> This thread is on a
Might I ask what are we arguing about? Does the TLS working group feel the
need to prohibit pure ML-DSA as authentication? Even though, after Q-day
happens (whenever that will be), that might be what people want?
If you go through the TLS ML-DSA draft, all they do is define three code points
> -Original Message-
> From: ilariliusva...@welho.com
> Sent: Saturday, November 23, 2024 3:44 AM
> To: tls@ietf.org
> Subject: [TLS] Re: [EXT] Re: ML-DSA in TLS
>
>
> But with signatures, the risks become substantial because:
>
> - Complexity. Some of it to deal with known non-obviou
trict compliance with CNSA 2.0, then there is no issue from my
perspective, but that's a (mildly) controversial part.
On Fri, Dec 6, 2024 at 9:29 AM D. J. Bernstein
mailto:d...@cr.yp.to>> wrote:
Scott Fluhrer (sfluhrer) writes:
> I understand that people want to discuss the hybrid KEM dr
> Which one? Yours or Panos et al? :)
I don’t care – we just need something reasonable, and those both qualify…
From: Salz, Rich
Sent: Friday, December 6, 2024 5:58 PM
To: Scott Fluhrer (sfluhrer) ; Andrey Jivsov
; TLS@ietf.org
Subject: Re: [TLS] Re: draft-connolly-tls-mlkem-key-agreem
How do we proceed with this draft?
This draft is quite boring (which is good from a cryptographical perspective);
it just says 'take ML-KEM and insert it as a key agreement into TLS in the
obvious way'.
I understand that people want to discuss the hybrid KEM draft more (because
there are more
: Monday, December 23, 2024 4:26 PM
To: Scott Fluhrer (sfluhrer)
Cc: John Mattsson ; Loganaden
Velvindron ; TLS List
Subject: Re: [TLS] Re: PQ Cipher Suite I-Ds: adopt or not?
Hi all, since I am still on the CC list,
I took the question to be about how to organize the work. If everything is a
TL;DR: Historical notes: not important for the current discussion.
To be clear about whether Cisco (or actually, me – I don’t actually speak for
Cisco, but I like to think they listen to my advice) preferred NTRU or NTRU
Prime – I actually didn’t have a strong opinion. I advocated NTRU because
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 went through the PAKE draft on TLS 1.3, and while I certainly appreciate the
use of a PAKE within TLS, I would like to highlight one potential security
issue that the working group needs to be aware of.
The draft has SPAKE2+ as its sole defined parameter set; SPAKE2+ has a rather
interesting
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 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
I support adoption (and I am willing to review)
> -Original Message-
> From: Sean Turner
> Sent: Wednesday, February 26, 2025 1:26 PM
> To: TLS List
> Subject: [TLS] WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key
> Agreement for TLSv1.3
>
> At IETF 121, the WG discussed “Post-
.
And, I cannot recommend endorsing a PAKE where solving a single discrete log
problem breaks the system globally, given there are other PAKE protocols that
do not have this vulnerability.
________
From: Michael Rosenberg
Sent: Thursday, May 29, 2025 12:03 PM
To: Scot
orla
Sent: Thursday, June 19, 2025 11:35 AM
To: Scott Fluhrer (sfluhrer)
Cc: Yaroslav Rosomakho ; TLS List
Subject: Re: [TLS] Re: [External⚠️] Re: [EXT] Re: [EXTERNAL] Re: Dual
certificates in TLS proposal
On Thu, Jun 19, 2025 at 6:03 AM Scott Fluhrer (sfluhrer)
mailto:sfluh...@cisco.c
Actually, allowing such combinations might actually be useful. For example:
first_signature_algorithm = [ECDSA-P256, SLH-DSA]
second_signature_algorithm = [ML-DSA, SLH-DSA]
Which would effectively convey that the client would be happy with either a
single SLH-DSA signature OR a combination of E
The normative portion of this draft (sections 4, 5) is pretty boring (in the
best possible way); it pretty much says "insert ML-KEM into TLS in the obvious
way, and use these code points".
On a minor note: when talking about failures (5.2), well, yes, decryption
failure (that is, both sides do
I support the adoption call, and I am willing to review.
From: Sean Turner
Sent: Monday, July 28, 2025 10:56 AM
To: TLS List
Subject: [TLS] Re: WG Adoption Call for A PAKE Extension for TLS 1.3
> On Jul 24, 2025, at 03:01, Sean Turner wrote:
>
> At IETF 122 &
I am in favor of adoption.
Obligatory bias notice: I am a coauthor...
From: Sean Turner
Sent: Friday, July 25, 2025 3:26 AM
To: TLS List
Subject: [TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3
Hi! Just a reminder that this call closes on Monday
84 matches
Mail list logo
