[Uta] Genart last call review of draft-ietf-uta-rfc7525bis-07

[Tim Evens via Datatracker <[e-mail]>]

Reviewer: Tim Evens
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-uta-rfc7525bis-??
Reviewer: Tim Evens
Review Date: 2022-05-27
IETF LC End Date: 2022-05-30
IESG Telechat date: Not scheduled for a telechat

Summary: Well written and informational draft.

Major issues:

Minor issues:

Section 1, introduction; incorrectly states "Datagram Transport Security Layer
(DTLS)" when it should be "Datagram Transport Layer Security (DTLS)"

Nits/editorial comments:
Can update [I-D.ietf-tls-dtls13] to [RFC9147].

In section 3.2, the first bullet point makes sense, but does the below
need to be there?

   "Because dynamic upgrade methods depend on negotiations
    that begin over an unencrypted channel (e.g., the server might
    send a flag indicating that TLS is supported or required), they
    are subject to downgrade attacks (e.g., an attacker could remove
    such indications); if the server does not indicate that it
    supports TLS, a client that insists on TLS protection would simply
    abort the connection, although the details might depend on the
    particular application protocol in use. In any case, ..."

Considering this ends with "In any case" I tend to lean towards not
mentioning the wordy description of dynamic upgrade methods. For
example, how about the below?

 *  Many existing application protocols were designed before the use
    of TLS became common.  These protocols typically support TLS in
    one of two ways: either via a separate port for TLS-only
    communication (e.g., port 443 for HTTPS) or via a method for
    dynamically upgrading a channel from unencrypted to TLS-protected
    (e.g., STARTTLS, which is used in protocols such as SMTP and
    XMPP).  Regardless of the mechanism for protecting the communication
    channel, TLS-only port or a dynamic upgrade method, what matters is
    the end state of the channel.  When TLS-only communication is
    available for a certain protocol, it MUST be used by implementations
    and MUST be configured by administrators.  When a protocol only supports
    dynamic upgrade, implementations MUST enable a strict local policy
    (a policy that forbids fallback to plaintext) and administrators
    MUST use this policy.

"Sec. of" is used instead of "Section of" in the document.  Normally this would
be consistent throughout the document.