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

[John Mattsson]

Hi,

Everybody seem to agree that hybrids should be specified. Looking in my crystal 
ball, I predict that registering hybrids as code points will be a big mess with 
way too many opinions and registrations similar to the TLS 1.2 cipher suites. 
The more I think about it, the more I think TLS 1.3 should standardize a 
generic solution for combining two or more key shares.

My understanding of what would be needed:

- New "split_key_PRF" extension indicating that client supports split-key PRF.

- When "split_key_PRF" is negotiated the server may chose more than one 
group/key share.

  struct {
  NamedGroup selected_groups<0..2^16-1>;
  } KeyShareHelloRetryRequest;

 struct {
  KeyShareEntry server_shares<0..2^16-1>;
  } KeyShareServerHello;

- When "split_key_PRF" is negotiated HKDF-Expand(Secret, HkdfLabel, Length) is 
replaced by a split-key PRF(Secret1, Secret2, ... , HkdfLabel, Length)

I think the current structure that the TLS server makes the decisions on 
“groups” and “key shares” should be kept.

There was a short discussion earlier on the list
https://mailarchive.ietf.org/arch/msg/tls/Z-s8A0gZsRudZ9hW4VoCsNI9YUU/


Sophie Schmieg sschm...@google.com wrote:
”Our stated intention is to move to Kyber once NIST releases the standard”
“I do not think it makes a lot of sense to have multiple schemes based on 
structured lattices in TLS, and Kyber is in my opinion the superior algorithm.”

I agree with that.

Cheers,
John Preuß Mattsson



From: TLS  on behalf of Sophie Schmieg 

Date: Thursday, 9 November 2023 at 08:40
To: tls@ietf.org 
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
> > On 8 Nov 2023, at 8:34, Loganaden Velvindron 
> > mailto:logana...@gmail.com>> wrote:
> >
> > I support moving forward with hybrids as a proactively safe deployment
> > option. I think that supporting
> > only Kyber for KEX  is not enough. It would make sense to have more options.
> >
> > Google uses NTRU HRSS internally:
> > https://cloud.google.com/blog/products/identity-security/why-google-now-uses-post-quantum-cryptography-for-internal-comms
> >
> > If Google decides to use this externally, how easy would it be to get
> > a codepoint for TLS ?
> As easy as writing it up in a stable document (may or may not be an 
> Internet-draft) and asking IANA for a code point assignment.
>
> It can be done in days, if needed.
>
>  Yoav

Just to clarify a few things about our internal usage of NTRU-HRSS: This is for 
historic reasons.

Our stated intention is to move to Kyber once NIST releases the standard, see 
e.g. my talk at PQCrypto [1], where I go into some detail on this topic.
Long story short, we had to choose a candidate well before even NIST's round 3 
announcement, and haven't changed since changing a ciphersuite, while 
relatively straightforward is not free, so we would like to avoid doing it 
twice in a year.
The only security consideration that went into the decision for NTRU was that 
we wanted to use a structured lattice scheme, with NTRU being chosen for 
non-security related criteria that have since materially changed.
I do not think it makes a lot of sense to have multiple schemes based on 
structured lattices in TLS, and Kyber is in my opinion the superior algorithm.

[1] https://www.youtube.com/watch?v=8PYYM3G7_GY


--
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Thu, Nov 09, 2023 at 08:48:07AM +, John Mattsson wrote:
> 
> Everybody seem to agree that hybrids should be specified. Looking in
> my crystal ball, I predict that registering hybrids as code points
> will be a big mess with way too many opinions and registrations
> similar to the TLS 1.2 cipher suites. The more I think about it, the
> more I think TLS 1.3 should standardize a generic solution for
> combining two or more key shares.

I don't think future hybrids in TLS will be anything even close to the
mess that TLS 1.2 ciphersuites are.


> My understanding of what would be needed:
> 
> - New "split_key_PRF" extension indicating that client supports
>   split-key PRF.
> 
> - When "split_key_PRF" is negotiated the server may chose more than
>   one group/key share.

The one part that could be problematic is multiple choices for classical
group to hybrizide with. That could be addressed with share compression
in client hello.

