[TLS] Using both External PSK and (EC)DH in TLS 1.3

Russ Housley <housley@vigilsec.com> Thu, 22 December 2016 21:54 UTC

Return-Path: <housley@vigilsec.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 80A1A1295FD for <tls@ietfa.amsl.com>; Thu, 22 Dec 2016 13:54:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4uBdbyFbghvB for <tls@ietfa.amsl.com>; Thu, 22 Dec 2016 13:54:12 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295A51295FB for <tls@ietf.org>; Thu, 22 Dec 2016 13:54:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E433B3002BF for <tls@ietf.org>; Thu, 22 Dec 2016 16:43:54 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XpWtFby-ltc9 for <tls@ietf.org>; Thu, 22 Dec 2016 16:43:53 -0500 (EST)
Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id CF0E5300260 for <tls@ietf.org>; Thu, 22 Dec 2016 16:43:53 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com>
Date: Thu, 22 Dec 2016 16:54:18 -0500
To: IETF TLS <tls@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1W_LRzLQHHH3iGS3zs-7LsMtx-8>
Subject: [TLS] Using both External PSK and (EC)DH 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: Thu, 22 Dec 2016 21:54:13 -0000

I want to make sure that it is possible to mix PSK with (EC)DH as a protection against the discovery of a quantum computer.  I recognize that the WG does not want to tackle this topic in the base specification; however, the following text in Section 4.1.1 makes this difficult to do so in a companion document:

>    The server indicates its selected parameters in the ServerHello as
>    follows:
>
>    -  If PSK is being used then the server will send a "pre_shared_key"
>       extension indicating the selected key.
>
>    -  If PSK is not being used, then (EC)DHE and certificate-based
>       authentication are always used.
>
>    -  When (EC)DHE is in use, the server will also provide a "key_share"
>       extension.
>
>    -  When authenticating via a certificate (i.e., when a PSK is not in
>       use), the server will send the Certificate (Section 4.4.1) and
>       CertificateVerify (Section 4.4.2) messages.

An Internal PSK offers no protection against the discovery of a quantum computer.  I assume that an attacker can save the handshake that established the Internal PSK, and then at some future date use the quantum computer to discover the Internal PSK.  Therefore, protection against the discovery of a quantum computer is only concerned with External PSK.

I would like for the specification to permit normal certificate authentication when someone is using an External PSK.  I am guessing that the granularity of the name associated with the External PSK to be pretty broad.  If this guess is correct, it would be appropriate for the name in the certificate to be further restrict the one associated with the External PSK.  Maybe the External PSK is associated with example.com, and then the certificate that includes www.example.com would be acceptable acceptable.  Then, I would expect any Internal PSK that is generated after such an authentication would be associated with the more granular certificate name.

Maybe it is as simple as reorganizing these bullets like this:

   - When only PSK is being used, …

   - When only (EC)DHE is being used, …

   - When PSK and (EC)DHE are both being used, …

If others agree with this direction, I am willing to propose some text.

Happy holidays,
   Russ