Viktor Dukhovni <ietf-d...@dukhovni.org> writes: >The protocol specification needs to say something along the lines of:
I'm not sure if this will work though. The PSK stuff is already the second biggest dog's breakfast in the spec (why are there two extensions used to communicate PSK information, with complex reconciliation rules needed between them?), full of special cases and exceptions and weird requirements (if the client asks for meat in pre_shared_key then the server must abort the handshake if it doesn't have red wine for its pre_shared_key unless the client has indicated it doesn't drink in its psk_key_exchange_modes or has negotiated a vegetarian option in signature_algorithms that will be used during the handshake or indicated they're vegan in signature_algorithms_cert), adding the list you've given just makes it an even more complex mess, assuming you can get implementations to both adopt it and get it right. I think a safer option moving forward is "scrap it and order a new one", just do an RFC with a new, single extension with unambiguous semantics that reintroduces the TLS classic session resumption, but done with TLS 1.3 mechanisms. In other words just a standalone psk_ke in a new extension with a description of "if the client sends this, use it". Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
