[TLS] 0-RTT security considerations (was OPTLS)

[Nico Williams <[e-mail]>]

Following up to the OPTLS proposal I thought it'd be interesting to
explore the security (API, and other) considerations of 0-RTT protocols.
I'm not sure[0] how much this has been done on this list before, so pardon
me if this is noisy.

My experience with 0-RTT is mostly from GSS [RFC2743] and Kerberos
[RFC4120], where the matter was given some explicit treatment treatment
many years ago.  That treatment is not complete, so this should be
relevant to KITTEN WG as well.  I'm cc'ing KITTEN WG, but we should
continue the discussion on the TLS list; Reply-To: is set.

For me the security considerations of 0-RTT have to bleed into APIs in
order to be manageable, which for many TLS apps may well be a deal
killer (and I suspect it generally is).

I.e., I think 0-RTT is generally more trouble than it's worth.

0-RTT means:

   The handshake might be two or three messages, but the client can
   send application data immediately after sending its hello, and
   the server can send application data immediately after consuming
   the client's hello.

This is not a really a new concept[1].

And this concept generalizes to longer exchanges too; the optimization
can be less good than 0-RTT but still better than full latency.

A client can do 0-RTT handshakes whenever it can obtain a usable session
key immediately upon sending the client's first[0] handshake message.

0-RTT could be made available when:

 - doing session resumption
 - the client knows the server's pubkey a priori
 - using PSK


Security considerations:

 - Replay protection (use replay cache or defer protection)

   Replay protection on the server side requires either a replay cache
   (which can more than negate the latency of one network round trip),
   or deferring replay protection availability to the end of the
   handshake.

   Deferring replay protection availability requires that the client's
   first data record(s) be held for delivery until replay protection is
   available (again, limiting the value of 0-RTT), or that the
   application be aware of the replay potential.

 - PFS (not available for 0-RTT data)

   What about PFS?  Can't be done in 0-RTT, but it can become available
   when each party learns the others' ephemeral (EC)DH key.

   Again, the application may (likely will) need to know about PFS being
   deferred, therefore this is an API consideration as well.

 - Server authentication state

   Even in the 0-RTT case the client must check that the server's pubkey
   hasn't been revoked, of course, but either it won't be able to until
   it receives the server's Hello (where stapled OCSP should be found),
   or it will have to check certificate status out of band (which has
   privacy considerations).

   The problem here is that any application data sent before receiving
   the server's Hello will be compromised if the server's private key
   was compromised (even if the cert was revoked).

   For HTTP(S) this is a problem: the HTTP request may or may not be
   sensitive, but the HTTP client implementation and TLS can't know
   if it is -- only the application can know.  This might mean that XHR,
   HTML, need extensions for specifying this.

   Again, this is an API consideration as well.

   DANE makes this consideration go away, mostly[2].

 - Client authentication state

   Imagine a handshake where the client is not authenticated until the
   second round trip, but we have key material for 0-RTT.  The server
   cannot authorize any application protocol commands at this stage.

 - Symmetric session key non-reuse depends entirely on the client and
   its RNG.  E.g., in the resumption and PSK cases.

   When using cipher modes where key/IV reuse is disastrous this could
   be a serious problem.


How to do 0-RTT in non-resumption, non-PSK handshakes:

 - with key transport (the server's static pubkey must be an encryption key)
 - with key agreement (the server's static pubkey must be an (EC)DH key)

PFS can be added, and anyways, it all looks a lot like session
resumption.


How to learn the server's pubkey prior to making the client Hello?

 - use DANE
 - recall the server's pubkey from a previous connection and use it
   optimistically (as in: it hasn't changed since last time)

The latter is the basis of Hugo Krawczyk's OPTLS proposal.

[0] I saw the thread starting at:

    https://www.ietf.org/mail-archive/web/tls/current/msg13298.html

    but the treatment of the security considerations of 0-RTT there was
    not exhaustive, unless I missed it.

[1] The GSS-API [RFC2743] has supported sending application data early,
    and has since 1997 [RFC2078].  GSS calls the "ready to send
    somewhat-protected data" state "prot_ready".  Kerberos V [RFC4120]
    effectively had it even earlier, in 1993 [RFC1510], and probably
    before then too.

[2] Provided one does not object to DANE.

Nico
--