Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

Russ Housley <housley@vigilsec.com> Wed, 22 May 2019 18:06 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 759431202DA for <tls@ietfa.amsl.com>; Wed, 22 May 2019 11:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 xiHk92JsfbCm for <tls@ietfa.amsl.com>; Wed, 22 May 2019 11:06:16 -0700 (PDT)
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 BFF00120320 for <tls@ietf.org>; Wed, 22 May 2019 11:06:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 72651300AE1 for <tls@ietf.org>; Wed, 22 May 2019 13:46:46 -0400 (EDT)
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 fJaDvSwzYnMr for <tls@ietf.org>; Wed, 22 May 2019 13:46:44 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 55E45300471; Wed, 22 May 2019 13:46:44 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <9FF3B61C-2EEE-42EC-84CD-615096609DE4@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9C9AABC8-204A-47C8-92EE-4806281E5FA8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 22 May 2019 14:06:01 -0400
In-Reply-To: <9f82ec83-2776-4de3-6f6d-94df8650c2b7@huitema.net>
Cc: IETF TLS <tls@ietf.org>, Joe Salowey <joe@salowey.net>
To: Christian Huitema <huitema@huitema.net>
References: <CAOgPGoBA8KykyHmLxqSEp51jyXO673Wb==O9KVx+U23k3h1=Tg@mail.gmail.com> <CAOgPGoDArfcX09bXVT58VgsyXspG76Cm9TNaBUmGgaqUB=ULUA@mail.gmail.com> <9f82ec83-2776-4de3-6f6d-94df8650c2b7@huitema.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Vp_CHsV8jvn4H7NCLciCoqzSWA0>
Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 22 May 2019 18:06:28 -0000

Christian:

> On 5/15/2019 6:20 AM, Joseph Salowey wrote:
>> The last call has come and gone without any comment.  Please indicate if you have reviewed the draft even if you do not have issues to raise so the chairs can see who has reviewed it.  Also indicate if you have any plans to implement the draft. 
>> 
>> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey <joe@salowey.net <mailto:joe@salowey.net>> wrote:
>> This is the working group last call for the "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key” draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ <https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/>. Please review the document and send your comments to the list by 2359 UTC on 23 April 2019.
> My only comment regards the trade-off in this draft between privacy and resilience. The proposed method uses PSK to provide greater resilience against quantum-capable attackers, and as Russ says this is something that the US government cares about. But at the same time, the use of PSK requires inserting a PSK-ID in the client hello, which is sent in clear text. So we have a trade-off: government communications are less likely to be decrypted, but the PSK-ID will help track government employees. It might make sense to describe the trade-off explicitly in the draft, maybe in the security section.
> 


I suggest the following additional section for this document:

  Privacy Considerations

   Appendix E.6 of [RFC8446] discusses identity exposure attacks on
   PSKs.  The guidance in this section remains relevant.

   This extension makes use of external PSKs to improve resilience
   against attackers that gain access to a large-scale quantum computer
   in the future.  This extension is always accompanied by the
   "pre_shared_key" extension to provide the PSK identities in plaintext
   in the ClientHello message.  Passive observation of the these PSK
   identities will aid an attacker to track users of this extension.

Does that address your comment?

Russ