Re: [TLS] Proposal: don't change keys between handshake and application layer

[Cedric Fournet]

We have rather different views of the protocol. You see the record layer as a 
sample application outside TLS, whereas our model (tied to our implementation) 
composes the handshake and the record-layer subprotocols to get security at the 
TLS API. You also reason about “the output session key”, whereas the handshake 
successively provides all traffic keys to the record layer and then provides an 
"exporter secret" to the application. Accordingly, you assume the handshake 
encrypts its own messages, whereas TLS delegates that task to the record 
layer—see my previous post for the details.

Hence, I understand your general argument, and I think it applies perfectly to 
the "exporter secret", but not to the proposed simplification (involving two 
traffic keys internal to TLS, successively used by the same record-layer) and I 
don’t see how this simplification would cause any security weakening.

Besides, in our analysis of the handshake, we get precisely the same “fresh, 
never-used secret” property you are advocating, with or without the 
simplification, each time the handshake provides keys to the record layer. 
These points are well-specified and delimited. They just do not coincide with 
the end of the handshake. So I don’t see any fundamental difference in term of 
generic-security.

We are left with scenarios whereby the record layer, given both the handshake 
and application-data traffic keys, somehow leaks only one of the two. I don’t 
mind keeping the key change if someone is concerned about it.

-Cédric

From: hugok...@gmail.com [mailto:hugok...@gmail.com] On Behalf Of Hugo Krawczyk
Sent: 19 February 2016 19:57
To: Cedric Fournet <four...@microsoft.com>
Cc: Eric Rescorla <e...@rtfm.com>; Ilari Liusvaara <ilariliusva...@welho.com>; 
Karthikeyan Bhargavan <karthik.bharga...@gmail.com>; tls@ietf.org; Markulf 
Kohlweiss <mark...@microsoft.com>; Antoine Delignat-Lavaud 
<an...@microsoft.com>; Santiago Zanella-Beguelin <santi...@microsoft.com>
Subject: Re: [TLS] Proposal: don't change keys between handshake and 
application layer



On Fri, Feb 19, 2016 at 12:58 PM, Cedric Fournet 
<four...@microsoft.com<mailto:four...@microsoft.com>> wrote:
As pointed out by Karthik, we are not strongly advocating this simplification, 
but we do not think it would weaken the security of TLS. Details below.

I am glad you are not strongly advocating this.
I strongly advocate not using the application keys to protect handshake 
messages.
I want a well-delimited point where the output session key is as good as a 
fresh, never-used secret key, and that session key be used to protect 
subsequent record layer traffic.

As I said, I cannot weigh this against implementation advantages of the 
freshness-violation approach; but these have to be *very* significant to be 
worth the security weakening.

And yes, I think this is a security weakening.
We are talking about two levels of guarantee.
One, where the TLS key exchange protocol outputs a secret key that is good for 
*any* application that requires two parties to share a secret key.
The other, where the use of the key produced by this protocol is secure enough 
for a *specific* application, namely, TLS record layer (at least in its current 
definition).

The second is clearly weaker. It has a more limited (secure) use scope.
For example, it means that changes to the record layer protocol could require a 
re-assessment of the security of the handshake, and certainly this is the case 
for a different application that somehow modifies the record layer or makes 
assumptions different than the intended use of the record layer.
With a "generically secure" handshake this reassessment of the handshake would 
not be needed, you would only need to verify that your application is secure 
under an (ideally) shared secret key.

I am sure we all agree that considering future changes to the record layer, 
changes to applications using the handshake, etc is not a theoretical concern.
The last thing you want to assume is that the TLS environment and the protocol 
evolution is static.

I think that a conservative take on this important point is the right way to go.

H
​ugo​


-Cédric, with the miTLS team


In the following, I only consider the record layer keys, which are used for 
authenticated encryption; I ignore all other derived key materials. The TLS 
layered design goes as follows:
- The handshake provides fresh keys to the record layer (depending on its 
internal state machine) and keeps running;
- The record layer uses the current keys for encrypting *all* traffic, mixing 
handshake messages, alerts, and application data (once enabled).

These keys are used sequentially, and only by the record-layer. They are not 
directly used within the handshake protocol itself, or by the TLS application.
- Since the sequence of keys is meant to protect the whole stream of TLS 
fragments, one needs to authen

Re: [TLS] Proposal: don't change keys between handshake and application layer

[Cedric Fournet]

As pointed out by Karthik, we are not strongly advocating this simplification, 
but we do not think it would weaken the security of TLS. Details below.

