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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
