New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 845506 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Feature



Sign in to add a comment

require pfs ciphersuites for WebRTC peerconnections

Reported by fi...@appear.in, May 22 2018

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36

Steps to reproduce the problem:
1) observe the DTLS client hello from chrome 
2) note non-PFS ciphersuites being negotiated
(see screenshot)

What is the expected behavior?
draft-ietf-rtcweb-security-arch recommends PFS ciphersuites (without making it mandatory to not support other mechanisms)

Given Firefox has required PFS since 2015 (
https://hacks.mozilla.org/2015/02/webrtc-requires-perfect-forward-secrecy-pfs-starting-in-firefox-38/ -- it broke a couple of apps back in the day) the interoperability risk for removing the non-pfs ciphers seems low.

What went wrong?
(feature request)

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 66.0.3359.181  Channel: stable
OS Version: 
Flash Version:
 
cipherlist.png
107 KB View Download
Cc: hta@chromium.org
Components: -Blink>WebRTC Blink>WebRTC>Network

Comment 2 by hta@chromium.org, May 22 2018

The relevant spec text:

   All data channels MUST be secured via DTLS.

   All implementations MUST implement DTLS 1.0, with the cipher suite
   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve
   [FIPS186].  The DTLS-SRTP protection profile
   SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.
   Implementations SHOULD implement DTLS 1.2 with the
   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
   Implementations MUST favor cipher suites which support PFS over non-
   PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites.

draft-ietf-rtcweb-security-arch-13.txt page 16

Labels: Needs-Triage-M66
Labels: -Type-Bug M-68 Triaged-ET FoundIn-68 Target-68 Type-Feature
Status: Untriaged (was: Unconfirmed)
As per comment#0 this seems to be a feature request. Hence marking as Untrigaed for further investigation from dev team.

Thanks!
Labels: -M-68 Needs-Feedback
Status: Unconfirmed (was: Untriaged)
Firefox is now also removing DHE ciphers: https://groups.google.com/forum/#!msg/mozilla.dev.platform/5n16ltyShIE/KNEBtMFAAgAJ

From the numbers i've seen on appear.in DHE is not used at all.
Project Member

Comment 7 by sheriffbot@chromium.org, Oct 7

Cc: anatolid@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: TE-NeedsTriageHelp
fippo@ Thanks for the update.

As per comment #6, adding 'TE-NeedsTriageHelp' and requesting someone from 'Blink>WebRTC>Network' team to look into the issue and help in further triaging.

Thanks..
Cc: huib@chromium.org
Labels: -Pri-2 Pri-3
Status: Untriaged (was: Unconfirmed)
Confirm that the issue exists, so changing status to "untriaged".

Adding @huib to the CC list, but I suspect its priority should be "below getting 1.0 compliance out the door" - so setting priority to 3.

Sign in to add a comment