On Tue, Mar 7, 2023 at 6:51 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> What specific changes would you recommend in say the OpenSSL > implementation? Just not sending the useless tickets? Fine, we've > saved a bit of bandwidth, but haven't really solved the problem. > I don't know the details of the OpenSSL implementation or the behavior of a psk_ke only client attempting that resumption with an OpenSSL server. Not sending the useless tickets sounds like the right fix. It also sounds like we've solved the problem: In a case where a client that only supports psk_key for resumption modes is talking to a server that only supports psk_dhe_ke for resumption, useless information is no longer being sent over the wire and the client will always attempt a full handshake. > > We have somewhat different interoperability expectations, because I > expect resumption to work under typical conditions, which would include > clients sending just "psk_ke". Unless the server has a good reason to > expect all clients to always request "psk_dhe_ke", it should support > "psk_ke", leaving the client the option to negotiate "psk_dhe_ke" or use > "psk_ke" if preferred. > I expect resumption to work when both endpoints support the feature. TLS has multiple options (thankfully TLS 1.3 has many fewer than TLS 1.2), and only the full handshake is required. You're correct that the client should have the option to negotiate psk_dhe_ke or psk_ke (or none at all) as desired, and in the same vein the server has the option to negotiate psk_dhe_ke or psk_ke (or decline resumption) as desired. > > Resumption is an important optimisation, it can make the difference > between a scalable service and a degraded or unusable service. > I don't disagree. In application profiles where the optimization makes a critical difference, the resumption modes that make that difference should be specified as MTI. The key here is that they should only be MTI in those application profiles. > > There's no downgrade attack, if both sides want psk_dhe_ke, they get it. > If some application or private deployment never needs psk_ke resumption, > fine. But in the absence of specific knowledge a generic client using > TLS to reach some random server should be able to perform resumption > without the sort of friction that turning up forward-secrecy to 11 > introduces. The client *should* still offer psk_dhe_ke where it makes > sense, and servers *should* then use DHE resumption, but if the client > has good reason to choose "psk_ke" it should not be punished for its > choice to optimise for performance. > Why should a client be allowed to force a server to accept psk_ke over performing a full handshake? A server should be free to choose to always perform forward secret handshakes. When a client that prefers psk_ke talks to said server, it isn't being punished. The client is offered psk_dhe_ke, and if it doesn't like that, it can always do a full handshake. Each peer is entitled to their preferences, and the TLS handshake negotiates the best option for both endpoints. > > > This isn't a protocol issue. This is an implementation issue (buggy > > implementations sending psk_dhe_ke NSTs in response to psk_ke > ClientHellos) > > and an ecosystem issue. > > But sending the unusable tickets isn't the problem, the problem is that > non-DHE resumption is unavailable by default. Is that an implementation > bug or not? That's not an implementation bug, that's an ecosystem issue. As I said earlier, all of the pieces are there in RFC 8446. People just have to choose to use it. TLS is used in many different ways by different application protocols. Stating that a certain feature of TLS should be available in all TLS implementations is a high bar to pass — it must be near universally useful. Instead, each ecosystem that uses TLS can and should decide for itself which features are useful. Actors in those ecosystems can choose their implementations (or choose to create their own) based on the availability of TLS features.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
