Fwd: PQC in Firefox and Thunderbird

[Falko Strenzke]

Hi,

I am interested to learn whether there are any short term or medium term plans to already add experimental support for post quantum cryptography to Firefox for TLS and to Thunderbird for S/MIME. We are ourselves working on integrations of PQC into our PKI products and would be interested to be compatible with these clients in order to have a small compatible ecosystem for evaluation and demonstration of PQC readiness. Maybe some kind of cooperation is possible in this field?

- Falko

--

MTG AG
Dr. Falko Strenzke
Executive System Architect

Phone: +49 6151 8000 24
E-Mail: falko.s...@mtg.de
Web: mtg.de


MTG Exhibitions – See you in 2023

---

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email. Unauthorised copying or distribution of this email is not permitted.

Data protection information: Privacy policy

[John Schanck]

Hi Falko, we are adding support for the X25519+Kyber768 TLS key exchange to NSS. There's work-in-progress attached to Bug 1775046, although we are waiting for the (draft) NIST standard version of Kyber.

We will also be adding support for some hash-based signatures to NSS. I don't expect that we will do much experimentation with non-hash-based PQ signatures in the near-term, although if there are specific systems that you're interested in evaluating I'd be happy to discuss further.

John

--
You received this message because you are subscribed to the Google Groups "dev-tec...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-tech-cryp...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/773bc910-3107-4969-adc5-f28abd79b1b2%40gmail.com.

[Falko Strenzke]

Hi John,

that is great to hear. Our two interests are PQC algorithms for TLS in Firefox and S/MIME in Thunderbird. As I understand it you are working on the former. Hash-based signatures are also interesting for us, mainly stateless ones. Are you going to support SPHINCS+ certificates for TLS, too?

Will there also be a publicly available version of Firefox with PQC support?

And do you already have a decision or idea about the (temporary) certificate standard you are going to follow? If we could agree on a set of algorithms and the preliminary certificate format, that would be ideal.

- Falko

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/CAFgAd7HfM4RRisPC0m1JThFVtKdzVCYQD8NGu8%2BG0EXwuMtfsw%40mail.gmail.com.

[Kai Engert]

Hi Falko,

On 22.08.23 08:52, Falko Strenzke wrote:
> Our two interests are PQC algorithms for TLS in
> Firefox and S/MIME in Thunderbird. As I understand it you are working on
> the former.

does the experimental code in bug 1775046, which John mentioned, help
you in any way for your request?

Would you be able to build Firefox yourself with that experimnental
code, and perform interoperability tests?

Regarding S/MIME, I'm not aware of anyone working on PQC support for the
CMS code in the NSS library yet, and I personally haven't seen any plans
for that yet either.

Are there already specifications/RFCs that describe how to use PQC
algorithms with CMS for S/MIME?

If yes, do those specifications use the same algorithms as TLS?

If yes, a project to add PQC support to the CMS module of the NSS
library could use the NSS algorithm implementations.

As of today, I haven't seen any plans to work on that. Unless Firefox
has a need for CMS, then this kind of enhancement would likely have to
be driven by the Thunderbird Project, or by contributors who would like
to see this functionality added to Thunderbird.

I don't have answers for your other questions.

Regards
Kai

[Robert Relyea]

On 9/22/23 7:42 AM, Kai Engert wrote:
> Hi Falko,
>
> On 22.08.23 08:52, Falko Strenzke wrote:
>> Our two interests are PQC algorithms for TLS in Firefox and S/MIME in
>> Thunderbird. As I understand it you are working on the former.
>
> does the experimental code in bug 1775046, which John mentioned, help
> you in any way for your request?

The relevant algorithms standards are still in Draft (no one is going to
use stateful hashes to sign email). TLS key exchange is the current low
hanging fruit (hybrid gives you resistance to record and playback in the
PQ case, and resistance to potential classic attacks against our very
new PQ algorithms).

S/MIME is another matter. You do care about keeping your email free from
decryption in the future, so key exchange is a priority. But you then
need to decide do you want hybrid key exchange, or pure PQ. You need
X509 to define which type of key exchange certs you want. If your
message has multiple users, you are vulnerable to the weakest (so if one
recipient is using a classical algorithm, the attacker can decrypt the
message with a quantum computer in the future even if you are using a
hybrid or PQ key yourself. if one recipient is using pure PQ and that
algorithm develops a  classical attack, you become vulnerable).

>
> Would you be able to build Firefox yourself with that experimnental
> code, and perform interoperability tests?
>
> Regarding S/MIME, I'm not aware of anyone working on PQC support for
> the CMS code in the NSS library yet, and I personally haven't seen any
> plans for that yet either.
>
> Are there already specifications/RFCs that describe how to use PQC
> algorithms with CMS for S/MIME?

