Re: [TLS] ML-KEM key agreement for TLS 1.3
* Tuesday, March 5, 2024 9:15 PM *To:* TLS@ietf.org <mailto:TLS@ietf.org> *Subject:* [TLS] ML-KEM key agreement for TLS 1.3 __ __ I have uploaded a preliminary version of ML-KEM for TLS 1.3 <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/> and have a more fleshed out <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> version to be uploaded when datatracker opens. It is a straightforward new `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a very similar style to -hybrid-design <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>. __ __ It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) ready to go when users are ready to use them. __ __ Cheers, Deirdre ___ TLS mailing list TLS@ietf.org <mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls> ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Sofía Celi @claucece Cryptographic research and implementation at many places, specially Brave. she/her, they/them. Chair of hprc at IRTF, pquip at IETF, and anti-fraud at W3C. Reach me out at: cheren...@riseup.net Website: https://sofiaceli.com/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
Dear, all, On 22/08/2022 14:24, Bas Westerbaan wrote: Here they're speaking about adding non-FIPS PQ to a non-PQ FIPS kex,[2] but the other way around is also ok — what am I missing? Let's assume Kyber is FIPS-approved. Indeed, you'll be able to have a FIPS library with Z generated by Kyber and T generated by X25519 (but not other way around). As X25519 is not FIPS-approved, the lab won't be able to test it, hence you can't declare any security on that scheme. This will be reflected in the security policy (as a "non-approved algorithm, with no security claimed"). In theory, X25519 may produce wrong results and your product still gets FIPS certificate as the algorithm is security irrelevant. It is similar situation as we have today, but with Z generated by P-256 and T by Kyber. What, I think, is more valuable for those who need FIPS, is to be able to have hybrid construction in which both algorithms are properly tested and certified by the FIPS lab. Also, in that case, Z can be generated by either PQ or non-PQ as both are FIPS-approved. I support this. I definetly support adding P256+Kyber512 (or any of the NIST curves + Kyber). For actual FedRAMP purposes, the most valuable thing, as Kris says, is to have them both being FIPS approved (and using a FIPS-certified implementation or sumitting it all for FIPS certification). Even if Kyber becaomes FIPS-approved, one will have to used a FIPS-certified implementation of it in other to be able to claim the FIPS-approved hybrid approach (and even then it depends how/where it is used). As far as I know, only the NIST curves are both FIPS approved and some of their implementations have a certification. Thank you, -- Sofía Celi @claucece Cryptographic research and implementation at many places, specially Brave. Chair of hprc at IRTF and anti-fraud at W3C. Reach me out at: cheren...@riseup.net Website: https://sofiaceli.com/ 3D0B D6E9 4D51 FBC2 CEF7 F004 C835 5EB9 42BF A1D6 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Before we PQC... Re: PQC key exchange sizes
Dear, all, On 06/08/2022 13:00, Rob Sayre wrote: On Fri, Aug 5, 2022 at 10:15 PM Benjamin Kaduk <mailto:bka...@akamai.com>> wrote: It's annoying to the attacker when they have to use their expensive and finicky hardware once (or multiple times) for each individual message/exchange they want to break, Well, I can agree with the term "expensive", but I'm not sure what you mean by "finicky". Are you saying they only work sometimes? It seems a bit hand-wavy to say that. I've seen quantum computers before. They are room-sized, but not that big. I still find the term "quantum annoying" rather imprecise. Maybe this is better (taken for the Eaton and Stebila paper in reference to PAKEs): """ If a scheme is quantum annoying, then being able to solve one discrete logarithm (in the case of DH, for example, sic) does not immediately provide the ability to compromise a system; instead, each discrete logarithm an adversary solves only allows them to eliminate a single possible password. Essentially, the adversary must guess a password, solve a discrete logarithm based on their guess, and then check to see if they were correct. """ It is difficult to asses how 'annoying' this will be for a quantum computer. For a strong noise-free quantum computer is probably not annoying but for something in between (which is what we might get in the upcomign years) it might be. Thanks, -- Sofía Celi @claucece Cryptographic research and implementation at many places, specially Brave. Chair of hprc at IRTF and anti-fraud at W3C. Reach me out at: cheren...@riseup.net Website: https://sofiaceli.com/ 3D0B D6E9 4D51 FBC2 CEF7 F004 C835 5EB9 42BF A1D6 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Before we PQC... Re: PQC key exchange sizes
Dear, all, On 06/08/2022 07:15, Benjamin Kaduk wrote: On Fri, Aug 05, 2022 at 07:16:06PM -0700, Rob Sayre wrote: On Fri, Aug 5, 2022 at 5:16 PM Sofía Celi wrote: There is a notion of being 'quantum annoyant' to a quantum computer: I've encountered the term "quantum annoyant" a few times. Is there a precise definition that could be referenced? Maybe [0]? I don't find the references I know of very satisfying, and I would translate "annoyant" to "doesn't actually work". thanks, Rob [0] https://urldefense.com/v3/__https://eprint.iacr.org/2021/696.pdf__;!!GjvTz_vk!S_lXpy5HvfAfDJmtXdME2kuOOLXGTGz07_pqClIgY8ppVcZYu7Cf2WQ0K7YjyyOypKFppMI6NE_C$ I think [0] is the reference (or at least very similar content) I've seen in previous discussions of this topic. It's annoying to the attacker when they have to use their expensive and finicky hardware once (or multiple times) for each individual message/exchange they want to break, rather than being able to amortize the cost of running the quantum computer across many protocol runs that are broken by that computer. They'd have to be selective about what to decrypt (quickly), rather than just getting "everything" -- while a QC does provide massive speedups, it does still take some actual amount of time to run, and we can build protocols so that the runtime of the QC is a practical constraint on the attacker's ability, even if it is not necessarily a theoretical constraint on them. Correct. Note that it doesn't mean that a QC will not break it at the end, but just that is is 'annoying' to perform such operations over and over. Edward Eaton and Douglas Stebila properly defined the "property" over here: https://eprint.iacr.org/2021/696.pdf It was first mentioned during the PAKE selection process at CFRG by Thomas: https://mailarchive.ietf.org/arch/msg/cfrg/dtf91cmavpzT47U3AVxrVGNB5UM/ Thanks, -- Sofía Celi @claucece Cryptographic research and implementation at many places, specially Brave. Chair of hprc at IRTF and anti-fraud at W3C. Reach me out at: cheren...@riseup.net Website: https://sofiaceli.com/ 3D0B D6E9 4D51 FBC2 CEF7 F004 C835 5EB9 42BF A1D6 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Before we PQC... Re: PQC key exchange sizes
Dear, all, Late to reply to some emails. I was just travelling ;) > I am now thinking in terms of 'Post Quantum Hardened" and "Post Quantum > Qualified". Hardening a system so it doesn't completely break under QCC > is a practical near term goal. Getting to a fully qualified system is > going to be a root-and-canal job. There is a notion of being 'quantum annoyant' to a quantum computer: perhaps that might be an starting point for other schemes that do no have a post-quantum counterpart as of right now. For others, a hybrid approach should definitly be taken such that classical cryptography still protects data. I am using PQC to protect the data and Threshold-ECC to protect the data with separation of roles. Unfortunately, Threshold-ECC does not have a propely assesed quantum secure version. There is some thoughts over here if interested: https://csrc.nist.gov/CSRC/media/Events/Second-PQC-Standardization-Conference/documents/accepted-papers/cozzo-luov-paper.pdf Thanks, -- Sofía Celi @claucece Cryptographic research and implementation at many places, specially Brave. Chair of hprc at IRTF and anti-fraud at W3C. Reach me out at: cheren...@riseup.net Website: https://sofiaceli.com/ 3D0B D6E9 4D51 FBC2 CEF7 F004 C835 5EB9 42BF A1D6 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Before we PQC... Re: PQC key exchange sizes
finitely yes; otherwise – who cares. __ __ PQC hardening the initial key exchange should suffice provided that we fix the forward secrecy exchange so that it includes the entropy from the primary. This would bring TLS in line with Noise and with best practice. It would be a change to the TLS key exchange but one that corrects an oversight in the original forward secrecy mechanism. __ __ If your rekey depends on the initial key values, and/or uses only Classic crypto – how can you provide Forward Secrecy? The TLS nomenclature is confused here. To me a session key is what I apply to data, i.e. session = KDF (ephemeral-agreement) My rekey uses the initial values plus the ephemeral exchange, ie session = KDF (initial-exchange + ephemeral-agreement) So the key I use to encrypt the data is secure if either the initial-exchange is secure or the ephemeral-agreement is secure. I have not proved that but any inability to produce such a proof should probably stand as indicating a limitation in the current state of the art in formal proofs of security than the protocol design. What I propose using in a minimally PQC hardened exchange is: session = KDF (initial-exchange + initial-PQC + ephemeral-agreement) That is one option but not the only one. There are 0) Classic initial, no forward secrecy 1) Classic initial + PQC initial, no forward secrecy 2) Classic initial + PQC initial, classical forward secrecy 3) Classic initial, classical forward secrecy + PQC forward secrecy 4) Classic initial, PQC forward secrecy 5) Classic initial + PQC initial, PQC forward secrecy 6) Classic initial + PQC initial, classical forward secrecy+ PQC forward secrecy etc. Given that Google has spent the past five years telling people that security signals absolutely don't work, they are going to face a billion dollar anti-trust suit from certain CAs if they then try to provide a new security signal to show off support for PQC crypto. So persuading sites to deploy PQC support might be challenging. The big difference between PQC initial and PQC forward secrecy is that if the PQC agreement is going to take place as an initial key agreement, the public key has to be attested by the TLS server certificate. It is this move that makes '0RTT' possible. As I keep saying, 0RTT is not really a thing, we just have clever ways to conceal parts of the protocol by moving them into a different protocol. If we want Kyber to work as 0RTT, we have to use the same techniques. Not sure if I follow, so apologies in that. We already have a hybrid mechanism to add to the key exchange phase of TLS: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ The KDF functions used during the Key Schedule are not targeted by a quantum computer so if the initial master key is quantum-safe, so are the subsequent ones for the KDFs. The term 'interactive' is used very differently in protocol design and cryptography. DH and ECDH are mutual key exchanges. Alice and Bob both receive a shared secret that both contribute to equally. Kyber is a unilateral key exchange, Alice encrypts to Bob's public key without using her key. If we want to have a mutually authenticated key exchange, Bob is going to have to encrypt something to Alice's public key. That is correct. Such is the way KEMs work. We don't have that counterpart in post-quantum that we can attest to a high level of security. This is not so evidently needed in TLS but it is on Signal, OTR, and other protocols. I recently sent an email to the pqc mailing list around the matter: https://mailarchive.ietf.org/arch/msg/pqc/mW1r-57_OX7kAMGPef3noC4ZF_E/ Thank you, -- Sofía Celi @claucece Cryptographic research and implementation at many places, specially Brave. Chair of hprc at IRTF and anti-fraud at W3C. Reach me out at: cheren...@riseup.net Website: https://sofiaceli.com/ 3D0B D6E9 4D51 FBC2 CEF7 F004 C835 5EB9 42BF A1D6 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PQC key exchange sizes
to:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls> _______ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Sofía Celi @claucece Cryptographic research and implementation at many places, specially Brave. Chair of hprc at IRTF and anti-fraud at W3C. Reach me out at: cheren...@riseup.net Website: https://sofiaceli.com/ 3D0B D6E9 4D51 FBC2 CEF7 F004 C835 5EB9 42BF A1D6 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IET110: Agenda Topics
Dear Chair, On behalf of the authors, I would like to shortly present this draft: https://tools.ietf.org/html/draft-sullivan-tls-opaque-01 I'm requesting a 5 minutes slot. Best Regards, Sofía Celi -- Sofía Celi @claucece https://www.sofiaceli.com/ Cryptographic research and implementation at many places, but mainly at Cloudflare FAB9 3EDC 7CDD 1198 DCFD 4558 91BB 6B45 6F44 2D02 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] comments on draft-subcerts
Dear Nick and list, The PR is here now: https://github.com/tlswg/tls-subcerts/pull/79 Looking forward to been submitted to WGLC#2. Thanks! -- Sofía Celi @claucece http://claucece.github.io/ Cryptographic research and implementation at many places, but mainly at Cloudflare FAB9 3EDC 7CDD 1198 DCFD 4558 91BB 6B45 6F44 2D02 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] comments on draft-subcerts
Dear, list, Sorry for sending this past the last call. Few comments on the draft, which are: - On Section 1: "For clarity, we will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC"." I think this sentence can be their own paragraph, so it does not get lost with the rest of the text. It will be good to clarify as well the usage of 'credential', 'delegation', 'delegator' terms used through out the document. It will be really nice to clarify the term 'credential' as it sometimes seems to be used to refer to 'delegated credential', and sometimes to the 'Credential' struct. - On section 7.3 "Delegated credentials do not provide any additional form of early revocation. Since it is short lived, the expiry of the delegated credential would revoke the credential. Revocation of the long term private key that signs the delegated credential also implicitly revokes the delegated credential." Not sure how the implicit revocation will work. It is my understanding that the sole way to check that a DC is revoked is by verifying its valid time, and this is the way that renders it 'invalid'. Maybe, the DC is valid until it expires regardless if the long-term private key is revoked, as I don't see a way to mark the DC invalid when the long-term private key revokes. But perhaps, I'm understanding this incorrectly. In that case, how the DC signed by a revoked key will be treated? Should it wait until they expire to render them completely explicitly invalid? I have other minor editorial changes that I'll send as a PR. Thanks! -- Sofía Celi @claucece http://claucece.github.io/ Cryptographic research and implementation at many places, but mainly at Cloudflare FAB9 3EDC 7CDD 1198 DCFD 4558 91BB 6B45 6F44 2D02 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
