> On Oct 1, 2023, at 22:34, Andrew Stone (Nokia) <andrew.st...@nokia.com> wrote: > > Hi Russ, WG, > > Responses inline below. > > Thanks > Andrew > > From: Russ Housley <hous...@vigilsec.com> > Date: Wednesday, September 27, 2023 at 11:50 AM > To: "Andrew Stone (Nokia)" <andrew.st...@nokia.com> > Cc: "draft-ietf-pce-pceps-tl...@ietf.org" > <draft-ietf-pce-pceps-tl...@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.st...@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 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
