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

Lars Eggert <> Tue, 12 July 2022 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DECCC14F735; Tue, 12 Jul 2022 10:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rlxtn6bm4Dnn; Tue, 12 Jul 2022 10:42:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AAA30C14F720; Tue, 12 Jul 2022 10:42:31 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 998F21D374B; Tue, 12 Jul 2022 20:42:22 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1657647743; bh=q9XlrnehbkFcOqh4j0I+pLIUVWxfMi3H2WfM8Dvxyrk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=iwya+I33bKsfhoggnF74G5yXGVbVuvVqZbuMxBrTMsRbn6CIfAt39vTWRK0FBvisv +/FSQpshn/2KiOErp3z3ZP2S3Yud+CApdbAx+Q5XFFLawAtbhIYzQwuG7sLNOv4hX+ Q4Minix0uhGz1cb1LEedKkl2n13lib9y3jcSWlC0=
Content-Type: multipart/signed; boundary="Apple-Mail=_D43B65DA-CD88-4AE1-B739-7491C78CB44E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Lars Eggert <>
In-Reply-To: <>
Date: Tue, 12 Jul 2022 10:42:15 -0700
Cc: General Area Review Team <>,,,
Message-Id: <>
References: <>
To: Tim Evens <>
X-MailScanner-ID: 998F21D374B.A5B8F
X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details
Archived-At: <>
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-uta-rfc7525bis-07
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jul 2022 17:42:35 -0000

Tim, thank you for your review. I have entered a Yes ballot for this document.


> On 2022-5-27, at 14:17, Tim Evens via Datatracker <> 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
> <>.
> 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