Re: [TLS] Adoption call for draft-davidben-tls-batch-signing

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Mon, 02 December 2019 14:18 UTC

Return-Path: <pkampana@cisco.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 F16E812006D for <tls@ietfa.amsl.com>; Mon, 2 Dec 2019 06:18:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=I3IykX0J; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fud3rVq7
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 zHmMfHQxe1vd for <tls@ietfa.amsl.com>; Mon, 2 Dec 2019 06:18:05 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D85E12000F for <tls@ietf.org>; Mon, 2 Dec 2019 06:18:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16884; q=dns/txt; s=iport; t=1575296285; x=1576505885; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D1sTRU6oHP9/06XMmj30DS055meYds69p8jgQjwKq/M=; b=I3IykX0JjhWXrgjDb7PoLODw9oknnVH6T28r5lnS+f2ztaUGSngvtEft vtbirsUXNbMir5iYRDPXPR2XJ1sBDT4nVPaDroXDoeZDSBQFShaYlk3An q1iduF+hQKRv5W2C9wSGvfuwUSAkGWy69agMm8W4yY3Wmk5oG6Jz1omM9 w=;
IronPort-PHdr: =?us-ascii?q?9a23=3A4enlgxGuM3J3T6Y1e+T/1Z1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eebpZikiFcJLfFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAQAuHOVd/4YNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBfoEcLyknBWxYIAQLKoQrg0YDinWCX4EBkiGEYoJSA1Q?= =?us-ascii?q?JAQEBDAEBGAEKCgIBAYRAAheBdCQ4EwIDDQEBBAEBAQIBBQRthTcMhVIBAQE?= =?us-ascii?q?BAwEBEAsGChMBASwLAQsEAgEIEQQBASgDAgICJQsUCQgCBA4FCBqDAYF5TQM?= =?us-ascii?q?uAQIMplwCgTiIYHWBMoJ+AQEFgUlBgncYghcDBoE2jBYagUE/gRFHghc1PoJ?= =?us-ascii?q?kAQEDAYFJCQ8rCYJaMoIsjQuDD4VMmFwKgi6HHoUniS+CQYdtj3WXBpFbAgQ?= =?us-ascii?q?CBAUCDgEBBYFpIoFYcBU7gmxQERSMZoEnAQyCP4UUhT90gSiNZ4I/AQE?=
X-IronPort-AV: E=Sophos;i="5.69,268,1571702400"; d="scan'208,217";a="669006817"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Dec 2019 14:18:04 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xB2EI11J023898 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Dec 2019 14:18:02 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Dec 2019 08:18:01 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Dec 2019 08:18:00 -0600
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 2 Dec 2019 08:18:00 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=duSGLTKmzwnP+Qg3p/xkhuVOQitp8jj8G8c5sliPEcz9d/LxMrbkmtdEOQ5uLrF5gBDSUkuDccc6fbVHsOTcvSl4cb/UTkKYdZje3cCRWVWmK1c+2NGY/gXWaFXVN4G2LHwKPihrZZFOktrrqnnJNdeqGhju6kOZJwQJliwMnTb5eguTogL/NtxB3Gwo/gOVdMOI47S4G1BxWyhGtIgZzHRJ246ppBreuYVREzDdeFJ+XxoWjDQegh8UloLDDblGGUejti/wZjTsuiYw+czGbjhriXKVwavFQk2p4v3oD6L6l5UXesaR57jgRcqqqlS4cFGwiMk1H8sEF4/ajgcKtg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D1sTRU6oHP9/06XMmj30DS055meYds69p8jgQjwKq/M=; b=WiQoUjjU1SkJVH8L44y2oW/ah5KDenY3G/RNITGqIEx39jfSOPeXEUjMC1uNaDQlBebqAzY38sTIsehdg9dsuAK3tKWFKY/ClPBAZQGW6dqhelLSInv9tRjywTiHKkRtyth3ZY4tfKzjcrc7y83QSMMq4ITC3xumgPAkce9fEpU2ZwhFxUxKPLmBnZ6dl85uJgmY1T+lS/ft1vI+Pe4uhf5j54Q6eM7GHQg98O3MlO4s6ksT44CviCVkQPjyA/1752JOFK/ekKXmzw1MSHr8CLMtl98MdStmIUZdTfqD/LCvogC9a/kNZtaS9r004Td/kxLJ24E+kjTrWSTElqwEIQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D1sTRU6oHP9/06XMmj30DS055meYds69p8jgQjwKq/M=; b=fud3rVq7liaehQsjcCODCV0U0woDqioeXcTQwLf1p+Gg3TsYc2+edshnlk867VC/KgJ4fHRFGfghkVTQXNxd5ZF778dxPmjeGxzikTPQGCkBV47uTHIh5rbnGPXG0chIgrC6lxigfE7EqsjtBvTqw+xU/sjWDSfGcORmf2N27s4=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2737.namprd11.prod.outlook.com (52.135.244.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.19; Mon, 2 Dec 2019 14:17:59 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802%6]) with mapi id 15.20.2495.014; Mon, 2 Dec 2019 14:17:59 +0000
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: David Benjamin <davidben@chromium.org>
CC: Sean Turner <sean@sn3rd.com>, TLS List <tls@ietf.org>
Thread-Topic: [TLS] Adoption call for draft-davidben-tls-batch-signing
Thread-Index: AQHVoMubo2uwrcUz4kKnCRDJOcjVN6em8dBg
Date: Mon, 2 Dec 2019 14:17:59 +0000
Message-ID: <BN7PR11MB25476085C61E094BCF8A8BEFC9430@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <B6698ABE-F0F8-419B-BE3A-17200ED3B380@sn3rd.com> <BN7PR11MB2547C6BC5C63ADF5B36B6C42C94E0@BN7PR11MB2547.namprd11.prod.outlook.com> <CAF8qwaDz3OsGrJ2H_q3AXqZmyLoOQL1Kq3aFsE-zdJnGrwDrCg@mail.gmail.com>
In-Reply-To: <CAF8qwaDz3OsGrJ2H_q3AXqZmyLoOQL1Kq3aFsE-zdJnGrwDrCg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com;
x-originating-ip: [2001:420:c0c4:1001::10c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d7f1cedc-3162-47f2-05ab-08d777326f11
x-ms-traffictypediagnostic: BN7PR11MB2737:
x-microsoft-antispam-prvs: <BN7PR11MB27378FF1B2A5ABC218F72BF8C9430@BN7PR11MB2737.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0239D46DB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(396003)(376002)(346002)(39860400002)(199004)(189003)(13464003)(99286004)(46003)(81156014)(81166006)(6116002)(66946007)(790700001)(66476007)(64756008)(8936002)(66556008)(66446008)(8676002)(76116006)(6916009)(229853002)(25786009)(5660300002)(2906002)(52536014)(102836004)(6506007)(446003)(11346002)(186003)(53546011)(76176011)(54906003)(86362001)(71190400001)(71200400001)(7696005)(256004)(316002)(14444005)(55016002)(6246003)(9686003)(236005)(478600001)(4326008)(6436002)(54896002)(14454004)(966005)(7736002)(6306002)(74316002)(606006)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2737; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3nc2G8dQJfYdVs8Ozj431+VItYdeajGhedtO6ZbUq8EoApVowvXhUk/9jK+a+/84Rz3G1gowPcKkaqT/FiU8x9pPxJs7kv199o2ZLxE2ULyN9YvMIe79RP1/WE6uf22o7+l4JMhZmla3c4T7HTA6HIxKVek/aoGufyGWp5xLtwmZwJrpl7SXf2lLFPqeJCqCh56nqu24Oa4fJ8MMRQX+O1HitcWJ/g4RYRUEV3wVtpcI4LriT/7uhkpc3cBNGPtTC0gAj+IbAjn2JK+jWI6VJchw3JYE28if4/a59NqX548zjgbB/fa1hKVa9MvIt/ND7lPvyaYUOTV3VCQ8jCQcam2XMB6Qb3Cpnmn9yBx+8LQYgdq3gth9Agj0oZdHGMjKXi6xF/SKIbKKZJizN8CsJOXkPCq8JgZ/ZemBFLDROcJsU7Kp4g5pt9WFTkcQo4eG1RZs1G1klvXpo6VOxXAJpqhv4ZJa6OX/FE8+Akpurvo=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN7PR11MB25476085C61E094BCF8A8BEFC9430BN7PR11MB2547namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d7f1cedc-3162-47f2-05ab-08d777326f11
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 14:17:59.0591 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: CRXiM2aY92GRP9wsvhNAEYsmATC/WwgRvYuxuOSXogt84zo36g9eNLO13RXjskmxrFb2TDPDj241muO29FYP1A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2737
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kdHIIdSM46HYHz8l4T_OT3A9sdI>
Subject: Re: [TLS] Adoption call for draft-davidben-tls-batch-signing
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, 02 Dec 2019 14:18:10 -0000

Thanks David, understood.

It sounds that it would be easier to switch away from RSA to avoid the extra complications of batching, but I understand that is not always possible. Given that this is an Experimental draft, I am ok with the WG adopting it, given that it has merit for some vendors’ usecases.



From: David Benjamin <davidben@chromium.org>;
Sent: Thursday, November 21, 2019 7:27 PM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>;
Cc: Sean Turner <sean@sn3rd.com>;; TLS List <tls@ietf.org>;
Subject: Re: [TLS] Adoption call for draft-davidben-tls-batch-signing

Deployments whose long-term private key is an ECDSA or EdDSA key stored in memory probably have no particular need for this, no. Such deployments probably see a signature cost comparable to the ECDH cost this document does not amortise. The existing signature algorithms are sufficient and no one's proposing removing them.

However, there are many deployments where that is not the case. Hosting providers often get their certificates and keys from customers, who may just upload an RSA key. RSA keys are expensive enough to be the target of DoS attacks. Beyond that, long-term credentials are very sensitive and, yes, there are deployments that RPC to a remote location or even use hardware modules. Due to performance, I doubt the hardware module is common for server keys, but this draft can apply in both directions. We've seen client certificate deployments that do this and hit performance problems when the hardware cannot even keep up with client connection loads. Batch signing is aimed at these kinds of scenarios.

You're right that peers need to be updated, but unupgraded peers do not block results. Load decreases as peers adopt this and DoS mitigations often involve selectively serving and dropping requests based on factors such as cost. This decreases the cost of a class of requests, which allows signers under load to serve more of them.

For my part in the client space, we are interested in implementing this in BoringSSL and Chrome.

On Fri, Nov 22, 2019 at 12:40 AM Panos Kampanakis (pkampana) <pkampana@cisco.com<mailto:pkampana@cisco.com>> wrote:
I am not in favor of adoption, but I could be convinced otherwise.

Sorry as this may have been discussed in IETF-106, but are we that worried about the CPU cost of ECDSA or EdDSA that we are willing to have the server buffer/slow down client connections, generate the Merkle tree and the batch signature? Do we really pull the private key from a hardware module or remote location with every signature instead of keeping it in volatile memory in our application?

I find it hard to buy the problem statement based on the usecases I know of, and such a draft would require a lot of client upgrades and participation in order to have fruitful results. I am ready to buy the argument, if there is concrete data on actual usecases.

Rgs,
Panos



-----Original Message-----
From: TLS <tls-bounces@ietf.org<mailto:tls-bounces@ietf.org>> On Behalf Of Sean Turner
Sent: Thursday, November 21, 2019 1:57 AM
To: TLS List <tls@ietf.org<mailto:tls@ietf.org>>
Subject: [TLS] Adoption call for draft-davidben-tls-batch-signing

At IETF 106 there was support for adoption of "Batch Signing for TLS" [0] as a WG item.  To confirm this on the list: if you believe that the TLS WG should not adopt this as a WG item, then please let the chairs know by posting a message to the TLS list by 2359 UTC 13 December 2019 (and say why).

NOTE:
: If the consensus is that this draft should be adopted as a WG item, then this will necessarily result in a WG rechartering discussions.  We would have gotten to this rechartering discussion anyway now that DTLS 1.3 is progressing out of the WG.

Thanks,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/doc/draft-davidben-tls-batch-signing/
_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

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