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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Mon, 20 May 2019 21:11 UTC

Return-Path: <prvs=0043516ff8=uri@ll.mit.edu>
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 03D3D120058 for <tls@ietfa.amsl.com>; Mon, 20 May 2019 14:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 QjBKE0hGNUUZ for <tls@ietfa.amsl.com>; Mon, 20 May 2019 14:11:53 -0700 (PDT)
Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CCD12004E for <tls@ietf.org>; Mon, 20 May 2019 14:11:52 -0700 (PDT)
Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id x4KLBosS001175; Mon, 20 May 2019 17:11:51 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Michael StJohns <msj@nthpermutation.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk
Thread-Index: AQHU71Dl4FuLhOFUaEet5GHjTbcLfaZspnEAgAhAFwD//8LZAIAAWHEA///A0oA=
Date: Mon, 20 May 2019 21:11:49 +0000
Message-ID: <18193F45-9A43-432C-AE7C-009B0F237598@ll.mit.edu>
References: <CAOgPGoBA8KykyHmLxqSEp51jyXO673Wb==O9KVx+U23k3h1=Tg@mail.gmail.com> <CAOgPGoDArfcX09bXVT58VgsyXspG76Cm9TNaBUmGgaqUB=ULUA@mail.gmail.com> <623BD5EA-1D76-494C-B87D-55FD1156EBD6@vigilsec.com> <71EB9B8A-C410-4A35-A0FE-3E2BE89E7C65@ll.mit.edu> <a58e25b3-dda2-007d-23e5-45441bce0d9b@nthpermutation.com>
In-Reply-To: <a58e25b3-dda2-007d-23e5-45441bce0d9b@nthpermutation.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.18.0.190414
x-originating-ip: [172.25.1.90]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3641217109_740760349"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-20_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905200132
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7d2yWUkOubs7xRFFRtZh8U56ukc>
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: Mon, 20 May 2019 21:11:57 -0000

One question that I have after reading it: I understand why one wants to implement this extension, but I don’t see how the two endpoints would arrive at that external PSK. 

Sadly - we're back to the 1980's in terms of key management.   The obvious answers are a) they meet to exchange keys, b) they're given a key through a KDC, c) they get them in the mail. (and I'm really not kidding about (c))

I don’t think I get it. There’s a ton of submissions at NIST PQC, most came with some formal proofs. I can’t believe none of them is good enough. Anything from that pool should be better than nothing…?

Also, if you do have a running KDC, why would you want/need TLS 1.3 ECDHE in addition to it? 

Would such a pre-shared key be long-term (i.e., good/used for many connections), or is it going to be a use-once thing?

 

 

From: TLS <tls-bounces@ietf.org> on behalf of Russ Housley <housley@vigilsec.com>
Date: Monday, May 20, 2019 at 3:21 PM
To: Joe Salowey <joe@salowey.net>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

 

TLS 1.3 Extension for Certificate-based Authentication with an External PSK ensures the US Government has a quantum-resistant option for TLS in the interim years until post-quantum algorithms emerge from the NIST process. For this reason, there is an intent to specify this extension in future procurements.

 

Russ

 




On May 15, 2019, at 9:20 AM, Joseph Salowey <joe@salowey.net> 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> 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/. Please review the document and send your comments to the list by 2359 UTC on 23 April 2019.

 

Thanks,
Chris, Joe, and Sean







_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls