Re: [TLS] Call for Consensus: ECC on standards track

mrex@sap.com (Martin Rex) Thu, 26 June 2014 05:34 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369DA1B2ABE for <tls@ietfa.amsl.com>; Wed, 25 Jun 2014 22:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 7iBetRmSrpdt for <tls@ietfa.amsl.com>; Wed, 25 Jun 2014 22:34:49 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8601B2AB9 for <tls@ietf.org>; Wed, 25 Jun 2014 22:34:49 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s5Q5Yh2X026198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2014 07:34:44 +0200 (MEST)
In-Reply-To: <CABcZeBOJ2nCbZmGV6=6Es0jH+PDmtAFMiTUv6EccAGbNtSjTdQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 26 Jun 2014 07:34:43 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140626053443.DBBE71AD68@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z0UOxFyhOvtOXL2uxTtG7FU-_Ww
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] Call for Consensus: ECC on standards track
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: <http://www.ietf.org/mail-archive/web/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: Thu, 26 Jun 2014 05:34:51 -0000

Eric Rescorla wrote:
> On Wed, Jun 25, 2014 at 8:45 PM, Martin Rex <mrex@sap.com> wrote:
> 
> > Sean Turner wrote:
> > >
> > > Based on the mailing list discussion, the chairs believe that there is
> > > strong support to publish TLS ECC Cipher Suites on the Standards
> > > Track
> > >
> > > - Should we include TLS ECC Cipher Suites for AES-GCM
> > >   directly in the TLS 1.3 document (and hence on the Standards Track).
> >
> > You would have to move the whole ECC for TLS stuff to standards track
> > before thinking about adding any cipher suites that depend on this
> > into the base TLS spec
> 
> Unless I am missing something, RFC 3967 permits normative references
> from Standards Track RFCs to Informational RFCs, provided that those
> issues are called out in IETF LC. So, I believe we could simply refer to
> 4492 from TLS 1.3 provided we follow the RFC 3967 Section 3.

The copy of rfc3967 that I'm just looking at contains the following exclusion
(last paragraph of Section 3):

   This procedure should not be used if the proper step is to move the
   document to which the reference is being made into the appropriate
   category.  It is not intended as an easy way out of normal process.
   Rather, the procedure is intended for dealing with specific cases
   where putting particular documents into the required category is
   problematic and unlikely ever to happen.


-Martin