On 12/8/2023 6:57 AM, John Mattsson wrote:
That seems like a good start. I think it would be good the TLS WG came up with additional guidelines/mechanisms/requirements for doing External PSK in a secure way that does not enable tracking. Using the same External PSK identifier for a long time should be discouraged. Maybe ECH is the solution. That would however be outside the scope of RFC 8773.
I spent a lot of time studying a related problem with DNSSD. It is very hard, and we could only find partial solutions.
One approach is to encrypt the PSK identifier using the public key of the destination. That works nicely if we suppose that the clients have somehow acquired that public key, maybe using a setup similar to ECH. But it supposes that the encrypted result is reasonably short so it can fit in the Client Hello without blowing its size. I am concerned that this will not work well using post quantum public keys.
Another approach would be to use symmetric key cryptography. Of course, we cannot really assume that random clients will have access to the encryption key chosen by the server. But we could have a system in which clients are provisioned with a set of equivalent encrypted identifiers. That approach works for Session Resumption Tickets. They are provisioned by the server, and the best practice is for client to use them only once. The downside is that this encryption typically uses Session Ticket Encryption Keys that are short lived and frequently rotated. That's a good fit for session resumption, but not so much for long term PSK.
If neither STEK nor public keys are adequate, we could use trial encryption. Encrypt the PSK-ID using the PSK, and let the server do trial decryption by going through the list of provisioned PSK. Your guess as to whether this is acceptable is as good as mine.
-- Christian Huitema _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
