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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to