[TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

[Viktor Dukhovni <[e-mail]>]

I took a look at whether it is practically possible for a client to
"opt-in" to (ostensibly cheaper) non-DHE TLS 1.3 resumption by sending a
"psk_key_exchange_modes" extension consisting of just "psk_ke".

Turns out that at least when the server is OpenSSL, the client is likely
to be sad.

Details below, but my question based on the details is whether, when the
client offers just [psk_ke], servers should generally be willing to go
along and support non-DHE resumption?  For otherwise, clients that
don't also offer "psk_dhe_ke" are punished for their non-conformity.

It seems to me that in many cases, and perhaps by default, servers
should be liberal in this regard, and accept the client's security
posture.  In server-to-server communications (say DNS resolver via ADoT
to DNS authoritative) where "hogging" idle connections is "rude", but
CPU cost and latency are also a concern on both ends, one might want
to use "psk_ke" with PSK lifetimes of up to an hour, but this turns
out to be impractical, either by design, or lack of clarity on default
expected server behaviour.

Comments welcome.  [ The issue is likely to also carry over into QUIC,
but there perhaps keeping somewhat idle "connections" "open" is less of
a concern, and resumption may be less frequent??? ]

Details:

    - Unless the server is *explicitly* configured with a non-default
      option to support psk_ke resumption, an OpenSSL server will
      (incorrectly I believe) still issue NewSessionTickets (2 by
      default):

        https://mailarchive.ietf.org/arch/msg/tls/ACqre4e9-CWiwJrvdOCIDw0rdl4/

            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.

    - And of course, they will then be useless for resumption, which
      results in a full handshake, which again (by default) sends two
      useless tickets...  So sending only [psk_ke] to reduce the cost
      of resumption, actually has the opposite effect of completely
      defeating resumption.

    - If the client sends both "psk_ke" and "psk_dhe_ke", OpenSSL
      servers will always choose to do DHE.

So, unless an, e.g. OpenSSL, server is specifically known (oracular
local configuration?) to support "psk_ke", the client must avoid that
choice, making just [psk_ke] essentially impractical.  The client simply
has to accept the CPU cost of asymmetric key agreement on every
resumption, and hope to amortise the cost by keeping connections open
long enough to perform multiple operations, and not do resumption too
often.

-- 
    Viktor.