Re: [Uta] Genart last call review of draft-ietf-uta-rfc7525bis-07
Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 27 May 2022 21:31 UTC
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4484C14F717; Fri, 27 May 2022 14:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p2D98CAYyUf; Fri, 27 May 2022 14:31:14 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8D7C14F6F8; Fri, 27 May 2022 14:31:11 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id q203so5983407iod.0; Fri, 27 May 2022 14:31:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=MYm41s89jyo0G9/SnRFFlg/+o1Pq+5eHbjuhqmXcrdk=; b=j+YIj8UXJNR1eXZ/qenzPpJSqoyJatU9YJu0d//0NxB1d244jS2iaNNMU+q0gD7MxM JI3KKdVsP5R2F94wctawdAIR4/ZVfJD7ynMS77wf/XZDxrIw7zVJH5aPHeErfER9HSK5 d0yK/LjGP2uT9+dVVU28D26tIYIRRGd+2OtrgxW+IpmpQFFWzwBG4/JIS+ahpC+wUmpD y/wGrt+pImQBDH6aPqRQgATZfQ7ct+Cz+aT2EmXOnHWTYPlsPWToNUqmEZWAYhkzpvzY 0yJaREXoqOUBvRAzsHmp1HE0MgpHoNTjgRsFkwcOsCnTtGZDqJHzta73jGUQqrSH+ikb tFbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=MYm41s89jyo0G9/SnRFFlg/+o1Pq+5eHbjuhqmXcrdk=; b=c26o1POeNMX4IcqkD9qJvQhIZbcFWeU5uzVmM1/tD2qMr/FUP1STv+PKHFyhNM45oM BRx0pEJEaUddyFCc9ydhH3l225Ws49Bj0bdPhLxaA/JKlyGNwd2b0Wof8F8o3aaebBhK YoZgyWYMFa0L7kAFxtt6sz4TMPKIwe2aARFIGT4L7V7fDfltTpENq+WU5QbbBRyqCswH MunYCpZPUwn0iJ1nhhA5pi0KWT3w6gnRjusj8KiZEIFWmnNyjdzQbpPwVeBn+LpA6K/Z cXGyvgwq5pqQQmXCqbeD5LxL3UOTH/ZvYoCkWFsto65gHdWMDYPDzxDsj7sXJJjLBhQz SkBQ==
X-Gm-Message-State: AOAM531kNCOGVfrVl0CvLYirh025Hh9PGcwzS9DPtn8Rk8FuHTcyZ0+F M9dD6TUrQEDYJ2cjxha/MKi1wnC+t+A=
X-Google-Smtp-Source: ABdhPJy2DDs1K7lrvsy2y+T/WjS89KHZLh9GsVPlGp+LbEGap0+Jr2nD66MuX/DeW33mPqFGwMXNNw==
X-Received: by 2002:a02:b693:0:b0:32d:adc7:ad17 with SMTP id i19-20020a02b693000000b0032dadc7ad17mr23721603jam.266.1653687068856; Fri, 27 May 2022 14:31:08 -0700 (PDT)
Received: from [192.168.68.100] (IGLD-84-229-147-76.inter.net.il. [84.229.147.76]) by smtp.gmail.com with ESMTPSA id z1-20020a02cea1000000b0032ebb709cb8sm843556jaq.103.2022.05.27.14.31.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 May 2022 14:31:08 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.61.22050700
Date: Sat, 28 May 2022 00:31:03 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: Tim Evens <tievens@cisco.com>, gen-art@ietf.org
CC: draft-ietf-uta-rfc7525bis.all@ietf.org, last-call@ietf.org, uta@ietf.org
Message-ID: <4A82580B-F9C0-491B-AA82-D8502FD52F01@gmail.com>
Thread-Topic: Genart last call review of draft-ietf-uta-rfc7525bis-07
References: <165368622922.5878.7619629078890912211@ietfa.amsl.com>
In-Reply-To: <165368622922.5878.7619629078890912211@ietfa.amsl.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/JmJGI--981F23p7LfTw7XMImeik>
Subject: Re: [Uta] Genart last call review of draft-ietf-uta-rfc7525bis-07
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 May 2022 21:31:14 -0000
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" <noreply@ietf.org> 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] Genart last call review of draft-ietf-uta-r… Tim Evens via Datatracker
- Re: [Uta] Genart last call review of draft-ietf-u… Yaron Sheffer
- Re: [Uta] [Last-Call] Genart last call review of … Lars Eggert