Re: [TLS] Data volume limits

On 12/15/2015 04:08 PM, Henrick Hellström wrote: > On 2015-12-16 00:48, Eric Rescorla wrote: >> >> >> 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 ciph

Re: [TLS] Data volume limits

On 12/15/2015 03:47 PM, Watson Ladd wrote: On Dec 15, 2015 6:08 PM, "Scott Fluhrer (sfluhrer)" mailto:sfluh...@cisco.com>> wrote: > > > > > -Original Message- > > From: Watson Ladd [mailto:watsonbl...@gmail.com ] > > Sent: Tuesday, December 15, 2015 5:3

[TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the following language in sec 4.8.1 In RSA signing, the opaque vector contains the signature generated using the RSASSA-PSS signature scheme defined in [RFC3447 ] with MGF1. The d

Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

On 01/22/2016 03:14 AM, Hubert Kario wrote: On Thursday 21 January 2016 18:25:00 Andrey Jivsov wrote: Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the following language in sec 4.8.1 In RSA signing, the opaque vector contains the signature generated using

Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

On 01/25/2016 03:11 PM, Russ Housley wrote: On Jan 25, 2016, at 2:43 PM, Hubert Kario wrote: On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote: On 01/22/2016 01:14 PM, Hubert Kario wrote: On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote: On 01/22/2016 03:14 AM, Hubert Kario

Re: [TLS] RSA-PSS in TLS 1.3

On 02/29/2016 09:32 AM, Joseph Salowey wrote: We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5 in TLS 1.3. However, there is a problem that it may take some hardware implementations some time to move to RSA-PSS. After an off list discussion with a few folks here is a

Re: [TLS] RSA-PSS in TLS 1.3

On 02/29/2016 09:32 AM, Joseph Salowey wrote: > We seem to have good consensus on moving to RSA-PSS and away from > PKCS-1.5 in TLS 1.3. However, there is a problem that it may take some > hardware implementations some time to move to RSA-PSS. After an off > list discussion with a few folks here

Re: [TLS] RSA-PSS in TLS 1.3

On 02/29/2016 02:36 PM, Hanno Böck wrote: We have an RFC for PSS since 2003. We had several attacks showing the weakness of PKCS #1 1.5. In the face of such danger, what's your opinion on PKCS #1.5 signatures being perfectly fine in TLS 1.3 ? I refer to signatures in X.509 certs in the latest

Re: [TLS] Point Compression

I propose a method to compress NIST curves as defined in https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html Its main benefit is that the compressed point fits into field size / group order size. There is no additional byte needed. This encoding is enabled by by modifying key generation. I

Re: [TLS] Point Compression

Do we have evidence that "02 " or "03 " is more widespread than for NIST curves? I haven't seen "02 " or "03 " in deployed products in TLS / X.509 at all. So, I feel that for TLS space the slate is clean regarding compression. X25519 uses one coordinate, which is simiiar to doing for NIST curves.

Re: [TLS] Point Compression

se one of the > values "02" and "03" or flip a coin. If you have support of 'regular' > (SEC1) compressed curves, then compact representation is trivial. > > > > Cheers, > > John > > > > *From: *TLS on behalf of Andrey Jivsov < > cry

Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

This is similar to the case when a server is unable to use its RSA key to sign with PSS passing (my slides for TLS WG in 2015 https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf , presented by Eric), but instead this is about client keys/signatures. I don't have a stake in this currentl

Re: [TLS] ML-KEM key agreement for TLS 1.3

> > I would treat non-hybrid drafts in IETF the same way > as "export" options in code: they're security risks. I would encourage > explicit withdrawal of any such drafts. Does this point apply in your opinion to hash-based signatures? ___ TLS mailing l

[TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

Greetings. TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client wants to negotiate TLS 1.3, it must support an upgraded (and incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms. You might recall that the poss

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On 05/29/2018 12:13 PM, Benjamin Kaduk wrote: > On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: >> Greetings. >> >> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client >> wants to negotiate TLS 1.3, it must support an upgraded (and

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On 05/29/2018 12:42 PM, Benjamin Kaduk wrote: > On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote: >> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote: >>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote: >>>> Greetings. >>>> &

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

egotiate TLS 1.3. Does this "upgrade" to TLS 1.2 extends to client authentication? Then this adds more work. There can be a performance penalty with RSA-PSS v.s. RSA legacy and more issues when private keys are used in client authentication (because e.g. they are HSM keys). >

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On 05/29/2018 01:58 PM, David Benjamin wrote: > On Tue, May 29, 2018 at 4:26 PM Andrey Jivsov <mailto:cry...@brainhub.org>> wrote: > > On 05/29/2018 01:07 PM, David Benjamin wrote: > > I'm not sure I follow this. So, in this scenario, you are the client. &g

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On 05/29/2018 06:17 PM, Martin Thomson wrote: > On Wed, May 30, 2018 at 7:20 AM Andrey Jivsov wrote: >> The issue here is that some hardware devices don't implement RSA CRT >> method with PSS, because they hard-wide RSA, legacy padding, and CRT >> method in one opera

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On 05/29/2018 10:13 PM, Martin Thomson wrote: > On Wed, May 30, 2018 at 2:53 PM Andrey Jivsov wrote: >> The quoted text quoted is old. The need to upgrade TLS 1.2 code if I >> support TLS 1.3 is new. > No, I'm certain we had that discussion too. > >> I am curious

[TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation

Greetings. it's unclear to me how is the shared secret g^xy calculated for groups in https://tools.ietf.org/html/rfc7919 . If you recall, the TLS 1.1 uses this method the https://tools.ietf.org/html/rfc4346#section-8.1.2 , causing some interoperability problems that are hard to fix. The RFC 7919

Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation

TLS 1.2. TLS 1.3 is free to use the more > sound method and does: > https://tools.ietf.org/html/rfc8446#section-7.4.1 > > On Tue, Feb 19, 2019 at 6:10 PM Andrey Jivsov <mailto:cry...@brainhub.org>> wrote: > > Greetings. > > it's unclear to me how is the

Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

Regarding PKCS 1.5 in TLS 1.3, please also see slide 4 for a year 2015 version of the same motivation https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf . On 7/29/19 5:15 PM, David Benjamin wrote: > Hi all, > > I’ve just uploaded a pair of drafts relating to signatures in TLS 1.3. > h

Re: [TLS] DH security issue in TLS

https://tools.ietf.org/html/rfc7919#section-5.1 prohibits x=(p-1)/2 because this results in a peer's public key g^x= 1. Allowing this makes some man-in-the middle attacks on TLS easier, because the attacker can predict the value of the ephemeral secret key on another leg of the connection. On Tue

Re: [TLS] RSA-PSS in TLS 1.3

On 03/01/2016 11:20 AM, Yoav Nir wrote: On 1 Mar 2016, at 8:23 PM, Alyssa Rowan wrote: [YN] It would be cool to ban PKCS#1.5 from certificates, but we are not the PKIX working group. Nor are we the CA/Browser forum. When a CA issues a certificate it has to work with every client and server ou

Re: [TLS] RSA-PSS in TLS 1.3

On 07/06/2016 10:23 AM, Joseph Salowey wrote: > I don't think we ever call consensus on this topic. It looks like there > is rough consensus to move forward with RSA-PSS as the MUST implement > algorithm for certificate verify in TLS 1.3 and not allow PKCS-1.5. > During the discussion it also se

Re: [TLS] Confirming consensus: TLS1.3->TLS*

On 11/17/2016 06:12 PM, Sean Turner wrote: At IETF 97, the chairs lead a discussion to resolve whether the WG should rebrand TLS1.3 to something else. Slides can be found @ https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. The consensus in the room was to l

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

I also think that counting in blocks is cleaner. Counting in bytes is a close alternative. I have a few nits below: On 03/02/2017 01:44 PM, Brian Smith wrote: > Aaron Zauner wrote: >> I'm not sure that text on key-usage limits in blocks in a spec >> that fundamentally deals in records is less co

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

On 03/02/2017 05:54 PM, Hal Murray wrote: > > cry...@brainhub.org said: >> I also think that counting in blocks is cleaner. Counting in bytes is a >> close alternative. > > Does counting bytes work? If the real limit is blocks, I think you will have > to round up the byte count when you send

[TLS] Improved nonce generation method for TLS 1.3

Greetings. I would like to suggest a small tweak to the nonce generation method in TLS 1.3. The motivation for this is stronger separation between the encryption layer and the TLS layer. An alignment with FIPS 140 guidance is another motivation, which tells that the IV management shall be interna

Re: [TLS] Improved nonce generation method for TLS 1.3

me to increment 12 bytes (suppressing the carry) in-place. On 06/02/2017 04:20 PM, Adam Langley wrote: > On Fri, Jun 2, 2017 at 3:33 PM, Andrey Jivsov <mailto:cry...@brainhub.org>> wrote: > > The benefits are that the encryption layer doesn't need to deal with

[TLS] Re: [EXT] Re: ML-DSA in TLS

If a dual signature weakens the security beyond a single given signature, there is an attack to add a second signature, and break the first target signature by breaking the dual signature. This should not be possible, but that would be the analysis here: what harm does adding a second signature bri

[TLS] Re: ML-DSA in TLS

> > The reality is that we have very tight deadlines from CNSA2.0, with > customers actively asking for post-quantum support. For those for whom > those > requirements apply, use of ML-DSA is not only uncontroversial, but > mandatory. CNSA 2.0, as clarified in a recent FAQ, does not prohibit ML-D

[TLS] Re: ML-DSA in TLS

1/-1/0/CSI_CNSA_2.0_FAQ_.PDF > > On Mon, Nov 18, 2024, 8:37 PM Andrey Jivsov wrote: > >> The reality is that we have very tight deadlines from CNSA2.0, with >>> customers actively asking for post-quantum support. For those for whom >>> those >>> requiremen

[TLS] Re: ML-DSA in TLS

Alie > > -- > *From:* Deirdre Connolly > *Sent:* Monday, November 18, 2024 7:43 PM > *To:* Andrey Jivsov > *Cc:* D. J. Bernstein ; TLS@ietf.org > *Subject:* [TLS] Re: ML-DSA in TLS > > The CNSA 2.0 FAQ states, "Do not use a hybrid or other no

[TLS] Re: ML-DSA in TLS

Given that the series of Suite B RFCs were Informational, it stands to reason that a document of the type that e.g. prohibits hybrids because of internal policies of any organization, a viewpoint which is not strongly shared by IETF, should not be a standards-track document. For what I see, no-hybr

[TLS] Re: [EXT] Re: ML-DSA in TLS

t; On Fri, Nov 15, 2024, 2:59 PM Andrey Jivsov wrote: > >> Classic McEllice team shows that over the last 10 years lattice crypto >> strength dropped as the equivalence of AES192 to AES128. Will this trend >> continue? >> >> In some deployments there may be a need to t

[TLS] Re: ML-DSA in TLS

I am curious why this draft exclusively proposes ML-DSA, instead of adopting a composite signature approach as outlined in draft-ounsworth-pq-composite-sigs, at least as an option. For instance, id-MLDSA87-ECDSA-P384-SHA512 defined in the draft aligns with CNSA 2.0. Could supporters of the draft e

[TLS] Re: ML-DSA in TLS

n Fri, Nov 15, 2024 at 9:53 AM Alicja Kario wrote: > On Friday, 15 November 2024 18:38:56 CET, Andrey Jivsov wrote: > > I am curious why this draft exclusively proposes ML-DSA, > > instead of adopting a composite signature approach as outlined > > in draft-ounsworth-pq-compos

[TLS] Re: [EXT] Re: ML-DSA in TLS

Classic McEllice team shows that over the last 10 years lattice crypto strength dropped as the equivalence of AES192 to AES128. Will this trend continue? In some deployments there may be a need to turn on a PQ method soon, and keep using, e.g. when configurability is not an option. Also, if a chan

[TLS] Re: [EXT] Re: ML-DSA in TLS

On Fri, Nov 15, 2024 at 3:56 PM Watson Ladd wrote: > ... > Why not hash based signatures? > I think that the stateful ones are perfectly suited for certifications in X.509 certs, but in the TLS handshake this has to be Sphincs+, at 16.2KB per signature at the AES-192 security level. In addition

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

I second D.J. Bernstein's concerns, but my other issue with giving options like this is that they will creep up into MTI sets or default sets, with higher priority than hybrids. I find it less ideal that the document on pure ML-KEM (or signature) and hybrids are disassociated, causing the progress