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 :)


Attachment: smime.p7s
Description: S/MIME cryptographic signature

TLS mailing list

Reply via email to