search

w3c-ccg / http-signatures

Signing HTTP Messages specification
https://w3c-dvcg.github.io/http-signatures/
Other
34 stars 9 forks source link

Consider removing the `headers` field to the `Signed-Headers` header field. #80

Open ioggstream opened 5 years ago

ioggstream commented 5 years ago

Suggestion

To take into account of the following Security-Consideration https://tools.ietf.org/html/draft-ietf-httpbis-semantics-04#section-12.5 about header field length

We could move the headers content to a Signed-Headers header field.

aljones15 commented 5 years ago

I actually think taken the growing number of pseudo headers (such as (expired) and (created)) the headers parameter could be renamed to something like Signature-Parameters to better express the variability of where the components for the signature can come from. Regardless this type of attack should be noted in the spec and a factor in the signature creation algorithm.

liamdennehy commented 5 years ago

I'm not sure how moving these parameters to a new header addresses the problem?

For me a single header capturing a single statement - the signature and how to validate it - has real power. We should always keep brevity in mind, but bearer tokens routinely go into hundreds of bytes, and some interfaces even ask for entire RSA PKI certificates in a header - kilobytes in size.

ioggstream commented 5 years ago

@liamdennehy moving this out will reduce the Signature size for long headers and improves security as we're explicitly signing the headers using the same mechanism we use for the rest.

liamdennehy commented 5 years ago

A 4096-bit RSA key will generate a signature (base64-encoded) of just under 400 bytes, and the various header parameters we've proposed so far add maybe a hundred bytes with lots of headers. EC keys are much shorter.

I think my basic question is: How long is too long? As in an actual number, what is the cutoff, and are we talking individual headers or the entire header set? Note that adding a new header name actually increases the overall header set size simply by being its own instance.

This would also cut off the possibility to attach multiple signatures (which would at least use a different keyId, if not the entire set of parameters) without further semantics. 12.5 suggests there are minimums that a recipient should support (then never refers to or states the minimums), but not a maximum.

I'm just not seeing the benefit without specifics: the risks 12.5 discusses are more about exploits abusing recipients than standardised implementations being too cumbersome, and we've yet to see an implementer that cannot do use this protocol because we're hitting a particular limit.

liamdennehy commented 5 years ago

we're explicitly signing the headers using the same mechanism we use for the rest.

I mentioned elsewhere I want to overhaul parameters, specifically to allow us to flexibly add/sign things without having to revise the entire specification to address your point here: https://github.com/w3c-dvcg/http-signatures/pull/51#issuecomment-494472655

This will need a large consensus as it's a big and breaking change, but I still think it is worthwhile.