Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)
RFC 6083
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Lars Eggert (was Discuss) No Objection
Section 1.1., paragraph 2: > Security features provided by DTLS over SCTP include authentication, > message integrity and privacy of user messages. Applications using > DTLS over SCTP can use almost all transport features provided by SCTP > and its extensions. Which ones can they not use? (Also, nit, I'm not a big fan of 1:1 repetition of the abstract in the introduction.) Section 3.2., paragraph 1: > DTLS limits the DTLS user message size to the current Path MTU minus > the header sizes. This limit SHOULD be increased to 2^14 Bytes for > DTLS over SCTP. The wording here is odd. You don't actually want to increase a limit of the base DTLS spec (because otherwise you'd need to Update it.) You probably want to say "for the purposes of running over SCTP, the DTLS path MTU SHOULD be considered to be 2^14." (And should this not be a MUST?) Section 4.3., paragraph 1: > Application protocols running over DTLS over SCTP SHOULD register and > use a separate payload protocol identifier (PPID) and SHOULD NOT > reuse the PPID that they registered for running directly over SCTP. Shouldn't these be MUSTs? Section 4.4., paragraph 2: > All DTLS messages of the ApplicationData protocol MAY be transported > over stream 0, but users SHOULD use other streams to avoid possible > performance problems due to head of line blocking. Suggest to change the sentence logic to "SHOULD use other streams, MAY use 0 if <condition>" and therefore say when it is OK to go against the SHOULD. Section 1.1., paragraph 17: > o The DTLS user can not perform the SCTP-AUTH key management, Nit: s/can not/cannot/ Section 4.5., paragraph 1: > This makes sure that an attacker can not modify the stream in which a Nit: s/can not/cannot/
(David Harrington; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
I support Lars's DISCUSS on section 3.1
(Jari Arkko; former steering group member) No Objection
Review by Ari Keränen:
3.1. Future Versions of DTLS
This document is based on [RFC4347]. If a new RFC updates or
obsoletes [RFC4347], this documents also applies to the newer
document defining DTLS unless this document also gets updated or
revised.
How do you know whether the "new DTLS" is compatible with this spec?
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
I also found section 3.1 awkward
(Ron Bonica; former steering group member) No Objection
Support Lars' discuss
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
#1 - Agree with Lars DISCUSS. A nice attempt at future proofing, but I don't think it'll fly ;) #2 - Sec 4.6: Before sending a ChangeCipherSpec message all outstanding SCTP user messages MUST have been acknowledged by the SCTP peer and MUST NOT be revoked anymore by the SCTP peer. anymore? Should it just be "revoked by"? #3 - In the security considerations, the I-D notes that "It is possible to authenticate DTLS endpoints based on IP-addresses in certificates." I went and looked in SCTP and didn't find anything about limiting endpoints with IP-address in certificates. It'd be nice to have a reference for this?
(Stewart Bryant; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
I support Lars discuss on section 3.1 I support Sean's discuss issue #1 (restrict the DTLS cipher suites to ones that provide the required security services).