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

Hi Roman, thanks for the detailed rundown. I have taken a stab at altering the registry as you suggest, based on the COSE specification text. I’ve incorporated that into this existing PR:

https://github.com/httpwg/http-extensions/pull/2570


Hopefully this addresses the concerns of the DISCUSS sufficiently.

 — Justin

On Jul 20, 2023, at 9:36 AM, Roman Danyliw <rdd@cert.org> wrote:

Hi Justin!

Thanks for explaining some of the thinking.  More below …

From: iesg <iesg-bounces@ietf.org<mailto:iesg-bounces@ietf.org>> On Behalf Of Justin Richer
Sent: Friday, June 23, 2023 3:19 PM
To: Roman Danyliw <rdd@cert.org<mailto:rdd@cert.org>>
Cc: John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>>; Martin Duke <martin.h.duke@gmail.com<mailto:martin.h.duke@gmail.com>>; The IESG <iesg@ietf.org<mailto:iesg@ietf.org>>; draft-ietf-httpbis-message-signatures@ietf.org<mailto:draft-ietf-httpbis-message-signatures@ietf.org>; httpbis-chairs@ietf.org<mailto:httpbis-chairs@ietf.org>; HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>; tpauly@apple.com<mailto:tpauly@apple.com>; Paul Wouters <paul.wouters@aiven.io<mailto:paul.wouters@aiven.io>>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-httpbis-message-signatures-17: (with DISCUSS and COMMENT)

Hi Roman — thanks for the response, answers inline, I think we’re getting there.


On Jun 23, 2023, at 2:06 PM, Roman Danyliw <rdd@cert.org<mailto:rdd@cert.org>> wrote:

Hi Justin!

Thanks for the PR (https://github.com/httpwg/http-extensions/pull/2570). More inline and snipping to the relevant parts:


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

Formally, the difference between Expert Review and Specification Required is covered in Section 4.5 and 4.6 of RFC8126.

https://datatracker.ietf.org/doc/html/rfc8126#section-4.5


https://datatracker.ietf.org/doc/html/rfc8126#section-4.6


Colloquially, Expert Review doesn't require and formal document or stable reference.  Specification Required requires such a stable reference and also included the review of the Designated Expert.

Given that this registry is pointing to a crypto algorithm, I don't see how one could fully described an algorithm in a registration template.  If someone is expected to be able to find an algorithm in this registry and implement it, it seems to need to be a stable reference.

OK, that makes sense. I went with Expert Review because we wanted someone to be able to enforce the other considerations (ie, not registering an alias), and I didn’t realize that the Specification Required mode effectively includes Expert Review as part of it. I’ll go change it to Specification Required.

I feel like I learn something new about IANA with each spec I work on. :)

[Roman] Sounds like a plan.  Note possible refinement below …


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

I read the following new text in the PR:

==[ snip ]==
When an algorithm is first registered, the status is set to "Active". If at a future time the algorithm as registered is found to have flaws, the registry entry can be updated and the algorithm can be marked as Deprecated to indicate that the algorithm has been found to have problems. This status does not preclude an application from using a particular algorithm, but serves to provide warning of possible known issues with an algorithm that need to be considered by the application.
==[ snip ]==

I appreciate the state of "Deprecated" and the workflow to get to it.  My concern remains on what does "Active" mean.  If "Deprecated" means that the "algorithm has been found to have problems", what assurances or claims are being made about "Active" -- is it that the algorithms is believed to be secure?  the registrations are unvetted regarding security?  How would one distinguish between the "trusted recommendations" made in this document and subsequent registrations?

Does the DE have any responsibility to assess the security properties if a request for "Active" is made, since there appears to be a responsibility to confirm lack of security in accepting a "Deprecated" update.

I referenced the TLS Cipher Suite registry (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4) because it side steps these issues.  Specifically, it requires a stable reference (with a Specification Required registration policy); provides the flexibility to register any documented algorithm (with the Specification Required policy), but can signal what is an IETF vetted algorithm (Recommendation=Y) and what has either not been vetted or has issues (Recommendation=N)

My recommendation would be to do something similar.

“Active” in this case is effectively what TLS has when something is in the registry but has “N” on the recommended column. That is to say, we don’t really make a statement that a particular algorithm
is appropriate for a given use case. In other words, we want to be able to warn people about known-bad algorithms (“Deprecated”) but don’t want to give people the wrong idea. That’s why we went with “Active” as the term as opposed to “Recommended” as the “Not Deprecated” label. This text from the PR was meant to capture some of that in the paragraph preceding the quoted one above:

==
The algorithms listed in this registry identify some possible cryptographic algorithms for applications to use with this specification, but the entries neither represent an exhaustive list of possible algorithms nor indicate fitness for purpose with any particular application of this specification. An application is free to implement any algorithm that suits its needs, provided the signer and verifier can agree to the parameters of that algorithm in a secure and deterministic fashion. When an application has a need to signal the use of a particular algorithm at runtime using the `alg` signature parameter, this registry provides a mapping between the value of that parameter to a particular algorithm. However, use of the `alg` parameter needs to be treated with caution to avoid various forms of algorithm confusion and substitution attacks, such as discussed in {{security-keydowngrade}} and others.
==

As well as this description of the Status field:

==
A value of "Active" indicates that an algorithm has been fully specified and registered, but does not indicate that an algorithm is suitable for all use cases or applications.
==


I don’t really want to put the DE into the position of vetting a “good” algorithm. Algorithm choice is going to be very application specific and it’s not expected to be a point of interoperability in general. Since applications of HTTP Signatures are going to have drastically different requirements for their algorithms, I don’t want to give a false sense of security even if an algorithm is recommended for general use. For example, HMAC is going to make sense in, say, a data center with HKM’s or key derivation techniques that can be drawn from the environment and context of a call, but probably not a good idea for a general application to use it (and there’s a security consideration to that effect).

[Roman] Agree that the DE shouldn’t be put in that position.

TLS benefits from many years of deployment experience and lots of formal analysis of the crypto algorithms, as well as a wide and invested community in its review. I’d be afraid that if we follow the TLS example of a “Recommended” field with similar review requirements (as I understand them), we’d end up with a registry that never got anything set to “Y” on that field.

[Roman] I don’t follow.  The document already specifies a number of algorithms in Section 3.3.1 – 3.3.6.  Aren’t these implicitly, consensus based recommendations.  The only time you would get something set to “yes” if there was a “vetting process” – standards action would be one of them.  We’ve been talking about TLS, but this is also what is done for COSE (https://www.iana.org/assignments/cose/cose.xhtml#algorithms).

[Roman] There are also existing patterns for handling recommended algorithms that don’t have general applicability.  See CCM_8 cipher suites in https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4.


What if instead of a “Status” column we simply have a “Deprecated” column that has a value of “N” by default and gets changed to “Y” if an algorithm needs to be marked as problematic? It’s functionally the same as what we have here now, but perhaps gives a better impression of what we mean by it. I’d be happy to change over to that approach if that makes things better in presentation.

[Roman] It appears the text would create two categories algorithms – “unknown security properties” and “known to be insecure”.  However, I think we are already in “three category system” – “vetted”, “unvetted”, and “know to be bad” (aka, what TLS and COSE already use).  New registrations could follow a “specification required” registration will be registered as “unvetted” (or “active” in the earlier parlance).  Certain things that were previously in the registry may be marked as “known to be bad”/“deprecated” likely based on how they were registered.  Additionally, this document has already made the “vetted” list with Section 3.3.1 – 3.3.6.  If the WG doesn’t have confidence that these aren’t “vetted”/”safe” choices then they likely don’t belong in a PS or at least some clear discussion needs to establish why a PS document is proposing unsafe cryptographic choices.

[Roman] Practically, doesn’t the COSE/RFC8152 Section 16.4 definition of “Recommended” support the flexibility for future agility and maintenance.

   Recommended:  Does the IETF have a consensus recommendation to use
      the algorithm?  The legal values are 'Yes', 'No', and
      'Deprecated'.

[Roman] Yes = takes a Standards Action and is vetted via the standards process; N = take Specification Required and provides a code point, but no validation of security properties (as you propose above); and “Deprecated” roughly aligns to the above definitions of how to handle something in the future that becomes problematic.

Roman