Subject: [Lurk] RSA authentication

From: Daniel Migault <[email-masked]>
Date: Thu, 24 Mar 2016 18:40:10 +0000

Hi,

When RSA authentication method is used, there are basically three ways to generate the Master Secret or the Extended Master Secret. In addition to the PRF and the RSAEncryptedPreMasterand, depending on how these secret are built we need to provide:

*         standard_master: the ClientHello.random and the ServerHello.random.

*         extended_master_from_session_hash: the session_hash

*         extended_master_method_from_handshake_messages: the complete handshake message.

I would be happy to have your opinion:

In your opinion should we consider both the generation of the master secret AND the extended master secret.

If we want to generate the extended master secret, do you have any preference on the method to use? In other words, do you think that the session_hash is sufficient to prevent the Key Server to operate as an oracle?

BR,
Daniel

[Ericsson]<http://www.ericsson.com/>

DANIEL MIGAULT
Researcher
Research

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
[email-masked]<mailto:[email-masked]>
www.ericsson.com<http://www.ericsson.com>

[http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>

Legal entity: Ericsson Canada Inc., registered office in Montreal. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 24 Mar 2016 18:53:26 +0000

Hi Daniel,

Am I assuming correctly that extended_master_from_session_hash refers to RFC 7627?

Which RFC describes the 3rd option (extended_master_method_from_handshake_messages)?

Cheers,

Andrei

From: Lurk [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Thursday, March 24, 2016 11:40 AM
To: [email-masked]
Subject: [Lurk] RSA authentication

Hi,

BR,
Daniel

[Ericsson]<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ericsson.com%2f&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cc8c8c2f34f82464d2be108d35413c835%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=PbY52lD%2bKigbSCVevA8oc9edEGv%2fD%2bstH6tlPvHzafA%3d>
DANIEL MIGAULT
Researcher
Research

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
[email-masked]<mailto:[email-masked]>
www.ericsson.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ericsson.com&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cc8c8c2f34f82464d2be108d35413c835%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=l27zPG55Zu%2f4M1zdaNMs9v%2fCI1OTtXby6xXyaN8U5OA%3d>

[http://www.ericsson.com/current_campaign]<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ericsson.com%2fcurrent_campaign&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cc8c8c2f34f82464d2be108d35413c835%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Nd9UCTVnRNo0G1FFpaA7ZzB1%2fLgX2WkBzT3wOiNHliA%3d>

Legal entity: Ericsson Canada Inc., registered office in Montreal. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ericsson.com%2femail_disclaimer&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cc8c8c2f34f82464d2be108d35413c835%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=el2p5uVbYLqorWWLI1Y7n90l9jj7Xv37GHrN7VCtSEA%3d>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 24 Mar 2016 19:10:36 +0000

Hi Andrei,

The second and third option both refer to rfc7627.

[RFC7627] defines the Extended Master Secret Extension where the
   "master_secret" is defined as follows:
    master_secret = PRF(pre_master_secret, "extended master secret",
                           session_hash)
                          [0..47];
    where:
       - session_hash = Hash(handshake_messages)
       - handshake_messages is the concatenation of all the exchanged
         Handshake structures, as defined in Section 7.4 of [RFC5246].
       - Hash is as defined in Section 7.4.9 of [RFC5246]

So if you would like the extended Master Secret to be generated you can either provide the following inputs:
a) PRF, RSAEncryptedPreMasterand and session_hash
OR
b) PRF, RSAEncryptedPreMasterand and handshake_messages

With option b, the Key Server will have to hash itself the handshake messages to generate the session_hash. The advantage I see with this alternative is that the Key Server can perform quite a lot of checks on the handshake messages, which may limit the use of the Key Server outside the scope of TLS. On the other hand, handshake message may come with a large overhead. Providing the session_hash may reduce the overhead, but provide less control for the Key Server.

BR,
Daniel

From: Andrei Popov [mailto:[email-masked]]
Sent: Thursday, March 24, 2016 3:53 PM
To: Daniel Migault; [email-masked]
Subject: RE: RSA authentication

Hi Daniel,

Cheers,

Andrei

From: Lurk [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Thursday, March 24, 2016 11:40 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Lurk] RSA authentication

Hi,

BR,
Daniel

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada

---

From: Andrei Popov <[email-masked]>
Date: Thu, 24 Mar 2016 19:33:37 +0000

Now I see what you mean, but why is the Key Server in charge of generating the master secret? I thought the Key Server would only need to decrypt the premaster secret?

From: Daniel Migault [mailto:[email-masked]]
Sent: Thursday, March 24, 2016 12:11 PM
To: Andrei Popov <[email-masked]>; [email-masked]
Subject: RE: RSA authentication

Hi Andrei,

BR,
Daniel

From: Andrei Popov [mailto:[email-masked]]
Sent: Thursday, March 24, 2016 3:53 PM
To: Daniel Migault; [email-masked]<mailto:[email-masked]>
Subject: RE: RSA authentication

Hi Daniel,

Cheers,

Andrei

Hi,

BR,
Daniel

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada

---

From: Daniel Migault <[email-masked]>
Date: Thu, 24 Mar 2016 19:41:46 +0000

The motivation for making the Key Server generate the master and not the premaster is to protect the Key Server and the private key from a chosen cipher text attack.
Suppose the Key Server only decrypt, an attack could potentially chose cipher texts that are sent to the Key Server, which return the corresponding clear text. If instead of the clear text, the hash of that clear text is returned, then we believe we make lurk more resistant to such attacks.

BR,
Daniel

From: Andrei Popov [mailto:[email-masked]]
Sent: Thursday, March 24, 2016 4:34 PM
To: Daniel Migault; [email-masked]
Subject: RE: RSA authentication

From: Daniel Migault [mailto:[email-masked]]
Sent: Thursday, March 24, 2016 12:11 PM
To: Andrei Popov <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: RSA authentication

Hi Andrei,

BR,
Daniel

Hi Daniel,

Cheers,

Andrei

Hi,

BR,
Daniel

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada

---

From: Andrei Popov <[email-masked]>
Date: Thu, 24 Mar 2016 21:12:23 +0000

A significant disadvantage of this design is that it's coupled to the internals of TLS master key generation, and will therefore need to be updated as new TLS extensions and versions are defined.
If you go this route, then the Key Server will have to support both traditional and extended master secret (a lot of clients still don't negotiate EMS, sometimes due to middle boxes dropping the extension).

Instead, could the attack be mitigated by authenticating the content server and cutting it off when it's compromised (within a reasonable time-frame)?

From: Daniel Migault [mailto:[email-masked]]
Sent: Thursday, March 24, 2016 12:42 PM
To: Andrei Popov <[email-masked]>; [email-masked]
Subject: RE: RSA authentication

BR,
Daniel

Hi Andrei,

BR,
Daniel

Hi Daniel,

Cheers,

Andrei

Hi,

BR,
Daniel

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada

---

From: Daniel Migault <[email-masked]>
Date: Thu, 24 Mar 2016 23:36:31 +0000

Even in the case of the first option, the communication between the edge server and the key server must be authenticated and encrypted. The question then is: is that sufficient in practice. I am happy to share opinion on it.

Even though it might be sufficient, I personally prefer to implement the MS / EMS at the Key Server as an additional security that prevent leakage of information on the private key.

BR,
Daniel

From: Andrei Popov [mailto:[email-masked]]
Sent: Thursday, March 24, 2016 6:12 PM
To: Daniel Migault; [email-masked]
Subject: RE: RSA authentication

BR,
Daniel

Hi Andrei,

BR,
Daniel

Hi Daniel,

Cheers,

Andrei

Hi,

BR,
Daniel

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada