Re: [rtcweb] Mirja Kühlewind's Discuss on draft-ietf-rtcweb-security-11: (with DISCUSS and COMMENT)

"Mirja Kuehlewind (IETF)" <> Tue, 05 March 2019 09:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E442131022; Tue, 5 Mar 2019 01:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gX38n5vEDNYC; Tue, 5 Mar 2019 01:54:08 -0800 (PST)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AACC8131026; Tue, 5 Mar 2019 01:54:07 -0800 (PST)
Received: from ([] helo=[]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1h16lw-0004TD-Nd; Tue, 05 Mar 2019 10:54:04 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <>
In-Reply-To: <>
Date: Tue, 05 Mar 2019 10:52:01 +0100
Cc:,, RTCWeb IETF <>, The IESG <>, Sean Turner <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Eric Rescorla <>
X-Mailer: Apple Mail (2.3445.9.1)
X-HE-SMSGID: 1h16lw-0004TD-Nd
Archived-At: <>
Subject: Re: [rtcweb] Mirja Kühlewind's Discuss on draft-ietf-rtcweb-security-11: (with DISCUSS and 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: Tue, 05 Mar 2019 09:54:12 -0000

Hi Ekr,

see below.

> Am 28.02.2019 um 22:22 schrieb Eric Rescorla <>:
> On Thu, Feb 28, 2019 at 10:00 AM Mirja Kühlewind <> wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-rtcweb-security-11: Discuss
> 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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I think this document is clearly informational. Other RTCweb documents should
> refer this document informatively and only reference the sec arch doc
> normatively.
> I don't feel strongly one way or the other. I will defer to the AD.

I will wait for more feedback from other ADs and then clear my discuss respectively. However, to be honest I also don’t quite fully understand the split between this doc and the sec-arch one. But maybe that just me...
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I would have also expected some discussion about the risks to the user if the
> browser gets corrupted, as indicated by the trust model presented in
> draft-ietf-rtcweb-security-arch. Alternatively, this document could go in the
> appendix of draft-ietf-rtcweb-security-arch instead.
> Hmm... We generally assume that the browser is uncorrupted. If it is, it's pretty much game over. Can you explain more about your position. 

My thinking here is that the security consideration should usually mention potentially attacks. First the whole document assumes that the browser is not corrupted but never says that. So it would help if this document would also mention the trust model as explicitly described in the sec-arch doc or refer to it. But then I also thought that it could be good to say more about what „game over“ means. Which information could or would be lost in danger. I understand that if an attacker has full control over the blower it can basically display anything, however, I was wondering if it would be possible to say more than that. Maybe there are part that can be easier hack than others… anyway was just a thought.