kemtls / draft-celi-wiggers-tls-authkem

IETF drafts that describe AuthKEM and AuthKEM-PSK

KEM-based Authentication for TLS 1.3

This is the working area for the individual Internet-Draft, "KEM-based Authentication for TLS 1.3".

AuthKEM

• Editor's Copy
• Individual Draft
• Compare Editor's Copy to Individual Draft

AuthKEM-PSK

• Editor's Copy
• Individual Draft
• Compare Editor's Copy to Individual Draft

Building the Draft

Formatted text and HTML versions of the draft can be built using make.

$ make

This requires that you have the necessary software installed. See the instructions.

Contributing

See the guidelines for contributions.

draft-celi-wiggers-tls-authkem's Issues

Move DC to appendix

Should we use the functions of the high-level API of HPKE?

Like using SetupBaseS/R followed by a Export().

DTLS concerns

Ilari writes:

Reading the draft, it occurs to me that adapting it to work on DTLS (or unreliable CTLS) might require major and very challenging changes to DTLS 1.3. Especially with client authentication.

And 0-RTT client auth probably can not work in DTLS at all, since DTLS has no reliability for 0-RTT, unlike other handshake, which is reliable.

Fix Douglas Stebila last name

For some reason, Douglas Stebila's name got changed to 'Douglas Steblia' in the data tracker.
We should fix it in a new release of the draft.

Mixing signature-based with KEM-based authentication

We need to figure out what to do about the following scenarios:

Server uses AuthKEM, client wants to use signing algorithm

Probably fixable by mixing in '0' in the AuthKEM key schedule.

Server uses signing algorithm, client wants to use AuthKEM authentication

This might be tricky with the key schedule?

Split out KEX

Build AuthKEM-PSK on top of TLS pre_shared_key extension?

We could maybe see if we can build AuthKEM-PSK on top of pre_shared_key instead of reinventing the wheel.

Fix the AuthKEM-PSK abstract

Relation with HPKE

HPKE already registers a bunch of KEMs

Should we keep using HPKE?

• HPKE is used in ECH
• But TLS key exchange uses "plain" KEMs so HPKE is extra effort.
• LAMPS is putting "plain" KEM public keys in certificates; we'd have to import those into HPKE (which is certainly possible)
• On the plus side, HPKE has nice context separation that we are currently using in the draft.

Add motivation

We should add a section or discuss why will someone use kem-based auth.

cc./ @thomwiggers @chris-wood

Relation to OPTLS/semistatic

Mention that the auth secret is derived from both ephemeral and auth key exchange.

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.

https://mailarchive.ietf.org/arch/msg/pqc/ZXleiKjJzbHv7sYRas11Z4lIjlk/

Drop PQ KEMs

Document PKI considerations

• CSRs still rely on issuing (and ACME relies on CSR)

Restructure KEM API info input

The KEM API we use in AuthKEM makes use of HPKE's key derivation, which allows label inputs.

We currently concatenate the context info to the setup label, but we should instead put it into the export function. this avoids string concat.

AuthKEM traffic key computations mismatch

       [...]
SSc||0 * -> HKDF-Extract = Main Secret
            |
            +--> Derive-Secret(., "c ap traffic",
            |                  ClientHello...server Finished)
            |                  = client_application_traffic_secret_0
            |
            +--> Derive-Secret(., "s ap traffic",
            |                  ClientHello...server Finished)
            |                  = server_application_traffic_secret_0
[...]

The traffic keys are here shown to be derived from server Finished. This is not possible: we've not received/sent server's Finished yet when we already need to derive the client application traffic keys. The KEMTLS paper and analyses uses that these keys are derived from the complete transcript (unlike in TLS 1.3). Changing it to be derived from just client finished, I don't like so much.

Is cached_info the right extension for conveying the public key?

If we deliver the KEM public key via something that is not a certificate, should we use cached_info for conveying the public key digest/fingerprint?

Authentication concerns for the client authentication requests

Came up during the IETF meeting:

David Benjamin:

I'm concerned about authenticating the server's request to the client. Client certificate decisions can result in interesting side effects, like unlocking smartcards or prompting the user. Having something so visible not be authenticated is pretty scary.

Add `certificate_request_context` to KemEncapsulation message

For handshake authentication the value is hard-coded (null) but this value is used to distinguish post-handshake auth requests (of which there can be multiple existing in parallel because of reasons). It's probably good future-proofing if we don't omit this distinguisher.

Add example instantiations section

Inspired by Dennis Jackson's https://dennisjackson.github.io/draft-jackson-tls-cert-abridge/draft-jackson-tls-cert-abridge.html#name-preliminary-evaluation we should also include a brief section where we show the sizes of some instantiations.

Should we encrypt the Client's Certificate in PDK with psk?