From nobody Thu Jan 14 03:00:29 2021 Return-Path: X-Original-To: secdispatch@ietf.org Delivered-To: secdispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C223A13AE; Thu, 14 Jan 2021 03:00:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: francesca.palombini@ericsson.com, rdd@cert.org, secdispatch-chairs@ietf.org, secdispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161062202714.21019.16948000294996391448@ietfa.amsl.com> Date: Thu, 14 Jan 2021 03:00:27 -0800 Archived-At: Subject: [Secdispatch] secdispatch - New Meeting Session Request for IETF 110 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 11:00:27 -0000 A new meeting session request has just been submitted by Francesca Palombini, a Chair of the secdispatch working group. --------------------------------------------------------- Working Group Name: Security Dispatch Area Name: Security Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: Chair Conflict: cbor core gendispatch httpbis Technology Overlap: cfrg saag dispatch ace acme cose curdle dots emu gnap i2nsf ipsecme kitten lake lamps mls oauth openpgp privacypass rats sacm secevent suit teep tls tokbind trans pearg People who must be present: Kathleen Moriarty Roman Danyliw Richard Barnes Benjamin Kaduk Francesca Palombini Resources Requested: Special Requests: Please avoid conflict with any Security related BoF. --------------------------------------------------------- From nobody Fri Jan 15 06:54:05 2021 Return-Path: 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 5DA1E3A09F5 for ; Fri, 15 Jan 2021 06:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 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, 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 KreSs6CDhGvf for ; Fri, 15 Jan 2021 06:54:02 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 797813A09F6 for ; Fri, 15 Jan 2021 06:54:02 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id c5so9552920wrp.6 for ; Fri, 15 Jan 2021 06:54:02 -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 :mime-version; bh=MOdFUTXIvLaHPvrw/aSCMHwNahagJnknbVMeH4kolsw=; b=QJubp86h+lDXG4QSAwxSMrjtFKPbPRcIbNXqfum5D389/fXtq+BdRufdkaczz32rBq jwWPE2nspfBFYYY1eFVACla54R/Jb/GpeV8ZG9LKPDmXNKyaP4nzHIsCuYb9Qt2UJhaq 2U5Lox9uJwpDizgAX4K8WlL8UFwoJ02dOqVA8WbvuxsuzhX68FJen9ZmxWOFF42fohrY lz4oBwKpJMNknRCkrUssy3nA1PNESoMJZzpe3KZWH1ZD2qPJH/YkoaEpLRxDhzmxFq0d c4AYbupqPmVhNi2kF1qDBHKDG/CSFaxtG5jMp3BnqRnJ41BoqqbYbkO6DZMaBeSeOkK+ lDfQ== 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:mime-version; bh=MOdFUTXIvLaHPvrw/aSCMHwNahagJnknbVMeH4kolsw=; b=W4axbXeCsfEG/+TWMsbP47CtHOrU9E6pxgoDzQSvcIOnTJZUuFwbHPwQQ/ndbgYqBJ lWapt/DLCnIoE9ms/meTUv9yXwa1LQZ7YKy28qQsDVHiR/01pTnytfEvd2Ss/4QTaEIt 3Jzs1tk3zj5SZX+aJAKPdpwi5TIZLVXo92WKP/WFiLAHOVmnFIcoWLup6MLkh0mVM0Ov sAO/ovLFbQgQypz+61X6wt2BIcBXAMzLjYuAvMAwf7qkeZuN15x4nQs+fzsGX8WTrLdc st2SCA1s2+PWBJf+m/0HZ+hOC3liVSQLPTteq87/ayLiI3vQHpP6fP9dzwnu9xIwJsS8 4wGA== X-Gm-Message-State: AOAM533nWmX+hawxjkka4Ew4GY8AbJa7GJiLdZ/rbprFfc2cwE+CX2Mi BWntpTa9E3EghPADhSiZtBhNLqbD0dJIOg== X-Google-Smtp-Source: ABdhPJw+03p8iV6BHrwqPlt9Jigpi/5Cxh0ABaQ86OaPLnM0E8Eesj9wemANyZ1uXoyE4SGwDxljgA== X-Received: by 2002:adf:cc81:: with SMTP id p1mr13471883wrj.339.1610722440694; Fri, 15 Jan 2021 06:54:00 -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 m18sm15371021wrw.43.2021.01.15.06.53.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jan 2021 06:54:00 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.45.21011103 Date: Fri, 15 Jan 2021 16:53:58 +0200 From: Yaron Sheffer To: CC: "Keselman, Gleb" , Yoav Nir Message-ID: <8B46C11A-790A-4E8E-A7A1-8FE97E2DD9A7@contoso.com> Thread-Topic: Ciphertext format draft Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3693574439_684251596" Archived-At: Subject: [Secdispatch] Ciphertext format draft X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 14:54:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3693574439_684251596 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable 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 au= tomation of large datasets that contain encrypted data, typically interspers= ed with plain data. Specifically we want to facilitate discovery of encrypte= d 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. =20 We received good feedback on the SAAG list to change from generic TLV to CB= OR, which we implemented in -01. =20 The authors would appreciate this list=E2=80=99s feedback regarding next steps. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 [1] https://tools.ietf.org/id/draft-sheffer-ietf-ciphertext-format-01.xml =20 --B_3693574439_684251596 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi, we just submitted draft-sheffer-ietf-ciphertext-format= -01 [1]. This is a CBOR-based set of headers for encrypted data, with the go= al of enabling automation of large datasets that contain encrypted data, typ= ically interspersed with plain data. Specifically we want to facilitate disc= overy 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 cha= nge from generic TLV to CBOR, which we implemented in -01.=

 

The authors would ap= preciate this list=E2=80=99s feedback regarding next steps.

<= p class=3DMsoNormal> 

Thanks,=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

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

 <= /p>

--B_3693574439_684251596-- From nobody Fri Jan 15 07:06:45 2021 Return-Path: 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 E24313A0A5E; Fri, 15 Jan 2021 07:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 wAydimgDWty1; Fri, 15 Jan 2021 07:06:36 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60062.outbound.protection.outlook.com [40.107.6.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D558B3A0A69; Fri, 15 Jan 2021 07:06:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gveCQmcVcixRXCtLHKOuummdZniDTpZpkJnDZ5OipXA4DOFDDlZKthLNWAF/gZEd0AjnwEi5Ang1GUI6S1MIcslm7uvRgq1pDRQmAmCOMunylr2qGPodJmoRMuxmRc5l1SERmZjUpXEXEFYsMrjd/qI+c7f8+JPjTfvc1MORBuRnElCNPjlun0s4PjQ1goWof8Vqj7RO8BwVMZJtl6kg2U6e2o05wO0aV2/7W+IG6QaH80t0oKFUFbiY1aIs1+ZLX+uKqrz2r5oROfX7QovJxfL2rvJa5gMPXVMrmDFuzKcj7gWsESHI8KC1Lu30AsviLZjuCKqQs/PAljovVT9Hqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JaBOyw01ei4Vu1mlWlu4cZgCM2436aNTPja04Wx5XvM=; b=acVL50gn+kDEtn9w7NCrWuE+esMQfF2Xm/lwJROFWYRyU4LuTLrT23HAAuHl9KMR98Se5m8fBLtU+xa+nwz+xGZl4DHj5YLdMGIA3VtV2UMAUi+DlFvqPDOVRN9n57RoEM+0N3DFEaLg63+AwWGp3vnVlM+k3jGF2SCs4H8mJ1J0r5zlwWJcIaP1KgXfeirbgrD040SF0ZTNrj+qR76Zj0KvcQYN2DJzb4njQP7VyB1FFO705pWO8gcRz/jBz1aRNTRuzqZo1RS2tS2ARsM0FAoZhkk/F/nTEUCNJOrkw6UsPrqm8qeRjlFt5SgDkelMHAevPgCi+ehXUuWArKXqeA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JaBOyw01ei4Vu1mlWlu4cZgCM2436aNTPja04Wx5XvM=; b=R9pxW6oNYlSQV3JVF/yslKk6PdUyCB1fA3DkTeHdD43bWOqVS7clbX2t0WxrjGe/idn8z3F3ZHVVGf4qIocPQaFNXFPXr+U4aIm1lojU9l1b2XDjo+sTy0M5yIEJxA6EUjGKNMmjtL2Jb3yHfONhZuXLCk5ZnqSuuqcXLG8Or0A= Received: from (2603:10a6:803:74::33) by VI1PR0701MB2814.eurprd07.prod.outlook.com (2603:10a6:800:82::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.5; Fri, 15 Jan 2021 15:06:32 +0000 Received: from VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::4957:ef58:c6d5:9aa2]) by VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::4957:ef58:c6d5:9aa2%6]) with mapi id 15.20.3763.009; Fri, 15 Jan 2021 15:06:32 +0000 From: Francesca Palombini To: "cbor@ietf.org" , Cose Wg CC: "Keselman, Gleb" , Yoav Nir , Yaron Sheffer , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] Ciphertext format draft Thread-Index: AQHW61ACuVzZBfoQR0yF7tKUzsM+eQ== Date: Fri, 15 Jan 2021 15:06:32 +0000 Message-ID: <2EA9CFF4-BB15-4337-ABDF-0BEEEF3A6163@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.44.20121301 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:c100:2d34:4bb5:8890:6849] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e0a152b-0d78-45ab-d3de-08d8b96724f3 x-ms-traffictypediagnostic: VI1PR0701MB2814: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cMv8BcYBBZfZcs3agPSbGznPwbHDlfYVtf7QGZ5UPUdxXkVCgbgXK8C5Kfg49pvt3Blr/EP168p6kfpn4gWfctg0928Uzfq04KTJU/vTQ+oL9K9GoVskdT8PdQfVpk9thIR0KQwEJY7vR//50dUgmXu0R1XHYBA9wwQKoOnDQejT+MNkx7uDxU8kmx7Z5J7gAA2Pa+4fvxevD81hWQzD7VzgPyREER3wAc39pqkuSf9wJRjGhddP1bvaQCJJ8ekE+AZ/q5uE+GX63dVgdFRvynpDRVFbfF3ceaOB5kgTFooEdzSvttQJ+SGTUMGs7yDfJkVdkg6Va6M4Ig5y1osZUP2ygZJzrff/MFggSi05WYoVayfLEpX2oHXEitzomuWeKXKNPDDCHxPBKHRgn2vj/dD38lrlT5Kz+6ZMYUoxQBeDEHjWixZHVQxSke6wt6JalsyCMZAX/dV1X6ADivopH9Q1eZG+PU0MItjeCFd01VibJBCHezPRtfYMkYHamoNGY0tzp54VLX6XLtyUUl4BBQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB4477.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(396003)(366004)(39860400002)(346002)(5660300002)(6506007)(86362001)(53546011)(8676002)(186003)(2906002)(6486002)(4326008)(36756003)(478600001)(8936002)(33656002)(966005)(2616005)(110136005)(66946007)(66476007)(66446008)(66556008)(54906003)(316002)(76116006)(64756008)(91956017)(166002)(44832011)(71200400001)(6512007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?WTI0WjYrNURBaXV4ajRmTWR2OStHZ0lIbld0Vy8rcmZQeGxObnNXS0t0MDds?= =?utf-8?B?Q0JHVXhXaktia2Nsa0dHd2tKb01QMlFSR3N0S25GWHhiSUdHUGxsYlBsQjZ6?= =?utf-8?B?c3drWS83NU4rZzYyZkFiWGNOcDZvcXhUMmxZeS82SmIxaW81NHI3WUUxREsz?= =?utf-8?B?clJzTUo4ZTBEMXJVa1dGRGxJY2ZldFEvcnNhMDNBcml1dzhIaVJaZ1pwUVFI?= =?utf-8?B?cWNMNWJ6QkZRRHhSN2lNaytRVHl2SHFTN1o4SXFOS1pINXhhWm9kN2FTRE5x?= =?utf-8?B?LzNFd0lxaUZOU005Z01YYm1qcjJ1dWNYeXp2NUtxTHRNWjhQN3hHZTNQVEVh?= =?utf-8?B?U3dRNk5tRUJ2MWlsK2pMZEFjZVVOSFFsdFFlYjhXYmxXUkFaVG4wNXZBQUM0?= =?utf-8?B?WDVzczRJN0c4MkdFRjVEOWhTdGtabXdTWm1ESlZBR3RaYWtBSHNtU1Z0dUlr?= =?utf-8?B?d2RCZlREVks4a3NIMkI1ZFc0U3g4Ym1NNGkzNnNxeHJsTWxaTWVwdHhvZ0h3?= =?utf-8?B?VjZ2NDl5cU1wOTk0Nkp6K3ZmUGFRVHBlUzR6SkZ0akV2R2RpL3VPaHY2Qk1I?= =?utf-8?B?RnlJUncvVFpmSjVaUUdSbGZhSDhYeHpFUjJXR3hNOFErN08wNWlOS09TMkZK?= =?utf-8?B?QXpIeDNzWm1wSW1FM3NmazI3dnY1MEJsbmhPT2hwd05zRVhpUU1tZ3VxZFhN?= =?utf-8?B?ajBaV3FXWEVzQVYvbTcrYW5ZWFpXVUZFSVlxYnZ6L1ljQk1CVlhMbXJodjVl?= =?utf-8?B?dlo0MFpCRldjeURmV1NwMHd3VjlIcXVqZ0tlelNkaC9hZDlmNUtrUm5oZisz?= =?utf-8?B?RHh4bmliRnZWMWpmdnJKbVFTZFJ3Q1pVQ2RaaUhXTnU4RERWaDIrakNiR3Rn?= =?utf-8?B?U29xa1JrRGl0QWYzSDhhcmNRY2JGanNYSG4vUDlpWXFjWUJVaXBDMDFEUUx6?= =?utf-8?B?bkNOamRSQVU2L1prRDRaelVGM1R5dXh3c1JlQzRkdkhMVFZMSDRUd2cvZVl6?= =?utf-8?B?aTJEbVo5UURiMmFsN3YvUkZnenJYbVkrRHRmS0ROa1A4dG9nTWxGbFRScUR1?= =?utf-8?B?bHkwSGZuOEYyb2lBVU01eEdqOThHMVdGVkwxSm14K2NBMWNaSmZuWGdYakVh?= =?utf-8?B?YnFGL2hIY0Iwd3FFVDh3RzhORGgvVitYd1Iyb1d6cWNtcWgxM2c4T1hqZDg5?= =?utf-8?B?M0lLUDBkNFdyeExaQlUyTDAvWXhXaklvR1EzZXFqMXdqNHRGTUhaOG1rdnlw?= =?utf-8?B?V0ZpV2dRNzB1V29YOFo2bldVc1RqMnFsN2FCd1VHZlpENS81dy9Cb1lSTXZ0?= =?utf-8?B?UVFIK3htK1lEREVWQ0N6ZlNyQVJqdDdqN09tbCtuRUVRbGdCV25Sc3pxVWdo?= =?utf-8?B?M2VneVl4T0FrOVlOZ0VWVmNQSjZTS0dFVEZXZHVYcVgrQU0zaXh2c292Snhs?= =?utf-8?B?U3doTU5IRmxneFU3bm5mbEZZVXhyd21POERwNm9LSlAxYyt1eE0zTWc4TUx5?= =?utf-8?B?ZXNhOGtiQy9pK1d6ZzZVQlZna2lJemxaSCtnNTRia2N6Y0lqOWxjc1ZmWDF0?= =?utf-8?B?ckFPZz09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_2EA9CFF4BB154337ABDF0BEEEF3A6163ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB4477.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e0a152b-0d78-45ab-d3de-08d8b96724f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2021 15:06:32.5084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qmI7Kdhon+JA4us8tY1Z3Y1swGutscIwivZdE6Xcg2DZ4nfC9vCLSE51BggtyuYRSddnQzhAQuCYrc6Hm/CJHA7fi7uFaZxMg9pE+P6Po19sh0plgWmZRHN5G/MNwZDL X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2814 Archived-At: Subject: Re: [Secdispatch] Ciphertext format draft X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 15:06:39 -0000 --_000_2EA9CFF4BB154337ABDF0BEEEF3A6163ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLg0KDQpUaGlzIGhhcyBiZWVuIHBvc3RlZCB0byBTZWNkaXNwYXRjaCwgYW5kIEkgdGhvdWdo dCBDQk9SIGFuZCBDT1NFIG1pZ2h0IHdhbnQgdG8gdGFrZSBhIGxvb2suIChGZWVsIGZyZWUgdG8g cmVwbHkgdG8gdGhlIG9yaWdpbmFsIHRocmVhZCBpbiBTZWNkaXNwYXRjaCwgdG8ga2VlcCB0aGUg Y29udmVyc2F0aW9uIGluIG9uZSBwbGFjZSkuDQoNCkZyYW5jZXNjYQ0KDQpGcm9tOiBTZWNkaXNw YXRjaCA8c2VjZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFlhcm9uIFNo ZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IEZyaWRheSwgMTUgSmFudWFyeSAy MDIxIGF0IDE1OjU0DQpUbzogInNlY2Rpc3BhdGNoQGlldGYub3JnIiA8c2VjZGlzcGF0Y2hAaWV0 Zi5vcmc+DQpDYzogIktlc2VsbWFuLCBHbGViIiA8R2xlYl9LZXNlbG1hbkBpbnR1aXQuY29tPiwg WW9hdiBOaXIgPHluaXIuaWV0ZkBnbWFpbC5jb20+DQpTdWJqZWN0OiBbU2VjZGlzcGF0Y2hdIENp cGhlcnRleHQgZm9ybWF0IGRyYWZ0DQoNCkhpLCB3ZSBqdXN0IHN1Ym1pdHRlZCBkcmFmdC1zaGVm ZmVyLWlldGYtY2lwaGVydGV4dC1mb3JtYXQtMDEgWzFdLiBUaGlzIGlzIGEgQ0JPUi1iYXNlZCBz ZXQgb2YgaGVhZGVycyBmb3IgZW5jcnlwdGVkIGRhdGEsIHdpdGggdGhlIGdvYWwgb2YgZW5hYmxp bmcgYXV0b21hdGlvbiBvZiBsYXJnZSBkYXRhc2V0cyB0aGF0IGNvbnRhaW4gZW5jcnlwdGVkIGRh dGEsIHR5cGljYWxseSBpbnRlcnNwZXJzZWQgd2l0aCBwbGFpbiBkYXRhLiBTcGVjaWZpY2FsbHkg d2Ugd2FudCB0byBmYWNpbGl0YXRlIGRpc2NvdmVyeSBvZiBlbmNyeXB0ZWQgZGF0YSAoZS5nLiwg dGhpcyBkYXRhYmFzZSBjb2x1bW4gY29udGFpbnMgY2lwaGVydGV4dCkgYW5kIGF0dHJpYnV0aW5n IHRoaXMgZGF0YSBiYWNrIHRvIHRoZSBzZXJ2aWNlIHRoYXQgY3JlYXRlZCB0aGUgZGF0YSBhbmQg dGhlIGtleSB0aGF0IHdhcyB1c2VkIHRvIGVuY3J5cHQgaXQuDQoNCldlIHJlY2VpdmVkIGdvb2Qg ZmVlZGJhY2sgb24gdGhlIFNBQUcgbGlzdCB0byBjaGFuZ2UgZnJvbSBnZW5lcmljIFRMViB0byBD Qk9SLCB3aGljaCB3ZSBpbXBsZW1lbnRlZCBpbiAtMDEuDQoNClRoZSBhdXRob3JzIHdvdWxkIGFw cHJlY2lhdGUgdGhpcyBsaXN04oCZcyBmZWVkYmFjayByZWdhcmRpbmcgbmV4dCBzdGVwcy4NCg0K VGhhbmtzLA0KICAgICAgICAgICAgICAgIFlhcm9uDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LXNoZWZmZXItaWV0Zi1jaXBoZXJ0ZXh0LWZvcm1hdC0wMS54bWwNCg0K --_000_2EA9CFF4BB154337ABDF0BEEEF3A6163ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <054C838CA68A0D4FA6A8BC1221C2E56E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9 InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+RllJLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhpcyBoYXMgYmVlbiBwb3N0ZWQgdG8gU2VjZGlzcGF0Y2gs IGFuZCBJIHRob3VnaHQgQ0JPUiBhbmQgQ09TRSBtaWdodCB3YW50IHRvIHRha2UgYSBsb29rLiAo RmVlbCBmcmVlIHRvIHJlcGx5IHRvIHRoZSBvcmlnaW5hbCB0aHJlYWQgaW4gU2VjZGlzcGF0Y2gs IHRvIGtlZXAgdGhlIGNvbnZlcnNhdGlvbiBpbg0KIG9uZSBwbGFjZSkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5GcmFuY2VzY2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNlY2Rpc3BhdGNoICZsdDtzZWNkaXNwYXRj aC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgWWFyb24gU2hlZmZlciAmbHQ7eWFy b25mLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIDE1IEphbnVh cnkgMjAyMSBhdCAxNTo1NDxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7c2VjZGlzcGF0Y2hAaWV0Zi5v cmcmcXVvdDsgJmx0O3NlY2Rpc3BhdGNoQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1 b3Q7S2VzZWxtYW4sIEdsZWImcXVvdDsgJmx0O0dsZWJfS2VzZWxtYW5AaW50dWl0LmNvbSZndDss IFlvYXYgTmlyICZsdDt5bmlyLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5bU2VjZGlzcGF0Y2hdIENpcGhlcnRleHQgZm9ybWF0IGRyYWZ0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpLCB3ZSBqdXN0 IHN1Ym1pdHRlZCBkcmFmdC1zaGVmZmVyLWlldGYtY2lwaGVydGV4dC1mb3JtYXQtMDEgWzFdLiBU aGlzIGlzIGEgQ0JPUi1iYXNlZCBzZXQgb2YgaGVhZGVycyBmb3IgZW5jcnlwdGVkIGRhdGEsIHdp dGggdGhlIGdvYWwgb2YgZW5hYmxpbmcgYXV0b21hdGlvbiBvZiBsYXJnZSBkYXRhc2V0cw0KIHRo YXQgY29udGFpbiBlbmNyeXB0ZWQgZGF0YSwgdHlwaWNhbGx5IGludGVyc3BlcnNlZCB3aXRoIHBs YWluIGRhdGEuIFNwZWNpZmljYWxseSB3ZSB3YW50IHRvIGZhY2lsaXRhdGUgZGlzY292ZXJ5IG9m IGVuY3J5cHRlZCBkYXRhIChlLmcuLCB0aGlzIGRhdGFiYXNlIGNvbHVtbiBjb250YWlucyBjaXBo ZXJ0ZXh0KSBhbmQgYXR0cmlidXRpbmcgdGhpcyBkYXRhIGJhY2sgdG8gdGhlIHNlcnZpY2UgdGhh dCBjcmVhdGVkIHRoZSBkYXRhIGFuZCB0aGUNCiBrZXkgdGhhdCB3YXMgdXNlZCB0byBlbmNyeXB0 IGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+V2UgcmVjZWl2ZWQg Z29vZCBmZWVkYmFjayBvbiB0aGUgU0FBRyBsaXN0IHRvIGNoYW5nZSBmcm9tIGdlbmVyaWMgVExW IHRvIENCT1IsIHdoaWNoIHdlIGltcGxlbWVudGVkIGluIC0wMS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBhdXRob3JzIHdvdWxkIGFwcHJlY2lhdGUgdGhpcyBs aXN04oCZcyBmZWVkYmFjayByZWdhcmRpbmcgbmV4dCBzdGVwcy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlhcm9u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bMV0NCjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtc2hlZmZlci1pZXRmLWNpcGhlcnRleHQtZm9y bWF0LTAxLnhtbCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1zaGVmZmVyLWlldGYt Y2lwaGVydGV4dC1mb3JtYXQtMDEueG1sPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2EA9CFF4BB154337ABDF0BEEEF3A6163ericssoncom_-- From nobody Fri Jan 15 07:10:04 2021 Return-Path: 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 4A8E83A0AC4; Fri, 15 Jan 2021 07:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 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, 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 0rW1-bD2Cgyh; Fri, 15 Jan 2021 07:09:50 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 505133A0ABE; Fri, 15 Jan 2021 07:09:50 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id c5so9608162wrp.6; Fri, 15 Jan 2021 07:09:50 -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=D96ZdDSHN1bJyemhvRtHR+dsqteYHktRD3V5FSEMnro=; b=WXCvoi9r6ogHjIymNkeOguZ/R7hf+X3EFKQwWCtdPPDNxKyKLOn5AG6vWBDBUtIO+K No2XHt4g0Eu4SOAJv4bEY2MWmvltXhF+lFc1e5hUiRSQOr9S1La2DLpqE1VhhUIEafDe DyLiFPlnJrxbO5fixWc2ofBS2P2xu6zJoSPYiwmd+eQX0otXODtm8EjdGUtudCpDBi8/ mf/s664ZwSPuJlHx2uA88drKG9CXC0opX5IUx0APTS2UWdnQcJCT0ApfHAgkobiJBmgX 5iJ3yDFDOOgHTHr/6PoH0otGJCe9zSwTVWKY7oXs7y/7eJkBjV22B0jmgjZdZeaQFyLn +oOg== 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=D96ZdDSHN1bJyemhvRtHR+dsqteYHktRD3V5FSEMnro=; b=l2ecLTYuW7G3F/xO8vmuF6b/dDwd6k8gLWj1JXAMJCyRAEKFQcSgTs6LnyMnvbwc5L pn/7Ki3xtnrf/RfltH6AeL3llReDk8M7uC8JFGKVlnLyEO2IR37tDpLAxlwUe5W396oo cEv2ck25G6dwZ11yW9BAKObq89E6AZv82aNQe59PNXtYbzvb/WZMwdSSEAM9QRaFrU8X 5Ora3vQGbF6yh/KuLgqivGa5qDqnO3n11ASSTJX5JseYRHKaRf9BugwgrDXqbppMz0Dt qpvsaMIlZ2Cx2GYSo0vYq3o5ulET8mHboC73quSRzSnGR60xJNHOLtNm3a1osbXTZGS1 EMmA== X-Gm-Message-State: AOAM533WSi7KzdmydvJP9hq++JlCTzXHeCyV1qGclBD+UlnMTHwo9wir pgm3VzzFHm4YmDkaefoGTqA= X-Google-Smtp-Source: ABdhPJy2hXN2SRT0BDSxTS/zvxHl/TBlMlWybb05VEXbbbjGAxiO5uD8c/hZRb4cLDekeYcJkdUDMQ== X-Received: by 2002:adf:e74a:: with SMTP id c10mr13844767wrn.122.1610723388846; Fri, 15 Jan 2021 07:09:48 -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 r13sm14945610wrt.10.2021.01.15.07.09.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jan 2021 07:09:48 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.45.21011103 Date: Fri, 15 Jan 2021 17:09:46 +0200 From: Yaron Sheffer To: Francesca Palombini , "cbor@ietf.org" , Cose Wg CC: "Keselman, Gleb" , Yoav Nir , "secdispatch@ietf.org" Message-ID: Thread-Topic: [Secdispatch] Ciphertext format draft References: <2EA9CFF4-BB15-4337-ABDF-0BEEEF3A6163@ericsson.com> In-Reply-To: <2EA9CFF4-BB15-4337-ABDF-0BEEEF3A6163@ericsson.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3693575388_459445110" Archived-At: Subject: Re: [Secdispatch] Ciphertext format draft X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 15:09:52 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3693575388_459445110 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable We would love feedback from the CBOR community, but to clarify: we are mere= ly using CBOR in the simplest way possible, we are not proposing any changes= to it. =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Francesca Palombini Date: Friday, January 15, 2021 at 17:06 To: "cbor@ietf.org" , Cose Wg Cc: "Keselman, Gleb" , Yoav Nir , Yaron Sheffer , "secdispatch@ietf.org" Subject: Re: [Secdispatch] Ciphertext format draft =20 FYI. =20 This has been posted to Secdispatch, and I thought CBOR and COSE might want= to take a look. (Feel free to reply to the original thread in Secdispatch, = to keep the conversation in one place). =20 Francesca =20 From: Secdispatch on behalf of Yaron Sheffer= Date: Friday, 15 January 2021 at 15:54 To: "secdispatch@ietf.org" Cc: "Keselman, Gleb" , Yoav Nir Subject: [Secdispatch] Ciphertext format draft =20 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 au= tomation of large datasets that contain encrypted data, typically interspers= ed with plain data. Specifically we want to facilitate discovery of encrypte= d 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. =20 We received good feedback on the SAAG list to change from generic TLV to CB= OR, which we implemented in -01. =20 The authors would appreciate this list=E2=80=99s feedback regarding next steps. =20 Thanks, Yaron =20 [1] https://tools.ietf.org/id/draft-sheffer-ietf-ciphertext-format-01.xml =20 --B_3693575388_459445110 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

