Re: [TLS] TLS1.3 + PSK with multiple identities

[David Woodhouse <[e-mail]>]

On Mon, 2016-09-19 at 07:55 -0700, Eric Rescorla wrote:
> > What if my client authenticates with an actual pre-shared key, and I
> > also want to resume a session? As it stands, that means I really do
> > need to offer two PSK identities — one for the real identity, and one
> > for the session resumption attempt. Are you saying that won't be
> > permitted?
> 
> I should start by saying that it's not entirely clear why this is useful.
> Can you elaborate?

I should start by pointing out that I have no personal *need* for this;
it just seems strange and wrong to forbid it.

I assume you're not asking why one would use PSK in the first place, in
place of public keys? I think the introduction to RFC4279 fairly much
covers that and is still relevant.

So I interpret your question as asking why it's useful to *resume* a
session which was initiated with PSK?

Even though the cryptographic operations are basically the same —
there's none of the heavyweight asymmetric key operations, it's also
the case that resumed sessions may carry more application-specific
context than a newly-authenticated connection. 

Consider IMAP, as an example. It has a large amount of per-connection
state. This *could* be maintained even when the client disconnects —
you can imagine a mobile client which resumes an existing TLS session
and is *immediately* presented with all the status updates which have
occurred since it disconnected, without any need for re-building the
application-session state (or using any of the protocol extensions like
QRESYNC which help to reduce the connection startup time).

(Note: I'm not suggesting a *stateless* resume could do that.)

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... just
because you've chosen to conflate PSK identities and session resumption
on the wire? :)

> > Or do we [need] to stop conflating the two types of PSK-identity, so that
> > we can allow only one of each?
> 
> That doesn't address the reasons for only allowing one, unfortunately. See
> the thread on Finished stuffing.

OK, I'll read up on that; thanks.

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

If we do anything else, we might as well stick with some of the horrid
hacks we already have (like abusing the session-id and not actually
*resuming* that session).

> 2. Wait for DTLS 1.3.

It's certainly *tempting* to manually add chacha20 to our ever-growing
list and *then* wait for DTLS1.3 :)

-- 
dwmw2