Kai is absolutely right. I think people are at the 'talking about it'
stage for CMS and S/MIME. I know that they've fed comments back to NIST
before the drafts. The fact the Classic McCliese is not one of the
original standards sort of tells me that CMS and S/MIME are not as
advanced in their pre-standards work as TLS (since these are the one
protocol that would likely benefit from a large, expensive, but highly
secure KEA).

[Robert Relyea]

On 8/21/23 11:52 PM, Falko Strenzke wrote:

Hi John,

that is great to hear. Our two interests are PQC algorithms for TLS in Firefox and S/MIME in Thunderbird. As I understand it you are working on the former. Hash-based signatures are also interesting for us, mainly stateless ones. Are you going to support SPHINCS+ certificates for TLS, too?

I don't know of anyone that's talking about hash-based signatures in any of the on-line protocols (TLS, SSH, IKE). The stateful ones have deployment issues and signature limitations, the stateless ones are have too big of keys.

The use case for hash-based appears to be mostly code-signing. It's also one of the few signing operations that have long lived signatures that could create real problems for a signature made today and a quantum computer 10 years in the future.

We'll probably have SPHINCS+ support in NSS. We'll recognize the OIDS so if you have them in your certs, we'll validate them, but I'm pretty sure TLS will not define SPHINCS+ authentication, and I wouldn't bet that you could fit a change of SPHINCS+ signed certificates in an SSL Certificate Chain message. That's not exactly a next 12 months statement, though.

You best indicator on what will be supportable is what the actual standards bodies define.

Will there also be a publicly available version of Firefox with PQC support?

As we add support for PQC, they will be publicly available. NSS and Firefox are open source and developed out of publicly available repositories.

And do you already have a decision or idea about the (temporary) certificate standard you are going to follow? If we could agree on a set of algorithms and the preliminary certificate format, that would be ideal.

Temporary standards, if used, are likely to be marked experimental because they are transient standards and can change (so we worry about interoperability). Even the X25519+Kyber768 is experimental.

The two areas of most work (In the entire cyrpto industry, not just firefox or NSS) is getting standardize hybrid into our streaming protocols which are subject to 'record now/decrypt later' attacks and firmware/code signing. These are the two main areas where the useful life of the encrypted/signed objects may outstrip the potential advent of a crypto relevant quantum computer. I expect that will be where most of the work occurs in 2024. Remember: the only standardized PQ algorithms right now is LMS/HSS and XMSS,XMSS/MT. That will change by early 2024 (NIST now has drafts for Kyber, Dilithium, and SPHINCS).

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/CAJoiKZgdwtQ%2BRd6Qi%3DwqRqbwkKRzBkyrSFUQrOuL%3DwxdnBh-0A%40mail.gmail.com.

[Falko Strenzke]

Hi Robert, thanks for your feedback. See my answers below.

Robert Relyea schrieb am Montag, 25. September 2023 um 19:23:04 UTC+2:

On 8/21/23 11:52 PM, Falko Strenzke wrote:

Hi John,

that is great to hear. Our two interests are PQC algorithms for TLS in Firefox and S/MIME in Thunderbird. As I understand it you are working on the former. Hash-based signatures are also interesting for us, mainly stateless ones. Are you going to support SPHINCS+ certificates for TLS, too?

I don't know of anyone that's talking about hash-based signatures in any of the on-line protocols (TLS, SSH, IKE). The stateful ones have deployment issues and signature limitations, the stateless ones are have too big of keys.

The use case for hash-based appears to be mostly code-signing. It's also one of the few signing operations that have long lived signatures that could create real problems for a signature made today and a quantum computer 10 years in the future.

I agree that hash-based schemes will most likely not appear in EE certificates. But in the certificate chain they might very well appear, I think. There are currently concepts being discussed for stateful hash-based root CAs.

We'll probably have SPHINCS+ support in NSS. We'll recognize the OIDS so if you have them in your certs, we'll validate them, but I'm pretty sure TLS will not define SPHINCS+ authentication, and I wouldn't bet that you could fit a change of SPHINCS+ signed certificates in an SSL Certificate Chain message. That's not exactly a next 12 months statement, though.

Indeed I wouldn't see SPHINCS⁺ in TLS primarily (if at all).

You best indicator on what will be supportable is what the actual standards bodies define.

The point here is that waiting for final standards delays large scale proof-of-concept testing for PQC migration – maybe by years. What I think would be useful is having at least ML-DSA (Dilithium) as a signature algorithm for authenticating the handshake in TLS. Could you imagine integrating that in NSS? Do you think an existing (individual) RFC draft for PQC signature identifiers  in TLS would help here?

