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

[i . boureanu=40surrey . ac . uk]

Ok.

I would like us to have a call maybe on some of this to make things clearer.

Yes the key server needs all the input to check the ClientFinished against, if 
we send it. If something is missing for this check, then we have to add it.

And, yes I will add the extra options in the file.

I will also reply bit by bit but I am on my phone now. So it is hard. I will do 
it later.
Sorry.

Ioana



Sent from my Samsung Galaxy smartphone.
 Original message 
From: Daniel Migault 
Date: 15/06/2018 19:24 (GMT+00:00)
To: "Boureanu IC Dr (Computer Science)" 
Cc: Stere Preda , lurk@ietf.org
Subject: RE: [Lurk] lurk -- February 2018 draft; comments

Hi Iona,

Please find my responses below.

Yours,
Daniel

From: i.boure...@surrey.ac.uk 
Sent: Friday, June 15, 2018 1:05 PM
To: Daniel Migault 
Cc: Stere Preda ; lurk@ietf.org
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.
 I agree

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.

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.


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

 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.


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.

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.

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, sen

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

[Daniel Migault]

Hi Iona,

Please find my responses below.

Yours,
Daniel

From: i.boure...@surrey.ac.uk 
Sent: Friday, June 15, 2018 1:05 PM
To: Daniel Migault 
Cc: Stere Preda ; lurk@ietf.org
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.
 I agree

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.

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.


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

 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.


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.

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.

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 ...

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 m

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

[Daniel Migault]

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, 
wrote:

> Hi,
>
>
>
>> 
> 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.
>>
>> 
> 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.
> 
>
>
> 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 
>> wrote:
>>
>> 

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

[Daniel Migault]

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, 
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> 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:
>
> 
>
> 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.
>>
>> 
>
> 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:
>
> 
>
> 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.)
>
> 
>
>
> *@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:
>
> CLIENTEDGE-SERVER
>  KEY-SERVER
> >
>
>
>
>TLS12 Request Header
>TLS12MasterRSARequestPayload
>key_id
>client_random
>S
>pfs
>EncryptedPremasterSecret
>>
>
>
> *and if we had*
>
> CLIENTEDGE-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)” 

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

[Daniel Migault]

On Thu, Jun 7, 2018 at 5:59 PM, 
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:
>
> 
>
> 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.
>>
>> 
>
> 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:
>
> 
>
> 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.)
>
> 
>
>
> *@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.
>
> 
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...



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

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

[i . boureanu=40surrey . ac . uk]

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:


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.


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:


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.)



@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

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

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

[Daniel Migault]

Hi Ioana,

The current working version is available here:
https://github.com/mglt/draft-mglt-lurk-tls12

The txt and mkd version are in sync. Feel free to update the text.

To briefly respond to your comments:

* TLS1.1 has been removed from this document.
* The way we implement PFS is described in section 4.1.1 "Perfect Forward
Secrecy".
* For the extended master secret, I do not thing the current design is
acceptable as there is no PFS.

I will send an update email to notify the list of the changes performed on
the version available on the git.

Feel free to update the document on github!

Yours,
Daniel






On Sat, May 26, 2018 at 6:25 AM, 

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

[i . boureanu=40surrey . ac . uk]

Hi Daniel,



Thanks for this.
Please see my answers below.


On 26 May 2018, at 01:08, Daniel Migault 
> 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".

If this were me, I would consider  altogether removing TLS 1.1…, unless there 
is some very stringent and very well motivate use-case for ot.

We are also planning to design an extension for TLS 1.3 by next IETF in 
Montreal.

Good. That’s great.

My understanding of step 1 and 2 is to prevent a passive attacker to send a 
request to the key server.

He is not just passive: first he is passive, then he is active —querying the 
key-server on an old KE_C = enc_pkS(premaster-secret)

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).

That was one of my suggestions for remedies to the above!
I did not see this in the Feb. draft.

More specifically, a recorded TLS handshake can only be replayed if the nonce 
provided by the key server matches the recorded one.

And that cannot happen, as I presume the channel between the key-server and the 
edge-server is secured...

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).

Correct. I wrote this in my initial comments. But without this nonce N_S 
contributed in the ServerHello from the key-server to the edge-server, the 
querying on an old KE_C is just unstoppable.

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.

Not sure what the 1st sentence means, but the 2nd is the crux of the doing this 
proxied handshake securely: one needs to bind the server in the ServerHello 
message.

In fact I do not remember as I write this, if the edge-server only sends KE_C 
back to the Server  at the end of the handshake, but I would make the 
edge-server send to the key-server [N_C , KE_C , enc(k_C;Client-Finished) ] at 
the end of the handshake. Like this the key-server, can check that his nonce 
N_S and *that the nonce N_C* appear in Client-Finished.

By the way, in the above, I call “ N_S” what you call "server-random” and “N_C" 
what you call "client-random”.


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.

Where does this M come from? Who produces it? I could now see it in the 
February draft.

Let’s do this…: I will just look at the link you sent me to the online, current 
draft.
Sorry for my commenting potentially on some old draft.

In addition, the server_random carry the time and the key server does not 
respond when the server_random is out of a windows.

That’s good.
I still would like  to check  that hash(M) thing...

Note that this latest time control may also be performed in your case.)

Correct.


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.

I agree, modulo the fact that I still would like  to check  that hash(M) 
thing...

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.

I will check and make comments on the very draft therein.

It will be done on Tuesday.

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

OK. If you want session-resumption, you have to give back “msk”  indeed.


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 do not follow this phrase above…. Sorry.
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!

You’re welcome.

I will be back on email and on this on Tuesday.


Best,
Ioana


Yours,
Daniel


On Thu, May 24, 2018 at 10:39 AM,