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

Dan Brown <danibrown@blackberry.com> Tue, 13 July 2021 15:08 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 657443A1572 for <tls@ietfa.amsl.com>; Tue, 13 Jul 2021 08:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 P2ltpSA1cprM for <tls@ietfa.amsl.com>; Tue, 13 Jul 2021 08:08:13 -0700 (PDT)
Received: from smtp-pc11.blackberry.com (smtp-pc11.blackberry.com [74.82.81.43]) (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 E7A5C3A1004 for <tls@ietf.org>; Tue, 13 Jul 2021 08:08:11 -0700 (PDT)
Received: from pps.filterd (mhs401cnc.rim.net [127.0.0.1]) by mhs401cnc.rim.net (8.16.0.43/8.16.0.43) with SMTP id 16DF4P05176317; Tue, 13 Jul 2021 11:08:08 -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=M8i273eavX+QQj/PEG8nHKAw3/h3QaQYmNk/T+J8Ou8=; b=cjKByotdnT9hr8whSDBprHFTcY2W0beA3ZUbDi3t8aRHUk0LJgldlp+p7ZkMKwYnYnuQ 2jT6uAcpvRbKXQYsTm8eyHNE1D8+jnr8Ixta0Uyz2Rv3oWtVByMGvKwM3oaUhsqEydxq YSOmXJ7JHl4ickeUuFnmfz1Y8pipbvqejlxVhFOix4+b5ZhYkmRf4eBDeUQJeYrKmk9p 3/UBoeuBo0jkK2D4o6k/p5dy9Fj4nzSWk1q4XCyDjY9UWyc4/krLS7hOwqgBchpSS+jc TVEpX7vjpak8D8C1P+VU5IV04hye6i+eO2VeIWGJ1oNv/XtTKltndwlJ4z/7Fndd+hcI dw==
Received: from xch214ykf.rim.net (xch214ykf.rim.net [10.12.114.214]) by mhs401cnc.rim.net with ESMTP id 39s7cy8nx5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 13 Jul 2021 11:08:08 -0400
Received: from XCH210YKF.rim.net (10.12.114.210) by XCH214YKF.rim.net (10.12.114.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Tue, 13 Jul 2021 11:08:07 -0400
Received: from XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8]) by XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8%5]) with mapi id 15.01.2176.014; Tue, 13 Jul 2021 11:08:07 -0400
From: Dan Brown <danibrown@blackberry.com>
To: Douglas Stebila <dstebila@gmail.com>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Advancing draft-ietf-tls-hybrid-design
Thread-Index: AQHXcs44HC5wbSPxoEev9a/FvF5/P6s3AzCAgAjoqgCAAQUagA==
Date: Tue, 13 Jul 2021 15:08:07 +0000
Message-ID: <b3eb577d13714202ba9a2664ab1f3a88@blackberry.com>
References: <1DCCB8D8-F987-4A30-8084-06CE6FBCD507@gmail.com> <8e134f86-0cb7-4d76-8090-37471364cece@www.fastmail.com> <BB506A1F-EDA5-44E6-B30E-3C78D7066086@gmail.com>
In-Reply-To: <BB506A1F-EDA5-44E6-B30E-3C78D7066086@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.167]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_001E_01D777D7.5CD9F1A0"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-13_07:2021-07-13, 2021-07-13 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yGex9g3gXoZhikyFgsz2lerpi8U>
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: Tue, 13 Jul 2021 15:08:18 -0000

Hi Douglas,

Your general approach paves the way for improved forward security, as
insurance against new attacks, a non-negligible risk (*).  So, the TLS WG
should advance it soon.  Sorry, that I've not yet looked at the details, but
I trust that your I-D is good. 

Best regards,

Dan

PS

(*) The non-negligible risk of new (or secret) attacks does not discount the
existing protocols or past work of the TLS WG. The TLS WG priority has
rightly been to address much greater risks (TCP unprotected by
cryptography), etc., but can now build on that work to further improve
security.

A strawman counter-argument to "hybrid public-key": why not do the same
thing for symmetric-key, i.e. the TLS record layer?  Two reasons. One: the
quantum computer risk more greatly affects public-key, while many of the PQC
alternatives are not yet tested (as much as the symmetric-key options).
Two: internally, typical symmetric-key cryptography already applies rounds
of different types of operations, e.g. linear and non-linear, so
symmetric-key is "hybrid" already (to a limited degree).


About "hybrid" terminology

> -----Original Message-----
> From: TLS <tls-bounces@ietf.org> On Behalf Of Douglas Stebila
 
> ...  Though at
> this point changing the word "hybrid" to "composite" would be a rather big
> rewrite so I'll omit that unless there are very strong objections to the
word
> hybrid.

On the "hybrid" terminology (i.e. which paint for the bike-shed), other
names seem better, if less slick.  

There's "layered diverse cryptography", but that conflicts with the L in
TLS.  Also, "strongest-link" is quite clear.  There's several other
alternatives, but maybe not as good. 


PPS: off-topic rant (for TLS ): 

Consider that CFRG has a draft about "Hybrid PKE" (HPKE, *).  This raises a
question: what to call a hybrid of this hybrid (e.g. ECC+PQC) with that
hybrid (e.g. KEM+DEM)?  Hyper-hybrid?

Although HPKE is not destined for TLS, consistent terminology for
cryptography across WGs would be ideal.  It could be confusing if each WG
used different terminology for the same cryptographic methods, or in this
case, the same terminology for different cryptographic methods.  That said,
coordination of a large open organization like IETF is difficult, and so is
choosing clear terminology for complicated ideas of cryptography.



----------------------------------------------------------------------
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.