Security Considerations for WebRTC
draft-ietf-rtcweb-security-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-01-18
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-06-29
|
12 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-03-16
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2019-11-06
|
12 | (System) | RFC Editor state changed to REF from EDIT |
2019-08-15
|
12 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-08-12
|
12 | (System) | RFC Editor state changed to MISSREF from EDIT |
2019-07-15
|
12 | (System) | RFC Editor state changed to EDIT |
2019-07-15
|
12 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-07-15
|
12 | (System) | Announcement was received by RFC Editor |
2019-07-12
|
12 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2019-07-12
|
12 | (System) | IANA Action state changed to In Progress |
2019-07-12
|
12 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-07-12
|
12 | Cindy Morgan | IESG has approved the document |
2019-07-12
|
12 | Cindy Morgan | Closed "Approve" ballot |
2019-07-12
|
12 | Cindy Morgan | Ballot approval text was generated |
2019-07-12
|
12 | Adam Roach | This document is ready for RFC Editor processing. |
2019-07-12
|
12 | Adam Roach | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2019-07-05
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-07-05
|
12 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-12.txt |
2019-07-05
|
12 | (System) | New version approved |
2019-07-05
|
12 | (System) | Request for posting confirmation emailed to previous authors: Eric Rescorla |
2019-07-05
|
12 | Eric Rescorla | Uploaded new revision |
2019-04-30
|
11 | Nancy Cam-Winget | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Nancy Cam-Winget. Sent review to list. |
2019-03-07
|
11 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2019-03-07
|
11 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2019-03-07
|
11 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-03-07
|
11 | Mirja Kühlewind | [Ballot comment] Based on feedback provided by other ADs, I'm clearing my discuss that this should be informational. I would have also expected some discussion … [Ballot comment] 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. |
2019-03-07
|
11 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss |
2019-03-06
|
11 | Benjamin Kaduk | [Ballot comment] ====== Previous DISCUSS section ======= I'd like to have a brief discussion about a few points, though it's not clear that any change … [Ballot comment] ====== Previous DISCUSS section ======= I'd like to have a brief discussion about a few points, though it's not clear that any change to the document will be required (details in the COMMENT section for all of these): Mutually-verifiable "secure mode" seems to require that the peer's browser be included in the TCB, which is a bit hard to swallow. Are we comfortable wrapping that in alongside "we trust the peer to not be malicious"? It's not clear how much benefit we can get from *optional* third-party identity providers; won't the calling service have the ability to silently downgrade to their non-usage even if both calling peers support it? ============= COMMENT section ============= I mostly only have editorial comments, though there are a few that are more content-ful. Section 1 As with any Web application, the Web server can move logic between the server and JavaScript in the browser, but regardless of where the code is executing, it is ultimately under control of the server. The user can observe the javascript running the browser, though maybe this distinction is not necessary here. Section 3 Huang et al. [huang-w2sp] summarize the core browser security guarantee as: Users can safely visit arbitrary web sites and execute scripts provided by those sites. I note that the author of this document is listed as a coauthor on huang-w2sp; does the self-cite really add much authority to the summary of the guarantee? The use of ALL-CAPS to call out new terms feels a bit dated. Note that for non-HTTPS traffic, a network attacker is also a Web attacker, since it can inject traffic as if it were any non-HTTPS Web site. Thus, when analyzing HTTP connections, we must assume that traffic is going to the attacker. nit: I know this is a web-centric document, but the privileging of https as the only "secure" traffic reads a bit oddly to me; something like "note that in some cases, a network attacker is also a web attacker, since transport protocols that do not provide integrity protection allow the network to inject traffic as if they were any communications peer. TLS, and HTTPS in particular, prevent against these attacks, but when analyzing HTTP connections, we must assume that traffic is going to the attacker." (A thought experiment might be to consider whether wss:// traffic counts as "HTTPS traffic".) Section 3.1 It might be appropriate to provide some example references in place of "extensive research". Section 4.1 In either case, all the browser is able to do is verify and check authorization for whoever is controlling where the media goes. [...] nit: the wording here is a bit odd, since in case (1) you're verifying you're talking to A, but you still control where the media goes (in terms of A or not-A; A can of course then forward on the media further). 00000000000000000000000000000000000000000000000000000000000000000000By contrast, consent to send network traffic is about preventing the user's browser from being used to attack its local network. [...] nit: "local" is perhaps overly restricting, depending on interpretation Section 4.1.1 Maybe note that the "result" of the cross-site requests that is leaked is in the form of pixels and not structured data, but that does not change the information content. Section 4.1.3 Now that we have seen another use case, we can start to reason about nit: I'm confused by "another" here. While not suitable for all cases, this approach may be useful for some. If we consider the case of advertising, it's not particularly convenient to require the advertiser to instantiate an iframe on the hosting site just to get permission; a more convenient approach is to cryptographically tie the advertiser's certificate to the communication directly. We're This seems to be relying on the reader to have some background knowledge and make some leaps of reasoning that may not be reasonable to expect. Another case where media-level cryptographic identity makes sense is when a user really does not trust the calling site. For instance, I might be worried that the calling service will attempt to bug my computer, but I also want to be able to conveniently call my friends. This is especially challenging because if the site (and/or its javascript) is in the path for binding a cryptographic identity to a real-world identity, then a malicious site can still get whatever keys it wants authorized. Section 4.1.4 3. The attacker forges the response apparently http://calling- service.example.com/ to inject JS to initiate a call to himself. seem to be missing a word or two here. which contain untrusted content. If a page from a given origin ever loads JavaScript from an attacker, then it is possible for that attacker to infect the browser's notion of that origin semi- permanently. nit: "If any page" is more emphatic, I think. Section 4.2 Do we want any discussion of the risks when metered bandwidth (pay per byte) is in use? Section 4.2.1 There's probably some room to tighten up the verbiage here; e.g., "the site initiating ICE" is referring to a website that is using a browser API to request ICE against some remote peer (right?). And "ICE keepalives are indications" is using Indication as the technical term for a message that doesn't get an ACK response, not in its common English usage. Section 4.2.2 A one- or two-sentence summary of the impact of misinterpretation attacks is probably in order, instead of making us follow the reference (which isn't a section reference). Where TCP is used the risk is substantial due to the potential presence of transparent proxies and therefore if TCP is to be used, then WebSockets style masking MUST be employed. nit: "employed" to obfuscate what, exactly? Section 4.2.3 refuses to send other traffic until that message has been replied to. The message/reply pair must be generated in such a way that an attacker who controls the Web application cannot forge them, generally by having the message contain some secret value that must be incorporated (e.g., echoed, hashed into, etc.). Non-ICE nit: "incorporated" into what? I think I'm a little confused about which legacy actors we're talking about. Are we still considering the broader situation a webserver-mediated interaction between two browsers or brower-adjacent applications? (E.g., a WebRTC client calling some other sort of video chat system?) leaves. The appropriate technologies here are fairly similar to those for initial consent, though are perhaps weaker since the threats is less severe. nit: "threat is" Section 4.2.4 Note that as soon as the callee sends their ICE candidates, the caller learns the callee's IP addresses. The callee's server reflexive address reveals a lot of information about the callee's location. In order to avoid tracking, implementations may wish to suppress the start of ICE negotiation until the callee has answered. Is "answered" supposed to be some interaction with the controlling site? In ordinary operation, the site learns the browser's IP address, though it may be hidden via mechanisms like Tor [http://www.torproject.org] or a VPN. However, because sites can cause the browser to provide IP addresses, this provides a mechanism for sites to learn about the user's network environment even if the user is behind a VPN that masks their IP address. [...] Some rewording for clarity is probably in order; "ordinary operation" is of a website without WebRTC; "sites can cause the browser to provide IP addresses" is when the site uses the browser API to request ICE initiation; etc. Section 4.3.1 [Obligatory note about "Forward Secrecy" vs. "Perfect Forward Secrecy"] to subsequent compromise. It is this consideration that makes an automatic, public key-based key exchange mechanism imperative for WebRTC (this is a good idea for any communications security system) and this mechanism SHOULD provide perfect forward secrecy (PFS). The signaling channel/calling service can be used to authenticate this mechanism. To be clear, the authentication that the calling service provides is a binding between identity and the public keys that are input to the key exchange mechanism? Section 4.3.2.1 Even if the user actually checks the other side's name (which all available evidence indicates is unlikely), this would require (a) the browser to trusted UI to provide the name and (b) the user to not be fooled by similar appearing names. nit: "browser to use trusted UI" Section 4.3.2.3 It's not clear that third-party identity providers actually provide downgrade-resistance -- can't the site mediating the calls just decline to acknowledge that a third-party identity is/was available for the peer? Section 4.3.2.4 I.e., I must be able to verify that the person I am calling has engaged a secure media mode (see Section 4.3.3). In order to achieve this it will be necessary to cryptographically bind an indication of the local media access policy into the cryptographic authentication procedures detailed in the previous sections. This seems to require extending the TCB from just the local browser to the remote browser as well, which is ... a stretch. (Also, do we really need the first person?) Section 9.2 The coordinates for [OpenID] don't seem quite right. |
2019-03-06
|
11 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-03-06
|
11 | Benjamin Kaduk | [Ballot discuss] I'd like to have a brief discussion about a few points, though it's not clear that any change to the document will be … [Ballot discuss] I'd like to have a brief discussion about a few points, though it's not clear that any change to the document will be required (details in the COMMENT section for all of these): Mutually-verifiable "secure mode" seems to require that the peer's browser be included in the TCB, which is a bit hard to swallow. Are we comfortable wrapping that in alongside "we trust the peer to not be malicious"? It's not clear how much benefit we can get from *optional* third-party identity providers; won't the calling service have the ability to silently downgrade to their non-usage even if both calling peers support it? |
2019-03-06
|
11 | Benjamin Kaduk | [Ballot comment] I mostly only have editorial comments, though there are a few that are more content-ful. Section 1 … [Ballot comment] I mostly only have editorial comments, though there are a few that are more content-ful. Section 1 As with any Web application, the Web server can move logic between the server and JavaScript in the browser, but regardless of where the code is executing, it is ultimately under control of the server. The user can observe the javascript running the browser, though maybe this distinction is not necessary here. Section 3 Huang et al. [huang-w2sp] summarize the core browser security guarantee as: Users can safely visit arbitrary web sites and execute scripts provided by those sites. I note that the author of this document is listed as a coauthor on huang-w2sp; does the self-cite really add much authority to the summary of the guarantee? The use of ALL-CAPS to call out new terms feels a bit dated. Note that for non-HTTPS traffic, a network attacker is also a Web attacker, since it can inject traffic as if it were any non-HTTPS Web site. Thus, when analyzing HTTP connections, we must assume that traffic is going to the attacker. nit: I know this is a web-centric document, but the privileging of https as the only "secure" traffic reads a bit oddly to me; something like "note that in some cases, a network attacker is also a web attacker, since transport protocols that do not provide integrity protection allow the network to inject traffic as if they were any communications peer. TLS, and HTTPS in particular, prevent against these attacks, but when analyzing HTTP connections, we must assume that traffic is going to the attacker." (A thought experiment might be to consider whether wss:// traffic counts as "HTTPS traffic".) Section 3.1 It might be appropriate to provide some example references in place of "extensive research". Section 4.1 In either case, all the browser is able to do is verify and check authorization for whoever is controlling where the media goes. [...] nit: the wording here is a bit odd, since in case (1) you're verifying you're talking to A, but you still control where the media goes (in terms of A or not-A; A can of course then forward on the media further). 00000000000000000000000000000000000000000000000000000000000000000000By contrast, consent to send network traffic is about preventing the user's browser from being used to attack its local network. [...] nit: "local" is perhaps overly restricting, depending on interpretation Section 4.1.1 Maybe note that the "result" of the cross-site requests that is leaked is in the form of pixels and not structured data, but that does not change the information content. Section 4.1.3 Now that we have seen another use case, we can start to reason about nit: I'm confused by "another" here. While not suitable for all cases, this approach may be useful for some. If we consider the case of advertising, it's not particularly convenient to require the advertiser to instantiate an iframe on the hosting site just to get permission; a more convenient approach is to cryptographically tie the advertiser's certificate to the communication directly. We're This seems to be relying on the reader to have some background knowledge and make some leaps of reasoning that may not be reasonable to expect. Another case where media-level cryptographic identity makes sense is when a user really does not trust the calling site. For instance, I might be worried that the calling service will attempt to bug my computer, but I also want to be able to conveniently call my friends. This is especially challenging because if the site (and/or its javascript) is in the path for binding a cryptographic identity to a real-world identity, then a malicious site can still get whatever keys it wants authorized. Section 4.1.4 3. The attacker forges the response apparently http://calling- service.example.com/ to inject JS to initiate a call to himself. seem to be missing a word or two here. which contain untrusted content. If a page from a given origin ever loads JavaScript from an attacker, then it is possible for that attacker to infect the browser's notion of that origin semi- permanently. nit: "If any page" is more emphatic, I think. Section 4.2 Do we want any discussion of the risks when metered bandwidth (pay per byte) is in use? Section 4.2.1 There's probably some room to tighten up the verbiage here; e.g., "the site initiating ICE" is referring to a website that is using a browser API to request ICE against some remote peer (right?). And "ICE keepalives are indications" is using Indication as the technical term for a message that doesn't get an ACK response, not in its common English usage. Section 4.2.2 A one- or two-sentence summary of the impact of misinterpretation attacks is probably in order, instead of making us follow the reference (which isn't a section reference). Where TCP is used the risk is substantial due to the potential presence of transparent proxies and therefore if TCP is to be used, then WebSockets style masking MUST be employed. nit: "employed" to obfuscate what, exactly? Section 4.2.3 refuses to send other traffic until that message has been replied to. The message/reply pair must be generated in such a way that an attacker who controls the Web application cannot forge them, generally by having the message contain some secret value that must be incorporated (e.g., echoed, hashed into, etc.). Non-ICE nit: "incorporated" into what? I think I'm a little confused about which legacy actors we're talking about. Are we still considering the broader situation a webserver-mediated interaction between two browsers or brower-adjacent applications? (E.g., a WebRTC client calling some other sort of video chat system?) leaves. The appropriate technologies here are fairly similar to those for initial consent, though are perhaps weaker since the threats is less severe. nit: "threat is" Section 4.2.4 Note that as soon as the callee sends their ICE candidates, the caller learns the callee's IP addresses. The callee's server reflexive address reveals a lot of information about the callee's location. In order to avoid tracking, implementations may wish to suppress the start of ICE negotiation until the callee has answered. Is "answered" supposed to be some interaction with the controlling site? In ordinary operation, the site learns the browser's IP address, though it may be hidden via mechanisms like Tor [http://www.torproject.org] or a VPN. However, because sites can cause the browser to provide IP addresses, this provides a mechanism for sites to learn about the user's network environment even if the user is behind a VPN that masks their IP address. [...] Some rewording for clarity is probably in order; "ordinary operation" is of a website without WebRTC; "sites can cause the browser to provide IP addresses" is when the site uses the browser API to request ICE initiation; etc. Section 4.3.1 [Obligatory note about "Forward Secrecy" vs. "Perfect Forward Secrecy"] to subsequent compromise. It is this consideration that makes an automatic, public key-based key exchange mechanism imperative for WebRTC (this is a good idea for any communications security system) and this mechanism SHOULD provide perfect forward secrecy (PFS). The signaling channel/calling service can be used to authenticate this mechanism. To be clear, the authentication that the calling service provides is a binding between identity and the public keys that are input to the key exchange mechanism? Section 4.3.2.1 Even if the user actually checks the other side's name (which all available evidence indicates is unlikely), this would require (a) the browser to trusted UI to provide the name and (b) the user to not be fooled by similar appearing names. nit: "browser to use trusted UI" Section 4.3.2.3 It's not clear that third-party identity providers actually provide downgrade-resistance -- can't the site mediating the calls just decline to acknowledge that a third-party identity is/was available for the peer? Section 4.3.2.4 I.e., I must be able to verify that the person I am calling has engaged a secure media mode (see Section 4.3.3). In order to achieve this it will be necessary to cryptographically bind an indication of the local media access policy into the cryptographic authentication procedures detailed in the previous sections. This seems to require extending the TCB from just the local browser to the remote browser as well, which is ... a stretch. (Also, do we really need the first person?) Section 9.2 The coordinates for [OpenID] don't seem quite right. |
2019-03-06
|
11 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-03-06
|
11 | Eric Rescorla | [Ballot comment] I am an author |
2019-03-06
|
11 | Eric Rescorla | [Ballot Position Update] New position, Recuse, has been recorded for Eric Rescorla |
2019-03-06
|
11 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-03-05
|
11 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-03-05
|
11 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-03-05
|
11 | Deborah Brungard | [Ballot comment] I support PS. As the shepherd writeup says, this document will be the reference point for other work. To me, that says it … [Ballot comment] 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". |
2019-03-05
|
11 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-03-05
|
11 | Warren Kumari | [Ballot comment] I do not have strong views on the track, but if pressed, I lean towards PS. |
2019-03-05
|
11 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-03-04
|
11 | Ben Campbell | [Ballot comment] I disagree that this should be informative. It does have sections that have informational content, but it also has sections that serve as … [Ballot comment] 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. |
2019-03-04
|
11 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2019-03-04
|
11 | Alissa Cooper | [Ballot comment] PS seems like the appropriate status for this document given its role in the WebRTC document suite. = Section 4.1.4 = "The attacker … [Ballot comment] 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. |
2019-03-04
|
11 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2019-03-03
|
11 | Alexey Melnikov | [Ballot comment] Thank you for this document. It made me more scared of using WebRTC, but I think it is Ok :-). The document seem … [Ballot comment] 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. |
2019-03-03
|
11 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-02-28
|
11 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2019-02-28
|
11 | Mirja Kühlewind | [Ballot comment] I would have also expected some discussion about the risks to the user if the browser gets corrupted, as indicated by the trust … [Ballot comment] 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. |
2019-02-28
|
11 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2019-02-28
|
11 | Mirja Kühlewind | [Ballot comment] I would have also expected some discussion about the risks to the user if the browser gets corrupted, as indicated by the trust … [Ballot comment] 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. |
2019-02-28
|
11 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2019-02-28
|
11 | Mirja Kühlewind | [Ballot discuss] I think this document is clearly informational. Other RTCweb documents should refer this document informatively and only reference the sec arch doc normatively. |
2019-02-28
|
11 | Mirja Kühlewind | [Ballot comment] I would have also expected some discussion about the risks to the user if the browser gets corrupted. |
2019-02-28
|
11 | Mirja Kühlewind | [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind |
2019-02-21
|
11 | Cindy Morgan | Placed on agenda for telechat - 2019-03-07 |
2019-02-21
|
11 | Adam Roach | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-02-21
|
11 | Adam Roach | Ballot has been issued |
2019-02-21
|
11 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2019-02-21
|
11 | Adam Roach | Created "Approve" ballot |
2019-02-21
|
11 | Adam Roach | Ballot writeup was changed |
2019-02-21
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Nancy Cam-Winget |
2019-02-21
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Nancy Cam-Winget |
2019-02-20
|
11 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Carl Wallace was rejected |
2019-02-15
|
11 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-02-14
|
11 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2019-02-14
|
11 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-rtcweb-security-11, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-rtcweb-security-11, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-02-12
|
11 | Joe Clarke | Request for Last Call review by OPSDIR Completed: Not Ready. Reviewer: Joe Clarke. Sent review to list. |
2019-02-07
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2019-02-07
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2019-02-07
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2019-02-07
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2019-02-05
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2019-02-05
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2019-02-01
|
11 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-02-01
|
11 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-02-15): From: The IESG To: IETF-Announce CC: adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , draft-ietf-rtcweb-security@ietf.org, … The following Last Call announcement was sent out (ends 2019-02-15): From: The IESG To: IETF-Announce CC: adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , draft-ietf-rtcweb-security@ietf.org, rtcweb@ietf.org, sean@sn3rd.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Security Considerations for WebRTC) to Proposed Standard The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'Security Considerations for WebRTC' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers - "real time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-02-01
|
11 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-02-01
|
11 | Cindy Morgan | Last call announcement was generated |
2019-02-01
|
11 | Adam Roach | Last call was requested |
2019-02-01
|
11 | Adam Roach | Ballot approval text was generated |
2019-02-01
|
11 | Adam Roach | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-02-01
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-02-01
|
11 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-11.txt |
2019-02-01
|
11 | (System) | New version approved |
2019-02-01
|
11 | (System) | Request for posting confirmation emailed to previous authors: Eric Rescorla |
2019-02-01
|
11 | Eric Rescorla | Uploaded new revision |
2018-11-01
|
10 | Adam Roach | See AD review at https://mailarchive.ietf.org/arch/msg/rtcweb/mjWIiMBWKFwTYMMDXF5wE4TPKas |
2018-11-01
|
10 | Adam Roach | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-10-30
|
10 | Adam Roach | IESG state changed to AD Evaluation from Publication Requested |
2018-09-10
|
10 | Adam Roach | Changed wrong document with previous change -- reverting. |
2018-09-10
|
10 | Adam Roach | IESG state changed to Publication Requested from Publication Requested::Revised I-D Needed |
2018-09-10
|
10 | Adam Roach | Waiting on merge of https://github.com/rtcweb-wg/security-arch/pull/77 and subsequent submission. |
2018-09-10
|
10 | Adam Roach | IESG state changed to Publication Requested::Revised I-D Needed from Publication Requested |
2018-05-16
|
10 | Adam Roach | Changed consensus to Yes from Unknown |
2018-01-22
|
10 | Sean Turner | https://media.giphy.com/media/ltbKep9Ce8dBS/giphy.gif |
2018-01-22
|
10 | Adam Roach | This document will be progressed at the same time as draft-ietf-rtcweb-security-arch and draft-rtcweb-ip-handling, so it may spend more time in AD Review than is typical. |
2018-01-22
|
10 | Adam Roach | Shepherding AD changed to Adam Roach |
2018-01-22
|
10 | Sean Turner | 1. Summary This document describes the security considerations for WebRTC. This draft is bound standards track because it includes all of the WebRTC security considerations … 1. Summary This document describes the security considerations for WebRTC. This draft is bound standards track because it includes all of the WebRTC security considerations and will referred to from all WebRTC WG drafts. Sean Turner is the document shepherd and Adam Roach is going to be our über Area Director! 2. Review and Consensus This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings. It’s been amended numerous times based on WG feedback and it reflects the WG consensus. 3. Intellectual Property The shepherd has confirmed the author's direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points DOWNREFs: None IANA Considerations: None. |
2018-01-22
|
10 | Sean Turner | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-01-22
|
10 | Sean Turner | IESG state changed to Publication Requested from AD is watching |
2018-01-22
|
10 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-10.txt |
2018-01-22
|
10 | (System) | New version approved |
2018-01-22
|
10 | (System) | Request for posting confirmation emailed to previous authors: Eric Rescorla |
2018-01-22
|
10 | Eric Rescorla | Uploaded new revision |
2018-01-04
|
09 | Sean Turner | 1. Summary This document describes the security considerations for WebRTC. This draft is bound standards track because it includes all of the WebRTC security considerations … 1. Summary This document describes the security considerations for WebRTC. This draft is bound standards track because it includes all of the WebRTC security considerations and will referred to from all WebRTC WG drafts. Sean Turner is the document shepherd and Adam Roach is going to be our über Area Director! 2. Review and Consensus This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings. It’s been amended numerous times based on WG feedback and it reflects the WG consensus. 3. Intellectual Property The shepherd has confirmed the author's direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points DOWNREFs: None IANA Considerations: None. |
2017-12-07
|
09 | Sean Turner | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-11-21
|
09 | Sean Turner | Notification list changed to Sean Turner <sean@sn3rd.com> |
2017-11-21
|
09 | Sean Turner | Document shepherd changed to Sean Turner |
2017-11-15
|
09 | Sean Turner | Tag Doc Shepherd Follow-up Underway cleared. |
2017-11-15
|
09 | Sean Turner | IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead |
2017-11-12
|
09 | Adam Roach | IESG state changed to AD is watching from Dead |
2017-10-29
|
09 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-09.txt |
2017-10-29
|
09 | (System) | New version approved |
2017-10-29
|
09 | (System) | Request for posting confirmation emailed to previous authors: Eric Rescorla |
2017-10-29
|
09 | Eric Rescorla | Uploaded new revision |
2017-10-19
|
08 | Tero Kivinen | Closed request for Early review by SECDIR with state 'Overtaken by Events' |
2016-04-08
|
08 | (System) | Document has expired |
2016-04-08
|
08 | (System) | IESG state changed to Dead from AD is watching::External Party |
2016-04-07
|
08 | Alissa Cooper | IESG state changed to AD is watching::External Party from Publication Requested |
2015-10-14
|
08 | (System) | Notify list changed from rtcweb-chairs@ietf.org, draft-ietf-rtcweb-security@ietf.org, draft-ietf-rtcweb-security.shepherd@ietf.org, draft-ietf-rtcweb-security.ad@ietf.org, turners@ieca.com to (None) |
2015-07-02
|
08 | Tero Kivinen | Request for Early review by SECDIR is assigned to Daniel Gillmor |
2015-07-02
|
08 | Tero Kivinen | Request for Early review by SECDIR is assigned to Daniel Gillmor |
2015-04-15
|
08 | Alissa Cooper | IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Consensus: Waiting for Write-Up |
2015-04-15
|
08 | Alissa Cooper | IETF WG state changed to WG Consensus: Waiting for Write-Up from Submitted to IESG for Publication |
2015-03-25
|
08 | Cindy Morgan | Shepherding AD changed to Alissa Cooper |
2015-03-20
|
08 | Richard Barnes | Last call announcement was generated |
2015-03-20
|
08 | Richard Barnes | Last call announcement was generated |
2015-03-20
|
08 | Richard Barnes | Ballot writeup was generated |
2015-03-19
|
08 | Sean Turner | 1. Summary This document describes the security considerations for WebRTC. This draft is bound standards track because it includes all of the WebRTC security considerations … 1. Summary This document describes the security considerations for WebRTC. This draft is bound standards track because it includes all of the WebRTC security considerations and will referred to from all WebRTC WG drafts. Sean Turner is the document shepherd and Alissa Cooper is going to be our über Area Director! 2. Review and Consensus This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings. It’s been amended numerous times based on WG feedback and it reflects the WG consensus. 3. Intellectual Property The shepherd has confirmed the author's direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points DOWNREFs: None IANA Considerations: None. |
2015-03-19
|
08 | Sean Turner | State Change Notice email list changed to rtcweb-chairs@ietf.org, draft-ietf-rtcweb-security@ietf.org, draft-ietf-rtcweb-security.shepherd@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-security.ad@ietf.org, turners@ieca.com |
2015-03-19
|
08 | Sean Turner | Responsible AD changed to Richard Barnes |
2015-03-19
|
08 | Sean Turner | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2015-03-19
|
08 | Sean Turner | IESG state changed to Publication Requested |
2015-03-19
|
08 | Sean Turner | IESG process started in state Publication Requested |
2015-03-19
|
08 | Sean Turner | Intended Status changed to Proposed Standard from None |
2015-03-19
|
08 | Sean Turner | Changed document writeup |
2015-02-26
|
08 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-08.txt |
2014-08-14
|
07 | Sean Turner | Tag Doc Shepherd Follow-up Underway set. |
2014-08-14
|
07 | Sean Turner | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2014-07-10
|
07 | Sean Turner | IETF WG state changed to In WG Last Call from WG Document |
2014-07-04
|
07 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-07.txt |
2014-07-02
|
06 | Sean Turner | Document shepherd changed to Sean Turner |
2014-01-21
|
06 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-06.txt |
2014-01-10
|
05 | Magnus Westerlund | Document shepherd changed to Ted Hardie |
2013-07-15
|
05 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-05.txt |
2013-01-22
|
04 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-04.txt |
2012-06-05
|
03 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-03.txt |
2012-03-12
|
02 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-02.txt |
2011-10-30
|
01 | (System) | New version available: draft-ietf-rtcweb-security-01.txt |
2011-09-22
|
00 | (System) | New version available: draft-ietf-rtcweb-security-00.txt |