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)
# 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.
* 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.
# 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.
Thanks
Andrew
[1] https://mailarchive.ietf.org/arch/browse/tls/?q=draft-ietf-tls-rfc8446bis
[2] https://mailarchive.ietf.org/arch/msg/pce/JmSlc7PT-ms120LXfrldyenG7Bc/
[3] https://mailarchive.ietf.org/arch/msg/pce/SCyLmChul8v27cf-C7EdwNqxfoQ/
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
