Subject: [TLS] shared secret keys between TLS clients: specific risks? OK in certain suites?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 29 Aug 2012 15:54:16 -0400

Hi TLS WG--

This is a hypothetical question about an unusual use of TLS, a scenario
which goes against all my instincts about reasonable key management.
I'm hoping for any insight or analysis that might help me understand the
specific risks.

Consider a TLS server that requires client-side key-based
authentication, but doesn't actually need (or want) to know which one of
a group of clients is connecting.

Let's say the operator of this TLS server creates a single secret
asymmetric (RSA or ECDSA or DSA) key (and corresponding X.509
certificate), and shared the same key each one of the group of several
clients.

I'm also fine assuming that both the server and the clients will insist
on negotiating a non-NULL cipher suite (maybe even a specific one if
necessary), are compliant with TLS 1.2, are extension-capable, and
refuse to negotiate down to an earlier version of TLS.

Is there a way that one such client (with a copy of the secret key used
by the client group) could snoop on (or inject traffic into) a
connection established by one of the other clients that share the key?
Or would this depend on the cipher suite selected?  Clearly, at least
PFS in the face of client-key compromise is a pre-requisite here; i note
that several of the existing PFS notes deal with the concept of the
server's secret key being compromised, but don't mention if a
compromised/shared client-side secret key has the same implications.
And of course PFS doesn't itself address the possibility of active
attacks.

Alternatively, if we think the one-secret-key-per-party assumption for
asymmetric keys is deep enough that we shouldn't even consider use cases
that violate it: would something like RSA-PSK be possible for the same
approach (multiple clients, same PSK on each client) as a way to avoid
asymmetric keys on the client?

Are there other risks besides client-to-client snooping/tampering
associated with this scenario?

Any other thoughts or observations or specific risks worth considering
in this context?

Regards,

    --dkg

---

From: Adam Langley <[email-masked]>
Date: Wed, 29 Aug 2012 16:08:07 -0400

> I'm hoping for any insight or analysis that might help me understand the

DH/ECDH certificates would allow a private key holder to decrypt other
connections made with the same client certificate.

I believe that a signature based (RSA/ECDSA) client certificate is
`safe' as a group authentication method in that one member of the
group could not intercept/decrypt a connection made by another.

"Group signatures" are a problem that has been studied and has a
practical solution:
http://crypto.stanford.edu/~dabo/papers/groupsigs.pdf, although the
bilinear group presents an implementation challenge. ("Group
signatures" in that case are defined to have slightly different
properties, see the paper.)

Cheers

AGL

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 29 Aug 2012 22:24:19 +0200

> connection established by one of the other clients that share the key?

Yes if the client and the server negociate PSK Key Exchange Algorithm
No if they negociate DHE_PSK or RSA_PSK Key Exchange Algorithms

Please refer to Section 2 of RFC4279 on the premaster secret formatting.

Best regards
Badra