Re: [Pce] Shepherd Review of draft-ietf-pce-pceps-tls13-01

Sean Turner <sean@sn3rd.com> Tue, 03 October 2023 13:56 UTC

Return-Path: <sean@sn3rd.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D556FC1526ED for <pce@ietfa.amsl.com>; Tue, 3 Oct 2023 06:56:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 sSqv6lhiWyj7 for <pce@ietfa.amsl.com>; Tue, 3 Oct 2023 06:56:27 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 32B6DC1519AF for <pce@ietf.org>; Tue, 3 Oct 2023 06:56:27 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-41820eecff2so6671681cf.1 for <pce@ietf.org>; Tue, 03 Oct 2023 06:56:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; t=1696341386; x=1696946186; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5oHaa1FMX8j9pPb1or2O/VIey3oVuOZ6YWbr7qyZ+jo=; b=kYCwkWTrM1jSLRHZUqKlj0jrVikUP5+w2zugFY86tmLwsCZYALLkJZ2F+h/+RfmTUF dO2zWYr46h/reKB1UL2ayu+D+dzhAdtyuGA6SGDQrmrAKqGfpxbI4wcZJzTg7zUz1vNw bJ+l+qyl8vH7jjmXDnAsYN7Odcn9QOeqUQBNU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696341386; x=1696946186; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5oHaa1FMX8j9pPb1or2O/VIey3oVuOZ6YWbr7qyZ+jo=; b=eugg7pNjdkAC9uQMXVAnOtTLjp7aAkH2gpazOr/GVYRUDUdlfSpGsLzn1m70ZAI5yG ViuUFAmLcqBv9AcNSQPTlLEEyEcL9mXpY1VjR6s9qnYs5/LeEyrC6naDuW2M4xWxGtar nK4F3prITn60M8a4WjUGqcd9m5RXHhJGkOk+RQ4gmWX+rWsyRxBOVmVv0C33AMhF5o2F ocTsr3Bfz0NF+2zCP2w/9O44UFYgJiiUQsCuL7jxN4B/tb+6ESw0m2h2jKWHbiAh/0Jf 7CgLch8b5kXCLjmED7IN7uQMOPtVbpiKKQ8bJ+N5NWImCiMeSdHyjTF1jyML582XHqKo EBCQ==
X-Gm-Message-State: AOJu0YwPwbtOojoYBbhWjLhoOSWND905Yz9FqVoHDyX0X3ixcmaUrFuD uC+F5zjv4PZUR4+ZnM5HnxhZBw==
X-Google-Smtp-Source: AGHT+IFsNvmthHQrPR67RgVJQ9VpSnsE2puLMEsNTMFsW3HVF6LjYUlvPFzSUTlQKqkwJuSw0vGwlQ==
X-Received: by 2002:a05:6214:e62:b0:65b:2b67:13c4 with SMTP id jz2-20020a0562140e6200b0065b2b6713c4mr18219889qvb.61.1696341386041; Tue, 03 Oct 2023 06:56:26 -0700 (PDT)
Received: from smtpclient.apple ([2600:4040:253b:7300:c9bc:ca75:799:7909]) by smtp.gmail.com with ESMTPSA id g1-20020a0cdf01000000b006590d020260sm490730qvl.98.2023.10.03.06.56.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Oct 2023 06:56:25 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <C570E56C-1E33-4AAF-AC5A-F443E4D9CB05@nokia.com>
Date: Tue, 03 Oct 2023 09:56:24 -0400
Cc: Russ Housley <housley@vigilsec.com>, "draft-ietf-pce-pceps-tls13@ietf.org" <draft-ietf-pce-pceps-tls13@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <144649BE-01F9-4836-A881-F839E304B327@sn3rd.com>
References: <2B797E54-1FA7-4EA4-8016-38DA84CF21FE@nokia.com> <BAEDB84B-8D7C-4002-B29A-8DF1631A6B59@vigilsec.com> <C570E56C-1E33-4AAF-AC5A-F443E4D9CB05@nokia.com>
To: "Andrew Stone (Nokia)" <andrew.stone@nokia.com>
X-Mailer: Apple Mail (2.3654.120.0.1.15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/1R6AjC02jOuYINvzPyjv_QMAow8>
Subject: Re: [Pce] Shepherd Review of draft-ietf-pce-pceps-tls13-01
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Oct 2023 13:56:31 -0000


> On Oct 1, 2023, at 22:34, Andrew Stone (Nokia) <andrew.stone@nokia.com> wrote:
> 
> Hi Russ, WG,
>  
> Responses inline below. 
>  
> Thanks
> Andrew
>  
> From: Russ Housley <housley@vigilsec.com>
> Date: Wednesday, September 27, 2023 at 11:50 AM
> To: "Andrew Stone (Nokia)" <andrew.stone@nokia.com>
> Cc: "draft-ietf-pce-pceps-tls13@ietf.org" <draft-ietf-pce-pceps-tls13@ietf.org>, "pce@ietf.org" <pce@ietf.org>
> Subject: Re: Shepherd Review of draft-ietf-pce-pceps-tls13-01
>  
>  
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>  
>  
> 
> 
>> On Sep 27, 2023, at 11:02 AM, Andrew Stone (Nokia) <andrew.stone@nokia.com> wrote:
>>  
>> Hi authors of draft-ietf-pce-pceps-tls13,
>>  
>> I’ve been selected as the document shepherd for this draft.
>>  
>> Thank you for the work on this document. The direct references to draft-ietf-tls-rfc8446bis sections were useful and the document is well written.
>>  
>> From a quick peak at messages from [1], it seems like WGLC consensus was reached on draft-ietf-tls-rfc8446bis + some follow up discussions which appear to be resolved(?) thus draft-ietf-tls-rfc8446bis is also pending a Shepherd writeup. It seems both documents are in similar same state (?).  Given the size and complexity differences I assume draft-ietf-tls-rfc8446bis will progress slower than this document (as hinted by editor note in the introduction as well), is the plan to still continue with the bis as a normative reference?
>>  
>> Taking into consideration the outstanding review comments [2], [3], some additional comments/questions from reading -01:
>>  
>> # From ID NITS:
>>  
>> 	• >Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
>> 		• (Considering the use inside the document and what is intended by referencing it I believe this is okay, but still wanted to point it out that it’s been picked up by the tool)
>  
> This reference is correct.
>  
> <Andrew> ACK 
>  
>> # Comments:
>> 
>>>  
>> 	• Abstract: uses "TLS" abbreviation, should be changed to: "..PCEP messages with Transport Layer Security (TLS) 1.2..."
>>  
>> 	• I was similarly unclear as Stephane regarding what does this document update for TLS 1.2 on RFC8253, but after going over it a few times, concluded this updates RFC8253 by bringing in RFC9325 recommendations and applying it to TLS 1.2 in the RFC8253 context. Is that the case? If so, it would be clearer in the introduction to make the point that RFC8253 TLS. 1.2 usage is being updated with recommendations from RFC5246.
>  
> We originally wrote a document that only talked about TLS 1.3, but the WG felt that it was better to update RFC 8253 to cover TLS 1.2 and TLS 1.3.
>  
> <Andrew> ACK, Sounds good to me then. 
> 
> 
>> 	• Editor Note in the Introduction should remark also updating appendix references in the document if draft-ietf-tls-rfc8446bis normative referenced is reduced to RFC8446
>>  
>> 	• Section 3 paragraph 2 – Replace E.5 with F.5 for the bis reference (…not use early data without a profile..). E.5 is correct for rfc8446, but is F.5 in draft-ietf-tls-rfc8446bis.
>>  
>> 	• Similar question to Stephanes regarding why no reference to RFC8253 in the security considerations? is one required and does this actually update RFC8253 security considerations? As well, the second paragraph seems like it can be removed as all it seems to dop is re-describe what PCE/PCEP is without discussing the security considerations or any explicit consideration updates. 
>  
> Do we want to be blocked on the publication of draft-ietf-tls-rfc8446bis?
>  
> <Andrew> At this moment I suspect not, but would defer this to the WG as a whole and the PCE WG chairs.  My own opinion is this doesn’t seem to have an explicit requirement on the BIS and happy to see it move forward with the base RFC8446 reference. Chairs, WG input?

I should note that 8446 is pinned on the TLS chairs getting their act together, which hopefully shouldn’t take all that long to unwind.  I’m also not sure there’s harm in waiting a bit.  But, I will totally bend to the will of the WG :)

spt

>> # Suggestion:
>> 
>>>  
>> OLD:
>> Note that TLS 1.3 can be used without early data as per Appendix F.5 of [I-D.ietf-tls-rfc8446bis]. In fact, early data is permitted by TLS 1.3 only when the client and server share a Pre-Shared Key (PSK), either obtained externally or via a previous handshake.
>>  
>> NEW:
>> TLS 1.3 can be used without early data as per Appendix F.5 of [I-D.ietf-tls-rfc8446bis], and allows early data only if both the client and server possess a shared Pre-Shared Key (PSK) obtained externally or from a previous handshake.
>  
> This depends on the answer to blocking on the publication of draft-ietf-tls-rfc8446bis.
>  
> Russ