Cryptography Reference
In-Depth Information
Still, it seems a shame that every datagram-based protocol must invent its
own means of securing its traffi c, doesn't it?
TLS Without TCP — Datagram TLS
In 2006, Nagendra Modadugu and Eric Rescorla drafted the Datagram TLS
( DTLS ) specifi cation ( http://crypto.stanford.edu/~nagendra/papers/dtls
.pdf ). Although you can't apply TLS directly to datagram traffi c, the number
of changes required to support it are surprisingly small. Whereas TLS's top-
level encapsulating header includes just type, version and length, DTLS adds
two fi elds:
Epoch: This fi eld increments whenever it receives a change cipher spec
handshake message. This way, if the change cipher spec itself is lost,
the server recognizes that the epoch has changed and knows something
has gone wrong. Recognizing a dropped change cipher spec message is
particularly important because that's the signal to start using encryption
(or, in the case of a session renegotiation, to use new keying material).
Sequence number: The purpose of this is obvious — to recognize dropped
or out-of-order packets. TCP has one of these, too.
What about leftover cipher state? Prior to TLS 1.1, CBC-based ciphers used
the last encrypted block as the IV for the next block — if one record is dropped,
every subsequent record is undecryptable. TCP guards against this by providing
automatic replay of dropped packets, but UDP has no such provision. Rather
than require it, which would essentially force UDP to behave exactly like TCP
in order to achieve any security, DTLS doesn't allow implicit IV's. They're a
security hole anyway, so IV's are always output explicitly, TLS 1.1+ style. This
also means that RC4, which carries state from one byte to the next, cannot be
used with DTLS in any form; there's no safe way to explicitly output the current
state of an RC4 cipher.
Interestingly, DTLS also requires that the client submit the ClientHello mes-
sage twice. The fi rst time, the server responds with a challenge “cookie” that
the client must repeat in the second ClientHello. This proves that the client is
actually receiving UDP packets at the given IP address and was designed to
prevent denial of service ( DOS ) attacks.
From the implementer's perspective, the most diffi cult part of DTLS is the
timeout and retransmit algorithm. Very similar to the one used by TCP, DTLS
mandates a timeout and retransmit procedure with a sliding window. In fact,
in a lot of ways, DTLS forces a UDP connection to behave like a TCP connection
behaves. It hasn't yet been fully explored just how much overhead DTLS adds
to a datagram connection and whether the extra overhead is worth DTLS or if
the user might be better off just using TSL over TCP instead.
Search WWH ::




Custom Search