[New Paper] Migration Strategy Towards Post-Quantum Authentication for TLS 1.3

[Sebastian Paul]

Hi all,

we would like to share our most recent work with you titled "Mixed Certificate Chains for the Transition to Post-Quantum Authentication in TLS 1.3". It has been accepted for publication at AsiaCCS 2022. The ePrint version is available at: https://eprint.iacr.org/2021/1447.

In summary:

• We propose and investigate a two-step migration strategy towards post-quantum authentication in TLS 1.3.
• Our strategy is based on the concept of "mixed certificate chains" which make use of different signature algorithms within the same certificate chain.
• In a first step, we combine hash-based signature schemes (SPHINCS+ and XMSS) at the root certificate level with ECDSA at the subsequent levels.
• In the second step, we combine hash-based signature schemes at the root level with lattice-based schemes (CRYSTALS-Dilithium and Falcon) to provide complete post-quantum authentication.
  
• In our experiments we evaluate these scheme combinations alongside PQC key exchange (CRYSTALS-Kyber) and demonstrate their practicality under realistic network conditions by reporting connection establishment times, communication size, code size, and peak memory usage.

Looking forward to your comments or questions.

Cheers,
Sebastian, Yulia, Norman, and Ruben

[Anthony Hu]

Hello PQC-Forum,

My name is Anthony Hu.  I am a member of the wolfSSL organization. We applaud and encourage the efforts of Sebastian and his team.

As Sebastian says in his paper, ""We selected the TLS library wolfSSL (v4.7.0) for our integrations of PQC, because it is suitable for embedded systems and supports TLS 1.3."

If anyone else is considering embedded use cases or projects that would be a good fit for any of wolfSSL's open source offerings, please do not hesitate to get in touch.  We are happy to encourage and help with the advancement of the PQC community. In fact, our own PQC efforts are underway as we have already integrated the NIST round 3 finalist KEMs into TLS1.3 via an integration with liboqs.  We are currently working on a signature scheme and that work should be done very soon.  Please have a look at our github project at https://github.com/wolfSSL/wolfssl/ .  Please do not hesitate to get in touch with me and the rest of the wolfSSL team at ant...@wolfssl.com and/or fa...@wolfssl.com .

Warm regards to all, Anthony

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/df58baba-0413-4d66-a8c8-aab669e389edn%40list.nist.gov.

[Kampanakis, Panos]

Hi Paul,

 

This is interesting work. The results make sense as HBS verification is, for the most part, fast and the rest also matches with some previous work we had done.

 

Btw, you could slim down the cert chains a bit more by going a little smaller (H=5) with XMSS or using smaller SPHINCS+ trees at the root. Roots sign just a few ICAs usually.  The performance would not change by a lot though.

 

I had tried to socialize the idea of a phased approach with HBS based Root CAs in the past and I have to say that industry peers brought up challenges that should not be underestimated:  

- Root CAs live for a long time, so it may make sense to add quantum-resistance earlier. But given what history has shown about these migrations, not all verifiers will be upgraded in time. Thus, we can’t really say an expiring Root CA could go completely HBS because that would cause outages to some verifiers. Some sort of a dual chain (classical and HBS root) would still need to be supported. Thus, we don’t really buy much by making the roots post-quantum early.

- Transitioning to HBS roots would require that we upgrade all these roots and the verifiers. Even after that happened, we would have roots that are quantum resistant but we would not have quantum-resistance. So, we would need to upgrade twice, instead of once when ready. Such migrations are never straightforward.

 

Anyway, regardless of the practical challenges of the approach, it is interesting work.

 

Rgs,

Panos

 

 

From: 'Sebastian Paul' via pqc-forum <pqc-...@list.nist.gov>
Sent: Thursday, October 28, 2021 3:36 AM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: [EXTERNAL] [pqc-forum] [New Paper] Migration Strategy Towards Post-Quantum Authentication for TLS 1.3

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

[Ruben Niederhagen]

Hi Panos!

On 10/30/21 05:21, 'Kampanakis, Panos' via pqc-forum wrote:
> Btw, you could slim down the cert chains a bit more by going a little
> smaller (H=5) with XMSS or using smaller SPHINCS+ trees at the root.
> Roots sign just a few ICAs usually. The performance would not change
> by a lot though.

I agree - but currently, such parameter sets are not specified. XMSS in
the single-tree variant only offers a minimum tree height of h=10 in RFC
8391 - and changing SPHINCS+ parameters in this way would reduce the
number of possible secure signatures under the minimum of 2^60 as
required for the NIST standardization process.

However, this may indeed be an application were a stateless hash-based
signature scheme with a smaller maximum number of signatures makes sense.

Ruben

[Kampanakis, Panos]

Hi Ruben,

> XMSS in the single-tree variant only offers a minimum tree height of h=10 in RFC8391 -

Good point. My bad. LMS (RFC8554) supports H=5, but I missed XMSS starts at H=10.

> and changing SPHINCS+ parameters in this way would reduce the number of possible secure signatures under the minimum of 2^60 as required for the NIST standardization process.

Agreed. We briefly discussed this in Section 4.2 (1st paragraph) of https://eprint.iacr.org/2021/041 where we generated new parameters for SPHINCS+ in a usecase where a maximum of 2^35 signatures would suffice.

If SPHINCS+ ends up getting standardized, it will probably be worth to consider standardizing parameters for usecases where we need less than 2^64 sigs.

-----Original Message-----
From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> On Behalf Of Ruben Niederhagen
Sent: Saturday, October 30, 2021 10:38 AM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: RE: [EXTERNAL] [pqc-forum] [New Paper] Migration Strategy Towards Post-Quantum Authentication for TLS 1.3

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/cea30436-27f5-f3ae-79e6-d5352d0c4c16%40polycephaly.org.