On Mon, Sep 19, 2016 at 7:07 AM, David Woodhouse <dw...@infradead.org> wrote:
> 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? > Yes. > 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? Or do we stop 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. > > > 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? > I can't speak for the motivations of the authors of this draft. It's not a WG item. However, I'm not generally in favor of backporting pieces of TLS 1.3 into 1.2 like this. 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. 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. 2. Wait for DTLS 1.3. -Ekr > -- > dwmw2
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
