Re: [TLS] Connection ID Draft

[Stephen Farrell <[e-mail]>]

Hiya,

On 13/10/17 14:56, Eric Rescorla wrote:
> I've seen a number of designs like these, but in general they
> have quite poor scaling properties. Can you describe the precise
> design you have in mind so that we can analyze it.

Sure, I can try...

What I'm suggesting is that we define a way that a TLS
node can change the connection ID to a new value that
is hard to link to the old, as a function that can be
used when the implementation chooses to use it.

I'm not currently arguing that the ids should be changed
for each packet. E.g. if a node is able to detect that the
5-tuple has just changed, it could use this then. If a
node sends one packet per day over say an nb-IoT network
where it might have a different IP address each time (not
that we know how nb-IoT will operate, so I'm guessing:-)
then it might make sense to do this for every packet.

I assume ids are initialised in some reasonable way.

To change an id, pick a value foo that depends on the TLS
session, e.g. like an extractor, and that is not visible
to the network. Then set next-id to H(foo||prev-id) or
some similar construct.

Receivers can store a set of ids calculated when the
session is established. I'd guess storing two (current
and next) might be a sensible thing to do.

The inefficiently compared to simply incrementing the
id value is to add another column to the lookup table I
guess. I don't know if that's a big scaling deal or not.

Cheers,
S.