On 05/07/16 14:49, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- >> On 04/07/16 20:54, Nikos Mavrogiannopoulos wrote: >>> >>> where id is sent by the server to the client either via an extension, or >>> by simply assuming that the client will copy and keep the ID seen at the >>> server packets (it doesn't really matter that this ID is unprotected as >>> it doesn't contribute nor affect the security in any way). >> >> Does that id need to be static? If so, then it'd act as an >> additional way to track a user roaming over different IP and >> ports. That'd be a pity. If such an id is useful, maybe there's >> a way to allow it to change as well, in a way predictable for >> the server. > > Could be, but I don't have a use case for such
Hmm. I'd hope we can all share a use case of bring more privacy-friendly where possible and of not introducing changes that are privacy-unfriendly unless absolutely unavoidable. Adding a new identifier that doesn't change despite changes in client IP address etc. seems like it fails if one has the "use case" above in mind. Actually, the above is not really a use-case, but is nonetheless something on which I think we ought be able to agree so not all changes need to correspond to some use or abuse case:-) > a switch nor can think something > obvious, what do you have in mind? I've no specific proposal. If it were the case that a new cleartext identifier is wanted, then there could be ways in which that can be modified (e.g. a hash-chain based on something known to both client and server but not sent in clear) so that the server can know then next "N" ids to be expected but an observer can't use these to re-identify a client. S. > > regards, > Nikos >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
