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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
