Hiya, On 13/10/17 15:29, Eric Rescorla wrote: > 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.
Pre-pending a fixed length (known to both sides) load-balancer ID would be fine, sure. That'd change the function to something like: next-id = lb-id || H(foo||prev-id) So long as each load balancer is busy enough that still has the hard-to-link property I think. The length of the lb-id could be fixed or part of the negotiation, with zero being a fine length when there's no lb-id needed. I think this'd work ok regardless of who controls the initial id value, so long as we don't need ids to work like tickets (where the id value would be the ciphertext of some state info). > > 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). Yes, schemes like this can be worse when packets go missing around the time of an id change. However, I think with this scheme (which isn't even on a napkin yet, just these mails:-), the sending side would just make the change when they want, and wouldn't signal that it's changed the id. So, in some cases (say if receivers store current and next, and id changes and packet losses are infrequent) a single packet drop would be just that and the id change wouldn't affect things at all. In the putative nb-IoT case I mentioned before then it could be a good bit worse unless the receiver stores a bunch of future ids. (I agree some work is needed to figure out if there's an acceptable scheme here, so for now I'm arguing that we not preclude such schemes when adopting your draft.) In figuring this out, I'd argue that we ought be comparing ideas like this against two things: 1) the simplest solution that does allow linkabillity and 2) the costs of setting up a new TLS session to avoid linkability. While this or similar schemes will look bad compared to (1), they will likely look pretty good compared to (2). Of course, how one evaluates such comparisons will depend on how serious a threat one considers linkabillity. I'd argue that many devices that'll need connections ids will be devices where the possibility of linkability could be a significant threat and where new TLS session establishment will be rare, so we therefore ought provide some good method of avoiding linkability. Cheers, S.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls