Re: [Last-Call] Last Call: <draft-ietf-httpbis-message-signatures-16.txt> (HTTP Message Signatures) to Proposed Standard

On Feb 17, 2023, at 6:24 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
> 
> On Fri, Feb 17, 2023 at 12:45 PM Justin Richer <jricher@mit.edu> wrote:
>> 
>> Mark, thanks for forwarding this message along. I’m CC’ing Watson Ladd on my reply here in case they’re not in the WG.
>> 
>> 
>> The issue of key and algorithm substitution attacks, particularly the JOSE-based attack mentioned here and discussed in section 7.3.6 of draft -15, are neither unknown to nor ignored by the authors of this draft.
>> In particular, while the predecessors to this draft repeated JOSE’s
> approach of always including the algorithm definition in the message
> and using that signal alone as the algorithm selector, this draft does
> have the same requirement. While it’s possible to signal the algorithm
> in the message itself, that signal is just one input into the
> algorithm selection process, and not the only one that needs to align
> for a proper validation of the signature.
> 
> Making the right thing an option is always inferior to making the
> right thing inevitable. Why can't we delete the indication from the
> message so that an implementer must look at the verification key or
> information provided alongside it to verify, without us having to
> specify a single word?

The “right thing” in this case is “don’t naively apply algorithm selectors”, and in my opinion it doesn’t really matter if those selectors are included in the message or in the key material. If you’re willing to apply the wrong key material or the wrong algorithm based on that key, then you’ve got really big problems.

I agree with you that specifying an algorithm at runtime can pose problems in some circumstances — that’s well-documented, and again the JOSE world is known and well understood by the authors here. But I also believe that there are reasonable reasons to have a runtime switch for a given application. For example, what about protocols where the keys are presented in a TOFU model? The first time the verifier sees a signature is also the first time the verifier sees a key. In these cases, the application just needs to make sure that the whole of the request — including any algorithm indicated in either the key material or the message itself — is appropriate for the application.

> 
>> 
>> I’ve taken the opportunity to go back and do a closer reading of the algorithm-selection portions of the draft, and I believe that we can in fact be clearer about this. In particular, the intent was always that an application of message signatures define the set of allowable algorithms (and key parameters) that should be accepted. The “alg” flag, derivation from the key material, and other methods of runtime determination are intended to choose from that allowable set. I’ve put together a PR that now says that explicitly:
>> 
>> https://github.com/httpwg/http-extensions/pull/2409

>> 
>> Will this language completely prevent naive implementations? Of course not, but I do believe that the lessons from JOSE are taken to heart here and implementations of this draft are much more likely to do the right and secure thing.
> 
> I think you overestimate the degree to which people with experience
> are tasked to implement these protocols or the diffusion of this
> information.
> 
> As for the change I think this language is actually *worse* than the
> preceding one. Rather than say "every key shall be used with one
> algorithm", it invites the application to say a set and imposes no
> rules on what sets are allowed, which could fatally include HMAC and
> ECDSA, or HMAC and RSA, etc. Is the reasoning here that we need to
> support all possible RSA signature parameters?  In fact any time the
> set is not very carefully picked (usually one element) we have a
> problem.

There are reasonable applications that use these combinations in different contexts, and an application choosing to do so really needs to have its reasons for choosing the set of allowable algorithms and how to map those to the keys in use.

Saying the algorithm is “specified in the key” doesn’t solve the selection problem, it just defers it to another layer. In the JOSE world, you can have a JWK without an “alg” parameter, and if the parameter is included, it’s not signed with the key. Or you can have a key specify an algorithm without specifying all of the parameters for that algorithm, in several key formats. For example, we all know that it’s not enough to just say “use RSA-PSS” without specifying the MFG and other portions — and yet that’s exactly what some systems out there do, picking some set of platform-specific defaults in the crypto library.

> 
> Again, all this could be avoided by not indicating in the message what
> algorithm is to be used to verify.

That is not really the case, since an application could easily choose some other method to indicate the algorithm with even worse security properties than a parameter that’s at least guaranteed to be covered by the signature.

We are at least giving people a chance to do the right thing instead of leaving the right thing to chance.

The explicit algorithms inside the spec do two things:

 - They provide a set of usable algorithms with well-defined paremters
 - They provide an example for how to apply other algorithms to the spec (including what not to leave underspecified)

In the end, I believe that the specification makes the right balance between allowing a variety of use cases and giving people the tools and examples to make the right decisions. We are giving the people who need this option the option, and providing guidance about how to use it well, and why it can’t be the only thing that they use.

> 
> Sincerely,
> Watson
> 
> -- 
> Astra mortemque praestare gradatim

Thank you,
 — Justin

Received on Thursday, 23 February 2023 19:32:34 UTC