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

[Harald Alvestrand <[e-mail]>]

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 <[e-mail]>:
>On Sat, Oct 7, 2017 at 10:22 PM, Harald Alvestrand
><[e-mail]>
>wrote:
>
>> On 10/06/2017 02:35 PM, Phillip Hallam-Baker wrote:
>> > 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.
>> >
>> Participant pushback, I'm neither a WG chair or a document editor:
>>
>>
>> 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.
>
>
>
>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.
>>
>
>​That is where I suggested it go.
>​
>
>> 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.
>>
>
>​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.
>
>
>
>> 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.
>>
>>
>>
>
>
>-- 
>Website: http://hallambaker.com/

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