On Fri, Oct 13, 2017 at 7:16 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > 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. > There are a number of cases where this is actually much harder to implement than a design where one side dictates the connection ID. For instance, consider a design where you have a pool of servers P1, P2, ... P_n with a load balancer in front. Each server i generates connection IDs of the form i || Random. The load balancer then just looks at the first byte and routes to the appropriate load balancer [0]. In this design, the LB can be totally stateless, whereas in the design you propose, it has to (a) have a back-channel to the server to get the initial conn-id (b), do crypto (c) store state for all the live connections. In addition, consider what happens when you get a CID you don't recognize. It might be nonsense but it might be that there was a cryptic CID change (e.g., the client did two changes but you missed a packet). You need to decide the number of changes you're willing to tolerate and then the table has to be that big times the number of connections (or you need to fill it in whenever you get an unknown CID, which the attacker can send you at any time). -Ekr [0] This has non-ideal topology-hiding properties, but there are obvious extensions with better properties.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
