Hi,
I've taken an initial look at this version of the document and I see that
in a number
of cases references which were present in RFC 8446 have been changed.
For example:
RFC8446:
[Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication
Compiler for Key Exchange (with Applications to Client
Authentication in TLS 1.3", Proceedings of ACM CCS 2016,
October 2016, <https://eprint.iacr.org/2016/711>.
RFC9846-to-be:
[Kraw10] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", Cryptology ePrint Archive,
Paper 2010/264, 2010, <https://eprint.iacr.org/2010/264>.
This is a regression. The situation here is that this paper was published in
ACM CCS (a top 4 conference) but the proceedings aren't public, and so
the link is to ePrint, which is public. It's misleading to have the citation
be to ePrint as if this wasn't peer reviewed published work. It's of course
possible that this isn't exactly the paper that was presented at
CCS, but I think this is generally the right practice. There are quite a
few of these
and I think we should reverse them to match RFC 8446.
In addition, some spot-checking finds other places where there are minor
edits in
this document to text which is otherwise unchanged from RFC 8446, especially
around commas. I think there should be a fairly strong presumption that the
text in 8446 is correct and shouldn't be changed unless there is a real
error,
as opposed to just that upon repeated copy-edit someone thinks it reads
better.
Can the RPC please go through its proposed changes to identify variances
from RFC 8446 in text that is otherwise unchanged and reconsider whether
those changes are in fact necessary?
Thanks,
-Ekr
On Tue, Dec 16, 2025 at 6:17 AM Paul Wouters <[email protected]> wrote:
> This document requires a small change applied to it related to PKCS v1.5
> Eric has the change for this.
>
> Paul
>
>
>
> On Tue, Dec 16, 2025 at 12:06 AM <[email protected]> wrote:
>
>> Authors,
>>
>> While reviewing this document during AUTH48, please resolve (as
>> necessary)
>> the following questions, which are also in the source file.
>>
>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in
>> the title) for use on https://www.rfc-editor.org/search. -->
>>
>>
>> 2) <!-- [rfced] The document header indicates it obsoletes and updates
>> the
>> following RFCs:
>>
>> Obsoletes: 8446
>> Updates: 5705, 6066, 7627, 8422
>>
>> In the body of the document, we see the text below. Note that the
>> mentions of updates seem consistent with the document header. However, the
>> text specifies that it obsoletes more than just RFC 8446, likely because
>> RFC 8446 obsoleted those documents. Please review and let us know how/if
>> the header can be consistent with the body of the document.
>>
>> a) Abstract: Note that we removed 8422 from the obsoletes list because
>> this doc seemingly updates it.
>>
>> This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes
>> RFCs 5077, 5246, 6961, 8422, and 8446.
>>
>>
>> b) Introduction:
>>
>> This document supersedes and obsoletes previous versions of TLS,
>> including version 1.2 [RFC5246]. It also obsoletes the TLS ticket
>> mechanism defined in [RFC5077] and replaces it with the mechanism
>> defined in Section 2.2. Because TLS 1.3 changes the way keys are
>> derived, it updates [RFC5705] as described in Section 7.5. It also
>> changes how Online Certificate Status Protocol (OCSP) messages are
>> carried and therefore updates [RFC6066] and obsoletes [RFC6961] as
>> described in Section 4.4.2.1.
>>
>> -->
>>
>>
>> 3) <!--[rfced] The following RFCs have been obsoleted as follows. May
>> they
>> be replaced with the obsoleting RFC?
>>
>> RFC 6347 has been obsoleted by RFC 9147
>> RFC 6962 has been obsoleted by RFC 9162
>> RFC 7507 has been obsoleted by RFC 8996
>> -->
>>
>>
>> 4) <!-- [rfced] This reference appears to match the information for the
>> following Internet-Draft:
>> https://datatracker.ietf.org/doc/draft-hickman-netscape-ssl/
>>
>> May we update this reference to point to this I-D?
>>
>> Current:
>> [SSL2] Hickman, K., "The SSL Protocol", 9 February 1995.
>>
>> Perhaps:
>> [SSL2] Elgamal, T. and K. E. Hickman, "The SSL Protocol", Work in
>> Progress, Internet-Draft, draft-hickman-netscape-ssl-00,
>> 19 April 1995, <https://datatracker.ietf.org/doc/html/
>> draft-hickman-netscape-ssl-00>.
>> -->
>>
>>
>> 5) <!-- [rfced] We updated [I-D.ietf-tls-esni] to [PRE-RFC9849] for now.
>> We will make the final updates in RFCXML.
>>
>> -->
>>
>>
>> 6) <!--[rfced] As "requiring" and "should" seem to contradict in this
>> statement, may we remove "should" from the text below?
>>
>> Original:
>> * Clarify behavior around "user_canceled", requiring that
>> "close_notify" be sent and that "user_canceled" should be ignored.
>>
>> Perhaps:
>> * Clarify behavior around "user_canceled", requiring that
>> "close_notify" be sent and that "user_canceled" be ignored.
>> -->
>>
>>
>> 7) <!--[rfced] FYI - We have updated Figure 1 to fit the 72-character
>> limit. Please review and let us know if any further updates are needed.
>> -->
>>
>>
>> 8) <!--[rfced] The SVG in Figures 1 and 4 are outputting a solid circle
>> for
>> this text, while the figure displays *. Please review. One possible fix
>> would be to move the legend outside of the figure. Please review and let
>> us know how this may be updated.
>>
>> Original:
>> * Indicates optional or situation-dependent
>> messages/extensions that are not always sent.
>> -->
>>
>>
>> 9) <!--[rfced] Table 1
>>
>> a) FYI - We have updated the citation for "record_size_limit" from
>> [RFC8849] to [RFC8449], as [RFC8449] defines the extension and [RFC8849]
>> does not have any mention of it.
>>
>> Original:
>> record_size_limit [RFC8849]
>>
>> Current:
>> record_size_limit [RFC8449]
>>
>>
>> b) We note that RFC 9345 uses "delegated_credential" rather than
>> "delegated_credentials" (no "s"). May we update the extension to reflect
>> RFC 9345?
>>
>> Current:
>> delegated_credentials {{RFC9345}}
>> -->
>>
>>
>> 10) <!-- [rfced] Table 2 extends one character line beyond the width
>> limit.
>> We will play with this in the RFCXML file, but please let us know if you
>> see a good way to break the lines differently.
>> -->
>>
>>
>> 11) <!--[rfced] We believe the intention of this line to note that the
>> asterisk has a specific meaning when present. Please note that we will
>> update the XML to treat this as <dl>. Currently, kramdown treats this as
>> a bulleted list item, and definition list yields the following:
>>
>> *: Only included if present.
>> -->
>>
>>
>> 12) <!--[rfced] May we rephrase the definition of this error alert to
>> improve readability and provide clarity?
>>
>> Original:
>> unrecognized_name: Sent by servers when no server exists identified
>> by the name provided by the client via the "server_name" extension
>> (see [RFC6066]).
>>
>> Perhaps:
>> unrecognized_name: Sent by servers when no server that can be
>> identified
>> by the name provided by the client via the "server_name" extension
>> (see [RFC6066]) exists.
>> -->
>>
>>
>> 13) <!--[rfced] In Section 9.1, may we format these two items into an
>> unordered list?
>>
>> Original:
>> In the absence of an application profile standard specifying
>> otherwise:
>>
>> A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256
>> [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384
>> [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see
>> Appendix B.4).
>>
>> A TLS-compliant application MUST support digital signatures with
>> rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for
>> CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A
>> TLS-compliant application MUST support key exchange with secp256r1
>> (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].
>>
>> Perhaps:
>> In the absence of an application profile standard specifying
>> otherwise:
>>
>> * A TLS-compliant application MUST implement the
>> TLS_AES_128_GCM_SHA256
>> [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384
>> [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see
>> Appendix B.4).
>>
>> * A TLS-compliant application MUST support digital signatures with
>> rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for
>> CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A
>> TLS-compliant application MUST support key exchange with secp256r1
>> (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].
>> -->
>>
>>
>> 14) <!--[rfced] FYI, we have updated the parenthetical text as follows to
>> better describe the "TLS Supported Groups" registry. Please review and
>> let us know of any objections.
>>
>> Original:
>> This document updates two entries in the TLS Supported Groups
>> registry (created under a different name by [RFC4492]; now maintained
>> by [RFC8422]) and updated by [RFC7919] and [RFC8447].
>>
>> Current:
>> This document updates two entries in the "TLS Supported Groups"
>> registry (created under a different name by [RFC4492]; now maintained
>> by [RFC8422] and updated by [RFC7919] and [RFC8447]).
>> -->
>>
>>
>> 15) <!--[rfced] We note that some author comments are present in the
>> markdown file. Please confirm that no updates related to these comments
>> are
>> outstanding. Note that the comments will be deleted prior to publication.
>>
>> {::comment}Cite IND-CPA?{:/comment}
>>
>> {::comment}Cite INT-CTXT?{:/comment}
>> -->
>>
>>
>> 16) <!--[rfced] FYI - We have updated some artwork to sourcecode. Please
>> review and let us know if further updates are necessary.
>> -->
>>
>>
>> 17) <!-- [rfced] Please review whether any of the notes in this document
>> should be in the <aside> element. It is defined as "a container for
>> content that is semantically less important or tangential to the
>> content that surrounds it" (
>> https://authors.ietf.org/en/rfcxml-vocabulary#aside).
>> -->
>>
>>
>> 18) <!-- [rfced] FYI - We have added expansions for the following
>> abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
>> review each expansion in the document carefully to ensure correctness.
>>
>> Elliptic Curve Cryptography (ECC)
>> Finite Field DHE (FFDHE)
>> Internet of Things (IoT)
>> -->
>>
>>
>> 19) <!-- [rfced] Please review the "Inclusive Language" portion of the
>> online Style Guide <
>> https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>> and let us know if any changes are needed. Updates of this nature
>> typically result in more precise language, which is helpful for readers.
>>
>> For example, please consider whether the following should be updated:
>> dummy
>> man-in-the-middle
>>
>> In addition, please consider whether "traditionally" should be updated
>> for
>> clarity. While the NIST website
>> <
>> https://web.archive.org/web/20250203031433/https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8366.pdf>
>>
>> indicates that this term is potentially biased, it is also ambiguous.
>> "Tradition" is a subjective term, as it is not the same for everyone.
>> -->
>>
>>
>> 20) <!-- [rfced] FYI - we will convert the list of Contributors contained
>> within <artwork> to be listed with the <contact> element once the file is
>> converted to RFCXML.
>>
>> In addition, we will update the following reference entries that were a
>> challenge to update in markdown.
>>
>> [BBFGKZ16]
>> [BBK17]
>> [CCG16]
>> [CHECKOWAY]
>> [CHSV16]
>> [JSS15]
>> [LXZFH16]
>> [SLOTH]
>> [CK01]
>> [CLINIC]
>> [DH76]
>> [DOW92]
>> [HCJC16]
>> [RSA]
>> [SIGMA]
>> [FETCH]
>> [SHS]
>> [DSS]
>> [ECDP]
>> [KEYAGREEMENT]
>> -->
>>
>>
>> Thank you.
>> Alanna Paloma and Sandy Ginoza
>> RFC Production Center
>>
>> On Dec 15, 2025, at 8:57 PM, [email protected] wrote:
>>
>> *****IMPORTANT*****
>>
>> Updated 2025/12/15
>>
>> RFC Author(s):
>>
>> Your document has now entered AUTH48.
>>
>> The document was edited in kramdown-rfc as part of the RPC pilot test
>> (see
>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc).
>>
>>
>> Please review the procedures for AUTH48 using kramdown-rfc:
>>
>>
>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown
>>
>> Once your document has completed AUTH48, it will be published as
>> an RFC.
>>
>>
>> Files
>> -----
>>
>> The files are available here:
>> https://www.rfc-editor.org/authors/rfc9846.md
>> https://www.rfc-editor.org/authors/rfc9846.html
>> https://www.rfc-editor.org/authors/rfc9846.pdf
>> https://www.rfc-editor.org/authors/rfc9846.txt
>>
>> Diff file of the text:
>> https://www.rfc-editor.org/authors/rfc9846-diff.html
>> https://www.rfc-editor.org/authors/rfc9846-rfcdiff.html (side by side)
>>
>> Diff of the kramdown:
>> https://www.rfc-editor.org/authors/rfc9846-md-diff.html
>> https://www.rfc-editor.org/authors/rfc9846-md-rfcdiff.html (side by
>> side)
>>
>>
>> Tracking progress
>> -----------------
>>
>> The details of the AUTH48 status of your document are here:
>> https://www.rfc-editor.org/auth48/rfc9846
>>
>> Please let us know if you have any questions.
>>
>> Thank you for your cooperation,
>>
>> RFC Editor
>>
>> --------------------------------------
>> RFC 9846 (draft-ietf-tls-rfc8446bis-14)
>>
>> Title : The Transport Layer Security (TLS) Protocol Version 1.3
>> Author(s) : E. Rescorla
>> WG Chair(s) : Joseph A. Salowey, Sean Turner, Deirdre Connolly
>>
>> Area Director(s) : Deb Cooley, Paul Wouters
>>
>>
>>
>>
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
