RE: Composing signing and encryption

Not my primary field, and I’ve missed obvious things in this space before, so please educate me if I’m missing a major hole here.

If you receive the MAC from the origin on an authenticated connection, then even if someone holds the key to the data, they can’t modify it without invalidating the MAC.  Doesn’t the OOB C-E fundamentally assume that the headers are those sent by an origin, while the body is the retrieved (and presumably encrypted) payload?  If so, wouldn’t it be sufficient for the origin to provide the MAC in the (already authenticated) headers?  For large payloads, you’d want to be able to authenticate those as you stream, though, which could make size a problem as you’d want to MAC each chunk.

A simple approach to this would be a content encoding that provides something like:

{ Chunk count; Chunk 1 MAC; Chunk 1 data (inner encoding); Chunk 2 MAC; Chunk 2 data (inner encoding); … }

The inner encoding could be out-of-band, in which case the client makes a slew of requests (presumably over HTTP/2) to retrieve the chunks it cares about, and then checks the MAC of each chunk.  Or it could be something else, in which case you’re just downloading the resource as normal with integrity.  Resources where streaming isn’t an issue for whatever reason have a single chunk with a MAC of the whole thing.  You could even do some neat things with the split if you allowed different chunks to use different inner encodings, like putting the thumbnail or low-res version in an in-band encoding and the larger high-res portion out-of-band.

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?

From: nygren@gmail.com [mailto:nygren@gmail.com] On Behalf Of Erik Nygren
Sent: Tuesday, May 3, 2016 7:48 AM
To: Mark Nottingham <mnot@mnot.net>
Cc: Martin Thomson <martin.thomson@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org>; Eric Rescorla <ekr@rtfm.com>
Subject: Re: Composing signing and encryption

On Tue, May 3, 2016 at 2:39 AM, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:
It sounds like you think we can continue the encrypted and streaming integrity content codings as separate work items (assuming we adopt MICE or something like it, and provided that all signature functionality is removed), perhaps including some text about the possible dangers of using encryption in combination with signatures in Security Considerations of the former.

Future use cases that required signatures and encryption could be invented as new content codings, or composed (carefully) with them.

It seems like there are a few dimensions and compositions here.
Distribution use-cases seem to fall into 1:1 and 1:many scenarios.
Key exchange use-cases seem to fall into out-of-band vs asymmetric.
In all of these we presumably want both integrity and in some cases privacy.
Full object decryption/validation vs streaming decryption/validation is another dimension
where large objects likely require the latter.

1) In the 1:1 scenario with oob key exchange, it seems like encryption with AEAD gives you everything you need for privacy and integrity?

2) In the 1:many scenario with oob key exchange (eg, file sharing and blind caching) it seems like we always need something to provide integrity (ideally streaming content integrity such as MICE, or at least a full content MAC such as in SRI but that limits applicability), plus encryption (which can be AEAD but we may not get much from it?).  Presumably if the content is also encrypted we should be doing encrypt-then-MAC?  My big concern here is that since the "many" has the encryption key (even with asymmetric key exchange) then anyone recipient or cache can trivially alter the data.
I haven't thought as much about the asymmetric key-exchange scenarios or how necessary they are for the complexity they add?
So while it may make sense to drop the asymmetric key-exchange, I feel the subtleties of encrypted-content-encoding for the 1:many scenario resulting in a lack of integrity protections is going to be dangerous and lost on folks.  As such, I'd much prefer to see something like MICE folded into encrypted-content-encoding or specified alongside it with clear cross-references on how to safely compose them  (encrypt-then-MAC, or just-MAC with supported cipher+mac combos?)

     Erik