[TLS] Re: Deb Cooley's No Objection on draft-ietf-tls-rfc8447bis-12: (with COMMENT)

[Sean Turner <[e-mail]>]

> On May 28, 2025, at 10:55, Deb Cooley <[e-mail]> wrote:
> 
> inline w/ [DC].  I'm fine w/ no changes, just pushing a little on your definitions....
> 
> Deb
> 
> On Wed, May 28, 2025 at 10:00 AM Sean Turner <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>>> On May 27, 2025, at 10:26, Deb Cooley via Datatracker <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Deb Cooley has entered the following ballot position for
>>> draft-ietf-tls-rfc8447bis-12: No Objection
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
>>> for more information about how to handle DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/
>>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> Thanks to Ben Schwartz for their secdir review.
>>> 
>>> Section 4:  Is there a note to be added to 'connection_id'?  (just looks a
>>> little weird to have notes for the other three)
>> 
>> So the comment was to have enough info to be able to track why it was (deprecated). The reference column already refers to RFC9146, which includes this:
>> 
>> Although the value 53 had been allocated by early allocation for a previous version of this document, it is incompatible with this document. Therefore, the early allocation has been deprecated in favor of this assignment.
>> 
>> So, I think it’s clear why it was deprecated.
> 
> [DC] this is fine.
>  
>> 
>>> Section 9:  Why is 'none' recommended 'Y' (it seems like this should be D)? 
>>> And what is the difference between 'none' and 'intrinsic’?
>> 
>> Not much, except that I think if you’re using ed25519 or ed448 you would use Intrinsic:
>> 
>> none meaning is:
>> 
>> The "none" value is provided for future extensibility, in case of a
>> signature algorithm which does not require hashing before signing.
>  
> [DC] Is there an example envisioned where 'does not require hashing before signing' is not actually the hash is incorporated into the signing algorithm (which is intrinsic apparently)?  I guess if the data is short (smaller than the hash output would be).  But how likely is that?  Is there a comment explaining when this is/isn't applicable?  (because it is a 'Y')

No example envisioned. It was an open ended place holder for future algorithms that might work that way.

As far as a comment, when an algorithm is defined then it will say when it is or is not applicable ;)

>> Intrinsic meaning is:
>> 
>> For bits-on-the-wire compatibility with TLS 1.3, we define a new
>> dummy value in the "TLS HashAlgorithm" registry that we call
>> "Intrinsic" (value 8), meaning that hashing is intrinsic to the
>> signature algorithm.
>> 
>>