Re: Composing signing and encryption

[Mark Nottingham <[e-mail]>]

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 <[e-mail]> 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/