Re: [secdir] Review of draft-merkle-tls-brainpool-03

Simon Josefsson <simon@josefsson.org> Sat, 06 July 2013 07:54 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138B121F9B44; Sat, 6 Jul 2013 00:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.249
X-Spam-Level:
X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OK5eCe4q9vIB; Sat, 6 Jul 2013 00:53:49 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [37.123.176.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3117421F9B45; Sat, 6 Jul 2013 00:53:48 -0700 (PDT)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r667rdvx005030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 6 Jul 2013 09:53:40 +0200
Date: Sat, 6 Jul 2013 09:53:38 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Johannes Merkle <johannes.merkle@secunet.com>
Message-ID: <20130706095338.2a12aa7b@latte.josefsson.org>
In-Reply-To: <51D6E22E.3040107@secunet.com>
References: <20130705004218.233f8942@latte.josefsson.org> <51D6E22E.3040107@secunet.com>
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se
X-Virus-Status: Clean
Cc: iesg@ietf.org, draft-merkle-tls-brainpool.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-merkle-tls-brainpool-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jul 2013 07:54:05 -0000

You wrote:

> > When I read the document, it seems to be missing its "gut".  There
> > is one section "Introduction" and then you would expect the actual
> > specification.  But instead comes the Security Considerations and
> > the rest of the usual IETF boiler plate.  The contribution of this
> > document is hidden in the IANA Considerations.
> 
> If you have a look at version 01, you see that such a section 2 was
> present. Sean suggested to remove it. It seems that your tastes as to
> the structure differ... I am willing to change the structure and
> wording as long as there is consensus on that.

I wasn't aware of this earlier discussion -- it was just my reaction
reading the current document, so you shouldn't take it too seriously.
Version 01 seems to contain a lot more normative language in that
section, maybe that was the issue.
 
> > --->>>
> > 2. Brainpool NamedCurve Types
> > 
> > This document adds three new NamedCurve types as follows.
> > 
> >         enum {
> > 	     brainpoolP256r1(TBD1),
> > 	     brainpoolP384r1(TBD2),
> > 	     brainpoolP512r1(TBD3)
> >         } NamedCurve;
> > 
> > These curves are suitable for use with DTLS [RFC6347].
> > <<<---
> > 
> This is much less verbose as our previous section 2. Maybe this could
> be a compromise between Sean's preference of being compact and your
> preference of the draft having "guts".

Yes.
 
> But isn't this syntax incorrect as there are already code points
> defined for namedCurve? Your text defines namedCurve as comprising of
> three values which is not true.

No, the TLS meta language is not strictly defined, and the above is
fine. If you compare other TLS documents inroduce new types, this is
how you often express adding new enums.  Compare RFC5878 and RFC6042.

/Simon