Reusing psk identities enables client and server tracking

[emanjon]

1287

[emanjon]

1289

Added server tracking by changing the heading. The rest of the text talks about connections and therefore apply to both client and server tracking.

[martinthomson]

A PSK identifier could be a nonce (random), plus an encryption of the true identifier, using that nonce as input to the key derivation process. There are options for similar protections that use something like FPE (such as this), but they might not be strong enough to pass serious scrutiny as a generic mechanism.

[emanjon]

I don't agree that SHOULD NOT and MUST NOT are almost the same. In some cases the difference between SHOULD NOT and MUST NOT can be drastic with people treating SHOULD NOT as "I don't need to change" and MUST NOT as "Ok, I actually need to change". That said, recommendations for what to do is certainly needed.

I think there are at least three strategies inside TLS 1.3:

• Use the external psk identifier the first time and then use a new ticket for each new connection. It is hard to see why ticket reuse is "SHOULD NOT" and general psk identifier reuse is not. In many external PSK use cases it would be preferable to reuse the ticket instead of reusing the external psk identifier. The requirement that "Servers MUST NOT use any value greater than 604800 seconds (7 days)" could maybe cause problems here. Using long lived tickets seems very much preferable to reusing a psk identifier.
• Use long connection. With key_update this is possible.
• Use Encrypted Client Hello.

There are also things that can be done outside of TLS.:

• As Martin says one option is to encrypt the psk identifier. This is what 5G does to mitigate the serious problems with IMSI catchers. This will hopefully be mandatory in future mobile networks.
• You can have encryption on a layer (IP, MAC) below TLS.
• You can derive a new psk identifier as new psk identifier = HMAC(psk, old psk identifier).
• You can use PSK for a single full handshake and then get a new PSK for next full handshake.

I think there are a lot of solutions here both in TLS and for the application and they can potentially be used together. If some use case does not have a strategy for how to mitigate this type of tracking and fingerprinting, then I think it is hard to recommend the use external PSK at all.

Even a mechanism that does not give 100% privacy is probably much better than always reusing a single psk identifier for a long time, sometimes decades.

[ekr]

I agree that this is a real issue but I also think that the SHOULD NOT is too strong given the state of the art. I don't really think that a SHOULD NOT is that great. PR #1294 takes a more descriptive approach.

[ekr]

I am closing based on PR #1294.