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

David Woodhouse <dwmw2@infradead.org> Mon, 19 September 2016 20:36 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 0D12B12B0BE for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 13:36:05 -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 3Nr_cxzxnmxd for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 13:36:03 -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 9362612B00D for <tls@ietf.org>; Mon, 19 Sep 2016 13:36:03 -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 1bm5IG-0001yE-Jl; Mon, 19 Sep 2016 20:36:00 +0000
Message-ID: <1474317357.144982.400.camel@infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 19 Sep 2016 21:35:57 +0100
In-Reply-To: <CABcZeBNoFmNYVfzQxt5hAr0F5rAOPd_gVq2guyxuSwNHKBBrVg@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> <1474299465.144982.347.camel@infradead.org> <CABcZeBNoFmNYVfzQxt5hAr0F5rAOPd_gVq2guyxuSwNHKBBrVg@mail.gmail.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-ZbmJdv2+2bKImWWQzUgC"
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/rhMi2Ek6DrfK27-hQcF1VYvNERk>
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 20:36:05 -0000

On Mon, 2016-09-19 at 09:53 -0700, Eric Rescorla wrote:
> > 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.

I suppose that's an answer in the general case too, isn't it? If you
want to try multiple identities, you can just keep trying with HRR
until you find one that the server accepts.

In fact, it doesn't even need to be "keep trying until...".

You could still offer multiple PSK identities in the ClientHello, and
only offer a hello_finished MAC for the *first* (preferred) one. If the
server doesn't want that one, it can send a HRR with a
PreSharedKeyExtension that tells the client which one it *does* want.

You preserve the original behaviour of negotiating which PSK identity
to use, while also fixing the problem that limits you to just one.


 < ...context switching to my actual use case... >

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

It's more than just a hint. It is saying precisely which client it is,
which has a 1:1 correspondence with which PSK it's using.

In theory it would work to use the existing identity in the
ClientKeyExchange in TLS1.2. However, in practice it becomes extremely
painful to do so because the ClientKeyExchange comes in too late.

It is purely a matter of software architecture — the initial incoming
UDP packets reach a dispatcher that needs to hand the connection off to
the appropriate worker process for that client.... and *really* wants
to make that decision based on the ClientHello alone.

If we *start* the handshake in the main dispatcher and get to the point
of seeing the ClientKeyExchange, we have to hand over the partially-
completed handshake (or keep going and then hand over a fully-completed 
handshake) to the appropriate worker. And in fact I don't even think
the dispatcher *has* the actual keys; only the identities so that it
knows where to dispatch connections to.

So I really do think that draft-jay-tls-psk-identity-extension was
*exactly* what I wanted. I don't care about *negotiating* the PSK
identity per se; I'm happy to support only one. It's purely about
*telling* the server, in the ClientHello, which identity I'm using.

I suppose I can just say 'screw it' and continue to abuse the
session-id for this without actually resuming a session :)

-- 
dwmw2