Re: [TLS] TLS1.3 + PSK with multiple identities
Eric Rescorla <ekr@rtfm.com> Mon, 19 September 2016 11:43 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 C813112B3A9 for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 04:43:55 -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 92HBySDgsTPB for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 04:43:53 -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 678C612B39E for <tls@ietf.org>; Mon, 19 Sep 2016 04:41:47 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id u82so137321482ywc.2 for <tls@ietf.org>; Mon, 19 Sep 2016 04:41:47 -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=vxkSSJJJcXQoQ2APUiOhuDzi63RTGNzkBje2n5l1SPw=; b=ZbypFXNrpKAGszA4OAjJZP26dOXoZC0ydhWpAZxTxlomawbfy54sBiQ8m4L60JqoZ+ orCuHR4YUwVRoPnX8Vpn3GTkpliJ7lCX/OpAcxJJxglYXsgmpk8k1ieuaGB8imU0ZGte MW6sboAsyq/lr3asrGVD1fYDJd6m4uK+OXNYCKwgAtcrFXgXgUMgnFiWkWeFGjxC0Qot s7nD7PW/EHI1IGZgrJ5HrQ4md/ZCaDI5OwqUBAk5NzRSy5eqIQCSqkv62Bt/Zd5beuoj DNenWamOw0tbZSwIaDo8fGoUEWKVe62BbJeBmDkOpTmeB2Un6PuHmN4S8C7iEpqSRhxi M5AA==
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=vxkSSJJJcXQoQ2APUiOhuDzi63RTGNzkBje2n5l1SPw=; b=UeK5fXNqoBTJmL9HRk3t/0aJHYOdINURk5MWkHWGin4t5fJaAFFIWAMV1htCVlj99K YcbtyLMya9jHqP0Q9iHdqT6yGi03lnieZn7hhL3jWS8vCLrsCRmRUB5l+VvKHNxhOQub HZIRYrOanWLsCjZnUom6mBw762gAzLSniy8zbnY8cm0HKYhJIeIxpxFZW0P2wOz5FN6S u1wG46c+XqkzHdMsUT81Zz4OfdrLIi6vQRr0K1s80Eq7UTia5UBlMDE0sw49XuLMWAYW mJkEzPp6ZMFYI9xf/k0fshpDlzdDUpCweOvSzPAJ4v8SzhnhiLZSRKiLdYSGGYjzWkT8 0Imw==
X-Gm-Message-State: AE9vXwMiuSsDk3tWby786+B/XQKlSKLuWxAoHBNzK8fUVeVfOXJ2SMpd4EegJHEXtKf1mjHm5BYYEEwD4eiIDg==
X-Received: by 10.129.83.193 with SMTP id h184mr25420372ywb.52.1474285306711; Mon, 19 Sep 2016 04:41:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.160.10 with HTTP; Mon, 19 Sep 2016 04:41:06 -0700 (PDT)
In-Reply-To: <1474278590.144982.255.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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 19 Sep 2016 04:41:06 -0700
Message-ID: <CABcZeBNfzzZXmtEiMptB3_eKsydvvsZ0gBMzLLPbQcBHtF_H+A@mail.gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Content-Type: multipart/alternative; boundary="001a114d6f1c013cb7053cdacc19"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bGeZQkRk7Cfjlv_vUku0W7BWz40>
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 11:43:56 -0000
On Mon, Sep 19, 2016 at 2:49 AM, David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 2016-09-19 at 10:29 +0200, Nikos Mavrogiannopoulos wrote: > > On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote: > > > More compact and makes the option where server sends some bad option > > > more clear. > > Note that if we really want to be more compact, we might also observe > that there is a redundant length field in the extension as sent by the > client: > case client_hello: > PskIdentity identities<6..2^16-1>; > > Each extension has at least four bytes on the wire — the extension_type > itself, and the length field of the extension_data in a uint16. > > If I am interpreting the spec correctly, then the data for the > PreSharedKeyIdentity extension in the ClientHello then follows that > with another uint16, which is *always* a value two lower than the one > which immediately precedes it. > > e.g. > > 0x00 0x29 // ExtensionType extension_type == 41 > 0x00 0x14 // opaque extension_data<0..2^16-1> > // This length field is entirely redundant: > 0x00 0x12 // PskIdentity identities<6..2^16-1> > // First identity: > 0x00 0x00 // PskKeyExchangeMode, PskAuthenticationMode > 0x00 0x04 // opaque identity<0..2^16-1> > 0x44 0x61 0x76 0x65 // "Dave" > // Second identity: > 0x00 0x00 // PskKeyExchangeMode, PskAuthenticationMode > 0x00 0x06 // opaque identity<0..2^16-1)> > 0x43 0x68 0x6c 0x6f 0xc3 0xab // "Chloë" > > 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. > 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. Is it permitted, and what is the meaning, to request a cipher suite of > (e.g.) TLS_PSK_WITH_AES_256_CBC_SHA and set PskKeyExchangeMode in the > identity to 'psk_dhe_ke'? Or conversely, to use the cipher suite > TLS_DHE_PSK_WITH_AES_256_CBC_SHA with PskKeyExchangeMode set to > 'psk_ke'? > > This seems redundant to me at first glance (unless some combinations > really do mean that you end up doing DHE *twice*) and could probably do > with some clarification. > TLS 1.3 cipher suites do not convey key exchange mode, just AED and KDF. See https://tlswg.github.io/tls13-spec/#cryptographic-negotiation for an overview of negotiation. -Ekr
- Re: [TLS] TLS1.3 + PSK with multiple identities Nikos Mavrogiannopoulos
- Re: [TLS] TLS1.3 + PSK with multiple identities Ilari Liusvaara
- [TLS] TLS1.3 + PSK with multiple identities Nikos Mavrogiannopoulos
- Re: [TLS] TLS1.3 + PSK with multiple identities David Woodhouse
- Re: [TLS] TLS1.3 + PSK with multiple identities Eric Rescorla
- Re: [TLS] TLS1.3 + PSK with multiple identities David Woodhouse
- Re: [TLS] TLS1.3 + PSK with multiple identities Eric Rescorla
- Re: [TLS] TLS1.3 + PSK with multiple identities David Woodhouse
- Re: [TLS] TLS1.3 + PSK with multiple identities Eric Rescorla
- Re: [TLS] TLS1.3 + PSK with multiple identities David Woodhouse
- Re: [TLS] TLS1.3 + PSK with multiple identities Eric Rescorla
- Re: [TLS] TLS1.3 + PSK with multiple identities David Woodhouse
- Re: [TLS] TLS1.3 + PSK with multiple identities Eric Rescorla
- [TLS] application-specific identifier was: TLS1.3… Nikos Mavrogiannopoulos
- Re: [TLS] TLS1.3 + PSK with multiple identities Olivier Levillain
- Re: [TLS] TLS1.3 + PSK with multiple identities Andreas Walz
- Re: [TLS] TLS1.3 + PSK with multiple identities Hannes Tschofenig