Subject: Re: [Tls-reg-review] (new thread for) how to handle legacy TLS 1.2 SignatureAlgorithm registration?

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Sep 2021 10:28:56 -0700

Adding IANA('s ticket queue), since there is now a question for them.

In a different thread, Dmitry proposed the following course of action:

---------
As we are trying to ensure consistent processing of the SignatureScheme and
SignatureAlgorithm registries, we suggest the following changes in the IANA
registries to ensure that the values are valid for real-life multiprotocol
(TLS 1.2 and 1.3) implementations.

SignatureScheme: Reserve the values 0x0840 and 0x0841 and mark them as
"Reserved for backward compatibility" in the registry. We could also add
these values to the TLS 1.2 draft into the “IANA consideration” section if
necessary.

SignatureAlgorithm: No reservation changes besides the current one (values
64 and 65 are already registered). We agree that leaving a note in the
SignatureAlgorithm registry that use of those values is only defined when
using the "Intrinsic" hash algorithm 8 makes sense, though it partially
duplicates the information in Section 5 of the draft.

If you think that any of these changes should have another distribution
between the registries, please let us know. We think that the new thread
with you, the IANA Designated Experts,
IANA itself, ISE, and maybe us as the document authors is worth initiating.
---------

This seems like a reasonable approach to me.

IANA, is it reasonable to you, and something that you think you can
implement (once appropriate text is provided)?

DEs, does that seem reasonable to you?

Thanks,

Ben

On Wed, Aug 11, 2021 at 05:04:56PM -0700, Benjamin Kaduk wrote:
> Hi all,
> 
> Starting a new thread to avoid the topic from getting filed back with the
> traffic from 2019 and intermingled with the full IANA review of the
> document in question as my original mail
> (https://mailarchive.ietf.org/arch/msg/tls-reg-review/VFxQHEAit6Qg1fmnPwhRW2GUrKU/)
> did...
> 
> (possibly repetitive background) The ISE is currently progressing a draft
> (draft-smyshlyaev-tls12-gost-suites) that specifies the use of some
> Russian GOST ciphers/algorithms for TLS 1.2.  (There's a separate draft for
> TLS 1.3 ciphers, which is I think not relevant here.)  The initial IANA
> review happened in 2019
> (https://mailarchive.ietf.org/arch/msg/tls-reg-review/s-fDBF8hzCXEH5UQSez6uC1CnUE/)
> and the experts' answers/approval in
> https://mailarchive.ietf.org/arch/msg/tls-reg-review/WvJJ5LB2bmNuPbXxl9bUqyV8G2k/
> include noting that the TLS SignatureAlgorithm registration of value 64 is
> okay.  I did the IESG conflict-review per RFC 5742 for this week's IESG
> telechat, and noticed that this introduces a conflict with the TLS 1.3
> SignatureScheme registry.  Details below.
> 
> The TLS SignatureAlgorithm registry is a legacy TLS-pre-1.3 registry,
> which the WG envisioned would be effectively closed once TLS 1.3 was
> published.  This is not solely because the new TLS protocol version
> obsoletes the old ones, but also because TLS 1.3 redefined how these values
> are used.  In TLS 1.2 and earlier, the separate HashAlgorithm and
> SignatureAlgorithm registered values are only used in combination, as the
> SignatureAndHashAlgorithm structure.  That structure, in turn, is used in
> DigitallySigned, CertificateRequest, and the "signature_algorithms"
> extension.  In particular, the HashAlgorithm and SignatureAlgorithm values
> are never used independently of each other in TLS.  (There may be such
> separate uses in other protocols, such as SNMP that uses the one-byte
> HashAlgorithm values, but that is probably also out of scope for this
> topic.)
> 
> The cross-product of all signature algorithms and all hash algorithms led
> to a large number of possibilities, many of which didn't actually make much
> practical sense.  Furthermore, with the introduction of EdDSA signature
> methods, it's possible to make signatures that don't have an associated
> hash algorithm, leading to the "intrinsic" hash algorithm (value 8) being
> registered.
> 
> Since the setup with separate registries was becoming increasingly
> infeasible at the time of TLS 1.3 development, TLS 1.3 changed the way the
> protocol is specified so as to use the combined two-byte SignatureScheme
> values, that are used in the "signature_algorithms" extension (and
> elsewhere) in place of SignatureAndHashAlgorithm.  However, since
> "signature_algorithms" is sent in the ClientHello that must be
> protocol-version-independent, this redefinition was performed in a
> backwards-compatible manner.  New two-byte codepoints were assigned for all
> the pairings of signature and hash that were in common use at the time,
> with the same values.  All then-unallocated values in the standalone
> HashAlgorithm and SignatureAlgorithm registries were marked as Reserved
> (with RFC 8447 as the reference)
> 
> Furthermore, the ranges in the combined registry that correspond to
> one-byte codepoints thare were already assigned as SignatureAlgorithms or
> HashAlgorithms were marked as reserved (with RFC 8446 as the reference), to
> avoid confusing any legacy implementations that receive the new two-byte
> codepoints as part of a TLS 1.3-compatible ClientHello.
> 
> So, in my mind, these changes were a cohesive whole that endeavor to shift
> all future allocations to the combined SignatureScheme registry and
> effectively close the HashAlgorithm and SignatureAlgorithms registries.
> The question of formally closing the registries was even posed to the WG
> (https://mailarchive.ietf.org/arch/msg/tls/zFywXFPO6nvcLMtQBEBQ1K4HlBs/,
> also a related thread at
> https://mailarchive.ietf.org/arch/msg/tls/cvAxrmvI3UsNgiTKNLjGAYKKqSU/),
> with the (meager) feedback taking us to the "reserve but leave open in case
> of huge surprises" stance.  The topic of how to allocate new things for TLS
> 1.2 came up in the latter thread, e.g.,
> https://mailarchive.ietf.org/arch/msg/tls/F4EC4O3nLYbeQ1t-YYeCHjARe8g/ that
> points to what is now RFC 8422 and mentions the awkward wording it had to
> go through to make this happen while using the semantics of the TLS 1.3
> registry.  (It's not actually a great example, though, since it did still
> make some allocations in the old registries, which was possible since it
> predated RFC 8446.  I think the relevant phrasing is "to represent ... in
> the signature_algorithms extension, the value shall be (x, y)", which keeps
> the paired nature of the new-style allocations.)  From my quick review of
> that thread, there seemed to be clear agreement that even new TLS 1.2
> allocations should use the new registry.
> 
> According to my email archives (and we could ask IANA to check their
> records, which are surely more authoritative than mine, if we want), the
> registry changes from RFCs 8446/8447 were finalized around June 2018, which
> significantly predates the January/February 2019 timeframe when the
> draft-smyshlyaev-tls12-gost-suites registrations were being processed.
> 
> Adrian has noted that the RFC 8446/8447 registry allocation procedures list
> the procedure for making registrations as basically saying that the fine
> folks of [email-masked] are the authority.  I basically agree with
> that, but I don't think I'd characterize changing a value's state from
> "Reserved" to "allocated" as being a regular "registration" -- I would only
> characterize transitions from "unallocated" to "allocated" in that way.
> Values marked as "reserved" would then have the change controller as the
> entity that caused them to be marked reserved, which in this case is the
> IETF.
> 
> Having laid out that background, what do the options like for paths
> forward?  The SignatureAlgorithm values 64 and 65 have been listed as
> allocated in the registry for a couple years already, so it seems absurd to
> somehow claim that the values should be "clawed back" and replaced with
> incompatible values from the SignatureScheme registry.  But it also seems
> problematic to have entries in the standalone SignatureAlgorithm registry
> that do not have corresponding reserved ranges in the SignatureScheme
> registry, since that would eventually lead to a situation where a given
> ClientHello+signature_algorithms entry would mean one thing when TLS 1.3 is
> negotiated and a different thing when TLS 1.2 is negotiated.  Making those
> reservations, though, would be a noticeable chunk of the codepoint space,
> and might fall afoul of the "duplicates existing functionality" clause in
> the guidance given to the experts in
> https://datatracker.ietf.org/doc/html/rfc8447#section-17 .  (I did not find
> anything that seems to specifically require an IETF or standards-track
> document to make such large sweeping reservations, but it seems like a
> reasonable person would not be surprised if the DEs gave pushback on a
> document that attempted to do so.)
> 
> I think there is a "middle path", though, that preserves compatibility with
> existing deployments while not falling afoul of registration procedures.
> It seems that it should be possible to register 0x0840 and 0x0841 in the
> SignatureScheme registry and change draft-smyshlyaev-tls12-gost-suites to
> use a wording similar to RFC 8422, that refers to pairs (8,64) and (8,65)
> in the SignatureAndHashAlgorithm field.  This is largely what is already
> done, though I did not do a complete audit just now.  (There does seem to
> be one place in §4.2.5 that talks about the "gostr34102012_256 value of the
> SignatureAndHashAlgorithm field"/etc., without clarifying which sub-field
> has that value.  I think it would be necessary to use the number and not
> the name gostr34102012_256, though, since that name is given to the current
> allocation that seems problematic.)  It would probably also be worth
> including a note explaining that the "MUST only contain the values {8,64}"
> is in order to be compatible with the changes TLS 1.3 made to signature
> algorithm registrations, that effectively removes the freedom to pair
> arbitrary signatures and hashes.
> 
> What do people think of that proposal?
> 
> Thanks, and sorry for only noticing this at the time of the RFC 5742
> conflict-review evaluation.
> 
> -Ben
> 
> _______________________________________________
> tls-reg-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls-reg-review

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Sep 2021 18:10:39 +0000

Works for me.

On 9/1/21, 1:29 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    ---------

    Thanks,

    Ben

    On Wed, Aug 11, 2021 at 05:04:56PM -0700, Benjamin Kaduk wrote:
    > (https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls-reg-review/VFxQHEAit6Qg1fmnPwhRW2GUrKU/__;!!GjvTz_vk!EoF9PiT-cIpQT6oUr3LHFg37-_oCp-Hte_l7ln1cNAKE6CQCH7Q_fk5gOK7w$ )
    > did...
    > 
    > (https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls-reg-review/s-fDBF8hzCXEH5UQSez6uC1CnUE/__;!!GjvTz_vk!EoF9PiT-cIpQT6oUr3LHFg37-_oCp-Hte_l7ln1cNAKE6CQCH7Q_fnwv6Uha$ )
    > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls-reg-review/WvJJ5LB2bmNuPbXxl9bUqyV8G2k/__;!!GjvTz_vk!EoF9PiT-cIpQT6oUr3LHFg37-_oCp-Hte_l7ln1cNAKE6CQCH7Q_fuHqw0Zk$ 
    > (https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/zFywXFPO6nvcLMtQBEBQ1K4HlBs/__;!!GjvTz_vk!EoF9PiT-cIpQT6oUr3LHFg37-_oCp-Hte_l7ln1cNAKE6CQCH7Q_fvy5V49S$ ,
    > also a related thread at
    > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/cvAxrmvI3UsNgiTKNLjGAYKKqSU/__;!!GjvTz_vk!EoF9PiT-cIpQT6oUr3LHFg37-_oCp-Hte_l7ln1cNAKE6CQCH7Q_flSqOgdp$ ),
    > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/F4EC4O3nLYbeQ1t-YYeCHjARe8g/__;!!GjvTz_vk!EoF9PiT-cIpQT6oUr3LHFg37-_oCp-Hte_l7ln1cNAKE6CQCH7Q_fosjPZzk$  that
    > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8447*section-17__;Iw!!GjvTz_vk!EoF9PiT-cIpQT6oUr3LHFg37-_oCp-Hte_l7ln1cNAKE6CQCH7Q_fhQ6uO7f$  .  (I did not find
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls-reg-review__;!!GjvTz_vk!EoF9PiT-cIpQT6oUr3LHFg37-_oCp-Hte_l7ln1cNAKE6CQCH7Q_ftzgTbf2$ 

    _______________________________________________
    tls-reg-review mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls-reg-review__;!!GjvTz_vk!EoF9PiT-cIpQT6oUr3LHFg37-_oCp-Hte_l7ln1cNAKE6CQCH7Q_ftzgTbf2$