On Mon, 2016-09-19 at 09:53 -0700, Eric Rescorla wrote: > > Perhaps I should turn your question round, and ask: if PSK is a first- > > class citizen as a key exchange and authentication method, why *should* > > we be forbidden from resuming sessions which started that way... > > Well, I'm not saying you can't do that. As I said, you can use HRR if the > resumption > fails.
I suppose that's an answer in the general case too, isn't it? If you want to try multiple identities, you can just keep trying with HRR until you find one that the server accepts. In fact, it doesn't even need to be "keep trying until...". You could still offer multiple PSK identities in the ClientHello, and only offer a hello_finished MAC for the *first* (preferred) one. If the server doesn't want that one, it can send a HRR with a PreSharedKeyExtension that tells the client which one it *does* want. You preserve the original behaviour of negotiating which PSK identity to use, while also fixing the problem that limits you to just one. < ...context switching to my actual use case... > > > > 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. In theory it would work to use the existing identity in the ClientKeyExchange in TLS1.2. However, in practice it becomes extremely painful to do so because the ClientKeyExchange comes in too late. 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. 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. I suppose I can just say 'screw it' and continue to abuse the session-id for this without actually resuming a session :) -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
