Found 1 record.

Status: Held for Document Update (1)

RFC 4347, "Datagram Transport Layer Security", April 2006

Note: This RFC has been obsoleted by RFC 6347

Note: This RFC has been updated by RFC 5746, RFC 7507

Errata ID: 115
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Held for Document Update by: Russ Housley

(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.)

Notes:

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.

from pending

Report New Errata