Last Call Review of draft-ietf-rtcweb-security-arch-18
review-ietf-rtcweb-security-arch-18-genart-lc-housley-2019-02-09-00

Request Review of draft-ietf-rtcweb-security-arch
Requested rev. no specific revision (document currently at 19)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-02-15
Requested 2019-02-01
Draft last updated 2019-02-09
Completed reviews Secdir Early review of -11 by Tobias Gondrom (diff)
Opsdir Last Call review of -18 by Tim Chown (diff)
Genart Last Call review of -18 by Russ Housley (diff)
Assignment Reviewer Russ Housley
State Completed
Review review-ietf-rtcweb-security-arch-18-genart-lc-housley-2019-02-09
Reviewed rev. 18 (document currently at 19)
Review result Almost Ready
Review completed: 2019-02-09

Review
review-ietf-rtcweb-security-arch-18-genart-lc-housley-2019-02-09

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-rtcweb-security-arch-18
Reviewer: Russ Housley
Review Date: 2019-02-07
IETF LC End Date: 2019-02-15
IESG Telechat date: unknown

Summary: Almost Ready


Major Concerns:

Section 4.1 says "... preferably over TLS ...", but it does not tell
what the consequences are if TLS is not used.  Since this is the
security architecture, I would expect these consequences to be
described.

Section 4.2: Please add a sentence or two that defines Interactive
Connectivity Establishment (ICE) data and non-ICE data.

Section 6.5 includes a contradiction.  One place it says, " MUST NOT
negotiate cipher suites with NULL encryption", and another place it
says, "if Null ciphers are used ...".  Please make these consistent.

Section 6.5 requires implementation of certificate fingerprints or a
Short Authentication String (SAS).  Please add a sentence to tell how
they are used to provide out-of-band verification.  Without such a
sentence, it is easy to imagine an implementation with a UI that is
too awkward to actually get the information on the screen while the
call is in progress.

Section 10: since this is a standards track document, the IESG should
be responsible for this new codepoint, not the document author.


Minor Concerns:

Section 3.1 uses https://www.evil.org/ as an example.  However, this is
a registered domain.  It would be better to follow the IESG statement on
examples: https://www6.ietf.org/iesg/statement/examples.html.

Section 6.2 uses customerservice@ford.com  as an example.  Of course,
ford.com is a registered domain. It would be better to follow the IESG
statement on examples (the URL is above).

Section 7 uses Poker Galaxy  as an example.  Of course, this is a real
web site. It would be better to follow the IESG statement on examples
(the URL is above).  It seems best to use the same names here as are
used in Section 7.2.


Nits:

Section 1 includes: "... SDP-based like SIP."  Please add a reference
for SDP.

Section 4.1: s/ permissions till later/ permissions until later/

Section 4.4: please add a reference for STUN.

Section 6.2: s/(though see Section 6.3/(See Section 6.3/

Section 6.4: please do not enclose the note is '[' and ']'.  Avoid
confusion with reference syntax.  One solution is to put the note at
the end of the paragraph.

Section 6.4: s/non-turn candidates/non-TURN candidates/

Section 6.5: the phrase "Implementations MUST implement" seems awkward.
Perhaps "Implementations MUST support".  This appears several places.

Section 6.5 ought to begin with "All data channels MUST be secured via
DTLS."  This appears half way through the section, but the material that
comes before is really in support of this sentence.

Section 8.1 discusses "<user>@<domain>", but the discussion of "user"
(note the quotes) and the discussion of domain (note the absense of
quotes) are using different conventions.  Please use quotes in both
places or neither place.

There are places in this document where "settings" is confusing.  It is
unclear whether the word is referring to configuration settings or it
is referring to an environment or situation.  Please look at each use
of this word and consider alternatives.