Taking a step back from the crypto, I'm trying to make sure I understand the desired security properties. As I understand the situation:
- the client has a preconfigured key pair (X_c, Y_c) - the server is anonymous (i.e., doesn't have a valid TLS cert). - the server is preconfigured with information about each client (in this case, Y_c). And the desired property you are looking for is that: 1. The client authenticates to the server using X_c 2. The client will only connect to servers that know the per-client information Is this correct? Assuming it is, it seems like we could accomplish this with less change to TLS. Here is one proposal (warning: not at all analyzed so may be totally broken). - Have the client take on the TLS server role, and use RFC 7250 raw public keys. This addresses requirement 1. - Store a separate per-client value K_c (this can be derived from the X_c to ease the burden on the client) and use RFC 8773 external PSK with cert authentication to inject K_c into the key schedule. -Ekr On Mon, Mar 8, 2021 at 7:09 AM Scott Fluhrer (sfluhrer) <sfluhrer= 40cisco....@dmarc.ietf.org> wrote: > Again, last minute reviews… > > > > It would appear that the exact computations that both the client and the > server need to perform needs to be explicitly spelled out, as there are > several possibilities. > > > > Here is the one I could see that appear to have the security properties > that you appear to be looking for: > > > > Variable names: > > g – Well known group generator > > h – The secret generator that is private to the client and > the server > > z – The secret value known to the client; g^z = h > > x – The client’s ephemeral DH private value > > y – The server’s ephemeral DH private value: > > > > Client keyshare: > > This is the value g^x > > > > When the server receives this, he selects y (and retrieves the value h); > he then transmits (as his keyshare) the value: > > h^y > > and stirs the value (g^x)^y into his KDF > > > > When the client receives this (h^y), he computes: > > (h^y) ^ (x z^-1) > > (where z^-1 is the modular inverse of z modulo the group order), and stirs > that value into his KDF. > > > > With this protocol, it appears that the client needs to know not only h, > but also the value z. However, this really needs to be spelled out (and > run past the CFRG to check for subtle issues) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
