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

Eric Rescorla <ekr@rtfm.com> Mon, 19 September 2016 16:54 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 4290C12B417 for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 09:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 CGtbzByjcHbA for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 09:54:38 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 550E712B13A for <tls@ietf.org>; Mon, 19 Sep 2016 09:54:38 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id g192so158583660ywh.1 for <tls@ietf.org>; Mon, 19 Sep 2016 09:54:38 -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=Xfl8M7vFIScIOdwvVhvTHTdsUpHmN+t2BLyg1IrXs2U=; b=vjHjUn/+5p1w6ZyUJS8nsWycVRbDkPu5e5cvDUPPq4+SRaRSqlsouOYWWzKXJOj2zH afGbAY695ubcnuicMOeK5OCSCYFo+ll4cAmNK65xHGx4/2V4/sUGM/t2fr2WUvJWPIOf sEv3rHfpU17Ui8+l+xlaYQ8u1cM2UisloOav8B6ndP/eZS16C3zww9vxsIOS35yKvnKd MyoK7LGxOl7fvK3JDJpJCdaBPqlXpeviS6UkyK9/+Z3XtCKNBIV2pKubCYFkUnaXc8w1 Q9tijRKlWKR8uVIzUDXbUB20EmojTIf1VIP2BViRDEzEwXYVcGQF88zYFBzu14VgSsij /nug==
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=Xfl8M7vFIScIOdwvVhvTHTdsUpHmN+t2BLyg1IrXs2U=; b=fcGpob1pKHKgml5WkOVLiMleZE7vs/F90g0dTGOZ9mRdXAe/vvFt+O7SakiE9xT4nr HpbEvu/rfMBiWbYEMMyNvVYpjDPyakn7XC3Kjiz80BGqadMbULtySkyGDBlSuQL6orhd L1EWg1wdSjX6Bpgh1sx+Ovj8Wuny5xnZ6fq4FrnHLvO8hiflX7pZdq31MkeQuDC1JCt+ rx5l7y/p7jSXp1Ut6acAdSgJT4PZ7M8dyFxjdJdpLlQS+2l3dZ/MR/PvIbExlXojWLuq p8HmVvQR1JsgnUulw8LeH/lFuyy6+oF902NgctGgX/VcnO5M6zvrv2CWWuLnaJr8FitP PBPA==
X-Gm-Message-State: AE9vXwNmvw7JoW7CYbSneLbcjLhTZGh1hQ87k8JqJzMK6/PtsBTDd7KkyzvUOsESM/vjyYCLp73f2ikrI4oO+g==
X-Received: by 10.129.53.88 with SMTP id c85mr26814540ywa.205.1474304077529; Mon, 19 Sep 2016 09:54:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.160.10 with HTTP; Mon, 19 Sep 2016 09:53:57 -0700 (PDT)
In-Reply-To: <1474299465.144982.347.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> <CABcZeBPj3Cbb2qj45yyxZGmnbQAKbn37yr7MmykP0yGS64Q+QA@mail.gmail.com> <1474299465.144982.347.camel@infradead.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 19 Sep 2016 09:53:57 -0700
Message-ID: <CABcZeBNoFmNYVfzQxt5hAr0F5rAOPd_gVq2guyxuSwNHKBBrVg@mail.gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Content-Type: multipart/alternative; boundary=001a1142153cd57aff053cdf2a3f
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xdyUHwW0PQ0smqZ1nrzFEQ4PBT8>
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 16:54:40 -0000

On Mon, Sep 19, 2016 at 8:37 AM, David Woodhouse <dwmw2@infradead.org>;
wrote:

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

Yes.



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

This doesn't seem like the kind of behavior we want to encourage in
applications.


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


Well, I'm not saying you can't do that. As I said, you can use HRR if the
resumption
fails.


just
> because you've chosen to conflate PSK identities and session resumption
> on the wire? :)
>

As I said before, that's not the reason to restrict to a single identity.


> 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 :)
>

No, I don't think that's true. That extension also attempts to actually
negotiate the keys in that layer. I'm just talking about a hint.

-Ekr