Subject: Re: [TLS] extending the un-authenticated DTLS header

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 15 Nov 2016 10:21:40 +0000

Sort of.  Client uses one HOTP value from the sequence at a time, until it sees fit — for example, until it's on the same network attachment.

When attachment changes (and its transport identifiers with it), before sending a new packet, it picks the next HOTP and sticks it in the record.
When Server sees this, it switches CID accordingly.

From: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 15 November 2016 10:12
To: "Fossati, Thomas (Nokia - GB)" <[email-masked]<mailto:[email-masked]>>
Cc: Nikos Mavrogiannopoulos <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ALU] Re: [TLS] extending the un-authenticated DTLS header

Okay, so you are saying that every packet has the same number?

On 15 Nov 2016 6:30 PM, "Fossati, Thomas (Nokia - GB)" <[email-masked]<mailto:[email-masked]>> wrote:
On 15/11/2016 09:20, "TLS on behalf of Martin Thomson"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>This means that you can guarantee privacy, but it forces
>the server to do an exhaustive search of all of its active connections
>(that is, O(N)) when it gets a 5-tuple mismatch.

I don't think I follow.  You'd use CID as primary key to index your
security contexts.  So, regardless your 5-tuple matches or not you'd do
your O(1) lookup in the CID table and find the associated security context.