It was resolved as Hold For Document Update, because the bis document resolved it by saying:
In order to accept early data, the server MUST have selected the first key offered in the client's "pre_shared_key" extension. In addition, it MUST verify that the following values are the same as those associated with the selected PSK: The selected TLS version number The selected cipher suite The selected ALPN [RFC7301 <https://www.rfc-editor.org/rfc/rfc7301>] protocol, if any These requirements are a superset of those needed to perform a 1-RTT handshake using the PSK in question.Future extensions MUST define their interaction with 0-RTT. So no textual changes from the bis will be done for this errata, and this bis text is considered closing that errata issue. if you still disagree, please let me know and share your proposed changed text for the bis document :) Paul On Thu, Oct 17, 2024 at 6:06 PM Martin Thomson <m...@lowentropy.net> wrote: > Based on the snippet here, I agree with David. > > On Fri, Oct 18, 2024, at 07:19, David Benjamin wrote: > > I don't think this erratum is correct. This is due to some weird > > allowance in PSK acceptance. You are allowed to use the PSK with a > > different cipher suite if the hash portion matches. But early data > > requires an exact match on top of it. > > > > On Thu, Oct 17, 2024, 12:21 RFC Errata System <rfc-edi...@rfc-editor.org> > wrote: > >> The following errata report has been held for document update > >> for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> https://www.rfc-editor.org/errata/eid6147 > >> > >> -------------------------------------- > >> Status: Held for Document Update > >> Type: Editorial > >> > >> Reported by: Ben Smyth <resea...@bensmyth.com> > >> Date Reported: 2020-04-29 > >> Held by: Paul Wouters (IESG) > >> > >> Section: 4.2.10. > >> > >> Original Text > >> ------------- > >> In order to accept early data, the server MUST have accepted a PSK > >> cipher suite....In addition, it MUST verify that the > >> following values are the same as those associated with the > >> selected PSK: > >> > >> ... > >> > >> - The selected cipher suite > >> > >> Corrected Text > >> -------------- > >> > >> > >> Notes > >> ----- > >> Accepting the "PSK cipher suite" surely implies the PSK is associated > with the cipher suite, hence, > >> "The selected cipher suite" can be dropped. > >> > >> Paul Wouters(SEC AD): The text was changed a little to solve this issue > >> > >> -------------------------------------- > >> RFC8446 (draft-ietf-tls-tls13-28) > >> -------------------------------------- > >> Title : The Transport Layer Security (TLS) Protocol > Version 1.3 > >> Publication Date : August 2018 > >> Author(s) : E. Rescorla > >> Category : PROPOSED STANDARD > >> Source : Transport Layer Security > >> Stream : IETF > >> Verifying Party : IESG > >> > >> _______________________________________________ > >> TLS mailing list -- tls@ietf.org > >> To unsubscribe send an email to tls-le...@ietf.org > > _______________________________________________ > > TLS mailing list -- tls@ietf.org > > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
