Is tuf.download immune to the endless data attack? about python-tuf HOT 4 CLOSED

It likely isn't. Let's address it.

from python-tuf.

TKK: Since you are currently working on modules related to this, you would be the ideal person to scrutinize/test the implementation for this attack.
Excluding code from the test and interposition modules, we only read data from a remote source in 'download.py'. We make a urllib2 connection to retrieve metadata and target files.
https://github.com/akonst/tuf/blob/master/tuf/download.py#L198
I believe we are vulnerable to a slow retrieval attack in 'download.py'. This is difficult to solve or protect against without a tradeoff.

Resources:
http://docs.python.org/2/library/urllib2.html#urllib2.urlopen
http://www.velocityreviews.com/forums/t720616-urllib2-urlopen-and-read-difference.html

from python-tuf.

Let me discuss this with Justin tomorrow; I have an idea that might work.

from python-tuf.

Fixed with the recent refactoring changes to the downloaded and updater modules, which will be in at least a1132af and onwards.

from python-tuf.