Security Considerations for WebRTC
Summary: Has enough positions to pass.
(Ben Campbell) Yes
I disagree that this should be informative. It does have sections that have informational content, but it also has sections that serve as security considerations for WebRTC as a whole. (nit) §4.2.1: Please expand ICE on first mention.
Alissa Cooper Yes
PS seems like the appropriate status for this document given its role in the WebRTC document suite. = Section 4.1.4 = "The attacker forges the response apparently http://calling-service.example.com/ to inject JS to initiate a call to himself." --> This doesn't read correctly. = Section 4.2.4 = It seems like this section should reference draft-ietf-rtcweb-ip-handling.
(Spencer Dawkins) Yes
Adam Roach Yes
Ignas Bagdonas No Objection
Deborah Brungard No Objection
I support PS. As the shepherd writeup says, this document will be the reference point for other work. To me, that says it is more than "informational".
Benjamin Kaduk (was Discuss) No Objection
Suresh Krishnan No Objection
Warren Kumari No Objection
I do not have strong views on the track, but if pressed, I lean towards PS.
Mirja Kühlewind (was Discuss) No Objection
Based on feedback provided by other ADs, I'm clearing my discuss that this should be informational. I would have also expected some discussion about the risks to the user if the browser gets corrupted, as indicated by the trust model presented in draft-ietf-rtcweb-security-arch. Alternatively, this document could go in the appendix of draft-ietf-rtcweb-security-arch instead.
Alexey Melnikov No Objection
Thank you for this document. It made me more scared of using WebRTC, but I think it is Ok :-). The document seem to sometimes state problems without suggesting any solutions, but I don't have specific suggestions how to improve it. It does read a bit Informational at times, but it also contains some RFC 2119 language, so I think PS designation is Ok.
Alvaro Retana No Objection
Martin Vigoureux No Objection
(Eric Rescorla) Recuse
I am an author