RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (1)

RFC 6655, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", July 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3761
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sandeep S. Kumar
Date Reported: 2013-10-22
Verifier Name: Sean Turner
Date Verified: 2014-01-14

Section 3 says: 

In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the
48-bit seq_num.

It should say:

In DTLS, the 64-bit sequence number is the 16-bit epoch concatenated 
with the 48-bit sequence_number in the order they appear on the wire.

Notes:

In DTLS 1.2 (RFC 6347, Sec 4.3.1.), the 48 bit sequence number is indicated as sequence_number. There is no mention of seq_num in the DTLS RFC.
The additional ordering information is used to keep it consistent with MAC computation in DTLS RFC 6347, Sec 4.1.2.1.)

Status: Reported (2)

RFC 6655, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", July 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3987
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Manuel Pégourié-Gonnard
Date Reported: 2014-05-14

Section 4 says: 

             CipherSuite TLS_PSK_DHE_WITH_AES_128_CCM_8 = {0xC0,0xAA}
             CipherSuite TLS_PSK_DHE_WITH_AES_256_CCM_8 = {0xC0,0xAB}

It should say:

             CipherSuite TLS_DHE_PSK_WITH_AES_128_CCM_8 = {0xC0,0xAA}
             CipherSuite TLS_DHE_PSK_WITH_AES_256_CCM_8 = {0xC0,0xAB}

Notes:

Since these suites use the DHE_PSK key exchange, their name should start with TLS_DHE_PSK, not TLS_PSK_DHE, which is inconsistent with the general naming scheme of ciphersuites, and with the names of their CCM (as opposed to CCM_8) counterparts.

Errata ID: 3990
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Manuel Pégourié-Gonnard
Date Reported: 2014-05-16

Section 6.2 says: 

   ... The input and output lengths are as for
   AEAD_AES_128_CCM.  An AEAD_AES_128_CCM_8 ciphertext is exactly 8
   octets longer than its corresponding plaintext.

It should say:

   ... The input and output lengths are as for
   AEAD_AES_128_CCM.  An AEAD_AES_256_CCM_8 ciphertext is exactly 8
   octets longer than its corresponding plaintext.

Notes:

This section is about AEAD_AES_256_CCM_8, so it should describe the length of a cihpertext with this cipher, not with An AEAD_AES_128_CCM_8 (which was the object of the prevous section).

Status: Held for Document Update (1)

RFC 6655, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", July 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3760
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sandeep S. Kumar
Date Reported: 2013-10-22
Held for Document Update by: Sean Turner
Date Held: 2014-01-14

Section 3 says: 

....is 8 octets.  Each value of the
   nonce_explicit MUST be distinct for each distinct invocation of the
   GCM encrypt function for any fixed key.  Failure to meet...

It should say:

....is 8 octets.  Each value of the
   nonce_explicit MUST be distinct for each distinct invocation of the
   CCM encrypt function for any fixed key.  Failure to meet...

Notes:

GCM should be corrected to CCM. The draft discusses the AES-CCM mode of operation.

spt: Don't think implementers will be confused by this so HFDU.

Report New Errata



Advanced Search