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

Eric Rescorla <ekr@rtfm.com> Mon, 19 September 2016 12:48 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 5B64012B3A6 for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 05:48:22 -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 aq2TyyTyhmt4 for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 05:48:20 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 C588E12B3EC for <tls@ietf.org>; Mon, 19 Sep 2016 05:46:50 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id t67so142015889ywg.3 for <tls@ietf.org>; Mon, 19 Sep 2016 05:46:50 -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=aSUSFOFmhnaYYjf4CwATJ2Pyt3ZYCaqJq8OrV5MxdzU=; b=0ec5MP9YQNVoO6Rigdrfm7ZDpexGVufu6HUO2gm0j63qB8jUEXgo0pAgcC9bVbKHHn /rPuDY+bMK+1kLskSn/72koQYG8GxscQkRSIHJ81ffqMpWfy25/A3b6HNWzIdZi6PUQ6 q8l6UNXV58VQluhW8233kIZlUBCj+JGoAhG0OSowD7NjU0XOh8qocrkBy+5gWoEowiAk 7QdQ5oyCM1sDOkgCVXUemMKrsmA9xS8102XazNizZ0csVqncfrPgwJ6LaZreSmM2sWhv MdUzoQ9aQa0cKnN4qxhf7ISyiH538ONFTsocGA5x3aQMTjnFIIEHu2dRqgssaJJ3k+Fv geNg==
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=aSUSFOFmhnaYYjf4CwATJ2Pyt3ZYCaqJq8OrV5MxdzU=; b=iKYVz+VFEuJ+eB7imZupne1n+DvRtMItnmN8HF5JTwCqmw4LL67M3rbv5uBu5Yj1xN e8VP0HX5xPzGnBMUJHmGYCrWkT7kNIohUwDP7axNXAowKimL3WIeNGvOPGe3P6RrcJnx ycrpuH6O8mjsZyfzLsClHFuI6PchAfANr4AKA+ICBD/7hBmFy7lNB6Hqfzs5NxDFkCyG UwXug6m7BNq8l+jInrJa8/dlbvl+7QBcieeF7IYoRqsxoLQmxuTrv8cZAxTSOBKQzF89 JPOx9hnlJcO+5+FEp2QoSV2ivdZ7iCXuIHUfF03RsqQZcEIpi8Cj8oj879pXqB0bWMFH JR9A==
X-Gm-Message-State: AE9vXwPtnStNGDUXWEaY+BMQzqVo09WDASystIplR99TTRVKRvTSK3mUePVrpmAW34bzcjQrmEBMB8XDvI0hIw==
X-Received: by 10.129.83.193 with SMTP id h184mr25710788ywb.52.1474289210067; Mon, 19 Sep 2016 05:46:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.160.10 with HTTP; Mon, 19 Sep 2016 05:46:09 -0700 (PDT)
In-Reply-To: <1474288002.144982.304.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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 19 Sep 2016 05:46:09 -0700
Message-ID: <CABcZeBMmZggyn=K64uRp48JKm0Ox71K54BwB0RMa7fwHP6bW+A@mail.gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Content-Type: multipart/alternative; boundary=001a114d6f1ca9bd38053cdbb4f4
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UL_P2FINkyDC7GMFLhdY5AoPYno>
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 12:48:22 -0000

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

> On Mon, 2016-09-19 at 04:41 -0700, Eric Rescorla wrote:
> > > Do we care that the '0x00 0x12' bytes on my third line above are
> > > entirely redundant on the wire? Or have I interpreted it wrong?
> >
> > Not enough to fix it, this is just the way TLS rolls.
>
> An interesting contrast to Nikos's observation that using the index in
> the response is "used nowhere else in TLS" — which he could have
> phrased using similar words. But I suppose in that case you're saving a
> *lot* more than two bytes in the ServerHello, so it makes sense to
> deviate from "the way TLS rolls" :)
>

Yes.


> > Is there no way the PSK identities for session resumption could be made
> > > smaller? Of the data which RFC5077 suggests that we put into a session
> > > ticket (and thus the PSK identity), is there *none* of it which could
> > > be sent later in a ClientKeyExchange packet?
> >
> > No. Also, there isn't a CKE record in TLS 1.3. All information needed to
> derive
> > the key needs to be in the CH.
>
> Well, that was kind of my point. Information needed to derive the *key*
> needs to be in the ClientHello.
>
> But if it's auxiliary information which isn't actually *needed* to
> derive the key or to select which {identity to use,session to resume},
> then perhaps the client could be required to supply it afterwards.
>

You need the complete ticket to make sensible decisions.


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.


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.


So it would be useful to have some clarity on the UTF-8 requirement
> from RFC4279, and whether it's being completely abandoned with TLS 1.3.
>

It's being abandoned. PR welcome.

-Ekr