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

David Benjamin <davidben@chromium.org> Fri, 22 November 2019 00:27 UTC

Return-Path: <davidben@google.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 EDABC120129 for <tls@ietfa.amsl.com>; Thu, 21 Nov 2019 16:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.25
X-Spam-Level:
X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 kTQ2bJcHAhtj for <tls@ietfa.amsl.com>; Thu, 21 Nov 2019 16:27:40 -0800 (PST)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936FD1200B7 for <tls@ietf.org>; Thu, 21 Nov 2019 16:27:40 -0800 (PST)
Received: by mail-pj1-x102e.google.com with SMTP id w8so2249701pjh.11 for <tls@ietf.org>; Thu, 21 Nov 2019 16:27:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sQmiFqZqfwpR7ZjrwQKS4n1hobu+hqlQf4dDRwhZKY0=; b=QOFp7w4XqgIKYU8tXdpdRxQ3XLOF6pXQORoW8F5DkCUTg2Akxgf3LnDggpeFe9mVjT HuFyqvqLHrpoNzesPCs/mBmY1V2iTqUkQyfUTebhbF7JD7wB3sQqYvGkYLCR06p0MaXR Ft+BFPnfWAyJTZOX19JdLPeqorNbDFW8aexB4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sQmiFqZqfwpR7ZjrwQKS4n1hobu+hqlQf4dDRwhZKY0=; b=CvLZhDXpQOSU9sQrbKOC/fXs+dobFnOFJntGa6j0kyv4mQeTL3zhDeL49Kg5VD+LON VZoIMGvN5AmS0DNsUGhum9IvlCt/9EJC2KH0t3sJefokbHWw1SRuhm4U5NvBRx+lwO+P uS3ikiTFbHdLfJmvDsU2jhLfGTLUj3gMDWQ3AqeRONFZJ9Mk9/TEVs1isC1Qmt9uiqtq ee3k6STsispZ7qRmUtpBfKBvDHQgXXMrh4IMcwZ6+2hp2pnhYMijNcRfWdWUUPics+u0 krZh8Sf32Y7KPJj8bnJyiwDbzwJD45+QZLUKaKDdZy/tHJuPYxt85mnnCKP0gJyR4rxH NiSw==
X-Gm-Message-State: APjAAAXsLXzbE4oDklusmtXAJ9L2T2ICq7gG/Ot5dF30Ku7bM+gs2H5f BT8vdwRjXfvGAEr2I6mk3H98kCihg5H687WD0r1T
X-Google-Smtp-Source: APXvYqwZkUOQpey2gWN+Hz/y679BwA4sZqP3TY9vQmQwSVnm/ZsTxW24dx+M/6sSPcNHh3xOR6svo6mZ69P9E15YhIE=
X-Received: by 2002:a17:90a:c789:: with SMTP id gn9mr14697138pjb.99.1574382459682; Thu, 21 Nov 2019 16:27:39 -0800 (PST)
MIME-Version: 1.0
References: <B6698ABE-F0F8-419B-BE3A-17200ED3B380@sn3rd.com> <BN7PR11MB2547C6BC5C63ADF5B36B6C42C94E0@BN7PR11MB2547.namprd11.prod.outlook.com>
In-Reply-To: <BN7PR11MB2547C6BC5C63ADF5B36B6C42C94E0@BN7PR11MB2547.namprd11.prod.outlook.com>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 22 Nov 2019 08:27:23 +0800
Message-ID: <CAF8qwaDz3OsGrJ2H_q3AXqZmyLoOQL1Kq3aFsE-zdJnGrwDrCg@mail.gmail.com>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
Cc: Sean Turner <sean@sn3rd.com>, TLS List <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004077a50597e47b14"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TG7ctnP8-JwqXbLCFWOE5Db0KCg>
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: Fri, 22 Nov 2019 00:27:42 -0000

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> 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> On Behalf Of Sean Turner
> Sent: Thursday, November 21, 2019 1:57 AM
> To: TLS List <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
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>