Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness
RFC 7675

Note: This ballot was opened for revision 15 and is now closed.

(Ben Campbell) Yes

Comment (2015-08-04 for -15)
No email
send info
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?


-- 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. "

(Alissa Cooper) Yes

(Spencer Dawkins) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Deborah Brungard) No Objection

(Benoît Claise) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2015-08-13)
No email
send info
Thanks for putting up with my partly silly discuss/comments.

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

Comment (2015-07-28 for -15)
No email
send info
A couple of very minor comments only:

FWIW, I think rtcweb-security-arch need only be an informative reference; it seems only explanatory.  I also think that about RFC 6263.

-- Section 5.1 --

   A full ICE implementation obtains consent to send using ICE.  After
   ICE concludes on a particular candidate pair and whenever the
   endpoint sends application data on that pair consent MUST be
   maintained following the procedure described in this document.

I don't understand the "MUST" here, given that Section 4 says this is "an optional extension".  Why "MUST", then, rather than "can be"?

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-08-03 for -15)
No email
send info
Thank you for your response to the SecDir review.

Alvaro Retana No Objection