IETF Logo Mail Archive

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

David Benjamin <davidben@chromium.org> Wed, 31 July 2019 17:23 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 17AA9120480 for <tls@ietfa.amsl.com>; Wed, 31 Jul 2019 10:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.251
X-Spam-Level:
X-Spam-Status: No, score=-9.251 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 X4fVXVmxw-d0 for <tls@ietfa.amsl.com>; Wed, 31 Jul 2019 10:23:03 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 1AA04120477 for <tls@ietf.org>; Wed, 31 Jul 2019 10:22:47 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id r6so49859016qkc.0 for <tls@ietf.org>; Wed, 31 Jul 2019 10:22:47 -0700 (PDT)
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=srkGQ+vQag8YzYiwOoNYiLeSUjU/Py2eplnhUKoBEzg=; b=dslCE822nBeSoBFbAyF0V4kB1uWnaeXJpIISV3dP2U/gbhHR3ySCxRK4Wq1gqhzesT iZlHY+vmtzlQX7qb0OLggpJgvffecmr69mZN7whw6pQogG63bh1MIp+FZ6N3SYM4hvoE zEfKYCpwMjteanoCiFl1d52aK5HTTlxJdRsMo=
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=srkGQ+vQag8YzYiwOoNYiLeSUjU/Py2eplnhUKoBEzg=; b=uedkr+UO3kGSS4kqGd6Qplyja1R8umDgvb3ZX02Rire/3b2xPs4dQ30ynfJkBMV4Dd OKPJPVLGvi0z+aSA7oylEIZXRXCvgYHN8ojMcYj+f/9gWkkBfACsj/seqm3PmLGkWDrg 1acK7Eq01ddtLenUC2pS5EYbVQ2ncF1YLlu3pLZQ6Kc6D0IJGnAoJJWBcTimnbzdr6bv c8Gg5AAmZxlfg4IteK3zoDftFDgpu5edWMk4ZqB17tSSy1J5suJytuyUuYXxqUytE1cZ Ni9VABICZkfrBHvAx1qV8XRCO0I8P9W+JTXu8Uwqc9QUOUVAF7NOexXWzxuu1bd6AKsp Hc1g==
X-Gm-Message-State: APjAAAXVoW+WYvnWobZZAQUZ4I9+CTzhjIPAA0isGpiBozQukjxA1G+b bYJCR5h7KFhJeiV09kiE/E9NarwUSeCnx4dJQPIn8iGpgg==
X-Google-Smtp-Source: APXvYqzq8JxUflPk5689qLP3xs0L44hhSd1nyONYNfrpOYkq2nIbYGPCAQhtI5xfk11dUFoycLfi/7OFuCSh+oJkb4k=
X-Received: by 2002:a37:a14e:: with SMTP id k75mr83153569qke.65.1564593765997; Wed, 31 Jul 2019 10:22:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaDxRhGXc522Rf4C-8OcGM4Mm08Xca4KNNpHcT=4Va89aA@mail.gmail.com> <CABzBS7k-Dy6QOqxvYug63iYnGf1nyvjZdp12jdL0XefdPt5BOQ@mail.gmail.com>
In-Reply-To: <CABzBS7k-Dy6QOqxvYug63iYnGf1nyvjZdp12jdL0XefdPt5BOQ@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 31 Jul 2019 13:22:28 -0400
Message-ID: <CAF8qwaCRxVQFvGivOf_Y3QMiUPvH_u6Y2PXgbKnq1K8fPkmfZg@mail.gmail.com>
To: Thom Wiggers <thom@thomwiggers.nl>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a45515058efd5fdc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/s2SCCZ0qogoyNlnSktE7UXUWj5E>
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 17:23:05 -0000

Thanks! I've applied those fixes to my local copy. They fixes will be in
the -01 revision.

On Wed, Jul 31, 2019 at 3:42 AM Thom Wiggers <thom@thomwiggers.nl> wrote:

> Hi David,
>
> I've found some small textual issues (I'm looking at the PDF version):
>
> In section 3.1 in step 1 (on PDF page 4):
>
> "element 2*i+1 to a random byte of string of Hash.length bytes."
>
> This sentence is slightly puzzling. A random bytestring?
>
> Section 4.2, first paragraph, last sentence:
>
> "so batch signing inherits preserves separation"
>
> This sentence contains two verbs.
>

I also apparently never finished that sentence. Oops. :-) In my local copy,
this paragraph now reads:

Signatures made by the same key in different contexts should be separated to
avoid potential cross-protocol attacks. Inputs to the batch signing
algorithm
include any existing context strings, such as TLS 1.3's distinct client and
server labels or new labels that may be allocated by future versions of TLS.
By signing over those labels, batch signing preserves separation between
those
inputs.


> It looks like an interesting proposition, which could also be interesting
> in the context of some of the post-quantum signing algorithms.
>
> Cheers,
>
> Thom
>
> Op di 30 jul. 2019 om 02:16 schreef David Benjamin <davidben@chromium.org
> >:
>
>> 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