- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 4 Jan 2016 08:01:01 +1100
- To: Barry Leiba <barryleiba@computer.org>
- Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On 1 Jan 2016, at 3:38 am, Barry Leiba <barryleiba@computer.org> wrote: > Furthermore, if the connection to the alternative service fails or is > unresponsive, the client MAY fall back to using the origin or another > alternative service. Note, however, that this could be the basis of > a downgrade attack, thus losing any enhanced security properties of > the alternative service. If the connection to the alternative > service does not negotiate the expected protocol (for example, ALPN > fails to negotiate h2, or an Upgrade request to h2c is not accepted), > the connection to the alternative service MUST be considered to have > failed. > > I don't understand how this stops a downgrade attack if the alternative > service has better security than the existing connection. The attacker > prevents me from establishing the better security, so I consider the > alternative service to have failed and fall back to the existing > connection... and the attack has succeeded, blocking me from upgrading > the security. No? IIRC that last sentence is NOT being offered as a mitigation of the downgrade, but instead was something added later. Perhaps just some editorial rearranging would help here. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Sunday, 3 January 2016 21:01:30 UTC