Re: [Last-Call] Genart last call review of draft-ietf-pce-pceps-tls13-02

Russ Housley <housley@vigilsec.com> Mon, 11 December 2023 19:35 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16FFC15107E; Mon, 11 Dec 2023 11:35:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 UC0Rzwo36oio; Mon, 11 Dec 2023 11:35:17 -0800 (PST)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 74C6BC151078; Mon, 11 Dec 2023 11:35:17 -0800 (PST)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id D19B7184977; Mon, 11 Dec 2023 14:35:16 -0500 (EST)
Received: from smtpclient.apple (unknown [96.241.2.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id BAA1B1847E2; Mon, 11 Dec 2023 14:35:16 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_AD2AAAE3-09EB-45B1-81D6-85F385BC9D9B"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <HE1PR07MB4441EEDA5501B8B5C1500893938FA@HE1PR07MB4441.eurprd07.prod.outlook.com>
Date: Mon, 11 Dec 2023 14:35:06 -0500
Cc: IETF Gen-ART <gen-art@ietf.org>, "draft-ietf-pce-pceps-tls13.all@ietf.org" <draft-ietf-pce-pceps-tls13.all@ietf.org>, Last Call <last-call@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E9A1A76-65BF-4B46-9432-D16FF55AC92B@vigilsec.com>
References: <170203631643.25271.3343940506201552538@ietfa.amsl.com> <0CCFDFF7-BA6A-4DE3-939F-CD82F2FDD9E0@vigilsec.com> <HE1PR07MB4441EEDA5501B8B5C1500893938FA@HE1PR07MB4441.eurprd07.prod.outlook.com>
To: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3731.700.6)
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/P8DuVTq_GRX_6cKLB7sxBzAIY_M>
Subject: Re: [Last-Call] Genart last call review of draft-ietf-pce-pceps-tls13-02
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Dec 2023 19:35:18 -0000

Hi Christer.

>> Section 2.3 of RFC 8446 explains that the security provided to early data is 
>> weaker than
>> the security provided to other kinds of TLS data.  This is the reason that 
>> PCEPS MUST NOT
>> make use of early data.  Will a note with a pointer to this text (or a 
>> pointer to the same part
>> of draft-ietf-tls-rfc8446bis) resolve this minor issue?
> 
> The second Note already points to the text in Section 2.3 of 8446. My issue is 
> not the fact that early data security is weaker, but why that is an issues for 
> PCEPS. Is there some specific property of requirement for PCEPS behind the 
> MUST NOT?

We are simply saying that PCEPS MUST NOT use early data.  We could not find a case where it is needed today, and we are concerned that sone future evolution of PCEPS might use it without understanding the associated security risk.

Russ


>> On Dec 8, 2023, at 6:51 AM, Christer Holmberg via Datatracker 
>> <noreply@ietf.org> wrote:
>> 
>> Reviewer: Christer Holmberg
>> Review result: Almost Ready
>> 
>> 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://wiki.ietf.org/en/group/gen/GenArtFAQ>.
>> 
>> Document: draft-ietf-pce-pceps-tls13-02
>> Reviewer: Christer Holmberg
>> Review Date: 2023-12-08
>> IETF LC End Date: 2023-12-19
>> IESG Telechat date: Not scheduled for a telechat
>> 
>> Summary: The document is well written, and easy to understand. I do
>> have one Minor issue/question and a few Editorial issues/questions
>> that I would like the authors to address.
>> 
>> Major issues: N/A
>> 
>> Minor issues:
>> 
>> Q1:Section 3 adds text saying that PCEPS implementations MUST NOT use
>> early data, and there are a couple of notes about what early data is.
>> However, I cannot find text which explains the "MUST NOT use". If the
>> case where early media is permitted does not apply to PCEPS it would
>> be good to add text which explains it. It would also be good to
>> explain the reason in the Introduction of this document.
>> 
>> Nits/editorial comments:
>> 
>> Q2:In a few places the text says "TLS protocol", and in other places "TLS".
>> Would it be possible to use "TLS" everywhere?
>> 
>> Q3: Section 6 indicates that there are no known implementations when
>> version
>> -02 of the draft was posted. If that is still the case when the RFC is
>> published, could the whole section be removed?
>> 
>> Q4: Related to Q3, if the section remains (e.g., because there are
>> known implementations), I suggest to say "time of publishing this
>> document" instead of "time of posting of this Internet-Draft".
>> 
>> 
>> --
>> last-call mailing list
>> last-call@ietf.org
>> https://www.ietf.org/mailman/listinfo/last-call
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call