Re: [TLS] DTLS 1.3

[Stephen Farrell <[e-mail]>]

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
>