Hi Dhruv and Russ, >>> 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? > > Russ: 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. > > Dhruv: And the same guidance has been issued in RFC9190 and > draft-ietf-netconf-over-tls13 (past IETF LC). Ok, I had a look, and the MUST NOT text in the pceps draft seems to be aligned. I guess people are aware of the security risks with early data, so no further justification is needed :) So, I am fine with the current text, and withdraw my minor issue Q1. Regards, Christer >> On Dec 8, 2023, at 6:51 AM, Christer Holmberg via Datatracker >> <mailto:noreply@xxxxxxxx> 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 >> mailto:last-call@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/last-call > -- > last-call mailing list > mailto:last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
