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

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.

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.

— Justin

(Re-sending from the correct email account for the mailing list, apologies to anyone who got two copies of this.)

On Feb 7, 2023, at 5:04 PM, Mark Nottingham <mnot@mnot.net> wrote:

FYI

Begin forwarded message:

From: Watson Ladd <watsonbladd@gmail.com>
Subject: [Last-Call] Last Call: <draft-ietf-httpbis-message-signatures-16.txt> (HTTP Message Signatures) to Proposed Standard
Date: 7 February 2023 at 6:24:42 pm AEDT
To: last-call@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/KFdTYxe2kkMZswSfPyZgR9yQf_Y>

Dear all,

I believe this draft has substantial security issues that are similar
to ones that have been exploited unsafely, often and extremely well.

This draft equates public key signatures with Message authentication
codes. MACs depend on having a shared key that is secret, and anyone
who knows the key can make a signature. Public key signatures separate
a private and a public key, and those with the private key may sign,
those with the public key can verify.

These are different notions with different requirements on what the
material they are used on must have. But the draft uses exactly the
same container and the same language to refer to them, inviting that
same confusion in the mind of a reader, and the library author to
blithely permit the algorithm in the message to be used.

This mistake in JWT lead to bug after bug in library and application.
Now we learn nothing, and choose once again to invite disaster with a
small oversight on the part of application authors. No, security
considerations will not prevent this mistake, and the ones in the
draft are woefully inconsiderate: they do not clearly indicate who
must do what, or refer to the details of the past bugs to indicate why
it is required.

I believe we need a section to describe what libraries must do with
their interfaces to prevent such hazards and how application
developers must avoid them in system design. Instead we get that the
secure way is merely encouraged. This is not good enough: I believe
the signature spec should remove the algorithm entirely, letting the
key provided to verify indicate what is to be done. Or, if that isn't
possible use MUST language to indicate that the allowed signature
algorithm (singular) MUST be passed in with the key, that the verifier
MUST NOT look at the message to find the algorithm used.

This of course means revising 3.2 step 6 to remove looking at the message.

Sincerely,
Watson Ladd

--
Astra mortemque praestare gradatim

--
last-call mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call


--
Mark Nottingham   https://www.mnot.net/