Subject: [secdir] Secdir last call review of draft-ietf-rtcweb-jsep-23

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 06 Oct 2017 05:35:08 -0700

Reviewer: Phillip Hallam-Baker
Review result: Ready

Given the design constraints in which the protocol operates, it is hard to see
how this could be done differently.

I have two sets of security concerns. One is that implementations need to be
designed so as to avoid buffer overrun conditions and also to prevent such
conditions leading to a breach. Compression formats such as are inevitably used
in video and image applications tend to make promiscuous use of nested length
encoding formats that commonly lead to security vulnerabilities.

This document does not have such a warning, having a reference on most of the
security issues, a warning on this issue should appear in:
https://tools.ietf.org/html/draft-ietf-rtcweb-security-08

The other security concern is that giving control over the host browser to run
pretty much arbitrary code was always going to be a security disaster but there
isn't much that can be done at this point.

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 8 Oct 2017 04:22:11 +0200

> isn't much that can be done at this point.
Participant pushback, I'm neither a WG chair or a document editor:

Was this intended as a review of a different document?

The concern about compression formats seems to be something that belongs
in compression format specifications, such as those referenced by
PAYLOAD et al. As such, it would reasonably belong in -rtcweb-security,
which pulls in security concerns from a number of fields.

The generic concern about running Javascript in the browser seems to
belong to rtcweb-overview if it belongs anywhere except in a generic
architecture critique of the browser ecosystem.

If there are concerns specific to JSEP, and the handling of SDP that is
described in JSEP, it seems appropriate to document them here. Generic
architectural issues and common security best practices don't seem to
have the right home in this document.

-- 
Surveillance is pervasive. Go Dark.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Oct 2017 23:18:51 -0400

> Was this intended as a review of a different document?

​No, I just didn't have any comments on the security considerations in this
one as they are handled in rtcweb-security. and that is the place to
address the one addressable concern I did have.

> which pulls in security concerns from a number of fields.

​That is where I suggested it go.
​

> architecture critique of the browser ecosystem.

​I wasn't suggesting a change. Just pointing out that we are dealing with
the ​attack model in which the attacker has control of a turing complete
mechanism in the communication channel. Given that one of the authors is a
Security AD, just pointing out that is the set of vectors that would cause
me most concern.

-- 
Website: http://hallambaker.com/

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 08 Oct 2017 09:49:30 +0200

Ok, sounds like we're in agreement on what needs to be done to this document based on the review (nothing). Good.

Den 8. oktober 2017 05:18:51 CEST, skrev Phillip Hallam-Baker <[email-masked]>:
>> > Given the design constraints in which the protocol operates, it is
>hard
>> to see
>> > I have two sets of security concerns. One is that implementations
>need
>> to be
>> > designed so as to avoid buffer overrun conditions and also to
>prevent
>> such
>> > in video and image applications tend to make promiscuous use of
>nested
>> length
>> > This document does not have such a warning, having a reference on
>most
>> of the
>> > The other security concern is that giving control over the host
>browser
>> to run
>> > pretty much arbitrary code was always going to be a security
>disaster
>> but there

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.