We need to make a test for this issue. (This is where a client keeps a TCP connection open indefinitely but very slowly trickles data in. The reason for doing this is to cause the client updater to "pause" forever without updating.)

If this issue occurs in TUF, we should make a workaround for it. Stork handled this by looking at the rate which data was received and setting a lower bound. When the amount of data sent is below this rate, the connection is dropped.

from python-tuf.

@zhengyuyu is taking care of this.

from python-tuf.

Okay, merged @zhengyuyu's code in 63fa51a. There is still some work left to do (such as better detection by measuring time instead of counting only slow chunks), but this should be a good foundation.

from python-tuf.

@JustinCappos : Will you please review 01db53d?

from python-tuf.

Sure.

It will likely need another review after edits.

Justin

On Sun, Sep 8, 2013 at 12:33 AM, Trishank Karthik Kuppusamy <
[email protected]> wrote:

@JustinCappos https://github.com/JustinCappos : Will you please review
01db53d 01db53d?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-24014896
.

from python-tuf.

Two problems with 01db53d:

1. The cumulative moving average (CMA) of download speed is sensitive to the initial value. If the initial value is too low, we may unfairly punish a server with a slow start. If the initial value if too high, we may unfairly reward a server with a fast start.
2. We may be overestimating the "true" CMA of download speed because our sample window is too small (at most 8192 bytes --- and usually much less --- in every window of usually less than a second).

from python-tuf.

Can you explain more about what is wrong with just computing the average?

Justin

On Sun, Sep 8, 2013 at 12:32 PM, Trishank Karthik Kuppusamy <
[email protected]> wrote:

Two problems with 01db53dhttps://github.com/theupdateframework/tuf/commit/01db53d
:

1. The cumulative moving average (CMA) of download speed is sensitive
   to the initial value. If the initial value is too low, we may unfairly
   punish a server with a slow start. If the initial value if too high, we may
   unfairly reward a server with a fast start.
2. We may be overestimating the "true" CMA of download speed because
   our sample window is too small (at most 8192 bytes --- and usually much
   less --- in every window of usually less than a second).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-24024054
.

from python-tuf.

On 09/08/2013 12:50 PM, JustinCappos wrote:

Can you explain more about what is wrong with just computing the average?

Aren't we just computing the average here anyway? I am simply updating
the average over time as each new speed data point arrives; I think that
is all CMA really does. Whether we compute the average or something
else, the problems outlined previously would apply: the metric may be
hypersensitive to the initial value, and the sample window may be too
small leading to overestimation.

from python-tuf.

Okay, here is my confusion. We can compute an elapsed time and a number
of bytes transferred so far. Why do we need to start / stop times for
each point?

I would expect something like this:

substitute correct timing call for time.clock()

starttime = time.clock()

while True:
try:
recvbytes = recv(...)
except ...:
recvbytes = 0

totalbytesrecvd = totalbytesrecvd + recvbytes

elapsedtime = time.clock() - starttime

compute the amount of time we say elapsed, taking the grace period into

account so a slow server start doesn't cause an incorrect error
effectiveelapsedtime = elapsedtime - tuf.conf.SLOWRETRIEVALGRACEPERIOD

if we haven't wait long enough to judge (longer than the grace period),

continue
if effectiveelapsedtime <= 0:
continue

otherwise, we should check if the data rate is at least the rate

specified (default 8KBps)
if totalbytesrecvd / effectiveelapsedtime <
tuf.conf.SLOWRETRIEVALMINIMUMRATE:
raise tuf.SlowRetrievalError("Possible SlowRetrievalError detected.
The data rate for "+urlname+" averaged "+str(totalbytesrecvd /
effectiveelapsedtime)+" over "+str(elapsedtime)+" seconds. See
https://updateframework.com/.../SlowRetrievalAttack for more information.")

Am I oversimplifying this and missing something?

from python-tuf.

On 09/08/2013 01:11 PM, JustinCappos wrote:

Okay, here is my confusion. We can compute an elapsed time and a number
of bytes transferred so far. Why do we need to start / stop times for
each point?

I wanted something that is sensitive to how the download speed is doing
recently, not across all time. That is why I was taking the average of
"local" speeds. I thought this to be better; let me explain why in my
next point.

I would expect something like this:

substitute correct timing call for time.clock()

starttime = time.clock()

while True:
try:
recvbytes = recv(...)
except ...:
recvbytes = 0

totalbytesrecvd = totalbytesrecvd + recvbytes

elapsedtime = time.clock() - starttime

compute the amount of time we say elapsed, taking the grace period into

account so a slow server start doesn't cause an incorrect error
effectiveelapsedtime = elapsedtime - tuf.conf.SLOWRETRIEVALGRACEPERIOD

