Re: [Secdispatch] Ciphertext format draft

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 15 January 2021 20:23 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D883A1158 for <secdispatch@ietfa.amsl.com>; Fri, 15 Jan 2021 12:23:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.526
X-Spam-Level:
X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.569, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47bispuQgd49 for <secdispatch@ietfa.amsl.com>; Fri, 15 Jan 2021 12:23:05 -0800 (PST)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8567E3A1154 for <secdispatch@ietf.org>; Fri, 15 Jan 2021 12:23:05 -0800 (PST)
Received: by mail-wr1-x433.google.com with SMTP id q18so10532788wrn.1 for <secdispatch@ietf.org>; Fri, 15 Jan 2021 12:23:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=dodI6USvpDXmqsNNidOroC9iYhNmcNTFuSxXQlKT1JA=; b=CaivW/IzFJkpeaQnphc2cG2ssZrDivou/eqg+V86sg+b1U2/MByCJEZ7YCoeAlOYPf sGQ6GVDFqS4QKX4MyKy8iNg4ZOdVhbUj2mb/L1500Pvakc01BNkq8y7fozpQhHhMgncZ znAnr/zBJmbv7p3qMHghegPFEWLkZwHSO0c4P5+5XbA/hLb9P0iuCyS4I8Pk18ZDZg4t egveEZsh0ivU/E+hvgAapSC2SEejEaiSPhs82jKUmop/gIuawLVB7y/KOTlGVKA3e1Hi lSLP5QhrMis7IoA5ghGmVawBdrscCksnuyhkcDw+WytWlYglctwKYwn8LaF8Y4SbwBof iAsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=dodI6USvpDXmqsNNidOroC9iYhNmcNTFuSxXQlKT1JA=; b=psjqmNHe98JcUVHinNfSnk+n8PBbS4kVs8NaO+dEi/t8Eoom3BmRenSfGW2fOXr6It 5G6THFORt9ByfCHyrO6SepdcOuqstodwEtiSJyN0Yv2d7DDb5pP0nvDTP7yqNOFsPQ/e qF+8BJxLJluIyJjaPyo+8mTENEuJlDfZFVLVIo6K3IPdXXUgrxdq27N546Q2Uo73yQIC Ejur204q1Gd4h/NcRPwrBamdpN/l2FY8yGgdSkgre4c8ayeU17fvhnBzrUm+zi8Ain9D FiHVBAENnvejrAt5gmWxz24pTBaxnRRTqFwBHhVU+L0r4oKrKOY9YenwiFLiXffD6lND gqCA==
X-Gm-Message-State: AOAM5316CFy2wCYlhn0Dn+9z+W6Z9pJpEmyrZrsJLYhYNstT2i8nx+fz JBUDhm4Fs4N5dCEZdWl1Rtc=
X-Google-Smtp-Source: ABdhPJzA8GhbJhV+qexwGR1+rItswgsrquPXJxCfl2Vvu5ndvWvyRi20khbzl054Ps9cdLkwXEUAQA==
X-Received: by 2002:adf:a40e:: with SMTP id d14mr4854207wra.144.1610742183997; Fri, 15 Jan 2021 12:23:03 -0800 (PST)
Received: from [192.168.68.105] (bzq-79-183-113-247.red.bezeqint.net. [79.183.113.247]) by smtp.gmail.com with ESMTPSA id c4sm13722977wmf.19.2021.01.15.12.23.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jan 2021 12:23:03 -0800 (PST)
User-Agent: Microsoft-MacOutlook/16.45.21011103
Date: Fri, 15 Jan 2021 22:23:01 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: Russ Housley <housley@vigilsec.com>
CC: IETF SecDispatch <secdispatch@ietf.org>, "Keselman, Gleb" <Gleb_Keselman@intuit.com>, Yoav Nir <ynir.ietf@gmail.com>
Message-ID: <3C9F29DF-CDA6-48BA-B94E-5CCE63E4AA57@gmail.com>
Thread-Topic: [Secdispatch] Ciphertext format draft
References: <8B46C11A-790A-4E8E-A7A1-8FE97E2DD9A7@contoso.com> <523854C0-3D2B-4565-A6FF-8DF46EBD88A2@vigilsec.com>
In-Reply-To: <523854C0-3D2B-4565-A6FF-8DF46EBD88A2@vigilsec.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3693594183_1796884523"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/lofphtL4NbOr7IQO7owwjy_2_Rs>
Subject: Re: [Secdispatch] Ciphertext format draft
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2021 20:23:08 -0000

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 <housley@vigilsec.com>
Date: Friday, January 15, 2021 at 18:37
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: IETF SecDispatch <secdispatch@ietf.org>, "Keselman, Gleb" <Gleb_Keselman@intuit.com>, Yoav Nir <ynir.ietf@gmail.com>
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 <yaronf.ietf@gmail.com> 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
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch