Subject: [TLS] Last call comments about DTLS (mostly editorial)

From: [email-masked]
Date: Thu, 17 Mar 2005 17:45:09 +0200

I've started reviewing draft-rescorla-dtls-03, and 
here's my first batch of comments (mostly editorial).

(I also have a couple of more technical comments, but
I haven't finished writing them down yet. I'll send
them in a separate message in a couple of days.)

1) 

Section 2 says that "While the design of the DTLS protocol does
not preclude its use in securing arbitrary datagram traffic, it
is primarily expected to secure communication based on datagram
sockets."

What does this mean? That DTLS is primarily intended for UDP,
but could be used for other kinds of datagram transports?

Suggested change: clarify sentence somehow.

2)

In Sections 4.2.1 and 4.3, "Cookie cookie<0..32>;" is not
correct, since the document does not define the type "Cookie"
(and even if it did, that would mean up to 32 individual
cookies).

Suggested change: define "opaque Cookie<0..32>;" and change the
ClientHello/HelloVerifyRequest field to "Cookie cookie;"

3)

Section 4.2.4.1: "RECOMMEND" is not a RFC 2119 keyword,

Suggested change: "We RECOMMEND that implementations use..." -->
"Implementations SHOULD use..."

4)

Section 4.2.4.1: Since [TCP] defines MSL to be 2 minutes, why
not just say so?

Suggested change "up to twice the TCP Maximum Segment Lifetime.
[TCP]" --> "up to 240 seconds (which happens to be twice the TCP
Maximum Segment Lifetime in [TCP])"

5)

Sections 4.2 and 5 make exaggarated claims about cookies and
denial of service attacks.

Cookies don't "prevent denial of service attacks"; they make it
more difficult to spoof the source IP address, but that's all. 
For instance, cookies alone do nothing to protect against DoS 
attacks where the source IP address is not spoofed.

Suggested change: explain that cookies give some protection
against DoS attacks from spoofed IP addresses. For attacks 
where the source IP is not spoofed, the DoS situation is 
the same as in ordinary TLS.

6)

Section 4.2.1 says that "If the client does not have a cookie
for a given server, it should use a zero-length cookie."

Cookies are not specific to a server, but a particular
negotiation instance (at least if the server follows the advice
given later and includes ClientHello.random in cookie
calculation). And even though "should" is an ordinary English
word, rather than RFC2119 keyword, it still raises the question
when some other choice (than using a zero-length cookie) would
make sense.

Suggested change: "If the client does not have a cookie for a
given server, it should use a zero-length cookie." --> "When
sending the first ClientHello, the client does not have a 
cookie yet; in this case, the Cookie field is left empty 
(zero length)."
  
7)

Section 4.3 is missing the ClientHello message.

Suggested change: copy the definition from Section 4.2.1.

8)

Section 6 (IANA Considerations): This document defines a new
HandshakeType value, so IANA needs to be told about it.

Also, the text "Identifiers MAY NOT be assigned for DTLS that
conflict with TLS" is quite unclear and probably unnecessary:
since we're using the same registries as TLS, how would IANA
allocate a conflicting number? (and "MAY NOT" is not a RFC 
2119 keyword anyway)

Suggested text:

   This document uses the same identifier space as TLS [TLS11],
   so no new IANA registries are required.

   This document defines a new handshake message,
   hello_verify_request, whose value is to be allocated from 
   the TLS HandshakeType registry defined in [TLS11]. The 
   value "3" is suggested.

9)

I would probably call [PHOTURIS], [RFC2401], [TCP], and [TLS]
informative references rather than normative. 

10)

Section numbering is a bit broken (there are two sections
numbered 4.2). And a table of contents wouldn't hurt, since
the document is anyway over 20 pages.

11)

Complaints from idnits-v1.61:

There are 11 instances of too long lines in the document, the 
longest one being 8 characters in excess of 72.
There is 1 instance of lines with control characters in   
the document.
It seems as if not all pages are separated by form feeds - 
found 0 form feeds but 22 pages

Best regards,
Pasi

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Mar 2005 08:16:08 -0800

Pasi,

Thanks for your comments. These seem pretty sensible. 
A few responses below.

> them in a separate message in a couple of days.)
We look forward to seeing them.

> but could be used for other kinds of datagram transports?

No, that you could use it for an DTLS tunnelled VPN a la IPsec,
but we mostly expect it to be used for application-layer
traffic a la TLS.

> Suggested change: clarify sentence somehow.
Suggested change: strike insane sentence entirely.

> ClientHello/HelloVerifyRequest field to "Cookie cookie;"
Good catch. 

> "Implementations SHOULD use..."
Sheesh. It's recommended.

> Maximum Segment Lifetime in [TCP])"

I have some memory that not all real TCP systems use 2 minutes,
which is why I added the indirection.

> the same as in ordinary TLS.
Ouch. My brain was on vacation that day.

> informative references rather than normative. 

RFC 2401 is needed as normative because it specifies in
part the anti-replay algorithm. TCP specifies MSL, and
since this is a delta from TLS, we need to specify TLS
as normative.

> the document is anyway over 20 pages.
Good catch.

> found 0 form feeds but 22 pages
I don't know what's going on here, since I do have form feeds. :(

Thanks,
-Ekr