Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024F912D647 for ; Sun, 12 Jun 2016 04:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 mxQenpka1HkU for ; Sun, 12 Jun 2016 04:53:56 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 D31F012D190 for ; Sun, 12 Jun 2016 04:53:55 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id v137so2462628ywa.3 for ; Sun, 12 Jun 2016 04:53:55 -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=vSljsB6NVXQ6TDLASdun2WXeLwPLd9rFP5mJWYBflko=; b=X7NnadJ1aMcAlL6Y1oVisdiiW0QEz97h1im3K9Az4tYRzxyhqrGp2ALV16JdnA2dtm 8GaFU3ud3HPqj53m2wMaTrlmyTHpVPPcCiCx1mEgE2ueTyxq8X7JXIzjbK5tIC6HPWl9 1sW8pI6YQ1DNhU6uT4RslnK8NwypAYz8KURIbMLOHN+xfqbW4jyE2eQm8zL8hRQzg7ki ukhN4ot4nXLhTEqpQc9sggbRgtqGmV1g3nVmNq8Or33VS9/ZdAMaOLW1UVPqxfFok6ms c/m1qNKoXLqgdvEJ53Oq9hpCy0Vv9QVAVcq3P7iVETSBv3LzmfDpItWoHA8MxZhcIl+E b6kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vSljsB6NVXQ6TDLASdun2WXeLwPLd9rFP5mJWYBflko=; b=IY5i8dALy+TgKTa/9vtf6oHzG3eLIjgfyePeWtnRSXPL28h1I0uGqipbHuMdHW2/wq PSwfqMzlL1Q+eo4W9U84aABB9EllkhRsKNUUJ2EvGdATgkK031tfD/Teden8nAYUkkKB kH1CiqDonDQkNgaxzNAL/rX8pK6Hnn9aroA6wrpyTsNb8b972q/mYzkbVgXaRVXmV/80 fBFNRKsRLzvtfs6r8YayGAUOEhgcFUXDlA0G5w09GU65bpG/Qv2jgdJMYY5Yi3ZnxlcD rIDTMam8b4JrzXH4KtOfzk1VpyzSNQUyzmwzwtqNAP9G4fXGY6nDDBkXkuQjDYKb0tRm bGfA== X-Gm-Message-State: ALyK8tKBRcUsWhNWUuOHZKFKIEoF4fq8ndPypOhRUhP6YKZ4Unl/ubx6dqYDNzJhVauTMG834wIfmYH4TVzuLw== X-Received: by 10.129.4.8 with SMTP id 8mr6047576ywe.44.1465732435058; Sun, 12 Jun 2016 04:53:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.213.206 with HTTP; Sun, 12 Jun 2016 04:53:15 -0700 (PDT) In-Reply-To: References: <57457874.1010708@alvestrand.no> <3A4427FF-A0F1-4B1A-B30C-7FE4319515A2@gmail.com> <3B7A187E-D85C-4EB7-A4A8-221E1FD5E059@sn3rd.com> From: Eric Rescorla Date: Sun, 12 Jun 2016 04:53:15 -0700 Message-ID: To: md84419@gmail.com Content-Type: multipart/alternative; boundary=001a113f575c20e6d10535136d31 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security architecture: Making ECDSA mandatory X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 11:53:58 -0000 --001a113f575c20e6d10535136d31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If there's something in particular you'd like to see, a pull request would be a great way to indicate that. -Ekr On Sun, Jun 12, 2016 at 2:19 AM, Michael Davey wrote: > > On 25 May 2016 at 16:10, Michael Davey wrote: > >> > I would recommend referencing IETF BCP 195. The comments about ECDHE > in that document (and of course the wider issues with weak DH key exchang= e) > may also be noteworthy. > > There is still no mention of BCP 195 in the -12 document. The > recommendations of BCP 195 with regards to ECDHE aren't reflected in the > -12 document. > > -- > Michael > > > On 9 June 2016 at 18:29, Sean Turner wrote: > >> I believe it=E2=80=99s in the newly posted -12 version: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch >> >> spt >> >> > On Jun 09, 2016, at 10:08, Bernard Aboba >> wrote: >> > >> > It should be merged. >> > >> > On May 25, 2016, at 03:03, Harald Alvestrand >> wrote: >> > >> >> In my search for status on ECDSA (we're in the process of switching >> the Chrome default), I came across this in the current draft: >> >> >> >> All implementations MUST implement DTLS 1.0, with the cipher suite >> >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection >> >> profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD >> >> implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >> >> cipher suite. Implementations SHOULD favor cipher suites which >> >> support PFS over non-PFS cipher suites and GCM over CBC cipher >> >> suites. [[OPEN ISSUE: Should we require ECDSA? Waiting for WG >> >> Consensus.]] >> >> >> >> >> >> I also found Martin's PR. It's 11 months old, still open. >> >> >> >> Can we merge this now? >> >> >> >> >> >> On 06/13/2015 12:06 AM, Martin Thomson wrote: >> >>> I've opened https://github.com/rtcweb-wg/security-arch/pull/33 >> >>> >> >>> >> >>> This changes the MTI cipher suites to ECDSA and does a little cleanu= p >> >>> on the corresponding API requirements to more closely match what has >> >>> just landed in the W3C specification. >> >>> >> >>> We discussed ECDSA and the only concerns raised were with >> >>> compatibility. I've done some testing with other implementations wi= th >> >>> no issues, and ECDSA seems to be well supported on all those >> >>> hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for helpin= g >> >>> out with checks there and to NIST for creating certification pressur= e >> >>> with FIPS-2). >> >>> >> >>> I have an implementation that switches Firefox to ECDSA with P-256 b= y >> >>> default. It's much, much faster. >> >>> http://bench.cr.yp.to/ >> >>> claims that >> >>> it's 150 times faster on mobile devices for keygen. >> >>> >> >>> _______________________________________________ >> >>> rtcweb mailing list >> >>> >> >>> rtcweb@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> >> rtcweb mailing list >> >> rtcweb@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113f575c20e6d10535136d31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If there's something in particular you'd like to s= ee, a pull request would be a great way to indicate that.