Will there also be a publicly available version of Firefox with PQC support?

As we add support for PQC, they will be publicly available. NSS and Firefox are open source and developed out of publicly available repositories.

 

And do you already have a decision or idea about the (temporary) certificate standard you are going to follow? If we could agree on a set of algorithms and the preliminary certificate format, that would be ideal.

Temporary standards, if used, are likely to be marked experimental because they are transient standards and can change (so we worry about interoperability). Even the X25519+Kyber768 is experimental.

The two areas of most work (In the entire cyrpto industry, not just firefox or NSS) is getting standardize hybrid into our streaming protocols which are subject to 'record now/decrypt later' attacks and firmware/code signing. These are the two main areas where the useful life of the encrypted/signed objects may outstrip the potential advent of a crypto relevant quantum computer. I expect that will be where most of the work occurs in 2024. Remember: the only standardized PQ algorithms right now is LMS/HSS and XMSS,XMSS/MT. That will change by early 2024 (NIST now has drafts for Kyber, Dilithium, and SPHINCS).

I understand being cautious to release experimental / not yet standardised features. Is there a concept in the NSS / Firefox code base and a development workflow for such features to be integrated into the code but not being accessible in the release version? That might facilitate contributions of experimental features that are not too invasive with respect to the source code structure such as merely adding new algorithms.

- Falko

[Falko Strenzke]

Hi Kai, hi Robert,

Robert Relyea schrieb am Montag, 25. September 2023 um 19:02:57 UTC+2:

On 9/22/23 7:42 AM, Kai Engert wrote:
> Hi Falko,
>
> On 22.08.23 08:52, Falko Strenzke wrote:
>> Our two interests are PQC algorithms for TLS in Firefox and S/MIME in
>> Thunderbird. As I understand it you are working on the former.
>
> does the experimental code in bug 1775046, which John mentioned, help
> you in any way for your request?

The relevant algorithms standards are still in Draft (no one is going to
use stateful hashes to sign email). TLS key exchange is the current low
hanging fruit (hybrid gives you resistance to record and playback in the
PQ case, and resistance to potential classic attacks against our very
new PQ algorithms).

S/MIME is another matter. You do care about keeping your email free from
decryption in the future, so key exchange is a priority. But you then
need to decide do you want hybrid key exchange, or pure PQ. You need
X509 to define which type of key exchange certs you want. If your
message has multiple users, you are vulnerable to the weakest (so if one
recipient is using a classical algorithm, the attacker can decrypt the
message with a quantum computer in the future even if you are using a
hybrid or PQ key yourself. if one recipient is using pure PQ and that
algorithm develops a  classical attack, you become vulnerable).

There exists a draft for using KEM in CMS and as I understand it, for the integration in S/MIME not too much more is necessary. The security issues you mention are obviously a concern, as is the use of outdated schemes generally in such aged protocols (for instance malleable CBC encryption in S/MIME). That could only be addressed by policies enforced by the e-mail client.

>
> Would you be able to build Firefox yourself with that experimnental
> code, and perform interoperability tests?
>
> Regarding S/MIME, I'm not aware of anyone working on PQC support for
> the CMS code in the NSS library yet, and I personally haven't seen any
> plans for that yet either.
>
> Are there already specifications/RFCs that describe how to use PQC
> algorithms with CMS for S/MIME?


Kai is absolutely right. I think people are at the 'talking about it'
stage for CMS and S/MIME. I know that they've fed comments back to NIST
before the drafts. The fact the Classic McCliese is not one of the
original standards sort of tells me that CMS and S/MIME are not as
advanced in their pre-standards work as TLS (since these are the one
protocol that would likely benefit from a large, expensive, but highly
secure KEA).

Interesting that you see McEliece for S/MIME. According to my knowledge, one problem here is that the own encryption certificates are usually send along with the encrpted message, thus always incurring the large McEliece key. But that problem could probably be solved by smarter decisions in the clients as to when there is a need to send one's one encryption certificate and when not.

>
> If yes, do those specifications use the same algorithms as TLS?
>
> If yes, a project to add PQC support to the CMS module of the NSS
> library could use the NSS algorithm implementations.
>
> As of today, I haven't seen any plans to work on that. Unless Firefox
> has a need for CMS, then this kind of enhancement would likely have to
> be driven by the Thunderbird Project, or by contributors who would
> like to see this functionality added to Thunderbird.