Probably simplest such scheme is allowing replacing first/second part of
share with group number, and then copying that share from start/end of
the referenced share.




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Scott Fluhrer (sfluhrer)]

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 better engineering decision, given the right negotiation 
mechanism), but if it delays actual deployment, I would prefer if we didn't.

From: TLS  On Behalf Of John Mattsson
Sent: Thursday, November 9, 2023 3:48 AM
To: Sophie Schmieg ; tls@ietf.org
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

Hi,

Everybody seem to agree that hybrids should be specified. Looking in my crystal 
ball, I predict that registering hybrids as code points will be a big mess with 
way too many opinions and registrations similar to the TLS 1.2 cipher suites. 
The more I think about it, the more I think TLS 1.3 should standardize a 
generic solution for combining two or more key shares.

My understanding of what would be needed:

- New "split_key_PRF" extension indicating that client supports split-key PRF.

- When "split_key_PRF" is negotiated the server may chose more than one 
group/key share.

  struct {
  NamedGroup selected_groups<0..2^16-1>;
  } KeyShareHelloRetryRequest;

 struct {
  KeyShareEntry server_shares<0..2^16-1>;
  } KeyShareServerHello;

- When "split_key_PRF" is negotiated HKDF-Expand(Secret, HkdfLabel, Length) is 
replaced by a split-key PRF(Secret1, Secret2, ... , HkdfLabel, Length)

I think the current structure that the TLS server makes the decisions on 
"groups" and "key shares" should be kept.

There was a short discussion earlier on the list
https://mailarchive.ietf.org/arch/msg/tls/Z-s8A0gZsRudZ9hW4VoCsNI9YUU/


Sophie Schmieg sschm...@google.com wrote:
"Our stated intention is to move to Kyber once NIST releases the standard"
"I do not think it makes a lot of sense to have multiple schemes based on 
structured lattices in TLS, and Kyber is in my opinion the superior algorithm."

I agree with that.

Cheers,
John Preuß Mattsson



From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Sophie Schmieg 
mailto:sschmieg=40google@dmarc.ietf.org>>
Date: Thursday, 9 November 2023 at 08:40
To: tls@ietf.org mailto:tls@ietf.org>>
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
> > On 8 Nov 2023, at 8:34, Loganaden Velvindron 
> > mailto:logana...@gmail.com>> wrote:
> >
> > I support moving forward with hybrids as a proactively safe deployment
> > option. I think that supporting
> > only Kyber for KEX  is not enough. It would make sense to have more options.
> >
> > Google uses NTRU HRSS internally:
> > https://cloud.google.com/blog/products/identity-security/why-google-now-uses-post-quantum-cryptography-for-internal-comms
> >
> > If Google decides to use this externally, how easy would it be to get
> > a codepoint for TLS ?
> As easy as writing it up in a stable document (may or may not be an 
> Internet-draft) and asking IANA for a code point assignment.
>
> It can be done in days, if needed.
>
>  Yoav

Just to clarify a few things about our internal usage of NTRU-HRSS: This is for 
historic reasons.

Our stated intention is to move to Kyber once NIST releases the standard, see 
e.g. my talk at PQCrypto [1], where I go into some detail on this topic.
Long story short, we had to choose a candidate well before even NIST's round 3 
announcement, and haven't changed since changing a ciphersuite, while 
relatively straightforward is not free, so we would like to avoid doing it 
twice in a year.
The only security consideration that went into the decision for NTRU was that 
we wanted to use a structured lattice scheme, with NTRU being chosen for 
non-security related criteria that have since materially changed.
I do not think it makes a lot of sense to have multiple schemes based on 
structured lattices in TLS, and Kyber is in my opinion the superior algorithm.

[1] https://www.youtube.com/watch?v=8PYYM3G7_GY


--
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Deirdre Connolly]

There are several documents in a cluster that define new hybrid
`NamedGroup`s and how those operate / are combined, abstracted away from
the rest of the TLS handshake. Treating hybrid schemes (key establishment,
signatures) as /separate and distinct from their component algorithms/ is a
good idea.

https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-09.html
https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-03.html
https://www.ietf.org/archive/id/draft-kwiatkowski-tls-ecdhe-kyber-01.html

I am aware of multiple implementations
 and at least one deployment

of the proposed `NamedGroup` `X25519Kyber768Draft00`, so


On Thu, Nov 9, 2023 at 12:01 PM Scott Fluhrer (sfluhrer)  wrote:

> 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 better engineering decision, given the right
> negotiation mechanism), but if it delays actual deployment, I would prefer
> if we didn’t.
>
>
>
> *From:* TLS  *On Behalf Of *John Mattsson
> *Sent:* Thursday, November 9, 2023 3:48 AM
> *To:* Sophie Schmieg ; tls@ietf.org
> *Subject:* Re: [TLS] What is the TLS WG plan for quantum-resistant
> algorithms?
>
>
>
> Hi,
>
>
>
> Everybody seem to agree that hybrids should be specified. Looking in my
> crystal ball, I predict that registering hybrids as code points will be a
> big mess with way too many opinions and registrations similar to the TLS
> 1.2 cipher suites. The more I think about it, the more I think TLS 1.3
> should standardize a generic solution for combining two or more key shares.
>
>
>
> My understanding of what would be needed:
>
>
>
> - New "split_key_PRF" extension indicating that client supports split-key
> PRF.
>
>
>
> - When "split_key_PRF" is negotiated the server may chose more than one
> group/key share.
>
>
>
>   struct {
>
>   NamedGroup selected_groups<0..2^16-1>;
>
>   } KeyShareHelloRetryRequest;
>
>
>
>  struct {
>
>   KeyShareEntry server_shares<0..2^16-1>;
>
>   } KeyShareServerHello;
>
>
>
> - When "split_key_PRF" is negotiated HKDF-Expand(Secret, HkdfLabel,
> Length) is replaced by a split-key PRF(Secret1, Secret2, ... , HkdfLabel,
> Length)
>
>
>
> I think the current structure that the TLS server makes the decisions on
> “groups” and “key shares” should be kept.
>
>
>
> There was a short discussion earlier on the list
>
> https://mailarchive.ietf.org/arch/msg/tls/Z-s8A0gZsRudZ9hW4VoCsNI9YUU/
>
>
>
>
>
> Sophie Schmieg sschm...@google.com wrote:
>
> ”Our stated intention is to move to Kyber once NIST releases the standard”
>
> “I do not think it makes a lot of sense to have multiple schemes based on
> structured lattices in TLS, and Kyber is in my opinion the superior
> algorithm.”
>
>
>
> I agree with that.
>
>
>
> Cheers,
>
> John Preuß Mattsson
>
>
>
>
>
>
>
> *From: *TLS  on behalf of Sophie Schmieg <
> sschmieg=40google@dmarc.ietf.org>
> *Date: *Thursday, 9 November 2023 at 08:40
> *To: *tls@ietf.org 
> *Subject: *Re: [TLS] What is the TLS WG plan for quantum-resistant
> algorithms?
>
> > > On 8 Nov 2023, at 8:34, Loganaden Velvindron 
> wrote:
> > >
> > > I support moving forward with hybrids as a proactively safe deployment
> > > option. I think that supporting
> > > only Kyber for KEX  is not enough. It would make sense to have more
> options.
> > >
> > > Google uses NTRU HRSS internally:
> > >
> https://cloud.google.com/blog/products/identity-security/why-google-now-uses-post-quantum-cryptography-for-internal-comms
> 
> > >
> > > If Google decides to use this externally, how easy would it be to get
> > > a codepoint for TLS ?
> > As easy as writing it up in a stable document (may or may not be an
> Internet-draft) and asking IANA for a code point assignment.
> >
> > It can be done in days, if needed.
> >
> >  Yoav
>
> Just to clarify a few things about our internal usage of NTRU-HRSS: This
> is for historic reasons.
>
> Our stated intention is to move to Kyber once NIST releases the standard,
> see e.g. my talk at PQCrypto [1], where I go into some detail on this topic.
>
> Long story short, we had to choose a candidate well before even NIST's
> round 3 announcement, and haven't changed since changing a ciphersuite,
> while relatively straightforward is not free, so we would like to avoid
> doing it twice in a year.
>
> The only security consideration that went into the decision for NTRU was

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

