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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
