> On Sep 27, 2023, at 11:02 AM, Andrew Stone (Nokia) <[email protected]> > 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. > # 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. > 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? > # 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 [email protected] https://www.ietf.org/mailman/listinfo/pce
