Re: [TLS] psk_key_exchange_mode question

[Eric Rescorla <[e-mail]>]

On Wed, May 2, 2018 at 4:57 PM, Benjamin Kaduk <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>