We would love feedback from the CBOR community, but to clarif= y: we are merely using CBOR in the simplest way possible, we are not proposi= ng any changes to it.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 <= /p>

From: Francesca Palombini <francesca.palombini@ericsson= .com>
Date: Friday, January 15, 2021 at 17:06
To: &qu= ot;cbor@ietf.org" <cbor@ietf.org>, Cose Wg <cose@ietf.org><= br>Cc: "Keselman, Gleb" <Gleb_Keselman@intuit.com>, Y= oav Nir <ynir.ietf@gmail.com>, Yaron Sheffer <yaronf.ietf@gmail.com= >, "secdispatch@ietf.org" <secdispatch@ietf.org>
Su= bject: Re: [Secdispatch] Ciphertext format draft

 =

FYI.

 

This ha= s been posted to Secdispatch, and I thought CBOR and COSE might want to take= a look. (Feel free to reply to the original thread in Secdispatch, to keep = the conversation in one place).

 

Francesca

 

From: Secdispatch <secdispatch-bounces@ietf.org= > on behalf of Yaron Sheffer <yaronf.ietf@gmail.com>
Date: Friday, 15 January 2021 at 15:54
To: "secdispatch@ietf.org&= quot; <secdispatch@ietf.org>
Cc: "Keselman, Gleb" = <Gleb_Keselman@intuit.com>, Yoav Nir <ynir.ietf@gmail.com>
Subject: [Secdispatch] Ciphertext format draft

 

