Reinstate full protection against slow retrieval attacks

Description of issue or feature request:

#781 updated tuf’s downloader module to use requests instead of custom networking code, to fix issues with HTTPS proxies.

This change, however, deprived TUF of a way to prevent a certain kind of slow retrieval attack, where the attacker sends bytes below a minimum average speed.

This attack can not be prevented with the timeout parameters provided by requests, which are:

• connect timeout (max # of seconds to establish connection with server)
• read timeout (max # of seconds between bytes sent from the server)

Current behavior: Cannot reliably enforce minimal average download speed and thus is vulnerable to slow retrieval attacks.

Expected behavior: Reinstate full protection against slow retrieval attacks

Possible ways of fixing are

• report issue to requests and ask them to fix it, or
• switch to equally well-established and feature-rich requests-alternative that supports non-blocking I/O

Note: The comments in #781 have more ways of addressing this issue and also discuss whey they are not viable. Consider reading up on the discussion when working on this issue.

[SantiagoTorres]

Btw., (and this is more a note to the co-maintainer) I saw that none of the mentioned libraries work on Python 2.7. @SantiagoTorres, @trishankatdatadog, @JustinCappos how long do we still want to support a Python 2.7 client?

I think this is an artifact of async not existing on py2 (iirc). My ideal roadmap was to:

1. Provide library X as an optdepend
2. if exists, you get slow retrieval protection
3. if it doesn’t, then you get whatever is in place right now

I find this appealing because we can also allow people to fall back to the default implementation if they find things to be finnicky. Needless to say, this way we can also leave py2 out of the question.

[Urhengulas]

Hey @lukpueh, I would also love to work on it as part of GSOC2020. Currently finishing my proposal and going to send a post in Slack.