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

[Deb Cooley <[e-mail]>]

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]> wrote:

>
>
> On May 27, 2025, at 10:26, Deb Cooley via Datatracker <[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')


>
> 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.
>
>
>
>