Hi, we just submitted draft-sheffer-= ietf-ciphertext-format-01 [1]. This is a CBOR-based set of headers for encry= pted data, with the goal of enabling automation of large datasets that conta= in encrypted data, typically interspersed with plain data. Specifically we w= ant to facilitate discovery of encrypted data (e.g., this database column co= ntains ciphertext) and attributing this data back to the service that create= d the data and the key that was used to encrypt it.

&nbs= p;

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

=

&= nbsp;

The authors would appreciate this list=E2=80=99s feedbac= k regarding next steps.

 

Thank= s,

         = ;       Yaron

 

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

 

--B_3693575388_459445110-- From nobody Fri Jan 15 07:28:58 2021 Return-Path: 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 48C673A0B17; Fri, 15 Jan 2021 07:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 PoXoNdZ-OVjL; Fri, 15 Jan 2021 07:28:49 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BACE3A0B12; Fri, 15 Jan 2021 07:28:46 -0800 (PST) Received: from [192.168.217.118] (p548dc939.dip0.t-ipconnect.de [84.141.201.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DHQ7c4HS1z1057; Fri, 15 Jan 2021 16:28:44 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Fri, 15 Jan 2021 16:28:44 +0100 Cc: Francesca Palombini , "cbor@ietf.org" , Cose Wg , "secdispatch@ietf.org" , "Keselman, Gleb" , Yoav Nir X-Mao-Original-Outgoing-Id: 632417324.134828-f610ff8ad399fc9f990d00f68eea93cc Content-Transfer-Encoding: quoted-printable Message-Id: <92C2FB28-1F0A-43E6-9D17-9609400C0A7E@tzi.org> References: <2EA9CFF4-BB15-4337-ABDF-0BEEEF3A6163@ericsson.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Secdispatch] [Cbor] Ciphertext format draft X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 15:28:51 -0000 Hi Yaron, Here is a quick update proposal to the CDDL: var_header =3D { K_KEY_PROVIDER =3D> uint, K_KEY_ID =3D> bstr, ? K_KEY_VERSION =3D> uint, ? K_AUX_DATA =3D> bstr, ? K_NONCE =3D> bstr, ? K_AUTH_TAG =3D> bstr, ? K_AAD =3D> bstr, * (k_ext .feature "header-extension") =3D> any } k_ext =3D uint .ge K__EXTENSIONS ; K_RESERVED =3D 0 K_KEY_PROVIDER =3D 1 K_KEY_ID =3D 2 K_KEY_VERSION =3D 3 K_AUX_DATA =3D 4 K_NONCE =3D 5 K_AUTH_TAG =3D 6 K_AAD =3D 7 ; extend from here K__EXTENSIONS =3D 8 The idea is to use =E2=80=9C.feature=E2=80=9D to clearly identify = extensions from the base set. This would give you validator output like ** Features potentially used: header-extension: [1577, 4416, 3178, 2698] /var_header/ {1: 2286, 2: /bstr/ h'686F74626564', 3: 4661, 5: /bstr/ h'756E70726F70656E7365', 6: /bstr/ h'6F7879616E746872617175696E6F6E65', 7: /bstr/ h'636572656272616C6C79', 1577: /any/ "feeze", 4416: /any/ "bronchiolitis", 3178: /any/ "mesole", 2698: /any/ = "parvoline=E2=80=9D} so you know which extensions are in use. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jan 15 08:37:27 2021 Return-Path: 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 161EE3A0CFA for ; Fri, 15 Jan 2021 08:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 APEKfIdS4mgS for ; Fri, 15 Jan 2021 08:37:24 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5283A0CF9 for ; Fri, 15 Jan 2021 08:37:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4344D300BAA for ; Fri, 15 Jan 2021 11:37:21 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Zlv2KH-JPp4a for ; Fri, 15 Jan 2021 11:37:19 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id D28673005D5; Fri, 15 Jan 2021 11:37:18 -0500 (EST) From: Russ Housley Message-Id: <523854C0-3D2B-4565-A6FF-8DF46EBD88A2@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1B7DF693-60CB-441C-BD73-75B0E0A09DE3" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 15 Jan 2021 11:37:20 -0500 In-Reply-To: <8B46C11A-790A-4E8E-A7A1-8FE97E2DD9A7@contoso.com> Cc: IETF SecDispatch , "Keselman, Gleb" , Yoav Nir To: Yaron Sheffer References: <8B46C11A-790A-4E8E-A7A1-8FE97E2DD9A7@contoso.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Secdispatch] Ciphertext format draft X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 16:37:26 -0000 --Apple-Mail=_1B7DF693-60CB-441C-BD73-75B0E0A09DE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yaron: How do you see AAD being used?=20 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 = wrote: >=20 > 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. > =20 > We received good feedback on the SAAG list to change from generic TLV = to CBOR, which we implemented in -01. > =20 > The authors would appreciate this list=E2=80=99s feedback regarding = next steps. > =20 > Thanks, > Yaron > =20 > [1] = https://tools.ietf.org/id/draft-sheffer-ietf-ciphertext-format-01.xml = > =20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch = --Apple-Mail=_1B7DF693-60CB-441C-BD73-75B0E0A09DE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99s feedback regarding next steps.
 
Thanks,
          &nb= sp;     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

= --Apple-Mail=_1B7DF693-60CB-441C-BD73-75B0E0A09DE3-- From nobody Fri Jan 15 12:23:09 2021 Return-Path: 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 ; 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 ; 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 ; Fri, 15 Jan 2021 12:23:05 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id q18so10532788wrn.1 for ; 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 To: Russ Housley CC: IETF SecDispatch , "Keselman, Gleb" , Yoav Nir 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: Subject: Re: [Secdispatch] Ciphertext format draft X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 20:23:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3693594183_1796884523 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Russ, =20 I=E2=80=99m not sure what you are asking re: AAD. This is a single octet-string i= nput 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 ca= n be used to bind ciphertext to its context in order to prevent cut-and-past= e attacks. =20 In our main use case, the data is structured with a well defined schema (a.= k.a., SQL database). So =E2=80=9Ccontent type=E2=80=9D doesn=E2=80=99t make sense. This is ear= ly days for the format and people will surely come up with other use cases. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 [1] https://aws.amazon.com/blogs/security/how-to-protect-the-integrity-of-y= our-encrypted-data-by-using-aws-key-management-service-and-encryptioncontext= / =20 From: Russ Housley Date: Friday, January 15, 2021 at 18:37 To: Yaron Sheffer Cc: IETF SecDispatch , "Keselman, Gleb" , Yoav Nir Subject: Re: [Secdispatch] Ciphertext format draft =20 Yaron: =20 How do you see AAD being used?=20 =20 Also, CMS carries a field that tells how to parse the plaintext (the conten= t type) after it obtained by decryption. I cannot tell whether that is usef= ul or in you use case, but I can imagine places where it would be very helpf= ul. =20 Russ On Jan 15, 2021, at 9:53 AM, Yaron Sheffer wrote: =20 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 au= tomation of large datasets that contain encrypted data, typically interspers= ed with plain data. Specifically we want to facilitate discovery of encrypte= d 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. =20 We received good feedback on the SAAG list to change from generic TLV to CB= OR, which we implemented in -01. =20 The authors would appreciate this list=E2=80=99s feedback regarding next steps. =20 Thanks, Yaron =20 [1] https://tools.ietf.org/id/draft-sheffer-ietf-ciphertext-format-01.xml =20 _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch =20 --B_3693594183_1796884523 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Russ,

 

I=E2=80=99m 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 th= eir KMS SDK, and published [1] a nice blog showing how it can be used to bin= d ciphertext to its context in order to prevent cut-and-paste attacks.<= /o:p>

 

In our m= ain use case, the data is structured with a well defined schema (a.k.a., SQL= database). So =E2=80=9Ccontent type=E2=80=9D doesn=E2=80=99t make sense. This is early days f= or the format and people will surely come up with other use cases.

 

Thanks,=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron=

 

[1] https://a= ws.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: <= /b>Friday, January 15, 2021 at 18:37
To: Yaron Sheffer <yaronf.= ietf@gmail.com>
Cc: IETF SecDispatch <secdispatch@ietf.org&g= t;, "Keselman, Gleb" <Gleb_Keselman@intuit.com>, Yoav Nir &l= t;ynir.ietf@gmail.com>
Subject: Re: [Secdispatch] Ciphertext fo= rmat 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. &nbs= p;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:

 <= /o:p>

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

 

We rece= ived good feedback on the SAAG list to change from generic TLV to CBOR, whic= h we implemented in -01.

 

The authors would appreciate thi= s list=E2=80=99s feedback regarding next steps.

 

Thanks,

&= nbsp;            = ;   Yaron

 

 

____________________________________= ___________
Secdispatch mailing list
Secdispatch@ietf.org
https:= //www.ietf.org/mailman/listinfo/secdispatch

<= /blockquote>

 

--B_3693594183_1796884523-- From nobody Fri Jan 15 13:41:07 2021 Return-Path: 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 ABEBA3A1258 for ; Fri, 15 Jan 2021 13:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 sY0vIrYda6w2 for ; Fri, 15 Jan 2021 13:40:56 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BE43A121F for ; Fri, 15 Jan 2021 13:40:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A56FA300BD1 for ; Fri, 15 Jan 2021 16:40:53 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id j2vGs7Tkd08Z for ; Fri, 15 Jan 2021 16:40:50 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 3C014300AE5; Fri, 15 Jan 2021 16:40:50 -0500 (EST) From: Russ Housley Message-Id: <77529C17-9D2F-46A0-9F80-44227A71C5A0@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F63CE13B-E82E-401C-AACB-0A064053ED7E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 15 Jan 2021 16:40:51 -0500 In-Reply-To: <3C9F29DF-CDA6-48BA-B94E-5CCE63E4AA57@gmail.com> Cc: "Keselman, Gleb" , IETF SecDispatch , Yoav Nir To: Yaron Sheffer References: <8B46C11A-790A-4E8E-A7A1-8FE97E2DD9A7@contoso.com> <523854C0-3D2B-4565-A6FF-8DF46EBD88A2@vigilsec.com> <3C9F29DF-CDA6-48BA-B94E-5CCE63E4AA57@gmail.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Secdispatch] Ciphertext format draft X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 21:41:06 -0000 --Apple-Mail=_F63CE13B-E82E-401C-AACB-0A064053ED7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = wrote: >=20 > Hi Russ, > =20 > I=E2=80=99m 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. > =20 > In our main use case, the data is structured with a well defined = schema (a.k.a., SQL database). So =E2=80=9Ccontent type=E2=80=9D = doesn=E2=80=99t make sense. This is early days for the format and people = will surely come up with other use cases. > =20 > Thanks, > Yaron > =20 > [1] = https://aws.amazon.com/blogs/security/how-to-protect-the-integrity-of-your= -encrypted-data-by-using-aws-key-management-service-and-encryptioncontext/= = > =20 > From: Russ Housley > > Date: Friday, January 15, 2021 at 18:37 > To: Yaron Sheffer > > Cc: IETF SecDispatch >, "Keselman, Gleb" = >, Yoav Nir = > > Subject: Re: [Secdispatch] Ciphertext format draft > =20 > Yaron: > =20 > How do you see AAD being used?=20 > =20 > 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. > =20 > Russ >=20 >=20 >> On Jan 15, 2021, at 9:53 AM, Yaron Sheffer > wrote: >> =20 >> 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. >> =20 >> We received good feedback on the SAAG list to change from generic TLV = to CBOR, which we implemented in -01. >> =20 >> The authors would appreciate this list=E2=80=99s feedback regarding = next steps. >> =20 >> Thanks, >> Yaron >> =20 >> [1] = https://tools.ietf.org/id/draft-sheffer-ietf-ciphertext-format-01.xml = >> =20 >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch = > =20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch = --Apple-Mail=_F63CE13B-E82E-401C-AACB-0A064053ED7E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 <yaronf.ietf@gmail.com> wrote:

Hi Russ,
 
I=E2=80=99m 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 = =E2=80=9Ccontent type=E2=80=9D doesn=E2=80=99t make sense. This is early = days for the format and people will surely come up with other use = cases.
 
Thanks,
          &nb= sp;     Yaron
 
[1] https://aws.amazon.com/blogs/security/how-to-protect-the-integr= ity-of-your-encrypted-data-by-using-aws-key-management-service-and-encrypt= ioncontext/
 
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=E2=80=99s = feedback regarding next steps.
 
Thanks,
          &nb= sp;     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
 
_______________________________________________
Secdispatch mailing = list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch

= --Apple-Mail=_F63CE13B-E82E-401C-AACB-0A064053ED7E-- From nobody Sat Jan 16 14:13:56 2021 Return-Path: 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 A4EAF3A19F1 for ; Sat, 16 Jan 2021 14:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 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, 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 3Z59y91DAuhI for ; Sat, 16 Jan 2021 14:13:52 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 6610E3A11DB for ; Sat, 16 Jan 2021 14:13:52 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id d26so12837951wrb.12 for ; Sat, 16 Jan 2021 14:13:52 -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=BYXdSvctGhv2OzqjG0q3voLzCP5vodI4p5Q4/WMsAUU=; b=s/bKsyEfQhwOtpbmmoHjx8wEK4HT/PJgfifaQ0mn0o3At4ee7vhXqVDkfncpda/hoH jUMdlrZTfO7Q7ll+BldK3yaTm9t/O85q2MIiN8zKzLFoVB9OEcBYWqk1+OtEeVfaiNay QH1SOTDa3CPFTVkfonIwh9S1b7RRZHLpLFND/dtsQ5lpL/DiKZM+oOjTMFKJN7o/VHZF vz2KgFlORwx1zJmy0pBvrBhlnPoC4DYp1treRuym7uj+bc9KQGU70RG6CYIWhF753Thi k36Nd2elNIVf/OpkDovK3kfG6cnRgQjlupvlUoxvx7P8UtNlJoaLjZyucfpXLCFGDoOw tJdw== 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=BYXdSvctGhv2OzqjG0q3voLzCP5vodI4p5Q4/WMsAUU=; b=LMwocWDx9v/leWs5W4l04flFuZ45fP+oM43UZtKmFJdEWXV0tD9IIFw2P2K+SQpHCX O0M5DDE0maoCTFqeaBBdORKriQqzlmfzCC6EajtOZ/yJ2Hz7FurCJWaNS/pRNM9wFAnP tkYqV0bDvVQq0qgjMvlBApmlH4/pi+68o/5+Pm1KFMDz2xpkPRLWNe8d6b6hceBskrg5 jFgcEfdYWJGtKYEKtmiXGMu8e8UxLmisLE1WchtgpxwC2AOciUXfl3IIjeSu1pKESnVr 5Qa+JpbSUcnJ9ZM6TDrSzSM39J5ZtVkMC6Psrc97snBO/NCcS8iID6hIj1m1SCGqSRY0 j6eg== X-Gm-Message-State: AOAM5315snFeq3z0aHpzVOmd2LfKHGrnPOgnXIoRUZFsVhUfGZTTXw0X SpvIOChlAmmxNzmMctFd7V0= X-Google-Smtp-Source: ABdhPJzJeN7HxdHtjs1qLiw0KledYiT7+A4BTWIRNRy/fcorWIm7f2XCGbGnYslZG6oPBQTblnRHQw== X-Received: by 2002:a5d:4e86:: with SMTP id e6mr19832336wru.33.1610835230965; Sat, 16 Jan 2021 14:13:50 -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 h13sm19950115wrm.28.2021.01.16.14.13.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Jan 2021 14:13:50 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.45.21011103 Date: Sun, 17 Jan 2021 00:13:48 +0200 From: Yaron Sheffer To: Russ Housley CC: "Keselman, Gleb" , IETF SecDispatch , Yoav Nir Message-ID: Thread-Topic: [Secdispatch] Ciphertext format draft References: <8B46C11A-790A-4E8E-A7A1-8FE97E2DD9A7@contoso.com> <523854C0-3D2B-4565-A6FF-8DF46EBD88A2@vigilsec.com> <3C9F29DF-CDA6-48BA-B94E-5CCE63E4AA57@gmail.com> <77529C17-9D2F-46A0-9F80-44227A71C5A0@vigilsec.com> In-Reply-To: <77529C17-9D2F-46A0-9F80-44227A71C5A0@vigilsec.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3693687229_1616701968" Archived-At: Subject: Re: [Secdispatch] Ciphertext format draft X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2021 22:13:55 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3693687229_1616701968 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Russ, =20 In the example in the document, the database primary key (e.g. customer=E2=80=99s= 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 ha= s no access to keys) from moving encrypted fields from one customer to anoth= er. Decryption of such moved fields would fail. =20 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. =20 Quoting the blog: =E2=80=9CEncryptionContext should include all of the informatio= n 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 iden= tify the location of the ciphertext (for example, a URI, file path, or datab= ase table and primary keys).=E2=80=9D =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Russ Housley Date: Friday, January 15, 2021 at 23:40 To: Yaron Sheffer Cc: "Keselman, Gleb" , IETF SecDispatch , Yoav Nir Subject: Re: [Secdispatch] Ciphertext format draft =20 Yaron: =20 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 i= s it used in this database context? =20 Russ On Jan 15, 2021, at 3:23 PM, Yaron Sheffer wrote: =20 Hi Russ, =20 I=E2=80=99m not sure what you are asking re: AAD. This is a single octet-string i= nput 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 ca= n be used to bind ciphertext to its context in order to prevent cut-and-past= e attacks. =20 In our main use case, the data is structured with a well defined schema (a.= k.a., SQL database). So =E2=80=9Ccontent type=E2=80=9D doesn=E2=80=99t make sense. This is ear= ly days for the format and people will surely come up with other use cases. =20 Thanks, Yaron =20 [1] https://aws.amazon.com/blogs/security/how-to-protect-the-integrity-of-y= our-encrypted-data-by-using-aws-key-management-service-and-encryptioncontext= / =20 From: Russ Housley Date: Friday, January 15, 2021 at 18:37 To: Yaron Sheffer Cc: IETF SecDispatch , "Keselman, Gleb" , Yoav Nir Subject: Re: [Secdispatch] Ciphertext format draft =20 Yaron: =20 How do you see AAD being used?=20 =20 Also, CMS carries a field that tells how to parse the plaintext (the conten= t type) after it obtained by decryption. I cannot tell whether that is usef= ul or in you use case, but I can imagine places where it would be very helpf= ul. =20 Russ On Jan 15, 2021, at 9:53 AM, Yaron Sheffer wrote: =20 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 au= tomation of large datasets that contain encrypted data, typically interspers= ed with plain data. Specifically we want to facilitate discovery of encrypte= d 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. =20 We received good feedback on the SAAG list to change from generic TLV to CB= OR, which we implemented in -01. =20 The authors would appreciate this list=E2=80=99s feedback regarding next steps. =20 Thanks, Yaron =20 [1] https://tools.ietf.org/id/draft-sheffer-ietf-ciphertext-format-01.xml =20 _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch =20 _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch =20 --B_3693687229_1616701968 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Russ,

 

In the example = in the document, the database primary key (e.g. customer=E2=80=99s 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 k= eys) from moving encrypted fields from one customer to another. Decryption o= f such moved fields would fail.

 =

Note that in this use case, the AAD does NOT ne= ed to be stored explicitly, because it is a duplicate of data in other (plai= ntext) fields.

 