I currently come to the conclusion that a proof-of-concept implementation that can make use of PQC certificates is much easier to reach for TLS – namely by just adding PQC signature algorithms to X.509 (IETF draft exist) and to TLS (draft not yet existing, but content would be trivial) – than for S/MIME, where I think that even though drafts and RFCs exist for signature and KEM in CMS, the implementation would require much more effort. However, as Robert pointed out, for TLS the pressing "store now – decrypt later" problem can be addressed without the need for PQC certificates, which is not the case for S/MIME, and thus the PQC-enabling the latter would thus maybe be the more intersting use case for an experimental implementation.

- Falko

[Robert Relyea]

On 10/12/23 4:52 AM, Falko Strenzke wrote:

Hi Robert, thanks for your feedback. See my answers below.

Robert Relyea schrieb am Montag, 25. September 2023 um 19:23:04 UTC+2:

On 8/21/23 11:52 PM, Falko Strenzke wrote:

Hi John,

that is great to hear. Our two interests are PQC algorithms for TLS in Firefox and S/MIME in Thunderbird. As I understand it you are working on the former. Hash-based signatures are also interesting for us, mainly stateless ones. Are you going to support SPHINCS+ certificates for TLS, too?

I don't know of anyone that's talking about hash-based signatures in any of the on-line protocols (TLS, SSH, IKE). The stateful ones have deployment issues and signature limitations, the stateless ones are have too big of keys.

The use case for hash-based appears to be mostly code-signing. It's also one of the few signing operations that have long lived signatures that could create real problems for a signature made today and a quantum computer 10 years in the future.

I agree that hash-based schemes will most likely not appear in EE certificates. But in the certificate chain they might very well appear, I think. There are currently concepts being discussed for stateful hash-based root CAs.

I did misspeak. for hash-based schemes, the key size isn't the issue, it's the signature size. So having hash-based signatures in your chain is going to blow up the size of the certs signed with those signatures. If you keep the signature count low, you can get away with  smaller signtures in state-full hashes, but then you run into nasty deployment issues as you can't really back up stateful keys in any meaningful way (you'll have to do something key key partitioning or similiar, which in turns expands the needed signature count).

That being said, I expect to support stateless verification. Again, if the oids are properly defined we would be able to handle certs that use them. We would not support stateless signature (at least not natively) in NSS because there isn't a way to safely deploy stateless signature in software.

You best indicator on what will be supportable is what the actual standards bodies define.

The point here is that waiting for final standards delays large scale proof-of-concept testing for PQC migration – maybe by years. What I think would be useful is having at least ML-DSA (Dilithium) as a signature algorithm for authenticating the handshake in TLS. Could you imagine integrating that in NSS?

Eventually yes, but TLS authentication is not the first priority. We only need to have that in and generally supported before Cryptographic Relevent Quantum computers are generally available. Recording a TLS session and in the future cracking the signature doesn't generate a compromise.

There are good reasons to wait for the standards before deployment (rather than experimentation). Mostly because all the PQ algorithms are quite new and we now have a pretty good track record for what happens if you move *TOO* quickly. We also want to have the final versions that everyone agrees on deployed and solid to maximize deployment of those (if there are a lot of competing standards and everyone still negotiates ECC or RSA we all loose).

In the mean-time experiments are good to help understand the deployment issues.

Other things we can do is try to prepare for the new algorithms. I currently have a patch for the general signature processing that would make adding the new PQ signatures pretty transparent, for instance.

Do you think an existing (individual) RFC draft for PQC signature identifiers  in TLS would help here?

It would. We're actually pretty close on the standards. NIST should be final first quarter of 2024. The draft is already good enough for other standards to reference it. There's a strong desire to get these things defined and finalized. I expect most of the important standards will be in place by the end of 2024.

The two areas of most work (In the entire cyrpto industry, not just firefox or NSS) is getting standardize hybrid into our streaming protocols which are subject to 'record now/decrypt later' attacks and firmware/code signing. These are the two main areas where the useful life of the encrypted/signed objects may outstrip the potential advent of a crypto relevant quantum computer. I expect that will be where most of the work occurs in 2024. Remember: the only standardized PQ algorithms right now is LMS/HSS and XMSS,XMSS/MT. That will change by early 2024 (NIST now has drafts for Kyber, Dilithium, and SPHINCS).

I understand being cautious to release experimental / not yet standardised features. Is there a concept in the NSS / Firefox code base and a development workflow for such features to be integrated into the code but not being accessible in the release version? That might facilitate contributions of experimental features that are not too invasive with respect to the source code structure such as merely adding new algorithms.

There are experimental API standards in NSS, where the API is access through a function that is marked as experimental and NSS API guarrentees do not apply. There are patches to add Kyber_25519 hybrid to NSS, but I don't see that they've landed yet. Those are explicitly experimental. Given that the final specs are now close, I'm not sure how much we would just put off for the final specs though.

bob