Tim, thank you for your review. I have entered a Yes ballot for this document. Lars > On 2022-5-27, at 14:17, Tim Evens via Datatracker <noreply@xxxxxxxx> wrote: > > 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
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
