On Mon, Sep 19, 2016 at 8:37 AM, David Woodhouse <dw...@infradead.org>
> 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.)
This doesn't seem like the kind of behavior we want to encourage in
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
> because you've chosen to conflate PSK identities and session resumption
> on the wire? :)
As I said before, that's not the reason to restrict to a single identity.
> 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.
TLS mailing list