Re: [Lurk] lurk -- February 2018 draft; comments

[Daniel Migault <[e-mail]>]

Hi Iona,

Please find my responses below.

Yours,
Daniel

From: [e-mail] <[e-mail]>
Sent: Friday, June 15, 2018 1:05 PM
To: Daniel Migault <[e-mail]>
Cc: Stere Preda <[e-mail]>; [e-mail]
Subject: Re: [Lurk] lurk -- February 2018 draft; comments

Hi Daniel,

Thanks for this.

@ your question

1. So, in the TLS 1.2 RSA mode,  the client does these:
Choose pmk
Set:
msk=HMAC_pmk (client-random, server-random)
 encrypted-premaster=Enc_(pk_S) (pmk)
(K_C,K_S )=HMAC_msk (N_C, N_S )
 Client-Finished=HMAC_msk (H[N_C…encrypted-premaster])

I was thinking generally of this type of general scenario:
—  a MiM attacker manages to corrupt an edge server, and then queries bad things to the key-server.
<mglt> I agree</mglt>

Now, if the server received the  Client-Finished in the proxy-query and checked the current query against the Client-Finished,  then there is less chance of any fraudulent query passing through.
***So, adding the Client-Finished to be sent to the key-server is —to my mind— a relatively cheap way to make the server have more verification-power/certainty of the client-edge part of the handshake.
<mglt>
I agree. The Key Server receives the ClientFinished from the Edge Server. By checking the ClientFinished the Key Server will have a “proof” that the master secret is associated to a complete TLS exchange and that the TLS Client owns the master secret as well. In our case it means the master secret has been part of a TLS exchange.

To verify the Finished message the Key Server is expected to compute verify_data

      verify_data
         PRF(master_secret, finished_label, Hash(handshake_messages))
            [0..verify_data_length-1];

However, currently the Key Server does not have handshake_message, so these has to be provided (explicitly). I believe the confusion may come from that the Key Server got most of the cryptographic element to “check” the finished message, but it also needs to have the exact byte-format used by the TCLS Client and the Edge Server. So in my opinion, the Edge Server needs to provide this input. This input MUST be checked against the client_random, server_random, encryptedpremaster provided separately.   Another way could be that these values are read from the handshake_messages, but that is another discussion to have.

Currently I would like to make the ClientFinished as optional ( similar to the POO) as the Finished and handshake_messages makes the exchange significantly bigger.
</mglt>

@ collisions for server-random=pfs(S)

2. You are right. Actually looking at what you wrote once again,  sending the Client-Finished to the key-server won’t help with my pb of finding collisions for server-random (since there is no way S would go in the Client-Finished; sorry I got muddled in between S and server-random).
My bad. I apologise. I’m sorry.

<mglt> I see the Finished has a proof that the request is part of a TLS handshake. It requires an attacker additional resource to send a request to the Key Server. It also probably makes the attacks more complex as the premaster, and randoms are really bound together.
</mglt>

3.  Going back to my original, exotic collision-based attack…, we had this:
a) Day-1: when MiM collects handshake data between C and Edge. This is based on server-random= pfs(S)
b) Day-n with n>>1 : This MiM has found an S' that is a collision for the S he collected in Day1, i.e., server-random = pfs(S)=pfs(S')
c) Day-m with m>n: This MiM corrupts an Edge server and queries the key-server on S’ + all the rest that MiM collected on day1.

<mglt>In my opinion, the property of the hash function makes the probability of success of such attacks very low. Possible reasons for finding these collisison may be that SHA256 is not anymore secure ( in which case we could change hash function) or if 32 bytes is not enough. In the later case this will probably impact greatly TLS security.</mglt>

To finish with this exotic, collision topic,  we can do one of these:
1. Forget that collisions will ever be found for “pfs” even if n >> 1  (in point b above) I.e., forget that the attacker has a lot of time and computational power on their hands and that “pfs” whatever it is may get broken in years to come . But we should maybe write of this forward-secrecy pb in the mdk.
2. Make the key-server initially provide S to the edge-server, send S in  the  proxy-query  made by the edge server to the key-server, and let the key-server accept such a query only if he generated the S in that last \delta-of-time
[This would take away the power of the MiM to find a collision as he’d not have months/years on his hands]
But, I know that you do not like to involve the key-server in the beginning of the handshake, but just saying ...

<mglt>First, the trick with the random simply does not work with the extended master, so we have no other choice to have the two exchanges for the extended master. Then, we may extended master to be extended to rsa master and ecdhe. In other words, the currently defined mechanism may be presented as optimizations. Would you like to define these exchange for the extended master secret in the draft ? If so feel free to send a pull request!
<mglt>


@something related (which I have just noticed):
Did you mean that the edge-server sends the “pfs” function to the key-server?
Isn’t this “pfs” meant to be public?
Is it chosen by the edge-server (as with cipher suites) at every session?

