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

From: Martin Thomson <[email-masked]>
Date: Tue, 12 May 2015 16:38:06 -0700

On 11 May 2015 at 22:06, Willy Tarreau <[email-masked]> 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.

The signing scheme in [1] is definitely a candidate here. 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.

I'm starting to think that the approach we adopted for encryption
applies equally well here.  Namely, protect the body, leave the
headers.  I understand that this exposes certain use cases to replay
attacks, but I don't think that's an insurmountable problem.  The acme
protocol spec seems to get by with just signatures over content.

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.

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

---

From: James M Snell <[email-masked]>
Date: Tue, 12 May 2015 17:23:56 -0700

Just playing devil's advocate here: how would a content encoding be
any more beneficial than, say, using multipart/signed for this? If
we're talking only about signing the payload of the request, using a
multipart/signed would work, would it not?

- James

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 13 May 2015 07:03:44 +0200

> 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

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.

> 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

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.

> 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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 13 May 2015 06:09:39 +0000

--------
In message <CABkgnnUOCh=[email-masked]>
>protocol: intermediaries can and do change header fields and we can't

I think we should stick to the simple to understand principle that
if you want something to be end to end, you put it in the body and
you encrypt and sign it appropriately there.

Headers are just the envelope for delivery, and postmen may
and will scratch things out and add things on the envelope
to aid the delivery.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 13 May 2015 14:46:47 +0200

> protocol: intermediaries can and do change header fields and we can't

The fundamental dichotomy is that the spec mandates that intermediaries
piggy-back on http headers to communicate with web clients (auth…) but
https advocates want to cipher everything including those headers.

This can not work out.

No mater what scheme you choose, until you separate the proxy client com
from the server client com nothing will be resolved

Http2 would have been a golden opportunity to define separate hop by hop
frames and end the bickering once and for all.

-- 
Nicolas Mailhot

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 May 2015 12:29:31 -0500

On 12 May 2015 at 19:23, James M Snell <[email-masked]> wrote:
> If

Yep, that would be consistent with this view.