Subject: [TLS] Security consideration for DTLS: Adversarial packet loss/reordering

From: Matt McCutchen <[email-masked]>
Date: Thu, 10 Feb 2011 12:49:16 -0500

Here's an issue that might be worth adding as a security consideration
in the next version of the DTLS specification.  It may affect IPsec too;
I haven't looked into that.  Thoughts?

DTLS does not prevent an attacker from dropping or reordering records.
Datagram applications are generally designed to tolerate random packet
loss and reordering, but care must be taken to ensure that adversarial
loss and reordering cannot break the desired higher-level security
properties.  For example, one popular email client, when the user adds
an account, attempts to test whether the server accepts TLS connections
and configures the account to use TLS or plaintext connections
accordingly.  Of course, this setup process is vulnerable to downgrade
if an attacker can block the test TLS connection, so the user might
choose to perform it over a simple DTLS-based VPN that encapsulates each
IP packet in a DTLS record.  However, the attacker can still cause a
downgrade if he can determine which encrypted DTLS records carry the
test TLS connection and drop those records.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Feb 2011 11:31:55 -0800

> I haven't looked into that.  Thoughts?

I disagree with this suggestion, at least as it is proposed.

> properties.

That "care" sounds like it is care in the DTLS-using protocol, but no 
suggestion is given how such a protocol can show care. This makes the 
suggestion little more than "be careful", which is not useful.

> For example, one popular email client, when the user adds

The user has no control over this application, and there are no 
email-over-DTLS protocols, so this example doesn't make sense. Is there 
a better, real-world example that might be used here?

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Feb 2011 12:03:03 -0800

> suggestion little more than "be careful", which is not useful.

DTLS does deliver order information, of course. It just doesn't impose
reordering.

Perhaps the take-home for DTLS itself is that it would be nice if
packets came with
their sequence numbers attached.

-Ekr

> email-over-DTLS protocols, so this example doesn't make sense. Is there a
> better, real-world example that might be used here?
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Feb 2011 12:03:21 -0800

> their sequence numbers attached.

In the API, I mean.

-Ekr

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 10 Feb 2011 16:07:48 -0500

> suggestion little more than "be careful", which is not useful.

Maybe the wording can be improved.  The point is to make the designers
of DTLS-based protocols aware of the issue.  Its implications will, of
course, depend on the protocol.

For some protocols, adversarial loss may not be a big deal.  Other
protocols may need to take steps to ensure that important records are
received so that one side does not do something bad on the basis of not
having received them.  For tunneling protocols like my hypothetical VPN,
the possibility of adversarial loss becomes an important characteristic
of the resulting tunnel abstraction that may make it unsuitable for some
uses.  E.g., users often imagine a VPN connection to be the equivalent,
for as long as it stays up, of a direct wired connection that suffers
only random packet loss, but this may not be true.

> The user has no control over this application,

I don't follow.  If you're saying the user should configure the
application manually, I agree, but it's worth noting that such
applications exist.

> and there are no 
> email-over-DTLS protocols,

In the example, the IP packets of the (say) IMAP TLS connection are
tunneled inside DTLS records.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 10 Feb 2011 16:10:49 -0500

> >> loss and reordering cannot break the desired higher-level security
[...]
> their sequence numbers attached.

Good point.  Though, I mentioned reordering mainly for completeness; I
can't think of a realistic attack based on reordering.

-- 
Matt

---

From: Steven Bellovin <[email-masked]>
Date: Thu, 10 Feb 2011 19:51:08 -0500

>> their sequence numbers attached.
Given the importance of sequence numbers for IPsec, I very much agree.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb