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

Hi Roman, thanks for the thorough read through of the draft. My comments are inline.

> On Jun 7, 2023, at 10:59 PM, Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
> 
> 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.

I’m honestly not sure what the effective difference would be and I’ll gladly defer to others for the appropriate IANA language here. We do want a DE in place to make sure that any registered algorithm meets all the stated criteria, but especially:

 - That it’s fully specified (and doesn’t have any variable parameters that implementations would need to choose independently)
 - That the name is fairly descriptive
 - That it’s not an alias of something already in there

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

This was meant as a way to de-activate algorithms previously registered at some future time when they’re no longer recommended for general use.

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

The registry is ONE source of algorithms — it’s not intended to be the only source for implementors. Applications are allowed to define their own signing algorithms appropriate to their environment, and they can do what they want within a given environment. So long as they aren’t using the “alg” parameter to signal which algorithm to choose, and don’t expect interoperability of algorithm selection, which is not required for many applications. In fact, it’s recommended that applications do not use the “alg” parameter at all, whether or not they use an algorithm in the registry, since there are a suite of confusion attacks that can come from allowing the sender (or an attacker) to choose the signing algorithm and have the verifier just accept that.

This theme is carried throughout the document, but is there something we can do to make the intent more clear?

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

I’d be fine with this being used instead of Active/Deprecated, if it works better.

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

Good call, will change.

> 
> ** 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?

This reference was added during earlier IETF LC comments, where the historical perspective of similar systems was raised as a resource for developers of this specification. It’s meant as an informative pointer only. How would you suggest we soften this statement?

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

Good catch, thanks.

> 
> ** Section 2.
> Message component values must therefore be canonicalized
> 
> Should this be “Message component values MUST ...?

I don’t think this is a normative statement - we can change the “must” to “have to be” or something of that line instead to be more clear.

> 
> ** 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?

Sadly, there is not, or we would lean on that.

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

Ah, I see how that could be misread - we’ll fix that.

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

I’m OK with doing that, but we explicitly import the term Byte Sequence in the terminology section. We don’t call out references to other SF types, like String or Inner List, except to call out explicit serialization and parsing rules.

> 
> ** 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)

This is what the POSIX reference is supposed to give us, we can clean that up.

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

The examples were all calculated using fixed date values, and all examples would need to be re-generated to change the timestamps. We could do that — there’s a script to generate all the examples, but the output from that script needs to be copied by hand to the right places. Consequently, I’m not convinced it’s worth the overhaul and possible mis-copying just for that change.

> 
> ** 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?

The value of the “expires” parameter is application specific, and there’s no recommendation. 5 mins was chosen somewhat arbitrarily for the example.

> 
> ** 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?

What we’re trying to say here is that it’s always up to the verifier to determine when a signature is still good, and “expires” is just a message from the signer saying “I (the signer) wouldn’t trust this signature after this timestamp”. This is a strong signal to the verifier, but not the only one the verifier needs to consider, as defined by the application of the signatures spec.

> 
> ** 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”?
> 

This is meant to be a requirement on the application of the signature spec and especially on verifiers - if someone hands you an RSA key but tells you to use HMAC for it, that’s a problem because the algorithm is not appropriate for the key material. Same if someone gives you a key from one curve and you try to use it on a different curve.

The “MAY” is this draft’s way of saying “use whatever signature algorithm you want so long as it defines HTTP_SIGN, HTTP_VERIFY, and follows all the other rules in this section”. It seems appropriate to me that this is a normative allowance - is there a better way to say that?

> ** 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?

No, the algorithm definitions come from the application of the signature spec. The algorithms registry gives you values you can use in the “alg” parameter and in the spec, sure, but there are lots of other ways to do it. This section tells you how to use any JWS algorithm definition against HTTP Signatures, by translating the input and output terms appropriately. Note that if you’re using a JWS algorithm, you’re prohibited from using the “alg” field, since the JWS algorithms are not defined in the registry.

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

Seems reasonable, we’ll add that.

 — Justin

Received on Friday, 9 June 2023 18:04:02 UTC