Hi,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

The draft describes the security architecture for WebRTC, a protocol used for real-time communications between web browsers.  It aims to address the threats and requirements described in draft-ietf-rtcweb-security, by the same author. 

The document is well-written, easy to read and free of typos. Overall, the document is close to being ready for publication, and the points as covered all seem appropriate, but I have some comments that the author should consider addressing.

Major comments:

Firstly, it is not clear that all the threats and requirements in draft-ietf-rtcweb-security have been addressed, as claimed in the Introduction to this document.   It would be useful to see the threats in the threats draft enumerated, and a section / appendix in this document saying where / how they are addressed or whether they remain open to be resolved.  Section 9 says "in order to avoid repetition", but I found it hard to deduce whether this draft met its claim of addressing all the threats.   As an example, there is discussion of fingerprinting in the threats document, but I don't recall seeing that  being covered in this document.

Secondly, it is not clear why communications to the call service can be over plain http.  What is this allowed?  Section 4.1 says communications to the calling service are "preferably over TLS"; why is this not a MUST be over TLS?  Likewise, 6.1 talks of http and https origins, and section 9.1 says "if https is not used to the signalling server".

Privacy is of course important, more so since RFC 7258. From the user's perspective, how do they judge setting the slider between security and privacy?   Section 4 says the document errs towards security rather than privacy, but how can user make an informed decision?  Section 9.2 says "Sites SHOULD make users aware of these tradeoffs", but how do you do that in a way a typical user can understand?

Section 9.2 talks about sites and that they SHOULD offer privacy-enhancing features by default, but perhaps you can go further and say that MUST make rolling DTLS keys be a configurable option. Similarly for the privacy-preserving CNAME generation mode.

It would seem natural to publish this draft and draft-ietf-rtcweb-security at the same time; I assume this is already planned.

Minor comments:

In the Introduction,  s/some Web server/a Web server providing the calling service/ ?

In section 3.1, 2nd bullet, isn't DTLS-SRTP a MUST later in the document (section 6.5), or are you not referring to keying here?  Are these two points consistent?

In Section 4, "relying party" is a term used before it is defined in 7.1.  Perhaps a definition of some terms would be useful in an early section in the document?

Best wishes,
Tim