Subject: Re: [TLS] Comments on draft-friel-tls-eap-dpp-01

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Mon, 14 Jun 2021 17:38:08 +0000

I have this working on mint - PSK derived from DPP public/private keypair, leveraging RFC7250 and RFC8773, was about to fixup draft, but realise that we need a flag in the ClientHello to signal to the server that it is a special PSK derived from the public part of the public/private keypair.

This could be done via an extension, similar to RFC8773 tls_cert_with_extern_psk, or Richard pointed me to this: https://chris-wood.github.io/draft-tls-extensible-psks/draft-group-tls-extensible-psks.html

Chris, Ekr, I think this could be a good mechanism to define a new type for this derived PSK, rather than a new ClientHello extension.

Thoughts?

From: TLS <[email-masked]> On Behalf Of Owen Friel (ofriel)
Sent: 11 March 2021 00:26
To: Eric Rescorla <[email-masked]>; Dan Harkins <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] Comments on draft-friel-tls-eap-dpp-01

[ofriel] Another requirement is that the full public key Y_c is not transmitted as part of TLS handshake from client to server. We cannot not use RFC 7250 as is. Instead, something like the Known Certificates proposal in cTLS https://tools.ietf.org/html/draft-ietf-tls-ctls-01#section-5.1.3 would work.

Is that a primary requirement or a derived requirement?

  I'm not sure of the distinction you're making here.

Well, once again, it seems like the technical requirement is that:

1. You want to authenticate the server to the client (as noted below, I don't think that the distinction
you are making between "assurance" and "authenticate" is sufficiently crisp to be helpful).
2. The only secret information that the server shares with the client is Y_c.

But this doesn't necessarily preclude the client *sending* Y_c, it merely requires that
it not send it to anyone who hasn't proven they know Y_c first. For instance, if Y_c
was used as a PSK (as owen suggests), then it might (again, no analysis here)
allow the client to send Y_c in an RFC 7250 certificate message because it would
already be being encrypted under a key that required knowing Y_c.

[ofriel] This makes sense, and should avoid having to use cTLS ‘Known Certificates’ for the client’s Certificate RPK.