Hi,

As per what I wrote originally, the below seems good to me.
Best,
Ioana

CLIENT                        EDGE-SERVER                                
KEY-SERVER

….
Client Finished
————>



                           TLS12 Request Header
                           TLS12MasterRSARequestPayload
                           key_id
                           client_random
                           S
                           pfs
                           EncryptedPremasterSecret
   Client Finished






On 11 Jun 2018, at 22:10, Daniel Migault 
<daniel.miga...@ericsson.com<mailto:daniel.miga...@ericsson.com>> wrote:

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=40surrey.ac...@dmarc.ietf.org<mailto:i.boureanu=40surrey.ac...@dmarc.ietf.org>>
 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) 
<i.boure...@surrey.ac.uk<mailto:i.boure...@surrey.ac.uk>> 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 Adv2  :) 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 + Adv2 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’ + encrypted-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 
<daniel.miga...@ericsson.com<mailto:daniel.miga...@ericsson.com>> 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...@dmarc.ietf.org<mailto:i.boureanu=40surrey.ac...@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<http://people.itcarlson.com/ioana>
Linkedin: goo.gl/540OHa<http://goo.gl/540OHa>
T.: +44 1483 683425








_______________________________________________
Lurk mailing list
Lurk@ietf.org<mailto:Lurk@ietf.org>
https://www.ietf.org/mailman/listinfo/lurk


_______________________________________________
Lurk mailing list
Lurk@ietf.org<mailto:Lurk@ietf.org>
https://www.ietf.org/mailman/listinfo/lurk



_______________________________________________
Lurk mailing list
Lurk@ietf.org<mailto:Lurk@ietf.org>
https://www.ietf.org/mailman/listinfo/lurk



_______________________________________________
Lurk mailing list
Lurk@ietf.org
https://www.ietf.org/mailman/listinfo/lurk

Reply via email to