Subject: [tcpm] Updating rfc6528

From: Loganaden Velvindron <[email-masked]>
Date: Sat, 28 Mar 2015 12:56:01 +0000

Dear All,

RFC6528 states that:

"3.  Proposed Initial Sequence Number Generation Algorithm

   TCP SHOULD generate its Initial Sequence Numbers with the expression:

      ISN = M + F(localip, localport, remoteip, remoteport, secretkey)

   where M is the 4 microsecond timer, and F() is a pseudorandom
   function (PRF) of the connection-id.  F() MUST NOT be computable from
   the outside, or an attacker could still guess at sequence numbers
   from the ISN used for some other connection.  The PRF could be
   implemented as a cryptographic hash of the concatenation of the
   connection-id and some secret data; MD5 [RFC1321] would be a good
   choice for the hash function."

However, there has been concerns about md5 as a hash function.

This has prompted Implementations like OpenBSD to switch to sha512,
since 2014. As there wasn't any major performance penalty, this has
been the default since then.

I would therefore like to update the RFC to reflect the running code
that we have:

"; SHA512[rfc6234] would be a good choice for the hash function".

We could then remove the section:

"

 It should be noted that while there have been concerns about the
   security properties of MD5 [RFC6151], the algorithm specified in this
   document simply aims at reducing the chances of an off-path attacker
   guessing the ISN of a new connection, and thus in our threat model it
   is not worth the effort for an attacker to try to learn the secret
   key.  Since MD5 is faster than other "stronger" alternatives, and is
   used in virtually all existing implementations of this algorithm, we
   consider that use of MD5 in the specified algorithm is acceptable.
   However, implementations should consider the trade-offs involved in
   using functions with stronger security properties, and employ them if
   it is deemed appropriate.

"

Feedback welcomed,
//Logan
C-x-C-c

-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

---

From: Joe Touch <[email-masked]>
Date: Sat, 28 Mar 2015 12:49:21 -0700

> However, there has been concerns about md5 as a hash function.

First, the RFC doesn't require MD5. It doesn't even recommend using a
cryptographic hash - that's stated as one possible approach.

Second, I'd like to see something more than "concerns about MD5".

MD5 isn't being used here as a MAC.

We should avoid "knee-jerk security". There's no justification for
endorsing a single approach here - diversity is is fine.

Until there's a security *justification* for endorsing a single
solution, IMO the current text is both sufficient and does not need to
be revised.

>    key.  ...

Absolutely not - it's still as valid for the case of SHA1. In neither
case is this being used as a MAC, so MAC strength analysis is simply not
relevant.

Joe

---

From: Loganaden Velvindron <[email-masked]>
Date: Sat, 28 Mar 2015 20:05:34 +0000

> endorsing a single approach here - diversity is is fine.

Sure, How about suggesting MD5 and also SHA512. Both of them have been
used in production implementations ?

I think that it's good that the RFC reflects the different choices
that have been used in different implementations.

---

From: Joe Touch <[email-masked]>
Date: Sat, 28 Mar 2015 13:27:57 -0700

> On Mar 28, 2015, at 1:05 PM, Loganaden Velvindron <[email-masked]> wrote:
> 

There is no need for an update at all. 

> that have been used in different implementations.

The RFC allows choice. Choices have been made. The choice is not important. The more examples you give the more it seems otherwise.