Re: [TLS] Obscure ciphers in TLS 1.3

> -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 >

Re: [TLS] Data volume limits

t; > On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) > > <sfluh...@cisco.com <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

Re: [TLS] Data volume limits

> -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,

Re: [TLS] Data volume limits

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

Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?

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

Re: [TLS] RSA-PSS in TLS 1.3

> -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

Re: [TLS] RSA-PSS in TLS 1.3

> -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

Re: [TLS] (TLS1.3 - algorithm agility support is enough; no need to crystal ball gaze PQ right now, except as pass-time) Re: RSA-PSS in TLS 1.3

. 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 gaze PQ right now, except as pass-time) Re: [TLS] RSA-PSS in TLS 1.3

Re: [TLS] RSA-PSS in TLS 1.3

> -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

Re: [TLS] removing 128-bit ciphers in TLS 1.3

> -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 > >

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

> -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

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

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:

[TLS] Question about unrecognized extension types in the TLS 1.3 client hello message

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

Re: [TLS] The alternative idea I had for token buckets.

> -Original Message- > From: Martin Thomson [mailto:martin.thom...@gmail.com] > Sent: Tuesday, March 28, 2017 11:46 AM > To: Scott Fluhrer (sfluhrer) > Cc: <tls@ietf.org> > Subject: Re: [TLS] The alternative idea I had for token buckets. > > On 28 Marc

[TLS] The alternative idea I had for token buckets.

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

Re: [TLS] The alternative idea I had for token buckets.

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: <tls@ietf.org>

Re: [TLS] The alternative idea I had for token buckets.

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: <tls@ietf.org> > Subject: Re: [TLS] Th

Re: [TLS] AdditionalKeyShare Internet-Draft

> -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 >

[TLS] Comments on draft-stebila-tls-hybrid-design-00

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

[TLS] Options for negotiating hybrid key exchanges for postquantum

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

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

, 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 about postquantum

[TLS] SIKE vs SIDH (was Options for negotiating hybrid key exchanges for postquantum)

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

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

> -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

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

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 >

Re: [TLS] DH security issue in TLS

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

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

> -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

Re: [TLS] DH generator 2 problem?

> -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

Re: [TLS] TLS Opaque

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

[TLS] Comments on draft-friel-tls-eap-dpp-01

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

[TLS] Comment on draft-sullivan-tls-opaque-00

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

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

> 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

Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

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

Re: [TLS] Revised hybrid key exchange draft

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 {

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

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

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

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

Re: [TLS] whitepaper from ambit inc

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

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

> -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,

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

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

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

> -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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

:13:38PM +, 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 > > > Sent: Sa

Re: [TLS] New Version Notification for draft-mattsson-tls-compact-ecc-00.txt

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

Re: [TLS] CRYSTALS Kyber and TLS

age- > 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 are de

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

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

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

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

Re: [TLS] Key Update for TLS/DTLS 1.3

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

[TLS] A suggestion for handling large key shares

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

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

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

[TLS]Re: Curve-popularity data?

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

[TLS]Re: Curve-popularity data?

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

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

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: