Re: Composing signing and encryption

On Tue, May 3, 2016 at 2:39 AM, Mark Nottingham <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