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

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?

>
> 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.

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

Sincerely,
Watson

-- 
Astra mortemque praestare gradatim

Received on Friday, 17 February 2023 23:24:48 UTC