2

From what I understand, when using DTLS, the TLS handshake is made reliable, but the transport of application data is not.

I'm looking at a PCAP from the DTLS section of the Wireshark site. The cipher TLS_RSA_WITH_AES_256_CBC_SHA was chosen.

Now when using CBC, the decryption of a message is dependent on the successful receipt of the previous message. However, given that DTLS does not reliably transport application data, it seems this would break the stream if a packet were lost.

So, is there something I missing? Can CBC work when using DTLS (over UDP), or should another cipher be chosen?

veganjay
  • 21
  • 1
  • DTLS 1.0 and 1.2 correspond to (non-D) TLS 1.1 (yes, not the same number) and 1.2 which have CBC IV explicit, because the chaining used in 1.0 and SSL 3 allowed attacks most famously BEAST; see RFCs 4346 5246 4347 6347. OTOH RC4 (the only nonAEAD-requires-1.2 and nonCBC cipher) does depend on all previous messages and was already unsupported in DTLS even before RC4 was deleted everywhere for algorithm-specific brokenness. – dave_thompson_085 Aug 26 '16 at 14:01
  • just because udp itself doesn't provide retry doesn't mean other protocols on the stack don't... – dandavis Aug 26 '16 at 22:16

1 Answers1

2

The paper http://crypto.stanford.edu/~nagendra/papers/dtls.pdf describes how DTLS explicitly implements sequence numbers, and uses explicit IV, so ciphers normal TLS CBC are supported.

Jonah Benton
  • 3,359
  • 12
  • 20
  • 1
    Thanks for the link. I see how replay attacks are addressed, but it's not clear how dropped packets are addressed. For example, in Figure 3, if message C2 is lost in the network (UDP is not reliable), the message C3 will not be decryptable. – veganjay Aug 26 '16 at 14:32
  • 1
    My read is that the implementation of CBC in TLS 1.1 and above and DTLS is that the use of random IVs, rather than prior state, allows each DTLS block to be independently decrypted. – Jonah Benton Aug 27 '16 at 12:21