Clearly specify how to optionally defend against slow-retrieval attacks

[trishankatdatadog]

Following up on #111: on second thought and some discussion, I think that we should reinstate slow-retrieval attacks in the spec, but only if we make it optional (because not everyone has control over their network stacks), and make it clear how to do so (e.g., moving average download speed must be X bytes/sec).

What do others think?

[jku]

Call me cynical but I'm doubtful that generic defenses work in practice here -- one persons flaky mobile connection is another persons slow retrieval attack.

I think the ideas are worth exploring but the bar for the example implementation should be set rather high: it should be shown that the defense actually protects against an attack type (and not just a carefully selected specific attack) and does not have a major negative effect on other use cases.

[trishankatdatadog]

Good observation. So even if we make it an optional defense, we should also state that any reaction to take is also up to the implementation (e.g., don't need to bail immediately, but perhaps tolerate a few more failures until it is no longer tolerable).

[joshuagl]

Source of inspiration might be curl's -Y, --speed-limit and -y --speed-time options which cause curl to stop the download if the transfer rate is not at least bytes per in bytes per second.

As the options are complementary, they have defaults if one is specified without specifying the other. Those defaults are speed-time 30 seconds and speed-limit 1 byte.