[TLS] AuthKEM: Splitting the draft and next steps

[Thom Wiggers <[e-mail]>]

Hi all,

It has been a while since I have had time to work on the IETF draft for
AuthKEM (``draft-celi-wiggers-tls-authkem``, aka "KEMTLS"), and some of you
have previously asked when the draft (which is currently expired) will be
updated. In this email, I want to pick up the work again.

Specifically, I want to do the following:

* Split the proposal in two parts for improved legibility and applicability
to use cases
* Once this is done and in a good shape, move forward towards consensus
with the aim of adoption

I will now describe the plan in more detail. I am welcoming further
suggestions, and would like to hear if these changes make sense and are
appreciated. If nothing else, you're welcome to help bikeshed draft names.
:-)

The draft currently describes TLS authentication via KEM ("KEMTLS
authentication") and TLS-PSK-style abbreviated handshakes via KEM
(KEMTLS-PDK). The TLS authentication and the abbreviated KEM-based
PSK-style handshake probably are independently interesting. The two
proposals can be split and this would hopefully make evaluating them
easier. AuthKEM and "pre-shared KEM" can be independently implemented.

"Plain AuthKEM" is useful for mitigating the cost of post-quantum signature
schemes in "regular" TLS handshakes. Use of plain AuthKEM can be especially
attractive to devices that want to use mutually authenticated TLS, but
would like to re-use the (e.g. protected) implementation of the KEM
algorithm for ephemeral key exchange. Compared to Dilithium2, use of Kyber
also offers significant space savings.

"KEM-PSK" is interesting for embedded or IoT applications that currently
are using symmetric-key PSK with ephemeral key exchange. Using KEM-PSK
avoids symmetric-key key management issues, such as protected storage and
key distribution, while allowing PSK-style abbreviated TLS handshakes.
Meanwhile, no additional code is needed over the ephemeral key exchange
algorithms. (In the future, we could even investigate additional mechanisms
to distribute the server’s public key, such as putting it in HTTPS records
alongside ECH, to allow more clients to use the abbreviated handshake.)

I hope to get these changes done over the coming weeks, but I doubt it'll
be ready for IETF 117. But, as stated above, I do not want to drag this
forward in the unadopted state forever—it's been long enough already. So
once refactoring has happened, discussion has settled and consensus has
been reached, I intend to ask the chairs for a call for adoption.

Cheers, and thanks for your comments,

Also on behalf of my co-authors,

Thom
PQShield

PS: we moved the Git repository to
https://github.com/kemtls/draft-celi-wiggers-tls-authkem