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

From: Robert Relyea <[email-masked]>
Date: Thu, 20 Sep 2012 16:54:41 -0700

On 08/29/2012 01:08 PM, Adam Langley wrote:
> On Wed, Aug 29, 2012 at 3:54 PM, Daniel Kahn Gillmor
> <[email-masked]>  wrote:
>> 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.
> DH/ECDH certificates would allow a private key holder to decrypt other
> connections made with the same client certificate.
So there are no TLS/SSL cipher suites where the clients have DH/ECDH 
certificates. Client auth certs are always signing certs.

There are Ciphers where the server has a DH or ECDH cert, but the client 
exchange keys are all generated on the fly by the client. Each one would 
have a unique key and the others could not read it.

I'm not quite sure why you want to have a single key in these cases, 
though. Signing key provisioning is pretty cheap... at least as cheap as 
trying to distribute pregenerated key/cert pairs. You can still keep 
everyone in the same group with a rather anonymous certificates. With a 
singer key/cert pair you have a pretty nasty recovery issue if you have 
a private key compromise (and such a compromise seems more likely then 
the normal client situation).

bob
>
> 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.
Adam is correct. And since all client auth certs are signing certs, you 
are safe in general.
>
> "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
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls