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

2016-02-20 Thread Watson Ladd 
On Feb 20, 2016 12:31 PM, "Eric Rescorla"  wrote:
>
> Kenny,
>
> Would you have a problem with doing as Karthik suggests and generating
> separate traffic and handshake keys but at the same time?

This solves all the problems completely, as the traffic key is fresh.

>
> -Ekr
>
>
> On Sat, Feb 20, 2016 at 11:58 AM, Paterson, Kenny <
kenny.pater...@rhul.ac.uk> wrote:
>>
>> Hi
>>
>> My 2c below...
>>
>> On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet"
>>  wrote:
>> >
>> >
>> >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.
>>
>> Like Hugo, I am also concerned about removing the key change. Let me try
>> to explain why.
>>
>> I would emphasise the point that while we *can* provide formal security
>> analyses in the situation where the application key is used during the
>> handshake itself, it is made significantly more complex.
>>
>> In particular, it means we cannot simply combine security results arising
>> from separate analyses of the Handshake Protocol and of the Record
>> Protocol to obtain security guarantees for the composition of these two
>> protocols. So for example, if we chose to refine our modelling of the
>> Record Protocol in some way, then we would need to re-do the analysis of
>> TLS (Handshake + Record Protocols) as a monolithic effort. That's hard
>> work and error prone. This situation would not arise if the application
>> keys were NOT used in the handshake.
>>
>> This is not merely a conjectured issue. As one example, several papers
>> (including [1,2]) in the "provable security" paradigm have used the ACCE
>> framework as a security model within which to conduct analysis of
>> fragments of previous versions of TLS. ACCE was specifically designed to
>> deal with keys that are used across the Handshake and the Record
>> protocols. But ACCE views the Record Protocol in a particular way -
>> essentially as a stateful encryption scheme that processes "atomic"
>> messages. This modelling does not take into full account the streaming
>> nature of the TLS Record Protocol - in fact, what the Record Protocol
>> actually guarantees is significantly different from what is implied by
the
>> ACCE modelling of it - see [3] for details, and also the cookie cutter
>> attack from the Triple Handshakes paper for an example of what can go
>> wrong.
>>
>> One implication of this is that the results of [1,2] for existing
versions
>> of TLS really need to be reworked in a modified version of the ACCE
>> framework that better reflects the streaming nature of the Record
>> Protocol. That need for rework would have been avoided had TLS not used
>> application keys in the Handshake Protocol, because the compositional
>> guarantees would have enabled us to "plug and play" with our results.
>>
>> The same pertains in TLS 1.3 going forward: keeping the strict key
>> separation - no use of the application keys in the Handshake - will make
>> future - and on-going - analyses of TLS 1.3 easier. This is
>> notwithstanding the fact that several research teams, including Cedric's
>> and [1,2] below, have managed to produce analyses that do handle the use
>> of the application key in the Handshake.
>>
>> Regards,
>>
>> Kenny
>>
>> [1] Tibor Jager, Florian Kohlar, Sven Schäge, Jörg Schwenk. On the
>> Security of TLS-DHE in the Standard Model. CRYPTO 2012.
>> [2] Hugo Krawczyk, Kenneth G. Paterson, Hoeteck Wee. On the Security of
>> the TLS Protocol: A Systematic Analysis. CRYPTO (1) 2013.
>> [3] Marc Fischlin, Felix Günther, Giorgia Azzurra Marson, Kenneth G.
>> Paterson: Data Is a Stream: Security of Stream-Based Channels. CRYPTO (2)
>> 2015.
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-02-20 Thread Eric Rescorla 
Kenny,

Would you have a problem with doing as Karthik suggests and generating
separate traffic and handshake keys but at the same time?

-Ekr


On Sat, Feb 20, 2016 at 11:58 AM, Paterson, Kenny  wrote:

> Hi
>
> My 2c below...
>
> On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet"
>  wrote:
> >
> >
> >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.
>
> Like Hugo, I am also concerned about removing the key change. Let me try
> to explain why.
>
> I would emphasise the point that while we *can* provide formal security
> analyses in the situation where the application key is used during the
> handshake itself, it is made significantly more complex.
>
> In particular, it means we cannot simply combine security results arising
> from separate analyses of the Handshake Protocol and of the Record
> Protocol to obtain security guarantees for the composition of these two
> protocols. So for example, if we chose to refine our modelling of the
> Record Protocol in some way, then we would need to re-do the analysis of
> TLS (Handshake + Record Protocols) as a monolithic effort. That's hard
> work and error prone. This situation would not arise if the application
> keys were NOT used in the handshake.
>
> This is not merely a conjectured issue. As one example, several papers
> (including [1,2]) in the "provable security" paradigm have used the ACCE
> framework as a security model within which to conduct analysis of
> fragments of previous versions of TLS. ACCE was specifically designed to
> deal with keys that are used across the Handshake and the Record
> protocols. But ACCE views the Record Protocol in a particular way -
> essentially as a stateful encryption scheme that processes "atomic"
> messages. This modelling does not take into full account the streaming
> nature of the TLS Record Protocol - in fact, what the Record Protocol
> actually guarantees is significantly different from what is implied by the
> ACCE modelling of it - see [3] for details, and also the cookie cutter
> attack from the Triple Handshakes paper for an example of what can go
> wrong.
>
> One implication of this is that the results of [1,2] for existing versions
> of TLS really need to be reworked in a modified version of the ACCE
> framework that better reflects the streaming nature of the Record
> Protocol. That need for rework would have been avoided had TLS not used
> application keys in the Handshake Protocol, because the compositional
> guarantees would have enabled us to "plug and play" with our results.
>
> The same pertains in TLS 1.3 going forward: keeping the strict key
> separation - no use of the application keys in the Handshake - will make
> future - and on-going - analyses of TLS 1.3 easier. This is
> notwithstanding the fact that several research teams, including Cedric's
> and [1,2] below, have managed to produce analyses that do handle the use
> of the application key in the Handshake.
>
> Regards,
>
> Kenny
>
> [1] Tibor Jager, Florian Kohlar, Sven Schäge, Jörg Schwenk. On the
> Security of TLS-DHE in the Standard Model. CRYPTO 2012.
> [2] Hugo Krawczyk, Kenneth G. Paterson, Hoeteck Wee. On the Security of
> the TLS Protocol: A Systematic Analysis. CRYPTO (1) 2013.
> [3] Marc Fischlin, Felix Günther, Giorgia Azzurra Marson, Kenneth G.
> Paterson: Data Is a Stream: Security of Stream-Based Channels. CRYPTO (2)
> 2015.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-02-20 Thread Paterson, Kenny 
Hi

My 2c below...

On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet"
 wrote:
>
> 
>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.

Like Hugo, I am also concerned about removing the key change. Let me try
to explain why.

I would emphasise the point that while we *can* provide formal security
analyses in the situation where the application key is used during the
handshake itself, it is made significantly more complex.

In particular, it means we cannot simply combine security results arising
from separate analyses of the Handshake Protocol and of the Record
Protocol to obtain security guarantees for the composition of these two
protocols. So for example, if we chose to refine our modelling of the
Record Protocol in some way, then we would need to re-do the analysis of
TLS (Handshake + Record Protocols) as a monolithic effort. That's hard
work and error prone. This situation would not arise if the application
keys were NOT used in the handshake.

This is not merely a conjectured issue. As one example, several papers
(including [1,2]) in the "provable security" paradigm have used the ACCE
framework as a security model within which to conduct analysis of
fragments of previous versions of TLS. ACCE was specifically designed to
deal with keys that are used across the Handshake and the Record
protocols. But ACCE views the Record Protocol in a particular way -
essentially as a stateful encryption scheme that processes "atomic"
messages. This modelling does not take into full account the streaming
nature of the TLS Record Protocol - in fact, what the Record Protocol
actually guarantees is significantly different from what is implied by the
ACCE modelling of it - see [3] for details, and also the cookie cutter
attack from the Triple Handshakes paper for an example of what can go
wrong.

One implication of this is that the results of [1,2] for existing versions
of TLS really need to be reworked in a modified version of the ACCE
framework that better reflects the streaming nature of the Record
Protocol. That need for rework would have been avoided had TLS not used
application keys in the Handshake Protocol, because the compositional
guarantees would have enabled us to "plug and play" with our results.

The same pertains in TLS 1.3 going forward: keeping the strict key
separation - no use of the application keys in the Handshake - will make
future - and on-going - analyses of TLS 1.3 easier. This is
notwithstanding the fact that several research teams, including Cedric's
and [1,2] below, have managed to produce analyses that do handle the use
of the application key in the Handshake.

Regards,

Kenny 

[1] Tibor Jager, Florian Kohlar, Sven Schäge, Jörg Schwenk. On the
Security of TLS-DHE in the Standard Model. CRYPTO 2012.
[2] Hugo Krawczyk, Kenneth G. Paterson, Hoeteck Wee. On the Security of
the TLS Protocol: A Systematic Analysis. CRYPTO (1) 2013.
[3] Marc Fischlin, Felix Günther, Giorgia Azzurra Marson, Kenneth G.
Paterson: Data Is a Stream: Security of Stream-Based Channels. CRYPTO (2)
2015.


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

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

2016-02-20 Thread 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

2016-02-19 Thread Hugo Krawczyk 
of 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 <ilariliusva...@welho.com>
> *Cc:* Karthikeyan Bhargavan <karthik.bharga...@gmail.com>; 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 <ilariliusva...@welho.com>
> 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 record encryption keys: handshake and application keys for
> > 0-RTT and 1-RTT, and then a sequence of keys generated during rekeying.
> > None of these keys should be used outside their intended use cases in a
> > single connection.  The only cross-connection secret specified in the
> > protocol is the resumption master secret, and if applications want a
> > key from TLS 1.3, they must only use the exporter master secret. All
> > other keys are internal to TLS.
>
> I think TLS 1.3 RFC should specify what the protocol looks like and how
> it can be used from application perspective. This includes specifying
> what keys can be exported (among many other things, like how
> authentication can be performed).
>
> I agree that exporting the main encryption keys or secrets those are
> derived from for any purpose is a rotten idea. If you need keying or
> authentication material, use TLS EXPORTER (tls-unique is deprecated)
> with requirement to use EMS on prior versions[1].
>
>
>
> This is the intent. I think we would be well-served to state this.
>
>
>
>
>
> Then one might need to export RMS. I think it should be exported as
> blob that also contains other associated information (e.g ciphersuites).
> And possibly also encrypted, using some MRAE algorithm.
>
>
>
> [1] Compatiblity hack: One might consider EMS always negotiated when
> TLS 1.3 is negotiated. This could prvent applications that do know
> about EMS but not TLS 1.3 from breaking when upgrading to TLS 1.3.
>
> That is, if application asks about TLS 1.3 (ServerVersion 3.4)
> connection "is EMS enabled?" the answer will be always "yes"
> (since the point of that check is to exclude THS attacks, and
> TLS 1.3 already excludes those on baseline).
>
>
>
> Good suggestion. This in fact is what NSS currently does:
>
>
> https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslinfo.c#70
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdxr.mozilla.org%2fmozilla-central%2fsource%2fsecurity%2fnss%2flib%2fssl%2fsslinfo.c%2370=01%7c01%7cFOURNET%40064d.mgd.microsoft.com%7c769519cd967541c83e5808d339375926%7c72f988bf86f141af91ab2d7cd011db47%7c1=yHU8A1PxV303DF3hxMLZ1BEQRbGqPe1gjdnrjhwWHe8%3d>
>
>
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
>
> -Ilari
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls=01%7c01%7cFOURNET%40064d.mgd.microsoft.com%7c769519cd967541c83e5808d339375926%7c72f988bf86f141af91ab2d7cd011db47%7c1=PPF4H7v%2fuGhlNE2r%2bgtYYhztJsCvr9ftMN%2fPrxevBxQ%3d>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-02-19 Thread 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 <ilariliusva...@welho.com>
Cc: Karthikeyan Bhargavan <karthik.bharga...@gmail.com>; 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 
<ilariliusva...@welho.com<mailto:ilariliusva...@welho.com>> 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

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

2016-02-19 Thread Eric Rescorla 
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 record encryption keys: handshake and application keys for
> > 0-RTT and 1-RTT, and then a sequence of keys generated during rekeying.
> > None of these keys should be used outside their intended use cases in a
> > single connection.  The only cross-connection secret specified in the
> > protocol is the resumption master secret, and if applications want a
> > key from TLS 1.3, they must only use the exporter master secret. All
> > other keys are internal to TLS.
>
> I think TLS 1.3 RFC should specify what the protocol looks like and how
> it can be used from application perspective. This includes specifying
> what keys can be exported (among many other things, like how
> authentication can be performed).
>
> I agree that exporting the main encryption keys or secrets those are
> derived from for any purpose is a rotten idea. If you need keying or
> authentication material, use TLS EXPORTER (tls-unique is deprecated)
> with requirement to use EMS on prior versions[1].
>

This is the intent. I think we would be well-served to state this.


Then one might need to export RMS. I think it should be exported as
> blob that also contains other associated information (e.g ciphersuites).
> And possibly also encrypted, using some MRAE algorithm.
>
>
>
> [1] Compatiblity hack: One might consider EMS always negotiated when
> TLS 1.3 is negotiated. This could prvent applications that do know
> about EMS but not TLS 1.3 from breaking when upgrading to TLS 1.3.
>
> That is, if application asks about TLS 1.3 (ServerVersion 3.4)
> connection "is EMS enabled?" the answer will be always "yes"
> (since the point of that check is to exclude THS attacks, and
> TLS 1.3 already excludes those on baseline).


Good suggestion. This in fact is what NSS currently does:
https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslinfo.c#70

-Ekr




>
>

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

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

2016-02-19 Thread Ilari Liusvaara 
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 record encryption keys: handshake and application keys for
> 0-RTT and 1-RTT, and then a sequence of keys generated during rekeying.
> None of these keys should be used outside their intended use cases in a
> single connection.  The only cross-connection secret specified in the
> protocol is the resumption master secret, and if applications want a
> key from TLS 1.3, they must only use the exporter master secret. All
> other keys are internal to TLS.

I think TLS 1.3 RFC should specify what the protocol looks like and how
it can be used from application perspective. This includes specifying
what keys can be exported (among many other things, like how
authentication can be performed).

I agree that exporting the main encryption keys or secrets those are
derived from for any purpose is a rotten idea. If you need keying or
authentication material, use TLS EXPORTER (tls-unique is deprecated)
with requirement to use EMS on prior versions[1]. 

Then one might need to export RMS. I think it should be exported as
blob that also contains other associated information (e.g ciphersuites).
And possibly also encrypted, using some MRAE algorithm.



[1] Compatiblity hack: One might consider EMS always negotiated when
TLS 1.3 is negotiated. This could prvent applications that do know
about EMS but not TLS 1.3 from breaking when upgrading to TLS 1.3.

That is, if application asks about TLS 1.3 (ServerVersion 3.4)
connection "is EMS enabled?" the answer will be always "yes"
(since the point of that check is to exclude THS attacks, and
TLS 1.3 already excludes those on baseline).





-Ilari

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

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

2016-02-19 Thread Karthikeyan Bhargavan 
I do not have a very strong opinion on whether the same traffic keys can or 
should be used for the handshake and application. As Hugo says, it complicates 
the cryptographic analysis but we do know now how to do the analysis for such 
key usage, thanks to years of work on TLS <= 1.2. I am told that separate 
application and data keys would be tricky for DTLS implementations, but it does 
not seem to matter too much in our TLS implementation,
where we already manage a sequence of epochs for TLS 1.2.

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 record 
encryption keys: handshake and application keys for 0-RTT and 1-RTT, and then a 
sequence of keys generated during rekeying. None of these keys should be used 
outside their intended use cases in a single connection.  The only 
cross-connection secret specified in the protocol is the resumption master 
secret, and if applications want a key from TLS 1.3, they must only use the 
exporter master secret. All other keys are internal to TLS.

We are in the process of implementing and analysing TLS 1.3 both in miTLS and 
in ProVerif, and from our early experiments, the one thing that is annoying to 
implement and analyze is the sheer number of places in the handshake where we 
generate keys. This is awkward because we need to mix in the handshake 
transcript at six different places, but also because we occasionally need to 
keep internal HKDF extracted state longer than necessary.  These points are 
probably more relevant to Ekr’s other email on the key schedule, and I will 
make them there and at my TRON talk. Coming back to the application/handshake 
key separation, I think I would be equally happy with deriving separate 
application and data keys but at the same time, so that we can still have three 
sets of keys, one for 0-RTT, one for 1-RTT, and one set of Final keys for 
resumption and exporters at the end of the handshake. This is essentially the 
same as Ekr’s proposal, except that we derive separate handshake and 
application keys at each stage. It has the minor added benefit of using HKDF as 
a black-box and not storing extracted secrets. If this complicates DTLS 
implementations, it would be worth understanding why.


