Subject: [core] Randomness in Tokens for anti-spoofing (#311)

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 May 2013 14:14:56 +0200

Experience with DNS shows that UDP-based protocols have to spend some effort protecting against spoofing ("Kaminsky attack").

Both Stephen's and Richard's IESG comments have pointed out that we don't really help implementers determine good sizes of the Token in order to provide anti-spoofing properties.

In response to this, the current editor draft [1361] says (penultimate paragraph of 5.3.1):

   A client sending a request without using transport layer security
   (Section 9) SHOULD use a non-trivial, randomized token to guard
   against spoofing of responses (Section 11.4).  This protective use of
   tokens is the reason they are allowed to be up to 8 bytes in size.
   The actual size of the random component to be used for the Token
   depends on the security requirements of the client and the level of
   threat posed by spoofing of responses.  A client that is connected to
   the general Internet SHOULD use at least 32 bits of randomness;
   keeping in mind that not being directly connected to the Internet is
   not necessarily sufficient protection against spoofing.  (Note that
   the Message ID adds little in protection as it is usually
   sequentially assigned, i.e. guessable, and can be circumvented by
   spoofing a separate response.)  Clients that want to optimize the
   Token length may further want to detect the level of ongoing attacks
   (e.g., by tallying recent Token mismatches in incoming messages) and
   adjust the Token length upwards appropriately.  [RFC4086] discusses
   randomness requirements for security.

The "at least 32 bits" may seem arbitrary.  My motivation:
-- The Kaminsky attack has shown that 16 bits is barely enough, even if suitably random;
-- Those who really need more than 32 bits should be using DTLS or are at least aware of their special security requirements (that's why we say "at least").
(One could argue that "at least 24 bits" or even "at least 24 to 32 bits" can also be defended on this basis.)

This is an actual technical change, even though it won't impact interoperability.
Before I close #311, I'd really like to hear feedback from the WG whether the choices here are sensible.

Grüße, Carsten