SPEC: encrypt all ACIs

[philips]

This is a discussion topic.

It is desirable to let people encrypt ACIs so that they can host the ACI on third party providers and place secrets inside an ACI. There are two paths to go: either make the encryption an optional code path or just make it so all ACIs are encrypted.

This issue is suggesting we consider encrypting by default.

For public ACIs this would mean that there would be a .aci.key file that would sit next to the image and describe the encryption that was used and the symmetric key to unlock it. For private ACIs this key could be distributed out of band or the .aci.key file could be protected behind a transport mechanism that could be discovered via something like ac-encryption-key https://mysecretstore.example.com which you would authenticate to using some sort of HTTP Authorization header.

Open Questions:

• File format of the .aci.key file?
• File format of the encryption: PGP or described in the .key file?

[polvi]

Few other design reasons why I'm in support:

If everything is encrypted:

• We have to deal with the UI and make it great
• Decoupling encryption from transport allows bittorrent to be trivial, as well as issues with data at rest
• Amazon AMIs have always been encrypted and tools for building them seem to handle it easily
• Mixing encrypted/non-encrypted content could leave users confused as to what is safe to put on public storage vs internally, etc.

[eyakubovich]

What about performance implications of always encrypting? On a large ACI (say a 200MB), this could add about 1-2 seconds. Still less than typical transport cost but not negligible. Obviously this cost is well worth it for private ones, but questionable for public ones.

While I don't know how it will actually play out, secrets can be brought in via a dependency (or invert the pattern) but either way, I see most bits being public.

[jonboulle]

@eyakubovich I guess one compromise would be to assume that ACIs are encrypted (and hence must always have an accompanying keyfile), but allow people to disable encryption by using a noop encryption type in the .key. But still have it on by default, of course ;-)

[eyakubovich]

@jonboulle I think that's a good compromise.

[b]

Why is that preferable to automating everything around the encryption and key management such that there is no overhead for users to produce properly encrypted images every time? The performance impact is minuscule, but secure defaults are enormously valuable.

[jonboulle]

I think that would be the ideal if we could make the UX absolutely streamlined. But that doesn't mean we have to explicitly preclude people from opting out.

[b]

Certainly, people should be able to opt out. What I am arguing is that the encryption pipeline should be built such that nobody wants to. Otherwise, lots of people will, quite reasonably, disable encryption because it is frustrating and that's a bad outcome.

[eyakubovich]

@b The performance impact is not significant but it's not minuscule. And the benefit is only for cases when there's something to hide :) But you're absolutely right that nailing the UX for encrypted case is important.

[b]

Bring performance data.

The "only if you have something to hide" argument about secrecy has a pretty sordid history, so probably not the best way to advocate against default encryption.

[chris-rock]

I think, encryption should not be enforced in a spec. Appc should ship with great options for encryption but leave it open to specific implementations to ship with encryption e.g. rocket may decide to support encrypted images only.

This would allow the runtime to expect the image to be unencrypted (tar + gzip). If an key file is available it tries to decrypt the image.

Is there any reason why the spec should restrict the encryption to symmetric keys?

[b]

The performance of asymmetric systems precludes their use for bulk encryption.

[chris-rock]

@b I thought, that the image is decrypted at startup and stays unencrypted on the local machine. Do you intend to keep the the filesystem encrypted all the time?

[b]

Sorry, I don't follow. You asked why the restriction to symmetric encryption. The answer is performance: use of asymmetric encryption for things the size of images is impractical. This is an orthogonal consideration to whether the image is locally decrypted to disk before execution or whether the encrypted image is used directly.

[chris-rock]

Of course the image itself should be symmetric encrypted. I was only talking about the keys. I was thinking about having one deployment key for my rocket machines. By using pubic key encryption, I encrypt the symmetric key with asymmetric encryption. This approach would allow me to restrict access to images to a specific set of machines. What do you think?

[krobertson]

Was talking about this earlier about doing build validation and knowing which keys are valid to be trusted, it was suggested to use/look at OCSP: http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol

Thought it might have some relevance to this topic as well.