Quoting the blog: =E2=80=9CEncryptionContext should include all of the= information associated with the ciphertext that you will later need to inte= rpret it. A good rule is to always include at least enough information to un= iquely identify the location of the ciphertext (for example, a URI, file pat= h, or database table and primary keys).=E2=80=9D

=  

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

<= o:p> 

From: R= uss Housley <housley@vigilsec.com>
Date: Friday, January 15,= 2021 at 23:40
To: Yaron Sheffer <yaronf.ietf@gmail.com>
= Cc: "Keselman, Gleb" <Gleb_Keselman@intuit.com>, IETF= SecDispatch <secdispatch@ietf.org>, Yoav Nir <ynir.ietf@gmail.com&= gt;
Subject: Re: [Secdispatch] Ciphertext format draft<= /span>

 

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 us= ed in packet protocols.  But how is it used in this database context?

 

<= p class=3DMsoNormal>Russ



On Jan 15, 2021, at 3:23 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

 

Hi = Russ,

 

I=E2=80=99m 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 w= ell as RFC 5116). Or did you mean: what is the use case for AAD when encrypt= ing data at rest? Amazon uses AEAD in their KMS SDK, and published [1] a nic= e 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= =E2=80=9Ccontent type=E2=80=9D doesn=E2=80=99t make sense. This is early days for the format = and people will surely come up with other use cases.

 

Than= ks,

    &nbs= p;           Yaron

 

 

=

From: Russ = Housley <housley@vigilsec.com&g= t;
Date: Friday, Jan= uary 15, 2021 at 18:37
To: Yaron Sheffer <yaronf.ietf@= gmail.com>
Cc: IETF SecDispatch <secdispatch@iet= f.org>, "Keselman, Gleb" <Gleb_Keselman@intuit.com>, Yoav Nir <ynir.ietf@gmail.com>
Subject: Re: [Secdispatch] Ciphertext format dra= ft

 =

Yaron:

 

How do you see AAD being used? 

<= div>

 

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

 

Russ




On Jan 15, 2021, at 9:53 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

<= /div>

 

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 o= f enabling automation of large datasets that contain encrypted data, typical= ly interspersed with plain data. Specifically we want to facilitate discover= y of encrypted data (e.g., this database column contains ciphertext) and att= ributing this data back to the service that created the data and the key tha= t was used to encrypt it.

 

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

 

The authors = would appreciate this list=E2=80=99s feedback regarding next steps.

=

 

Thanks,

          &n= bsp;     Yaron

 

 

_______________= ________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch<= o:p>

 <= o:p>

_______________________________________________
Secd= ispatch mailing list
Secdispatch@ietf.org=
https://www.ietf.org/mailman/listinfo/secdispatch

 = ;

--B_3693687229_1616701968-- From nobody Sun Jan 17 08:10:15 2021 Return-Path: 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 23E623A120B for ; Sun, 17 Jan 2021 08:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7koPMsDF61u2 for ; Sun, 17 Jan 2021 08:10:11 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A833A1209 for ; Sun, 17 Jan 2021 08:10:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CED8B300B7F for ; Sun, 17 Jan 2021 11:10:08 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cpphlu4vVc3V for ; Sun, 17 Jan 2021 11:10:04 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 5D819300231; Sun, 17 Jan 2021 11:10:04 -0500 (EST) From: Russ Housley Message-Id: <1721133D-89C3-435D-9B0D-BA362A4B1242@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E8AEA1A1-2646-4B6E-888D-7145C6797AA4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Sun, 17 Jan 2021 11:10:05 -0500 In-Reply-To: Cc: "Keselman, Gleb" , Yoav Nir , IETF SecDispatch To: Yaron Sheffer References: <8B46C11A-790A-4E8E-A7A1-8FE97E2DD9A7@contoso.com> <523854C0-3D2B-4565-A6FF-8DF46EBD88A2@vigilsec.com> <3C9F29DF-CDA6-48BA-B94E-5CCE63E4AA57@gmail.com> <77529C17-9D2F-46A0-9F80-44227A71C5A0@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Secdispatch] Ciphertext format draft X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 16:10:14 -0000 --Apple-Mail=_E8AEA1A1-2646-4B6E-888D-7145C6797AA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = wrote: >=20 > Hi Russ, > =20 > In the example in the document, the database primary key (e.g. = customer=E2=80=99s 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. > =20 > 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. > =20 > Quoting the blog: =E2=80=9CEncryptionContext 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).=E2=80=9D > =20 > Thanks, > Yaron > =20 > From: Russ Housley > > Date: Friday, January 15, 2021 at 23:40 > To: Yaron Sheffer > > Cc: "Keselman, Gleb" >, IETF SecDispatch = >, Yoav Nir = > > Subject: Re: [Secdispatch] Ciphertext format draft > =20 > Yaron: > =20 > 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? > =20 > Russ >=20 >=20 >> On Jan 15, 2021, at 3:23 PM, Yaron Sheffer > wrote: >> =20 >> Hi Russ, >> =20 >> I=E2=80=99m 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. >> =20 >> In our main use case, the data is structured with a well defined = schema (a.k.a., SQL database). So =E2=80=9Ccontent type=E2=80=9D = doesn=E2=80=99t make sense. This is early days for the format and people = will surely come up with other use cases. >> =20 >> Thanks, >> Yaron >> =20 >> [1] = https://aws.amazon.com/blogs/security/how-to-protect-the-integrity-of-your= -encrypted-data-by-using-aws-key-management-service-and-encryptioncontext/= = >> =20 >> From: Russ Housley > >> Date: Friday, January 15, 2021 at 18:37 >> To: Yaron Sheffer > >> Cc: IETF SecDispatch >, "Keselman, Gleb" = >, Yoav Nir = > >> Subject: Re: [Secdispatch] Ciphertext format draft >> =20 >> Yaron: >> =20 >> How do you see AAD being used?=20 >> =20 >> 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. >> =20 >> Russ >>=20 >>=20 >>=20 >>> On Jan 15, 2021, at 9:53 AM, Yaron Sheffer > wrote: >>> =20 >>> 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. >>> =20 >>> We received good feedback on the SAAG list to change from generic = TLV to CBOR, which we implemented in -01. >>> =20 >>> The authors would appreciate this list=E2=80=99s feedback regarding = next steps. >>> =20 >>> Thanks, >>> Yaron >>> =20 >>> [1] = https://tools.ietf.org/id/draft-sheffer-ietf-ciphertext-format-01.xml = >>> =20 >>> _______________________________________________ >>> Secdispatch mailing list >>> Secdispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdispatch = >> =20 >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch = > =20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch = --Apple-Mail=_E8AEA1A1-2646-4B6E-888D-7145C6797AA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 <yaronf.ietf@gmail.com> wrote:

Hi Russ,
 
In the example in the = document, the database primary key (e.g. customer=E2=80=99s 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: = =E2=80=9CEncryptionContext 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).=E2=80=9D
 
Thanks,
          &nb= sp;     Yaron
 
From: Russ Housley <housley@vigilsec.com>
Date: Friday, January 15, = 2021 at 23:40
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: "Keselman, Gleb" <Gleb_Keselman@intuit.com>, = IETF SecDispatch <secdispatch@ietf.org>, Yoav Nir <ynir.ietf@gmail.com>
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 = <yaronf.ietf@gmail.com> = wrote:
 
Hi Russ,
 
I=E2=80=99m= 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 =E2=80=9Ccontent type=E2=80=9D doesn=E2=80=99t = make sense. This is early days for the format and people will surely = come up with other use cases.
 
Thanks,
          &nb= sp;     Yaron
 
[1] https://aws.amazon.com/blogs/security/how-to-protect-the-integr= ity-of-your-encrypted-data-by-using-aws-key-management-service-and-encrypt= ioncontext/
 
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=E2=80=99s = feedback regarding next steps.
 
Thanks,
          &nb= sp;     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
 
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch
 
_______________________________________________
Secdispatch mailing = list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch
= --Apple-Mail=_E8AEA1A1-2646-4B6E-888D-7145C6797AA4-- From nobody Sun Jan 17 08:39:48 2021 Return-Path: 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 99A1F3A127D for ; Sun, 17 Jan 2021 08:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 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_NONE=-0.0001, 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 RRdCl2Xssj3K for ; Sun, 17 Jan 2021 08:39:45 -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 60D6F3A127B for ; Sun, 17 Jan 2021 08:39:45 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id l12so8962616wry.2 for ; Sun, 17 Jan 2021 08:39:45 -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=pVv54TVnSP8lO33a/QZjbkqGl511IxCrM1iZ3EnLExI=; b=blzDoJ3gcauZ+Fo6zIrmrTanoPo00vRLer79hR2wt4MXt01y7HzUcJMxu1aFp0+SCc Sto7Cutx8adopvdkdakh5ZQJeyWBbBqNAAW+8fl3+YzV+R/093NoncW4KJjSG1jbs+OE eSSouLhilRi5DNL0+tD/+9epbRoeusI3VJx+8l9gSbOix+BIrwgyXyR7wmeqGrR2qI4V uuhjoDuvXF0gunrI1ovn7KBrmPE3NWxcItGEejGcbAgd5GhMrDhO8UueUdNOZ9GI+XS4 +aYIH53gJ8smO6Py2fdeyY0N1ip52SHnwb1viOtCr9b3pT5yaE2tK8ABcxijrrgyD+Od RV9A== 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=pVv54TVnSP8lO33a/QZjbkqGl511IxCrM1iZ3EnLExI=; b=BnEBc/E8jSnqmo6lI/maVecUo8fuK6HDmikLuRRtSzVC+njEu6jzt4dbpFY+6jMe+b AGD3uEDwUafo47qsPS+keiXBmSYdMeV4/mzT6/t9r+gvT8EV9FZhD9JaIyO3uzpsQmKa TRHLGjvHgQLAT7f0P46Rgobp03NbOuFA/RVOWSL201hLKrhvqbx1d+Xo9QWu5QpcjBcl Xzj4Uud4qHx5aLv8iKetqo3D+wN6hzU1ndMkrPhZDUi/iy8Oaj4jHcywPZasZl6cl1td j5R7HIP7RctKYMZimbdz7E0t8OpxFGldOTaiS4AKvTgJ9cJe1ETo20I56ZwqH+YEMhUw 5emg== X-Gm-Message-State: AOAM533hWh98AiEYhOwiFZa4uEPCLdsOe0t5mTFgSndWYjHYCRcwltDU ferOj0yQjTAKyrc6xFM2WAk= X-Google-Smtp-Source: ABdhPJwigdhr+QkB8o3U/y0nY74k0xMkAfjXiAS/OXsV6uhVLwEIVaOhAO41hL+qnoanos6nQocX9g== X-Received: by 2002:a5d:4f82:: with SMTP id d2mr22040453wru.87.1610901583483; Sun, 17 Jan 2021 08:39:43 -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 r10sm5451856wmd.15.2021.01.17.08.39.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Jan 2021 08:39:42 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.45.21011103 Date: Sun, 17 Jan 2021 18:39:41 +0200 From: Yaron Sheffer To: Russ Housley CC: "Keselman, Gleb" , Yoav Nir , IETF SecDispatch Message-ID: <3CFBC5E4-1261-4635-931B-BB090E8AB881@gmail.com> Thread-Topic: [Secdispatch] Ciphertext format draft References: <8B46C11A-790A-4E8E-A7A1-8FE97E2DD9A7@contoso.com> <523854C0-3D2B-4565-A6FF-8DF46EBD88A2@vigilsec.com> <3C9F29DF-CDA6-48BA-B94E-5CCE63E4AA57@gmail.com> <77529C17-9D2F-46A0-9F80-44227A71C5A0@vigilsec.com> <1721133D-89C3-435D-9B0D-BA362A4B1242@vigilsec.com> In-Reply-To: <1721133D-89C3-435D-9B0D-BA362A4B1242@vigilsec.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3693753582_497584094" Archived-At: Subject: Re: [Secdispatch] Ciphertext format draft X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 16:39:48 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3693753582_497584094 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Russ, =20 NIST 800-38D speaks of a single AAD input, not multiple. Thus we have a sin= gle AAD field in the format. An application can obviously concatenate multip= le inputs into this field, and we could add instructions how to do it secure= ly. Would that address your comment? =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Russ Housley Date: Sunday, January 17, 2021 at 18:10 To: Yaron Sheffer Cc: "Keselman, Gleb" , Yoav Nir , IETF SecDispatch Subject: Re: [Secdispatch] Ciphertext format draft =20 Yaron: =20 Binding the plaintext fields to the ciphertext ones is important, but it re= quires knowledge such as the ordering that is not expressed in the format. = That would be useful. =20 Russ On Jan 16, 2021, at 5:13 PM, Yaron Sheffer wrote: =20 Hi Russ, =20 In the example in the document, the database primary key (e.g. customer=E2=80=99s= 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 ha= s no access to keys) from moving encrypted fields from one customer to anoth= er. Decryption of such moved fields would fail. =20 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. =20 Quoting the blog: =E2=80=9CEncryptionContext should include all of the informatio= n 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 iden= tify the location of the ciphertext (for example, a URI, file path, or datab= ase table and primary keys).=E2=80=9D =20 Thanks, Yaron =20 From: Russ Housley Date: Friday, January 15, 2021 at 23:40 To: Yaron Sheffer Cc: "Keselman, Gleb" , IETF SecDispatch , Yoav Nir Subject: Re: [Secdispatch] Ciphertext format draft =20 Yaron: =20 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 i= s it used in this database context? =20 Russ On Jan 15, 2021, at 3:23 PM, Yaron Sheffer wrote: =20 Hi Russ, =20 I=E2=80=99m not sure what you are asking re: AAD. This is a single octet-string i= nput 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 ca= n be used to bind ciphertext to its context in order to prevent cut-and-past= e attacks. =20 In our main use case, the data is structured with a well defined schema (a.= k.a., SQL database). So =E2=80=9Ccontent type=E2=80=9D doesn=E2=80=99t make sense. This is ear= ly days for the format and people will surely come up with other use cases. =20 Thanks, Yaron =20 [1] https://aws.amazon.com/blogs/security/how-to-protect-the-integrity-of-y= our-encrypted-data-by-using-aws-key-management-service-and-encryptioncontext= / =20 From: Russ Housley Date: Friday, January 15, 2021 at 18:37 To: Yaron Sheffer Cc: IETF SecDispatch , "Keselman, Gleb" , Yoav Nir Subject: Re: [Secdispatch] Ciphertext format draft =20 Yaron: =20 How do you see AAD being used?=20 =20 Also, CMS carries a field that tells how to parse the plaintext (the conten= t type) after it obtained by decryption. I cannot tell whether that is usef= ul or in you use case, but I can imagine places where it would be very helpf= ul. =20 Russ On Jan 15, 2021, at 9:53 AM, Yaron Sheffer wrote: =20 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 au= tomation of large datasets that contain encrypted data, typically interspers= ed with plain data. Specifically we want to facilitate discovery of encrypte= d 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. =20 We received good feedback on the SAAG list to change from generic TLV to CB= OR, which we implemented in -01. =20 The authors would appreciate this list=E2=80=99s feedback regarding next steps. =20 Thanks, Yaron =20 [1] https://tools.ietf.org/id/draft-sheffer-ietf-ciphertext-format-01.xml =20 _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch =20 _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch =20 _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch =20 --B_3693753582_497584094 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Russ,

 

NIST 800-38D sp= eaks 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 t= his field, and we could add instructions how to do it securely. Would that a= ddress your comment?

 

<= p class=3DMsoNormal>Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: <= /span>Russ Housley <housle= y@vigilsec.com>
Date: Sunday, January 17, 2021 at 18:10
T= o: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: "Kesel= man, Gleb" <Gleb_Keselman@intuit.com>, Yoav Nir <ynir.ietf@gma= il.com>, IETF SecDispatch <secdispatch@ietf.org>
Subject: Re: [Secdispatch] Ciphertext format draft

<= p class=3DMsoNormal> 

Yaron:<= /o:p>

 

Binding the plaintext fields to the ciphertext ones is important, bu= t it requires knowledge such as the ordering that is not expressed in the fo= rmat.  That would be useful.

 

Russ



On Jan 16, 2021, at 5:13 PM, Yaron= Sheffer <yaronf.ietf@gmail.com> wrote:

 

Hi Russ,

 

In the example in the = document, the database primary key (e.g. customer=E2=80=99s email address) is incl= uded as AAD for all the fields that are encrypted for that customer. This pr= event an attacker who can modify the database (but has no access to keys) fr= om moving encrypted fields from one customer to another. Decryption of such = moved fields would fail.

 <= o:p>

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.

&n= bsp;

Quoting the blog: =E2=80=9CEncryp= tionContext should include all of the information associated with the cipher= text that you will later need to interpret it. A good rule is to always incl= ude at least enough information to uniquely identify the location of the cip= hertext (for example, a URI, file path, or database table and primary keys).= =E2=80=9D

 

<= div>

Thanks,

From: Russ Housley <= housley@vigilsec.com>
Date:&n= bsp;Friday, January 15, 2021 at 23:40
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: "Keselman, Gleb" <Gleb_Keselman@intuit.com>, IETF SecDispatch = <secdispatch@ietf.org>, Yoav= Nir <ynir.ietf@gmail.com>Subject: Re: [Secdispa= tch] Ciphertext format draft

 

Yaro= n:

 

The document does not saqy anything ab= out 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 co= ntext?

 

Russ




On Jan = 15, 2021, at 3:23 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

 

H= i Russ,

 

I=E2=80=99m 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 c= ase 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 =E2=80=9Ccontent type=E2=80=9D doesn=E2=80=99t = make sense. This is early days for the format and people will surely come up= with other use cases.

 

Thanks,=

    &= nbsp;           Yaron=

 

&n= bsp;

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@int= uit.com>, Yoav Nir <ynir.ietf= @gmail.com>
Subject: Re: [Secdispatch] Ciphertext format draft

 

Yaron:

 

How do you see AAD being used? 

 

<= /div>

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-she= ffer-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 colu= mn contains ciphertext) and attributing this data back to the service that c= reated 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.<= o:p>

 

The authors w= ould appreciate this list=E2=80=99s feedback regarding next steps.

<= /div>

 

Thanks,

=

     =            Yaron

 

 

_______________= ________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch<= o:p>

 

_________________________________= ______________
Secdispatch mailing list
Secdispat= ch@ietf.orghttps://www.ietf.org/mailman/li= stinfo/secdispatch

<= div>

 

<= span style=3D'font-size:9.0pt;font-family:Helvetica'>_________________________= ______________________
Secdispatch mailing list
S= ecdispatch@ietf.org
https://www.ietf.org/ma= ilman/listinfo/secdispatch

 

