Hi Alan, Thank you for your reply! We have updated the document as requested and have a few followup questions/comments.
>> 23) <!-- [rfced] Should this citation be to BCP26 or RFC 8126? >> >> Current: >> This section provides guidance to the Internet Assigned Numbers >> Authority (IANA) regarding registration of values related to the TEAP >> protocol, in accordance with BCP 26 [RFC8126]. >> --> > > BCP 26. > >> 25) <!-- [rfced] Should this citation be to BCP 86 or RFC 3766? >> >> Current: >> Note 1. BCP 86 [RFC3766] offers advice on appropriate key sizes. The >> National Institute for Standards and Technology (NIST) also offers >> advice on appropriate key sizes in [NIST-SP-800-57]. >> --> > > BCP 86. 1) For #23 and #25, we have updated the corresponding text in the file when updating the BCP citations. Please review and let us know if the text appears as desired. >> 29) <!-- [rfced] References >> >> c) RFCs 5077, 5246, and 6961 have been obsoleted by RFC 8446. May we replace >> them with RFC 8446? If they must be referenced, we suggest mentioning >> RFC 8446 (e.g., RFC 6961 has been obsoleted by RFC 8446). See Section >> 4.8.6 in the RFC Style Guide (RFC 7322). >> --> > > Updating the references is fine. 2) Upon further review, we came across a few instances of text where we are unsure if updating to use RFC 8446 is correct. Please review each instance below and let us know how we should update. Note that we will continue to cite RFC 5246 where there is a direct mention of TLS 1.2. a) Original: TEAP is in full conformance with TLS ticket extension [RFC5077]. Separately, we note that this is the only mention of the term "TLS ticket extension", whereas "SessionTicket extension" is used multiple times in this document. Should the term be updated as follows? Perhaps: TEAP is in full conformance with the SessionTicket extension [RFC5077]. b) Original: It is REQUIRED that anonymous cipher suites such as TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] only be used in the case when the inner method provides mutual authentication, key generation, and resistance to on-path and dictionary attacks. (Note that TLS_DH_anon_WITH_AES_128_CBC_SHA does not appear in RFC 8446.) c) The challengePassword field is limited to 255 octets (Section 7.4.9 of [RFC5246] indicates that no existing cipher suite would result in an issue with this limitation). d) The TLS-PRF is defined in [RFC5246] as: PRF(secret, label, seed) = P_<hash>(secret, label | seed) (Note that this definition does not appear in RFC 8446.) e) Original: The derivation of S-IMCK is as follows: S-IMCK[0] = session_key_seed For j = 1 to n-1 do IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) S-IMCK[j] = first 40 octets of IMCK[j] CMK[j] = last 20 octets of IMCK[j] where TLS-PRF is the PRF (described above) negotiated as part of TLS handshake [RFC5246]. f) For instance, the Certificate Status Request extension [RFC6066] and the Multiple Certificate Status Request extension [RFC6961] can be used to leverage a certificate-status protocol… (Note: No mention of Multiple Certificate Status Request extension in RFC 8446.) The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9930.txt https://www.rfc-editor.org/authors/rfc9930.pdf https://www.rfc-editor.org/authors/rfc9930.html https://www.rfc-editor.org/authors/rfc9930.xml Diff files: https://www.rfc-editor.org/authors/rfc9930-diff.html https://www.rfc-editor.org/authors/rfc9930-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9930-auth48diff.html https://www.rfc-editor.org/authors/rfc9930-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9930-alt-diff.html (shows moved text) AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9930 Thank you! Madison Church -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
