Blumenthal, Uri wrote: >Without getting into details – EDHOC is still more “verbose” than CAKE-HI, >thus – not >“minimalistic” (which was one of our design goals).
The overhead except key shares and MACs in EDHOC is typically 21 bytes. If your protocol uses the NIST PQC algorithms with their large public keys and encapsulation sizes, I have a hard time to see that this “verbosity” (EDHOC has type and length for all fields so that it can be parsed without an agreed template) would matter much in practice :) John From: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> Date: Friday, 27 January 2023 at 16:09 To: loic.ferre...@orange.com <loic.ferre...@orange.com>, Thom Wiggers <t...@thomwiggers.nl> Cc: John Mattsson <john.matts...@ericsson.com>, Mike Ounsworth <Mike.Ounsworth=40entrust....@dmarc.ietf.org>, p...@ietf.org <p...@ietf.org>, tls@ietf.org <tls@ietf.org> Subject: Re: [Pqc] [TLS] Did TLS AuthKEM die? Thank you Uri. My pleasure. Then what about CAKE-HI vs. EDHOC? Ah, a good question – with a less-technical answer. Without getting into details – EDHOC is still more “verbose” than CAKE-HI, thus – not “minimalistic” (which was one of our design goals). At this point, EDHOC is not PQ, which precludes it from being evaluated and considered in our use cases. If DH in EDHOC is replaced by a PQ KEM – the numbers will start favoring CAKE-HI, but at this time is doesn’t look like there’s interest to make EDHOC Quantum-Resistant. I’d say CAKE-HI could replace EDHOC, if and when Quantum Resistance is needed (and the channel can tolerate larger packet/message sizes), and when template-based approach is preferred to online negotiations. By the way is there any specification of CAKE-HI available? In the process of “release review”. ;-) Thanks! Orange Restricted De : Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> Envoyé : jeudi 26 janvier 2023 21:08 À : FERREIRA Loïc INNOV/IT-S <loic.ferre...@orange.com>; Thom Wiggers <t...@thomwiggers.nl> Cc : John Mattsson <john.matts...@ericsson.com>; Mike Ounsworth <Mike.Ounsworth=40entrust....@dmarc.ietf.org>; p...@ietf.org; tls@ietf.org Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die? How would you compare CAKE-HI and cTLS? Loïc, an excellent question. Naturally, there are similarities and differences. Similarities: 1. Both strive to reduce unnecessary communications; 2. Both strive to avoid unnecessary negotiations; 3. Both embrace “template-based specialization” that allows avoiding negotiations altogether (if I understood this part of cTLS correctly). Differences: 4. Different purpose: 1. cTLS is a compact Transport Layer Security that protects user data , and includes key exchange (as one of the mechanisms it utilizes to achieve its goal). 2. CAKE-HI is a Key Exchange protocol that provides session keys (shared secret(s)) to other protocols that handle user data. 5. Different degree of “minimization”, as CAKE-HI is much more minimalistic than cTLS: 1. cTLS tries to create a “leaner TLS” by paring the “fat” of TLS, backward-compatibility with TLS 1.2, etc. But quite a bit of TLS details remains there. 2. CAKE-HI has nothing in common with the TLS handshaking, options, syntax, fields, and such. It has a set of cryptographic primitives that it employs to generate symmetric shared secret and satisfy security properties listed below. 6. Thus, CAKE-HI cannot replace cTLS, (among other reasons) because by itself it does not provide user data protection (and requires another protocol, like SCIP to handle that), nor can cTLS “replace” CAKE-HI because it does a lot of things unnecessary for “pure” key exchange and carries more overhead than a truly minimalistic AKE needs. On the sad part, CAKE-HI specification (actually, we’ll most likely present CHAKE-HI, aka – Compact Hybrid Authenticated Key Exchange Hiding Identities) lags behind in details that have been provided in cTLS ID (https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.html <https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.html>). But we’ll get there. ;-) I realize the above is rather sketchy – please feel free to ask more questions, and I’ll do my best to answer them. Thanks! Orange Restricted De : Pqc <pqc-boun...@ietf.org <mailto:pqc-boun...@ietf.org>> De la part de Blumenthal, Uri - 0553 - MITLL Envoyé : mercredi 25 janvier 2023 22:49 À : Thom Wiggers <t...@thomwiggers.nl <mailto:t...@thomwiggers.nl>> Cc : John Mattsson <john.matts...@ericsson.com <mailto:john.matts...@ericsson.com>>; Mike Ounsworth <Mike.Ounsworth=40entrust....@dmarc.ietf.org <mailto:Mike.Ounsworth=40entrust....@dmarc.ietf.org>>; p...@ietf.org <mailto:p...@ietf.org>; tls@ietf.org <mailto:tls@ietf.org> Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die? I'll first ask the first question, and then try to clarify a few of the other things raised in this thread. > Is AuthKEM dead? I'd say it's hibernating. The draft has indeed expired: there was nothing significant to add since the last time we edited/updated it. I also couldn't make it to the last two IETF meetings (and due to conflict with Real World Crypto, I will most likely not be able to make IETF116 either). The TLS working group has seemed to want to focus on getting PQ key exchange out of the door, but if it's ready to continue the discussion on post-quantum authentication (which should include some other things like OCSP and CT), I'd be very happy to continue the discussion and work on AuthKEM. We have a simplified protocol (CAKE-HI) inspired by and based on AuthKEM. Being simplified, CAKE is not really suitable for TLS. Thus, we’d like to see AuthKEM progressing within the TLS WG. One change that we'd probably like to make soon is to include Kyber-based (hybrid / PQ/T) KEMs -- once those KEMs have been hammered out for the ephemeral key exchange. Yes, something worth discussing. I am currently working hard on wrapping up my PhD thesis* (which is largely on post-quantum TLS and KEMTLS in particular). This is another reason why the draft has been sitting there for a while. To me, right now, most of the "homework" behind the AuthKEM/KEMTLS proposal feels pretty "finished"; I'd argue we have some form of running code (as in the various KEMTLS experimental implementations we did for the academic work are pretty close to AuthKEM). We also have proofs, both pen-and-paper and two Tamarin models. If anyone has suggestions for concrete next steps, perhaps in which AuthKEM solves a problem that they're seeing, let us know. But in the end, AuthKEM, as any IETF WG proposal, can't get pushed over the line by some ivory tower academic like myself --- we will need people coming out and saying they want to have this. For TLS we want AuthKEM. For other protocols – we have a similar alternative. ;-) By the way, if anyone wants to discuss KEM-based authentication for other protocol(s) by the way, I am always happy to talk, for example in the new PQUIP wg that's also addressed :-) Please count me in. ;-) Next, replying to John's comments: Op di 24 jan. 2023 om 19:32 schreef John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org <mailto:40ericsson....@dmarc.ietf.org>>: Using ephemeral-static ECDH for implit authentication as in the Noise protocol has several benefits. The benefits of using KEMs instead of signatures seem more limited. The current proposal requires 3 full round-trips instead of 1.5 round-trips for mutual authentication. If I understand correctly, the messages sizes are smaller than Kyber+Dilithium but similar to Kyber+Falcon (probably a bit larger in total). Indeed, our mutual authentication story with plain AuthKEM is pretty weak; but to be fair, it appears mutual authentication is extremely rarely used in web browsing [0]. True. But as far as I’m concerned, web browsing is somebody else’s problem. ;-) If continued, I think Kyber KEMs makes a lot more sense than ECDH KEM. For ECDH KEM you can do something much more efficient. Naturally, OPTLS/draft-semistatic are indeed more elegant given DH/NIKE. I'd argue that we're looking at a KEM-based future, though: AFAIK we currently still don't have any satisfactory answers to the PQ NIKE question: CSIDH's security is still a big, on-going discussion, CSIDH is also awfully slow, and SIDH-based solutions (not to be confused with CSIDH) seem dead in the water. If any new proposals pop up, they will probably not have seen much cryptanalysis yet. I concur. TNX _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
