On 10/30/2018 4:07 AM, Russ Housley wrote: >> On Oct 30, 2018, at 2:26 AM, Christian Huitema <huit...@huitema.net> wrote: >> >> On 10/29/2018 9:56 PM, Martin Thomson wrote: >> >>> You should do something more concrete with the label parameter. Keep >>> in mind that both client and server need to agree on a use for this, >>> so my initial intuition to put the server identity might not work, but >>> it could be a start. The problem being that how the client identifies >>> the server might not be something it shares with the server. >> There is also a privacy issue with the external identifiers. For session >> tickets, this is solved by only using a given resume ticket once, but >> that's harder with external PSK. > Christian: > > Proclaiming that you have access to a particular external PSK may reveal that > you as part of a group. I do not see a way to completely avoid this because > the PSK is input to the key schedule at the very top. Thus, there is no key > that could be used to encrypt it.
You do have a shared secret, the PSK itself. In the DNS SD privacy proposal, we construct an obfuscated key identifier as base64(nonce|truncated(hash(nonce|PSK))). In the simplest form, the nonce is chosen randomly by the client, and the server has to try all available keys until it finds one that matches. We were worried about the compute cost of many trials, so we specified a "predictable nonce" set to a "rounded time" -- in our case, the most significant 24 bits of the 32 bit Unix time. The server would only have to compute the set of hashes and potential identifiers once per time interval. But that's of course a trade-off between obfuscation and compute costs. We were somewhat concerned about replay attacks, but that's a general problem with PSK. An attacker could repeat the client hello, and see whether the server's response provides information about the server identity. Hopefully, TLS 1.3 takes care of that. My point however is not to propose specific solutions, but rather to ensure that the documents that we produce acknowledges the privacy concerns with key identifiers. Once we agree that this is indeed an issue, we can debate the appropriate solution. -- Christian Huitema _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
