I'm still undecided as how to publish the crate on crates.io, I have already tried to get into contact with the crate owner of dtls, and if that comes through, I'll use that.

However, if it doesn't come through, I'd like an alternative name that can be instantly used. I've thought of rustls-dtls, but that would pledge and use the rustls namespace, which I am not 100% sure on yet.

Funny or clever names are appreciated though :D

I currently chose the EUPL-1.2 license because I believe it could gain some recognition and interest as a government-created and legalised document, which would give projects using it more assured standing.

However, in the wider context of usability, compatibility, and other licensing, I don't know if this is the right choice, I'd like to see what some opinions are on licensing, and if I should change it to something like MIT or Apache-2.

(Of course, before doing that, I'll get consensus from all authors up until that point, so it's easier to change earlier than to do it later.

Also, I'm only interested if the current license is too restrictive for use, I am not going to change to a viral copyleft license like AGPLv3, as it would hinder library use, which is the primary motivation for this library for me.)

DTLS implementations are likely to send application data alongside flight 5 or 6, without waiting for confirmation, we should buffer this application data and give it to the connection object to then be immediately decrypted.

Brainstormed some ideas for anti-replay, and they're as follows;

• Have a VecDeque with epoch and sequence information on the packets, plus their arrival time.
• Have a "max age" parameter by which all older packets are discarded.

The first would be done with a 24-byte structure as;

pub struct PacketToken {
  epoch_seq: u64, // epoch and sequence in one
  at: Instant, // u128 on linux, u64 on macos and windows
}

This would discard anything older than 2 minutes, or FIFO at a max amount (configurable).

The oldest packet will update the "max age" sequence counter when it is popped from the stack, but only if it is younger than the age parameter.

Searching the VecDeque for a match when a packet comes in would introduce a little overhead, but at the cost of replay protection.

It would also cause a little memory overhead. (On linux, approximately 2.4MB for 100k packets indexed (150MB at max MTU, so 2 minutes of +10MBps download speeds))

The DTLS 1.2 handshake looks like thus;

All of this is able to be encapsulated in Handshaker objects, which handle all of this (+ retransmission) for the clients.

Because of this, handshakes have a special API which makes them able to alert the program to wait until a certain moment to retransmit the packets they'd want to send.

However, the 6th flight could get lost, either the CCS or the Finished packet, which means the client can get in a deadlock, see the following passage from [RFC6347];

   In addition, for at least twice the default MSL defined for [TCP],
   when in the FINISHED state, the node that transmits the last flight
   (the server in an ordinary handshake or the client in a resumed
   handshake) MUST respond to a retransmit of the peer's last flight
   with a retransmit of the last flight.  This avoids deadlock
   conditions if the last flight gets lost.

However, this would block the server handshaker from transitioning into a connection object until the client has sent any application data.

It would be more "correct" to wait until a client sends data, but depending on the application, the server might want to immediately start to send data.

This could be especially problematic with resuming sessions, or #9, which might require this kind of "last state" to be certain before either side starts sending buffered data again.

For now, I think it's more clean to wait for application data, but in the future I could add a "server handshaker mode" which immediately transitions to a connection object after finishing the last flight, but keeps it sealed and keeps it ready to be sent if the client were to send flight 5 again, this would be a ton of extra logic to keep, though.

#13 gave requirement for something like Connection objects to become fall-through, however, i don't think this works well with the black-box approach.

Furthermore, together with #10, I'd like to make something reusable and generic, so i'll settle with a set of traits, and an object/trait;

• DIO, "Datagram In Out", would also immediately standardise a Datagram IO. This'll only be on connection objects for now, but i could possibly look if i can implement this for things like UdpSocket. This is only currently meant to signal "upwards" IO, inputs to this will go up an abstraction layer, outputs will go down towards more physical layers.
• SelectiveDIO, basically DIO, but can reject a packet.
• DeMux, i'm not entirely sure if this'll be an object or a trait, but effectively this'll store many SelectiveDIO objects, and try each one in sequence until one of them accepts. This way, a connection object (wrapped in a dynamic selector), or a SRTP sink/buffer, can be multiplexed over the same "path" that a router would select such an object for.

I don't know how well this would work/clash with #9, as partially this is also supposed to solve that bit, where multiple connections can exist over the same peering, but this could be a generic enough solution for now.

For #13, this could be implemented by providing a selector which only checks on the following; 127 < B < 192: forward to RTP Checking the first byte, and moving on if it doesn't match.

Possibly, in the future, this could allow for a QUIC+DTLS dual endpoint and router.

The WebRTC spec defines some requirements for the used DTLS implementation:

At least the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite needs to be supported with support for the P-256. Both of these requirements are met in rustls (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 & P-256).

Firefox additionally has support for P-384 and x25519 as well as TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256. Chrome adds TLS_RSA_WITH_AES_128_GCM_SHA256 on top. Except the added one of chrome all are supported by rustls, so this is fine. Both Chrome and Firefox also have support for CBC ones, but I guess we can ignore them (at least for now).

Furthermore, "Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered." So I guess It would be nice if dtls-rs could allow to configure in which cases an alert should be created in addition to allow configuring stuff like renegotiation.

The spec has some more API requirements I will not copy here. Could you have a look at them too?