[John Mattsson]

Scott Fluhrer wrote:
>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.

I think it is bit problematic that the discussion was so long ago before any 
KEM standards were even close to ready and interest in deploying 
quantum-resistant KEMs was limited. The cluster Deirdre mention are all 
non-recommended parameters that I personally don’t care about and don’t want to 
use. I want standards track RFCs. We will likely have FIPS standards for ML-KEM 
and ML-DSA before IETF 119 and it worries me that TLS WG has not even started 
any work (which is equally much my fault). I would like to make ML-KEM and 
ML-DSA mandatory to support in all 3GPP systems that use TLS, DTLS, and QUIC, 
which are many and growing. Current 3GPP policy is to only use “recommended” 
parameters.

The discussion at IETF 105 was 10 min discussion about a specific proposal that 
included complex client preferences and gave the impression that it 
significantly changes the key schedule. I don’t think any client preferences 
would be needed except the group order. The server can determine the most 
preferred PQC KEM and the most preferred ECC group and make a choice based on 
its own policy. The client should not advertise groups that it does not want to 
use. The presentation from IETF 105 gives the impression that the key schedule 
changes. I don’t think a split key PRF changes the key schedule, you just 
exchange one PRF (HKDF-Extract) with another PRF, in fact I think it was wrong 
to hard-code HKDF in TLS 1.3, HMAC and HKDF are constructions to mitigate the 
weaknesses in SHA-2.

https://datatracker.ietf.org/meeting/105/materials/slides-105-tls-sessa-hybrid-key-exchange-in-tls-13-00
https://datatracker.ietf.org/meeting/105/materials/minutes-105-tls-00

>Do we want to reopen that argument?
I guess I already did, but unless people support the idea in this thread, we 
don’t need to discuss it in a meeting. Registering hybrids as code points 
clearly work and it’s anybody’s guess how many hybrids will be registered and 
for how long they will be used. I think the time required for discussing which 
hybrids to register (or not to register) might be the biggest problem.

Cheers,
John Preuß Mattsson

From: Deirdre Connolly 
Date: Thursday, 9 November 2023 at 12:28
To: Scott Fluhrer (sfluhrer) 
Cc: John Mattsson , Sophie Schmieg 
, tls@ietf.org 
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
There are several documents in a cluster that define new hybrid `NamedGroup`s 
and how those operate / are combined, abstracted away from the rest of the TLS 
handshake. Treating hybrid schemes (key establishment, signatures) as /separate 
and distinct from their component algorithms/ is a good idea.

https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-09.html
https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-03.html
https://www.ietf.org/archive/id/draft-kwiatkowski-tls-ecdhe-kyber-01.html

I am aware of multiple 
implementations
 and at least one 
deployment
 of the proposed `NamedGroup` `X25519Kyber768Draft00`, so


On Thu, Nov 9, 2023 at 12:01 PM Scott Fluhrer (sfluhrer) 
mailto:40cisco@dmarc.ietf.org>> wrote:
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 better engineering decision, given the right negotiation 
mechanism), but if it delays actual deployment, I would prefer if we didn’t.

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of John 
Mattsson
Sent: Thursday, November 9, 2023 3:48 AM
To: Sophie Schmieg 
mailto:40google@dmarc.ietf.org>>; 
tls@ietf.org
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

Hi,

Everybody seem to agree that hybrids should be specified. Looking in my crystal 
ball, I predict that registering hybrids as code points will be a big mess with 
way too many opinions and registrations similar to the TLS 1.2 cipher suites. 
The more I think about it, the more I think TLS 1.3 should standardize a 
generic solution for combining two or more key shares.

My understanding of what would be needed:

- New "split_key_PRF" extension indicating that client supports split-key PRF.

- When "split_key_PRF" is negotiated the server may chose more than one 
group/key share.

  struct {
  NamedGroup selected_groups<0..2^16-1>;
  } KeyShareHelloRetryR

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

[D. J. Bernstein]

Sophie Schmieg writes:
> NTRU being chosen for non-security related criteria that have since
> materially changed.

I recommend discussing the patent issues explicitly, including public
analysis of the patent threats. For example, Yunlei Zhao in

   
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/F63mixuWBAAJ

said "Kyber is covered by our patents (not only the two patents
mentioned in the KCL proposal, but also more patent afterforwards)". The
first two patents were filed a month before the publication of "NewHope
without reconciliation", Kyber's direct predecessor:

   https://patents.google.com/patent/CN107566121A/en
   https://eprint.iacr.org/2016/1157

Maybe there's some reason that Zhao is wrong and these patents don't
actually cover Kyber, but then it's important to have a public analysis
convincingly saying why.

More broadly, the big project of protecting user data against future
quantum computers has suffered years of delay from the combination of

   * paying inadequate attention to patents and
   * selecting cryptosystems in the GAM/LPR family.

Some people seem to think that the activation of NIST's licenses in 2024
will bring this mess to an end; I'm skeptical.

---D. J. Bernstein

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Thom Wiggers]

Hi,

I remembered that this discussion was somewhat summarised in 
https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-03#appendix-B,
 which might be helpful.

Cheers,

Thom


> Op 9 nov 2023, om 12:00 heeft Scott Fluhrer (sfluhrer) 
>  het volgende geschreven:
> 
> 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 better engineering decision, given the right 
> negotiation mechanism), but if it delays actual deployment, I would prefer if 
> we didn’t.
>  
> From: TLS  On Behalf Of John Mattsson
> Sent: Thursday, November 9, 2023 3:48 AM
> To: Sophie Schmieg ; tls@ietf.org
> Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
>  
> Hi,
>  
> Everybody seem to agree that hybrids should be specified. Looking in my 
> crystal ball, I predict that registering hybrids as code points will be a big 
> mess with way too many opinions and registrations similar to the TLS 1.2 
> cipher suites. The more I think about it, the more I think TLS 1.3 should 
> standardize a generic solution for combining two or more key shares.
>  
> My understanding of what would be needed:
>  
> - New "split_key_PRF" extension indicating that client supports split-key PRF.
>  
> - When "split_key_PRF" is negotiated the server may chose more than one 
> group/key share.
>  
>   struct {
>   NamedGroup selected_groups<0..2^16-1>;
>   } KeyShareHelloRetryRequest;
>  
>  struct {
>   KeyShareEntry server_shares<0..2^16-1>;
>   } KeyShareServerHello;
>  
> - When "split_key_PRF" is negotiated HKDF-Expand(Secret, HkdfLabel, Length) 
> is replaced by a split-key PRF(Secret1, Secret2, ... , HkdfLabel, Length)
>  
> I think the current structure that the TLS server makes the decisions on 
> “groups” and “key shares” should be kept.
>  
> There was a short discussion earlier on the list
> https://mailarchive.ietf.org/arch/msg/tls/Z-s8A0gZsRudZ9hW4VoCsNI9YUU/
>  
>  
> Sophie Schmieg sschm...@google.com  wrote:
> ”Our stated intention is to move to Kyber once NIST releases the standard”
> “I do not think it makes a lot of sense to have multiple schemes based on 
> structured lattices in TLS, and Kyber is in my opinion the superior 
> algorithm.”
>  
> I agree with that. 
>  
> Cheers,
> John Preuß Mattsson
>  
>  
>  
> From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
> Sophie Schmieg  >
> Date: Thursday, 9 November 2023 at 08:40
> To: tls@ietf.org  mailto:tls@ietf.org>>
> Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
> 
> > > On 8 Nov 2023, at 8:34, Loganaden Velvindron  > > > wrote:
> > > 
> > > I support moving forward with hybrids as a proactively safe deployment
> > > option. I think that supporting
> > > only Kyber for KEX  is not enough. It would make sense to have more 
> > > options.
> > > 
> > > Google uses NTRU HRSS internally:
> > > https://cloud.google.com/blog/products/identity-security/why-google-now-uses-post-quantum-cryptography-for-internal-comms
> > >  
> > > 
> > > 
> > > If Google decides to use this externally, how easy would it be to get
> > > a codepoint for TLS ?
> > As easy as writing it up in a stable document (may or may not be an 
> > Internet-draft) and asking IANA for a code point assignment.
> > 
> > It can be done in days, if needed.
> > 
> >  Yoav
> 
> Just to clarify a few things about our internal usage of NTRU-HRSS: This is 
> for historic reasons.
> 
> Our stated intention is to move to Kyber once NIST releases the standard, see 
> e.g. my talk at PQCrypto [1], where I go into some detail on this topic.
> Long story short, we had to choose a candidate well before even NIST's round 
> 3 announcement, and haven't changed since changing a ciphersuite, while 
> relatively straightforward is not free, so we would like to avoid doing it 
> twice in a year.
> The only security consideration that went into the decision for NTRU was that 
> we wanted to use a structured lattice scheme, with NTRU being chosen for 
> non-security related criteria that have since materially changed.
> I do not think it makes a lot of sense to have multiple schemes based on 
> structured lattices in TLS, and Kyber is in my opinion the superior algorithm.
>  
> [1] https://www.youtube.com/watch?v=8PYYM3G7_GY
> 
> 
> --
> ___
> TLS mailing list
>

[TLS] The qpack_static_table_version TLS extension (Draft version 02)

[Rory Hewitt]

Hey folks,

Following my presentation at the meeting at IETF 118 today (thanks for
taking it easy on me, as this was my first IETF appearance as well as being
my first I-D), I have created another version of my I-D:

https://www.ietf.org/archive/id/draft-hewitt-ietf-qpack-static-table-version-02.html

Significant changes from version-01 are as follows:

1. I changed references to registry "Version" to "Variant" to make it clear
that they could be very different.

2. I added a section on vendor-defined registries, which would contain
static tables that might be much smaller and/or contain vendor-specific
field names or values - for instance for personal assistants and APIs which
only use a very small set of headers with known values.

3. In the QPACK Static Table Background

section,
I added an example showing how the use of a static table can significantly
reduce bytes on the wire by passing only 2- or 3-byte references to much
longer strings that are known to both client and server.

4. The details of the TLS extension has been changed so that it is no
longer simply a Variant/Length pair, but similarly to ciphersuite support,
it is (when passed in the ClientHello) an array of Variant/Length
combinations supported by the client and (when passed in the ServerHello) a
single negotiated Variant/Length pair which will be used by both client and
server.

Note that the draft still refers to this as a "TLS extension" - I think
many of us agree that it would be preferable if it were defined in ALPS,
but since ALPS support is still minimal, I'll keep referring to it as a TLS
extension for now. Given that, I would really appreciate any comments on
the high-level concept, on the understanding that it may not end up being a
TLS extension. Speaking of which, where can I find details of why ALPS was
not taken up - it was mentioned in the meeting that there were 'concerns'
about ALPS, but I'm not clear on what they were or who was concerned - HTTP
WG or TLS WG or both or some other entity?

Finally, I'm still trying to build a test harness to determine whether the
benefits of any additional compression make sense - is this even worth the
hassle? I would greatly appreciate any help on this - you'll get co-author
credit, for what that's worth :)

Thanks,

Rory
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Deb Cooley]

I've done a tiny bit of checking on the situation of where we (USG DOD)
have smartcards doing client auth TLS.  To my knowledge, most (all?) are
currently TLS 1.2 w/ PKCS1v1.5 certs.   So, I would be in favor of this
update (when I wrote RFC9151 I had long discussions about this, because I
was worried about it then).

This is a problem that will go away with the adoption of PQ asymmetric
algorithms.

Deb Cooley
NSA/CSD
deco...@radium.ncsc.mil


On Mon, Oct 30, 2023 at 11:37 AM Andrei Popov  wrote:

