[rtcweb] Comments on draft-ietf-rtcweb-security-06

[John Mattsson <[e-mail]>]

I have reviewed Security Considerations for WebRTC (draft-ietf-rtcweb-security-06)


Seems to be in good shape.


Cheers

John





-[General]

The draft should discuss threats when the users belong to different calling services. There are then two potentially malicious calling services as well as the transport between them.


-[General]

The draft should make clear how the threats, levels of consent, and chrome indications differ between data channels and media channels. Obviously consent and chrome indicators are needed for accessing mic and camera. Right now the draft mostly talks about consent and indicators for a "call" and says nothing about caller and callee consent and chrome indicators for pure data channels.


-[General]

A draft discussing threats to a user-to-user communication system should probably discuss unsolicited communication (i.e. SPIT, SPIM) a little bit, not just writing that "prank calls" is out of scope.




3.  The Browser Threat Model


-[s3] "NETWORK ATTACKERS, who are able to control your network"

Should be "the network" or "part of the network"



4.1.  Access to Local Devices


-[s4.1] "In either case, all the browser is able to do is verify and check authorization for whoever is controlling where the media goes."

Should mention that the browser may be able to authenticate the media destination.


-[s4.1] "By contrast, consent to send network traffic is about preventing the user's browser from being used to attack its local network."

   It's also about DoS (which is mentioned in the beginning) and protecting other networks that may have firewalls blocking traffic from Dr. Evil but accepting traffic from you.


-[s4.1.2.1, 4.1.2.2]

4.1.2.1 "If I grant permission to calling service A to make calls on my behalf, then I am implicitly granting it permission to bug my computer whenever it wants."


4.1.2.2 "Note also that the user interface chrome must clearly display elements showing that the call is continuing in order to avoid attacks where the calling site just leaves it up indefinitely but shows a Web UI that implies otherwise."


The text on chrome indications is also highly relevant for 4.1.2.1, Even if the user have granted long term consent, the browser should still show when a site accesses mic and camera.



4.2.  Communications Consent Verification


-[s4.2.2] "UDP over DTLS"

Is this used anywhere or just a theoretical example?



4.3.  Communications Security


-[s4.3] "secure against both message recovery and message modification."

Add replay


-[s4.3] "the peer's identity information, which, after all, is only meaningful in the context of some calling service."

Not if authenticated via IdP or PKI.


-[s4.3, 4.3.1, and 4.3.2]

I think the division in "uncompromised during call, later compromised" and "active" is a bad idea. I would strongly recommend restructuring section 4.3, 4.3.1, and 4.3.2 to follow the definitions of "passive attacks" and "active attacks" in RFC 3552. The text could then also:

        - Differentiate between attacks on the signaling plane and the user plane, and clarify where PFS is needed.

        - Differentiate active attacks on the key management vs. active attacks by sending traffic to a recording service.

        - Also consider passive and active attacks from other than the calling service.

        - Make it clear that (in most cases) you need access to both control and user plane data.


-[s4.3] "The calling service is compromised during the call it wishes to attack (often called an "active attack")."

While "active attack" implies "compromised during call" the opposite is not true as a during-call attack can very well be passive.


-[s4.3] "The calling service is non-malicious during a call but subsequently is compromised and wishes to attack an older call (often called a "passive attack")"

Similarly as the above comment "passive attack" does not equate the calling service being non-malicious during the call.


-[s4.3] "We discuss some potential approaches and why they are likely to be impractical in Section 4.3.2."

Section 4.3.2 does not discuss "why they are likely to be impractical"


-[s4.3]

Fails to clearly describe that the attacker needs access to the media channel and describe how the attacker gets that. If the calling service is compromised it can just include itself it the media path, but otherwise the attacker must intercept the media path.


-[s4.3] "However, it is extremely difficult"

Well theoretically it's simple (authenticate), maybe explain that the difficult part is deployment in the WebRTC case.


-[s4.3.1]

Should mention that the retrospective attack requires that the calling service has either saved all the media (not that likely) or that the attacker has captured it beforehand.


-[s4.3.1] "in SDES [RFC4568]), then retrospective attack is trivial."

I would remove trivial. I agree that if you have 1. been able to capture the data by intercepting the communication between the  peers, 2. been able to compromise the calling service, and 3. been able to read the key from the logs, then decrypting is trivial, but 1,2,3 is not trivial.


-[s4.3.2]

Should mention that any fingerprint mechanism sent via the calling service (such as the one in DTLS-SRTP) does not help at all (when the call service is malicious).


-[s4.3.2.4]

In the secure media mode, the calling site should not only be forbidden to view and modify the media. It should also be forbidden to send audio to the speakers. Othervise it can still indirectly modify the media.



4.4.  Privacy Considerations


-[s4.4.1]

Should mention that there is a trade-off between resetting DTLS certs and key continuity.



Editorials:


-"WebTC"

-"Westerland" -> "Westerlund"

-"CNAMES" -> "CNAMEs"

-"implementated"

-"reflrect"

-"soft phones" or "softphones"

-"xref target="RFC6454"/>"

-First sentence in 4.2.2 is duplicated

-"Use or RTCP"

-"site not work well"



JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security

Ericsson AB
Security Research
Färögatan 6
SE-164 80 Stockholm, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]<mailto:[e-mail]>
www.ericsson.com<http://www.ericsson.com/>


[http://www.ericsson.com/]<http://www.ericsson.com/>

This Communication is Confidential. We only send and receive email on the basis of the terms set out atwww.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>