default max stream limit should be finite for security reasons

[grmocg]

One of the interesting attack vectors against HTTP2 is to successfully allow a client to begin a session with a website, then attempt to probe its compression context by forging acks (to ensure the TCP send window continues to be open), by having javascript (or equivalent) emit links to the DOM linking to the site whose cookie/secret in the compression context is going to attack and thus causing the browser to continue to emit TLS records which the attacker then black-holes, though it observes the size of the packets).

This is particularly fun because it provides the server little/no information that it is occurring.

By limiting the number of concurrent streams, however, this attack can be greatly slowed and be forced to be visible-- since no data is sent until the TLS handshake completes, the server which has the certificate needs to be contacted if the attacker wishes to continue to press the attack. This implies that that server is given at least that signal, and it also implies that the attacker must wait for this to succeed before continuing to attack.

[martinthomson]

This is mitigation for #373.

[mnot]

Discussed in London; closing with no action.

[grmocg]

This proposal has no merit and would be ineffectual, since an attacker could cancel requests, causing the streams to be reset, and thus the limit is useless.