Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 04 Aug 2015 15:08:23 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-rtcweb-stun-consent-freshness-15: Yes

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-stun-consent-freshness/

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

This looks good overall. I have a few minor comments:

-- General: 

After re-reading this, and the relevant parts of
rtcweb-security-architecture, I think a novice reader might find the
meaning of "consent" a bit vague, especially in terms of how it might
differ from "reachability". Can you offer an example of when an otherwise
reachable peer might choose to withdraw consent?

-- section 1, first paragraph:

I think readers are going to stumble over why we think a device that
plans to attack a peer is going to worry about consent. This makes more
sense in section 2. It might be helpful to move (or copy) the bit about
"... deployments of WebRTC..." and "... malicious javascript" forward to
the intro.

- 4, 3rd paragraph:

Should the reader infer that the receipt of a package that is strongly
assured to have come from a party implies consent from that party? If so,
it might be worth an explicit mention.

-- 5.1, first paragraph:

The normative MUST feels wrong here, (and is probably redundant with
other normative language further down in the section.) For example, could
a sender just choose to stop sending?

-- 5.1, 5th paragraph:

>From the next paragraph, I infer that you mean consent expires after 30
seconds when you have been sending binding request every few seconds, not
30 seconds after sending any particular binding request. If that's
correct it might be helpful to add a few words to that effect.

-- 5.1, 6th paragraph:

Does the "MUST NOT" refer to the general interval between checks prior to
randomization, or to the specific interval between a pair of checks after
randomization?

Nits:

-- 2, 2nd paragraph: "verify peer's consent"

Missing article (or "verify peer consent")

-- 5.1, paragraph 3:

s/sending an stun binding/sending a stun binding

-- 5.1, 7th paragraph: "Each STUN binding request for consent MUST use a
new STUN transaction
   identifier for every consent binding request..."

That's sort of redundant. I suggest something to the effect of "each
consent binding request MUST use a new stun transaction identifier. "

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 6 Aug 2015 04:56:21 +0000

Hi Ben,

Thanks for your feedback. Please see my responses inline

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Wednesday, 5 August 2015 3:38 am
To: The IESG <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>,
"[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Ben Campbell's Yes on
draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT)

>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/

Reachability of a endpoint does not indicate that it is willing to receive
traffic. 
So if a peer has to continue sending data it must do consent.
If the peer does not intend to send data, it can stop consent and later
resume Whenever it wants to send data again.
An example would be "As with a teacher in a classroom who grants consent
to each student to speak words, consent is granted to each sender to
transmit packets."

>"... deployments of WebRTC..." and "... malicious javascript" forward to

Sure. I will move the text related to malicious javascript to first para
of intro. 

OLD:
To prevent attacks on peers, endpoints have to ensure the remote peer
   is willing to receive traffic.  This is performed both when the
   session is first established to the remote peer using Interactive
   Connectivity Establishment ICE [RFC5245] connectivity checks, and
   periodically for the duration of the session using the procedures
   defined in this document.

NEW: 
To prevent attacks on peers, endpoints have to ensure the remote peer
   is willing to receive traffic. Verification of peer consent before
sending traffic is necessary in deployments like WebRTC to ensure that
a malicious JavaScript cannot use the browser as a platform for launching
attacks. This is performed both when the session is first established to
the
 remote peer using Interactive Connectivity Establishment ICE [RFC5245]
connectivity checks, and periodically for the duration of the session
using the procedures defined in this document.

>it might be worth an explicit mention.

No. Even in that case consent is needed.

>a sender just choose to stop sending?

Sender can stop sending data on that pair at anytime. If
the sender continues to send data, it must do consent other wise consent
will expire. That is the reason the document says that consent
must be maintained when application sends data. The other usage of
normative statements are for timer selection which is needed
to ensure that every implementation derives the timers based
on the suggested range.

>correct it might be helpful to add a few words to that effect.

The next para discusses how the endpoint has to pace the bind requests for
consent. 
It mentions that the interval is between 4 - 6.

>Randomization?

It is between a pair of checks after randomization. So essentially each
request should be paced between 4 - 6 seconds after initial consent
obtained (via ICE validation)

>consent binding request MUST use a new stun transaction identifier. "

Thanks. Will address all the nits above.

Regards,
Ram

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 11 Aug 2015 09:48:10 +0000

Hi Ben,

Here is the diffs with your comments updated.
https://github.com/Draft-Mafia/Consentfreshness/compare/ConsentDraftBenComm
ents

Once other comments from Stephen are resolved, I will send a consolidated
diff.

Ram

-----Original Message-----
From: Cisco Employee <[email-masked]>
Date: Thursday, 6 August 2015 10:26 am
To: Ben Campbell <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]"
Subject: Re: Ben Campbell's Yes on