Re: Fwd: PQC in Firefox and Thunderbird
Falko Strenzke <[email protected]> Thu, 12 Oct 2023 05:29:10 -0700 (PDT)
| Newsgroups | gmane.comp.mozilla.crypto |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_15714_68244753.1697113750758 Content-Type: multipart/alternative; boundary="----=_Part_15715_302694836.1697113750758" ------=_Part_15715_302694836.1697113750758 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:=20 > Hi Falko,=20 >=20 > On 22.08.23 08:52, Falko Strenzke wrote:=20 >> Our two interests are PQC algorithms for TLS in Firefox and S/MIME in=20 >> Thunderbird. As I understand it you are working on the former.=20 >=20 > does the experimental code in bug 1775046, which John mentioned, help=20 > you in any way for your request?=20 The relevant algorithms standards are still in Draft (no one is going to=20 use stateful hashes to sign email). TLS key exchange is the current low=20 hanging fruit (hybrid gives you resistance to record and playback in the=20 PQ case, and resistance to potential classic attacks against our very=20 new PQ algorithms).=20 S/MIME is another matter. You do care about keeping your email free from=20 decryption in the future, so key exchange is a priority. But you then=20 need to decide do you want hybrid key exchange, or pure PQ. You need=20 X509 to define which type of key exchange certs you want. If your=20 message has multiple users, you are vulnerable to the weakest (so if one=20 recipient is using a classical algorithm, the attacker can decrypt the=20 message with a quantum computer in the future even if you are using a=20 hybrid or PQ key yourself. if one recipient is using pure PQ and that=20 algorithm develops a classical attack, you become vulnerable).=20 There exists a draft for using KEM in CMS=20 <https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kemri/> and as I=20 understand it, for the integration in S/MIME not too much more is=20 necessary. The security issues you mention are obviously a concern, as is= =20 the use of outdated schemes generally in such aged protocols (for instance= =20 malleable CBC encryption in S/MIME). That could only be addressed by=20 policies enforced by the e-mail client. >=20 > Would you be able to build Firefox yourself with that experimnental=20 > code, and perform interoperability tests?=20 >=20 > Regarding S/MIME, I'm not aware of anyone working on PQC support for=20 > the CMS code in the NSS library yet, and I personally haven't seen any=20 > plans for that yet either.=20 >=20 > Are there already specifications/RFCs that describe how to use PQC=20 > algorithms with CMS for S/MIME?=20 Kai is absolutely right. I think people are at the 'talking about it'=20 stage for CMS and S/MIME. I know that they've fed comments back to NIST=20 before the drafts. The fact the Classic McCliese is not one of the=20 original standards sort of tells me that CMS and S/MIME are not as=20 advanced in their pre-standards work as TLS (since these are the one=20 protocol that would likely benefit from a large, expensive, but highly=20 secure KEA).=20 Interesting that you see McEliece for S/MIME. According to my knowledge,=20 one problem here is that the own encryption certificates are usually send= =20 along with the encrpted message, thus always incurring the large McEliece= =20 key. But that problem could probably be solved by smarter decisions in the= =20 clients as to when there is a need to send one's one encryption certificate= =20 and when not. >=20 > If yes, do those specifications use the same algorithms as TLS?=20 >=20 > If yes, a project to add PQC support to the CMS module of the NSS=20 > library could use the NSS algorithm implementations.=20 >=20 > As of today, I haven't seen any plans to work on that. Unless Firefox=20 > has a need for CMS, then this kind of enhancement would likely have to=20 > be driven by the Thunderbird Project, or by contributors who would=20 > like to see this functionality added to Thunderbird.=20 I currently come to the conclusion that a proof-of-concept implementation= =20 that can make use of PQC certificates is much easier to reach for TLS =E2= =80=93=20 namely by just adding PQC signature algorithms to X.509 (IETF draft exist)= =20 and to TLS (draft not yet existing, but content would be trivial) =E2=80=93= than=20 for S/MIME, where I think that even though drafts and RFCs exist for=20 signature and KEM in CMS, the implementation would require much more=20 effort. However, as Robert pointed out, for TLS the pressing "store now =E2= =80=93=20 decrypt later" problem can be addressed without the need for PQC=20 certificates, which is not the case for S/MIME, and thus the PQC-enabling= =20 the latter would thus maybe be the more intersting use case for an=20 experimental implementation. - Falko >=20 > I don't have answers for your other questions.=20 >=20 > Regards=20 > Kai=20 >=20 --=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/a4e8beeb-20b7-4653-8785-6d51a70a93fdn%40mozil= la.org. ------=_Part_15715_302694836.1697113750758 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kai, hi Robert,<br /><br /><div><div dir=3D"auto">Robert Relyea schrieb = am Montag, 25. September 2023 um 19:02:57 UTC+2:<br /></div><blockquote sty= le=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);= padding-left: 1ex;">On 9/22/23 7:42 AM, Kai Engert wrote: <br />> Hi Falko, <br />> <br />> On 22.08.23 08:52, Falko Strenzke wrote: <br />>> Our two interests are PQC algorithms for TLS in Firefox and = S/MIME in=20 <br />>> Thunderbird. As I understand it you are working on the forme= r. <br />> <br />> does the experimental code in bug 1775046, which John mentioned,= help=20 <br />> you in any way for your request? <br /> <br />The relevant algorithms standards are still in Draft (no one is going= to=20 <br />use stateful hashes to sign email). TLS key exchange is the current l= ow=20 <br />hanging fruit (hybrid gives you resistance to record and playback in = the=20 <br />PQ case, and resistance to potential classic attacks against our very= =20 <br />new PQ algorithms). <br /></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-l= eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <br />S/MIME is another matter. You do care about keeping your email free f= rom=20 <br />decryption in the future, so key exchange is a priority. But you then= =20 <br />need to decide do you want hybrid key exchange, or pure PQ. You need= =20 <br />X509 to define which type of key exchange certs you want. If your=20 <br />message has multiple users, you are vulnerable to the weakest (so if = one=20 <br />recipient is using a classical algorithm, the attacker can decrypt th= e=20 <br />message with a quantum computer in the future even if you are using a= =20 <br />hybrid or PQ key yourself. if one recipient is using pure PQ and that= =20 <br />algorithm develops a=C2=A0 classical attack, you become vulnerable). <br /></blockquote><div>There exists a <a href=3D"https://datatracker.ietf.= org/doc/draft-ietf-lamps-cms-kemri/">draft for using KEM in CMS</a> and as = I understand it, for the integration in S/MIME not too much more is necessa= ry. The security issues you mention are obviously a concern, as is the use = of outdated schemes generally in such aged protocols (for instance malleabl= e CBC encryption in S/MIME). That could only be addressed by policies enfor= ced by the e-mail client.<br /></div><blockquote style=3D"margin: 0px 0px 0= px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <br />> <br />> Would you be able to build Firefox yourself with that experimnen= tal=20 <br />> code, and perform interoperability tests? <br />> <br />> Regarding S/MIME, I'm not aware of anyone working on PQC support= for=20 <br />> the CMS code in the NSS library yet, and I personally haven't se= en any=20 <br />> plans for that yet either. <br />> <br />> Are there already specifications/RFCs that describe how to use P= QC=20 <br />> algorithms with CMS for S/MIME? <br /> <br /> <br />Kai is absolutely right. I think people are at the 'talking about it'= =20 <br />stage for CMS and S/MIME. I know that they've fed comments back to NI= ST=20 <br />before the drafts. The fact the Classic McCliese is not one of the=20 <br />original standards sort of tells me that CMS and S/MIME are not as=20 <br />advanced in their pre-standards work as TLS (since these are the one= =20 <br />protocol that would likely benefit from a large, expensive, but highl= y=20 <br />secure KEA). <br /> <br /></blockquote><div>Interesting that you see McEliece for S/MIME. Accor= ding to my knowledge, one problem here is that the own encryption certifica= tes are usually send along with the encrpted message, thus always incurring= the large McEliece key. But that problem could probably be solved by smart= er decisions in the clients as to when there is a need to send one's one en= cryption certificate and when not.</div><div><br /></div><blockquote style= =3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p= adding-left: 1ex;">> <br />> If yes, do those specifications use the same algorithms as TLS? <br />> <br />> If yes, a project to add PQC support to the CMS module of the NS= S=20 <br />> library could use the NSS algorithm implementations. <br />> <br />> As of today, I haven't seen any plans to work on that. Unless Fi= refox=20 <br />> has a need for CMS, then this kind of enhancement would likely h= ave to=20 <br />> be driven by the Thunderbird Project, or by contributors who wou= ld=20 <br />> like to see this functionality added to Thunderbird. <br /></blockquote><div><br /></div><div>I currently come to the conclusion= that a proof-of-concept implementation that can make use of PQC certificat= es is much easier to reach for TLS =E2=80=93 namely by just adding PQC sign= ature algorithms to X.509 (IETF draft exist) and to TLS (draft not yet exis= ting, but content would be trivial) =E2=80=93 than for S/MIME, where I thin= k that even though drafts and RFCs exist for signature and KEM in CMS, the = implementation would require much more effort. However, as Robert pointed o= ut, for TLS the pressing "store now =E2=80=93 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.</div><div><br /></d= iv><div>- Falko<br /></div><div><br /></div><blockquote style=3D"margin: 0p= x 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1= ex;">> <br />> I don't have answers for your other questions. <br />> <br />> Regards <br />> Kai <br />> <br /> <br /></blockquote></div> <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/a4e8beeb-20b7-4653-8785-6d51a70a93= fdn%40mozilla.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.go= ogle.com/a/mozilla.org/d/msgid/dev-tech-crypto/a4e8beeb-20b7-4653-8785-6d51= a70a93fdn%40mozilla.org</a>.<br /> ------=_Part_15715_302694836.1697113750758-- ------=_Part_15714_68244753.1697113750758--