[TLS] PSK in TLS 1.3

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 15 March 2016 20:46 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 8F80E12DD7E for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 13:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 DFhHx7mvghbt for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 13:46:36 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744B212DD86 for <tls@ietf.org>; Tue, 15 Mar 2016 13:46:35 -0700 (PDT)
Received: from [192.168.10.140] ([129.192.176.70]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MdoR7-1aRpOG07ob-00PeLR for <tls@ietf.org>; Tue, 15 Mar 2016 21:46:33 +0100
To: "<tls@ietf.org>" <tls@ietf.org>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <56E874A4.3030506@gmx.net>
Date: Tue, 15 Mar 2016 21:46:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="aBwxRtRx19NJRbvDnOVrMQrdIKkvXtmF1"
X-Provags-ID: V03:K0:YQdJcGHhORzHG7X6AI+jzD9qSbUCQPQeCrVV3/1G6TvRqne1xGA GuyefLUg3Nd/NZR/p9uQcW9kcuDvhDQqM2mBKyZCzhgPISYV/Rd1vdCJ+WZD/bvXJ5syc9j Vj5NqtdXXyqxPwp2izAtLhusthBktH7n4Gew3Oon4BzjAyYhGq2UPltCb8DKazmksL9YcMN aOEbz29ml6NiWwwEgiKHQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:oVScp0cp0ns=:PYaaFz6GMp2U5778iP+qaO 2Of0PCcfJKKzgA+++bZhbmRLUdEYljb8LV6/ZrG83L1CuQo8QDpuc+GA0AFboh8ACk4KK1R/w hohIhS+IH562vccqThlz4+UlV5iWAm7+vHNAy+p0xgAJ3eIA0tKIsWkC2u+pPEQZvVCZ30+Og 8mnTcliV3ZKwH3zAUGZD5SY5TVEnXP9RhoJeq3WP3feQ0XqJX5eLbbYMZxIlEVY/5OANZJYnH VIBczHdcRhQWNu30ZnuI6jfGdO0XR/Tucffqb/JY2PGPsp27dTDKVV7ytkDoIrKdlnykIinRZ VWFxnYT0W8Jt3S2IdWuRXn+XQnpJxeGg0aBrMhRo9ECPQe53bnTMi2SN4cpnxUx+1m5mW8B/Y lE++qikm2OjZ9UMU5LhqFgSLWt4GRQVRUCKlmcE82d8VTlcKZ6tBEfNV2b+HhoS8BgAJEBojP EgIvcZj4Bw/9Men7PSVHWkgFqnLx8hDdfA15mh4W23OUyx3NIt/c0X8bNXAvs5mqUKGCW4eet GLoSF5FFyOgi/yL0Bt0VvCMrs6QNSeqAaBecG4xr9i5mLbBNcAMhE8Ld9gz2pcuCAQRcSkYUu 1/0P2JYyHhlbGlc+41G/w9W9f7TrPGBvmyGGVYZ4ZKO4Z4rp1e9hxnG/mkQrXpiXq1O63avYD yyzypd8GRbUXqjYpp+RJ08wt6mtRrgcRE3wSmFMb5+keZDM4kUU9jiwjnX8u6gIkA7koiA65j 5uvb/pnD4jjaOR5ds506Mwyw37pU8fqBZczWLia1GT6GDC8rtcR+eXahtfE=
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ii3seD3zRKHw_fu2049hU7_IdrM>
Subject: [TLS] PSK in TLS 1.3
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: Tue, 15 Mar 2016 20:46:37 -0000

Hi Ekr, Hi all,

I am not entirely sure about the PSK story in TLS 1.3.

In Section 6.2.3 I read that the PSK approach has been combined with
resumption.

Appendix A4 lists the defined ciphersuites but there is no PSK-based
ciphersuite in that list.

Section 6.3.1.2 explains that the ServerHello message handling:

"
The server will send this message in response to a ClientHello message
when it was able to find an acceptable set of algorithms and the
client’s “key_share” extension was acceptable. If the client proposed
groups are not acceptable by the server, it will respond with a
“handshake_failure” fatal ale
"

What this text should be saying is that the response from the server
depends on the selected ciphersuite. Implicitly you are saying that in
another part of the document, namely in Section 8.2 "MTI Extensions".

Ciao
Hannes