In short - yes please. Thanks!
Regards,
Uri
> On Jul 4, 2023, at 02:01, Thom Wiggers <t...@thomwiggers.nl> wrote:
>
>
> This Message Is From an External Sender
> This message came from outside the Laboratory.
> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
