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

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 5 Mar 2019 10:52:01 +0100

Hi Ekr,

see below.

> Am 28.02.2019 um 22:22 schrieb Eric Rescorla <[email-masked]>:
> 
> 
> 
> On Thu, Feb 28, 2019 at 10:00 AM Mirja Kühlewind <ietf@kuehlewind..net> 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 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...
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Mar 2019 06:30:55 -0800

On Tue, Mar 5, 2019 at 1:54 AM Mirja Kuehlewind (IETF) <[email-masked]>
wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> 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...
> >
> >
> >
> > 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.

This is an explciit part of the RFC 3552 threat model.
https://tools.ietf.org/rfcmarkup?doc=3552#section-3

   The Internet environment has a fairly well understood threat model.
   In general, we assume that the end-systems engaging in a protocol
   exchange have not themselves been compromised.  Protecting against an
   attack when one of the end-systems has been compromised is
   extraordinarily difficult.  It is, however, possible to design
   protocols which minimize the extent of the damage done under these
   circumstances.

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.

We would then have to change every document we write to say this, I should
think.

-Ekr

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 6 Mar 2019 13:34:06 -0600

On 3/5/19 3:52 AM, Mirja Kuehlewind (IETF) wrote:
>> ---------------------------------------------------------------------
>>

One additional point regarding the publication status of this document 
to consider is that it is intended to inform not just IETF efforts in 
this space, but W3C efforts as well. From that inter-SDO collaboration 
perspective, I believe having it clear the higher bar of Standards Track 
is an important signal regarding the level of consensus and review it 
has received.

/a