On Mon, 2016-09-19 at 14:13 -0700, Eric Rescorla wrote: > > > It is purely a matter of software architecture — the initial > > incoming > > UDP packets reach a dispatcher that needs to hand the connection > > off to > > the appropriate worker process for that client.... and *really* > > wants > > to make that decision based on the ClientHello alone. > > > > If we *start* the handshake in the main dispatcher and get to the > > point > > of seeing the ClientKeyExchange, we have to hand over the > > partially- > > completed handshake (or keep going and then hand over a fully- > > completed > > handshake) to the appropriate worker. And in fact I don't even > > think > > the dispatcher *has* the actual keys; only the identities so that > > it > > knows where to dispatch connections to. > > See above. The key advantage of what I am proposing here is that it > has > exactly the same cryptographic properties as current TLS-PSK, with > the > indicator just serving as a routing-ID.
We've decided to take that approach. What we have currently is described at: https://tools.ietf.org/html/draft-mavrogiannopoulos-app-id-00 Comments are welcome. regards, Nikos _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