-Cédric, with the miTLS team


In the following, I only consider the record layer keys, which are used for 
authenticated encryption; I ignore all other derived key materials. The TLS 
layered design goes as follows:
- The handshake provides fresh keys to the record layer (depending on its 
internal state machine) and keeps running;
- The record layer uses the current keys for encrypting *all* traffic, mixing 
handshake messages, alerts, and application data (once enabled).

These keys are used sequentially, and only by the record-layer. They are not 
directly used within the handshake protocol itself, or by the TLS application.
- Since the sequence of keys is meant to protect the whole stream of TLS 
fragments, one needs to authenticate each point in the stream where there is a 
key change, to prevent any traffic truncation. As discussed in another thread, 
we believe this is correctly handled in draft#11, but each key change remains a 
source of complication [1].
- There are excellent reasons to change keys between 0-RTT and 1-RTT (stronger 
key materials, forward secrecy).
- Otherwise, what matters is the provenance of the key (how it was derived, 
what identities are associated with it) and there is no point changing keys 
with the same provenance.

The situation is particularly clear in 0-RTT: in draft#11, the client always 
derives two record-layer keys from the same materials, and uses each of these 
keys in turn to encrypt half of its 0-RTT flight, with a Finished message 
in-between that signals the key change. This key change does not degrade 
security, but seems unnecessary.

In 1-RTT, this is less obvious because, in draft#11, the handshake keys and 
application-data keys are not exactly derived from the same materials. We 
believe this should be fixed (see the “simplified key schedule” thread). Then 
the same argument applies: the key change is not terrible, but it is an 
unnecessary complication.

I disagree with Hugo that using the same record-layer key for handshake and 
application data yields a proof of a weaker guarantee. As far as I can tell, 
this is a technicality in the cryptographic proof of the handshake, and we 
still get the same security guarantees for TLS users [2]. I also like simple 
proofs of generic security for the handshake core, but I do not see how they 
can cover the other features of TLS [e.g. 3, and late handshake messages] with 
or without the simplification. Given the choice between a simpler protocol that 
it is easier to implement correctly, and simpler proofs for a core, I would 
rather simplify the overall protocol and do the extra proof work.

One may argue about what would happen if some of the record-layer keys were 
mis-used, against the TLS specification (despite its export mechanism) and 
conclude that we need more, not less key changes [3]. But I would not call it 
“a different application” and I am still tempted to simplify the key schedule 
for its intended usage in TLS.


[1] An attacker may, for instance, delete the last fragment encrypted before 
the key change. Such a deletion will be caught at the protocol layer, e.g. 
because the last fragment is not an “end_of_early_data” alert or a Finished 
message. Without the key change, any deletion would be caught immediately, as 
the next fragment decryption fails.

[2] we do not have a complete model for TLS 1.3 yet, but we developed a 
detailed model for TLS 1.2 http://eprint.iacr.org/2014/182 similarly covering 
record-layer key changes (for renegotiations) and the fact that those keys were 
used to protect the Finished messages *before* key confirmation and 
application-data traffic. The main difference with classic models for key 
exchange, where the protocol runs to completion and returns “the” application 
key, is that in our model the honest instances provide keys during the protocol 
run.

[3] as recently discussed as 0.5-RTT, the spec enables the use of 1-RTT keys 
before completing the handshake, with weaker guarantees on the encrypted 
application data. However, an extra key change would require additional 
signalling messages.


From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: 19 February 2016 14:16
To: Ilari Liusvaara 
Cc: Karthikeyan Bhargavan ; tls@ietf.org
Subject: Re: [TLS] Proposal: don't change keys between handshake and 
application layer



On Fri, Feb 19, 2016 at 3:58 AM, Ilari Liusvaara 
> wrote:
On Fri, Feb 19, 2016 at 10:04:38AM +0100, Karthikeyan Bhargavan wrote:

> Regardless of whether we make this change though, I think it would be
> useful for the TLS 1.3 RFC to clearly limit the scope of various keys
> generated by the handshake. During the connection lifetime, we generate
> a series of 

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

[Cedric Fournet]

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:martin.thom...@gmail.com] 
Sent: 17 December 2015 23:39
To: Cedric Fournet <four...@microsoft.com>
Cc: tls@ietf.org; Antoine Delignat-Lavaud <an...@microsoft.com>; Karthikeyan 
Bhargavan <karthik.bharga...@gmail.com>
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 <four...@microsoft.com> 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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Cedric Fournet]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls