Hi Jesus Albertot, You are more than welcome to intergate LURK with OpenSSL and NGINX. We discussed this during the hachathon in London, so feel free to share your thoughts or questions on the mailing list. I am sure you will get some interesting feed backs.
If I understand correctly your question is whether the Key Server should only "decrypt" the premaster versus computing the master secret. One reason is to limit the scope of usage of the private key. Returning the premaster can be used by any attacker to decrypt any random bytes ( of the size of the premaster ) which could be used outside the scope of a TLS session. Returning the master, instead limits the usage outside the scope of TLS. A typical attack could consist in asserting you are the company " www.example.com" and ask users to rely on the RSA public key to encrypt some data. An attacker corrupting a edge server to gain access to the key server could decrypt this data and as such impersonate "www.example.com". In this example data is outside the scope of a TLS session. Returning the master requires the attacker to reverse the master to the premaster to access data which is harder to do. Another reason is that within the scope of TLS providing the master enables to provide perfect forward secrecy, and in our case the inability to regenerate a master secret from an observed TLS key exchange. If the key server returns the premaster, an attacker corrupting a edge server to gain access to the key server and observing a TLS key exchange is able to access the master and decrypt the TLS session. If the attacker does not have physically access to the private key, he will have the opportunity to perform the operation it needs. The purpose of PFS is to prevent that a TLS key exchange can be replayed even if you have access to the Key Server. The mechanism currently described is the one from  which uses a one one-way function. The key server and the edge server uses hash( R ) for the server random. A passive observer will see H( R ) on the wire, and needs to send R to the Key Server for the generation of the master. This is assumed to be a difficult operation. This mechanism prevents requesting the Key Server from an observed TLS key exchange. However, we do not prevent "illegitimate" exchange to happen, that is request outside a TLS exchange. Note also that by providing the master, the edge server is able to do session resumption.... The following document provides a security analysis of KeylessSSL . Thank you for raising this question and please feel free to raise your concern. Yours, Daniel  https://tools.ietf.org/html/draft-erb-lurk-rsalg-01  https://epubs.surrey.ac.uk/813643/1/mainKeyless.pdf On Mon, Apr 9, 2018 at 4:32 AM, Jesús Alberto Polo <i...@jesusalberto.me> wrote: > Hi, > > > I’m currently working on an implementation of LURK to be integrated with > OpenSSL and NGINX. After having identified all main parts and started the > development, I have some questions regarding the LURK extension for (D)TLS > 1.1 and 1.2 draft, more specifically for RSA as key exchange method > (rsa_master, section 5). > > > As I understand, the Edge Server (LURK client) only needs the Private Key > to decrypt the premaster secret sent by the TLS client. I would like to > understand why LURK server computes the master secret instead of only > decrypting the premaster secret and letting the Edge Server compute the > master secret (since it is terminating the TLS connection). In this way: > > > 1. the LURK server would still protect the private key. > 2. it’d be less intrusive for the TLS protocol (the only change is the > remote decryption instead of local decryption), it’d have less impact on > the OpenSSL code as well. > 3. less error handling (however, LURK server would have less control > over the cyphers, TLS versions, PRF functions…). > 4. the master secret would be locally computed by the TLS server and > never sent through the network (that is, even if an attacker compromises > the secure connection between LURK client and server and steals the > decrypted premaster key, they still need for other values of the TLS > connection in the LURK client). > > Thank you in advance. > > > Best regards, > > Jesús Alberto > > _______________________________________________ > Lurk mailing list > Lurk@ietf.org > https://www.ietf.org/mailman/listinfo/lurk > >
_______________________________________________ Lurk mailing list Lurk@ietf.org https://www.ietf.org/mailman/listinfo/lurk