Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

Dan Brown <danibrown@blackberry.com> Mon, 24 February 2020 16:13 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 A32423A0EB7 for <tls@ietfa.amsl.com>; Mon, 24 Feb 2020 08:13:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level:
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 nHRj0oxanaj2 for <tls@ietfa.amsl.com>; Mon, 24 Feb 2020 08:13:28 -0800 (PST)
Received: from smtp-pg11.blackberry.com (smtp-pg11.blackberry.com [68.171.242.227]) (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 B58AD3A0EBD for <tls@ietf.org>; Mon, 24 Feb 2020 08:13:28 -0800 (PST)
Received: from pps.filterd (mhs401ykf.rim.net [127.0.0.1]) by mhs401ykf.rim.net (8.16.0.27/8.16.0.27) with SMTP id 01OG2eBB143847; Mon, 24 Feb 2020 11:13:27 -0500
Received: from xch210ykf.rim.net (xch210ykf.rim.net [10.2.27.110]) by mhs401ykf.rim.net with ESMTP id 2yb0ea4j00-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 24 Feb 2020 11:13:27 -0500
Received: from XCH210YKF.rim.net (10.2.27.110) by XCH210YKF.rim.net (10.2.27.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Mon, 24 Feb 2020 11:13:26 -0500
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.1847.003; Mon, 24 Feb 2020 11:13:26 -0500
From: Dan Brown <danibrown@blackberry.com>
To: Joseph Salowey <joe@salowey.net>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design
Thread-Index: AQHV4pDu9Go5DG3bvEWKQxVxFPuB4agqfwvw
Date: Mon, 24 Feb 2020 16:13:26 +0000
Message-ID: <5f2869e8978a4602be3dade68ec5ec3a@blackberry.com>
References: <CAOgPGoA25d3=irP1BB-=9DJ=sB3zDiRjtqExpCN2qdxbFxtjoQ@mail.gmail.com>
In-Reply-To: <CAOgPGoA25d3=irP1BB-=9DJ=sB3zDiRjtqExpCN2qdxbFxtjoQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [100.64.97.242]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_000E_01D5EB03.6E3E8D00"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-24_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002240128
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-zLtgud0pnuMM2AMKGy4PNu-Y3o>
Subject: Re: [TLS] Call for Adoption: draft-stebila-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: Mon, 24 Feb 2020 16:13:31 -0000

I support rapid adoption, if only based on general principles, as elaborated below.

 

***

 

I have not studied the draft in detail, but I think that strongest-link security is important to allow, the sooner the better, for those that can afford it, I think the benefit is worth cost.

 

I think that the how-to of strongest-link is straightforward enough to start working on it, and I trust the draft authors to have done a good job at it.  Any subtleties or optimizations of strongest-link crypto can be perfected as they arise.

 

I would also favor using both ECC and PQC, (a) _after_ NIST PQC is done, (b) _before_ a Shor-capable QC arrives.  I’m hoping the time of (a) < (b), and therefore hybrid should be ready to roll out.

 

I would also favor adding PQC support to TLS _before_ even NIST PQC is done, then just switching over to NIST choices at the time, even though this seems not to be the interpretation consensus opinion, e.g. CFRG opted to wait for NIST.  I agree waiting for NIST is sensible, if one want the best PQC protection, but not to the point of delaying having any PQC protection, see next point.

 

Getting details right is a known difficulty, with mistakes inevitable.  Haste makes waste, sure, but delay is deadly, so let’s get to debugging the details right away.  Bugs are a nuisance, but better than nothing.

 

I realize that anybody worried about Shor-capable QC, can add a PQC out-of-band to official TLS, but I understand TLS to offer many benefits as security protocol, such that adding in PQC would create synergy (excuse my word choice here).

 

I think “hybrid” is the wrong word.  CFRG has adopted another document where “hybrid” means weakest-link.  Can we choose clearer words?  I like “compound”, but strongest-link, and defense-in-depth are clearer at the price of being longer.  (I prefer hybrid to synergy, of course!)

 

General arguments that attackers will find other system weaknesses than directly attacking crypto are valid, but these arguments already rely on good crypto, and are invalid as an excuse to use weaker crypto, to stop improving crypto.

 

Best regards,

​​​​​

Dan Brown

BlackBerry

 

From: TLS <tls-bounces@ietf.org> On Behalf Of Joseph Salowey
Sent: Thursday, February 13, 2020 12:13 PM
To: <tls@ietf.org> <tls@ietf.org>
Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

 

The authors of "Hybrid Key Exchange" have asked for adoption of their draft as a WG item.  Please state whether you support adoption of this draft as a WG item by posting a message to the TLS list by 2359 UTC 28 February 2020.  Please include any additional information that is helpful in understanding your position.

NOTE:
If the draft is adopted, the working group has change control over the draft and the timing of its progression.  This means the document does not have to be perfect as the working group can and will make changes.  Adopting the draft means the working group thinks the topic is a good idea and the draft is a good place to start the work.  

Thanks,
Chris, Joe, and Sean

[0]  <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dstebila-2Dtls-2Dhybrid-2Ddesign_&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=YGrWhrwPJMcluBHfaPE8h_pponmVeM1dfJFrLKO-Y2c&s=QH64ybNj9x2PM84z-J18Fb113WNyH8szhQxy-UzKDZc&e=> https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/

 

 

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