On Mon, 2016-09-19 at 05:46 -0700, Eric Rescorla wrote: > > > And then the client only needs to supply one copy of it for the > > identity which the server actually selected, not one for *each* > > identity which was being offered by the client. > > We're most likely going to allow only on PSK anyway.
You mean "only one", I assume? 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? Or do we stop to stop conflating the two types of PSK-identity, so that we can allow only one of each? > > I share Nikos's concern about using the PSK identity for two completely > > different types of identifiers — especially given that one type has > > historically been defined as UTF-8 text, while the other is binary. > > > > The reason I care about this right now is that we're looking at using > > PSK to bootstrap a DTLS connection in the context of an SSL VPN, > > currently using DTLS 1.2 and draft-jay-tls-psk-identity-extension. > > I recommend against this: I very much doubt that we are going to adopt this > draft in TLS. That is useful feedback; thank you. Although I'm slightly confused — although the draft is out of date, I thought the point of it was to simply document what you *are* adopting in TLS1.3, for use in TLS1.2. Are you saying that the extension will never be retroactively 'blessed' for TLS1.2 even when it's part of TLS1.3? What we're trying to do is move away from the existing model, inherited from Cisco AnyConnect, where the DTLS ciphersuite is negotiated out-of- band along with a master secret, and then we 'resume' a DTLS session that never really existed. It took us a *long* time to gain support for DTLS1.2 and AEAD cipher suites because of that, and it would be much better just to let DTLS negotiate as $DEITY intended. But the architecture of our server is such that it *really* wants to know from the very first ClientHello packet which client it's talking to, so that the packet can be dispatched to the correct worker process. The first prototype of this continued to abuse the Session-ID to identify the client — making it *look* like a session resume attempt when in fact we weren't prepared to resume the session at all, and we rely on the server *not* doing so. I kind of threw my toys out of the pram at that — if we're going to attempt to use the protocol properly, then I really do want to do it *properly*. Hence the interest in draft-jay-tls-psk-identity-extension. If that's not going to be viable, then I'm starting to wonder if we should just wait for DTLS1.3. After all we *already* support the fun parts of DTLS1.2, and AEAD ciphersuites, so there's no desperate rush to start using proper negotiation. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
