Re: [Uta] [Last-Call] Genart last call review of draft-ietf-uta-rfc7525bis-07

[Lars Eggert <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call