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

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

On Tue, May 12, 2015 at 4:38 PM, Martin Thomson
<martin.thomson@gmail.com> 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.
>
> 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 Wednesday, 13 May 2015 00:24:43 UTC