Encrypting Confidential Data at Rest task implies recommendation against AES CBC is due to padding oracle risk

[pwolanin]

Maybe I'm missing something, but the comment that "CBC's vulnerability to padding oracle attacks. " is why aescbc is not recommended seems to be misguided or wrong.

Padding oracle attacks can only occur if the attacker can send many different versions of the encrypted data and have the server respond in a way that the attacker can determine that there was an invalid padding. e.g. see https://blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites/

That article notes that AES-CBC is secure for encrypting static content. I think that matches how it's used for the secrets API I'd also hope that kubernetes stores the encrypted secrets using a MAC after encryption, which removes the padding oracle attack vector.

How does a padding oracle attack become relevant in this context?

re: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

[utkarsh-singh1]

/language en

[sftim]

/kind support

This does feel mostly like a support query. These docs were reviewed for technical accuracy; if they are wrong, we'd like evidence, rather than a question.

If you want to use the AES CBC mode, despite the project's recommendations, you can.

[pwolanin]

It is not a support query. I think this is a technical inaccuracy in the docs - I do not think there is any padding oracle that exists in kubernetes. Indicating that aescbc is weak for that reason is inaccurate.

Obviously I can still use it, and we do use AES-CBC for similar purposes in code internal to our projects where we want to encrypt multiple secrets at rest using the same encryption key.

[sftim]

/remove-kind support /priority awaiting-more-evidence /sig security auth

[sftim]

/retitle Encrypting Confidential Data at Rest task implies recommendation against AES CBC is due to padding oracle risk

[sftim]

Relevant but different to this issue's focus: we should add more of a concept guide to API encryption at rest. Then, the task page can focus on the “how”, with hyperlinks into the concept page for the “why” aspects.

[sftim]

I have some PRs including https://github.com/kubernetes/website/pull/43176 that aim to help around the topic of API encryption at rest, but either:

• the quality is not yet right on those PRs
• we're short of reviewer time

Help is welcome

[sftim]

What we actually recommend is KMS with a v2 plugin and a KEK that's never revealed to the Kubernetes API server. This is a security model I personally like, too.

[pwolanin]

Yes, clearly not having the KEK in kubernetes is better, but I don't think the doc is accurate as is

On Fri, Dec 1, 2023, 08:58 Tim Bannister @.***> wrote:

What we actually recommend is KMS with a v2 plugin and a KEK that's never revealed to the Kubernetes API server. This is a security model I personally like, too.

— Reply to this email directly, view it on GitHub https://github.com/kubernetes/website/issues/44169#issuecomment-1836163670, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA2JKYHH425GQVBU4PMF6DYHHPBVAVCNFSM6AAAAABACEXQ62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZWGE3DGNRXGA . You are receiving this because you authored the thread.Message ID: @.***>

[sftim]

I'm inferring that in the absence of a formal proof around the lack of a padding oracle, precaution is good. The docs don't state this.

[pwolanin]

In order for a padding Oracle to exist the attacker must be able to submit multiple versions of the cipher text for attempted decryption and also the stored value must have been done as MAC before encrypt.

I am pretty sure those conditions don't exist. What kind of proof is needed?

On Fri, Dec 1, 2023, 09:50 Tim Bannister @.***> wrote:

I'm inferring that in the absence of a formal proof around the lack of a padding oracle, precaution is good. The docs don't state this.

— Reply to this email directly, view it on GitHub https://github.com/kubernetes/website/issues/44169#issuecomment-1836244429, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA2JK52PQ22AY4S56AACW3YHHVD3AVCNFSM6AAAAABACEXQ62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZWGI2DINBSHE . You are receiving this because you authored the thread.Message ID: @.***>

[ibihim]

/triage accepted