Datagram Transport Layer Security
Note: This ballot was opened for revision 05 and is now closed.
(Ted Hardie) (was Discuss) Yes
Nits: However, over the past few years an increasing number of application layer protocols have been designed which UDP transport. --> which use UDP as a transport. SIP, for instance, uses a subsert of S/MIME to secure its traffic. -->subset of S/MIME it typically require a large amount of effort to design --->requires using the following sliding, window procedure --->sliding window procedure?
(Sam Hartman) Yes
Comment (2005-04-24 for -)
I suspect that some more examples will be needed as we find out how people manage to read this spec and make non-interoperable implementations. This seems like a fine level of detail for a proposed standard but probably will need revisions for draft. Overall quite well done.
(Russ Housley) Yes
(Allison Mankin) (was Discuss) Yes
Worked with Mark Allman and Ekr to edit the RTO/rtx discussion so it's congestion-aware, based on RFC 2988. DCCP needs to be careful when it writes DTLS/DCCP, as does DTLS/unordered SCTP.
(Brian Carpenter) No Objection
Comment (2005-04-21 for -)
Review comments from Joel Halpern: One minor suggestion occurred to me reading this. It would be helpful to have a paragraph or so indicating what should be done if using a transport like DCCP which does order preservation but not loss prevention. My guess is that we should just use this protocol, because the cost of extra serial numbers and a few checks is tiny. But it would be nice if the document said so. typo: last paragraph of 4.1.: in a single datagram. hey ^ T
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Scott Hollenbeck) No Objection
(David Kessens) No Objection
(Jon Peterson) No Objection
(Mark Townsley) No Objection
(Bert Wijnen) No Objection
Comment (2005-04-25 for -)
Comments recorded here to ensure they get picked up. Author (Eric) has already agreed to make sure these nits will be addressed. From AAA-doctors review (Jari): Its a great spec! Some minor nits below, however. Hope you find them useful... > 4.1.1. Transport Layer Mapping > > Each DTLS record MUST fit within a single datagram. In order > to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD > determine the MTU and send records smaller than the MTU. DTLS > implementations SHOULD provide a way for applications to > determine the value of the PMTU (or alternately the maximum > application datagram size, which is the PMTU minus the DTLS > per-record overhead). If the application attempts to send a > > ... > > 220.127.116.11. PMTU Discovery > > In general, DTLS's philosophy is to avoid dealing with PMTU > issues. The general strategy is to start with a conservative > MTU and then update it if events require it, but not actively > probe for MTU values. PMTU discovery is left to the > application. I think I know what you intend to do here, but the above two text pieces appear to be in conflict. And isn't PMTU probing is more or less what you are doing in Section 18.104.22.168 anyway? Suggest changing the latter text to "The general strategy is to start with a conservative MTU and then update it if events either during the handshake or actual application data transport phase require it." > The PMTU SHOULD be initialized from the interface MTU that > will be used to send packets. If the DTLS implementation > receives an RFC 1191 [RFC1191] ICMP Destination Unreachable > message with the "fragmentation needed and DF set" Code > (otherwise known as Datagram Too Big) it should decrease its > PMTU estimate to that given in the ICMP message. A DTLS > implementation SHOULD allow the application to occasionally > reset its PMTU estimate. The DTLS implementation SHOULD also > allow applications to control the status of the DF bit. These > controls allow the application to perform PMTU discovery. How does this play with RFC 1981, IPv6 version of PMTU discovery? At least the ICMPs are different, and the IPv6 version appears to say something more specific about the aging of PTMU information. Suggest adding "RFC 1981 procedures SHOULD be followed for IPv6.", or something to this effect. > 2. An attacker can use the server as an amplifier by > sending connection initiation messages with a forged source > of the victim. The server then sends its next message (in > DTLS, a Certificate message, which can be quite large) to > the victim machine, thus flooding it. > ... > Although DTLS servers are not required to do a cookie > exchange, they SHOULD do so whenever a new handshake is > performed in order to avoid being used as amplifiers. If the > server is being operated in an environment where amplification > is not a problem, the server MAY choose not to perform a > cookie exchange. In addition, the server MAY choose not do to > a cookie exchange when a session is resumed. Clients MUST be > prepared to do a cookie exchange with every handshake. This is pretty good stuff. But given that the victim is a different entity than the one that decides whether the cookies are used, I wonder if you should say this slightly differently. Maybe "DTLS servers SHOULD perform a cookie exchange whenever a new handshake is being performed. If the server is being operated in an environment where amplification is not a problem, the server MAY be configured to not to perform a cookie exchange. The default SHOULD be that the exchange is performed, however. In addition, the server MAY choose not do to a cookie exchange when a session is resumed. Clients MUST be prepared to do a cookie exchange with every handshake." > layer security protocol. SIP, for instance, uses a subsert of s/subsert/subset/ > Multiple DTLS records may be placed in a single datagram. hey s/hey/They/ > Section 3.4.3 of [RFC 2402] s/]/]./ > A.1Summary of new syntax Non-ascii char.