On Fri, 2016-07-08 at 09:29 +0000, Fossati, Thomas (Nokia - GB) wrote: > > > > How would the hash chain matching work for a server handling > > > > multiple > > > > clients? > > > Sorry, I'm not sure I understand the question. Are you asking > > > what > > > happens if there is an Id collision between two separate hash > > > chains? > > No, my question is much simpler. How would a server handling for > > example 20000 clients, will figure to which chain a hash of H(x) > > belongs to? Will it have to iterate through all the chains (client > > states) and test for matching or there is something more clever > > than > > that? > Ah! The hash chain would be computed at the end of the handshake, so > all L > Ids can be put in a hash table that maps them to the same DTLS > context. > When a data record comes in, its Id can be used to look up the > context in > O(1). > Clearly the server needs to negotiate a sensible L if it doesn't want > to blow up.
As long as both the client and the server are able to notify each other that they only support L=1 I'd be content with it. However, I'd prefer a simple solution and defer the hash chain negotiation for a separate extension, since we cannot foresee how and if such an extension will be used. As we saw with heartbleed any unused complexity is not necessary adding value. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
