3

I have a UDP client application that is long-lived: Ideally, it keeps streaming to a server forever. I'm using Datagram Transport Layer Security (DTLS) to secure the UDP communication.

  1. How often does DTLS refresh the session keys established during handshake that are used to secure the record layer communication?
  2. Is re-handshake required to refresh the keys? Can this be done using another method?
Steven Volckaert
  • 1,193
  • 8
  • 15
cdev
  • 31
  • 3

1 Answers1

4

There is no notion of "key refresh", in either DTLS or even TLS, which would be independent of the handshake. If you want to refresh your keys for some reason, then you do so by requiring a new handshake. Both client and server can trigger a new handshake at any time (the client does so by sending a ClientHello, while the server sends an HelloRequest).

There are two types of keys in TLS (and DTLS):

  • The master secret is established through asymmetric cryptography (RSA, Diffie-Hellman) as part of a "full handshake".
  • The actual encryption and MAC keys are produced from the master secret and the "random values" sent by client and server. When a client and server do an "abbreviated handshake", a previously shared "master secret" is reused, but new encryption/MAC keys are produced.

There is no intrinsic reason in TLS or DTLS which would force a new handshake, except possibly running out of distinct sequence numbers; but since that number is a 64-bit counter, running out does not actually happen in practice (by a very long shot). Any specific application may wish to do a "refresh" at any time, and can do so by triggering a new handshake (abbreviated or full: an abbreviated handshake occurs only if both client and server agree to it).

It must be noted that there are very few rational reasons for "refreshing" the keys. People who do the refresh actually do so for the sake of formal compliance to regulatory requirements whose basis has been lost in the mists of Time (usually remnants of procedures which were needed for security with cryptosystems from before the invention of the computer). The unspoken myth at work in those cases is an assumption that keys somehow degrade upon usage, like bearings for a wheel, and must be replaced on a regular basis. This myth is, well, a myth, but a strong one, which still powers many standards and "best practice" documents.

(The one rational reason I have seen for a "refresh" was not about refreshing at all; it was a TLS server used in a context where the client also has a certificate, whose private key was in a smart card. The server regularly forced a new full handshake to make sure that the smart card was still there.)

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • 1
    Agree it's *probably* unneeded but: as you(!) answered in http://security.stackexchange.com/questions/30170/after-how-much-data-encryption-aes-256-we-should-change-key for CBC it's desirable though not vital to rekey at the birthday bound; AES $2^68$ is safely out of reach but 3DES $2^35$ is not. Also DTLS takes 16bits to count CCSs (= renegotiations) because datagrams could be reordered across them; the remaining 48bits is still big but not unthinkable: 100B records on a 10Gbps link could reach it in about a year. – dave_thompson_085 Jul 30 '14 at 06:54