> On 18 Feb 2016, at 17:45, Hugo Krawczyk  wrote:
> 
> I want to point out that the benefits of using the application key output by 
> the
> handshake protocol also for handshake traffic protection are not clear cut. 
> I cannot comment at the level of implementation simplification that motivates
> this change but I can comment on the cryptographic implications of this 
> change.
> 
> Yes, TLS 1.3, can probably be proved secure even with this key merge, but it 
> is
> a proof of a *weaker* guarantee. When the application key is not used during 
> the exchange you can claim that the handshake protocol provide *generic* key
> exchange security. Here "generic" means that you can use the key with 
> *any* application that requires a secret shared key. In contrast, using the
> application key during the key exchange process itself can still guarantee
> security for a *specific* application but not in general. That is, we can now
> prove security for the specific application of this key to protecting TLS 
> record
> layer traffic (achieved via TLS message type separation). But if you want to
> take that same key and use it for a variant of the protocol or in a different
> application [1] then you need to go and re-analyze [2] the protocol with that
> specific application in mind.
> 
> Given the history of weaknesses in TLS I would prefer a more conservative
> design. TLS evolves and is used in places and ways not contemplated by the
> designers. For example, no one contemplated originally that people will use a
> MAC value or a session key as collision-resistant identifiers for sessions but
> people did. Models and requirements need to be strengthened over time, not
> weakened. The merge of handshake and application key is a weakening.
> 
> Finally, a side effect of this change is that it limits the generality of the
> protocol. Till now the protocol was ready for an immediate variant where the
> server uses a Diffie-Hellman certificate. It would require a minimal 
> adaptation
> of the current specification where the CertificateVerify message is omitted 
> and
> an entry in the key derivation table is added. But to encrypt the DH 
> certificate
> you'd need to derive a key from g^xy only (which is not the case for the
> application key). The DH variant is not currently contemplated but one that 
> can
> be handy in the future (it is a simpler protocol than what we have now and can
> have benefits in a "post-quantum transition"). 
> 
> Hugo
> 
> PS: I wrote more about this topic here 
>

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

2016-02-18 Thread Hugo Krawczyk 
I want to point out that the benefits of using the application key output
by the
handshake protocol also for handshake traffic protection are not clear cut.
I cannot comment at the level of implementation simplification that
motivates
this change but I can comment on the cryptographic implications of this
change.

Yes, TLS 1.3, can probably be proved secure even with this key merge, but
it is
a proof of a *weaker* guarantee. When the application key is not used
during
the exchange you can claim that the handshake protocol provide *generic* key
exchange security. Here "generic" means that you can use the key with
*any* application that requires a secret shared key. In contrast, using the
application key during the key exchange process itself can still guarantee
security for a *specific* application but not in general. That is, we can
now
prove security for the specific application of this key to protecting TLS
record
layer traffic (achieved via TLS message type separation). But if you want to
take that same key and use it for a variant of the protocol or in a
different
application [1] then you need to go and re-analyze [2] the protocol with
that
specific application in mind.

Given the history of weaknesses in TLS I would prefer a more conservative
design. TLS evolves and is used in places and ways not contemplated by the
designers. For example, no one contemplated originally that people will use
a
MAC value or a session key as collision-resistant identifiers for sessions
but
people did. Models and requirements need to be strengthened over time, not
weakened. The merge of handshake and application key is a weakening.

Finally, a side effect of this change is that it limits the generality of
the
protocol. Till now the protocol was ready for an immediate variant where the
server uses a Diffie-Hellman certificate. It would require a minimal
adaptation
of the current specification where the CertificateVerify message is omitted
and
an entry in the key derivation table is added. But to encrypt the DH
certificate
you'd need to derive a key from g^xy only (which is not the case for the
application key). The DH variant is not currently contemplated but one that
can
be handy in the future (it is a simpler protocol than what we have now and
can
have benefits in a "post-quantum transition").

Hugo

PS: I wrote more about this topic here
https://www.ietf.org/mail-archive/web/tls/current/msg13625.html
(it was in the context of the need to encrypt the Finished message but the
issue
I was commenting on was the same as here, namely, the re-use of the
application
key during the handshake)

[1] Given the wide availability of TLS implementations, it makes sense for
different applications to use the TLS handshake as their key-exchange
protocol.
Fortunately, there is the exporter key that is still secure in the stronger
generic sense and can be used for that purpose. Even then, I would expect
people to use the application key as the natural session key, or be tied to
TLS
in a way that requires using the same application key. And, in any case,
changes
to the record layer protocol would require a re-assessment of security in
the
combined handshake-record protocol.

[2] The analysis of a protocol that breaks the generic and modular security
principles is doable but more complex and needs to be re-assessed with
changes
to the application protocol.


On Thu, Feb 18, 2016 at 9:54 AM, Eric Rescorla  wrote:

