Roman Danyliw's Discuss on draft-ietf-httpbis-message-signatures-17: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-httpbis-message-signatures-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am raising a similar argument as Martin Duke left in his COMMENT feedback.

** Section 6.2.  HTTP Signature Algorithms Registry.

-- What is the difference between how this “Expert Review” registration
guidance as written (of being a DE review + spec) and one that is
“Specification Required”.  Both appear to require an expert review and a
specification.

-- What does “Active” mean?  “Deprecated” is framed as the algorithm is “no
longer recommended for use and might be insecure or unsafe”.  Does “Active”
mean “recommended and secure/safe”?  Is the DE responsible for assessing the
cryptographic properties of new registration?  Is that a realistic expectation?

Subsequent language in Section 7.3.1 suggests that the registry is the source
of “trust signature algorithms”:
   To counter this, only vetted keys and signature algorithms should be
   used to sign HTTP messages.  The HTTP Message Signatures Algorithm
   Registry is one source of trusted signature algorithms for
   applications to apply to their messages.

Should a mechanism like the “Recommended” column in the TLS registries be used:

“If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that
the item either has not been through the IETF consensus process,
has limited applicability, or is intended only for specific use
cases.”


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 1.1
   The term "Unix time" is defined by [POSIX.1], Section 4.16
   (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
   V1_chap04.html#tag_04_16)

That URL should be a reference.

** Section 1.4.
   Historical
   systems, such as [AWS-SIGv4], can provide inspiration and examples of
   how to apply similar mechanisms in a secure and trustable fashion.

With due respect to AWS, is this too strong of a statement of a system not
evaluated by the IETF?

** Section 2.  Editorial.  s/a the raw query string/a raw query string/

** Section 2.
Message component values must therefore be canonicalized

Should this be “Message component values MUST ...?

** Section 2.1
   Other encodings could exist
   in some implementations, and all non-ASCII field values MUST be
   encoded to ASCII before being added to the signature base.

Is there a standardized way to do this canonicalization to ASCII?

** Section 2.1
   Specifically, HTTP fields
   sent as multiple fields MUST be combined using a single comma (",")
   and a single space (" ") between each item.

Recommend making this text clear.  I initially read it as space on either side
of the comma (because it said “between each item”).  The intent from Section
5.2 of [HTTP] appears to be “concatenate a ‘,’ + ‘ ‘” between items.

** Section 2.1.3.  Editorial. Recommend adding an explicit reference to Byte
Sequences per Section 3.3.5 of RFC8941.  Perhaps in step 3.4.

** Section 2.3.  Provide a formal reference to “UNIX timestamp”.  Perhaps: 
IEEE Std 1003.1-2017
(https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html)

** Section 2.3.  Editorial.  Consider using a date in 2023 for the example
(instead of 2021).

** Section 2.3.  I didn’t find any guidance in the text around setting the
“expires” signature parameter.  However, many of the non-normative example seem
to use 300 seconds (5 minutes).   What is the basis of that value?  Is there a
recommendation on how to reason about setting the expiration?

** Section 3.1
3.  If applicable, the signer sets the signature's expiration time
       property to the time at which the signature is to expire.  The
       expiration is a hint to the verifier, expressing the time at
       which the signer is no longer willing to vouch for the safety of
       the signature.

What is “safety of the signature”?  Is this safety window measured in 5
minutes, like in the various examples?

** Section 3.3.
   An HTTP Message signature MUST use a cryptographic digital signature
   or MAC method that is appropriate for the key material, environment,
   and needs of the signer and verifier.  This specification does not
   strictly limit the available signature algorithms, and any signature
   algorithm that meets these basic requirements MAY be used by an
   application of HTTP message signatures.

It is unclear what the normative MUST and MAY are prescribing.  Recommend not
using the RFC2119 language here.

-- Per sentence 1, Lacking any context, “appropriate for the …” seems entirely
subjective.  My judgement on what’s appropriate may not be yours.

-- Per sentence 2, what are the “basic requirements”?

** Section 3.3.7.
   If the signing algorithm is a JOSE signing algorithm from the JSON
   Web Signature and Encryption Algorithms Registry established by
   [RFC7518], the JWS algorithm definition determines the signature and
   hashing algorithms to apply for both signing and verification.

 I don’t understand this guidance.  Don’t the signing algorithms have to be
 pulled from the (new) “HTTP Signature Algorithm” registry?

** Section 5.1.  Editorial.  Should a reminder be added to the alg field that
the values come from the HTTP Signature Algorithms registry