On Wed, May 2, 2018 at 4:57 PM, Benjamin Kaduk <bka...@akamai.com> wrote:
> 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. > What this text is supposed to mean is that the server shouldn't send tickets if it doesn't like the client's psk_ke modes. So, say that the client only supports psk_dhe_ke and the server only supports psk_ke, then the server shouldn't advertise tickets, because future resumption will be useless. -Ekr _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