<mglt> currently the pfs is defined by the hash function and the only hash function defined is sha256. The hash function used for the pfs is specified in each exchange between the edge server and the key server. The definition of pfs is publicly defined, the choice of the pfs is agreed between the edge_server and the key server… but there is currently a single possiblity 😉
</mglt>

Thanks.

Best,
Ioana


On 15 Jun 2018, at 16:51, Daniel Migault <[e-mail]<mailto:[e-mail]>> wrote:

Hi Ioana,

I apology for the delay. It is still unclear to me what the Key Server is doing with Finished message. My understanding is that the Key Server checks the Finished message. If that is the case, I believe the handshake messages needs also to be provided by the edge_server to the Key Server, in which case the exchange would become:

+++ mention the addition.

                       TLS12 Request Header
                       TLS12MasterRSARequestPayload
                           key_id
                           client_random
                           S
                           pfs
                           EncryptedPremasterSecret
 ++++                  client Finished
 ++++                  client Handshake Context
                       -------->

                                    server_random = pfs( S )


                                    master_secret = PRF(\
                                    pre_master_secret + \
                                    "master secret" +\
                                    client_random +\
                                    server_random)[0..47];

++++                            check server_randoms in the Handshake Context
++++                            check Finished versus Handshake Context

                                           TLS12 Response Header
                                           TLS12MasterResponsePayload
                                               master
                         <--------



Is that correct ?


Yours,
Daniel




On Tue, Jun 12, 2018 at 4:41 AM, <i.boureanu=[e-mail]<mailto:i.boureanu=[e-mail]>> wrote:
Hi,




<daniel>
I agree that finding a newly found S' that achieves pfs( S' ) = pfs( S ) would make this attack feasible. My understanding is that this corresponds to a pre-image attack, and cryptographic hash function such as the currently specified sha256 are resistant to these attacks.

This attack is to find a collision

I agree it would take time and computation power to find a collision.

I also agree that we have not YET exposed any collision for sha256.

BUT you offered this as a computationally-cheaper solution to something else I proposed, so I looked at it overall.
I was looking at this from the perspective of your pfs being ANY hash function and the perfect forward secrecy  and therefore channel security being potentially ever broken.
Conceptually, you have this collision problem  with an offline attack which can happen over long time.

Now, sending the Client Finished to the key-server (along with all that you send already) helps counteract this attack.







@my solution, still
3. One way in which I see that we can protect again these is the following: the key-sever produces the “server-random” to be send to the client and the key-server accepts a query on an "encrypted pmk” only in some time-window from when it generated that “server-random”. The key-server is sent the Client Finished message too on a query on a given "encrypted pmk”, and the key-server only processes the query if it sees that it is on the server-random that it sent some milliseconds before.

In other words, this point 3 of mine, just above equates still what I said on the 24th in terms of solutions to the pb.
You can revisit that as well, further down in this email.

<daniel>
The inconvenient I found with this alternative are that:
* it requires an additional round trip to retrieve the server_random value which adds latency.
* it requires additional data to be sent to the key server which adds latency.
* when multiple Key servers are used for load balancing, it may be hard to keep them synchronized unless we have a wide time window.

The main advantage I see for using the Finished message is that we provide the ability to move to other hash functions as the output is not fixed and depends on the hash length. Such properties seems to me interesting when sha256 will not be considered safe. I am wondering how much the security of the Finished message relies on the security of the hash function.
</daniel>

Forget this solution; I agree that this is an overkill.
If you engage the server at that early stage of the “hello”, it’d be for other reasons (like cross-protocol attacks) not to protect against this potential collision problem.



@also (in any case, and almost irrespective of these attacks):
4. At the step where S, encrypted pmk etc are sent from the edge-server to the key-server, we should have the *edge-server send the Client Finished message to the key-server* too, so that the key-server can verify the Client Finished message against the client_random too.

Sending the Client Finished message to the key-server does help though, as explained in the phrase above.

Best,
Ioana





Chat soon.

Best,
Ioana



On 26 May 2018, at 01:08, Daniel Migault <[e-mail]<mailto:[e-mail]>> wrote:

Hi Ioana,

Thanks for the feed back. I agree with you that the document should be focused on TLS 1.2. This is especially true as the designation of the extension is "tls12". We are also planning to design an extension for TLS 1.3 by next IETF in Montreal.

My understanding of step 1 and 2 is to prevent a passive attacker to send a request to the key server. The key server is bound to a specific TLS handshake, by providing an random nonce involved in the handshake (and checking that random nonce has effectively been used in the exchange). More specifically, a recorded TLS handshake can only be replayed if the nonce provided by the key server matches the recorded one.

The two drawback I see with this proposed mechanism are that it requires two interactions with the key server ( one to send the ServerHello, and one to retrieve the keys). Then, the handshake_message as well as the Finished message needs to be send to the key server. The advantage is on the other hand an explicit binding to a TLS handshake.

