Subject: Re: Composing signing and encryption

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 May 2016 16:39:39 +1000

Thanks, Martin.

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.

Is that correct, and if so, what do others think? Specifically CC:ing EKR here, as he brought this up in B-A.

Cheers,

> On 29 Apr 2016, at 11:20 AM, Martin Thomson <[email-masked]> wrote:
> 
> I've been looking into the issue ekr raised during the last
> meeting with respect to the risks involved with combining signing
> and encryption.
> 
> (tl;dr I don't think we need signing and I will drop it.)
> 
> A lot of the material concentrates on a messaging case, where a
> message is signed by the sender and encrypted toward the
> recipient.  For that scenario, composition isn't safe.
> 
> The property that is expected, namely that a message is sent from
> a particular sender to a particular recipient, is not provided by
> a simple composition of signing and encryption.  What is provided
> is *separate* statements of origin and destination.  An attacker
> can exploit this separation by replacing the outer layer with
> their own.  Depending on which is applied first, that allows the
> attacker to switch out their own origin or destination.
> 
> For messaging, a range of simple fixes are available, including
> the simple remedy of adding addressing information to the
> plaintext of the message and checking that it is correct.  Other
> techniques bind the signature to the encryption or vice versa.
> Personally, given what I know of other attempts to combine
> cryptographic primitives, I've concluded that a unified primitive
> that combines signing and encryption safely is a better way to
> solve the messaging problem.  Such a primitive could be properly
> and thoroughly analyzed by cryptographers.
> 
> But that's messaging.
> 
> The use cases currently identified for encryption and signing in
> HTTP don't have the same profile.  For the most part HTTPS is
> sufficient to address all of our direct 1-to-1 messaging
> scenarios.  Also critical here, I really don't want to create
> the impression that work on encryption is intended as a
> replacement for HTTPS.
> 
> However, based on my analysis, it appears as though the need for
> signing is not acute.  I am going to propose that we defer
> working on signing and will remove the (frankly) superficial
> treatment in the next revision of my -mice draft.
> 
> We could attempt to address the composition issue with some very
> careful security considerations.  I even drafted some up last
> week.  On balance, I would rather avoid any risk that we create
> tools that will be very hard to use safely.
> 
> --
> 
> Here is my more detailed analysis the use cases that I know
> about, for both signing and encryption:
> 
> ## Webpush
> 
> This is actually the scenario most alike messaging.  An
> application server places a message that is encrypted to a
> particular user agent on a push service.  The user agent later
> retrieves that message and decrypts it.  However, this use case
> does not use signing, just encryption, and a shared symmetric key
> is used with encryption to authenticate the origin of the
> message.
> 
> ## SRI
> 
> For sub-resource integrity, integrity is the only goal.  That
> might use signing, but composition with encryption isn't
> relevant.
> 
> ## File sharing
> 
> In this case, a file is encrypted and uploaded to a server before
> being shared.  Only clients with the URL and key can retrieve and
> decrypt the file.  In a sense, this file is encrypted toward
> multiple recipients.  It's conceivable here that the file could
> be signed as well as encrypted.
> 
> This is one case that would require great care before including
> signatures.  If the intent is to emulate a message from one
> entity to a specific set of recipients, then this could turn into
> the messaging problem.
> 
> ## Blind caching
> 
> Here we have an case that could use both signing and encryption,
> but in the course of doing this analysis, I discovered problems
> with these that are independent of the composition problems.
> Magnus Westerlund already identified an issue that is most
> problematic if we use signing.  Both problems are eliminated[*]
> if simple hash-based integrity plus encryption are used.
> 
> It's possible that for operational reasons, we will want to
> explore signing later.  And it's possible that it could be
> structured in a safe fashion.  There is no inherent assumptions
> around the relationship between encryption and message
> recipients, which might make using signatures for the purpose of
> integrity feasible if we determine that to be necessary.
> However, much more analysis would be needed to ensure that what
> we build is safe.  And we might want to build a far narrower
> solution if we take that option.
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Erik Nygren <[email-masked]>
Date: Tue, 3 May 2016 10:47:48 -0400

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 3 May 2016 17:40:06 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Nygren
Sent: Tuesday, May 3, 2016 7:48 AM
To: Mark Nottingham <[email-masked]>
Cc: Martin Thomson <[email-masked]>; HTTP Working Group <[email-masked]>; Eric Rescorla <[email-masked]>
Subject: Re: Composing signing and encryption

On Tue, May 3, 2016 at 2:39 AM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> 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.

Full object decryption/validation vs streaming decryption/validation is another dimension

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 May 2016 12:03:45 +1000

> AEAD gives you everything you need for privacy and integrity?

Pretty much, assuming that you do the oob key exchange properly.  Much
of the complication in WebPush (for example) arises from that.

> asymmetric key exchange) then anyone recipient or cache can trivially alter

That's the reason that you distribute a hash.  You can't modify
content if everyone expects a particular hash.

> I haven't thought as much about the asymmetric key-exchange scenarios or how
> necessary they are for the complexity they add?

For encryption, these are the bulk of the complexity, yes.  But I'd be
against removing it without stronger reasons.  Using symmetric keys
changes the dynamics of WebPush and will require re-evaluation of the
system: for instance, it means that anyone able to send a message is
also able to read any message.

> just-MAC with supported cipher+mac combos?)

I think that the parallel with block cipher modes is a misleading one.
Hash-based integrity and encryption can be applied in any order.

The problem that we're looking to avoid here is the one that arises
where identity is involved.  That is, there are problems when
endpoints make assumptions about identity based on the keys that are
used in messages, or assumptions about the binding of identities to
other things.

A simple integrity check avoids that morass.  It's only when you have
a signature that it gets complicated.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 May 2016 12:07:49 +1000

On 4 May 2016 at 03:40, Mike Bishop <[email-masked]> 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.