On Mon, Sep 19, 2016 at 7:07 AM, David Woodhouse <dw...@infradead.org>

> 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?

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
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.


> --
> dwmw2
TLS mailing list

Reply via email to