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

[Eric Rescorla <[e-mail]>]

On Tue, Nov 18, 2014 at 3:46 PM, Nico Williams <[e-mail]>
wrote:

>
> 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.
>

A fair bit, including a complete solution in Snap Start
and some handwavy stuff in draft-rescorla-tls13-new-flows-01, as
well as the Watson Ladd mail you reference below



> 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.
>

Yes, I agree that this doesn't make sense. The server needs to provide
anti-replay as part of the TLS stack using some sort of server-side state.
Servers which don't want to do that should not offer 0-RTT.



>  - 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.
>

Yes, we'll need APIs to let the client control whether data should be sent
w/o PFS. Note that the we already have a parallel situation with resumption
which currently never offers OCSP.


 - 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.
>

I'm not following this. Generally, server 0-RTT keys will probably be fairly
short-lived by comparison to OCSP-stapled responses, so you can just
continue to use the key within the OCSP window. Remember that if the
key is compromised within the OCSP window, then the attacker can
attack you with 1-RTT as well as 0-RTT. Again, this is also an issue
with resumption.


 - 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


Every proposal I have ever seen for 0-RTT has the client delivering
client auth in the first flight for exactly this reason.



 - 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.
>

The conventional way to address this (as in snap start) is to use an
anti-replay mechanism which ensures uniqueness of the client random,
thus providing key uniqueness.

-Ekr