On Fri, Aug 27, 2021 at 7:31 AM Philipp Hancke < philipp.han...@googlemail.com> wrote:
> 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 <yoavwe...@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 <yoavwe...@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. > Are there vendors still selling such software nowadays? > > >> >>> >>>> >>>> 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. >> > > The existing behaviour of throwing in setRemoteDescription when receiving > an SDES-only offer seems good (and works in both Chrome and Firefox). > The error code might need some work, it differs between Chrome and Firefox. > > We have some test coverage for this: > > https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/peerconnection/RTCPeerConnection-sdes-constraint.html;l=11;drc=09074552ce314b5d942d960ceaa90599671ee137 > I'll add a negative assertion as a WPT. Why ask when you can write a test > :-) > > >> >> >>> >>> >>>> >>>> >>>>> What's the requested timeline for the deprecation part of this? >>>>> >>>> >>>> I'd like to get the deprecation warning in 95 (stable Oct 19), start >>>> throwing in 97 (stable Jan 4), and removing the code entirely in 99 (stable >>>> Mar 1). >>>> >>>> >>>>> Any plans for targeted outreach for the remaining users? >>>>> >>>> >>>> Only the usual PSA on webrtc-users and discuss-webrtc + word of mouth. >>>> >>>> >>>>> >>>>> On Thu, Aug 26, 2021 at 11:05 AM 'Philipp Hancke' via blink-dev < >>>>> blink-dev@chromium.org> wrote: >>>>> >>>>>> stats here: >>>>>> https://www.chromestatus.com/metrics/feature/timeline/popularity/2383 >>>>>> >>>>> >>>>> Impressive decline in usage! >>>>> >>>>> >>>>>> Away with it! >>>>>> >>>>>> Am Do., 26. Aug. 2021 um 10:45 Uhr schrieb 'Harald Alvestrand' via >>>>>> blink-dev <blink-dev@chromium.org>: >>>>>> >>>>>>> Contact emails...@chromium.org >>>>>>> >>>>>>> ExplainerNone >>>>>>> >>>>>>> Specificationhttps://www.rfc-editor.org/rfc/rfc8826#section-4.3.1 >>>>>>> >>>>>>> Summary >>>>>>> >>>>>>> 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 componentBlink>WebRTC>Network >>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC%3ENetwork> >>>>>>> >>>>>>> Motivation >>>>>>> >>>>>>> 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 statusNot applicable >>>>>>> >>>>>>> Risks >>>>>>> >>>>>>> >>>>>>> Interoperability and Compatibility >>>>>>> >>>>>>> >>>>>>> >>>>>>> Gecko: No signal >>>>>>> >>>>>>> WebKit: No signal >>>>>>> >>>>>> >>>>> Filing for signals may be an overkill here, but are there bugs filed >>>>> on other implementers asking them to follow? >>>>> >>>> >>> Is SDES shipped in other browsers? What's the status there? >>> >> >> I believe that neither Firefox nor WebKit ever shipped SDES, but I put >> "no signal" because I haven't checked. >> >> >>> >>> >>>> >>>>> >>>>>> >>>>>>> Web developers: No signals >>>>>>> >>>>>>> >>>>>>> Debuggability >>>>>>> >>>>>>> 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 >>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>> ?No >>>>>>> >>>>>>> Flag name >>>>>>> >>>>>>> Requires code in //chrome?False >>>>>>> >>>>>>> Tracking bughttps://crbug.com/webrtc/11066 >>>>>>> >>>>>>> Estimated milestones >>>>>>> >>>>>>> Link to entry on the Chrome Platform Status >>>>>>> https://www.chromestatus.com/feature/5695324321480704 >>>>>>> >>>>>>> This intent message was generated by Chrome Platform Status >>>>>>> <https://www.chromestatus.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+unsubscr...@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 >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFNbzG24kGbRFT1sMAroU4ifwv%2BpkA0kU2vkmpHFSgDrQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>>> 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+unsubscr...@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 >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJrgemVNeyGP5bw%3Dp40%2Bwc6Zbxi3q-CRWpqV%2BpU%3Dk8%2BgQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVhNsxmU97TqvsxCDJ1CWP61aLpwZ_QSY5GOiKymkRQ4w%40mail.gmail.com.
