On Mon, Apr 23, 2018 at 01:45:34PM +0200, Daiki Ueno wrote: > Hello, > > I have a question about handling the psk_key_exchange_mode extension. > > 4.2.9. Pre-Shared Key Exchange Modes says: > > This extension also restricts the modes for use with PSK resumption; > servers SHOULD NOT send NewSessionTicket with tickets that are not > compatible with the advertised modes > > Is this compatibility defined externally to the protocol, or does it > depend on the initial handshake? > > To take an example, suppose the server uses the ticket construction > mechanism described in RFC 5077. > > If the former is the case, the server requires PSK with (EC)DHE when the > ticket encryption key is required to be forward secret. From the > implementation point of view, that would be provided as an option in the > server configuration. > > On the other hand, if the latter is the case, the server requires PSK > with (EC)DHE when the initial handshake chose (EC)DHE key exchange, > because the ticket is tied to resumption_master_secret derived from the > (EC)DHE secret. > > Since the above paragraph is followed by: > > however, if a server does so, the impact will just be that the > client’s attempts at resumption fail. > > I thought the latter is more plausible; however, in that case psk_ke > would only be meaningful when the initial handshake is PSK-only.
It looks like this came in with https://github.com/tlswg/tls13-spec/pull/672 which doesn't provide much commentary on the motivation for it. I believe the latter is the case, in that the issued ticket contains information about the psk_key_exchange_modes sent in the initial handshake, but I disagree with your interpretation that it is only meaningful when the initial handshake is PSK-only. (To be fair, the existing text is not very clear about what it should mean, so confusion is understandable.) In particular, I think "also restricts the modes for use with PSK resumption" means that the psk_key_exchange_modes value(s) sent in the ClientHello is supposed to be retained by both parties and associated with the session ticket, and the saved value(s) then restrict what mode can be used for resumption, along with what values are sent in the resumption handshake itself. This would be useful if, for example, a client sends psk_key_exchange_modes of just psk_dhe_ke in an initial (non-resumption) handshake, so the server can store state in the session ticket that indicates the session ticket must not be used for a psk_ke resumption flow. The text about "SHOULD NOT send NewSessionTicket with tickets that are not compatible with the advertised modes" is then pretty devoid of content, since any given PSK (considered as a string of bits) could be used for either psk_ke or psk_dhe_ke -- the math doesn't care. It perhaps means that if the server gets this psk_dhe_ke initial handshake and then stores a session ticket which only references psk_ke, the resumption would fail, but the server has no reason to do that, so we probably didn't even need to say it. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
