Re: Fwd: PQC in Firefox and Thunderbird
Robert Relyea <[email protected]> Thu, 12 Oct 2023 10:31:30 -0700
| Newsgroups | gmane.comp.mozilla.crypto |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------6ziwqRQ5rNC4RFPk180rcrah Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable 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=20 > certificates. But in the certificate chain they might very well=20 > appear, I think. There are currently concepts being discussed for=20 > stateful hash-based root CAs. I did misspeak. for hash-based schemes, the key size isn't the issue,=20 it's the signature size. So having hash-based signatures in your chain=20 is going to blow up the size of the certs signed with those signatures.=20 If you keep the signature count low, you can get away with=C2=A0 smaller=20 signtures in state-full hashes, but then you run into nasty deployment=20 issues as you can't really back up stateful keys in any meaningful way=20 (you'll have to do something key key partitioning or similiar, which in=20 turns expands the needed signature count). That being said, I expect to support stateless verification. Again, if=20 the oids are properly defined we would be able to handle certs that use=20 them. We would not support stateless signature (at least not natively)=20 in NSS because there isn't a way to safely deploy stateless signature in=20 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=20 > proof-of-concept testing for PQC migration =E2=80=93 maybe by years. What= I=20 > think would be useful is having at least ML-DSA (Dilithium) as a=20 > signature algorithm for authenticating the handshake in TLS. Could you=20 > imagine integrating that in NSS? Eventually yes, but TLS authentication is not the first priority. We=20 only need to have that in and generally supported before Cryptographic=20 Relevent Quantum computers are generally available. Recording a TLS=20 session and in the future cracking the signature doesn't generate a=20 compromise. There are good reasons to wait for the standards before deployment=20 (rather than experimentation). Mostly because all the PQ algorithms are=20 quite new and we now have a pretty good track record for what happens if=20 you move *TOO* quickly. We also want to have the final versions that=20 everyone agrees on deployed and solid to maximize deployment of those=20 (if there are a lot of competing standards and everyone still negotiates=20 ECC or RSA we all loose). In the mean-time experiments are good to help understand the deployment=20 issues. Other things we can do is try to prepare for the new algorithms. I=20 currently have a patch for the general signature processing that would=20 make adding the new PQ signatures pretty transparent, for instance. > Do you think an existing (individual) RFC draft for PQC signature=20 > identifiers=C2=A0 in TLS would help here? It would. We're actually pretty close on the standards. NIST should be=20 final first quarter of 2024. The draft is already good enough for other=20 standards to reference it. There's a strong desire to get these things=20 defined and finalized. I expect most of the important standards will be=20 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=20 > standardised features. Is there a concept in the NSS / Firefox code=20 > base and a development workflow for such features to be integrated=20 > into the code but not being accessible in the release version? That=20 > might facilitate contributions of experimental features that are not=20 > too invasive with respect to the source code structure such as merely=20 > adding new algorithms. There are experimental API standards in NSS, where the API is access=20 through a function that is marked as experimental and NSS API=20 guarrentees do not apply. There are patches to add Kyber_25519 hybrid to=20 NSS, but I don't see that they've landed yet. Those are explicitly=20 experimental. Given that the final specs are now close, I'm not sure how=20 much we would just put off for the final specs though. bob --=20 You received this message because you are subscribed to the Google Groups "= [email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozill= a.org/d/msgid/dev-tech-crypto/851358ae-aaf3-43a2-bf59-b50ac0a7c081%40redhat= .com. --------------6ziwqRQ5rNC4RFPk180rcrah Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE html> <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8= "> </head> <body> <div class=3D"moz-cite-prefix">On 10/12/23 4:52 AM, Falko Strenzke wrote:<br> </div> <blockquote type=3D"cite" cite=3D"mid:[email protected]"> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF= -8"> Hi Robert, thanks for your feedback. See my answers below.<br> <br> <div> <div dir=3D"auto">Robert Relyea schrieb am Montag, 25. September 2023 um 19:23:04 UTC+2:<br> </div> <blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 20= 4); padding-left: 1ex;"> <div> <div>On 8/21/23 11:52 PM, Falko Strenzke wrote:<br> </div> <blockquote type=3D"cite"> <div dir=3D"ltr"> <div>Hi John,</div> <div><br> </div> <div>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?</div> </div> </blockquote> </div> <div> <p>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. <br> </p> </div> </blockquote> <blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 20= 4); padding-left: 1ex;"> <div> <p>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.<br> </p> </div> </blockquote> <div>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.<br> </div> </div> </blockquote> <p>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=C2=A0 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).</p> <p>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.<br> </p> <blockquote type=3D"cite" cite=3D"mid:[email protected]"> <div> <blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 20= 4); padding-left: 1ex;"> <div> <p> </p> <p>You best indicator on what will be supportable is what the actual standards bodies define.<br> </p> </div> </blockquote> <div>The point here is that waiting for final standards delays large scale proof-of-concept testing for PQC migration =E2=80=93 = 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?</div> </div> </blockquote> <p>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.</p> <p>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).<br> </p> <p>In the mean-time experiments are good to help understand the deployment issues.</p> <p>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.<br> </p> <blockquote type=3D"cite" cite=3D"mid:[email protected]"> <div> <div> Do you think an existing (individual) RFC draft for PQC signature identifiers=C2=A0 in TLS would help here?</div> </div> </blockquote> 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.<br> <blockquote type=3D"cite" cite=3D"mid:[email protected]"> <div> <blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 20= 4); padding-left: 1ex;"> <div> <p> </p> </div> <br> <div> <p>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).</p> </div> </blockquote> <div>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.<br> </div> </div> </blockquote> <p><br> </p> <p>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.</p> bob<br> </body> </html> <p></p> -- <br /> You received this message because you are subscribed to the Google Groups &= quot;[email protected]" group.<br /> To unsubscribe from this group and stop receiving emails from it, send an e= mail to <a href=3D"mailto:[email protected]">dev-tech= [email protected]</a>.<br /> To view this discussion on the web visit <a href=3D"https://groups.google.c= om/a/mozilla.org/d/msgid/dev-tech-crypto/851358ae-aaf3-43a2-bf59-b50ac0a7c0= 81%40redhat.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog= le.com/a/mozilla.org/d/msgid/dev-tech-crypto/851358ae-aaf3-43a2-bf59-b50ac0= a7c081%40redhat.com</a>.<br /> --------------6ziwqRQ5rNC4RFPk180rcrah--