Re: [Pqc] [TLS] Did TLS AuthKEM die?

[Thom Wiggers <[e-mail]>]

Hi all,

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.

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.

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.

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 :-)

Next, replying to John's comments:

Op di 24 jan. 2023 om 19:32 schreef John Mattsson <john.mattsson=
[e-mail]>:

> 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]. Naturally, that doesn't say anything about mTLS
deployments in e.g. service-to-service or IoT contexts. The
'pre-distributed key' version of AuthKEM (which relies on much-easier to
manage public keys) may be a remedy in some of those deployments, or be
used with caching, to at least avoid the full handshake penalty most of the
time.



> 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.

- “these proposals require a non-interactive key exchange”
>
> My understandaing of NIKE is that the parties do not have any interaction.
> One example of NIKE is static-static DH. OPTLS uses ephemeral-static DH.
> I don't think it is correct to describe that as NIKE.
>
> https://eprint.iacr.org/2012/732.pdf
>

Ephemeral-static DH key exchange is also exactly what I would describe as
NIKE: you just get a unilaterally authenticated secret instead of a
mutually authenticated secret. Following the terminology in the linked
paper (slightly simplified), you need exactly the SharedSecret operation:

server_authenticated_ss = SharedKey(servers_sk_static,
client_pk_ephemeral).

The "lack of interaction" lies in the fact that the computation of the
shared secret has only this single operation and that it requires no more
communication than the exchange of public keys, unlike KEMs which have
Encaps and Decaps and require the exchange of a ciphertext: indeed, there
is no way of doing static-ephemeral with a KEM-style API.

 - The document could mentioned that to derive the
> application_traffic_secret, an attacker needs more than a single private
> key. Having a single ephemeral private key is no longer enough as it is
> the case in ordinary certificate based TLS 1.3.
>

Thanks! We must have missed pointing that out. I put it on the list for a
next revision:
https://github.com/claucece/draft-celi-wiggers-tls-authkem/issues/22

Cheers,

Thom

[0]: M. Birghan and T. van der Merwe, "A Client-Side Seat to TLS
Deployment," *2022 IEEE Security and Privacy Workshops (SPW)*, San
Francisco, CA, USA, 2022, pp. 13-19,
https://ieeexplore.ieee.org/document/9833861.
Unfortunately, I couldn't find an open access source, but they measured TLS
usage from Firefox on a big scale. The relevant data point is: out of all
of the hundreds of billions of TLS connections they measured, they only saw
three (!!) instances of mutual authentication in the handshakes.
Post-handshake authentication was used <6000 times per day in web browsing,
out of 32-66 billion connections per day.

* I should have a job after finishing my PhD that will allow me to keep
being involved in these kinds of discussions :)