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

[Yaron Sheffer <[e-mail]>]

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" <[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.