> Correct, hardware update takes years. Deployments that use client crypto
> devices without RSA-PSS support (or with an RSA-PSS implementation that
> produces TLS 1.3-incompatible signatures) have to disable TLS 1.3 on the
> client and/or server side.
>
>
>
> In a lot of these deployments the system admin can detect incompatible
> client crypto devices and update TLS stacks as needed.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* David Benjamin 
> *Sent:* Friday, October 27, 2023 11:34 AM
> *To:* Benjamin Kaduk 
> *Cc:* Andrei Popov ; TLS@ietf.org
> *Subject:* [EXTERNAL] Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for
> TLS 1.3
>
>
>
> On Fri, Oct 27, 2023 at 2:07 PM Benjamin Kaduk  wrote:
>
> On Tue, Oct 24, 2023 at 10:12:56PM -0400, David Benjamin wrote:
> >Additionally I want to emphasize that, because of the negotiation
> order
> >between versions and client certificates, there is no way to do an
> >incremental transition here. Saying deployments stick with 1.2 not
> only
> >impacts the relevant hardware but also *any other connections that the
> >server makes*. Essentially the server cannot enable TLS 1.3 until
> *every*
> >client has stopped using one of these PSS-incapable signers. This is
> not a
> >good transition plan.
>
> I think we should probably think out the transition plan here a bit more.
> Sure, if we can have updated clients offer new SignatureSchemes and the
> server
> notice that to let them use TLS 1.3.  But how does the server get to a
> place
> where it can use TLS 1.3 with every client that offers it?  It seems like
> it
> has to know that all clients with old hardware tokens have updated, which
> would
> require knowing about and tracking exactly which clients those are, since
> other
> clients would not be sending the new SignatureSchemes in the first place.
> I
> see this getting a small win for the legacy clients but no improvement for
> other clients or the server's default behavior.  Am I missing something?
>
>
>
> Good question. You're right that, because we didn't do this from day
> one[*], the transition plan is not ideal.
>
>
>
> Updating software is a lot easier than replacing hardware, so I think
> waiting for clients with old hardware tokens to update (at least those that
> have enabled TLS 1.3) can be viable. Most client certificate deployments
> that stick keys in interesting hardware tokens are relatively closed
> ecosystems on the client half, such as a managed enterprise deployment. You
> need to have a provisioning process that knows to use the TPMs. In those
> cases, it is viable for the enterprise to rollout client support for these
> legacy codepoints, wait a bit, and then start enabling TLS 1.3 on the
> servers.
>
>
>
> Andrei is probably better to speak to how commonly that plan would and
> wouldn't be viable. If there are enough deployments where this doesn't
> work, I suppose we could define a ClientHello extension that means "I will
> either speak the legacy RSASSA-PKCS1-v1_5 codepoints, or it is not relevant
> to me". Those semantics are pretty messy though, and it makes
> the server-random downgrade hack much more complex. We can always do it
> later if enough folks need it, so I'm inclined to defer it for now.
>
>
>
> David
>
>
>
> [*] As I recall, TLS 1.3 was broadly intended to be deployable with the
> same keys as TLS 1.2, otherwise we probably needn't have bothered with RSA
> at all. We switched from PKCS#1 v1.5 to PSS mostly because it was perceived
> to cost us nothing. This was broadly true for server certificates. Client
> certificates not so much. In hindsight, I think banning PKCS#1 v1.5 for
> client signatures was a tad too ambitious for TLS 1.3.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Loganaden Velvindron]

I support moving forward with this document.

On Wed, 25 Oct 2023 at 04:49, Andrei Popov
 wrote:
>
> Hi TLS,
>
>
>
> We would like to re-introduce 
> https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/
>
> (it’s intended for the TLS WG and the Standards track, despite what the 
> document says at the top; we’ll fix it as soon as the submission tool 
> reopens).
>
>
>
> In the course of TLS 1.3 deployment, it became apparent that a lot of 
> hardware cryptographic devices used to protect TLS client certificate private 
> keys cannot produce RSA-PSS signatures compatible with TLS.
>
> This draft would allow RSA-PKCS signatures in the client CertificateVerify 
> messages (and not in any other contexts), as a way to unblock TLS 1.3 
> deployments.
>
> This is an unfortunate situation, and work is being done with hardware 
> vendors to reduce the likelihood of similar issues in the future, but 
> existing devices tend to stay around for years.
>
>
>
> Comments/suggestions are welcome,
>
>
>
> Cheers,
>
>
>
> Andrei
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls