[Cfrg] W3C WebCrypto WG Liasioning [was Re: ECC reboot (Was: When's the decision?)]

Harry Halpin <hhalpin@w3.org> Mon, 20 October 2014 19:50 UTC

Return-Path: <hhalpin@w3.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C521ACD45 for <cfrg@ietfa.amsl.com>; Mon, 20 Oct 2014 12:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.013
X-Spam-Level:
X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 bGN4Ic4v7YQc for <cfrg@ietfa.amsl.com>; Mon, 20 Oct 2014 12:50:03 -0700 (PDT)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18EF51ACD44 for <cfrg@irtf.org>; Mon, 20 Oct 2014 12:50:03 -0700 (PDT)
Received: from host91-242-static.240-95-b.business.telecomitalia.it ([95.240.242.91] helo=[192.168.1.105]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <hhalpin@w3.org>) id 1XgIxt-0004bP-Kr for cfrg@irtf.org; Mon, 20 Oct 2014 15:50:01 -0400
Message-ID: <54456762.7090606@w3.org>
Date: Mon, 20 Oct 2014 21:49:54 +0200
From: Harry Halpin <hhalpin@w3.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: cfrg@irtf.org
References: <D065A817.30406%kenny.paterson@rhul.ac.uk>
In-Reply-To: <D065A817.30406%kenny.paterson@rhul.ac.uk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/u9WEJ15bxZrv7jXMMm93TbNopT0
Subject: [Cfrg] W3C WebCrypto WG Liasioning [was Re: ECC reboot (Was: When's the decision?)]
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Oct 2014 19:50:05 -0000

Note that there has been a vigorous discussion over exposing whatever
curves the CFRG recommends to the IETF TLS WG as part of the W3C
WebCryto API.

For those who are interested, see here:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618

In particular, there is debate over extensions for ECC curves for
WebCrypto, which currently only the NIST curves. Developers have
requested non-NIST curves during our public "Last Call" review. The
opinions in the Working Group are wide-ranging.

Microsoft has already provided a change request for the NUMS curve and
Trevor Perrin has provided an extension spec for Curve 25519.

With my W3C hat on, I'm just going to announce that due to this
situation there's a possible dependency with WebCrypto on this decision.
Since W3C has a rather strict process and timetable for Working Groups,
knowing the precise schedule for the decision helps our process run
smoother and allows us to co-ordinate our schedule.


   cheers,
         harry




On 10/16/2014 06:08 PM, Paterson, Kenny wrote:
> Dear all,
> 
> Watson rightly pointed out that we are far behind the originally
> advertised schedule for our process for selection of curves to recommend
> to the TLS WG. Other parties in and beyond IETF are waiting on our
> recommendations too.
> 
> The reasons for the delay are quite complex, and I won't go into reviewing
> them here. Suffice to say we've had a lot of really informative technical
> discussion about performance of the different options, benchmarking, etc,
> so the slippage has not exactly been wasted.
> 
> Our first task should be to finalise the requirements that we will use to
> guide the selection process. I think we are close, with a couple of
> outstanding issues:
> 
> 1. Amount of "wiggle room" that should be permitted.
> 
> 2. A more nuanced set of hardware requirements.
> 
> 
> I suggest we use the next *week* to try to finalise the requirements, and
> then November to evaluate the candidates that we currently have (along
> with any new candidates that might emerge) against the final set of
> requirements. 
> 
> With this schedule, we'd miss the IETF 91 meeting for our decision, but I
> don't think having our answer by mid-Novmeber is really feasible. We
> should certainly be able to deliver an early Christmas present to the TLS
> WG.
> 
> To make this work, we'd need the RG to focus on the requirements for a
> short additional period of time.
> 
> So here's a proposal for a new schedule which I believe to be feasible:
> 
> 24/10/14 (1 week from now): we finalise requirements, including hardware
> requirements.
> 31/10/14 (2 weeks from now): we agree on whatever benchmarking system
> we're going to use for performance measurements. (Right now, supercop
> seems like the front runner to me.)
> 30/11/14 (6 weeks from now): we deliver our recommendations to the TLS WG.
> 
> Could people let me know if this looks workable, within the next 24-48
> hours? Meantime, I'll send a message indicating where things stand on the
> requirements list.
> 
> Thanks
> 
> Kenny 
> 
> 
> On 06/10/2014 16:26, "Watson Ladd" <watsonbladd@gmail.com> wrote:
> 
>> Dear all,
>> We were promised on July 27 a process running for 6 weeks. Doubling I
>> get 12 weeks, which is three months, of which two (August, September)
>> have already gone. Am I correct in supposing that we're on track for a
>> decision by Halloween?
>>
>> If we aren't, what remaining issues need to be addressed/when can we
>> expect a decision?
>>
>> Sincerely,
>> Watson Ladd
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>