Thanks Christian, I think all of the suggested solutions are viable with different tradeoffs. Actually, I think it is hard to find special cases where none of the solutions work.
>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. If you distribute the external PSK, I think you can distribute a public key as well. If the external PSK is derived that is trickier as the client has to fetch it from e.g., DNS. The size of ECIES is 32 bytes for the public key + overhead for the tag and a few bytes for any encoding overhead. I don't think quantum-resistance should be a excuse to not do anything. Using ECIES is much much better than sending the psk identifier in cleartext. >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. In many systems you can replace the external PSK quite often. In 3GPP the external PSK used in TLS are refreshed every week. >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. You can trial decrypt (symmetic crypto) quite many PSK-ID using the same number of cycles as an asymmetric signature. But if the server needs to fetch the PSKs from a database it might be problematic. I think mentioning that you can encrypt the PSK identifier and that the server can do trial decryption would be very good additions to Section C.4 of RFC8446bis that discusses tracking. Cheers, John Preuß Mattsson From: TLS <tls-boun...@ietf.org> on behalf of Christian Huitema <huit...@huitema.net> Date: Friday, 8 December 2023 at 21:25 To: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>, Russ Housley <hous...@vigilsec.com> Cc: IETF TLS <tls@ietf.org> Subject: [TLS] Privacy and PSK identifiers (was Re: Call to Move RFC 8773 from Experimental to Standards Track) 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
