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

[Cedric Fournet <[e-mail]>]

The surprise is that breaking one key also yields the ability to truncate traffic protected with another key. We agree that we don't have any particularly scary way to exploit it against the current draft, but we'd much prefer handshake encryption not to depend on 0RTT, and application data protection not to depend on handshake encryption.

With our proposed change, the main point to keep in mind is that, by design, the TLS 1.3 record layer does not prevent suffix truncations. Instead, TLS prevents prefix truncations at the protocol layer, by sending an unambiguous final message with each record key:  end_of_early_data; finished; and close_notify.

-----Original Message-----
From: Martin Thomson [mailto:[e-mail]] 
Sent: 17 December 2015 23:39
To: Cedric Fournet <[e-mail]>
Cc: [e-mail]; Antoine Delignat-Lavaud <[e-mail]>; Karthikeyan Bhargavan <[e-mail]>
Subject: Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379)

So the actual impact here is that an attacker who has compromised a key can introduce a gap.  Aren't there other options available to such an attacker?  Scarier options?

On 18 December 2015 at 07:01, Cedric Fournet <[e-mail]> wrote:
>
> 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).

Even with my question above, this seems reasonable to me.  I'll note that chaining in the way you describe would require that the rekey message (the last message of the previous epoch) would need to be retransmitted in DTLS.  That seems more brittle, but we probably want to retransmit anyway, since that would let use remove the explicit epoch from DTLS packets.