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

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.

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

Received on Tuesday, 12 May 2015 23:38:33 UTC