Draft: draft-ietf-rtcweb-jsep

Commentary: From " Opsdir last call review of draft - ietf - rtcweb - jsep-21 " A minor observation , not even a nit , is that the text in the Security Considerations " While formally the JSEP interface is an API , it is better to think of it is an Internet protocol , with the JS being untrustworthy from the perspective of the endpoint . " could be more clear . 
 I have no idea what to do with this . Obviously I thought it was clear when wrote it , and still do . 
 This is the only place in the document where we use " JS " . I think it would be good to spell out " JavaScript " , and potentially use " application JavaScript " in the first usage . Finally , I think we should use " implementation " rather than " endpoint " in this para . 
 LGTM
Paragraph (version A):
While formally the JSEP interface is an API, it is better to think of
it is an Internet protocol, with the JS being untrustworthy from the
perspective of the endpoint.  Thus, the threat model of RFC3552
applies.  In particular, JS can call the API in any order and with
any inputs, including malicious ones.  This is particularly relevant
when we consider the SDP which is passed to setLocalDescription().
While correct API usage requires that the application pass in SDP
which was derived from createOffer() or createAnswer(), there is no
guarantee that applications do so.  The JSEP implementation MUST be
prepared for the JS to pass in bogus data instead.
Paragraph (version A):
Conversely, the application programmer needs to be aware that the JS
does not have complete control of endpoint behavior.  One case that
bears particular mention is that editing ICE candidates out of the
SDP or suppressing trickled candidates does not have the expected
behavior: implementations will still perform checks from those
candidates even if they are not sent to the other side.  Thus, for
instance, it is not possible to prevent the remote peer from learning
your public IP address by removing server reflexive candidates.
Applications which wish to conceal their public IP address should
instead configure the ICE agent to use only relay candidates.
Paragraph (version B):
While formally the JSEP interface is an API, it is better to think of
it is an Internet protocol, with the application JavaScript being
untrustworthy from the perspective of the JSEP implementation.  Thus,
the threat model of RFC3552 applies.  In particular, JavaScript can
call the API in any order and with any inputs, including malicious
ones.  This is particularly relevant when we consider the SDP which
is passed to setLocalDescription().  While correct API usage requires
that the application pass in SDP which was derived from createOffer()
or createAnswer(), there is no guarantee that applications do so.
The JSEP implementation MUST be prepared for the JavaScript to pass
in bogus data instead.
Paragraph (version B):
Conversely, the application programmer needs to be aware that the
JavaScript does not have complete control of endpoint behavior.  One
case that bears particular mention is that editing ICE candidates out
of the SDP or suppressing trickled candidates does not have the
expected behavior: implementations will still perform checks from
those candidates even if they are not sent to the other side.  Thus,
for instance, it is not possible to prevent the remote peer from
learning your public IP address by removing server reflexive
candidates.  Applications which wish to conceal their public IP
address should instead configure the ICE agent to use only relay
candidates.