Skip to main content

Last Call Review of draft-ietf-rtcweb-security-arch-18

Request Review of draft-ietf-rtcweb-security-arch
Requested revision No specific revision (document currently at 20)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-02-15
Requested 2019-02-01
Authors Eric Rescorla
I-D 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
Request Last Call review on draft-ietf-rtcweb-security-arch by General Area Review Team (Gen-ART) Assigned
Reviewed revision 18 (document currently at 20)
Result Almost ready
Completed 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

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

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 as an example.  However, this is
a registered domain.  It would be better to follow the IESG statement on

Section 6.2 uses  as an example.  Of course, 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.


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.