[Uta] Roman Danyliw's Yes on draft-ietf-uta-rfc7525bis-09: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-uta-rfc7525bis-09: Yes

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-uta-rfc7525bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Ben Kaduk for the SECDIR review.

** Section 3.2
  When TLS-only
  communication is available for a certain protocol, it MUST be used
  by implementations and MUST be configured by administrators.

This guidance seems a little vague but prescriptive.  Is the guidance that if
there is a TLS-version or TLS support for a given protocol, that
implementations of that protocol “MUST” support it?  My confusion is around the
wording that “it must be used by implementations.”

** Section 3.2
        When
        a protocol only supports dynamic upgrade, implementations MUST
        provide a strict local policy (a policy that forbids use of
        plaintext in the absence of a negotiated TLS channel) and
        administrators MUST use this policy.

Aren’t site administrators responsible for setting and enforcing local policy? 
Why would the software vendor (implementations) be provided the policy?

** Section 3.3.1

-- Given that the recommendations of this section include things beyond
certificate compression, is the title of “Certificate Compression” appropriate?

-- Would there be any additional techniques to list per Section 4 of RFC9191?

** Section 4.4
        When a sender is approaching CL, the implementation SHOULD initiate a
        new handshake (or in TLS 1.3, a Key Update) to rotate the session
        key.

        When a receiver has reached IL, the implementation SHOULD close the
        connection.

Should these normative SHOULDs be MUSTs?  What is the circumstance where it
would be prudent or necessary sender to use the existing key material after the
CL has been exceeded?  Same issue on the IL limit.