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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Aug 2021 17:04:56 -0700

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

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 12 Aug 2021 13:38:56 +0000

Speaking for myself, I did not treat "reserved" as separate from unassigned.  That's my mistake. I notice other registries often say *why* it is reserved, and perhaps an update to the TLS registries should do that as well.

I am less concerned about registrations having different meanings in TLS 1.3 compared to 1.2 and earlier, and more concerned about breaking interop with things already deployed that were based on the designated experts review.  In short, they proceeded in good faith, and we seem to have made a mistake, we should own that.

Your "middle ground" proposal makes sense to me.

Thanks for the detailed write-up.

---

From: Смышляев Станислав Витальевич <[email-masked]>
Date: Sun, 15 Aug 2021 11:33:37 +0000

Dear Ben, 

We’ve discussed your proposals with the other authors of the draft (and some developers of GOST implementations) and agree with it. 

We’ll send a message with some details a bit later. 

Thanks a lot, Ben!

Regards,
Stanislav 

> On 12 Aug 2021, at 03:05, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Алексеев Евгений Константинович <[email-masked]>
Date: Wed, 18 Aug 2021 16:20:33 +0000

Dear Ben,

Thank you again for your remarks. We have taken them into account in the 15th draft version.

Our comments are in attachment.

Best regards,
Evgeny Alekseev,
CryptoPro LLC

-----Original Message-----
From: Смышляев Станислав Витальевич 
Sent: Sunday, August 15, 2021 2:34 PM
To: Benjamin Kaduk <[email-masked]>
Cc: [email-masked]; [email-masked]; Коллегин Максим <[email-masked]>; Алексеев Евгений Константинович <[email-masked]>; Смышляева Екатерина Сергеевна <[email-masked]>; Белявский Дмитрий <[email-masked]>; [email-masked]; Николаев Василий Дмитриевич <[email-masked]>
Subject: Re: (new thread for) how to handle legacy TLS 1.2 SignatureAlgorithm registration?

Dear Ben, 

Thanks a lot, Ben!

Regards,
Stanislav 

> 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
> 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/WvJJ5LB2bmNuPbXxl
> 9bUqyV8G2k/ 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.
> 
> 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.
> 
> 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
> 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)
> 
> 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.
> 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
> 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.
> 
> 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.
> 
> 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 
> ClientHello+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.
>