Found 2 records.

Status: Held for Document Update (1)

RFC 6083, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", January 2011

Note: This RFC has been updated by RFC 8996

Errata ID: 5744
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sidhartha Pant
Date Reported: 2019-05-30
Held for Document Update by: Martin Duke
Date Held: 2020-04-21

Section 4.8 says:

4.8.  Handling of Endpoint-Pair Shared Secrets

   The endpoint-pair shared secret for Shared Key Identifier 0 is empty
   and MUST be used when establishing a DTLS connection.  Whenever the
   master key changes, a 64-byte shared secret is derived from every
   master secret and provided as a new endpoint-pair shared secret by
   using the exporter described in [RFC5705].  The exporter MUST use the
   label given in Section 5 and no context.  The new Shared Key
   Identifier MUST be the old Shared Key Identifier incremented by 1.
   If the old one is 65535, the new one MUST be 1.

   Before sending the Finished message, the active SCTP-AUTH key MUST be
   switched to the new one.

   Once the corresponding Finished message from the peer has been
   received, the old SCTP-AUTH key SHOULD be removed.

It should say:

4.8.  Handling of Endpoint-Pair Shared Secrets

   The endpoint-pair shared secret for Shared Key Identifier 0 is empty
   and MUST be used when establishing a DTLS connection.  Whenever the
   master key changes, a 64-byte shared secret is derived from every
   master secret and provided as a new endpoint-pair shared secret by
   using the exporter described in [RFC5705].  The exporter MUST use the
   label given in Section 5 and no context.  The new Shared Key
   Identifier MUST be the old Shared Key Identifier incremented by 1.
   If the old one is 65535, the new one MUST be 1.

   Before sending the Finished message, the active SCTP-AUTH key 
   SHOULD be switched to the new one.
   However if the ChangeCipherSpec and Finished messages are sent 
   back to back, there may be a case if Finished message is sent with
   the new key might get dropped by peer, if the new key is not 
   configured yet.
   Hence the sender MAY send the Finished message with Old Key which
   SHOULD be accepted by the peer. 

   Once the corresponding Finished message from the peer has been
   received, the old SCTP-AUTH key SHOULD be removed.

Notes:

If the time gap between the ChangeCipherSpec and Finished messages is very less than either the peer may wait to configure the new key received in ChangeCipherSpec and then validate the Finished messges with new key. Alternatively the Sender may choose to send the Finished message with Old key to peer which should still be configured at the peer. Once the peer recevies the Finished message it should accept with Old key. Subsequently the Old key Should be removed.
Hence during this switchover of Key , two keys can be used by both peer nodes.

Status: Rejected (1)

RFC 6083, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", January 2011

Note: This RFC has been updated by RFC 8996

Errata ID: 6323
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Claudio Porfiri
Date Reported: 2020-11-04
Rejected by: Martin Duke
Date Rejected: 2020-11-06

Section 1.1 says:

The maximum user message size is 2^14 bytes, which is the DTLS
      limit.

It should say:

The maximum user message size is limited by the DTLS implementation.

Notes:

TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes).
See https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/?include_text=1
section 3.3 as reference
--VERIFIER NOTES--
The citation in the note clearly refers to handshake messages, not application data records. RFC 4347 and draft-ietf-tls-dtls13 clearly state that the limit is 2^14.

Report New Errata