Hi Nikos, On 08/07/2016 10:55, "Nikos Mavrogiannopoulos" <n...@redhat.com> wrote: >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.
In the straw man I proposed above, it is sufficient for the server to say L=1. In that case the client will trigger a re-handshake when its Id rollover policy says so. >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. I wholeheartedly agree on the implementation simplicity goal. I think the proposal allows both sides to be as simple as they want to. Cheers, t _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
