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

Russ Housley <housley@vigilsec.com> Sat, 09 February 2019 18:50 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E95C130DD6; Sat, 9 Feb 2019 10:50:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Russ Housley <housley@vigilsec.com>
To: <gen-art@ietf.org>
Cc: draft-ietf-rtcweb-security-arch.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154973824800.29421.10047365396889314189@ietfa.amsl.com>
Date: Sat, 09 Feb 2019 10:50:48 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/mrplJ5GzxvoYiHdhruOvGSprfHI>
Subject: [rtcweb] Genart last call review of draft-ietf-rtcweb-security-arch-18
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Feb 2019 18:50:48 -0000

Reviewer: Russ Housley
Review result: Almost Ready

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 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.


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.