The current protocol prevents an exchange to be replayed by generating the server_random as the output of a hash function. server_random = hash( M ) and the operations performed by the edge server as well as by the key server. A passive attacker would observed server_random but could not reverse M. In addition, the server_random carry the time and the key server does not respond when the server_random is out of a windows. Note that this latest time control may also be performed in your case.)

I believe that the two mechanisms achieve the same goal with a different perspective. Explicit biding, versus unability to replay a query based on cryptographic hash function. While the mechanism is not described in the appendix, I am wondering if you see any reason to change the mechanism. That said agree that the appendix should be clarified and updated.

Regarding 3) we effectively prove the master secret. This provides session resumption for efficiency reasons.


Regarding extended master, the current design does not prevent anti replay mechanism as the edge server provides the hash of the session. In this case, there is probably a trade off between perfect forward secrecy versus efficiency.  I would be happy to know which direction we should take. pfs would require sending the handshake messages to the key server so the key server can generate the server_random and the session hash.

Thanks you for your feed backs!

Yours,
Daniel


On Thu, May 24, 2018 at 10:39 AM, <i.boureanu=[e-mail]<mailto:i.boureanu=[e-mail]>> wrote:
Dear all,

I’ve had a look at a draft of Lurk that Daniel Migault sent me a while back; it was  dated February 2018.
Here come a mix of comments:


1. I like the aspect of termination of TLS be split into different services  (e.g., network + crypto); I think we should expand on this side...
We should expand both because it’s a nice idea and because I’m a bit worried of weird DoS attacks where one service is left in limbo.

2. I would do away with TLS 1.1.

3. I would introduce a version for TLS 1.3.

4. Let us focus on annex A1 (Lurk/TLS 1.2. RSA mode)

As you know there is this work: , "Content delivery over TLS: a cryptographic analysis of keyless SSL,” by K. Bhargavan, I. Boureanu, P. A. Fouque, C. Onete and B. Richard at 2017 IEEE European Symposium on Security and Privacy (EuroS&P), Paris, 2017, pp. 1-16.
And an attack was shown on Cloudflare’s "Keyless SSL” when run in RSA mode.

The attack rests on the fact that the client sends the “encrypted premaster secret” to the edge server who forwards this to the key server and the *answer the key-server gives back to the edge-server*.
As per Annex A1, it is not clear to me what does the key-server reply with, to the edge-server, in this step. This we need to make clear.

However, in this last step of the LURK handshake in TLS1.2. RSA-mode, the key-server should not *reply to the edge server with the premaster secret* .
Such a reply would be an issue. Namely, if one edge server E1 becomes corrupt this is what it can be used to do.
The attacker collects handshake data (which is over insecure channel) from one session —called session1-- between a client and an edge server E2; this collected data includes the  “encrypted premaster secret” of this session 1.
Then, the attacker used the corrupted edge server E2 to query the key-server on this  “encrypted premaster secret” of session 1. The key server would reply back to the corrupted E2 with the premaster secret  from session1. The attacker who controls E2 and has the handshake data from session1 can now obtain the channel key for session1 and therefore decrypt the record-layer of  session1.

In the work I mentioned above, there are several solutions to this and we can discuss them.
One solution I would suggest, and is very pertinent as a tightening of the design in LURK, is like so:
1. the key-server is involved in the handshake at the beginning and generates a nonce N_S which is sent to the edge server who sends it further to the client, as to is essentially used in the ServerHello from the edge-server to the client.

2. the edge-server sends to the key server (in the step attacked above) not just the “encrypted premaster secret” but also the nonce of the client and the encrypted Finished message by the client. (In this way the key-server can find his nonce N_S inside the finished message and the attacker above is counteracted).

3. the key-server answers with X, where depending on what we wish for then we make X be different things. My top preference would be that X be the "channel keys + the Server-Finished message”. In this way, the edge-server cannot do session-resumption. This is therefore inefficient in practice. So, if we want session resumption, then we can make X be pmk or msk. Of course, we can link this to the options of the handshake..

 (Also, there is the question as to whether we want RSA mode, but this is orthogonal to the above).


5. I did not look at the description TLS 1.2 DHE-mode.
But there we need to be able to describe well the beginning of the handshake as the work I mentioned above also exposes some weird cross-protocol attacks.
I.e.,  the edge-server is corrupted and makes the key-server sign a QUIC hash (with a long TTL inside) and then this edge-server can run for quite some time.
So, we need to pay some attention to this.

Speak soon.

Best,
Ioana Boureanu


Dr. Ioana Boureanu, FHEA

Lecturer in Secure Systems
Department of Computer Science
Surrey Centre for Cyber Security
University of Surrey, Guildford, GU2 7XH
Web: people.itcarlson.com/ioana
Linkedin: goo.gl/540OHa
T.: [phone]








_______________________________________________
Lurk mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lurk


_______________________________________________
Lurk mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lurk


_______________________________________________
Lurk mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lurk



_______________________________________________
Lurk mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lurk