>
> On Thu, Feb 18, 2016 at 7:32 AM, Wan-Teh Chang  wrote:
>
>> On Wed, Feb 17, 2016 at 7:49 PM, Eric Rescorla  wrote:
>> >
>> > TL;DR.
>> > I propose that we should not change keys between the handshake
>> > and application traffic keys.
>>
>> Hi Eric,
>>
>> I'm not sure if I understand your one-sentence summary, because
>> "change keys between the foo and bar keys" is hard to understand. Are
>> you proposing that we should use the same keys to encrypt handshake
>> messages and application data?
>
>
> Yes, precisely.
>
> -Ekr
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2016-02-18 Thread Eric Rescorla 
On Thu, Feb 18, 2016 at 7:32 AM, Wan-Teh Chang  wrote:

> On Wed, Feb 17, 2016 at 7:49 PM, Eric Rescorla  wrote:
> >
> > TL;DR.
> > I propose that we should not change keys between the handshake
> > and application traffic keys.
>
> Hi Eric,
>
> I'm not sure if I understand your one-sentence summary, because
> "change keys between the foo and bar keys" is hard to understand. Are
> you proposing that we should use the same keys to encrypt handshake
> messages and application data?


Yes, precisely.

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

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

2016-02-18 Thread Ilari Liusvaara 
On Wed, Feb 17, 2016 at 08:49:33PM -0700, Eric Rescorla wrote:
> Hi folks,
> 
> TL;DR.
> I propose that we should not change keys between the handshake
> and application traffic keys.
> 
> The general idea is that there is no strong security reason to change
> change keys between handshake and traffic in the same phase (e.g.,
> between the 1-RTT handshake and traffic keys, so we should simplify by
> not doing so.)  This is something that implementers have asked for,
> especially for DTLS (so you don't need to have three contexts in one
> flight) and we have resisted, nominally for security reasons but
> really over concerns about analysis.
> 
> There are three basic security reasons why one might want to change
> keys:
> 
> - To add additional secret information.
> - To bind in additional context.
> - For PFS.
> 
> None of these apply at the handshake/traffic transition: We don’t have
> any more secret material at this point in TLS 1.3 (SS and ES are both
> known at the time that the handshake keys must be generated.) It is
> not necessary to bind in the additional context to the traffic keys
> (though see below about resumption) because it is tied to the keys
> via the Finished messages. We know how to do security proofs
> for this (those exist for 1.2).  There’s no reason to have different
> PFS for the handshake versus the application traffic.
> 
> We can simplify matters by adopting a schedule more like the following:
> 
> 
> Key Class Input   Handshake Context Specific
>   Secrets /Transcript   Keys
> -
> 0-RTT KeysSS  ClientHello + client write keys
>ServerConfiguration +client finished keys
>ServerCertificate +
>CertificateRequest
> 
> 1-RTT KeysSS, ES  ClientHello,  client/server write
> keys
>   ServerHello   client/server
> finished keys
> 
> 
> Final KeysSS, ES  Complete transcript
>   through client finished   exporter master
> secret
> resumption master
> secret
> [Maybe
> traffic_secret_1]

Hmm... If there was master secret that was derived from SS, ES and
hash(ClientHello1...ServerHello) and then encryption keys, exporter
keys and resumption keys were derived from that, the result would be
very simple to analyze for GDHE-CERT (without CFG), GDHE-PSK and
PSK.

GDHE-CERT with CFG and other similar schemes are harder case. In
that case, attacks can peneratrate all the way to ClientFinished.

> Note that it is very important that the Resumption Master Secret
> include the server certificate (otherwise you get Triple Handshake)
> but you shouldn'tt need that for the initial handshake traffic keys.

Eh, if using baseline GDHE-CERT without CFG and having master secret
like previous, I don't see how (except if going by misleading statement
in EMS RFC abstract).

However, given that things can go definitely wrong if *client*
certificate isn't included and attacks all the way to ClientFinished
can happen if SS is nontrivially used, it is probably the simplest and
the most conservative to take it as Hash(ClientHello1...ClientFinished),
which also happens to include server certificate

> There is a sense in which it makes analysis harder in that the
> cryptographic (as opposed to symbolic) proofs are better adapted to
> assuming that the keys being output by the handshake are never used
> for any handshake purpose. However, there are techniques for making
> this work with plausible assumptions about how TLS will use the keys
> (mainly that only TLS will be allowed to send traffic with the TLS
> internal keys and that everything else will only get access to
> Exported keys) [1].

One thing to note is that TLS 1.3 record type/length hiding makes
encrypted handshake and application data records distinct.


-Ilari

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