[rtcweb] Opsdir last call review of draft-ietf-rtcweb-security-arch-18

[Tim Chown via Datatracker <[e-mail]>]

Reviewer: Tim Chown
Review result: Has Issues

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