Skip to main content

Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)
RFC 6083

Yes

(David Harrington)

No Objection

(Adrian Farrel)
(Alexey Melnikov)
(Ralph Droms)
(Russ Housley)
(Stewart Bryant)

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

Lars Eggert (was Discuss) No Objection

Comment (2010-08-23)
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

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection ()

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection (2010-08-25)
I support Lars's DISCUSS on section 3.1

(Jari Arkko; former steering group member) No Objection

No Objection (2010-08-24)
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

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection (2010-08-24)
I also found section 3.1 awkward

(Ron Bonica; former steering group member) No Objection

No Objection (2010-08-26)
Support Lars' discuss

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2010-08-25)
#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

No Objection ()

                            

(Tim Polk; former steering group member) No Objection

No Objection (2010-08-26)
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).