Subject: [Lurk] Open source implementation of Key Server following draft-cairns-tls-session-key-interface-01

From: OSCAR GONZALEZ DE DIOS <[email-masked]>
Date: Sun, 3 Apr 2016 20:19:31 +0000

Hi LURKs, authors of [email-masked],

   Following the IETF principle of believing in running code, we have
implemented a prototype of a Key Server following
draft-cairns-tls-session-key-interface-01. I think it is useful as a base
point to play with the concept, make modifications and improvements in the
interface, and detect weaknesses, play with packet losses, etc.

   The repository is publicly available in
https://github.com/mami-project/KeyServer with an Apache license. The
first version available is functional (not focused on performance). In
this first functional implementation after a session is closes the HTTPS
connection, but the next version (to be released asap) keeps the
connection persistent as suggested by the draft. The keys are stored in a
redis database unable to be accessed from the exterior, only internally
from the Key Server.

   Some preliminar feedback:

   - Authentication and identity verification is left to implementer¹s
choice. It might be better to add more requirements here. Now, e.g. The
implemented Key Server has a whitelist of IPs it allow connections from.
User/password of certificates could be used to have more security.

    - There was one question in the list about throughput. The Key server
does the following steps (without counting opening the HTTPS session):
        1) parse JSON input data
        2) query redis database with the hash of the certificate.
        3) get the private key associated to the certificate
        4) applies description in case of RSA or signing in case of ECDHE
        5) creates a JSON structure with the previous information
        6) sends the data though the socket

        The query time to the redis database depends on the number of private
keys stored in the key server. Any hint on what could be a good practice?

    - Do you expect many distributed Key Servers with few keys, or some
distributed key servers with a keys from different edge servers? If we try
to avoid

     If you have more questions about the implementation, let me know. In
any case, I¹ll be around in the Lurk BoF. And if  you want to play and do
you own modifications.. Just fork the code :-)

        Best Regards,

                Óscar

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 4 Apr 2016 10:33:02 -0300

Thank you Oscar!

Draft authors, I suggest you update the draft per RFC 6982.

Best,
	Yaron

On 04/03/2016 05:19 PM, OSCAR GONZALEZ DE DIOS wrote:
> _______________________________________________
> Lurk mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lurk
>

---

From: Daniel Migault <[email-masked]>
Date: Mon, 4 Apr 2016 13:41:20 +0000

Thanks for providing the RFC. I was not aware of this one. We will of course update the draft with it. 

BR, 
Daniel

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Monday, April 04, 2016 10:33 AM
To: OSCAR GONZALEZ DE DIOS; [email-masked]; [email-masked]
Subject: Re: [Lurk] Open source implementation of Key Server following draft-cairns-tls-session-key-interface-01

Thank you Oscar!

Best,
	Yaron

On 04/03/2016 05:19 PM, OSCAR GONZALEZ DE DIOS wrote:
> draft-cairns-tls-session-key-interface-01. I think it is useful as a 
> base point to play with the concept, make modifications and 
> improvements in the interface, and detect weaknesses, play with packet losses, etc.
>
> this first functional implementation after a session is closes the 
> HTTPS connection, but the next version (to be released asap) keeps the 
> connection persistent as suggested by the draft. The keys are stored 
> in a redis database unable to be accessed from the exterior, only 
> internally from the Key Server.
>
>     - Authentication and identity verification is left to 
> implementer¹s choice. It might be better to add more requirements 
> here. Now, e.g. The implemented Key Server has a whitelist of IPs it allow connections from.
>      - There was one question in the list about throughput. The Key 
> server does the following steps (without counting opening the HTTPS session):
>          1) parse JSON input data
>          The query time to the redis database depends on the number of 
> private keys stored in the key server. Any hint on what could be a good practice?
>
>      - Do you expect many distributed Key Servers with few keys, or 
> some distributed key servers with a keys from different edge servers? 
> If we try to avoid
>
>       If you have more questions about the implementation, let me 
> know. In any case, I¹ll be around in the Lurk BoF. And if  you want to 
> play and do you own modifications.. Just fork the code :-)
>
>          Best Regards,
>
>                  Óscar
>
>
>
>
>
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
> destinatário, pode conter informação privilegiada ou confidencial e é 
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa 
> senhoria o destinatário indicado, fica notificado de que a leitura, 
> utilização, divulgação e/ou cópia sem autorização pode estar proibida 
> em virtude da legislação vigente. Se recebeu esta mensagem por erro, 
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
> proceda a sua destruição
>