draft-westerlund-tsvwg-sctp-dtls-chunk's Introduction

Stream Control Transmission Protocol (SCTP) DTLS Chunk

This is the working area for the individual Internet-Draft, "Stream Control Transmission Protocol (SCTP) CRYPTO Chunk".

Contributing

Contributions can be made by creating pull requests. The GitHub interface supports creating pull requests using the Edit (✏) button.

Command Line Usage

Formatted text and HTML versions of the draft can be built using make.

$ make

Command line usage requires that you have the necessary software installed. See the instructions.

draft-westerlund-tsvwg-sctp-dtls-chunk's People

Contributors

Watchers

draft-westerlund-tsvwg-sctp-dtls-chunk's Issues

Update PPID registration

This draft has gotten a PPID assigned:
4242 DTLS Chunk Key-Management Messages [draft-westerlund-tsvwg-sctp-dtls-chunk-01]

Need to update the draft.

Split DTLS Options Identifier space info safe to ignore, ignore and report, fail types.

The DTLS options in the parameter is not split into categories where one can define them as being possible to ignore or need to be understood. That should be done by splitting the spaces based on the higher bits like for other SCTP code points.

PVALID needs to define how it is reliability mechanism works

Turning off DTLS replay protection is typically a major security problem

https://mailarchive.ietf.org/arch/msg/tls/f990CfKIRDQKTa4tAkIrgHcKqWc/

Hi,

Reading RFC 9147 (DTLS 1.3) I cannot find any other interpretation than that replay protection may be disabled for all records. This is not a problem for the initial lock-step handshake, alerts, KeyUpdate, and ACKs. It seems to be a major problem for NewSessionTicket, NewConnectionId, RequestConnectionId, and Post-handshake client authentication as the lack of replay protection might significantly affect availability. It seems to me that DTLS 1.3 forgot to update replay protection based on the new post-handshake messages. Let me know if I miss something.

It is a bit surprising that DTLS 1.3 published in 2022 allows the application to turn off replay protection at all. This very far from current best practice for security protocols. There are very good reasons why Datagram QUIC mandates replay protection and why TLS 1.3 has several pages discussing security considerations for 0-RTT data, which lacks replay protection. In general, turning off replay protection (even just for application data) might lead to loss of confidentiality, integrity, and availability, i.e., the whole CIA triad.

Applications cannot be expected to understand the severe consequences of not having replay protection or understand how to fix it on the application layer. I also don't see any need for turning off replay protection except RFC 6083 which is a bit of a special case, and which turned out to have replay issues.
https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00

I would strongly recommend all DTLS 1.3 libraries to completely remove the option to disable replay protection.

An easy fix for the post-handshake messages is to "clarify" that replay protection must not be turned off for anything else than application data. I you agree I can submit an “erratum” for RFC 9147. But this does not solve the general issue that turning off replay protection would be a major security problem in almost all applications.

Cheers,
John Preuß Mattsson

Recommend Projects