Artart last call review of draft-ietf-httpbis-message-signatures-16

Reviewer: Harald Alvestrand
Review result: Not Ready

Overall opinion: This approach is wrong.

There are two basic problems with this document.

One: This document does not describe security function.
Instead, it is a toolbox of security components that can be applied in an
application in various combinations depending on the application’s security
needs and tolerance for risk.

This means that it’s impossible to evaluate, based on this document alone,
whether it is fit for purpose or not.

Two: The approach taken - that of assuming that a bit exact canonical form can
be regenerated from a message transferred via any combination of HTTP
functional units - is a very tall order. This approach resembles DKIM, which
has caused widespread havoc in the email ecosystem by its intolerance of common
mailing list behaviors. The complexity of even trying this task is shown by the
fact that ¼ of this 108-page spec is devoted just to the canonicalization
mechanisms - even when several complex topics are handled by referencing other
specifications.

As such, I would not recommend this going on the standards track at this time.

IF it is possible to:
- Describe 2 or more “applications” (in the document’s terminology) that serve
an useful function in securing some part of the ecosystem against some attack -
Implement these functions in a way that exercises a fairly comprehensive subset
of the behaviors mandated in this document - Run the resulting application in a
real environment for some significant period of time, and observe that the
number of canonicalization errors resulting in validation failure is
insignificant to zero THEN it seems to me reasonable to place this on the
standards track.

Until then, I think this best belongs as an experimental protocol that people
can implement to gather experience with, not something that the IETF should
publish as a consensus standards-track protocol.

The rest of this review concerns smaller issues.

Larger issues
==============
Versioning of the protocol is not defined. For example, in 2.1.1, the
serialization of structured fields says that the signer MAY include the sf
parameter, and MUST do STRUCTURED-FIELDS “extensions and updates”. There is no
mechanism to indicate which version of STRUCTURED-FIELDS the signer uses; how
can one be sure that we always get a version that the verifier can reconstruct?

This can be handwaved away by saying “this must be specified by the
application” - but since we have no description of what an application spec
would look like - neither in examples nor in rules - we can’t know if this will
be handled at that level.

The Accept-Signature: field seems more dangerous than described in the spec. In
particular, if the attacker knows the value of some field set, the attacker can
use it as an oracle; it can get a valid signature over that field set in the
signer’s signing key by specifying an Accept-Signature: that includes that
field only (plus overhead). This can then be used in a replay attack together
with unsigned components against other entities that trust the signer.

Smaller issues
==============
These are more at the level of nits - worth fixing or making the meaning more
obvious, but they are not show-stoppers by any means. These are listed by
section, sequentially.

1.1 - Definitions: “Unix time” is not defined. “Key identifier” is used but not
defined.

2 - Canonicalization. The text is not explicit that case differences in field
names do not matter; it just implies it (by lowercasing everything).
Cache-Control: and cache-control: are the same header, and if both occur, they
must be merged. Be explicit.

The spec assumes that case is not being changed in any field value over which
signatures are computed. This should be called out.

2.1.1 - use of ;bs - the term “known by the application to cause problems with
canonicalization” is handwaving. Step 3 of this algorithm seems to assume that
all field values have an unique ASCII representation; is this assumption
warranted?

2.2 - the term “printable character” is undefined. Are we dealing with
0x20-0x7E (ASCII) or some subset thereof, or do Unicode characters occur here?

All of section 2.2 seems to assume that we’re dealing only with HTTP URLs. This
assumption should be made explicit.

For @authority, the reference for normalization does NOT specify lowercasing;
it says “The scheme and host are case-insensitive and normally provided in
lowercase”. Please be explicit that lowercasing MUST be done when computing the
signature base.

(Since I’m working with IDNs, I have to ask if the @authority is comprised of
A-labels or U-labels; I suspect that the answer is “obviously A-labels”, but
offhand, I can’t find the sentence that states this.)

Section 2.3 assumes that “Unix time” is an integer number of seconds. This
depends on what definition of “Unix time” is used (Unix “man 2 time” gives you
the integer representation; other representations include fractional seconds.)

In section 2.4, when multiple modifiers are used, is there a convention for
their order, or do you depend on the verifier using the signer’s order when
reconstructing the signature base?

In section 2.5, the signature base is computed with LF as a line ending, as
opposed to the CRLF line ending conventionally used in HTTP/1.1. This should be
called out, justified, or changed.

Section 4.3, discussing a proxy re-signing a message where it knowingly damages
the message so that its original signature can’t be verified, is confusing. The
text seems to be saying that the original (now failing) signature will be
forwarded, so the final verifier will probably try to verify both signatures,
have one fail and one succeed, and has to take the proxy’s word that the
original signature was OK. This means, of course, that the proxy can carry out
any attack it desires.

More worrisome is that the text does not call out explicitly that this is what
is expected: That the signature from a trusted signer saying that another
signature is to be believed even when it verifies as bad should cause the final
verifier to suspend disbelief. Being very explicit here would be good.

Section 5.2 uses the undefined notion of “fail the processing” for an
Accept-Signature. What is supposed to happen to the request in that case? 500
failure, or just ignoring the Accept-Signature request?

In reading section 7, there seems to be a number of things that are punted on
in the direction of “the application”. This calls out again that there is no
guidance in the document about what an application needs to look like.

Section 7.5.6 details the difficulties in signing the Set-Cookie header (a
major attack target). If the mechanism can’t handle this, is it worth doing?

Section 7.5.7 assumes that all header values can be validated. This seems like
a tall order, since the concept of “validation” isn’t well defined. (You can’t
validate an x-undefined: header)

Received on Monday, 6 March 2023 23:37:50 UTC