IETF Logo Mail Archive

Re: [TLS] Advancing draft-ietf-tls-hybrid-design

Dan Brown <danibrown@blackberry.com> Thu, 05 August 2021 19:22 UTC

Return-Path: <danibrown@blackberry.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 C32333A1F4A for <tls@ietfa.amsl.com>; Thu, 5 Aug 2021 12:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=blackberry.com
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 YNOssPglym9I for <tls@ietfa.amsl.com>; Thu, 5 Aug 2021 12:22:25 -0700 (PDT)
Received: from smtp-pc10.blackberry.com (smtp-pc10.blackberry.com [74.82.81.42]) (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 40D763A1F49 for <tls@ietf.org>; Thu, 5 Aug 2021 12:22:25 -0700 (PDT)
Received: from pps.filterd (mhs400cnc.rim.net [127.0.0.1]) by mhs400cnc.rim.net (8.16.0.43/8.16.0.43) with SMTP id 175JM9Rf019390; Thu, 5 Aug 2021 15:22:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackberry.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=corp19; bh=Nf9jiO59dyYoWxXpFvYquvWdY/D7a7uJu/EUuoEJYds=; b=ifwYCmmJsjbwSJ5dQ84uDBVYo/H1OEjcwNkMBMm48GrtF/MUtUFEH6/+xhFIZLHxyFAa OGYG81Wow/KsxHDzF/Lblljs3A4RLaydxAbs7QFiPwmVifCdNtoJbtYs25aHpFIuLe5I l5dEuwOayesaWbXMHBYBePYl2fs0loD5KIxxnwAjY2lU2PAvmSIMUY5Ss6DRz4oo+v95 1uo54phavmjKFf2y3+zmqO0mieG9QHRP4oFEMssaltKIyasyl/p24Clt0S5yxx16hYSE 1HqaxZtz5MWY7255dqPiyUUqDIncS9dKIVkFfFLxtMfb28scbH3NQdOhLf1/f+qXQVuE HQ==
Received: from xch214cnc.rim.net (xch214cnc.rim.net [10.3.27.119]) by mhs400cnc.rim.net with ESMTP id 3a72wvnpb5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 05 Aug 2021 15:22:09 -0400
Received: from XCH210YKF.rim.net (10.12.114.210) by XCH214CNC.rim.net (10.3.27.119) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 5 Aug 2021 15:22:09 -0400
Received: from XCH210YKF.rim.net ([fe80::ac8d:3541:704c:478a]) by XCH210YKF.rim.net ([fe80::ac8d:3541:704c:478a%5]) with mapi id 15.01.2176.014; Thu, 5 Aug 2021 15:22:09 -0400
From: Dan Brown <danibrown@blackberry.com>
To: Douglas Stebila <dstebila@gmail.com>, "tls@ietf.org" <tls@ietf.org>
CC: Shay Gueron <gueron@amazon.com>
Thread-Topic: [TLS] Advancing draft-ietf-tls-hybrid-design
Thread-Index: AQHXcs44HC5wbSPxoEev9a/FvF5/P6tlc0dQ
Date: Thu, 05 Aug 2021 19:22:09 +0000
Message-ID: <dfcf9b0c26eb49cd899638afaa2ec886@blackberry.com>
References: <1DCCB8D8-F987-4A30-8084-06CE6FBCD507@gmail.com>
In-Reply-To: <1DCCB8D8-F987-4A30-8084-06CE6FBCD507@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [100.64.197.166]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_0049_01D78A0D.ACFBF3C0"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-05_10:2021-08-05, 2021-08-05 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/edbx9830agFDlyrHuYKPM5Wh-1M>
Subject: Re: [TLS] Advancing draft-ietf-tls-hybrid-design
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: Thu, 05 Aug 2021 19:22:31 -0000

> -----Original Message-----
> From: TLS <tls-bounces@ietf.org> On Behalf Of Douglas Stebila
> We wanted to see if there is any further feedback on our draft "Hybrid key
> exchange in TLS 1.3" ...  We have not received any new feedback from the
working group
> since we posted our last non-trivial update in October 2020.

Allowing 3 or more key exchange methods in a hybrid combination should
somehow be an option, for a user who can afford the extra cost and is
risk-averse and has high-value data to protect.
 
I was told this issue (2 versus 2+) was already discussed on the list, but I
must have forgotten (or missed) that conversation.

A workaround is to nest TLS into TLS, to get more types of key exchange, or
to apply the extra key exchanges at the application layer, on top of TLS,
for those (few) who want the extra security.  These workarounds imply
applying symmetric crypto twice, which does not help against the quantum
threat.




----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

v2.23.0 | Report a Bug | By Email