Thank you Tim! Opened two issues,
https://github.com/yaronf/I-D/issues?q=is%3Aissue+is%3Aopen+label%3ABCP195
Yaron
On 5/28/22, 00:17, "Tim Evens via Datatracker" <[email protected]> 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.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
