Subject: RFC 4347 (DTLS) errata

From: Alfred Hönes <[email-masked]>
Date: Mon, 29 May 2006 11:53:32 +0200 (MESZ)

Hello,

studying the recently published RFC 4347 authored/edited by you,
I found a couple of issues I'd like to report.

All excerpts from the RFC text are taken keeping their original
formatting, and modified text is formatted in conformance with
RFC guidelines again.

I use change bars ('|' in column 1) and casual up/down pointing
tags ('^^^' / 'vvv' marks in extra lines) to emphasize the location
of textual issues and/or proposed textual enhancements/corrections.

(1)  typo

At the top of page 3, Section 1 of RFC 4347 says:

                [...].  Unfortunately, although application layer
   security protocols generally provide superior security properties
   (e.g., end-to-end security in the case of S/MIME), they typically
   requires a large amount of effort to design -- in contrast to the
   relatively small amount of effort required to run the protocol over
   TLS.

It should say:

                [...].  Unfortunately, although application layer
   security protocols generally provide superior security properties
   (e.g., end-to-end security in the case of S/MIME), they typically
|  require a large amount of effort to design -- in contrast to the
   relatively small amount of effort required to run the protocol over
   TLS.

(2)  imprecise data description for `ciphersuites`

This is an issue inherited from RFC 4346 -- see my errata submission
on that RFC.  For convenience, I repeat the details here.

Section 7.4.1.2 of RFC 4346 (on p. 12 of RFC 4346) defines the syntax:

      uint8 CipherSuite[2];    /* Cryptographic suite selector */

According to the specifications given in Section 4.3 of RFC 4346,
vectors of type CipherSuite strictly must have byte lengths being a
multiple of 2.
This also means that the upper bound for a varaiable-length array
of type CipherSuite should always be a multiple of 2.

Hence, the declaration in Section 4.2.1 of RFC 4347, on page 12,

      struct {
        ProtocolVersion client_version;
        Random random;
        SessionID session_id;
        opaque cookie<0..32>;                             // New field
        CipherSuite cipher_suites<2..2^16-1>;
        CompressionMethod compression_methods<1..2^8-1>;
      } ClientHello;

should say:

      struct {
        ProtocolVersion client_version;
        Random random;
        SessionID session_id;
        opaque cookie<0..32>;                             // New field
|       CipherSuite cipher_suites<2..2^16-2>;
        CompressionMethod compression_methods<1..2^8-1>;
      } ClientHello;

This change should be applied to the syntax summary in section 4.3.2,
on mid-page 21, as well.

(3)  missing white space

In Section 4.2.2 of RFC 4347, the lines on top of page 14,

          case hello_verify_request: HelloVerifyRequest;  // New type
          case server_hello:  ServerHello;
          case certificate:Certificate;
          case server_key_exchange: ServerKeyExchange;
          case certificate_request: CertificateRequest;
          case server_hello_done:ServerHelloDone;
          case certificate_verify:  CertificateVerify;
          case client_key_exchange: ClientKeyExchange;
          case finished:Finished;

should say:

          case hello_verify_request: HelloVerifyRequest;  // New type
          case server_hello:         ServerHello;
|         case certificate:          Certificate;
          case server_key_exchange:  ServerKeyExchange;
          case certificate_request:  CertificateRequest;
|         case server_hello_done:    ServerHelloDone;
          case certificate_verify:   CertificateVerify;
          case client_key_exchange:  ClientKeyExchange;
|         case finished:             Finished;

This change should be applied to the syntax summary in section 4.3.2,
on top of page 21, as well.

(4)  copy-and-paste issue (?)

On page 20, the first declaration in Section 4.3.2,

      enum {
        hello_request(0), client_hello(1), server_hello(2),
        hello_verify_request(3),                          // New field
        certificate(11), server_key_exchange (12),
        certificate_request(13), server_hello_done(14),
        certificate_verify(15), client_key_exchange(16),
        finished(20), (255)
      } HandshakeType;

should say, using the appropriate term:

      enum {
        hello_request(0), client_hello(1), server_hello(2),
|       hello_verify_request(3),                          // New value
        certificate(11), server_key_exchange (12),
        certificate_request(13), server_hello_done(14),
        certificate_verify(15), client_key_exchange(16),
        finished(20), (255)
      } HandshakeType;

(5)  Outdated Informative References

RFC 4347 has been published several months after the new IPsec RFCs.
It therefore would have been preferrable to have the following
references updated:

   [AH]   :  RFC 2402  -->  RFC 4302

   [ESP]  :  RFC 2406  -->  RFC 4303

BTW: The Ref. "[AH]" does *not* appear anywhere in the text!

Also, The DCCP RFCs have been published a few weeks before RFC 4347;
therefore, the following Ref. update would have been appropriate:

   [DCCP] :  "Work in Progress"  -->  RFC 4340, March 2006.

(6)  unexpected / inappropriate Reference

Page 23 contains the inappropriate Informative Reference:

   [PHOTURIS] Karn, P. and W. Simpson, "ICMP Security Failures
              Messages", RFC 2521, March 1999.

This clearly should be:

|  [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management
|             Protocol", RFC 2522, March 1999.

(Cf. the citations to [PHOTURIS], in Section 4.2.1, on page 11.)

I propose to post an Errata Note covering the above issues,
to the RFC Editor's RFC Errata web page.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+