[Emu] Lars Eggert's No Objection on draft-ietf-emu-eap-tls13-20: (with COMMENT)

Lars Eggert via Datatracker <noreply@ietf.org> Thu, 30 September 2021 12:22 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: emu@ietf.org
Delivered-To: emu@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A066C3A0B26; Thu, 30 Sep 2021 05:22:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Lars Eggert via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-emu-eap-tls13@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Joseph Salowey <joe@salowey.net>, joe@salowey.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.38.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Lars Eggert <lars@eggert.org>
Message-ID: <163300455762.6020.7934912747983319097@ietfa.amsl.com>
Date: Thu, 30 Sep 2021 05:22:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/C6cTrBK7FeiF9K5m9eHYrUjUCK8>
Subject: [Emu] Lars Eggert's No Objection on draft-ietf-emu-eap-tls13-20: (with COMMENT)
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2021 12:22:38 -0000

Lars Eggert has entered the following ballot position for
draft-ietf-emu-eap-tls13-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.1.4. , paragraph 4, nit:
-       server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and
-       no data from the EAP-TLS peer, follwed by EAP-Success from the
+       server, followed by an EAP-Response packet of EAP-Type=EAP-TLS and
+                   +
+       no data from the EAP-TLS peer, followed by EAP-Success from the
+                                          +

Section 2.1. , paragraph 5, nit:
> t encrypt significant amounts of data so this functionality is not needed. I
>                                      ^^^
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

Section 2.1.7. , paragraph 3, nit:
> ods can use the TLS exporter in a similar fashion, see [I-D.ietf-emu-tls-eap-
>                              ^^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

Section 2.1.7. , paragraph 3, nit:
> o truncate the output by requesting less data from the TLS-Exporter function
>                                     ^^^^
Did you mean "fewer"? The noun data is countable.

Section 2.2. , paragraph 5, nit:
>  in EAP-TLS with TLS 1.3 is stronger as authentication with revoked certific
>                                      ^^
Comparison requires "than", not "then" nor "as".

Section 2.5. , paragraph 2, nit:
> ovide integrity and replay protection but MAY be unauthenticated. Protected f
>                                      ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 2.5. , paragraph 6, nit:
> dresses, IP addresses, port numbers, WiFi SSID, etc.). EAP-TLS servers implem
>                                      ^^^^
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

Section 4. , paragraph 4, nit:
>  layer. To perform resumption in a secure way, the EAP-TLS peer and EAP-TLS
>                               ^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

Section 5.1. , paragraph 5, nit:
> e the session ID or PSK identity to lookup this information during resumption
>                                     ^^^^^^
The word "lookup" is a noun. The verb is spelled with a white space.

Section 5.1. , paragraph 6, nit:
> ached data cannot be retrieved in a secure way, resumption MUST NOT be done.
>                                ^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

Section 5.4. , paragraph 1, nit:
> e without access to cached data. Therefore systems which expect to perform a
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Therefore".

Section 5.4. , paragraph 6, nit:
>  do not contain any cleartext privacy sensitive information. Tracking of use
>                               ^^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 5.5. , paragraph 3, nit:
>  typically visible. How much privacy sensitive information the domain name l
>                              ^^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 5.6. , paragraph 3, nit:
> a cryptographically secure way so that that it is computationally infeasible
>                                   ^^^^^^^^^
Possible typo: you repeated a word.

Reference [RFC2560] to RFC2560, which was obsoleted by RFC6960 (this may be on
purpose).

Reference [RFC4282] to RFC4282, which was obsoleted by RFC7542 (this may be on
purpose).

Reference [RFC4346] to RFC4346, which was obsoleted by RFC5246 (this may be on
purpose).

Reference [RFC2246] to RFC2246, which was obsoleted by RFC4346 (this may be on
purpose).

Reference [RFC5077] to RFC5077, which was obsoleted by RFC8446 (this may be on
purpose).

Reference [RFC5246] to RFC5246, which was obsoleted by RFC8446 (this may be on
purpose).

Reference [RFC3280] to RFC3280, which was obsoleted by RFC5280 (this may be on
purpose).

Document references draft-ietf-tls-md5-sha1-deprecate-08, but -09 is the latest
available revision.