The SDES key exchange mechanism for WebRTC has been declared a MUST NOT in the relevant IETF standards since 2013. The SDES specification has been declared Historic by the IETF. Its usage in Chrome has declined significantly over the recent year. This intent is to deprecate and remove this code from Chromium and WebRTC.
The reason why SDES is deprecated is that it is a security problem: It exposes session keys to Javascript, which means that entities with access to the negotiation exchange, or with the ability to subvert the Javascript, can decrypt the media sent over the connection.
When this feature is removed, people attempting to set up such a connection will fail to do so. This should be easy to diagnose.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFNbzG24kGbRFT1sMAroU4ifwv%2BpkA0kU2vkmpHFSgDrQ%40mail.gmail.com.
Away with it!Am Do., 26. Aug. 2021 um 10:45 Uhr schrieb 'Harald Alvestrand' via blink-dev <blin...@chromium.org>:Contact emails
h...@chromium.orgExplainer
NoneSpecification
https://www.rfc-editor.org/rfc/rfc8826#section-4.3.1Summary
The SDES key exchange mechanism for WebRTC has been declared a MUST NOT in the relevant IETF standards since 2013. The SDES specification has been declared Historic by the IETF. Its usage in Chrome has declined significantly over the recent year. This intent is to deprecate and remove this code from Chromium and WebRTC.
Blink component
Blink>WebRTC>NetworkMotivation
The reason why SDES is deprecated is that it is a security problem: It exposes session keys to Javascript, which means that entities with access to the negotiation exchange, or with the ability to subvert the Javascript, can decrypt the media sent over the connection.
Initial public proposal
TAG review
TAG review status
Not applicableRisks
Interoperability and Compatibility
Gecko: No signal
WebKit: No signal
----
Web developers: No signalsDebuggability
When this feature is removed, people attempting to set up such a connection will fail to do so. This should be easy to diagnose.
Is this feature fully tested by web-platform-tests?
NoFlag name
Requires code in //chrome?
FalseTracking bug
https://crbug.com/webrtc/11066Estimated milestones
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5695324321480704This intent message was generated by Chrome Platform Status.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFNbzG24kGbRFT1sMAroU4ifwv%2BpkA0kU2vkmpHFSgDrQ%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJrgemVNeyGP5bw%3Dp40%2Bwc6Zbxi3q-CRWpqV%2BpU%3Dk8%2BgQ%40mail.gmail.com.
What would breakage look like?
What's the requested timeline for the deprecation part of this?
Any plans for targeted outreach for the remaining users?
On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss <yoav...@chromium.org> wrote:What would breakage look like?Once the feature is gone (the end state), anyone attempting to set up a connection using SDES will have their session rejected.Anyone attempting to set the constraint will just have it ignored, like any other unsupported value in a dictionary.
I'm thinking that we should add an intermediate step where anyone attempting to configure SDES has the constructor throw rather than ignoring the member.
--
Web developers: No signalsDebuggability
When this feature is removed, people attempting to set up such a connection will fail to do so. This should be easy to diagnose.
Is this feature fully tested by web-platform-tests?
NoFlag name
Requires code in //chrome?
FalseTracking bug
https://crbug.com/webrtc/11066Estimated milestones
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5695324321480704This intent message was generated by Chrome Platform Status.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFNbzG24kGbRFT1sMAroU4ifwv%2BpkA0kU2vkmpHFSgDrQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
A few questions raised at the API OWNERS meeting today.On Thursday, August 26, 2021 at 1:34:11 PM UTC+2 Harald Alvestrand wrote:On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss <yoav...@chromium.org> wrote:What would breakage look like?Once the feature is gone (the end state), anyone attempting to set up a connection using SDES will have their session rejected.Anyone attempting to set the constraint will just have it ignored, like any other unsupported value in a dictionary.OK. Any enterprise risk here? Are you aware of any enterprise apps using this?
I'm thinking that we should add an intermediate step where anyone attempting to configure SDES has the constructor throw rather than ignoring the member.An unhandled exception seems more risky than a silent failure here, right?Any reason to think console warnings won't be enough?
--
Web developers: No signalsDebuggability
When this feature is removed, people attempting to set up such a connection will fail to do so. This should be easy to diagnose.
Is this feature fully tested by web-platform-tests?
NoFlag name
Requires code in //chrome?
FalseTracking bug
https://crbug.com/webrtc/11066Estimated milestones
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5695324321480704This intent message was generated by Chrome Platform Status.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFNbzG24kGbRFT1sMAroU4ifwv%2BpkA0kU2vkmpHFSgDrQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
On Thu, Aug 26, 2021 at 9:29 PM Yoav Weiss <yoav...@chromium.org> wrote:A few questions raised at the API OWNERS meeting today.On Thursday, August 26, 2021 at 1:34:11 PM UTC+2 Harald Alvestrand wrote:On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss <yoav...@chromium.org> wrote:What would breakage look like?Once the feature is gone (the end state), anyone attempting to set up a connection using SDES will have their session rejected.Anyone attempting to set the constraint will just have it ignored, like any other unsupported value in a dictionary.OK. Any enterprise risk here? Are you aware of any enterprise apps using this?I doubt it. There is no real reason for using it; DTLS is safer and simpler to configure.I'm thinking that we should add an intermediate step where anyone attempting to configure SDES has the constructor throw rather than ignoring the member.An unhandled exception seems more risky than a silent failure here, right?Any reason to think console warnings won't be enough?The connection won't go through anyway unless both ends of the connection upgrade at the same time; throwing is a failure that is more obvious.When things fail, I like to have them fail for obvious reasons.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVEXR9LuZEoJEg6yVSoLBa40qV6Qu7Grh76fdmEhfXcduw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-JRfZewUFrF_WRO-ban7e2U2T%3DNzCWAfVb2t7hbVTQUA%40mail.gmail.com.
On Thu, Aug 26, 2021 at 9:29 PM Yoav Weiss <yoav...@chromium.org> wrote:A few questions raised at the API OWNERS meeting today.On Thursday, August 26, 2021 at 1:34:11 PM UTC+2 Harald Alvestrand wrote:On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss <yoav...@chromium.org> wrote:What would breakage look like?Once the feature is gone (the end state), anyone attempting to set up a connection using SDES will have their session rejected.Anyone attempting to set the constraint will just have it ignored, like any other unsupported value in a dictionary.OK. Any enterprise risk here? Are you aware of any enterprise apps using this?I doubt it. There is no real reason for using it; DTLS is safer and simpler to configure.
I'm thinking that we should add an intermediate step where anyone attempting to configure SDES has the constructor throw rather than ignoring the member.An unhandled exception seems more risky than a silent failure here, right?Any reason to think console warnings won't be enough?The connection won't go through anyway unless both ends of the connection upgrade at the same time; throwing is a failure that is more obvious.When things fail, I like to have them fail for obvious reasons.
Am Do., 26. Aug. 2021 um 22:47 Uhr schrieb Harald Alvestrand <h...@google.com>:On Thu, Aug 26, 2021 at 9:29 PM Yoav Weiss <yoav...@chromium.org> wrote:A few questions raised at the API OWNERS meeting today.On Thursday, August 26, 2021 at 1:34:11 PM UTC+2 Harald Alvestrand wrote:On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss <yoav...@chromium.org> wrote:What would breakage look like?Once the feature is gone (the end state), anyone attempting to set up a connection using SDES will have their session rejected.Anyone attempting to set the constraint will just have it ignored, like any other unsupported value in a dictionary.OK. Any enterprise risk here? Are you aware of any enterprise apps using this?I doubt it. There is no real reason for using it; DTLS is safer and simpler to configure.I bet there are some callcenters using it on the agent side and being callcenters, they won't report metrics.The list of vendors is known though. As is the IETF 2013 consensus that this is a MUST NOT.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU5SOqsi%3DRLqU5UJYW-%2Bq3mRZ3-%2Bt5Bkx9_iPCebyMPCg%40mail.gmail.com.
Is this the right place to ask question? (I came across from google results)
Just curious about the intention "The reason why SDES is deprecated is that it is a security problem: It exposes session keys to Javascript, which means that entities with access to the negotiation exchange, or with the ability to subvert the Javascript, can decrypt the media sent over the connection."
Is javascript a real concern? IIUC, the new insertable stream will allow javascript to be able to access media and the potential usage of it for E2EE will intentionally let javascript to handle E2EE keys.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/39f67083-8391-4e0a-8f3e-549848adbc73n%40chromium.org.