Re: [TLS] PSK in TLS 1.3

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 21 March 2016 22:00 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 B609E12D0DD for <tls@ietfa.amsl.com>; Mon, 21 Mar 2016 15:00:17 -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 n2bbOIB_yUOg for <tls@ietfa.amsl.com>; Mon, 21 Mar 2016 15:00:14 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 D883A12D0E7 for <tls@ietf.org>; Mon, 21 Mar 2016 14:59:56 -0700 (PDT)
Received: from [192.168.10.140] ([94.79.182.6]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M35iN-1ZtJhG0qf9-00swjY; Mon, 21 Mar 2016 22:59:53 +0100
To: Eric Rescorla <ekr@rtfm.com>
References: <56E874A4.3030506@gmx.net> <CABcZeBOS+D2wkctkq0pmNRJCxi=EA9Hk4dH6YrUTcAXLq8xaEw@mail.gmail.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <56F06EDC.9080406@gmx.net>
Date: Mon, 21 Mar 2016 22:59:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBOS+D2wkctkq0pmNRJCxi=EA9Hk4dH6YrUTcAXLq8xaEw@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="X3v0HFQF7uvBC9iOwBNBTv1awuCL2t56u"
X-Provags-ID: V03:K0:rEw0Wo+B5dANBDg5wYlItMW+NOc4CkSJwfKlAwLbwA7eFbx7mdY njEMIA0eTPvXxly9odyBDgnGvcfMJLZH4kFybu0OObAnIe7ZBP5E/lSpE8ipLyuTifZJiyZ bhtv6WFO5A2/yZQymyhy3icxuI4lNdOLMK03Ab5n5QCVUZ7SmaVgmpdk0nhWw0YVcKbcWMC mc5XGYfqxhTAre04iHkCw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:2xxFG/o5BAg=:X6jXypkU0jUDyQbulkVl7L 1ieiGlCCykxPOAyUb9TFwP9tFAhqA7KTY+1m75xbK0LdnOpTE+q2x3H+YDGMUCSD3KVacfx54 MpmN3Eo7UJqTQUwYf4InsNIhb3MThr56woHuZSR1G60SafCMBFvAWmJE0mmXS/nTLq+Z5xhCN a0UMyaUOMEWJckL2oK2sGvpMXpqbr6kitXKq7VOKS64QGpTIqbT5yKQkmUR3CZ5pZMr/m30QU 14Ua+GD6HmUBP9NuzT+7Xkd025k/PbvIWjR4aqUH/nh3oWAfiICvAgWdxI3ek1nH35ZbVKfNT 6qQAM74jnJb+e/HE2sJSMki15K3+BC9Uu854sodPtxeBXNZOLnsrfWsRGdqLPh/k+NW8yXvUq vxYbxeoW7y4MUwJsG54xFmPHUe3mdrpSZp17JAr2UfuAzF2JORvEAaCioIoaNWKDhsZB5cgVR CR6e7Fc8N83B/V3ZPvpQFl4Yqc7xDyjiBcYPMhlpXmW0ThZ+pAClyJ/lSSw3uVbHoeqlWDXPj PQ6u8FLNJ5DpTVQJZIhSBMCtV5YzkUA2eMUC4dYRjqeT5tbeyqtiS0I3cdCDcLEZvYgeSVaxl iZdQg2/D3sOezXC/3ANW1EVE9BNEauYjc7xAZZYGb33DIuo2YiLW2zrs5I+s/4WLQesmL8uEB RIK0O1EflfZEjzB3+OLu5zkx+XX+dYRHq1xBccLIq4MMsfUNEsUeCs0NNwjT9GgM/bZ8FDBJk 4gijMpPKCknHgO9YV586LaIkqY6xqhRmTRROOoEq5r1tlZZXhHXPEMvWrSs=
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/DBZfRNKRq63CVh5AjFoU9c7C6rQ>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [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: Mon, 21 Mar 2016 22:00:17 -0000

Hi Ekr,

~snip~

>     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".
> 
> 
> Sorry, I'm not following your question here. Can you say more?
> 

The conditions for the server to return a ServerHello are complex and
the wording is confusing.

The decisions are at least based on:

- Is there an acceptable set of algorithms and groups that are mutually
supported?

- Did the client’s KeyShare contain an acceptable offer?

- Is a KeyShare extension present?

- Is “signature_algorithms” extension present?

- Does msg offer (EC)DHE cipher suites?

Ciao
Hannes