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

"Martin Thomson" <> Wed, 31 July 2019 03:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36C6712002E for <>; Tue, 30 Jul 2019 20:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=SCeo42nO; dkim=pass (2048-bit key) header.b=xqVBUCZ3
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BuNEnEltF86g for <>; Tue, 30 Jul 2019 20:59:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1FA512008A for <>; Tue, 30 Jul 2019 20:59:30 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id DBA69679 for <>; Tue, 30 Jul 2019 23:59:29 -0400 (EDT)
Received: from imap2 ([]) by compute1.internal (MEProxy); Tue, 30 Jul 2019 23:59:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=5t4+y3fdI4STFEskpGRIYatTpKetonp HsihnDKtGId4=; b=SCeo42nOecwDCvGw/WaF7YB0bf+yZl+anEZvh4qfAf5U8Bj 65jU9x/wPEGY1QTtc5bJf/NrYr1umgXPb2+3Fk7LrsNg7JfQYVH3v6VHveAu0LAy 4rO6qhhX8loZ7k/TV2PmvMZX+4v97+xioj/E7wrYjgRjV9nOv6jjsKjbW9NDUtQq iLxhL1BhC3JoURIM4M7/JjBgi+ESpwPOpXVPKoY3G6q+fnEeq2PaMIzcGDwokZ9d oP2JMOkGZbRCvlBv7lzVAU8aQEKudztbb8FAW9EZ0s0QjoSJLxzbJW+dyKJ30hCU KEVKRcN0OIsup5TtsitwJ4DIRhgFrvUySfvCmUA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=5t4+y3 fdI4STFEskpGRIYatTpKetonpHsihnDKtGId4=; b=xqVBUCZ30d6ALTtM+vmaJJ JgjXNGR/KsEDTMN9IMNZCkANT6NgL2KC2ekJOXNuFO7BSBZueRCFSw/1mAlAAPoj D/yCGjOFGlfGUS/hfMWUnl9HqpYOJ7kLlwYirxT8YEtowm7Uu7GeihwkVzpK7C+8 iiNe7k/U/buBmsPUhLCj7KRvj139//xKLWLmb1C2zL5wZwDMk8Pt5J9tkR9ImY2+ 5xoni1n8+DjSs592n7qw2iuJYQ8B9uDjI7044O76sLoXOt/rw4HkGA1zWdtwuFN9 7pj7mbrsVyz/6r/uJrL0Zq5hw7WONyrxTE7lsIiYvikma+4t7wxXykQDn3HTHUMA ==
X-ME-Sender: <xms:IRJBXa-X3ghBaM-5uQqPYTsOEc3pMAe-WQaGvYnrWmj2ClA9B-4-jg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrleeggdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:IRJBXXYbDGi9-TGXcBzfl6sjAN3RiWsylnVxnepOAaRFMSLq6PvO2Q> <xmx:IRJBXT6YiUzQ4W17jO1m5C9fjGVVPFgnd33XcWO6F7bh4ljXYE2KPQ> <xmx:IRJBXcl5S_D4q7MHC9QOmf0RWhgykjlWRPy4BgoOPwSAp3hNkEfHmA> <xmx:IRJBXQmqnhweZ0hhTQey9WCpv3WRWH-Gc-_xr4V10VQcpI4vKDfJzA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 11DB4E00A2; Tue, 30 Jul 2019 23:59:29 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-799-g925e343-fmstable-20190729v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <>
Date: Wed, 31 Jul 2019 13:59:29 +1000
From: "Martin Thomson" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] Drafts for batch signing and PKCS#1 v1.5
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Jul 2019 03:59:33 -0000

On Wed, Jul 31, 2019, at 13:54, Ben Schwartz wrote:
> 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?

The usual trick when under duress is to attempt to process some requests, and lowering the cost of handling those requests enables higher tolerance to attack and better continuity of service.  A server might choose not to serve clients that don't offer batching if it is stressed.

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

The blinding process is explained in Section 4.3.