Re: Signing HTTP (Was: New Version Notification for draft-thomson-http-encryption-00.txt)

On Tue, May 12, 2015 at 04:38:06PM -0700, Martin Thomson wrote:
> On 11 May 2015 at 22:06, Willy Tarreau <w@1wt.eu> wrote:
> > I can predict that you'll get requests for encrypting or at least signing
> > *some* header fields because these people had to do that when facing the
> > same use cases :-)
> 
> Predictions aren't of much value when the event they predict has
> already happened.  I believe that this request arose even before -00
> of the -nottingham- draft was published.

Certainly, years ago I was involved in defining a signature system for
some authenticating proxies, and this need for a signature was the natural
result of transfering data in cleartext, which is why I expect that others
doing the same came to the same conclusion.

> The signing scheme in [1] is definitely a candidate here.

I didn't know this one, yes indeed. Thanks for the link.

> But I think
> that it attempts to resolve what is a fundamental dichotomy in the
> protocol: intermediaries can and do change header fields and we can't
> predict which.

Yes and that's *why* you want signatures in the first place. It's not
only to protect against attacks but also offer guarantees of integrity
over a long chain. That becomes important when you imagine that a bug
in an intermediary can cost millions and you need to know who has to
indemnify the other party! Better reject the request or response than
let it pass through. So in practice, the application knows what fields
are important (in general most of them begin with "X-") and signs them.

> I'm starting to think that the approach we adopted for encryption
> applies equally well here.  Namely, protect the body, leave the
> headers.

For signature alone, it's harder to limit the processing to the body
because in some environments you can (and sometimes want) to have each
intermediary validate the signatures for logging purposes (in fact you
add "signature ok" in each log so that you quickly know where the
contents were tampered).

> I understand that this exposes certain use cases to replay
> attacks, but I don't think that's an insurmountable problem.

Replay attacks are reasonably easy to deal with using timestamping and
sequence numbers once the fields in question are signed.

> The acme
> protocol spec seems to get by with just signatures over content.

I fact what describes the content often needs to be signed, as well
as what describes the source or the destination of the contents. For
example in some environments, a content-type might have a high enough
importance for data interpretation to be signed. The URI as well, or
an application ID. In fact many messages can be important without
transporting any body. An example is the logout request on some
applications. You want to ensure the user is really logged off, from
the expected application, regardless of any body.

> The biggest challenge I see here relates more to the mechanisms we
> employ.  I would like to have a signature appear after the content,
> but know that trailers are basically unusable for this purpose.  Does
> it make sense to make signatures a content transformation in the same
> way that other content-codings are?  Precomputing a signature to fill
> a header field might be frustrating for performance.

I think that signature of the body can reasonably be appended to the
body itself. If we consider that some entity headers move to the body
during the encryption operation, they can be part of the whole signature
as well. However, keep in mind that a HEAD request or a GET returning a
304 will carry no body. In this case they should return the same headers
as the equivalent GET request with an encrypted&signed body, and that
*could* be OK. But this needs to be handled with care. And some GET
requests will have to transport a signature for some headers, but the
proposal you linked to [1] should take care of this.

Willy

> [1] https://tools.ietf.org/html/draft-cavage-http-signatures-04

Received on Wednesday, 13 May 2015 05:04:20 UTC