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

David Woodhouse <dwmw2@infradead.org> Mon, 19 September 2016 15:38 UTC

Return-Path: <BATV+e4a5c8c88c3adab274df+4775+infradead.org+dwmw2@bombadil.srs.infradead.org>
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 EF03E12B404 for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 08:38:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level:
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
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 ZP5ZB5BrXo_U for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 08:38:05 -0700 (PDT)
Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 9CEDE12B3BD for <tls@ietf.org>; Mon, 19 Sep 2016 08:37:51 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bm0dg-0005Mp-G7; Mon, 19 Sep 2016 15:37:48 +0000
Message-ID: <1474299465.144982.347.camel@infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 19 Sep 2016 16:37:45 +0100
In-Reply-To: <CABcZeBPj3Cbb2qj45yyxZGmnbQAKbn37yr7MmykP0yGS64Q+QA@mail.gmail.com>
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>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-NW3VlKmEIOrrhhCTqcrA"
X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24)
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by bombadil.infradead.org. See http://www.infradead.org/rpr.html
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ito3ooYFR_oIwYzQA8sxvo0WuMI>
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 15:38:07 -0000

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?

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

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... just
because you've chosen to conflate PSK identities and session resumption
on the wire? :)

> > Or do we [need] 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.

OK, I'll read up on that; thanks.

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

If we do anything else, we might as well stick with some of the horrid
hacks we already have (like abusing the session-id and not actually
*resuming* that session).

> 2. Wait for DTLS 1.3.

It's certainly *tempting* to manually add chacha20 to our ever-growing
list and *then* wait for DTLS1.3 :)

-- 
dwmw2