Re: [TLS] Proposed text for removing renegotiation

[Eric Rescorla <[e-mail]>]

On Sat, Jun 7, 2014 at 7:58 AM, Watson Ladd <[e-mail]> wrote:

> On Fri, Jun 6, 2014 at 3:30 PM, Martin Rex <[e-mail]> wrote:
> > Brian Smith wrote:
> >> Martin Rex <[e-mail]> wrote:
> >>>
> >>> Conceptually, the TLS session cache is readonly after an entry
> >>> is created, and that is GOOD, i.e. full TLS handshakes create new,
> >>> distict session cache entries, and abbreviated TLS handshakes resume
> >>> existing session cache entries and *NEVER* modify them.
> >>
> >> That is not true. During session resumption, the server can send a new
> >> session ticket for the existing session and the client has the option of
> >> adding the new ticket to the session (and removing the old ticket).
> >>
> >> Also often timestamps (e.g. for LRU replacement bookkeeping) and/or
> >> counters (e.g. for cache hit rate statistics) in a session are updated
> >> during resumption, though these are "just" implementation issues.
> >
> >
> > With "conceptually", I referred to the requirements of the specification,
> > not to the details of certain implementations of it.  Counting how often
> > sessions are resumed is nothing that the spec requires, and how you
> > manage your cache entries (expiration) is not in scope of that concept.
> >
> > When the read-only concept is violated, and implementations start
> scribbling
> > over _state_ of sessions that are in the cache during resumption
> > handshakes, it may result in problems such as these:
>
> What about this solution: separate TLS into a handshake and transport.
> The handshake computes a connection key associated with the ticket,
> then the transport computes a transport key based on that key and some
> conceptually separate random data from both sides exchanged in the
> handshake. When the transport is exhausted or we resume, the random
> numbers change, but the connection key does not.


To some extent TLS already does try to make this separation, with
separate "TLS Record Protocol" (Section 6) and "TLS Handshaking
Protocols" (Section 7) with the handshake protocol establishing a
Master Secret for the entire session which is then used to derive
distinct record keys every time you reconnect (resume) in the same
session, with diversity provided by the random values. So, arguably,
TLS already behaves this way, with the exception of dealing with
cryptographic exhaustion of the transport keys (e.g., GCM counter
rollover).

MT's basic suggestion is to fix the cryptographic exhaustion
problem by having a signal to re-generate new transport level keys
from the Master Secret. AFAIK this doesn't require any new random
exchange because you already have existing random values that
provide per-connection diversity, so you just need to generate new
crypto keys, e.g., by cranking the PRF again starting with the PRF
and the random values and some sort of iteration count and doesn't
require any conceptual changes to the TLS session cache model
of the kind that Martin Rex is discussion.


Where things get interesting is that this solely addresses exhaustion
but not PFS [0] I.e., as long as the Master Secret is stored somewhere
(e.g., the session cache) then an attacker who recovers it can
recover all the traffic keys. Traditionally, if you renegotiate without
resumption (i.e., do a fresh key exchange), then you can address
this issue, but if we remove renegotiation, that option is no longer
available. That leaves us with a number of options:

- Tell people they just need to reconnect if they want to limit the
   exposure of a given session (i.e., do nothing).

- Provide a mechanism for re-keying the connection in a way that
  allows you to destroy the previous keys [1]. However, this still
  runs afoul of the fact that the Master Secret needs to be available
  to generate the connection keys. You can deal with this in two
  major ways:

  (a) Tell people not to use resumption (i.e., not to store the MS in the
        session cache) if they want to provide this feature.
  (b) Change the value stored in the session cache so it can only be
        used to make new connections but not to decrypt old ones.
        AFAIK this requires being willing to change the session cache [2]

Or perhaps there's some clever idea I haven't thought of...

Best,
-Ekr


[0] Maybe we need a new term other than PFS for this particular
security feature.

[1] E.g., have a per-connection "Connection Master Key" generated
from the MS and then used to generate the traffic keys. When you
initially connection, you would compute CMS[0] = PRF(MS, Randoms)
and then do Traffic Keys = PRF(CMS[0], ...). Then when the keys
were exhausted you would do CMS[1] = PRF(CMS[0], ...) and recompute
the traffic keys with CMS[1].  Since the PRF is notionally irreversible,
an attacker with access to the keys after the key change couldn't
decrypt old traffic.

[2] Vigorous handwaving: the trivial thing to do is just to have MS[0],
MS[1], MS[2], etc. where every time you resume you generate the next
generation MS and destroy the old one. Obviously this requires changing
the session cache data, which is undesirable for the reasons indicated
by Martin Rex.