IETF Logo Mail Archive

Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

Ben Schwartz <bemasc@google.com> Wed, 31 July 2019 03:54 UTC

Return-Path: <bemasc@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 CDE0C12008A for <tls@ietfa.amsl.com>; Tue, 30 Jul 2019 20:54:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ihaK5cjnrSnZ for <tls@ietfa.amsl.com>; Tue, 30 Jul 2019 20:54:44 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 65D7412002E for <tls@ietf.org>; Tue, 30 Jul 2019 20:54:44 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id m24so133255474ioo.2 for <tls@ietf.org>; Tue, 30 Jul 2019 20:54:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WuqyGS8+ab6dorTAhUW8EHs8lwJvRUv+lCCekE/38GY=; b=ARZ17mFW0A8TrBA8ABMJ5HHElbgbEShfhXrPOExi/lTtSTt01K28HxsWiL8mtfm9wI gWMkksTqXAh5uQxd/ktAjNL40t7/f7qluQuDBMw4Y2jiQSRmR/ZXww49gXPhqwI1t7kD u9mxk9LpRlkip9kurCcg5Z47GrNqexj82liYbw2X2YC4wQghB+A3k4RZzeZCkxI7UoX/ khccd8uy0vvIeroPKRiMdKX8Ui409R7eHBLsWzT/hWicTWmPIlXJHsD98Q/r3bV3zyns pSXmHKBas2ZVntHIhfCmhXOTRq3onSjg5HWFbKqlwVl3df8gFPaVFSDT/kASuEH3FFpk o56Q==
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=WuqyGS8+ab6dorTAhUW8EHs8lwJvRUv+lCCekE/38GY=; b=tM1dFCTk9xZeYeiyzFwnxIkjucX9gYZ+Tdsn6ig0D5dNpFUKJuWFlrCMoSw6PdWam7 PLSjM/64QqBTDW7Z4V6631gP7nQzygGPpbUADagowPRP4Qvvg81jXCcnULgianUfheQK ekm+ds4P4VhBnnZOsKJ43XSlCiNBWH/dEaFO3Zp/B+28WCN/gPyVDpl3UNEDUbYa/RBT u0EEf2sYVV09DeIPkWXAYr1xLJ8jxWjNdU68OAmRgK4t95sPtzW7DfX0oSeAqoHxQnaC uhAe6NmnkFUgkjXAcQ5miNSNGT3ZE/6KNTKXCFTBXiSKa1zeCw9IVhp2cBr5PJJdbSZc /X8A==
X-Gm-Message-State: APjAAAV5qsH9Y4YP0mf9Cs8hKLIshlHI8sZSyyeRDlfH0Y2aveY9h7lb c0ltzlxCbNdwljP+XzYqF3wjL2RCMeJ6J1tPvNG1Gw==
X-Google-Smtp-Source: APXvYqwHfkgqcnvfuOVR0WL5qwr2w1zfOvndXNENQuLr5L0FjRpVO21wMhMqpysIf95P9c+uuCk1ZDNB39C6W8uqwkY=
X-Received: by 2002:a6b:5a17:: with SMTP id o23mr3295324iob.41.1564545283273; Tue, 30 Jul 2019 20:54:43 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaDxRhGXc522Rf4C-8OcGM4Mm08Xca4KNNpHcT=4Va89aA@mail.gmail.com> <CAF8qwaD=5B9AXkGziwHZ-=LGH-n6fW0KQ9cQfZ2DWhpjDujhEQ@mail.gmail.com>
In-Reply-To: <CAF8qwaD=5B9AXkGziwHZ-=LGH-n6fW0KQ9cQfZ2DWhpjDujhEQ@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 30 Jul 2019 23:54:30 -0400
Message-ID: <CAHbrMsCBvZz7j5uH-gKfDrxc4ub=btZh7RyxNZmaADXZEEFJ+A@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000e0c6ac058ef21528"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BGGWm-OBnL4yOteK9mhC6E1lcP0>
Subject: Re: [TLS] Drafts for batch signing and PKCS#1 v1.5
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, 31 Jul 2019 03:54:47 -0000

The batch signing idea is very cool.  I'm not entirely sure I understand
the intended use case, though.  The intro suggests that this motivated by
DoS defense, but presumably an attacker who controls their own TLS client
stack could simply omit support for these signature schemes.  Do you
envision a future where servers can safely omit support for all the
non-batch signature schemes?  Or are you thinking of attackers who don't
control the TLS client stack?

Minor question: in the tree diagrams, m2 goes to t04.  Is there any reason
it couldn't go directly to t12?  That would seem more natural to me.

On Tue, Jul 30, 2019 at 3:09 PM David Benjamin <davidben@chromium.org>
wrote:

> Oops. draft-davidben-tls-batch-signing-00 cites
> draft-davidben-http2-tls13-00. That should be
> draft-davidben-tls13-pkcs1-00. (The XML file took a really long time to be
> created, so I manually tried to recreate it based on another file and
> forgot to update one of the fields..) I'll fix this in -01.
>
> On Mon, Jul 29, 2019 at 8:15 PM David Benjamin <davidben@chromium.org>
> wrote:
>
>> Hi all,
>>
>> I’ve just uploaded a pair of drafts relating to signatures in TLS 1.3.
>> https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00
>> https://tools.ietf.org/html/draft-davidben-tls-batch-signing-00
>>
>> The first introduces optional legacy codepoints for PKCS#1 v1.5
>> signatures with client certificates. This is unfortunate, but I think we
>> should do it. On the Chrome side, we’ve encountered some headaches with the
>> TLS 1.3 PSS requirement which are unique to client certificates. The
>> document describes the motivations in detail.
>>
>> The second describes a batch signing mechanism for TLS using Merkle
>> trees. It allows TLS clients and servers to better handle signing load. I
>> think it could be beneficial for a number of DoS and remote key scenarios.
>>
>> Thoughts?
>>
>> David
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email