I don't believe this is correct.
On Mon, Nov 14, 2022 at 8:50 AM RFC Errata System <[email protected]> wrote: > The following errata report has been submitted 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/eid7250 > > -------------------------------------- > Type: Technical > Reported by: Alan DeKok <[email protected]> > > Section: 4.6.1 > > Original Text > ------------- > The client MAY use this PSK for future handshakes by including the > ticket value in the "pre_shared_key" extension in its ClientHello > (Section 4.2.11). > > Corrected Text > -------------- > (to add) > > Where the client does not support session tickets, this extension MUST > be ignored. > This proposed change would be wrong because you can support PSKs without session tickets. > > Notes > ----- > I've seen a TLS implementation which doesn't implement session tickets. > That's fine, but the implementation doesn't *ignore* session tickets it > receives. Instead, it treats reception of the ticket as un recoverable > error, and drops the TLS connection. > > It's also worth adding a note to section 4.2 at the bottom of page 38. To > note that in general, f an extension isn't supported AND doesn't materially > affect the TLS exchange, THEN it should be ignored. > S 4.1.2 says: extensions: Clients request extended functionality from servers by sending data in the extensions field. The actual "Extension" format is defined in Section 4.2. In TLS 1.3, the use of certain extensions is mandatory, as functionality has moved into extensions to preserve ClientHello compatibility with previous versions of TLS. Servers MUST ignore unrecognized extensions. > i.e. there's nothing in the spec which mentions Postel's law "be > conservative in what you send, be liberal in what you accept". So > implementors reading this document are free to do all kinds of odd things. > Well, I don't think we should cite Postel's law for reasons stated in https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-09.html I do think this document should make clear cases where you are supposed to ignore specific unknown values. I think it does that for this, but if you have other examples, please file an issue on RFC 8446-bis: https://github.com/tlswg/tls13-spec/ > In addition, the text in Section 4.2 at the bottom of page 38 says: > > " > Designers > and implementors should be aware of the fact that until the > handshake has been authenticated, active attackers can modify > messages and insert, remove, or replace extensions. > " > > The implicit conclusion here is that an implementation receiving > extensions must sanity check them. e.g. an attacker adding an undefined / > unknown extension should not cause the entire session to be torn down. > Because the keys are derived from the handshake transcript, an attacker adding any extension or indeed changing any other part of the handshake should cause the handshake to fail. -Ekr > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > 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 > Area : Security > Stream : IETF > Verifying Party : IESG >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
