Hi Uri, I'm afraid that like you I am not going to Yokohama, as I am attending RWC and HACS in Tokyo that week instead. While the AuthKEM draft has been sitting idle, I have been very busy, pretty much writing the book on it — my PhD thesis. I am sitting on a large pile of tables and benchmark results that show the impact of putting Kyber, Dilithium and Falcon at all NIST security levels into TLS (and KEMTLS/AuthKEM). Once I manage to get everything written up and submitted to the reading committee, I will see if I can extract some numbers for the TLS working group that are hopefully interesting, also independent of AuthKEM. Hopefully I have time to do so next month.
Otherwise, I think what I wrote in January [thread] still applies: > 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. Your email clearly indicates that you are in favor of AuthKEM. If others want to voice their support and/or have suggestions for the draft, a plan of attack, whatever; feel free to also let me know: maybe for IETF 117 can we dust off the draft, relate it to the NIST selections for signature schemes, and also see if the idea has support for adoption. Cheers, Thom PS. As mentioned, I will be in Tokyo for RWC and HACS, so I hope to be able to meet some of the TLS folks face-to-face again there :-) [thread]: https://mailarchive.ietf.org/arch/msg/pqc/AsLh6qEtJfn1EE1TTtSEXoZwZAE/ Op di 21 mrt 2023 om 21:55 schreef Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu>: > Richard, yes, you git it right. > > > > *From: *Richard Barnes <r...@ipv.sx> > *Date: *Tuesday, March 21, 2023 at 4:32 PM > *To: *Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> > *Cc: *tls@ietf.org <tls@ietf.org> > *Subject: *Re: [TLS] Resurrect AuthKEM? > > Hi Uri, > > > > Just to be clear, the AuthKEM draft you mean is this one? > > > > https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/ > > > > Assuming that's the case, in case anyone else is confused (as I was), the > "AuthKEM" here does not refer to a KEM implementing the AuthEncap/AuthDecap > interface from RFC 9180. Instead it refers to the construction in that > document, which uses a normal KEM. > > > > --Richard > > > > > > On Tue, Mar 21, 2023 at 2:34 PM Blumenthal, Uri - 0553 - MITLL < > u...@ll.mit.edu> wrote: > > I’m surprised to see that there isn’t much (isn’t any?) discussion of the > AuthKEM draft. > > > > It seems pretty obvious that with the advent of PQ algorithms, the sheer > sizes of signatures and public keys would make {cDm}TLS existing > authentication and key exchange impractical in bandwidth-constrained > environments, especially when higher security-level algorithms (like, > what’s demanded by CNSA-2.0) are required. > > > > Thus, implicit authentication (think – MQV, Hugo Krawczyk’s HMQV, etc.) > seems to be a-must for making the PQ impact on bandwidth somewhat > manageable. > > > > I would like this WG to resurrect the AuthKEM draft. > > > > I can’t be in Yokohama, and am not fanatical enough to spend nights on > XMPP or such. But hopefully, we can discuss AuthKEM approach here on the > list. > > > > Thank you! > > -- > > V/R, > > Uri Blumenthal Voice: (781) 981-1638 > > Secure Resilient Systems and Technologies Cell: (339) 223-5363 > > MIT Lincoln Laboratory > > 244 Wood Street, Lexington, MA 02420-9108 > > > > Web: https://www.ll.mit.edu/biographies/uri-blumenthal > > Root CA: https://www.ll.mit.edu/llrca2.pem > > > > *There are two ways to design a system. One is to make it so simple there > are obviously no deficiencies.* > > *The other is to make it so complex there are no obvious deficiencies.* > > * > > - > C. A. R. Hoare* > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
