Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT)

Sean Turner <> Wed, 27 March 2019 10:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79215120293 for <>; Wed, 27 Mar 2019 03:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hOk60HTdVA7N for <>; Wed, 27 Mar 2019 03:06:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDF6212028F for <>; Wed, 27 Mar 2019 03:06:24 -0700 (PDT)
Received: by with SMTP id d132so12049018ywa.2 for <>; Wed, 27 Mar 2019 03:06:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dU2Tgdc1QFbt6qbAyRW0KftqrqqnFXxeW+QehCOnd1Q=; b=ABpmYjTe59Gk7Nr0c9oWHftJxrcPHIui7farwU1fzc7bhklQFIKfVsgQOps6VPKHqy tQJxhtshGL9U/lBHyUKAwHivPJ6wrcnwdaPcxDVYSbdtJfr3cKrkcEf8TTPzltkL7LF0 dsVt9+7uGLUtFSWDPlXJEl1f1+pAcuCyQvliM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dU2Tgdc1QFbt6qbAyRW0KftqrqqnFXxeW+QehCOnd1Q=; b=jUsCXp5DncE0rCeJmlagGPgweKgrFVpkbxfsbaEiftDdV2/Flin7+lCBjDwj6dppPL ah4FD3UauguaJD1MzpGKrVA4XZ3EVMSOEXddtoyADAua+beuLncHiXCFyrCrD03ittE8 /ia1XD1CH+7LqfyYFVe/MP5jFl/cljKyD0wF4UuQUJ0fieF11j1rhEcO1WFuxkWx7Ofw wDcgQZvngQbSSKWFVZ9GMC9cx9fqtFV/Rq01jjUWpJwpCiraAwN/8BBBFMOS210QHYBA mL0cAsORM2YP/3L6T+qtwVDfn4ldRrOi7HPvODIKXiwQ2uKmmswh3QRKFm9JdAic034Y dNTg==
X-Gm-Message-State: APjAAAUmxYFe4e8a2cuaE1iYYskC5rDeHZioVaLRKbrfh9pratsQzN5i gnNBHLmNmRgUT4lt4lCfW5dlvg==
X-Google-Smtp-Source: APXvYqwFVsCsm2VkJlzwnQ/+1WnyNHbAf3u8JQS3XHti1RSlDwrfUIWNFF5F+lxyupaTOPhlCxanFQ==
X-Received: by 2002:a0d:db91:: with SMTP id d139mr30300404ywe.418.1553681184065; Wed, 27 Mar 2019 03:06:24 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:1468:25d2:df6d:be9d? ([2001:67c:370:128:1468:25d2:df6d:be9d]) by with ESMTPSA id 77sm7692805ywo.72.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 03:06:23 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Sean Turner <>
In-Reply-To: <>
Date: Wed, 27 Mar 2019 11:06:20 +0100
Cc: The IESG <>,,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Ben Campbell <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Mar 2019 10:06:28 -0000

> On Mar 5, 2019, at 13:45, Ben Campbell <> wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-rtcweb-security-arch-18: Yes
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Update: Ignore my comment about t= vs c=0. I had my order crossed; it is
> correct in the example.
> I'm balloting "yes", but have a few minor comments and editorial comments:
> §1:
> - (nit) The first sentence will not age well; I gather RTCWEB will close before
> long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the
> W3C?)

Fixed in the following PR:

> - (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned
> in the text. At least, please expand the abbreviation somwhere. (It also shows
> up in figure 4.)

Fixed in the above mentioned PR.

> (nit) §3.1, first bullet: While I don't normally object (beyond nose holding,
> anyway) to the use of first person in RFCs, it seems an odd choice for this
> sentence. I assume "we" in this sentence does not refer to the the author or
> the WG.

I am hoping the RFC editor can help here.  “we” is used a lot in this draft.

> §4.1:
> (nit) - '... button next to Bob’s name which says "Call".':
> s/which/that

fixed in the above PR

> - "The calling site will also provide some user interface
> element (e.g., a button) to allow Bob to answer the call, though this
> is most likely not part of the trusted UI."
> This is the first mention of "trusted UI". It would be helpful to elaborate on
> that prior to this mention.

Fair enough, but there is draft-ietf-rtcweb-security that you also had to read and there’s a lot of discussion there about browsers, sandboxing, etc.

> §5.1.4:
> - "In this
> case, the established identity SHOULD be applied to existing DTLS
> connections as well as new connections established using one of those
> fingerprints."
> Applied by the recipient? (consider active voice). Also, why not MUST? Don't
> unexpected things happen if the recipient doesn't do this?

will get back to you on this one. 

> §6.2:
> - "Because HTTP origins cannot be securely established against network
> attackers, implementations MUST NOT allow the setting of permanent
> access permissions for HTTP origins. Implementations MUST refuse all
> permissions grants for HTTP origins."
> (nit-ish) - The MUST NOT seems non-constraining considering the last sentence.
> Or am I reading that sentence wrong?

will get back to you on this one.

> (nit) - .E.g., "Call"' : sentence fragment.
> (nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural
> disagreement (assuming the browsers do not share 1 cert).

fixed in the above PR

> (maybe nit) - "Clients MAY permit the formation of data channels without any
> direct user approval." Is the switch from talking about "the browser" to
> "Clients" intentional?

fixed in the above PR

> §6.4:
> (nit) - "Note that these requirements are NOT intended..."
> "NOT" in all caps is likely to be confused with 2119/8174 language.

fixed in the above PR

> §6.5:
> (nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST
> implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP
> keying. Implementations MUST implement [RFC8261]."
> Thank you for using the citation style that doesn't assume everyone has
> memorized the RFC numbers. But why not do the same for 8261?

fixed in the above PR

> §7.2:
> (nit) - First paragraph: Can there be a citation for the W3C API spec?

There might be, but if you get 

> (My bad, the draft is correct. Comment removed.) §7.1.4, SDP example:
> (nit) §11: The first sentence is a fragment.

It is.

> §13.1 (normative references)
> (nit) - There's a reference to RFC 5234, but it is not cited in the text.

Yep meant to delete that now it’s gone see the earlier PR.

> - Is there a reason to reference 5246 rather than 8446, which obsoleted it?

1.2 is required so we’re pointing there.

> §13.2:
> - seems like the jsep reference should be normative.

Well the reference comes from “Note” sentence.  Since you’re really only doing this drfat And, you’re really only doing this draft because you’re doing the JSEP draft