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

[Daniel Migault <[e-mail]>]

On Thu, Jun 7, 2018 at 5:59 PM, <i.boureanu=[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 *
>
> 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.
>
> <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.
As 32 bytes is 256 bits, we might be in the scope of sha256. That said the
draft uses the first 4 bytes to indicate the time, in which case the real
number of bits to consider is 224 instead of 256. In addition, using a fix
size may not be convenient if we are willing to also use hash functions
with larger outputs. I believe that one question is whether TLS1.2/RSA and
its LURK extension are expected to survive sha256...
</daniel>


> *@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>


> *@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
>
>