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

[Daniel Migault <[e-mail]>]

If I am correct we also nee to send the complete handshake_messages that is
in our case ClientHello...Client Finished.

Yours,
Daniel

On Mon, Jun 11, 2018 at 6:37 AM, <i.boureanu=[e-mail]>
wrote:

> Hi Daniel, Hi all,
>
> I am replying to my pb I singled in myself in my last email, as per the
> below.
>
>
>
> On 7 Jun 2018, at 22:59, Boureanu IC Dr (Computer Science) <
> [e-mail]> wrote:
>
>
> Hi Daniel and all,
>
> *Daniel*, thanks for the below. I am going to come back onto the attack I
> spoke of in here, on the 24th and your answer/countermeasure
>
> Let me recall the attack I described on the 24th of May:
>
> <ioana>
>
> 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.
>>
>> </ioana>
>
> Recall again, my "24th-of-May” attacker *Adv1* did two things in a
> sequence: (a) first,  *Adv1 *eavesdropped some handshake between an
> edge-server E1 and  a client and collected the data; (b) then, *Adv1 *corrupted
> an edge-server E2 and used this corrupted E2 to query the key-server on old
> data, replaying from the collection in the session in point (a).
> To this, you said:
>
> <daniel>
>
> 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.)
>
> </daniel>
>
>
> *@some fix, indeed: *
> *1.* I agree that,* in the current version of the draft that you speak of
> above*, because  the edge-sever sends to the key-server* S* and *pfs* and
> NOT  *server-random, *my attacker above cannot collect S  from a session1
> of the handshake run on the insecure channel that is between the client and
> the edge-server, so *my 24th-of-May attacker cannot replay *the whole
> message from session1. I.e., my "24th-of-May” replay attacker is missing S.
>
> *@some attack still exists:*
> *2*. What the “7th-of-June” attacker *Adv*2  :) can do is this:
> (a)  first,  *Adv2 *eavesdropps some handshake in a session session1
> between an edge-server E1 and  a client and collected the data, namely *encrypted-pmk1
>  *and *client-random1, **server-random1 *+ *Adv*2 recored the time when
> this was done; let’s say that *Adv2* does this today
> (b) *Adv2* has a lot of time on his hands and computation power, so he
> spends his time, for some weeks even, trying to find a collision *S’ * for
> the hash *pfs* such that it gives the same *server-random1 *he collected
> (c) then, *Adv2 *corrupts an edge-server E2 and uses this corrupted E2 to
> query the key-server on *client-random1+ newly found **S’ + e*
> *ncrypted-pmk1 *
>
>
> This attack by me above is counteracted if the edge-server sends the
> client Finished to the key-server. In this way any S’ found as a collision
> for pfs(S) after months of computing is of no use as the Client Finished
> collected from the past would not match.
>
> I.e., now in the draft we have:
>
> CLIENT                        EDGE-SERVER
>  KEY-SERVER
> ————>
>
>
>
>                        TLS12 Request Header
>                        TLS12MasterRSARequestPayload
>                            key_id
>                            client_random
>                            S
>                            pfs
>                            EncryptedPremasterSecret
>                        -------->
>
>
> *and if we had*
>
> CLIENT                        EDGE-SERVER
>  KEY-SERVER
>
>  Client Finished
> ————>
>
>
>
>
>                           TLS12 Request Header
>                            TLS12MasterRSARequestPayload
>                            key_id
>                            client_random
>                            S
>                            pfs
>                            EncryptedPremasterSecret
>  [I.B. ADDED:] *Client Finished*
>                        -------->
>
>
> that would be much better.
>
> I argued this addition in different context and I think we should have it.
>
> Best,
> Ioana
>
>
> Yes, I know, you’d say that this is not a super-big threat, but this is my
> answer to the *"S, server-random:=pfs(S)” * trick on the edge-server side.
> One can think of what the *pfs* function should be to minimise the risks
> above, but… still...
>
> In all honesty, all these are forward-secrecy attacks, which are due to or
> inherent to  building something on TLS in RSA mode.
>
> *@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.
>
>
> *@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.
>
>
> Chat soon.
>
> Best,
> Ioana
>
>
> On 26 May 2018, at 01:08, Daniel Migault <[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=40surrey.ac.uk@
> dmarc.ietf.org> 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]
>> https://www.ietf.org/mailman/listinfo/lurk
>>
>>
> _______________________________________________
> Lurk mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lurk
>
>
>
>
> _______________________________________________
> Lurk mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lurk
>
>