IETF Logo Mail Archive

Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

Eric Rescorla <ekr@rtfm.com> Tue, 17 July 2018 15:48 UTC

Return-Path: <ekr@rtfm.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 32095130F3F for <tls@ietfa.amsl.com>; Tue, 17 Jul 2018 08:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 3cjQFKAKpASW for <tls@ietfa.amsl.com>; Tue, 17 Jul 2018 08:48:31 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 21A7F130F66 for <tls@ietf.org>; Tue, 17 Jul 2018 08:48:31 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id g6-v6so1188475lfb.11 for <tls@ietf.org>; Tue, 17 Jul 2018 08:48:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q4UDfZteJ9Cdzn1cxXpRZ/GJrZB7L5sI6aOo5rrcKkk=; b=U36gWfItesfYKsJ1SrmoDGOtEO30Sar/cbSVQyRbKGe22FPEIKXRO0Fp9Zjck5mvs0 nIO73Hplf7DvZyvkSLeCT2RGm7LwXZ0N1yiGYSN2viVq/codH5Az/NFHE+2MQmT8mREx mHZGvdSAQgi5WLKjEg2HwPOjxC61LOW8+uZThzBW2+FUYmzAvboqs4ylKmoPng47Zo8n 1Wd5Cm2zMonh7cdIzdsLlqH8FQaW96JxIsmPsfgtAMGaI2J4ktAn2Awa1mZnwv0GL+2/ wr2t6V3YzA6T1/tQpNnW+AbnyafKYVKO/sfbrHjSU/1sm1NyjF1b0RklLW24lHhiNR5O 3xiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q4UDfZteJ9Cdzn1cxXpRZ/GJrZB7L5sI6aOo5rrcKkk=; b=ahcC9EiJvzMDWC0WvC84BLutsSk31LeN3GWaJC9XeOKuZ94A6Y2eY+L0BNohhwoJyC SXLVuEieyQ1pEsUthW6JhxqTzMqt0DyW00vz4Ni8VlM76i0bK0IhR+e6Q99nUcCobEWv UG/P++14BD+K/D/UsFTIe8smDb0yMOIZloRKGljC8jTddYQ7dByQRqSSL1iFPefk68hi gsSc3QAJ0YqP1U0Hu4p3K4VmmDd5vNx8zpBycIY4wSzRdQwpMfudgHp1nIm44t3mdeel Yg0M6bzPJCJkHnBlvgv4/wCmp4/CUkoo8Hyt4OASuRWWTMS3tcMJs1Cdm3ypdkQOCSJP eSfA==
X-Gm-Message-State: AOUpUlEN0gQp9IznFTcd9s4qECQgNIYgNs1gwRyov2uFLVgBnpmG4RPG 79TXUZPetLG63vH1DdvcnccVRMJrVKn7xU/sDTY8hg==
X-Google-Smtp-Source: AAOMgpciDIRXHGAzHp+cBunArTTtt5MojBJsgYrjdwNFCTR1e1zWRRgdUBZPI8e+AQ1/ENYvENgU6V/Pp8ZhuLZTVzI=
X-Received: by 2002:a19:a417:: with SMTP id q23-v6mr1587346lfc.59.1531842509375; Tue, 17 Jul 2018 08:48:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 08:47:48 -0700 (PDT)
In-Reply-To: <5cde94e3-416a-6773-c35c-9bb3952f5097@secunet.com>
References: <DE8E4C1F24911E469CC24DD4819274AA2770426C@mail-essen-01.secunet.de> <20180717155550.1a18202e@computer> <5cde94e3-416a-6773-c35c-9bb3952f5097@secunet.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 17 Jul 2018 08:47:48 -0700
Message-ID: <CABcZeBNjewd4B3BcjXB8ePk7LCxR8HaiQpb+7oa9dBHYihLWMQ@mail.gmail.com>
To: Johannes Merkle <johannes.merkle@secunet.com>
Cc: Hanno Böck <hanno@hboeck.de>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009f9d43057133e0c7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TYwoMJ_54VlHWFr7589w7cGStGU>
Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 17 Jul 2018 15:48:47 -0000

On Tue, Jul 17, 2018 at 8:04 AM, Johannes Merkle <
johannes.merkle@secunet.com> wrote:

> Hi,
>
> > There's a very strong reason against this: It creates complexity. More
> > opportunities for attacks, more fragmentation of the ecosystem. I
> > believe I speak for a lot of people here when I say that fewer
> > algorithms is better and having more algs "just because" is not a good
> > reason. With that in mind an algorithm doesn't have to be weak to be
> > removed from TLS. It's reason enough if it's rarely used and doesn't
> > have a significant advantage over alternatives.
>
> Crypto agility definitely has its value. There are not so many curves
> supported by TLS 1.3, and all of them use primes
> of a very special form. Of course, this is exactly what makes these curves
> faster than the Brainpool curves, but from a
> security perspective it might be advisable to have alternatives at hand
> which have very different properties (and have
> not been generated by the NSA using seeds of obscure origin). In
> particular, as the code points had already been
> registered and have already been implemented in some products.
>

Well, I think the question here centers on what "at hand" means. We've
generally decided to limit the number of algorithms we recommend (the
Recommended) column in the registry. I have trouble seeing any situation in
which we would have these curves as Recommended. And so "at hand" really
means (1) code points assigned and (2) some small number of people who
don't follow our Recommended advice do them. I have trouble seeing, for
instance, many Web implementations having these curves.

If we think that we need a backup set of curves with yet different
properties from the CFRG curves and the NIST curves, then we should ask
CFRG to produce such curves, which we would then feel good about marking
"Recommended"

-Ekr


Furthermore, the reasoning in the draft that these curves "should be
> assumed to be potentially unsafe" is completely wrong.
>
> Johannes
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email