- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 4 May 2016 12:07:49 +1000
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: Erik Nygren <erik@nygren.org>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Eric Rescorla <ekr@rtfm.com>
On 4 May 2016 at 03:40, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > If I’m parsing MICE correctly, it functions somewhat similarly -- the MAC > for each chunk is embedded in the previous chunk, so you can validate the > chain has not been modified as long as you know the MAC of the first chunk > before you start. The MAC of the first chunk comes over the authenticated > connection to the origin, so an attacker can’t modify that, even if they > have the well-known key. I’m not clear how that exposes us to forged data, > even if the attacker has the key? Your analysis is correct. As long as the integrity check is authenticated, then the data can arrive in any way you like. My preference is to add integrity checks first, then encrypt. Then you can maintain the same integrity check for the resource even if you re-encipher. But it actually doesn't matter here. The order of the Content-Encoding header field allows us to express what the order is.
Received on Wednesday, 4 May 2016 02:08:17 UTC