RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 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".

Status: Held for Document Update (1)

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: 3913
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Martin Thomson
Date Reported: 2014-03-06
Held for Document Update by: Ben Campbell
Date Held: 2015-07-22

Section 5.1.2 says:

Arriving packets may be of types RTP, DTLS, or STUN [RFC5389].
...
                   |       B < 2   -+--> forward to STUN
...
If the value of this byte is 0 or 1, then the packet is STUN.

It should say:

Arriving packets may be of types RTP, DTLS, or STUN [RFC5389].  
STUN messages with methods identifiers of 1280 or higher cannot 
be demultiplexed.
...
                   |       B < 20  -+--> forward to STUN
...
If the value of this byte is less than 20, then the packet is STUN.

Notes:

This is a tricky one. We can't distinguish all STUN message types,
because - at least in theory - new message types >= 1280 can be added
to STUN, which could collide with DTLS.

Please see Section 7 of RFC 7983 for the change that addresses this problem more
holistically and *differently* than above.

Report New Errata



Advanced Search