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

Eric Rescorla <ekr@rtfm.com> Mon, 19 September 2016 21:14 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 E75B112B388 for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 14:14:23 -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 s-g05_7Psn9B for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 14:14:22 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 0106F12B2F6 for <tls@ietf.org>; Mon, 19 Sep 2016 14:14:22 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id u82so157460574ywc.2 for <tls@ietf.org>; Mon, 19 Sep 2016 14:14:21 -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=zaZLcef/EwcGaBt1+CYP1XIAWMLRj29c+0sz74rgKBQ=; b=ES4Z2zqjne5cbJBr/dNRARh6uSPzobUnim/wT3hv8an4hqlsgNdj9fTRi/1LtWO6o5 frD+j6yU/bPiCHD/tnpk9tzKEyDW6+Vg4pY3Sdp3E3EbE/n1DPI7X/qQMQrUV2jn1v03 M3NMww7K9d3oWDKwNfCE/ATcfaZwPNAOKOnXff4hTfN5fbJvktEKaoPKAxr0ZVJ5b064 LLMp33CNkRp+ukIIxLZToHK+7EJDLj1/Wjd7HgSIpq/YPWPEdXAh3VXcKT5GTyME6K03 aUoNXUnmFyj4ELw9EaOGbuGwUvfy3Snt+xG9LrM/d5WYe8MHqysEf15Hy0zWxs5xbee6 BKBQ==
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=zaZLcef/EwcGaBt1+CYP1XIAWMLRj29c+0sz74rgKBQ=; b=VHsVsVmTnzANHBuviWcLcm4qUbXeOTKCzOhVT2Mr+8NGGlfO6JncQsK3NJcSXxqGaB bqbWNgxoLSV/HTCcMbB/Acu/IZ3ujjhXyAJAtNgYIVj8btEMjqp8zDBLJ9S7CPL3pwEV KjPmbya6VgEJ3zZP2xGFfX4rqEnTL1GfEc5XZICkf1Yg/vFZbAkgvsPGmoOz/xXUobef VguafLwFAgX4u2xlqlditgIHs6innzr7UI5rSEDEOALJj6SuA3b5iBpgS07MCZVc2eQg Llu3eFjrvtLvvIu9YpSvCSChx7cHH4Xr+HntbUIIYcixqyPhvD1d4z5bLRVdcWQqjTwW sM5A==
X-Gm-Message-State: AE9vXwMYpMpHKcbkCHM/t7uHwilD+OexAZzbNvj4HL5mRi/WLsSyF6TRRL4WHX0vO5UTfEBxRlv+H6ZPSgVLBw==
X-Received: by 10.129.41.196 with SMTP id p187mr27012738ywp.149.1474319661195; Mon, 19 Sep 2016 14:14:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.160.10 with HTTP; Mon, 19 Sep 2016 14:13:40 -0700 (PDT)
In-Reply-To: <1474317357.144982.400.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> <CABcZeBNoFmNYVfzQxt5hAr0F5rAOPd_gVq2guyxuSwNHKBBrVg@mail.gmail.com> <1474317357.144982.400.camel@infradead.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 19 Sep 2016 14:13:40 -0700
Message-ID: <CABcZeBMpw-To=SGDjn3P9KNNuBo52bDtGEp1hXhxqr0C3LB2WQ@mail.gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Content-Type: multipart/alternative; boundary="001a1142154eb14590053ce2cb6f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iUQAFv5y-M50TpGuoqnb8tkVKuU>
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 21:14:24 -0000

On Mon, Sep 19, 2016 at 1:35 PM, David Woodhouse <dwmw2@infradead.org>
wrote:

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

Call it a promise, if you prefer. One that you fulfill with the CE.


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

See above. The key advantage of what I am proposing here is that it has
exactly the same cryptographic properties as current TLS-PSK, with the
indicator just serving as a routing-ID.


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

See above.

-Ekr