DTLS RFC6347 4.2.8 compliance

[hnrkp]

Hi,

I've been putting the DTLS preview to work and have found it to be working generally well. But it seems that mbedtls isn't really compliant with RFC6347 4.2.8 (yet?):

"4.2.8. Establishing New Associations with Existing Parameters

If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is possible that a client will silently abandon one connection and then initiate another with the same parameters (e.g., after a reboot). This will appear to the server as a new handshake with epoch=0. In cases where a server believes it has an existing association on a given host/port quartet and it receives an epoch=0 ClientHello, it SHOULD proceed with a new handshake but MUST NOT destroy the existing association until the client has demonstrated reachability either by completing a cookie exchange or by completing a complete handshake including delivering a verifiable Finished message. After a correct Finished message is received, the server MUST abandon the previous association to avoid confusion between two valid associations with overlapping epochs. The reachability requirement prevents off-path/blind attackers from destroying associations merely by sending forged ClientHellos."

It seems that new ClientHellos are now dropped (and no error returned), which was unexpected.

[mpg]

Your observation is correct: new ClientHellos are silently dropped, just as any other record that has an epoch from the past.

To the best of my knowledge, 1.4-preview and the upcoming 2.0 do comply with every single MUST and MUST NOT requirements form the RFC, but some SHOULDs are not implemented yet, and section 4.2.8 is one of them.

It is on our roadmap and will hopefully be in the 2.1 release. However, it's not entirely clear to me yet how the API for that should look like. I don't think it would be correct to silently establish a new association without letting the application layer know. Do you have an idea how you would like the API to be?

[mpg]

PS: I'm thinking the right place to handle that might very well be below the SSL layer. That is, instead of using UDP sockets in connected mode, do explicit demultiplexing (also based on the quadruplet), and then during the demultiplexing peek at the first bytes to see if the datagram looks like an epoch=0 ClientHello, and if it does treat it as a new incoming connection.

[hnrkp]

Well, I haven't spent that much time thinking about it and it's not really obvious what would be most intuitive.. I agree that establishing a new association in place of the old one not letting the application layer know would be less than ideal (and would not really work in any sane real world scenarios?), so the best thing for an easy fix would be to (if supported) send the HelloVerifyRequest and if it gets back OK then abandon the current association.

I guess the rest depends on how you use mbedtls, in what environment.. But yes, for DTLS it would make sense to not use connected mode UDP sockets and pipe all incoming packets into one layer before SSL and let that layer demux and drive data to the correct associations (or establish new ones). The trick would be to separate the association(s), but I guess that doing that by epoch wouldn't be too ugly?

And if all my wishes come true, also have the possibility to feed data into mbedtls and get callbacks when decrypted data is received instead of having to do ssl_read(). :)

[mpg]

Just to confirm that implementing this "SHOULD" has been added to our roadmap, and we'll try to get to it in the coming weeks.

Regarding more support for event-based I/O using callbacks, we heard you and will consider it.

[mpg]

@hnrkp I believe this was fix almost two years ago by Mbed TLS 2.1.1: see the ChangeLog entry, so I'm closing this ticket. Please feel free to reopen if I'm mistaken.