On Mon, Sep 19, 2016 at 8:37 AM, David Woodhouse <[email protected]> wrote:
> 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? > Yes. 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 applications. 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. just > 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. -Ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
