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

From: "Amanda Baber via RT" <[email-masked]>
Date: Wed, 27 Oct 2021 23:01:36 +0000

Hi Yoav, Nick,

Can one of you confirm that we can mark values 0x0840 and 0x0841 in the SignatureScheme registry "Reserved for backward compatibility"?

https://datatracker.ietf.org/doc/html/draft-smyshlyaev-tls12-gost-suites-17

thanks,
Amanda

On Wed Sep 01 18:11:03 2021, [email-masked] wrote:
> Works for me.
> 
> On 9/1/21, 1:29 PM, "Benjamin Kaduk" <[email-masked]> wrote:
> 
> 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls-
> > reg-review/VFxQHEAit6Qg1fmnPwhRW2GUrKU/__;!!GjvTz_vk!EoF9PiT-
> > cIpQT6oUr3LHFg37-_oCp-Hte_l7ln1cNAKE6CQCH7Q_fk5gOK7w$ )
> > 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls-
> > reg-review/s-fDBF8hzCXEH5UQSez6uC1CnUE/__;!!GjvTz_vk!EoF9PiT-
> > cIpQT6oUr3LHFg37-_oCp-Hte_l7ln1cNAKE6CQCH7Q_fnwv6Uha$ )
> > and the experts' answers/approval in
> >  https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls-
> > reg-review/WvJJ5LB2bmNuPbXxl9bUqyV8G2k/__;!!GjvTz_vk!EoF9PiT-
> > cIpQT6oUr3LHFg37-_oCp-Hte_l7ln1cNAKE6CQCH7Q_fuHqw0Zk$
> > 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://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$ ),
> > 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/F4EC4O3nLYbeQ1t-
> > YYeCHjARe8g/__;!!GjvTz_vk!EoF9PiT-cIpQT6oUr3LHFg37-_oCp-
> > Hte_l7ln1cNAKE6CQCH7Q_fosjPZzk$  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://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
> > 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://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$
>

---

From: Nick Sullivan <[email-masked]>
Date: Thu, 28 Oct 2021 11:56:09 -0400

Yes, I can confirm.

On Wed, Oct 27, 2021 at 7:01 PM Amanda Baber via RT <
[email-masked]> wrote:

> Hi Yoav, Nick,
>
> Can one of you confirm that we can mark values 0x0840 and 0x0841 in the
> SignatureScheme registry "Reserved for backward compatibility"?
>
> > > (
> > > (
> > > (
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/zFywXFPO6nvcLMtQBEBQ1K4HlBs/__;!!GjvTz_vk!EoF9PiT-
> https://www.ietf.org/mailman/listinfo/tls-reg-review
>