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

["Ram Mohan R (rmohanr)" <[e-mail]>]

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 <[e-mail]>
Date: Thursday, 6 August 2015 10:26 am
To: Ben Campbell <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]"
<[e-mail]>,
"[e-mail]" <[e-mail]>,
"[e-mail]"
<[e-mail]>,
"[e-mail]"
<[e-mail]>, "[e-mail]"
<[e-mail]>
Subject: Re: Ben Campbell's Yes on
draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT)

>Hi Ben,
>
>Thanks for your feedback. Please see my responses inline
>
>-----Original Message-----
>From: Ben Campbell <[e-mail]>
>Date: Wednesday, 5 August 2015 3:38 am
>To: The IESG <[e-mail]>
>Cc: "[e-mail]"
><[e-mail]>,
>"[e-mail]" <[e-mail]>,
>"[e-mail]"
><[e-mail]>,
>"[e-mail]"
><[e-mail]>, "[e-mail]"
><[e-mail]>
>Subject: Ben Campbell's Yes on
>draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT)
>
>>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?
>
>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."
>
>
>
>>
>>-- 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.
>
>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.
>
>
>
>>
>>- 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.
>
>No. Even in that case consent is needed.
>
>
>
>>
>>-- 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?
>
>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.
>
>
>>
>>-- 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.
>
>The next para discusses how the endpoint has to pace the bind requests for
>consent. 
>It mentions that the interval is between 4 - 6.
>
>
>
>
>>
>>-- 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?
>
>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)
>
>
>>
>>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. "
>
>Thanks. Will address all the nits above.
>
>Regards,
>Ram
>
>
>>
>>
>