Ballot for draft-ietf-rtcweb-stun-consent-freshness
Yes
No Objection
Note: This ballot was opened for revision 15 and is now closed.
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. "
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"?
Thank you for your response to the SecDir review. https://www.ietf.org/mail-archive/web/secdir/current/msg05760.html
Thanks for putting up with my partly silly discuss/comments.