--B_3693753582_497584094-- From nobody Sun Jan 17 09:59:59 2021 Return-Path: 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 F297E3A12C9 for ; Sun, 17 Jan 2021 09:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 kqdraixA0fHQ for ; Sun, 17 Jan 2021 09:59:54 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C972C3A12C7 for ; Sun, 17 Jan 2021 09:59:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 61669300B84 for ; Sun, 17 Jan 2021 12:59:51 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VgRwIBtQcMre for ; Sun, 17 Jan 2021 12:59:46 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id BDAC3300AE5; Sun, 17 Jan 2021 12:59:46 -0500 (EST) From: Russ Housley Message-Id: <1AB484F5-1900-41E2-97AB-5333C36CE191@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_64CC4AB5-D73A-4EBF-9340-DE2BBF8CED16" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Sun, 17 Jan 2021 12:59:48 -0500 In-Reply-To: <3CFBC5E4-1261-4635-931B-BB090E8AB881@gmail.com> Cc: "Keselman, Gleb" , Yoav Nir , IETF SecDispatch To: Yaron Sheffer References: <8B46C11A-790A-4E8E-A7A1-8FE97E2DD9A7@contoso.com> <523854C0-3D2B-4565-A6FF-8DF46EBD88A2@vigilsec.com> <3C9F29DF-CDA6-48BA-B94E-5CCE63E4AA57@gmail.com> <77529C17-9D2F-46A0-9F80-44227A71C5A0@vigilsec.com> <1721133D-89C3-435D-9B0D-BA362A4B1242@vigilsec.com> <3CFBC5E4-1261-4635-931B-BB090E8AB881@gmail.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Secdispatch] Ciphertext format draft X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 17:59:57 -0000 --Apple-Mail=_64CC4AB5-D73A-4EBF-9340-DE2BBF8CED16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, that would allow people to do it the same way. Russ > On Jan 17, 2021, at 11:39 AM, Yaron Sheffer = wrote: >=20 > Hi Russ, > =20 > 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? > =20 > Thanks, > Yaron > =20 > From: Russ Housley > > Date: Sunday, January 17, 2021 at 18:10 > To: Yaron Sheffer > > Cc: "Keselman, Gleb" >, Yoav Nir >, IETF SecDispatch > > Subject: Re: [Secdispatch] Ciphertext format draft > =20 > Yaron: > =20 > 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. > =20 > Russ >=20 >=20 >> On Jan 16, 2021, at 5:13 PM, Yaron Sheffer > wrote: >> =20 >> Hi Russ, >> =20 >> In the example in the document, the database primary key (e.g. = customer=E2=80=99s 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. >> =20 >> 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. >> =20 >> Quoting the blog: =E2=80=9CEncryptionContext 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).=E2=80=9D >> =20 >> Thanks, >> Yaron >> =20 >> From: Russ Housley > >> Date: Friday, January 15, 2021 at 23:40 >> To: Yaron Sheffer > >> Cc: "Keselman, Gleb" >, IETF SecDispatch = >, Yoav Nir = > >> Subject: Re: [Secdispatch] Ciphertext format draft >> =20 >> Yaron: >> =20 >> 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? >> =20 >> Russ >>=20 >>=20 >>=20 >>> On Jan 15, 2021, at 3:23 PM, Yaron Sheffer > wrote: >>> =20 >>> Hi Russ, >>> =20 >>> I=E2=80=99m 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. >>> =20 >>> In our main use case, the data is structured with a well defined = schema (a.k.a., SQL database). So =E2=80=9Ccontent type=E2=80=9D = doesn=E2=80=99t make sense. This is early days for the format and people = will surely come up with other use cases. >>> =20 >>> Thanks, >>> Yaron >>> =20 >>> [1] = https://aws.amazon.com/blogs/security/how-to-protect-the-integrity-of-your= -encrypted-data-by-using-aws-key-management-service-and-encryptioncontext/= = >>> =20 >>> From: Russ Housley > >>> Date: Friday, January 15, 2021 at 18:37 >>> To: Yaron Sheffer > >>> Cc: IETF SecDispatch >, "Keselman, Gleb" = >, Yoav Nir = > >>> Subject: Re: [Secdispatch] Ciphertext format draft >>> =20 >>> Yaron: >>> =20 >>> How do you see AAD being used?=20 >>> =20 >>> 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. >>> =20 >>> Russ >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Jan 15, 2021, at 9:53 AM, Yaron Sheffer > wrote: >>>> =20 >>>> 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. >>>> =20 >>>> We received good feedback on the SAAG list to change from generic = TLV to CBOR, which we implemented in -01. >>>> =20 >>>> The authors would appreciate this list=E2=80=99s feedback regarding = next steps. >>>> =20 >>>> Thanks, >>>> Yaron >>>> =20 >>>> [1] = https://tools.ietf.org/id/draft-sheffer-ietf-ciphertext-format-01.xml = >>>> =20 >>>> _______________________________________________ >>>> Secdispatch mailing list >>>> Secdispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/secdispatch = >>> =20 >>> _______________________________________________ >>> Secdispatch mailing list >>> Secdispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdispatch = >> =20 >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch = --Apple-Mail=_64CC4AB5-D73A-4EBF-9340-DE2BBF8CED16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes, = that would allow people to do it the same way.

Russ

On Jan = 17, 2021, at 11:39 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

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,
          &nb= sp;     Yaron
 
From: Russ Housley <housley@vigilsec.com>
Date: Sunday, January 17, = 2021 at 18:10
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: "Keselman, Gleb" <Gleb_Keselman@intuit.com>, = Yoav Nir <ynir.ietf@gmail.com>,= IETF SecDispatch <secdispatch@ietf.org>
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 = <yaronf.ietf@gmail.com> = wrote:
 
Hi Russ,
 
In the = example in the document, the database primary key (e.g. customer=E2=80=99s= 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: =E2=80=9CEncryptionContext 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).=E2=80=9D
 
Thanks,
          &nb= sp;     Yaron
 
From: Russ Housley <housley@vigilsec.com>
Date: Friday, January 15, = 2021 at 23:40
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: "Keselman, Gleb" <Gleb_Keselman@intuit.com>, = IETF SecDispatch <secdispatch@ietf.org>, Yoav Nir <ynir.ietf@gmail.com>
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 <yaronf.ietf@gmail.com> = wrote:
 
Hi = Russ,
 
I=E2=80=99m 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 = =E2=80=9Ccontent type=E2=80=9D doesn=E2=80=99t make sense. This is early = days for the format and people will surely come up with other use = cases.
 
Thanks,
          &nb= sp;     Yaron
 
[1] https://aws.amazon.com/blogs/security/how-to-protect-the-integr= ity-of-your-encrypted-data-by-using-aws-key-management-service-and-encrypt= ioncontext/
 
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=E2=80=99s feedback regarding next steps.
 
Thanks,
          &nb= sp;     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
 
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch
 
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch
= --Apple-Mail=_64CC4AB5-D73A-4EBF-9340-DE2BBF8CED16-- From nobody Wed Jan 27 17:25:38 2021 Return-Path: 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 73F953A0FD2 for ; Wed, 27 Jan 2021 17:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=a6m/8HuV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rbV1QBzJ 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 dy8RxpRnlRUQ for ; Wed, 27 Jan 2021 17:25:35 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36893A0FD1 for ; Wed, 27 Jan 2021 17:25:34 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 469615C0241 for ; Wed, 27 Jan 2021 20:25:33 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 27 Jan 2021 20:25:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=guj7zT6tPkytdhSkLtNh+4Toypu5Fgzo7m1ircb0vNs=; b=a6m/8HuV FnkEFzcGb5xT2A2SWtx6W3h2K0YGPBbBYvTH3hUIsMZ+sWvgqwx0e/NqMfm0oITX niAMCJ1WARY2rnHNb6oTLTSrgU2TuR1fZHXA4+eAlMPl0b4xzUJ5PQ+xIdfrrCQp UX/U0rzb2z4tPUt1dYhlJSt0wkksQ+nSTetg7EHHHKuh6vp+oINioBwYwMzxWPtu GsjZAJvtB9i6Jh8qm6B5b422mq5V0SQcpwzuMtyX/SsDUTGnQLyCyqczoGQIAc9r hfZO1gGGi0yyIzonZMwPoW1Ub0YRMBcuGAYeOMdmPlrymdLH0Q9XQCUa+APpUK2T l9OJW6Orx0ShPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=guj7zT6tPkytdhSkLtNh+4Toypu5F gzo7m1ircb0vNs=; b=rbV1QBzJvxhWK7aPLaVVxhgl/2w77XvGF6RKZNbcs8cM5 hVsTqM7LnCjV70GKCae0w1Cb8xYKKdsu1jIDrCTBszLDZ63P+mKgHGUTOE/aNeaD yDjLdqGJ+EL+qxnYwTFb9FfLNGJ1l7Ll/acAPaB4erb2Fvc8eywWItF5WWfdSjIH Q3AwpVR3mIUZiwW7wIlCkiMDi2rVUHFN7oT5kk/l5Iv46DPUtvh/LFBYq/rBgMUp idATDuvtTvZsajR7BRSbobaDCiUIoQhDfkvf6oFupGIz3bvaZ9Sm6u5s8oKDoS9R JmkM/bNv5NR0IJTbrqefu+amC/MDzuPayDWa4FZuA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdelgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepleehuddtvddvleduueeigfeige elkeejgefgteelieefvdfhjeejtdekkeefleefnecuffhomhgrihhnpehivghtfhdrohhr ghdprggtmhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 830424E0063; Wed, 27 Jan 2021 20:25:32 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-84-gfc141fe8b8-fm-20210125.001-gfc141fe8 Mime-Version: 1.0 Message-Id: Date: Thu, 28 Jan 2021 12:25:13 +1100 From: "Martin Thomson" To: secdispatch@ietf.org Content-Type: text/plain Archived-At: Subject: [Secdispatch] Requesting dispatch of Oblivious HTTP X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 01:25:36 -0000 Hi, Those familiar with oblivious DNS in its various forms [1][2] probably won't really need any introduction here. This proposes a design that uses HPKE [3] and a proxy to provide a general framework for privacy for sensitive HTTP requests. DNS is one fairly obvious application of this, but there are other applications that might benefit from this. A generic framework will enable those applications. The primary draft is: https://www.ietf.org/archive/id/draft-thomson-http-oblivious-00.html This draft describes the framework, plus how to encapsulate requests and responses using HPKE and the format of the server key configuration that clients need. A supplementary draft describes a simple binary encoding for HTTP requests: https://www.ietf.org/archive/id/draft-thomson-http-binary-message-00.html The request here is to discuss what to do with this work. Assuming this isn't dispatched before the next meeting, that includes a request for agenda time to continue or resolve that discussion. In doing so, we might need to consider how this interacts with existing work in other groups, HTTP, ADD, and DPRIVE in particular. I'll be sending notes to a few groups shortly advising them of this discussion and inviting them to offer input. Cheers, Martin [1] https://dl.acm.org/doi/abs/10.1145/3340301.3341128 [2] https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh [3] https://tools.ietf.org/html/draft-irtf-cfrg-hpke-07#appendix-A.1