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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux