Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03

[Fernando Gont <[e-mail]>]

Hi, Mark,

>> (1) provides a scheme that
>> complies with such requirement 
> 
> Yep, it does.
> 
> But, (1) does not somehow uniquely address that requirement.

Agreed.


>> and that also has the good property that it makes it hard for an
>> off-path attacker to guess the timestamps in use by victim
>> connections.
> 
> The question is whether this is really important or not.

If the question is whether I think this is a vector that is currently
being exploited or that will be exploited in the near term, I fully
agree with you: I believe this is very unlikely.

However, 32 bits of additional "state information" doesn't look like a
big deal to me.  So my argument was (?) that would fail on the side of
unpredictable timestamps (i.e., this is so cheap....).  -- but please
see the end of this e-mail.



>>> Or, at least perhaps we could see more motivation for (1) that would
>>> sway us to understanding the tangible benefit it offers.
>> Using unpredictable values is acting pro-actively. If we, say, propose
[....]
> option to make it even harder to mess with the connection?  If you want
> to be so pro-active why are we not just saying every TCP connection
> should use the auth option?  Or, IPsec?  

I guess two possible answers would be:
* They are not a local policy, such as this algorithm (you do need the
other side to cooperate to get TCP-AO or IPsec working)
* They're hard to deploy for the general case, in practice.

(But yes, I see your point)



> So then, yeah, with timestamps you also have to pass the PAWS check on
> top of all that and so its even harder.  And, if you can somehow find an
> endhost's global clock then this reduces to the non-timestamp case.
> But, if you can't then you have some additional shot in the dark.  But,
> even without adding this additional variable I hope you can see my
> skepticism and thinking that this adds basically nothing tangible to the
> situation because the bar is already So Damn High.  

As mentioned above, I fully agree with you. For the most part, my take
is (was?) that the overhead needed for unpredictable timestamps is so
small that *I* would fail on the side of unpredictable timestamps.

That said, if we don't recommend the RFC1948-like scheme, one could
mention it as a "possible" approach ("MAY", or just an appendix with no
RFC2119 text... or well, completely remove it if the wg decides so). I'd
argue that the I-D should probably mention that if a global clock is
used, the initial value should be randomized at system boot time, so
that the system uptime is not leaked.



>> Actually, at least part of this discussion has already taken place:
>> there's a CERT advisory on predictable timestamps (I think I referenced
>> it in the I-D),
> 
> I can't find the reference in the I-D.  Can you provide it?  Perhaps
> they have more substantive motivation that you are providing.

It's "US-CERT Vulnerability Note VU#637934", available at:
https://www.kb.cert.org/vuls/id/637934 -- I realize that while it
discusses a timestamps-based vulnerability, it does not really discusses
predictable timestamps (sorry :-( ).

FWIW, re-reading this advisory caused me to re-analyze some of the
"timestamps randomization" stuff:

* While Section 4.2.2 of RFC1323 states some requirements for the
Timestamp Clock, receivers don't "enforce" these requirements. That is,
the timestamp will be considered valid if SEG.TSval >= TS.Recent. That
means that an attacker would need to try only two timestamps to guess a
"valid" one.
* So the timestamps don't really add much to the mitigation of off-path
attacks, and in that case, a global counter that is initialized at
system boot time with a random value would do.

(I guess that one could implement some type of "timestamps window", but
this *would* be unnecessarily complex. -- Just for curiosity sake, I'll
probably check the proposal that was made in 2005 (by Kacheong Poon?) to
use timestamps as a mitigation for off-path attacks, to figure out how
they used timestamps for this purpose).

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1