Should we keep this in a security queue, or there is a better bug type?
Maybe "Feature" or "Launch" with a proper access control label?

Chris proposed to file a security issue

Sounds good, thanks for the comment!

+battre, yitingc, and Privacy, since it's likely to be relevant to their interests as well.

Section 5.5. says:

"""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."""

The MUST and SHOULD language there seems odd; if implementations support non-PFS or non-AEAD, then we must assume they will be used at least some of the time. It seems unnecessary, in 2016, to support such cipher suites, in a new standard? Also SRTP_AES128_CM_HMAC_SHA1_80 doesn't smell great to me. SHA-1's weaknesses perhaps don't apply in an HMAC scenario, but the 80-bit tag seems like an unnecessary limitation? I admit I don't fully understand this problem space or have all the context, though.

Can we maybe use only the strongest cipher suites? Do we know what the installed base looks like right now?

Can an RTC person let us know if http://w3c.github.io/webrtc-pc/#sec.identity-proxy is still current?

I believe the DTLS cipher suite language was added because there wasn't consensus to mandate DTLS 1.2 and thereby PFS, due to existing equipment (non-browser) that was prohibitively difficult to change. So we ended up with this somewhat watered-down "you should really use DTLS 1.2 and PFS" language.

Regarding the SRTP crypto suites, the suite you mention is the strongest that exists unless you move to the GCM suites, which are not yet widely deployed.

identity-proxy is current, but I believe is marked at-risk due to there only being one implementation at present (Firefox)

Hi Ramin - can you look at this? I'm adding Balazs as a second shadow.

-ramine@ +rhalavati@

Also assigning back to palmer@, since this bug asks primarily for security review.

Hi,

I read the document and didn't see any privacy concerns besides the ones mentioned, but will discuss it in our next team meeting to ask for former issues in WebRTC implementations and will add them here.

We discussed this in our team meeting and all former issues that was remembered are already covered in the document.

Currently this is in the security sheriff queue because it doesn't have an impact/severity. I don't have all the context but I'm guessing this is marked as a security issue because a review may turn up some security bugs in our code and so we want to track/resolve it as such?

I'm tentatively assigning low-severity / stable impact based on that to remove it from the queue. But feel free to change that or change to a non-security bug if it doesn't need to be tracked as such :) 

Re-read everything, to make sure there's nothing else.

The open issue noted in section 5.2 does not seem too frightening to me. I am happy with Chrome's screen-sharing chooser; I think it is adequate for informed consent while also being functional and enabling meaningful choices.

There's a potential for a separate feature request about enabling people to choose their IP address privacy mode (see internal b/68695142 and https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling), but if that arises we'll handle it in that bug.

"""UI Requirements: A user-oriented client MUST provide an "inspector" interface which allows the user to determine the security characteristics of the media.""" It then goes on to list specific requirements.

As far as I know, Chrome doesn't have this. But I'm also not sure we need it, because the only allowable modes are all sufficiently modern, and it doesn't seem like the additional detail would edify most users. estark (or anyone else): If you disagree, feel free to re-open this bug or open a new one.

No further concerns.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot