Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)
RFC 7350
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
(Alissa Cooper; former steering group member) Yes
(Spencer Dawkins; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Alia Atlas; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
First of all, let me applause. I don't recall the last time a WG was ahead of schedule. Jul 2014 Send draft adding DTLS as a transport for STUN/TURN to IESG for publication as Proposed Standard draft-ietf-tram-stun-dtls Confused by the abstract/footer. The former is "DTLS for STUN", while the latter is "TURN over DTLS". Both should be aligned. Wouldn't the abstract/footer be more accurate with "DTLS for STUN and TURN" or maybe "DTLS for ICE"?
(Brian Haberman; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
Editorial: Section 4.3 has some broken XML code for the reference.
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
Thank you for addressing the SecDir review comments. I'll look for the update as many good points were made and discussed with the editors. This is a placeholder to watch for the corrections identified in the review. The discussion looks good so far, thanks. Could a reference be added for the two items in this description of the Introduction? This sub-optimality primarily stems from the added latency incurred by the TCP-based head-of-line (HOL) blocking problem coupled with additional TLS buffering (for integrity checks).
(Martin Stiemerling; former steering group member) (was Discuss) No Objection
thank you for addressing the discuss.
(Pete Resnick; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- section 3, last para: the magic cookie is mentioned here without introduction. Maybe add a ref to section 6 of 5389 if that's the right place? - 4.1.1: "The <host> value MUST be used when using the rules in Section 7.2.2 of [RFC5389] to verify the server identity. A STUN URI containing an IP address MUST be rejected, unless the domain is provided by the same mechanism that provided the STUN URI, and that this domain name can be passed to the verification code." I didn't get that sorry, can you explain what it means? The "domain is provided by" bit confused me. (Same for end of 4.6.1) - 4.2, 1st para: "not possible" hmm. Well, if the same SDP stuff is sent to many places then it is, or if the attacker can otherwise see the SDP stuff. Isn't that common or won't it be common with WebRTC? - 4.2, 2nd para: I'm not getting if you're encouraging folks to use [I-D.thomson-rtcweb-ice-dtls] or not. Might help to be clear about that. (I've not followed the discussion on that draft though.) - Section 5: Thanks!
(Ted Lemon; former steering group member) No Objection