-Ekr


On Sun, Jun 12, 2016 at 2:19 AM, Michael Davey <md84419= @gmail.com> wrote:

On 25 May 2016 at 16:10, Michael D= avey=C2=A0<md84419@gmail.com>=C2=A0wrote:
>=C2=A0I would recommend referencing IETF BCP 195.=C2=A0 The comments about = ECDHE in that document (and of course the wider issues with weak DH key exc= hange) may also be noteworthy.
=
There is stil= l no mention of BCP 195 in the -12 document.=C2=A0 The recommendations of B= CP 195 with regards to ECDHE aren't reflected in the -12 document.

--= =C2=A0
Michael


On 9 June 2016 at 18:29, Sean Turner <sean@sn3rd.com= > wrote:
I believe it=E2=80= =99s in the newly posted -12 version:
https://datatracker.ietf.org/doc/dra= ft-ietf-rtcweb-security-arch

spt

> On Jun 09, 2016, at 10:08, Bernard Aboba <bernard.aboba@gmail.com> wrote:<= br> >
> It should be merged.
>
> On May 25, 2016, at 03:03, Harald Alvestrand <harald@alvestrand.no> wrote: >
>> In my search for status on ECDSA (we're in the process of swit= ching the Chrome default), I came across this in the current draft:
>>
>>=C2=A0 =C2=A0 All implementations MUST implement DTLS 1.0, with the= cipher suite
>>=C2=A0 =C2=A0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP = protection
>>=C2=A0 =C2=A0 profile SRTP_AES128_CM_HMAC_SHA1_80.=C2=A0 Implementa= tions SHOULD
>>=C2=A0 =C2=A0 implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_12= 8_GCM_SHA256
>>=C2=A0 =C2=A0 cipher suite.=C2=A0 Implementations SHOULD favor ciph= er suites which
>>=C2=A0 =C2=A0 support PFS over non-PFS cipher suites and GCM over C= BC cipher
>>=C2=A0 =C2=A0 suites.=C2=A0 [[OPEN ISSUE: Should we require ECDSA?= =C2=A0 Waiting for WG
>>=C2=A0 =C2=A0 Consensus.]]
>>
>>
>> I also found Martin's PR. It's 11 months old, still open.<= br> >>
>> Can we merge this now?
>>
>>
>> On 06/13/2015 12:06 AM, Martin Thomson wrote:
>>> I've opened https://github.com/rt= cweb-wg/security-arch/pull/33
>>>
>>>
>>> This changes the MTI cipher suites to ECDSA and does a little = cleanup
>>> on the corresponding API requirements to more closely match wh= at has
>>> just landed in the W3C specification.
>>>
>>> We discussed ECDSA and the only concerns raised were with
>>> compatibility.=C2=A0 I've done some testing with other imp= lementations with
>>> no issues, and ECDSA seems to be well supported on all those >>> hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for = helping
>>> out with checks there and to NIST for creating certification p= ressure
>>> with FIPS-2).
>>>
>>> I have an implementation that switches Firefox to ECDSA with P= -256 by
>>> default.=C2=A0 It's much, much faster.
>>> http://bench.cr.yp.to/
>>>=C2=A0 claims that
>>> it's 150 times faster on mobile devices for keygen.
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>>
>>> rtcweb@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/rtc= web
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--001a113f575c20e6d10535136d31--