Re: [Secdispatch] Ciphertext format draft

[Yaron Sheffer <[e-mail]>]

Hi Russ,

 

NIST 800-38D speaks of a single AAD input, not multiple. Thus we have a single AAD field in the format. An application can obviously concatenate multiple inputs into this field, and we could add instructions how to do it securely. Would that address your comment?

 

Thanks,

                Yaron

 

From: Russ Housley <[e-mail]>
Date: Sunday, January 17, 2021 at 18:10
To: Yaron Sheffer <[e-mail]>
Cc: "Keselman, Gleb" <[e-mail]>, Yoav Nir <[e-mail]>, IETF SecDispatch <[e-mail]>
Subject: Re: [Secdispatch] Ciphertext format draft

 

Yaron:

 

Binding the plaintext fields to the ciphertext ones is important, but it requires knowledge such as the ordering that is not expressed in the format.  That would be useful.

 

Russ



On Jan 16, 2021, at 5:13 PM, Yaron Sheffer <[e-mail]> wrote:

 

Hi Russ,

 

In the example in the document, the database primary key (e.g. customer’s email address) is included as AAD for all the fields that are encrypted for that customer. This prevent an attacker who can modify the database (but has no access to keys) from moving encrypted fields from one customer to another. Decryption of such moved fields would fail.

 

Note that in this use case, the AAD does NOT need to be stored explicitly, because it is a duplicate of data in other (plaintext) fields.

 

Quoting the blog: “EncryptionContext should include all of the information associated with the ciphertext that you will later need to interpret it. A good rule is to always include at least enough information to uniquely identify the location of the ciphertext (for example, a URI, file path, or database table and primary keys).”

 

Thanks,

                Yaron

 

From: Russ Housley <[e-mail]>
Date: Friday, January 15, 2021 at 23:40
To: Yaron Sheffer <[e-mail]>
Cc: "Keselman, Gleb" <[e-mail]>, IETF SecDispatch <[e-mail]>, Yoav Nir <[e-mail]>
Subject: Re: [Secdispatch] Ciphertext format draft

 

Yaron:

 

The document does not saqy anything about what might go in the AAD field.  I know what it is, and I know how it is used in packet protocols.  But how is it used in this database context?

 

Russ




On Jan 15, 2021, at 3:23 PM, Yaron Sheffer <[e-mail]> wrote:

 

Hi Russ,

 

I’m not sure what you are asking re: AAD. This is a single octet-string input to AES-GCM (NIST SP 800-38D, Sec. 5.2.1.1, as well as RFC 5116). Or did you mean: what is the use case for AAD when encrypting data at rest? Amazon uses AEAD in their KMS SDK, and published [1] a nice blog showing how it can be used to bind ciphertext to its context in order to prevent cut-and-paste attacks.

 

In our main use case, the data is structured with a well defined schema (a.k.a., SQL database). So “content type” doesn’t make sense. This is early days for the format and people will surely come up with other use cases.

 

Thanks,

                Yaron

 

[1] https://aws.amazon.com/blogs/security/how-to-protect-the-integrity-of-your-encrypted-data-by-using-aws-key-management-service-and-encryptioncontext/

 

From: Russ Housley <[e-mail]>
Date: Friday, January 15, 2021 at 18:37
To: Yaron Sheffer <[e-mail]>
Cc: IETF SecDispatch <[e-mail]>, "Keselman, Gleb" <[e-mail]>, Yoav Nir <[e-mail]>
Subject: Re: [Secdispatch] Ciphertext format draft

 

Yaron:

 

How do you see AAD being used? 

 

Also, CMS carries a field that tells how to parse the plaintext (the content type) after it obtained by decryption.  I cannot tell whether that is useful or in you use case, but I can imagine places where it would be very helpful.

 

Russ





On Jan 15, 2021, at 9:53 AM, Yaron Sheffer <[e-mail]> wrote:

 

Hi, we just submitted draft-sheffer-ietf-ciphertext-format-01 [1]. This is a CBOR-based set of headers for encrypted data, with the goal of enabling automation of large datasets that contain encrypted data, typically interspersed with plain data. Specifically we want to facilitate discovery of encrypted data (e.g., this database column contains ciphertext) and attributing this data back to the service that created the data and the key that was used to encrypt it.

 

We received good feedback on the SAAG list to change from generic TLV to CBOR, which we implemented in -01.

 

The authors would appreciate this list’s feedback regarding next steps.

 

Thanks,

                Yaron

 

[1] https://tools.ietf.org/id/draft-sheffer-ietf-ciphertext-format-01.xml

 

_______________________________________________
Secdispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdispatch

 

_______________________________________________
Secdispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdispatch

 

_______________________________________________
Secdispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdispatch