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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Wed, 07 July 2021 01:47 UTC

Return-Path: <prvs=6822c8ca97=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 7B2AA3A156E for <tls@ietfa.amsl.com>; Tue, 6 Jul 2021 18:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 YqRaGSjzsxld for <tls@ietfa.amsl.com>; Tue, 6 Jul 2021 18:47:09 -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 F33BA3A156C for <tls@ietf.org>; Tue, 6 Jul 2021 18:47:08 -0700 (PDT)
Received: from LLE2K16-HYBRD02.mitll.ad.local (LLE2K16-HYBRD02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id 1671l4sr010087; Tue, 6 Jul 2021 21:47:04 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=QtUdIJ5vTMCS9PQirKJR2flMePpmUrLMWwQ8X+EufkEJ5gGedJ86YbRpxJJIa4ZmLvapBwyot8dAYUcpyVRt5MC7cyiwZwhbwkh8eJtqsAs4r2OeOm2lkySxM3fqOTnZrS9ifnL56rmYMD4tNxRm7e3WYnWCFOXXoWeVoiZrMs3Mu6C6sAMqh5+dVjl3wTFtlxLQmtBFwln+ZDvNuPR5CwRUz7rNw/aOI9DsEO2UDz/In1xMpPyqRdhhDMrGV00vTVyPWw7fYMWvlIGAjsLZF7iuqdZkBBvbshcQd9lHGcvjyTklboJU+WLgYoGkTMU0T7yZWg4pZoEIMq9ga4CCnA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3f7fajNIbCaCPbwX8wCoNgl6dsAexEBR14poxZSguls=; b=xeXvPXsdEznPA+UDlrr6BjxyGjCRRDKBP5cz+CAK3aoke5/qxXKeUAdPUI0trynQdhJ8ClymNL4voV5h5lnNsftbNQ5bHT56SmVwZH7yb3uef2nQMqqYzsKpzmDXgim5C7iYX7EJSnXtjbtEPPpPyOADGavHjA5u7tWM6gZ5efDQIi4pMLn/5p9h2dNWbVZNh26GdLxf4c7yNJgsUZNo7odhBiDT3q2mThE73fjFiMa0q12s5RBHlhZjPvtqvQrBCnZj3982B3XlDzTlWtMFWkbl1fEINbluwQOCl9kw5BjW73aOsRijRunlS6IaK9jVRu597wkc/CpSF8cbwfc+QQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
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: AQHXcs4yiCN9hM3zfEqUO3BIPXGVuqs2e0kA
Date: Wed, 07 Jul 2021 01:47:01 +0000
Message-ID: <7F745088-F606-43EA-8CAC-12E4122175E6@ll.mit.edu>
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:
user-agent: Microsoft-MacOutlook/16.50.21061301
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ll.mit.edu;
x-originating-ip: [129.55.200.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6ae7f401-04f8-4526-3744-08d940e91d46
x-ms-traffictypediagnostic: SN5P110MB0367:
x-microsoft-antispam-prvs: <SN5P110MB0367CD6ECA248FFF31C0D935901A9@SN5P110MB0367.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:5236;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7YVuaNQXSZalzhAUGQcFZZWEsKpMmz8xWLawAen18eErplkWAJuEqxhPnO7mLDdguPaj6BZojUNBTpDf39nsC43lR3nddrPB8SXEHlIplVinUdnXkHTqPXCWkQJV4dupCk7R7Gt9qI2kkFFsDMbUSILtStm4T8j6xVwJ07zTYYlz1YbOMER94vZx+1KYVEytqrwLs6yZxkXIuCslAxwQ7a6qVeTwRG1RH7n1sBvlIWpXK5kWmqkjxtq0lzz2t4BNeU458QUjn9sv95DbXBjrjkfs6ydBOJjXTGCRZOLKYZvXpUeMZJs8K1WCFKJOhM+gr4aSjAtteZ/gKtWj2JxpQFCKbJwHbRgAy047w96g8tO7VeCv0tk0pHfJ78OskOWlrG3p3MTFcbvW8pjdLM3qAcYwbcO42s4A2u1EJq5FKgUqack4sHQlyQyvnSszzMBOi9rzoy5JkjFd16mvwFWxPXpDb3z7uDwV0kxcfLOjy55jh2DAdVXTKkwy7OyoyBVAXpf/CiYbyRA/Oe2YBvqp/eOZgzIBSNtj8ammtmjFQ0D0aSeVxemdlaC9pudn3RNZ9sYyyaKC0+y+7GhQArohM+M+llHzQPRaJWooM6dMWJPsVkQYIw1B/5x83YEg9mB8
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(396003)(39860400002)(376002)(346002)(4326008)(8676002)(99936003)(6506007)(8936002)(71200400001)(6512007)(66476007)(66556008)(75432002)(66446008)(5660300002)(2906002)(86362001)(83380400001)(316002)(33656002)(66616009)(186003)(66946007)(64756008)(6486002)(478600001)(2616005)(122000001)(110136005)(966005)(38100700002)(76116006)(26005)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: ei1FYqFgAQGsy/EHyGWaMhYFckwXR5Ei0AHWZQaxERRTa7fEV2mqQ8t/L/b7/8ykk7j3lmumj/Zv3tT7tNxULL1+3uwXI5b/kTyv0TIMbSYiCHbWdWFVlo1NmJ6klviYIW47FboL7AVs6j0N73/28k33TiPtpw0CUIsbwyk9A8wmzxByb7P+Gr8PXD/BYsjpUG+AtNG8hmYfnFgQ4hzpBSIABalaBlD2xb3Lk1HSIZnZ8ZrNZXYklG48r6vUj/xphBcBWGJxyfpgXyMu+DXgXOnSYacuKbgHjESQg9EyVDxYbjGcGxjL7RqC7OkSxnYDsjq43blvPTFpE+xRSqdJxKHwkDMelQUzf/rFOklI3TnpUFLriqYPhSt2Aaat7aU2XDrvla5oz36L4hvQdEklIt2t76CukALpcXEmEXeVq3OGJrdZgUROvf9EpxcFqWAbkVnWqvvoJfYHcw34URva5xNsIAvcgcmS84MHgyEh/Vi3YvQR8XxIdImQDhDUv1DtRzbZe3ICRYoDG4AKRlQgAbLlBEsmaZT2FuyP4ky67AKlyz+v9HQhStY5IcC1YVnZB7/jQk+4WJ6oBOcnEpZY2keTUQr+Oe/wr4L9vdWQDTL2Af2vIVPMod3jSwUP2kuYsKXoJPrOXvj8s5yw0s/oL0I69GmNmayvLgAgaVgbO/a07MhQ47tBdD9eCY3mHZogItKPpyNMzErG+zK2EywzQA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3708452820_507557773"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ae7f401-04f8-4526-3744-08d940e91d46
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2021 01:47:01.1284 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN5P110MB0367
X-OriginatorOrg: ll.mit.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-06_13:2021-07-06, 2021-07-06 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-2103310000 definitions=main-2107070007
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/W-MuHREKmOC-_sfn1I2TCV-SSps>
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: Wed, 07 Jul 2021 01:47:12 -0000

I personally do not find the proposed approach appealing (or even useful).

There are three possibilities.

a. Quantum computers capable of breaking crypto (QC) become practical *and* NIST PQC winner(s) resist both quantum and classic attacks;
b. QC become practical, and NIST PQC candidates fail (doesn't matter whether they fall to classic or quantum attack!);
c. QC do *not* materialize, *and* PQC candidates fail to classic attacks.

The only possibility justifying the hybrid exchange is (c), which I personally find the least probable. In both (a) and (b) addition of ECC does not make the KE any more secure than without it.
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare
 

On 7/6/21, 21:19, "TLS on behalf of Douglas Stebila" <tls-bounces@ietf.org on behalf of dstebila@gmail.com> wrote:

    Dear TLS working group,

    We wanted to see if there is any further feedback on our draft "Hybrid key exchange in TLS 1.3" (https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/) and what steps are required for it to advance further.  We have not received any new feedback from the working group since we posted our last non-trivial update in October 2020.

    The draft as written does not actually specify any post-quantum algorithms nor give identifiers for specific algorithm combinations, only the formats for hybrid key exchange messages and key derivation.  We have received a suggestion that the draft be updated to include identifiers for hybrid key exchange combining elliptic curve groups and the KEMs currently in Round 3 of the NIST PQC standardization process, so that implementations can begin testing interoperability using numbers listed in the draft, rather than relying on ad hoc lists for such purposes.  Is that something the working group would like to see, or would you prefer to leave it as it currently stands, without any specific algorithm identifiers?

    Douglas, Scott, and Shay
    _______________________________________________
    TLS mailing list
    TLS@ietf.org
    https://www.ietf.org/mailman/listinfo/tls