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

[Nico Williams <[e-mail]>]

On Tue, Nov 18, 2014 at 04:04:10PM -0800, Eric Rescorla wrote:
> On Tue, Nov 18, 2014 at 3:46 PM, Nico Williams <[e-mail]>
> wrote:
> >  - Replay protection (use replay cache or defer protection)
> >    [...]
> 
> 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.

But how would the client know the first time?  Perhaps it shouldn't
matter.  The server should just hold back before delivering the data.
Still, in order to do this without a replay cache the handshake has to
have two more messages after the one where the client is prot_ready and
the client has to confirm the early messages.  So this has to be part of
the protocol.

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

Yes, this is a general problem that can only really be addressed via key
freshness.

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

Even ones where the client is afforded confidentiality for its ID?  I
can certainly imagine protocols where that wouldn't be the case.

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

By the time the server can check this it's too late: the client sent the
bad ciphertext.

Nico
--