Hi David, I'm still not sure, if there is just a misunderstanding:
For me, case 2, the support of legacy peers comes with using only full-handshakes, and no abbreviated handshakes. For the client the consequence is, to use full-handshakes with legacy servers. So, I would assume, that just the same applies for servers as well. If a legacy client tries to execute a resumption handshake, the server in mode 2 has two options to support such a legacy client according the general rule to only use "full-handshakes" and not "abbreviated" ones. - abort the client initiated abbreviated handshake in order to make the client restart with a full-handshake (that's what the RFC defines) - the server chose to fallback to a full-handshake directly in the same way, that the server would do, if no matching session id is available. https://datatracker.ietf.org/doc/html/rfc5246#page-36 "The client sends a ClientHello using the Session ID of the session to be resumed. The server then checks its session cache for a match. ... If a Session ID match is not found, the server generates a new session ID, and the TLS client and server perform a full handshake." With such a fallback by the server, the general rule, to only use "full-handshakes", will be also full filled. And the benefit would be, that the client doesn't need to send a second handshake. best regards Achim Kraus Am 28.10.21 um 19:44 schrieb David Benjamin:
It depends on what the server is trying to do. If the server is trying to mandate EMS, aborting the connection is correct. E.g. the full handshake section then says: If the server receives a ClientHello without the extension, it SHOULD abort the handshake if it does not wish to interoperate with legacy clients. Though I suppose the abbreviated handshake version is missing a "if it does not wish to interoperate with legacy clients". Yeah, okay, this probably also needs an erratum to add the right qualifier. Gosh this document is confusingly organized.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
