Subject: Re: [rtcweb] Security architecture: Making ECDSA mandatory

From: Randell Jesup <[email-masked]>
Date: Thu, 9 Jun 2016 02:52:12 -0400

On 5/25/2016 6:03 AM, 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?

PLEASE :-)  Is there any objection at all?  If not, let's do it ASAP.

>
>
> On 06/13/2015 12:06 AM, Martin Thomson wrote:
>> I've openedhttps://github.com/rtcweb-wg/security-arch/pull/33

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email [email-masked]!  Way too much spam

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 9 Jun 2016 08:08:09 -0700

It should be merged. 

> On May 25, 2016, at 03:03, Harald Alvestrand <[email-masked]> 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:
> 
>> I've opened https://github.com/rtcweb-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 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 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 pressure
>> with FIPS-2).
>> 
>> I have an implementation that switches Firefox to ECDSA with P-256 by
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Sean Turner <[email-masked]>
Date: Thu, 9 Jun 2016 12:29:20 -0500

I believe it’s 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 <[email-masked]> wrote:
> 
> It should be merged. 
> 
>>> default.  It's much, much faster.  
>>> http://bench.cr.yp.to/
>>>  claims that

---

From: Michael Davey <[email-masked]>
Date: Sun, 12 Jun 2016 10:19:04 +0100

On 25 May 2016 at 16:10, Michael Davey <[email-masked]> 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 exchange)
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 <[email-masked]> 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:
> >>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 12 Jun 2016 04:53:15 -0700

If there's something in particular you'd like to see, a pull request would
be a great way to indicate that.

-Ekr