Security considerations of using same cert for TLS client and server

[emanjon]

TLS WG went through a lot of work (RFC 9258) to make sure that PSKs only be used with a single hash function. But as far as I can see the RFC8446(bis) does not say anything about:

• Using the same cert for TLS client and TLS server
• Using the same public key cert for TLS and another protocol (JOSE, COSE, SMIME, IKE, etc, ….)
• Using the external PSK for TLS and another protocol.

I think it should.

• Using the same signature key or PSK for TLS and another protocol is obviously unsecure in the worst case. But probably practically secure in many cases even if nobody has proved it.

• Did any of the formal analysis prove that using the same key for TLS client and server is secure? It is quite common that the same node is a TLS server and client.

[ekr]

I don't think we know much about this, so I'm reluctant to say too much. @karthikbhargavan, thoughts?

[karthikbhargavan]

Using the same key for client and server can result in unexpected reflection scenarios similar to Selfie (https://eprint.iacr.org/2019/347). So, for this to be safe, we need to be careful about knowing whether the context sufficiently disambiguates whether a principal intends to authenticate as a client or a server.

I'd have to look to see if there is a cryptographic analysis allowing for the same key to be used for both client and server authentication. I suspect not. Extending the symbolic analyses to do this seems easy, modulo the reflection scenarios mentioned above.

[davidben]

Reusing a TLS key in an arbitrary other protocol is clearly a problem. It's actually particularly bad for TLS 1.2 server keys because TLS 1.2 ServerKeyExchange signatures have an arbitrary, attacker-chosen prefix. (And then a server-chosen random value.) That's why TLS 1.3 has those 64 spaces in front.

I'm less clear on client/server reuse being a problem though. The signing payloads use different labels between client and server, so there's no cross-protocol mixups. And certificates are not as inherently symmetric as PSKs are. If a TLS client (conversely, server) is configured to accept some identity, that means it accepts any server (conversely, client) that is capable and willing to authenticate as that identity. If that set is multiple entities or includes itself, that's perfectly coherent.

(TBH, I'm quite unconvinced of Selfie as a real attack. PSKs are the same. If a TLS client accepts servers that use some PSK, it inherently accepts all servers that know that PSK and that are willing to use it in a server role. If this set includes itself in another context, cool. If this set wasn't intended to include itself, then configure TLS some other way!)

[chris-wood]

My take is that, in general, we ought to not encourage key reuse in different contexts, even we think the underlying protocol might make it safe to do so. So rather than say nothing, I would suggest that we prohibit it outright on the basis of good hygiene.

[ekr]

I tend to agree that better hygiene would be to not do this, but we also know it happens (e.g., with SMTP). Given that the purpose of this document is to mostly clarify 8446-bis, and implementations have been doing this for quite some time, I don't think 2119 language is warranted. PR #1300 tries to split the difference here.