Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379)

[Cedric Fournet <[e-mail]>]

As explained below, we propose that the record-layer sequence numbers
be reset to 0 whenever new keys are installed (as in TLS 1.2):

https://github.com/tlswg/tls13-spec/pull/379

Cédric Fournet, on behalf of the miTLS team.


While working on a formal model of the TLS 1.3 record layer, I bumped
into a new weakness due to the chaining of sequence numbers between
epochs.

In the current draft, the sequence number is not reset when a new key
is installed. This is a new mechanism we suggested a while ago: the
intent was to prevent suffix truncations of traffic encrypted with the
old key by making the first decryption with the new key fail.

This mechanism prevents suffix truncations when *both* keys are
secure, but it introduces a new weakness when the old key is
compromised and the new key is secure.  Then, the attacker gains the
ability to delete the first few fragments encrypted with the new key,
which we think is not acceptable.

This is problematic when switching from the 0RTT keys to the handshake
keys, then to the application keys, as the whole point of the TLS 1.3
key schedule is to gradually establish stronger keys. We discuss below
some of the complications it may cause.

PREFIX TRUNCATION: HANDSHAKE ---> APPLICATION

This weakness in the transition from the handshake key to the
application data key may be exploited as follows:

* The client and server complete a 1-RTT handshake, and some
  implementation bug causes the handshake key to be leaked.

* The attacker may play with handshake message fragmentation to
  artificially increase the sequence number on either side of the
  channel. The handshake data remains untouched, so the handshake can
  still be successful. 

* When the client and server start exchanging application data (using
  the new, secure key), the attacker can remove as many fragments as
  he added to truncate application data in both directions!

PREFIX TRUNCATION: 0RTT ---> HANDSHAKE 

A variant may also occurs during the change from the 0-RTT key to the
handshake key:

* The client first sends 0RTT-encrypted fragments, then
  handshake-encrypted fragments.

* The attacker breaks the 0RTT key, and rewrites 0RTT traffic to
  insert additional fragments, for instance by fragmenting the 0RTT
  payload into several fragments. For each additional fragment with
  the old key, it also deletes a fragment encrypted with the new key,
  and then forwards the rest of the client traffic unchanged.

* The server's sequence number is higher than the client's when it
  changes key, but nonetheless the server successfully decrypt all
  received fragments.

Similarly, if the server refuses 0RTT but continues the handshake, it
is unclear which sequence number the client should use for encrypting
handshake traffic. If the client continues with the 0RTT sequence
number, then the only way for the server to decrypt the handshake
traffic is to count how many 0RTT fragments it discards---and this can
be controlled by the attacker, even without breaking the 0RTT key!

Although prefix truncations will probably cause the handshake to fail,
this complicates the analysis of the record layer, whose security now
depends on the details of the handshake protocol. There are also
corner cases; for instance, assuming alerts are protected using the
current keys (as they are in TLS 1.2), it may be possible to silently
delete a warning from the client to the server, or to truncate half of
the client certificate and observe whether the second half starts with
a well-formed alert fragment.

OUR PROPOSAL. In the current draft, the ends of encrypted traffic have
now all be made explicit (using end_of_early_data; Finished; and
close_notify), so there is no apparent need to chain sequence numbers.

We propose to revert this change (that is, to reset the sequence
number each time a new key is installed, as in TLS 1.2). If the
chaining is still required for some other reason, one could instead
include the old sequence number in the new key derivation (or the new
key's additional data, but we believe this is no longer an option).