Re: [TLS] TLS1.3 + PSK with multiple identities

Eric Rescorla <ekr@rtfm.com> Mon, 19 September 2016 14:56 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC3312B3FE for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 07:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOO2I8rZP10r for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 07:56:11 -0700 (PDT)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3933912B404 for <tls@ietf.org>; Mon, 19 Sep 2016 07:56:11 -0700 (PDT)
Received: by mail-yb0-x234.google.com with SMTP id x93so88264613ybh.1 for <tls@ietf.org>; Mon, 19 Sep 2016 07:56:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tk8ikKlJj+HkYvyIkfFJ+HGL1Q/kywDVLxYrW+9+H5M=; b=hK0k4JJoumYsoQW0GtkAGFWPDifNQRzqQnNHFSN4w2bxTk5fWBU6X+AoOWJwG3tG18 By3khOjGOVO/FOqRQE4WoGX7jVGe0VWsihuHftCLuAqYVtUXj46aVtdTZKBdF73yj0nr p2/JGqpDJJtrB2FPvnqZPffOrAxU1uId6MHZiV9/O1r09bWDKbQcR0V6dAfX3Iwdz2KO h2DF3+zCCJxocnGUylkRR+eWtZ8fTiMJbmYQY0V8LWfn0RmwMAjypHESFpbcXjzNzrJI c5He9gjPyhDpaY1nGgMmC5dSyZ7Ko5BKSKxRCy8UlDUC7Do/nnrVJn9ME6GnHcgYAz7N xZIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tk8ikKlJj+HkYvyIkfFJ+HGL1Q/kywDVLxYrW+9+H5M=; b=SVIQZ6tAIGJF+vHPOcXidn6a39aLt5J0P3wOBk+pqsSbEaU0SS1nylXWe4awYKcq7S ehnjfi9mDSTENKOfTiN/7HwgqHcDHLrkyO6Cs0i+OqXvUByr9UI3Sr30J8FflKzotRDy 4EuBMRA/UynAUyrYtS2zkS0k5rqCtDUGmWGQCTLHf612LYsO7FGrhUGIr6WcQgrTmOWr Mr+4II9VjINpliuAdkbsUDmAxsXi8vrHmutaWsg5GcZ7HBY5T8D5s4RkzxVaNA5kjTo7 FN+443GT5zHTK2MaTXpDRu6k1rxWcRuKd8ME4KJ7de1qhcEwXNrDjfwMDjgiH67auUyL C1FQ==
X-Gm-Message-State: AE9vXwMxZ5pCWVaevP1oFTfTQu9EeRSQInqFkvMSDBt6jCDo95+hIEUeEqQD4Ewt48Yb7eWKTlABg+3M7X1CnA==
X-Received: by 10.37.57.86 with SMTP id g83mr26117610yba.64.1474296970230; Mon, 19 Sep 2016 07:56:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.160.10 with HTTP; Mon, 19 Sep 2016 07:55:29 -0700 (PDT)
In-Reply-To: <1474294073.144982.327.camel@infradead.org>
References: <1470644260.3026.13.camel@redhat.com> <20160808082836.jgq7a4qqvis6msp5@LK-Perkele-V2.elisa-laajakaista.fi> <1470648042.3026.44.camel@redhat.com> <1474278590.144982.255.camel@infradead.org> <CABcZeBNfzzZXmtEiMptB3_eKsydvvsZ0gBMzLLPbQcBHtF_H+A@mail.gmail.com> <1474288002.144982.304.camel@infradead.org> <CABcZeBMmZggyn=K64uRp48JKm0Ox71K54BwB0RMa7fwHP6bW+A@mail.gmail.com> <1474294073.144982.327.camel@infradead.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 19 Sep 2016 07:55:29 -0700
Message-ID: <CABcZeBPj3Cbb2qj45yyxZGmnbQAKbn37yr7MmykP0yGS64Q+QA@mail.gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Content-Type: multipart/alternative; boundary="001a114f5d9034b50e053cdd8379"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hxP-tJndudGmjBfFWU9DfWh5yVE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS1.3 + PSK with multiple identities
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2016 14:56:21 -0000

On Mon, Sep 19, 2016 at 7:07 AM, David Woodhouse <dwmw2@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