if we haven't wait long enough to judge (longer than the grace period),

continue
if effectiveelapsedtime <= 0:
continue

otherwise, we should check if the data rate is at least the rate

specified (default 8KBps)
if totalbytesrecvd / effectiveelapsedtime <
tuf.conf.SLOWRETRIEVALMINIMUMRATE:
raise tuf.SlowRetrievalError("Possible SlowRetrievalError detected.
The data rate for "+urlname+" averaged "+str(totalbytesrecvd /
effectiveelapsedtime)+" over "+str(elapsedtime)+" seconds. See
https://updateframework.com/.../SlowRetrievalAttack for more
information.")

Am I oversimplifying this and missing something?

Suppose the attacker has accumulated good "karma" and built a good
average by delivering everything pretty fast in the beginning. Then he
slowly trickles every delivery to a byte per second (or whatever the
socket timeout value is). How long would it take for the average
presented above to detect this?

from python-tuf.

If the attackers goal is to slow the connection down to take the maximum
time, couldn't they just do this from the start?

Why build up karma?

Justin

On Sun, Sep 8, 2013 at 1:22 PM, Trishank Karthik Kuppusamy <
[email protected]> wrote:

On 09/08/2013 01:11 PM, JustinCappos wrote:

Okay, here is my confusion. We can compute an elapsed time and a number
of bytes transferred so far. Why do we need to start / stop times for
each point?

I wanted something that is sensitive to how the download speed is doing
recently, not across all time. That is why I was taking the average of
"local" speeds. I thought this to be better; let me explain why in my
next point.

I would expect something like this:

substitute correct timing call for time.clock()

starttime = time.clock()

while True:
try:
recvbytes = recv(...)
except ...:
recvbytes = 0

totalbytesrecvd = totalbytesrecvd + recvbytes

elapsedtime = time.clock() - starttime

compute the amount of time we say elapsed, taking the grace period into

account so a slow server start doesn't cause an incorrect error
effectiveelapsedtime = elapsedtime - tuf.conf.SLOWRETRIEVALGRACEPERIOD

if we haven't wait long enough to judge (longer than the grace period),

continue
if effectiveelapsedtime <= 0:
continue

otherwise, we should check if the data rate is at least the rate

specified (default 8KBps)
if totalbytesrecvd / effectiveelapsedtime <
tuf.conf.SLOWRETRIEVALMINIMUMRATE:
raise tuf.SlowRetrievalError("Possible SlowRetrievalError detected.
The data rate for "+urlname+" averaged "+str(totalbytesrecvd /
effectiveelapsedtime)+" over "+str(elapsedtime)+" seconds. See
https://updateframework.com/.../SlowRetrievalAttack for more
information.")

Am I oversimplifying this and missing something?

Suppose the attacker has accumulated good "karma" and built a good
average by delivering everything pretty fast in the beginning. Then he
slowly trickles every delivery to a byte per second (or whatever the
socket timeout value is). How long would it take for the average
presented above to detect this?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-24024995
.

from python-tuf.

On 09/08/2013 01:24 PM, JustinCappos wrote:

If the attackers goal is to slow the connection down to take the maximum
time, couldn't they just do this from the start?

Why build up karma?

Would someone not try to deceive the slow retrieval detector? I would
worry about how an attacker trying to manipulate the slow retrieval
detector would do in the worst case.

from python-tuf.

Right. My point is that the worst case is to transfer at the minimum for
the entire time.

As I see it, "building up positive karma" means acting less malicious for a
while.

On Sun, Sep 8, 2013 at 1:36 PM, Trishank Karthik Kuppusamy <
[email protected]> wrote:

On 09/08/2013 01:24 PM, JustinCappos wrote:

If the attackers goal is to slow the connection down to take the maximum
time, couldn't they just do this from the start?

Why build up karma?

Would someone not try to deceive the slow retrieval detector? I would
worry about how an attacker trying to manipulate the slow retrieval
detector would do in the worst case.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-24025309
.

from python-tuf.

On 09/08/2013 01:41 PM, JustinCappos wrote:

Right. My point is that the worst case is to transfer at the minimum for
the entire time.

Aha, I see your point now. Even given a good karma start, you are not
worried about the time spent by the client downloading from a trickle
because eventually the average speed would drop and that's what you care
about: the average speed that is the total number of bytes received
divided by the total amount of time spent receiving those bytes.

Okay. My concern was with how long it would for us to take to discover
this drop in average speed. I see that you are not worried about how the
speed curve develops over the entire way; you are simply concerned about
maintaining the average speed. Yes, I think that should be good enough.

I will incorporate this when I am done preparing some of the security
tests of pip without and with TUF.

from python-tuf.