RFC Errata
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.