Subject: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-rtcweb-qos-16: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 18 May 2016 09:06:20 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-rtcweb-qos-16: No Objection

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-tsvwg-rtcweb-qos/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I was a little surprised that there's no additional security
considerations due to the fact that JS can set the
application priority - isn't that different enough (from
earlier uses of DSCP) that a browser might want to be a
little suspicious if some JS wants to try send too much
stuff as high priority, given that that same JS code might
be running on many many browsers all at once for a while
after some WebRTC server has been hacked? Or do we conclude
that that won't make any real difference or make it easier
for such JS malware to cause some kind of DoS somewhere?

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 May 2016 19:54:10 +0000

Hi Stephen,

Sure - that security consideration makes sense to add, IMHO.  In addition
to the browser being a little suspicious, the new text could also usefully
point out that the Diffserv architecture requires ingress traffic conditioning
for reasons that include protecting the network from this sort of attack.

I'd view the two countermeasures as complementary.

Thanks, --David (as draft shepherd)

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, May 18, 2016 12:06 PM
> To: The IESG
> Cc: [email-masked]; Black, David; [email-masked];
> Black, David; [email-masked]
> Subject: Stephen Farrell's No Objection on draft-ietf-tsvwg-rtcweb-qos-16: (with
> COMMENT)
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 18 May 2016 15:37:09 -0500

Not as AD, for now ... but I'm curious.

> I'd view the two countermeasures as complementary.

I'd agree with adding both points, I think, but I'm not sure what the
browser should be looking for (how much is "too much" high-priority
traffic?), so I'm not sure what the recommendation is, here.

Just, "be suspicious"? Or is there more specific guidance that could be
included?

Thanks,

Spencer

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 May 2016 21:38:51 +0100

> Just, "be suspicious"? Or is there more specific guidance that could be

Yeah, if I knew a good answer to that, I'd have balloted DISCUSS;-)

I think we can point out the issue but I'm not sure what a browser
can do really.

Cheers,
S.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 18 May 2016 15:45:53 -0500

Hi, Stephen,

> I think we can point out the issue but I'm not sure what a browser

OK, we're in sync here.

Thanks,

Spencer

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 19 May 2016 03:48:30 +0000

I modified the security considerations section to capture the idea (and 
much wording).  Please feel free to suggest additional improvements.

Paul

<section title="Security Considerations">
   <t>
     Since it is possible for the JavaScript application to indicate
     an Application Priority and, therefore, influence the DSCP value
     the browser uses for media flows, the browser might wish to
     consider a large number of higher priority flows as suspect.  If
     the server hosting the JavaScript application is compromised,
     many browsers within the network might simultaneously transmit
     flows with the same DSCP marking.  The DiffServ architecture
     requires ingress traffic conditioning for reasons that include
     protecting the network from this sort of attack.
   </t>

   <t>
     Otherwise, this specification does not add any additional
     security implications beyond those addressed in the following
     DSCP-related specifications.  For security implications on use
     of DSCP, please refer to Section 7 of <xref target="RFC7657"/>
     and Section 6 of <xref target="RFC4594"/>.  Please also see
     <xref target="I-D.ietf-rtcweb-security"/> as an additional
     reference.
   </t>
</section>

------ Original Message ------
From: "Black, David" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>; "The IESG" 
<[email-masked]>
Cc: "[email-masked]" 
<[email-masked]>; "[email-masked]" 
<[email-masked]>; "[email-masked]" <[email-masked]>; "Black, 
David" <[email-masked]>
Sent: 5/18/2016 3:54:10 PM
Subject: RE: Stephen Farrell's No Objection on 
draft-ietf-tsvwg-rtcweb-qos-16: (with COMMENT)

---

From: [email-masked]
Date: Thu, 19 May 2016 06:54:35 +0000

> much wording).  Please feel free to suggest additional improvements.

LGTM
Cheers 
S