On Mon, Sep 19, 2016 at 1:35 PM, David Woodhouse <dw...@infradead.org> wrote:
> On Mon, 2016-09-19 at 09:53 -0700, Eric Rescorla wrote: > > > > > I would address this either by: > > > > > > > > 1. Registering a new extension which is used to indicate the right > worker > > > > process, but using existing TLS 1.2 PSK. > > > > > > OK... except this basically *is* the PSK identity. So the new extension > > > we'd want to register, if we want to make it something that's useful in > > > the general case rather than an application-specific hack, *is* > > > basically draft-jay-tls-psk-identity-extension :) > > > > No, I don't think that's true. That extension also attempts to actually > > negotiate the keys in that layer. I'm just talking about a hint. > > It's more than just a hint. It is saying precisely which client it is, > which has a 1:1 correspondence with which PSK it's using. > Call it a promise, if you prefer. One that you fulfill with the CE. 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. > > So I really do think that draft-jay-tls-psk-identity-extension was > *exactly* what I wanted. I don't care about *negotiating* the PSK > identity per se; I'm happy to support only one. It's purely about > *telling* the server, in the ClientHello, which identity I'm using. > See above. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
