You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As described in the (mailing list discussion)[https://mailarchive.ietf.org/arch/search/?email_list=rtcweb&gbt=1&index=bHtRzwKfRoI7bHr2eV1V7r0Ul_s#]
As the RTCCertificates are allowed to be stored or transferred across domains via postMessage it could allow a potential attacker to reuse a past identity assertion when it is no longer valid.
A possible solution would to generate an unique dtls external session Id per peerconnection as described in https://tools.ietf.org/html/draft-ietf-mmusic-sdp-uks-01 and provide that information to the generate and validate assertion js methods.
The text was updated successfully, but these errors were encountered:
Means that the security arch draft needs to say that the security architecture depends on the keying material not being available to move between origins, but that we understand and assume that the identity token can be passed to anyone that the page cares to.
And, Martin also added this PR to the WebRTC spec:
Also w3c/webrtc-pc#1870
As described in the (mailing list discussion)[https://mailarchive.ietf.org/arch/search/?email_list=rtcweb&gbt=1&index=bHtRzwKfRoI7bHr2eV1V7r0Ul_s#]
As the RTCCertificates are allowed to be stored or transferred across domains via postMessage it could allow a potential attacker to reuse a past identity assertion when it is no longer valid.
A possible solution would to generate an unique dtls external session Id per peerconnection as described in https://tools.ietf.org/html/draft-ietf-mmusic-sdp-uks-01 and provide that information to the generate and validate assertion js methods.
The text was updated successfully, but these errors were encountered: