Re: I-D Action: draft-ietf-httpbis-message-signatures-18.txt

Hi Roman,

Thanks so much for the quick turnaround and for your flexibility in addressing this last issue. I have submitted a new draft with the updated text, and we should be all set now.

- Justin

On Jul 26, 2023, at 11:03 AM, Roman Danyliw <rdd@cert.org> wrote:

Hi Justin!

To document our conversation yesterday, I agree on the value of aligning the language in this draft with what is said in the draft-ietf-httpbis-digest-headers regarding.  Thanks for surfacing the related threads.

Having had a chance to re-read the digest draft and look at the proposed PR, it gets to the same result that I was advancing with a three-state registry.  By all means commit the PR.  For expediency, I’m not re-balloting (as things current stand with a “No Objection”, no feedback text position).

Thanks again for iteratively working through this issue.

Roman

From: Justin Richer <jricher@mit.edu>
Sent: Monday, July 24, 2023 12:15 AM
To: Roman Danyliw <rdd@cert.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>; Mark Nottingham <mnot@mnot.net>; Lucas Pardue <lucaspardue.24.7@gmail.com>; Backman, Annabelle <richanna@amazon.com>
Subject: Re: I-D Action: draft-ietf-httpbis-message-signatures-18.txt

Hi Roman,

After publishing the new draft based on your recommended text earlier today (below), I had a conversation with a few members of the HTTP WG here in San Francisco where it was brought to my attention that the Digest draft, which is related to the signatures draft, has a similar but different approach to this IANA registry. There, the relevant field is called “Status” and it has three values:

Status: the status of the algorithm. The options are
- "Active" - for algorithms without known problems,
- "Provisional" - for unproven algorithms,
- "Deprecated" - for deprecated or insecure algorithms,


The application of these values is further enumerated with the following text from Digest:


When reviewing registration requests, the designated expert(s) should pay attention to the requested status. The status value should reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs. The "Active" status is not suitable for an algorithm that is known to be weak, broken, or experimental. If a registration request attempts to register such an algorithm as "Active", the designated expert(s) should suggest an alternative status of "Deprecated" or "Provisional".When reviewing registration requests, the designated expert(s) cannot use a status of "Deprecated" or "Provisional" as grounds for rejection.Requests to update or change the fields in an existing registration are permitted. For example, this could allow for the transition of an algorithm status from "Active" to "Deprecated" as the security environment evolves.


I was unaware that this change had already been made to the Digest specification until I had this conversation tonight. This approach provides the same three functional categories that your proposed recommendation text suggests, but I think it cuts a much better line towards what is actually intended by the registry. We’re not really recommending specific algorithms for applications, we’re trying to tell implementors a bit about how that entry got into the registry. This is especially relevant given that the signatures draft recommends against using inline algorithm specification in several places, due to the security issues that could happen with algorithm substitution attacks as we have seen in the JOSE world.

The working group members in the discussion tonight believe it’s important that the signatures and digest drafts are in alignment with each other. As such, I am recommending that we adopt the approach and text from the digest draft. I have prepared a pull request to do just that here:

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

I believe this addresses the concern you raised in your DISCUSS and provides the same three categories of guidance around registered algorithms while providing a better alignment with what the WG was conveying with the field originally, as well as aligning with a very similar field in the Digest draft which has cleared IESG review. If you agree this is changed text is sufficient to address the DISCUSS you raised, I will apply this and release -19.

Thanks,
 — Justin



On Jul 23, 2023, at 4:32 PM, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the HTTP (HTTPBIS) WG of
the IETF.

  Title           : HTTP Message Signatures
  Authors         : Annabelle Backman
                    Justin Richer
                    Manu Sporny
  Filename        : draft-ietf-httpbis-message-signatures-18.txt
  Pages           : 118
  Date            : 2023-07-23

Abstract:
  This document describes a mechanism for creating, encoding, and
  verifying digital signatures or message authentication codes over
  components of an HTTP message.  This mechanism supports use cases
  where the full HTTP message may not be known to the signer, and where
  the message may be transformed (e.g., by intermediaries) before
  reaching the verifier.  This document also describes a means for
  requesting that a signature be applied to a subsequent HTTP message
  in an ongoing HTTP exchange.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-18.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-httpbis-message-signatures-18

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts