Subject: [Lurk] Some SKI protocol requirements

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 21 Jan 2016 12:48:06 +0300

Hello,

As I had some experience implementing a SKI-like solution for one of our
client,
I think there are some more points that may be taken into account when we
design the SKI protocol.

1. Real-life applications need to check whether the Key Server has a
private key matching the public key present at the Edge  server.

2. A keepalive option between the Edge Server and The Key Server may be
useful, though I am not sure that it should be at the protocol level.

3. Do we need to pad the messages (digest value, premaster secret, etc)
that are transmitted between the Edge Server and the Key Server? Can it
make the traffic analysis more difficult?

Also I am not sure that the term "Content Provider" used in drafts is exact
enough. I think that the variant "Content Owner" should be better.

Thank you!

-- 
SY, Dmitry Belyavsky

---

From: Daniel Migault <[email-masked]>
Date: Thu, 21 Jan 2016 14:35:50 +0000

Hi Dimitry,

Thanks for the feed backs. I am assuming you refer to the following document:

https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01

Please see my comment inline.

BR,
Daniel

From: Lurk [mailto:[email-masked]] On Behalf Of Dmitry Belyavsky
Sent: Thursday, January 21, 2016 4:48 AM
To: [email-masked]
Subject: [Lurk] Some SKI protocol requirements

Hello,

As I had some experience implementing a SKI-like solution for one of our client,
I think there are some more points that may be taken into account when we design the SKI protocol.

1. Real-life applications need to check whether the Key Server has a private key matching the public key present at the Edge  server.

MGLT: That is a very good feed back. I think that such requirement should be mentioned in the architecture document, that is: https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01
My intention when writing the following document  https://tools.ietf.org/html/draft-mglt-lurk-tls-requirements-00 was to identify the requirements associated to the model of a split authentication, that is for each authentication what are the credential that can be shared and what data should or must not been exchanged between the Content Owner and the Edge Server. The purpose of the abstract api is mostly to formalize a bit more these exchanges so they match the requirements.  This abstract API may be implemented in different ways, and with additional exchanges. Maybe such exchange could be also mentioned here. I will publish the abstract API soon and feel free to let us know what you think.

2. A keepalive option between the Edge Server and The Key Server may be useful, though I am not sure that it should be at the protocol level.

MGLT: I think some requirements/recommendations should be added in the architecture document.  We could also end up with an optional exchange in the abstract API, but the keep alive may also be performed at various layers (TCP, http) too…

3. Do we need to pad the messages (digest value, premaster secret, etc) that are transmitted between the Edge Server and the Key Server? Can it make the traffic analysis more difficult?

MGLT: If I am correct the motivation for padding would be to hide any information derived from the payload sizes while in motion. Since TLS/IPsec enable padding I would be more inclined to  leave that to the transport layer security (TLS). But they might be some needs to have that feature at the application layer too.

Also I am not sure that the term "Content Provider" used in drafts is exact enough. I think that the variant "Content Owner" should be better.

MGLT: I agree with that.
Thank you!

--
SY, Dmitry Belyavsky

---

From: Dmitry Belyavsky <[email-masked]>
Date: Fri, 22 Jan 2016 16:28:36 +0300

Dear Daniel,

On Thu, Jan 21, 2016 at 5:35 PM, Daniel Migault <[email-masked]
> wrote:

> https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01
Yes.

And one more point omitted in the description:
It should be useful to have a "cookie" in requests. It should be repeated
in response to identify the original request (and handshake) at the Edge
Server.

-- 
SY, Dmitry Belyavsky