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>: 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
