Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00

[Joe Touch <[e-mail]>]

On 1/10/2011 11:38 AM, Fernando Gont wrote:
> Hi, Joe,
>
> On 10/01/2011 04:09 p.m., Joe Touch wrote:
>> IMO, this might be ready for experimental, but shouldn't go
>> standards-track unless it uses an algorithm for which we have
>> substantial experience.
>
> Yes, I'll be backing out SHA-256 and will go back to recommending MD5.
> -- As already noted on this list, this change was political rather than
> technical.
>
> So I assume that this would address your concern and you'd be game for
> std track, right?

The specification of the PRF needs to be more detailed. I.e., state how 
the hash is padded, byte order, and what portion of the output you're 
using (since MD5 hashes are too long).

>> 1) is this the most important change we want to make to TCP
>>
>>      as a WG, we ought to be discussing this for
>>      every standards-track change to TCP; we don't seem
>>      to be doing this as a plan
>
> huh? Why should this be "the most important change to TCP" for us to
> work on it?

This is a general question; we don't want to be spending cycles around 
the edges if we have bigger fish to fry.

>> 2) the discussion of how this doc changes 1948 needs to be included in
>> the core of the doc (Sec 2, IMO), and needs to be updated
>
> No problem with this -- what do others think?
>
>
>
>>      - this is a new algorithm, which, IMO, is experimental at best
>>      the alg proposed in Sec 2 is predictable for a given socket
>>      pair; that seems inconsistent with the security concerns that
>>      drive this doc
>
> Joe, this document is about mitigating blind attacks. If you know the
> socket pair, you can predict the ISN, unless you were able to see the
> ISN of a previous connection for that socket pair -- which is a
> completely different threat-model, that this document does not (and
> doesn't aim to) address.

If knowing the socket pair means you can predict the ISN, then this doc 
shouldn't be discussing the need for a random component or the time value.

I.e., your response above is inconsistent with a LOT of the discussion 
in this doc.

>>      - security concerns with MD5 need to be cited; the current
>>      note cites the definition of MD5 only; it's not clear
>>      they apply for unkeyed use as just a hash function
>
> The I-D cited by Lloyd will be referenced in the next revision.
>
>
>
>>      - the impact of guessing a sequence number should be discussed
>>      better; as per 4953, increasing window sizes and link speeds
>>      means that knowing ISN value isn't as important as it once was
>
> Guessing the ISN is still as important as it was when it comes to
> connection spoofing (note that most of the discussion is about
> connection spoofing and trust relationship exploitation).
>
> We could possibly add an informative reference to RFC 4953 for other
> sequence number issues.
>
>
>> 2) the impact of this doc on TIME_WAIT isn't sufficiently addressed
>>
>>      most machines simply don't keep TW around as long as they
>>      are required; they also sometimes use a single pseudo-random
>>      generator across all connections; this needs to be considered
>>      in more detail
>
> So now you care about running code? -- It's surprising that you're
> raising this, instead of declaring them as bugs and be done with it.

I'm concerned about the performance impact of declaring this a SHOULD.

> Anyway, this document is not about the TIME-WAIT state. And proper
> references are included where appropriate (e.g., the reference to the
> CPNI TCP security document)

If the result of this SHOULD impacts TW performance, then yes, it is 
about TW state.

>> 3) the doc should discuss how it can be implemented on a machine that
>> doesn't know absolute time
>>      even TCP's timestamps don't need to be absolute, but if a
>>      machine always boots the same way with the same info, it
>>      will reuse sequence numbers unless it has a persistent clock,
>>      coordinates time with another party, or has persistent state;
>>      none of these are necessarily true, e.g., for small devices
>
> C'mon, Joe: initialize that timer to a random value, and be done with it.

Stand-alone boxes don't necessarily understand 'random' - if they reboot 
and execute the same code in the same order, their 'random' is 
deterministic. You need to address that. This relates to the other 
concerns about some TCP mods that require state in home routers - it's a 
valid concern. You're declaring a SHOULD; you need to explain what you 
assume is available.

Joe

>> 4) where true authentication is noted as an alternative, TCP-AO should
>> be included, IMO
>
> No problem with this. Will do.
>
> Thanks,