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

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/