[art] Re: AD Evaluation: draft-barnes-sframe-iana-256-00

[Aron Rosenberg <[e-mail]>]

>> > 
>> > ## Discuss worthy
>> > 
>> > ### Change controller
>> > 
>> > ```
>> > The "Change Controller" entry should be removed.
>> > ```
>> > 
>> > Why? These registries were established with the IETF as the change controller.
>> > 
>> > The registration policy is Spec Required with a call out per rfc9605:
>> > 
>> > ```
>> > Recommended: Whether support for this cipher suite is recommended by the IETF. Valid values are "Y", "N", and "D" as described in Section 17.1 of [MLS-PROTO]. The default value of the "Recommended" column is "N". Setting the Recommended item to "Y" or "D", or changing an item whose current value is "Y" or "D", requires Standards Action [RFC8126].
>> > ```
>> > 
>> > In my reading, IETF remains the change controller regardless of the column given the note about standards action.
>> > 
>> > What motivated the decision to remove the change controller column?

We changed the Change Controller portion of the registry because it was not actually the original intent of the original authors to require a new RFC for introducing a new cipher suite definition. They had originally intended it to be expert review only. This got lost during the original process and the writing of the IANA considerations section in RFC 9605 and wasn’t discovered until I tried to register the new cipher suites that this draft defines. We then decided to formally update this since we had to write an RFC anyway given the current registry rules. Since SFrame is not creating its own crypto or hash algorithms and uses them only in terms of RFC 5869 HKDF usage, we felt this would simplify the process in the future for others.

>> > 
>> > ## Comments
>> > 
>> > ### auth subkey?
>> > 
>> > ```
>> >    *  enc_key: The encryption subkey produced by the derive_subkeys()
>> >       algorithm
>> > 
>> >    *  auth_key: The encryption subkey produced by the derive_subkeys()
>> >       algorithm
>> > ```
>> >

This is a typo and should say "authentication" subkey and will be fixed in the updated draft. This is also a typo in the original RFC 9605, and I submitted an errata for that today.

>> > ### Why typically?
>> > 
>> > ```
>> >    *  Nt: The overhead in bytes of the encryption algorithm (typically
>> >       the size of a "tag" that is added to the plaintext)
>> > ```
>> > 
>> > In which cases is this not the size of the tag? Why the optionality here?
>> > 
>> 

This was the exact language from RFC9605, so I left it as is. With all the current Hash and Auth tag algorithms used in the current and proposed cipher suites (GCM and the hash as tag for the CTR modes), it is correct that it is *only* the tag length. If somebody came up with a new hash or tag computation approach it might not be true, hence why "typically" was used.