Composing signing and encryption

[Martin Thomson <[e-mail]>]

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.