RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (3)

RFC 5764, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", May 2010

Note: This RFC has been updated by RFC 7983, RFC 9443

Source of RFC: avt (rai)

Errata ID: 3971
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Martin Thomson
Date Reported: 2014-04-22
Verifier Name: Ben Campbell
Date Verified: 2015-07-22

Section 4.1.3 says:

   If the client detects a nonzero-length MKI in the server's response
   that is different than the one the client offered, then the client
   MUST abort the handshake and SHOULD send an invalid_parameter alert.

It should say:

   If the client detects a nonzero-length MKI in the server's response
   that is different than the one the client offered, then the client
   MUST abort the handshake and SHOULD send an illegal_parameter alert.

Notes:

invalid_parameter isn't defined anywhere; this probably means illegal_parameter(47), which is defined in RFC 5246.

Errata ID: 4788
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Eric Rescorla
Date Reported: 2016-08-30
Verifier Name: Ben Campbell
Date Verified: 2016-11-08

Section 4.2 says:

   which are assigned as shown below.  The per-association context value
   is empty.

It should say:

   which are assigned as shown below.  No per-association context value
   is used.

Notes:

This code is somewhat ambiguous, though the better interpretation is probably that you should use a zero-length context (arm 2 of https://tools.ietf.org/html/rfc5705#section-4). However, real implementations do not seem to use the exporter value, so we need to resolve this in that direction.

Errata ID: 4873
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Peter Wu
Date Reported: 2016-11-30
Verifier Name: Murray Kucherawy
Date Verified: 2023-11-08

Section 5.1.1 says:

When the mechanism described in this document is in
effect, this is modified so that data written by upper-level protocol
clients of DTLS is assumed to be RTP/RTP and is encrypted using SRTP
rather than the standard TLS record encoding.

It should say:

When the mechanism described in this document is in
effect, this is modified so that data written by upper-level protocol
clients of DTLS is assumed to be RTP/RTCP and is encrypted using SRTP
rather than the standard TLS record encoding.

Notes:

Section 5.1 notes that RTP or RTCP can be sent over the channel, so "RTP/RTP" should be "RTP/RTCP".

Report New Errata



Advanced Search