From nobody Fri Jul 2 15:05:03 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 17CEF3A09E0; Fri, 2 Jul 2021 15:02:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, secdispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162526337507.26814.8357941255854958622@ietfa.amsl.com> Date: Fri, 02 Jul 2021 15:02:55 -0700 Archived-At: Subject: [Secdispatch] secdispatch - Requested session has been scheduled for IETF 111 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: Fri, 02 Jul 2021 22:03:04 -0000 Dear Mohit Sethi, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. secdispatch Session 1 (2:00 requested) Monday, 26 July 2021, Session III 1600-1800 Room Name: Room 8 size: 508 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/111/sessions/secdispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Security Dispatch Area Name: Security Area Session Requester: Mohit Sethi Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: People who must be present: Benjamin Kaduk Kathleen Moriarty Mohit Sethi Richard Barnes Roman Danyliw Resources Requested: Special Requests: Please avoid conflict with any Security related BoF. --------------------------------------------------------- From nobody Tue Jul 6 04:34: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 139583A2437 for ; Tue, 6 Jul 2021 04:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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 1UO7swF-9WFK for ; Tue, 6 Jul 2021 04:33:58 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20075.outbound.protection.outlook.com [40.107.2.75]) (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 510183A2435 for ; Tue, 6 Jul 2021 04:33:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jZp4NyaH6CYchctiKGvO60f51NvKByOt7ifsJIlC0uTCyAYWOMAtbAUdIZkFuPkpoEo/rMpyMnByWgEqe4Axqi14QkgTnwnPZJ1N6xo/qFRto+kyAxf98R79iR/QZpHHnDkwg6/fI5mbW1abbXs/NtMrGr3U0/CJYwcZtlS8hGSTTHUJkRwFKuo/rjHs1tY/plQedYSzUh7vhEMZHjbSrqTi/4igu5nhiyvHPBr2Pk6VATGeMo0H+JvUOxFDXVZn/mjWIyoxUoH76nimhSq9/HChH56B1Hoh1RNamLd4OBNHOjQkfaATnUkwA3HxwdyACKWavHXC5pzZXF/CH1JyCA== 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=OdCnA4dQEJ6qhsH3a66t2dvn1rukRPybulwUD5piv88=; b=iQI55zVeTlKHG1guXoJtHJKcI5mFTK8JuQ19IKsJ5jQPIZK3wML11DdQ5Dd8AP9uHCEA80HWYNw1qAKOWJb8ADqldK4xvaTpsGtLhTTR/DHHMOpecy039YW56YlTUrZU8WmTTz7YthbTIww8e50mlUOzumQzXpWDrDvsUXlvzNdsR6b4PiodVfwAgmY5oDSSy6FCrz3gyoCtmDSv2hUoQ/irm0nYVkvQ3asJLX8fJpsgsZ2RUl7EZA5MqNWWVxBQ23w76YavnJ/TanjrCvHWcEEeKIMS4kAkUTvSZH17gQkmVPNBCkG71lhCyridnF0GgajZcypYMfje//JkM/W4OQ== 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=OdCnA4dQEJ6qhsH3a66t2dvn1rukRPybulwUD5piv88=; b=BaeFr5mEStzgAZiD5epVKp0FPTDSbFEC3lEFqggbECJF/uCPIJLbAlDFxvyKcef93RM9Ly+dDJJfz+qYGvt+f/r0Nog35WcYkClAvZvysseVPOBodZi8am8hxT6/8DfAK6LaDTeEkSjTzRGqo2V7HddoezybPcNV2cNPBgiul1I= Received: from HE1PR07MB3436.eurprd07.prod.outlook.com (2603:10a6:7:37::31) by HE1PR07MB3083.eurprd07.prod.outlook.com (2603:10a6:7:2f::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.12; Tue, 6 Jul 2021 11:33:54 +0000 Received: from HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::c04b:9f4f:3494:b84c]) by HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::c04b:9f4f:3494:b84c%7]) with mapi id 15.20.4308.019; Tue, 6 Jul 2021 11:33:54 +0000 From: Mohit Sethi M To: IETF SecDispatch Thread-Topic: Call for agenda items - Secdispatch @ IETF 111 Thread-Index: AQHXclrN+crx2ypfbEeWsOzYQg0TUA== Date: Tue, 6 Jul 2021 11:33:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 70feadf1-59b9-4a6e-3b22-08d94071efd3 x-ms-traffictypediagnostic: HE1PR07MB3083: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: THmneRyv58l9J/S6jjynM0jCMJ3aj4Ip8CSnZtYpdK5Rl1MnXd0jPZA8Ktg/gXIg31+A2hvz89vYs75llII1if+JVXU0Cgjfk8OdErdiQ+58g8SA11BjDqTUyXcUbAsaeFJh7Zf08GZE7cSAFcwjzQfzQYJKxT21uErYX1h2M3rcHzdaMpgp04VbAPHtBEp2XdmZRyXEaPcjYBwKgYhVMIF4REi/6Dzm27gk1e9bOSyJiq1US+g5W/msvfgB5NydAcHfpyx9wW1VLndJJrjEldgnDF9SJzpsWf1ERl1+4y3yHRX1Q6KE++Gl431Ip7H+6UVQ9m88AzOGG5U/nbUwTw5fyLe2Sj9skUgM/j9hR/Xbk2T9wQfuSGM8MKuCZy/fzPspLk86EpOzplcGRgeGocANluWqeeFZ+2KoWa5apscou2O4ujNIPY90o1PXpjK5DtNuwFtm6+atpSAC4Ytj6s3soQo21+pwC5hTQvyZJkQ9RwU4Pjk/gcFj6nlA5f28FOHjKe5pjL9ynBK3YrDxMKU2C1+Q4mWSvT/kqaSC1YyR6AgVdMyJxBGQi4q3MIgKP+C4bl9dwCnPmbvSymzQH3ZIiHpKVKmm0vb+MA6Su39RUuCPrcv5uprSjJtO/D1vkE2n8T/PGWqgNp/A1z/XpwMwO2Pf8Ys1EX6f+HcNY/Mi5jypzWCu1Dq5+C3Y6xNW41HhvkUKeqVTD5ODUg0JBTqu0uI99rtrDV/7f3ssHKlQrvaW1hBpxFJCrwUZeBsLOpZShH5fydiq32DsWfaXdxnsI6KGFeF5g+PPWsz/XBIP29Su9kU1jgeiESeuJRLZkiVgaU8pQmelJeSXHLoi5RGa1ZF2lDjChTEy1UP5PoM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3436.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(136003)(376002)(346002)(396003)(38100700002)(66946007)(83380400001)(122000001)(8936002)(31686004)(71200400001)(64756008)(478600001)(66476007)(36756003)(66556008)(5660300002)(86362001)(8676002)(2616005)(316002)(186003)(31696002)(66446008)(2906002)(6916009)(6486002)(6512007)(76116006)(966005)(6506007)(4744005)(45980500001)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?aWR0ZHQwdW5uUFdGSis1ZVVQUm5Cc2Vzb3N0cjUwekVkQjBJeXMvY2l6K0RC?= =?utf-8?B?Y0JzUTZoK3paRXg4TkxYY3N2ZXhwMVlBRWxMTXdGT2h2RTlVbVBzeit3eDJo?= =?utf-8?B?S2JhMFpKV0ZRYkg2L0xIWHNCMUtrdEphOFBFUGhXMjZKS3NMenNSS0FXWFYz?= =?utf-8?B?QzFUdjl3RHJPU3M1cWMrTEkxNFNtT0JOb1JjNHVrbi8yZU9QKzFzMkVSTmlC?= =?utf-8?B?QnFvbXVBN0dxWmJPQnUvSnliYXRWajZTd3VORWNPa1VEMWZzM0VRMVg3TUZP?= =?utf-8?B?dFRlNzRPK1hyb3g5dGErL2d3QkNLOGJuakt0WUZabkdhYnVyUUdxWm5paWpu?= =?utf-8?B?N0ZzU3hJSXBkK1FlNXRTWkZWenJ1QWtiKzBPeWYrOVdhR3FtdFdYNTdZRm14?= =?utf-8?B?TW5CYW16emRQVE9aY3ZnTmM4ZkVlZVlUS1U5clpDQzdDMXliekhmVW1aREJo?= =?utf-8?B?dk9RZHU4emVLTE5wZ0dLbUx0bmQ1ZFZGQVpzSkp4WVEyKzVHQTNtaHBOY2hK?= =?utf-8?B?UDZac3g1RVhzZzlTVVl4YWNsRmIzVWh5c1A2ZXA2NWdaQTg1aUpLTjBtTmcv?= =?utf-8?B?aDNhclRoTTJmS1dXdXluRTFORnN3dFpUeTB3YytJNXRFTG4wNDVzbGlLZk1E?= =?utf-8?B?amM4MHVnWDlSOE01dFFzQ1pjTjNMRVJpYUdJUE1aMDlzYldSNmprbnVOYUVZ?= =?utf-8?B?Qk9JL3RYN01YWm1HZTdMRmVzSFhmd1UxZU9ZQUQvOVpzblBVQ1NmQXFicGpa?= =?utf-8?B?MEw0S01kNjVqSmZwVmFaTEsyMGJrSDRCUGNNYzAvb1lCVyttTTFMYWtNQyti?= =?utf-8?B?TGxzNkVMR2dFVmQrN1N4RytqR3FJb1pmTVBmT3ZlekcrdDlJV3Y5RkhJUHQ0?= =?utf-8?B?Q0ZCUGlOK2I5ek9aSTgyamNtNHpvN0Y2eEpkK0sxSEdING1hUDNtTkNaVm9D?= =?utf-8?B?YjFrbEhkWG9MWTVIYVp0V1ltS3F0OXcwVDhDOTg5STJROGh0TGRZTVR6L29S?= =?utf-8?B?V0ErNEdtbGkybThINFB0SkpEMzV4dDh6c0x2aVBEWFp1VkdQa3pQcWhjMXli?= =?utf-8?B?cjJXZmFJdUxXNnZBdnZaM3BHTHl0RVNRbzU2R2srd1NGY1UwcElMaCtxT3Bi?= =?utf-8?B?bmZ4WnY3dklVWVFnOEw0ZEkzRlJvOUVLVEJZTE1EMm1wOFdveFE1T3hYS0xx?= =?utf-8?B?MEFiZlhFQnk2L2JqMTc0VkhmUGJvWTF4OFgwNUlSU01KLzhYQTVONzRBTGQ3?= =?utf-8?B?TWx4cWphWDRRRU1INWJuZlpwbllYeFZWNkF5cWM5cmJKTmNxK0MwaHVIRndr?= =?utf-8?B?R05yM1dWZ3pxbFZYQ2F1Z1Q4STU1emJnc1N3aDdJRnVjanl0dm95YnhHbEY3?= =?utf-8?B?bHVNZmtVdCtHdFN0cEVFcFg2Ujh0RG1VNDJaMjdEOE5lWW5VTGdXNTY0YkdB?= =?utf-8?B?N3ZJNmVKZ3JmajdJbGx2bG9wc3pScnBBbUlMZGtRSVpnaUI5VUtlUkZkdGxG?= =?utf-8?B?enEwNGJ3K0NCek90cnJXYUhHWk5kd1RlM3Q5ZVFWY1ViQ2JTYmNTWlRScm1T?= =?utf-8?B?cjhPQTUrWVQxU1VrOTJjQTN4RGUwNWNMckFkM1hRTXNBUUVvL0Y5cnNGV2lZ?= =?utf-8?B?Z3dEbHZXZURDb08vTzNlZS8xZXdrL09Pei9BT2ZQVTRwU0ZpT2RSWG5jKzZl?= =?utf-8?B?R1pTY21Hb2FydGMxcGQ1Z1NmaVQ4TTU4SFlxVEUrRzEyYzIxa1RuVWNzVzJr?= =?utf-8?B?WFdtZmxkbTVzcGxvbTlFTlh4NlZHdkhlcjN6VktwdmI0VUhkaldoZmlob1la?= =?utf-8?Q?rQ8OC6A2okgajDvHyaSnujHlxEvAsMWuwb/vw=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3179B2F9E7037E4B8E541560B24A5FFF@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3436.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70feadf1-59b9-4a6e-3b22-08d94071efd3 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2021 11:33:54.8046 (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: drh3d8ZNJ2stRhHvELln0NNk8Rm/CT4aW+LrfLowU4CU4gRYFhaK0Z0izPaP+lcDMlyXTWZqnkdE1ZdIgl//5B14KYjP+UvhdS9WBFNhXUg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3083 Archived-At: Subject: [Secdispatch] Call for agenda items - Secdispatch @ IETF 111 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: Tue, 06 Jul 2021 11:34:03 -0000 RGVhciBhbGwsDQoNCldlIHdpbGwgaGF2ZSBvdXIgMiBob3VyIHNlc3Npb24gb24gTW9uZGF5LCBK dWx5IDI2LCBiZXR3ZWVuIDIzOjAwLTAxOjAwIA0KKCsxKSBVVEMuIFdlIGhhdmUgcmVjZWl2ZWQg cHJlc2VudGF0aW9uIHJlcXVlc3RzIGZvciB0aGUgZm9sbG93aW5nIGRyYWZ0czoNCg0KMS4gZHJh ZnQtam9yZGFuLWp3cy1jdDogDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWpvcmRhbi1qd3MtY3QtMDQNCjIuIGRyYWZ0LXZhdWdobi10bHN0bS11cGRhdGU6IA0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC12YXVnaG4tdGxzdG0t dXBkYXRlLTAxIA0KPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt dmF1Z2huLXRsc3RtLXVwZGF0ZS0wMT4NCjMuIGRyYWZ0LW1hZGRlbi1qb3NlLWVjZGgtMXB1OiAN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWFkZGVuLWpvc2Ut ZWNkaC0xcHUtMDQgDQo8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1tYWRkZW4tam9zZS1lY2RoLTFwdS0wND4NCjQuIGRyYWZ0LWtub2RlbC1lMmVlLWRlZmluaXRp b246IA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1rbm9kZWwt ZTJlZS1kZWZpbml0aW9uLTAxIA0KPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQta25vZGVsLWUyZWUtZGVmaW5pdGlvbi0wMT4NCg0KSWYgeW91ciBkcmFmdC90b3Bp YyBpcyBub3Qgb24gdGhlIGxpc3QgYW5kIHlvdSB3b3VsZCBsaWtlIHRvIHByZXNlbnQgYXQgDQp0 aGUgdXBjb21pbmcgdmlydHVhbCBJRVRGIG1lZXRpbmcsIG5vdyBpcyB0aGUgdGltZSB0byBzdGFy dCBhIHRocmVhZCBvbiANCnRoZSBTZWNkaXNwYXRjaCBtYWlsaW5nIGxpc3QuIFRoZSBTZWNkaXNw YXRjaCB3aWtpIGNvbnRhaW5zIGluZm9ybWF0aW9uIA0KYWJvdXQgd2hhdCB3ZSBleHBlY3QgdG8g c2VlIGluIHRoZSBtYWlsIHRocmVhZCBmb3IgZWFjaCBhZ2VuZGEgaXRlbTogDQpodHRwczovL3Ry YWMuaWV0Zi5vcmcvdHJhYy9zZWNkaXNwYXRjaC93aWtpI1JlcXVlc3RpbmdUaW1lb250aGVBZ2Vu ZGEgDQo8aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvc2VjZGlzcGF0Y2gvd2lraSNSZXF1ZXN0 aW5nVGltZW9udGhlQWdlbmRhPg0KDQpUaGFua3MhDQpLYXRobGVlbiwgUmljaGFyZCwgYW5kIE1v aGl0DQoNCg== From nobody Tue Jul 6 07:59:16 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 534B63A2A9E for ; Tue, 6 Jul 2021 07:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 CfpT7CC6MDeo for ; Tue, 6 Jul 2021 07:59:10 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 76D113A2A9B for ; Tue, 6 Jul 2021 07:59:10 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 166EopJS005212; Tue, 6 Jul 2021 15:59:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=HWvqGaqlaGDm5rwKU9tHR5Loee0ozFUZZL8gvlmu3B8=; b=AOA4tlthXSt7nafDQSIm+I/Dax3uAKd95wqRRX2WEDFN3R9rnxMzGuNq0q38nHrXpGok Xoyiw0iu8iZ1x2YNExmhimfbIVR9WQVEG3OfIFxqkhAy1Pey4cu4gCIc5D0cbFQ9OtVe sOnKLsK4G6GLJi4wHGnAOBGRQlFtYGUA4Nx6LYeZPG8AcGRy5SqRd4fZnBFk46ftKyoe pjLr//Kd32rwpmvR/Wf8Ek+w8IjMmfIwvpJ4yUjAaY0rrG5ersZaEojVxcyA0QV9IC4A itW2b6mjMuxIdZ1WvQtQa8nS+vjhb5fDamopFFi5yFduyxzFcASIHmIjQLpHBiBVKH2b 4A== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 39mmskcs4g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Jul 2021 15:59:08 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 166EoR0P011969; Tue, 6 Jul 2021 10:59:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint7.akamai.com with ESMTP id 39jk80k22u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 06 Jul 2021 10:59:06 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 6 Jul 2021 09:59:05 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.018; Tue, 6 Jul 2021 09:59:05 -0500 From: "Salz, Rich" To: Mohit Sethi M , "IETF SecDispatch" , Alec Muffett Thread-Topic: [Secdispatch] Call for agenda items - Secdispatch @ IETF 111 Thread-Index: AQHXcnd3Rfo+NYdQdUCneV8xlD29Pg== Date: Tue, 6 Jul 2021 14:59:05 +0000 Message-ID: <6AF3F5DE-0DEA-4E57-895A-14AA24CC3622@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.50.21061301 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-06_07:2021-07-06, 2021-07-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxscore=0 malwarescore=0 phishscore=0 suspectscore=0 adultscore=0 spamscore=0 mlxlogscore=674 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107060067 X-Proofpoint-GUID: osn5rbvtfguT0c-_8Vu6VDr-lP4Y2rFE X-Proofpoint-ORIG-GUID: osn5rbvtfguT0c-_8Vu6VDr-lP4Y2rFE X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-06_07:2021-07-06, 2021-07-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 spamscore=0 suspectscore=0 mlxlogscore=638 malwarescore=0 bulkscore=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 clxscore=1011 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107060068 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.33) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint7 Archived-At: Subject: Re: [Secdispatch] Call for agenda items - Secdispatch @ IETF 111 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: Tue, 06 Jul 2021 14:59:15 -0000 PiAgICA0LiBkcmFmdC1rbm9kZWwtZTJlZS1kZWZpbml0aW9uOiANCj4gICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1rbm9kZWwtZTJlZS1kZWZpbml0aW9uLTAx DQoNClRoaXMgaXMgYmVpbmcgcHJlc2VudGVkIGF0IENGUkc6IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbXVmZmV0dC1lbmQtdG8tZW5kLXNlY3VyZS1tZXNzYWdp bmctMDENCg0KSXQgd291bGQgYmUgdXNlZnVsIGlmIHRoZSBhdXRob3JzIGNvdWxkIGJlIHJlYWR5 IHRvIGNvbXBhcmUvY29udHJhc3QgYmV0d2VlbiB0aGUgZG9jdW1lbnRzLiAgTm90IG9uIHRoZSBs aXN0LCBub3Qgbm93LCBwbGVhc2UgOikNCg0KDQo= From nobody Tue Jul 6 11:16:24 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 D32E03A3057 for ; Tue, 6 Jul 2021 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 x5d5dMtelPIi for ; Tue, 6 Jul 2021 11:16:18 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 5E5D23A3058 for ; Tue, 6 Jul 2021 11:16:18 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id h2so28468qtq.13 for ; Tue, 06 Jul 2021 11:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:from:subject:to :content-language:content-transfer-encoding; bh=1O/p5NlVqjYzo2oFcsjr8RcZQR77b3qu/JRirelT1K8=; b=STQSYZMe/VCio9g3uDFbuzXQzA8Kd1Ph0wpcRrHgSFsRdVDl92wnAyXhUR96GSdxs3 UcgL5i5NSUjoGJfyAvMGu4X6D8GnzcjOnEZejIk1wBVy2PV2E/TWY8heqicdZ8zZNyP6 S4jfSxOrUx4ATXirIu63mhZVeyNZqzWMjwHaE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:to:content-language:content-transfer-encoding; bh=1O/p5NlVqjYzo2oFcsjr8RcZQR77b3qu/JRirelT1K8=; b=atNp/QQgsb7s99+T8xD3gKQJaoiqgZ4xTEaW7kBKFEWsrjIz8b257hvEXD/AcUIGU+ kcGG6S98ixO3yvNg8RroXXZ7M+cS6kCJjV1vjwnbUzyNFiJe+d1uh8/Iykk8zV7yvoZz SCivtzLQEOWWQW0pWbMYXWyES6jjNI7CTSWkwK7Hbjbi62HNxBx47xuxVAjh8oMXfIZR ZI14BKunL4KWNFQofN+L3p/IjbELNPM5FLk/LP4o14hd0/rX35NCj4s8WHaqEDyVoNv1 6PWkt4SFB6lr/Dkl1frtUaTi3D231ZLrONQUFiBh3swi1j+wUjCZi7ZpA9pvAjdld2fr WJTw== X-Gm-Message-State: AOAM532NzopG8TzOgUXjrhgra66eOyvWEQ4nYGrFufqE122+cRR3t73t 4oHDZGsPeP59JfPlOwIHnmsvcg== X-Google-Smtp-Source: ABdhPJwa+c196jY1bca5kyyQyTzJ6K8ib1gv4T4b+ap3RLZ3+oqgUSjFjD8pB5zw5CyPLNwIrxdEtA== X-Received: by 2002:a05:622a:89:: with SMTP id o9mr18090424qtw.339.1625595376657; Tue, 06 Jul 2021 11:16:16 -0700 (PDT) Received: from [192.168.0.130] (c-73-163-188-207.hsd1.dc.comcast.net. [73.163.188.207]) by smtp.gmail.com with UTF8SMTPSA id d3sm3714628qtp.12.2021.07.06.11.16.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 11:16:16 -0700 (PDT) Message-ID: Date: Tue, 6 Jul 2021 14:16:15 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:90.0) Gecko/20100101 Thunderbird/90.0 From: Mallory Knodel To: "secdispatch-chairs@ietf.org" , secdispatch@ietf.org Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Secdispatch] Requesting agenda time for draft-knodel-e2ee-definition 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: Tue, 06 Jul 2021 18:16:23 -0000 Hi everyone, I requested time on the agenda to discuss https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition, a relatively new document that my co-authors and I wrote earlier this year. It is a three-part definition for end-to-end encryption (formal, features, user expectations). Feedback on the MLS working group list has been encouraging. Additionally I presented at the last MLS interim and it was suggested that secdispatch provide feedback on the best place for this draft, if not MLS. I will have -02 in the datatracker before the 111 meeting that brings in more nuance to the "end" problem as it relates to identity, and a nice pointer to a game-based definition. I'm hoping to use 10 minutes to present and get feedback on which WG is best to continue work on the draft. Thanks! -Mallory -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Wed Jul 7 06:04:39 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 5A17A3A145A; Wed, 7 Jul 2021 06:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch 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 cbK9jzxhS99y; Wed, 7 Jul 2021 06:04:33 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 EE4DC3A1455; Wed, 7 Jul 2021 06:04:32 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1001::440] ([IPv6:2001:420:c0c0:1001:0:0:0:440]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 167D4Siq100496 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 7 Jul 2021 15:04:28 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1625663068; bh=X+ds4SJFHPwv850KGKf9dbe7ZB25GEagf1mTUUODjxw=; h=To:References:From:Subject:Date:In-Reply-To:From; b=jsEX2DkpPfFOqrcKYi4DMQhSmC2GpE/TSZpE4G/vJBrtPltOwI2Nu+B5RyvPQ8w3S PvcGWsjJk29Jd/8Ml95vVBdTij+8mGsFT0lP++WOsLzJZuqxMhZS7+X/f58iLssxIg jXK9hDNdBeZnEK6zUP/ZtIYQaX9TMIutsAFHa7W4= To: Mallory Knodel , "secdispatch-chairs@ietf.org" , secdispatch@ietf.org References: From: Eliot Lear Message-ID: <1adb0acc-39c5-1d47-3522-88d67f2ef60e@lear.ch> Date: Wed, 7 Jul 2021 15:04:25 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V39IxtOdFaSJbCKQDmtzvlhRLEclEaAxP" Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-knodel-e2ee-definition 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: Wed, 07 Jul 2021 13:04:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V39IxtOdFaSJbCKQDmtzvlhRLEclEaAxP Content-Type: multipart/mixed; boundary="n00OBRwF7TgcvmnFGI6vcAADDVSP1C4rp"; protected-headers="v1" From: Eliot Lear To: Mallory Knodel , "secdispatch-chairs@ietf.org" , secdispatch@ietf.org Message-ID: <1adb0acc-39c5-1d47-3522-88d67f2ef60e@lear.ch> Subject: Re: [Secdispatch] Requesting agenda time for draft-knodel-e2ee-definition References: In-Reply-To: --n00OBRwF7TgcvmnFGI6vcAADDVSP1C4rp Content-Type: multipart/alternative; boundary="------------9B4622BCC7DF69BFFD25CB37" Content-Language: en-US This is a multi-part message in MIME format. --------------9B4622BCC7DF69BFFD25CB37 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Mallory, I am hoping that you don't actually mean to create a new definition of a = term that has been around at least since 1984.=C2=A0 I *think* what you m= ean=20 to do is to establish an aspirational model that leads to a state in=20 which certain conditions hold true.=C2=A0 Would I be wrong? Eliot On 06.07.21 20:16, Mallory Knodel wrote: > Hi everyone, > > I requested time on the agenda to discuss=20 > https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition, a=20 > relatively new document that my co-authors and I wrote earlier this=20 > year. It is a three-part definition for end-to-end encryption (formal, = > features, user expectations). > > Feedback on the MLS working group list has been encouraging.=20 > Additionally I presented at the last MLS interim and it was suggested=20 > that secdispatch provide feedback on the best place for this draft, if = > not MLS. > > I will have -02 in the datatracker before the 111 meeting that brings=20 > in more nuance to the "end" problem as it relates to identity, and a=20 > nice pointer to a game-based definition. > > I'm hoping to use 10 minutes to present and get feedback on which WG=20 > is best to continue work on the draft. > > Thanks! > > -Mallory > --------------9B4622BCC7DF69BFFD25CB37 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Mallory,

I am hoping that you don't actually mean to create a new definition of a term that has been around at least since 1984.=C2=A0= I think what you mean to do is to establish an aspirational model that leads to a state in which certain conditions hold true.=C2=A0 Would I be wrong?

Eliot

On 06.07.21 20:16, Mallory Knodel wrote:
Hi everyone,

I requested time on the agenda to discuss https://datatracker.ietf.org/doc= /draft-knodel-e2ee-definition, a relatively new document that my co-authors and I wrote earlier this year. It is a three-part definition for end-to-end encryption (formal, features, user expectations).

Feedback on the MLS working group list has been encouraging. Additionally I presented at the last MLS interim and it was suggested that secdispatch provide feedback on the best place for this draft, if not MLS.

I will have -02 in the datatracker before the 111 meeting that brings in more nuance to the "end" problem as it relates to identity, and a nice pointer to a game-based definition.

I'm hoping to use 10 minutes to present and get feedback on which WG is best to continue work on the draft.

Thanks!

-Mallory

--------------9B4622BCC7DF69BFFD25CB37-- --n00OBRwF7TgcvmnFGI6vcAADDVSP1C4rp-- --V39IxtOdFaSJbCKQDmtzvlhRLEclEaAxP Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDlplkFAwAAAAAACgkQh7ZrRtnSejMQ DwgA3JPar5bSG3n1QA6wSt0613ylQdEXWKribnwZEjCHPAFFFc15Y4ORG9nEPamE6SbzTaehv5XA 5Y5Sq7cuXzYzA5DCeBCf16Sb2vsx1b5N9yvbU97E5um0+lgDkFpe7RD9bzaQRGB0v5Oubr/GQ+tS ou7q2LQ8bKcw5M39bgduLkRBb4fIry0ytAP/AipmlMF6fuSppex5vNW65srhMrK2MbtUXNuW7sA3 TcZfps/0ozAGf++PS0eoCkOe2mCZnV+vHABJaK+g7W4d4hJYTY0ly/4QqSRzia8ACS8XJO1X4s7R NM+ipTVEKvMumSsNVp3sE6Z6DqdK/a9eSo88cPqSJw== =Ue6k -----END PGP SIGNATURE----- --V39IxtOdFaSJbCKQDmtzvlhRLEclEaAxP-- From nobody Wed Jul 7 06:23:51 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 EDE763A163D; Wed, 7 Jul 2021 06:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 kyPcJISqmXlm; Wed, 7 Jul 2021 06:23:45 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367F93A163C; Wed, 7 Jul 2021 06:23:45 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GKg9V1Zy3z2xG9; Wed, 7 Jul 2021 15:23:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <1adb0acc-39c5-1d47-3522-88d67f2ef60e@lear.ch> Date: Wed, 7 Jul 2021 15:23:41 +0200 Cc: Mallory Knodel , "secdispatch-chairs@ietf.org" , secdispatch@ietf.org X-Mao-Original-Outgoing-Id: 647357021.62851-2a734ca9009cbd1a52fa13af60f026c4 Content-Transfer-Encoding: quoted-printable Message-Id: <65230170-A28A-4CF8-B904-6A89198B8656@tzi.org> References: <1adb0acc-39c5-1d47-3522-88d67f2ef60e@lear.ch> To: Eliot Lear X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-knodel-e2ee-definition 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: Wed, 07 Jul 2021 13:23:50 -0000 On 2021-07-07, at 15:04, Eliot Lear wrote: >=20 > I am hoping that you don't actually mean to create a new definition of = a term that has been around at least since 1984. I think what you mean = to do is to establish an aspirational model that leads to a state in = which certain conditions hold true. Would I be wrong? As in https://datatracker.ietf.org/doc/html/rfc1775 ? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 12 11:42:03 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 106CE3A0860; Mon, 12 Jul 2021 11:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.995 X-Spam-Level: X-Spam-Status: No, score=-9.995 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Y+czAU4i; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sgXpmkGo 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 nPbucYc6CvgY; Mon, 12 Jul 2021 11:41:56 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460AD3A085B; Mon, 12 Jul 2021 11:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9529; q=dns/txt; s=iport; t=1626115316; x=1627324916; h=from:to:cc:subject:date:message-id:mime-version; bh=xrYz1KStB69d2YVbx9OZJ2xdcodO9/VH0JvRuI0MJyc=; b=Y+czAU4iFJdpfBDaWaglNSHxF+4V5cs+3Rt3fbAG6qC8dIkJ/I3CtS17 pjWyty/V/Sg1H35h50hoPKeky/5TXunWIFe3c/e0ddQAN1t/IZCmHLMBJ uL7mI+M/Xt8gWGypGZOHKYdrEZeUL0WL7iMAwtHgFwVSC8PKFrtz8lKWJ Y=; X-IPAS-Result: =?us-ascii?q?A0DBAgCPjOxgl4ENJK1XAx0BAQEBCQESAQUFAYIZgSMwU?= =?us-ascii?q?X5aNzGESINIA4U5iFeVLYUAglMDVAsBAQENAQE1DAQBAYRUAheCYQIlOBMCB?= =?us-ascii?q?AEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQFohWgNhkgWER0BATAHA?= =?us-ascii?q?Q0EAQ84AwIEGRcUEwQBDQUigk8BgX5XAy8BDpx8AYE6AoofeoEygQGCBwEBB?= =?us-ascii?q?gQEgUlBgy4YgjIJBYE1gnuCcVM5DwEBhmInHIFJRIE8DBB4gWqBQgGBXQIDg?= =?us-ascii?q?TRACgwJCAmCUDaCLoQDUgFPO1CSUoM5iDKNM5ITCoMkBYoslAMFJoUqoSgrh?= =?us-ascii?q?juPHIwukyIpIAKEZQIEAgQFAg4BAQaBciKBW3AVZQGCPglHGQ6OHxcCg1eFF?= =?us-ascii?q?IVKczgCBgoBAQMJiWyCRwEB?= IronPort-PHdr: A9a23:LvigLxSKMNW/hKKMv+aOa7D2stpso6fLVj580XJvo7NDbqrl+I7tb wTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pNVcFhMwakhZmDJuDDkv2f//ncyJ8G 95NBxdp+nihOh1TH8DzL1TZvny162sUHRPyfQp4L+j4AMjclcOyguuz4JbUJQ5PgWnVXA== IronPort-HdrOrdr: A9a23:SdTGuKy2Lk47DPNsZhVoKrPxp+skLtp133Aq2lEZdPULSK2lfp GV8sjziyWatN9IYgBcpTiBUJPwJk80hqQFnbX5XI3SEzUO3VHJEGgM1/qY/9SNIVyaygc/79 YvT0EdMqyLMbESt6+Ti2PUf6dCsbu6GcuT9IHjJgJWPHlXgtZbnn5E42igYylLbTgDIaB8OI uX58JBqTblU28QdN6HCn4MWPWGj8HXlbr9CCR2RiIP2U2rt3eF+bT6Gx+X0lM1SDVU24ov9m DDjkjQ+rijifem0RXRvlWjr6i+2eGRieerNvb8z/T9GQ+czjpAo74RHIFqiQpF4t1HLmxa1u Uk7S1QZviboEmhAV1d6SGdpTUIlgxes0MLDTSj8CHeSQuTfkNgNyMJv/MoTvOSgXBQze1Uwe ZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjxUC3fLFuIIO5l7Zvt3+90a1wax7S+cQiCq 1jHcvc7PFZfReTaG3YpHBmxJipUm4oFhmLT0AesojNugIm0ExR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY+8C3DLQxjLLGWOSG6XWZ3v+0i94qIfxY9FkN1CVKZ4vqfaqa 6xJm+w71RCCH4GIff+qaF2zg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,234,1620691200"; d="scan'208,217";a="743398763" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jul 2021 18:41:55 +0000 Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 16CIftdT017473 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 12 Jul 2021 18:41:55 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 12 Jul 2021 13:41:54 -0500 Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 12 Jul 2021 14:41:53 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 12 Jul 2021 14:41:53 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l5VdWR0RTgFBYBdf7BdQKfxq1s+KogmrTpQsMofW+ZWRiTDBV4neto3vrX3yFXudM0hOsRNEP08nDKBaGXHkgdjWyKSisJlNkZBK7tN0Tdi/Ey/gJzJuePHxCGJ5ExltDsgx+yLmLTZvRMBCi6eg7enocZhtE91dRERPKZx2dtNRHpqHsnHCiQsViZk/cDioNluUo0hknn3B47lpRiNbM/hhq1FKbHzcXcQDmWyYrZ0Nuz/4STRQeX9uu9WEiBjfAKUEAaX7H30kEX5uAD4Z0EZ1Ij+RkGF56S4eefQhFDPO4LkC3DgOK+HAmr8iJ6koRFpdMh9ThuSw7M2kkK2AKg== 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=xrYz1KStB69d2YVbx9OZJ2xdcodO9/VH0JvRuI0MJyc=; b=Bzodr24aq3dn7gm9GeU447TVzv/2uPTdIj5cTXJTu1uSKY7iho94CIkBIp9gefEEVQgssmpZshGi3Xh8Yl2b/8m2TdfkqYaU/1o1GT+1nVy+fhm39YA4tZMTG2br7bQhViZ7gIf9pZtDIS0MMMl9i93W9IdEd+IOis0JS5vrgX1fL9PFKQLUw/f7yzEXF+2pfgTsdop8NbpkmnFqu/Ohcq1TCwmOFLp0sH9RoHi3scSlEI98M5F3IiBSVa1oXdnHB9X9jceuZMTEhO71TnzOYGVdGsBQgRJ6GhzZ68sf8IRhF3H/zNaSB90j/40zZvEMAp0PMtcUqsR+ElRJXVZZTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xrYz1KStB69d2YVbx9OZJ2xdcodO9/VH0JvRuI0MJyc=; b=sgXpmkGo6PjrsW+xCDGo7bnXCEt9KMUBtokmVkNoEWKkyTe73cxFXsFq4JUhOuaoGSNbTEMfyE4zBv/g2rfvUdSEv433BsWAfWcZlSO30YL807BNQcv6hmx8OZYy0Ey2+j3sYMSfjZu+kTChyHymiFoAWft4Ppz6LNJEEQ62Cwg= Received: from BN0PR11MB5742.namprd11.prod.outlook.com (2603:10b6:408:162::18) by BN7PR11MB2738.namprd11.prod.outlook.com (2603:10b6:406:b3::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.23; Mon, 12 Jul 2021 18:41:52 +0000 Received: from BN0PR11MB5742.namprd11.prod.outlook.com ([fe80::147e:497d:90f3:b90d]) by BN0PR11MB5742.namprd11.prod.outlook.com ([fe80::147e:497d:90f3:b90d%3]) with mapi id 15.20.4308.026; Mon, 12 Jul 2021 18:41:52 +0000 From: "Jerome Henry (jerhenry)" To: "secdispatch@ietf.org" , "secdispatch-chairs@ietf.org" CC: "Stephen Orr (sorr)" Thread-Topic: Requesting agenda time @ IETF 111 for FT OWE Thread-Index: AQHXd02UwdNPCDPfP0eUZvI0Hq58pw== Date: Mon, 12 Jul 2021 18:41:51 +0000 Message-ID: <441F1B88-4775-4303-ABCA-928BC9800242@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.50.21061301 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 320fa800-7261-4cd0-9857-08d94564b728 x-ms-traffictypediagnostic: BN7PR11MB2738: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: G2kSbQbjfic4yQXucTxMyN6MOps8TBF0k+IeM+Fy/Pv1NAtMavAkysOJiShljuGDV25dNIdDNmgloX8MRfLpybHyC5bSCjMQgpVFVfMIvjUmYdPjFFb8HcpYqWxyPXVrTp2aCzB6SFs7aW3ckzxGd6K+uNkq2kHph4SvJdNlMbIKwgCHQkkgU251M6WpQgw9FisuvhHY/gjwUonJOGk8rfz9eCYhzQ1/2TWy80sH8cvsTmPqFn6UYohLOeZtr5jdcjl7D4fNhwh9u6F7ggEXLjOYvABNhFBsQxr9YY7gV5rjUgA33bhVWykyPy9JeMhcVsw3Ja+rbGbXe9z6c6nvapy0Vwo7+Q7ECzOZ0ifAPvzWGHw4lJ1LGwmbk5P/Vhpkl5FmPQOoUa15VjYjkGrd5aHXi39A5QQgbJjTts/JUxAgUj5XwEms4LQrSrGP9XhujXxF+jPKdhyKvrghBFJX2zWv3Mi2ncdLbgx7Aegh3ygMbbZS5TbnQPMvrntPsKKiFAQaUn/azobud8CsiWe49SLfc67PYWxLyYHsO/S0YEVi+knyKcFLWF6DNeNDuljdVP118HspeuUJuIQH36ozbyc4mk4Y60lCLl0oKPdJ632np62l3Iq2/0toiP5nRVG7FyUlR/FEEoKX5hfrctJjbeWc8VinC6bVKKBTw4buQw+oe0++6t68FTh7djpJa9rtGUHolyosQKD68tDDlyxsgmpk23oSE3wf7CbqLOI5MFYNtqgygSS5ppx12PQzVxiwHcTgLDLik8wzNS/5k+hSnuAR9U3kh0rQzkDYWZYUeU4zzDhoHSF8+XTeTpuR0AHA/TCHo0YVR4Z7L9f01n/2Lg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0PR11MB5742.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(136003)(39860400002)(376002)(346002)(66446008)(5660300002)(36756003)(478600001)(86362001)(64756008)(66556008)(6486002)(450100002)(26005)(6512007)(66476007)(8676002)(4326008)(110136005)(966005)(122000001)(76116006)(66946007)(2906002)(166002)(71200400001)(4744005)(83380400001)(316002)(2616005)(8936002)(186003)(107886003)(33656002)(6506007)(38100700002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?U3U5R3lZdGx5TWFMTDl1MWJGemIyaTdRMnZGMVdPQXZtQnpLejhEVWpNUS9S?= =?utf-8?B?Z2hjbDdTaW95alczV29CR3BnTnVtenNEenc2TGw0eWdYem9jVjFvd3NOT0FI?= =?utf-8?B?N2JwaGNFOWIwUnQxOUt2UUZhb1RCc1E3bXJmcjNwdERSTWpzZG83K3l0U3NJ?= =?utf-8?B?UHE2VmdsQ3dyVGdJZmpQendCNHAxRURwNjRiTW9TcWxacDgrN05IY3VzZWNw?= =?utf-8?B?L2ErT1NHcGRZLzEzSUZZaDVpdS9tVm9BbFBqNnUzRU8yd0ZoSDJHbnhnSmcv?= =?utf-8?B?aitab2ZTNi9XUzRVbk4yc1VGWXpMaWRieElDZ2tXWnkxcktsaGdDMElNcUl3?= =?utf-8?B?WEQwTGRvNW5lNGYxY21lTjVkdzQ4dmNRQU44T3k2cnFKVGRuZDM1S1Y5NUk2?= =?utf-8?B?ME8razFka01neWxyYzVFRi9qTmIxSS9sbDRQdEhsTjU0Y0FhaUFRQzh4MTF2?= =?utf-8?B?M2lCWkY4dlBpWDY1dElpenRrbTZYOXR0RE10ZWZpZnJHY3J0QzdGVXVsNTBQ?= =?utf-8?B?M2F4Sng2SFRvVmkwV2dpSjd1b3NIWkt0VTZDUzl4Mi93WlJ6S1VEOFBFMUQw?= =?utf-8?B?V2QvU2FzUjFsb2RUcDlaMVhGdnd2MGNkek5XR1ZIOTgyME15eWJwY1Zkd1Ny?= =?utf-8?B?TzdyNFE0Q1hxY2oxSCtVUFU2dDYzY2RoeHNSQXZicHlkcndxYVV0VG1ON2Nq?= =?utf-8?B?YTFKWGUrdXNRaTdDcnpjWlFzUFJYRzJkVEZFNFNGM05GM3NvWWJlS2dKejFH?= =?utf-8?B?OHZxYW54SWRtYk5ZbmJMNWdEbWZQWXl6c3dNTDNPSHdsRkhXMUR3K09VMllL?= =?utf-8?B?QjZPOU0wZnNDbkNNNEdhQ2FzME15UHN6eDhpUGZaQldZd0xDQzdWajJwQUhI?= =?utf-8?B?TUVhWkJ4RG85SGhQb3k4M1NmTEFPVG9GSlpyZ0RxaU9rMEwwMGtQQ1c4T3J3?= =?utf-8?B?UU1WRlF3OFZPWEVZdnZpUkZZV0lNWFA4cWZFMWNacmxSRC9HZXJOL2xQR2Z2?= =?utf-8?B?dmZVdDdqSXRMOFJwd3U1ODV2SlhWYU1EK1FSRXYza1dwZTNrL3pVc2Q4cy9N?= =?utf-8?B?TjJpeDhPVkcrNm1xYmpzWmVLNmJFYU1JNCt5emdRZmFwUnFOelNEaW9YMXpN?= =?utf-8?B?WnBXV0NzbWdkWkNYdHlvUmpGblgxWGJRL0pBVDN3ajZpOVYxWkl3VkNRYVlx?= =?utf-8?B?dW1ORTJDUnlJaXZPNi8zOE4weThsMWQzdUMrTVFUSkxEMHRNM1F5QnNtWS82?= =?utf-8?B?eHZSM0NSZlJueUVGOTNZRDNHMU5BZ0RTbzNqcU9ucjVSbkRmUXYwTXRKWlhB?= =?utf-8?B?eEwwY2JTTjRpYzZlUCtxeTRoMnBNRk9oZWk3VWtvU1RCT1dsVkIzQUp0cTB5?= =?utf-8?B?VEZaWEdlNnhDVFNvcDZvQ1p0bjVoRUpXOVBSNEF0K0tyS2kzVVZqczVKNHdL?= =?utf-8?B?Y1Nma3hta0FLT1ZDNEVPWjNUQ3VzbmluV3JqZHMwNHM4VGRqZ2pOZlBidlpH?= =?utf-8?B?amFZSE9BZGZHN2Q4Z3ZaaHVJY1BjMTd0Qnh4Nmx0WDY1YXh2QU9lbTJKT3lG?= =?utf-8?B?b29RRFZBeXQyOXRkVktWRzNIN1VROUZhRW52dkJRQTZKQzU5a2pxTUZ6c2JW?= =?utf-8?B?QnYxQ1Z1Sm1sd1BHRHNFWXRKb1pvR0xTdEZwYmZ4Z3laampCaGdDTnQwMXk3?= =?utf-8?B?SnBpWmpETzBMSEw4bkR1VUJvNGpJQWxFMWlHbDZFNThqOXdFZ0E3K2ZOaXNK?= =?utf-8?Q?PktQEiZFaK3j8TwhZsbmyOLLqx9J9CKLitEkIW5?= Content-Type: multipart/alternative; boundary="_000_441F1B8847754303ABCA928BC9800242ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN0PR11MB5742.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 320fa800-7261-4cd0-9857-08d94564b728 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2021 18:41:52.0676 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ljCwBalr/fZgmDk7Ay47v4bcMj2ZxPKpiE2QsLqSAxqPPJTEOTIFhv7fshnS2MFJLLhQL0YHqNws5OUsJKLCfQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2738 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: [Secdispatch] Requesting agenda time @ IETF 111 for FT OWE 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: Mon, 12 Jul 2021 18:42:01 -0000 --_000_441F1B8847754303ABCA928BC9800242ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQpXZSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgYWdlbmRhIHRpbWUgYXQgSUVU RiAxMTEgdG8gcHJlc2VudCBvdXIgZGlzY3VzcyBGVCBPV0U6DQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1oZW5yeS1mdC1vd2UvDQoNCk9wdGltaXN0aWMgV2lyZWxlc3Mg RW5jcnlwdGlvbiBpcyBkZWZpbmVkIGluIFJGQyA4MTEwLiBUaGlzIHByb3Bvc2FsIGF1Z21lbnRz IFJGQyA4MTEwIGJ5IHByb3Bvc2luZyBhIEZhc3QgVHJhbnNpdGlvbiBtb2RlIChzaW1pbGFyIGlu IGNvbmNlcHQgdG8gRlQgZGVmaW5lZCBpbiA4MDIuMTEpLCB0aGF0IGFsbG93cyBhIGNsaWVudCB0 byBwcmUtbmVnb3RpYXRlIE9XRSwgdGhyb3VnaCBhIGZpcnN0IFdpRkkgYWNjZXNzIHBvaW50IChB UCksIHdpdGggYSBzZWNvbmQgQVAuIFdlIGJlbGlldmUgdGhhdCB0aGlzIG1vZGUgaXMgdXNlZnVs IHRvIDEpIGFjY2VsZXJhdGUgdGhlIHRyYW5zaXRpb24gZnJvbSBvbmUgQVAgdG8gdGhlIG5leHQg KGJ5IGF2b2lkaW5nIHRoYXQgdGltZSBpcyB3YXN0ZWQgbmVnb3RpYXRpbmcgbmV3IGtleXMgYXQg dGhlIHRpbWUgb2YgdGhlIGp1bXApIGFuZCAyKSBwcm92aWRlIGEgcmVhc29uYWJsZSBpbmRpY2F0 aW9uIHRoYXQgYm90aCBBUHMgaGF2ZSBhIHRydXN0ZWQgcmVsYXRpb25zaGlwIG92ZXIgdGhlIHdp cmUuDQoNClRoYW5rcyENCg0KSmVyb21lDQoNCg0KLS0NCkplcm9tZSBIZW5yeQ0KUFJJTkNJUEFM IEVOR0lORUVSDQpPZmZpY2Ugb2YgdGhlIENUTw0KamVyaGVucnlAY2lzY28uY29tPG1haWx0bzpq ZXJoZW5yeUBjaXNjby5jb20+DQpQaG9uZTogKzEgOTE5IDM5MiAyNTAzDQpDaXNjbyBTeXN0ZW1z IExpbWl0ZWQNCjcxMDAtOCBLaXQgQ3JlZWsgUm9hZCBQTyBCb3ggMTQ5ODcNClJFU0VBUkNIIFRS SUFOR0xFIFBBUksNCk5PUlRIIENBUk9MSU5BDQoyNzcwOS00OTg3DQpVUw0KQ2lzY28uY29tPGh0 dHA6Ly93d3cuY2lzY28uY29tLz4NCg0KDQoNCg0KDQo= --_000_441F1B8847754303ABCA928BC9800242ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <32086E6F7C28A34E94BD5490C25D3B7A@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IZWxsbyBhbGwsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XZSB3b3VsZCBsaWtlIHRvIHJlcXVl c3QgYWdlbmRhIHRpbWUgYXQgSUVURiAxMTEgdG8gcHJlc2VudCBvdXIgZGlzY3VzcyBGVCBPV0U6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWhlbnJ5LWZ0LW93ZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWhlbnJ5LWZ0LW93ZS88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5PcHRpbWlzdGljIFdpcmVsZXNzIEVuY3J5cHRpb24gaXMgZGVmaW5lZCBpbiBS RkMgODExMC4gVGhpcyBwcm9wb3NhbCBhdWdtZW50cyBSRkMgODExMCBieSBwcm9wb3NpbmcgYSBG YXN0IFRyYW5zaXRpb24gbW9kZSAoc2ltaWxhciBpbiBjb25jZXB0IHRvIEZUIGRlZmluZWQgaW4g ODAyLjExKSwgdGhhdCBhbGxvd3MgYSBjbGllbnQgdG8gcHJlLW5lZ290aWF0ZQ0KIE9XRSwgdGhy b3VnaCBhIGZpcnN0IFdpRkkgYWNjZXNzIHBvaW50IChBUCksIHdpdGggYSBzZWNvbmQgQVAuIFdl IGJlbGlldmUgdGhhdCB0aGlzIG1vZGUgaXMgdXNlZnVsIHRvIDEpIGFjY2VsZXJhdGUgdGhlIHRy YW5zaXRpb24gZnJvbSBvbmUgQVAgdG8gdGhlIG5leHQgKGJ5IGF2b2lkaW5nIHRoYXQgdGltZSBp cyB3YXN0ZWQgbmVnb3RpYXRpbmcgbmV3IGtleXMgYXQgdGhlIHRpbWUgb2YgdGhlIGp1bXApIGFu ZCAyKSBwcm92aWRlIGEgcmVhc29uYWJsZQ0KIGluZGljYXRpb24gdGhhdCBib3RoIEFQcyBoYXZl IGEgdHJ1c3RlZCByZWxhdGlvbnNoaXAgb3ZlciB0aGUgd2lyZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkplcm9tZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0tJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI3MjQiIHN0eWxlPSJ3aWR0aDo1NDMu MHB0O2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9 IjMyNyIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyNDUuNTVwdDtwYWRkaW5nOjBpbiA1LjRw dCAwaW4gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkplcm9tZSBIZW5yeTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UFJJTkNJUEFM IEVOR0lORUVSJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk9mZmljZSBvZiB0aGUgQ1RPPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxhIGhyZWY9Im1haWx0bzpqZXJoZW5yeUBjaXNjby5jb20iIHRpdGxlPSJt YWlsdG86amVyaGVucnlAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+amVy aGVucnlAY2lzY28uY29tPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGhvbmU6Jm5ic3A7 PGI+KzEgOTE5IDM5MiAyNTAzPC9iPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg d2lkdGg9IjMzNSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyNTEuNXB0O3BhZGRpbmc6MGlu IDUuNHB0IDBpbiA1LjRwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Q2lzY28gU3lzdGVtcyBMaW1pdGVkPC9zcGFuPjwvYj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij43MTAwLTggS2l0IENyZWVrIFJvYWQgUE8gQm94IDE0OTg3PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlJFU0VBUkNIIFRSSUFOR0xFIFBBUks8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Tk9SVEggQ0FST0xJTkE8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Mjc3MDktNDk4Nzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5VUzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS8iPjxzcGFuIHN0eWxlPSJj b2xvcjojOTU0RjcyIj5DaXNjby5jb208L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8dGQgd2lkdGg9IjMiIHN0eWxlPSJ3aWR0aDoxLjk1cHQ7cGFkZGluZzowaW4gNS40 cHQgMGluIDUuNHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCB3aWR0aD0iNzI0IiBjb2xzcGFuPSIzIiBzdHlsZT0id2lkdGg6NTQzLjBwdDtib3Jk ZXI6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICNDMUMxQzEgMS4wcHQ7cGFkZGluZzowaW4gNS40 cHQgMGluIDUuNHB0Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNzI0IiBzdHlsZT0id2lkdGg6 NTQzLjBwdDtib3JkZXItY29sbGFwc2U6Y29sbGFwc2UiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHdp ZHRoPSI2NjUiIHN0eWxlPSJ3aWR0aDo0OTkuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIwIiBzdHlsZT0id2lk dGg6LjNwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_441F1B8847754303ABCA928BC9800242ciscocom_-- From nobody Wed Jul 14 01:37: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 687E03A18B6; Wed, 14 Jul 2021 01:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 mU5TkJoAjl02; Wed, 14 Jul 2021 01:37:52 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 8E24C3A18B3; Wed, 14 Jul 2021 01:37:46 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id w14so2013035edc.8; Wed, 14 Jul 2021 01:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Mi9461Ak+veUtCulfz/X878ohiUDI43LzTvKNrsYLws=; b=Uxbi3ZdN9ViZGHBzzeneyKZrZ6t49eGh1mG4RZFAE0rwio8zjFAYqeZHJaLv3C/Qtf oQxacBcSsmXRwYql/gxY2bEWlGQ9I6DMhK9ZsH/jk1TZcOIKppGI2faw4mk9u4ivd68C WcSzngF449r03Um3ixzuIbdJPbAcWkeRm6k6CQBCzRoLBa6yIH0tkIwJKt8VtzCfV1KT rsFHmkMPyTBq6oFyxAvFbKps201msRXqILx3M7NX6avMNEuJqNTAi64+w8XixcCTFu2u lLswdtIp6YibH2K+naKplVOhQCKjmFo6kqqnRRKpjtdNbT8YqkW06V6/NVtrffRbAPCU CV+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Mi9461Ak+veUtCulfz/X878ohiUDI43LzTvKNrsYLws=; b=TPmpoFeazvni9WMtMrRYgx7CCgXRrrkm88T16XoaA6Z6QRSndHXsWxkrBUDyJKxrJc q0xmqfkB4kenuHW3O0XeH18X56jlg8Lo0MnAJymhP0N7ZIhCRHMQHgdiCw2psSQbLSJr qANimRa1g516MSPYZ/dFTPamjXUjWuFJORj0HRyv+iAlUiZF4oawfo64dWApqXZEJHDO r4786DmlKIgi/Gy38qRDITMj3OmSoZC7Sm74+Ah2zi8AEyyHszJZb1niz6qhEYb+l3pi 9/NwkRacLL6ttGO2NrTeRlQph2PdI0wpgOkbkMmkltNdNmTXus8PE6lnokFhXZNzPDRB RG7A== X-Gm-Message-State: AOAM532yFEHLXSYxjcEaw8BHcmFAHQ3qwyC1XfgDiMj1N51as93VqJp+ GA7F7w48vbuNsmTNaOXzWlu0xkt+yU/JfuYmvc1uFIL+8zLOHNCs X-Google-Smtp-Source: ABdhPJy/xDp3tyErpNvU/iblXyuMGsds05wgEQUi9jspDZNUL6B6mQOVLLDrz5MffpzvsFxyZOFlmURo5ZsBLUZgZ3c= X-Received: by 2002:a05:6402:100e:: with SMTP id c14mr11920294edu.51.1626251864104; Wed, 14 Jul 2021 01:37:44 -0700 (PDT) MIME-Version: 1.0 From: Christine van Vredendaal Date: Wed, 14 Jul 2021 10:37:33 +0200 Message-ID: To: secdispatch@ietf.org, spasm@ietf.org, saag@ietf.org Content-Type: multipart/alternative; boundary="000000000000ace09005c7114450" Archived-At: Subject: [Secdispatch] Pre-draft QSC Key Serialization and Identification 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: Wed, 14 Jul 2021 08:37:58 -0000 --000000000000ace09005c7114450 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, We (folks from NXP, IBM and Utimaco) have been working on a draft specifying key serializations and OIDs for quantum-safe cryptography to already start to prepare for the upcoming new public-key standard. We shared this with the CFRG for feedback and recommendations and would now also like to share it for the same purpose in this broader community. At the moment this is a pre-draft in the sense that it is not in an IETF format yet, but all the content is there. You can find the link to a comment-only Google Docs version here . The abstract of the document is as follows: With the NIST standardization effort still in full swing, companies implementing post-quantum cryptography now are running into multiple issues, such as: 1. Difficulty in managing algorithm versions and the compatibility of associated keys 2. Difficulty in interoperability testing 3. Difficulty in evaluating the impact of integrating algorithms with higher level standards These difficulties result in delay of many follow-up activities for algorithm integration and adoption. The document `Quantum Safe Key Identification and Serialization=E2=80=99 sp= ecifies the key formats of selected quantum safe algorithms, to hopefully resolve some of these interoperability issues. Additionally it should serve to make choices in future standard clear and prevent delays in adaption. To this end the document contains parameter identifiers for the Round 3 finalist parameter sets (specific OIDs in some cases to be added), as well as key descriptions, byte sizes, and their ASN.1 formatting. Open items that we would consider still adding (opinions are welcome) are the addition of CBOR formats, and the serialization of signatures and ciphertexts. We also note that the current OIDs are not useable or filled in yet. We are investigating adding temporary OIDs, and in the end permanent OIDs should be assigned by NIST upon standardization of a set of algorithms. *(Current) authors: *Dieter Bong (Utimaco), Joppe Bos (NXP), Silvio Dragone (IBM), Basil Hess (IBM), Christopher Meyer (Utimaco), Mike Osborne (IBM), Christine Cloostermans (NXP, f.k.a. van Vredendaal), Karen Willbrand (Utimaco) Looking forward to your thoughts and suggestions, Cheers on behalf of the team, Christine --000000000000ace09005c7114450 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello all,

We (folk= s from NXP, IBM and Utimaco) have been working on a draft specifying key se= rializations and OIDs for quantum-safe cryptography to already start to pre= pare for the upcoming new public-key standard.

We shared this with the CFRG for feedb= ack and recommendations and would now also like to share it for the same pu= rpose in this broader=C2=A0community.


At the moment this is a pre-draft in the sense that it is not i= n an IETF format yet, but all the content is there.
You can find the lin= k to a comment-only Google Docs version=C2=A0here.


The abstract of the document is as follows:


With the NIST standardizat= ion effort still in full swing, companies implementing post-quantum cryptog= raphy now are running into multiple issues, such as:


  1. Difficulty in managin= g algorithm versions and the compatibility of associated keys
    2. D= ifficulty in interoperability testing
  2. Difficulty in evaluating = the impact of integrating algorithms with higher level standards

These difficulties result in delay of many follow-up activities fo= r algorithm integration and adoption.

The document `Quantum Safe Key Identification a= nd Serialization=E2=80=99 specifies the key formats of selected quantum saf= e algorithms, to hopefully resolve some of these interoperability issues.

Additio= nally it should serve to make choices in future standard clear and prevent = delays in adaption.


To this end the document contains parameter identifiers for the Round = 3 finalist parameter sets (specific OIDs in some cases to be added), as wel= l as key descriptions, byte sizes, and their ASN.1 formatting.

Open items that we wou= ld consider still adding (opinions are welcome) are the addition of CBOR fo= rmats, and the serialization of signatures and ciphertexts.

We also note that the cur= rent OIDs are not useable or filled in yet. We are investigating adding tem= porary OIDs, and in the end permanent OIDs should be assigned by NIST upon = standardization of a set of algorithms.


(Current) authors:=C2=A0Dieter Bong (Utimaco), Jop= pe Bos (NXP), Silvio Dragone (IBM), Basil Hess (IBM), Christopher Meyer (Ut= imaco), Mike Osborne (IBM), Christine Cloostermans (NXP,=C2=A0f.k.a. van Vrede= ndaal), = Karen Willbrand (Utimaco)


Looking forward to your thoughts and suggestions,


Cheers on behalf of the te= am,


Christine

--000000000000ace09005c7114450-- From nobody Wed Jul 14 01:54: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 B40EF3A193A for ; Wed, 14 Jul 2021 01:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=forgerock.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 1vAUWlohsz3r for ; Wed, 14 Jul 2021 01:54:42 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 D567C3A1936 for ; Wed, 14 Jul 2021 01:54:41 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id d12so2183621wre.13 for ; Wed, 14 Jul 2021 01:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to:content-transfer-encoding; bh=zoNrXCvlKKxvPZqV3d40d9E1/vIa/d02HElgRYUgd2s=; b=WZ/MHPFA53/myghiHQv6RildF4wSKu7ywFVKiwBufUDwhgHhBhyzNCbS1FejFAO+Yl eP97emHWk1UJULvp7HyFW5aQJQYeXKiLPsmcdyXmHGm2JI6kJNvaFYzxRL1TYONCVy6l v0LWIfihweGYJFt4vxqKh30M5hf4nMgVP73Zg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:content-transfer-encoding; bh=zoNrXCvlKKxvPZqV3d40d9E1/vIa/d02HElgRYUgd2s=; b=HAwGQ79dn7i064lx4WVf6r9EYS6SJr4KT7eqGz6iJeG1KdqYA2jCnzUz+vDEZ7CCLS j/oLgbykTe+ALNWHRdY61xlAqlFpfCMNN25Kgba4nH/UGM16lSIh/AKphBkN3x3EABnt A0suIkB5gPIk36SjVIh/4omS6PnNl/hP4KJBgZTVWhdRgLHx2KyrZR25FvHIrdBi8SbD jo2r8jglc9Zu9XOxE4Punue/zcp7AKXIQY2G/CR5BX8++P3xFeCmaWGMAr/73tH2A5lj VDhrzyuFwR42Sdwfd3Hm1yostRp1v695tFewHr0V7eFVrnF59UXLOmHyieZQjCTWv6vf bseg== X-Gm-Message-State: AOAM5324k4Ey3dMgrLTFpNerd8Ny/9Nw0lML3N6ZziujcAk4IaXQC5dc tSf5Keb3JxrCLkFJy+d96Hc/IUKYZhhaFc8n6KrsOvpH8y15vIJViYzSmY5tgqQHRv66ooddi51 BhwK6EVZxup6vHz6r X-Google-Smtp-Source: ABdhPJxk0vWy2u94fLzt6wPf1up9IBoL/+qQmxGwmLhBwaW2btnWJqj2zz8z7oi05WZeTXJ2lFlaYw== X-Received: by 2002:adf:edd1:: with SMTP id v17mr11109209wro.276.1626252879316; Wed, 14 Jul 2021 01:54:39 -0700 (PDT) Received: from [172.16.130.222] (78-33-22-162.static.enta.net. [78.33.22.162]) by smtp.gmail.com with ESMTPSA id a207sm5405328wme.27.2021.07.14.01.54.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jul 2021 01:54:39 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Neil Madden In-Reply-To: Date: Wed, 14 Jul 2021 09:54:37 +0100 Cc: IETF SecDispatch Message-Id: References: To: Mohit Sethi M X-Mailer: Apple Mail (2.3608.120.23.2.7) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Secdispatch] Call for agenda items - Secdispatch @ IETF 111 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: Wed, 14 Jul 2021 08:54:47 -0000 > On 6 Jul 2021, at 12:33, Mohit Sethi M wrote: >=20 > 3. draft-madden-jose-ecdh-1pu:=20 > https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04=20 Unfortunately I won=E2=80=99t be able to attend this session to present thi= s in person. Is there an alternative way of presenting this work? Or would = IETF 112 in November be the next opportunity? Kind regards, Neil --=20 ForgeRock values your Privacy From nobody Wed Jul 14 02:00:24 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 C27153A195D for ; Wed, 14 Jul 2021 02:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.254 X-Spam-Level: X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Ooh2BldHGxVS for ; Wed, 14 Jul 2021 02:00:15 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2089.outbound.protection.outlook.com [40.107.20.89]) (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 D0E533A195B for ; Wed, 14 Jul 2021 02:00:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nQOegnItHGTe3iqyYQwy2TuxYpXaEkbDgyPdfnz5ANbTOtr5LYQg8ItTME1mEm99OQAhD4ttJW+m98xeR7fJL8otwiNBMb8aH/N2UcIeWqV6qFzqLXHD3a1KF2qUhBIMeZ/IpVq9UVFaPiRryyW4xmrNuNltfbVhqBncr5jHBQlbRi7qjFizTBk8Xl7tgKpbv01RajPKIDl4b9DW8a0ejORhAU7is/dwBC1QzBOGo5qscZJpF+4rTe0p/qsjVJh6x4bH413DGsAXaEoGO1+NljY0vKD3fzMuwFy1gR4kdQMZqFKMSQtVx7rK/pea10/fTyubnZyVzAgriscExhsh/Q== 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=9424M52zO3CiijLJBhsZGAi5zVAgy8pHHZ+xqGXwmTg=; b=l6fyXg5DWgendads8ipwQFE1ntoD++cNbUswMgfA0SVt677b1Tvx4rE6T4WQR3XkFm7HbpnlsG1GBDL3KIK6wGPFFqh35nBPEgOKju7N56yUyA5/gSlxLWHlrkDbo4YIyPH7b5PpE8pZyM1jimaGjRBHreV85YBcaHzmWM8Fp33vSsSAoRNNGrBLc/eNBveoPeA+paVrjwNzHEQZEGeNBDG/km34J/FrH10eyOQCxY+UoopQWotG4HkADHLEhoUiumot/LrGsuRWTKAWaaik1/oa441W0LoUl+l3pZMhKNB1U3ZRl35VQDwkjxasVksqsQVGhS0wXt4c3VBMFOxuag== 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=9424M52zO3CiijLJBhsZGAi5zVAgy8pHHZ+xqGXwmTg=; b=ACTOqozk54fzKGls4GuSeZspXmZQuf1EJ42tYXE5Mx7HnWzV0KSJK7d8k0A7Wq9o39C3D8vS6X9GJAp4DfN0cE9d6AJV/JRliP675o3zEDrR+LWZZtAoVw+LqLQN/Xw+SAGkcNpMe4UwDRc3p2Sxv9829zhFhTJHgqQFLDJP7Z4= Received: from HE1PR07MB3436.eurprd07.prod.outlook.com (2603:10a6:7:37::31) by HE1PR07MB3083.eurprd07.prod.outlook.com (2603:10a6:7:2f::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.17; Wed, 14 Jul 2021 09:00:12 +0000 Received: from HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::c04b:9f4f:3494:b84c]) by HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::c04b:9f4f:3494:b84c%7]) with mapi id 15.20.4331.021; Wed, 14 Jul 2021 09:00:12 +0000 From: Mohit Sethi M To: Neil Madden CC: IETF SecDispatch Thread-Topic: [Secdispatch] Call for agenda items - Secdispatch @ IETF 111 Thread-Index: AQHXclrN+crx2ypfbEeWsOzYQg0TUKtCNwmAgAABj4A= Date: Wed, 14 Jul 2021 09:00:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 authentication-results: forgerock.com; dkim=none (message not signed) header.d=none; forgerock.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0d74aef-06fa-4bf4-8627-08d946a5c9ed x-ms-traffictypediagnostic: HE1PR07MB3083: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wXb+Nql5HdT1RnLZIuSuifRB3emoy/S667laqzxSCbkZV/Sy4iBCeFqvvWvHYmW9dt7tvHWCKJPZD0t4lhMuPchW+ZHm4AvQaUw7QUjQi2sFaDn0fQ133SoXUzLzAiFX6HRp+K1kJD0anjEKQpZPKbM8jqiP6IdrwZC8ZcH9MNbTTdn1Dy7DsM394sR6H2Pfn1jUr9NrE1lJ2MoAOAMu0Ej89PxCyLECm+7p9YUXyyDydNH2ve/AeIS2AWQ0yq4qPtxs3dmuX5395gjfkjkzHOC99PMqNIbDisS5h7vlLDwt1GgbOqkkT+tsHiRiHODGz9PmNOixP7q4EiOA+S7QvS0EhRtxOgBR77MOSqFpkwbNtWVwRq1ukI5/Fa8UxN06i05hmsI9aLoPG4aVg8N8ZUu2FRynbCem39aLliwcBInjl6UuhvO3luJsskQRVGSMytsyP57MlhyCBwSjIUO776A5FJcr0DszsxvmWtmfaJBkdri2LS7Us0qX3nfY12hWJScpCJxH/LFrs3dofYA7sNojKvFy4/dqikuRxey1LwsG84T6prBjiqsL6+1MXxyYGHB0rz0cHnsnA2LLA386x4fmcNO8MTxwnMAhwkGsrVfPBvJmgPABug7/Sz0JmZr3weZ2IvqDzVs96NKHKzQYNcIMOeCx/M+/YYnOO+/z89xE0NY2Cs/o2eScswKcPdn6lKG4ti+SBAXmzCP0qCtU15vgGDPZqi487B2NxM1KMKelI0/1V66G9OP5HLaYMfLxbeOEwjf7ELGU8N7gGe9arLC4J+TJ+h8UAI0gNtOvv4FtxWC8lPYibFimkBVAuewz+OpEAlqKZpzEyZRayyL2fW54OOKdWgNwgJ+vrSfNW7g0vlFVUIvVzbYD8BvjqN40HWtsCndi+cZQalrOKrgECA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3436.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(376002)(346002)(39860400002)(38100700002)(186003)(966005)(4744005)(71200400001)(83380400001)(6486002)(122000001)(2906002)(36756003)(66556008)(53546011)(2616005)(86362001)(8936002)(6916009)(31696002)(478600001)(76116006)(8676002)(66476007)(66446008)(5660300002)(6506007)(4326008)(66946007)(64756008)(6512007)(316002)(31686004)(45980500001)(43740500002)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bUdOZ2k5RDhtZndBM2o4ci9JTWJIZkdLdlU1azRmTkpkWENEKzF4bHY5aGg3?= =?utf-8?B?Qk84eFF5eVF1cnI0VTJ2cXJLRENIeWd2UmFiM1N4VDB3VHpxYk9NMmRCZkVr?= =?utf-8?B?Wjk0ZFhRemFZVVNLRUxVMEtrdHNmb3pRL2gzQXJKVUFoME5IU1B6bFU5L0py?= =?utf-8?B?NjFGYnpFd2xIM28xTDRkamovVjBIVVY2U3NKblFFTGgvRnVVeDJJSXF0TThl?= =?utf-8?B?RHgreWpibzZuSkNYUnNRSjBjMGJpVDRsR3V3NzFiZWhPTmhqWjNmbGc5NXR3?= =?utf-8?B?dCtxYzdYOEsySlY5RFRndGFidXduVFppQ3Nzem4ySHRybDQ3L3NGb1l5cXJx?= =?utf-8?B?RC9KRm5mMjhKaDE4OHJDNW9CQ1gwNGRyYkdIZlFnN2UrYXhRYklTeWRHOWMy?= =?utf-8?B?Q1ZzenFWbmY2UGx4RDlQTVpVZ0NVak5tYTZiZFdmaVJTZWNWb1ZPZ0ZTaFJ3?= =?utf-8?B?TjdNRUg4TTFpWlBSWmoxVW1xYXVTQTRSYisyYW0wS1JDUkJTTGRNNFJxNksz?= =?utf-8?B?UEtjbnVRMzdqanAxTE1xZzIrRlBweG1wdmV6bGdMWFhEMEh5SExDTXQyU2hH?= =?utf-8?B?YURERkJBcDluSHlMM3FEazQ2Wkd6YkR0MUpYR2lHRzhLUytCRi9jSHV5eUlL?= =?utf-8?B?aVhLQ0V1bVEvakFxdEhUMnFES0U5bmlBVTlsbVR1QVJsVEIwSXIzbHFITHVk?= =?utf-8?B?ZHJyNzRKQlVFTkw1azVvcnNBaFRJQm1tY0ttK0ZGVG5Yd0NSWXpsM2Z1NitN?= =?utf-8?B?UVNTTDJVaDhZSVE0SU8zZWg2ZlRidHlNS1JnSnpWT3k0YmpiS3NVbk5OSGlD?= =?utf-8?B?V3pwRWhJWWdJUjNSTUhJUXpDVTJ5M3lQRnFLL3JmRlhZa2x0MmtnNUpIWXNW?= =?utf-8?B?NnQxVGpoK2lCcnptbnIzdWRmWCs0Qm9qMEJ0L3plMWYyZXJYWjVZeEx6aEY4?= =?utf-8?B?QWdlaGxoKzZ3U3NITmJnTUFvT3J4Y0FJTjJBQTNvRkJ4eEZLOVp1NDhRbkkz?= =?utf-8?B?ZUI4NmY0Y3cxRHYvZFZNenZmQ2Y0S0huaytZalRldzNRcWUwVXluSG04U3NT?= =?utf-8?B?OFJpOU9TQk5ZZEtPS2M3cXVGT2VHYVlyRmhiY3NTL3ZiNDh5b0FaeTRMVFFQ?= =?utf-8?B?bExyclZCcGs5a3YrcHViWitMd2owSU9FYlZISG5Xc1hpWG9Da2RWKzlHdi9k?= =?utf-8?B?NWN4d3krSFFBdk9VUW1IVFFSU3ZpSnhoQkEySDZqaVF5a2svSW93YTFZZEdZ?= =?utf-8?B?WWlTMWY5MFlHekQ4blVMYk5YZEVWRTRYd2U4S2FFZzdmSi9weDhTTldJbE5j?= =?utf-8?B?dC8yUGRNYnhzdHhzZHd0LzNPZjJ2em5lcFQrNFMxblEwRHBVWFJ5dGliR0h3?= =?utf-8?B?YjJtVjBSS0cxWEZNVnI3Qy9UcGFOWlFwN3YwN0djQjhCMkwyQzlyUU90U05m?= =?utf-8?B?eW9oMWFkNkxOYnNTM0JQTUg5cmo4aC9TMy8vamRzWCswUFVwRkRsajJXcndV?= =?utf-8?B?NmV3aFRMMFhsZFBDMnI2djd2bHdqampsZ1B1VzUzSTlLV0ZURk0wM1BrV3lz?= =?utf-8?B?Z216Y2xCalFmL2FvOTBWT25LTDkydVdibGhPVTFIQUQ0N1FmKzFxR1pCTGps?= =?utf-8?B?eVA1NTl3QTNteUtJTlVHbXFIZDFKUkYwS1V4dSsvYVRpNTFLK3JlOG5rZHZD?= =?utf-8?B?aW1hNU5yRi9LUUE4cURuR3VWdW5jQlE4cHZRUXpHcGU4SEdwTDQ2R1RrZ29u?= =?utf-8?B?R1lkbFRmZG5lSDNSWWw2T3RjT1ZzTmVUTndIejZhdTI3ejhZM1B6dlp3QXEx?= =?utf-8?B?M2JEOFJRWGJ3eDd4Z0VYc21vS0xlVXI3cFBEQmFsY0JyUnE2ekM3bnNUb1Rw?= =?utf-8?Q?6hXzar5llyEnd?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <6B020DF86668434280F3BB9E5F2420B5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3436.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0d74aef-06fa-4bf4-8627-08d946a5c9ed X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2021 09:00:12.0221 (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: ZhD+8XOKCCfbeeYja5hHNlY3LDYblQyW86uPDPfFMw4xrV59bCiOo6kDBgRRARcFBH3hBbQLvc5pttUPI8hUZv4UCoF03xTE+RR6hBCc9RQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3083 Archived-At: Subject: Re: [Secdispatch] Call for agenda items - Secdispatch @ IETF 111 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: Wed, 14 Jul 2021 09:00:22 -0000 SGkgTmVpbCwNCg0KSUVURiAxMTEgd2lsbCBiZSBvbmxpbmU6IGh0dHBzOi8vd3d3LmlldGYub3Jn L2hvdy9tZWV0aW5ncy8xMTEvLg0KDQpMZXQgdXMga25vdyBpZiB5b3Ugd2lsbCBiZSBhYmxlIHRv IGpvaW4gdXMgdmlydHVhbGx5IGFuZCBwcmVzZW50IHlvdXIgDQpkcmFmdC4gTW9yZSBpbmZvIG9u IGhvdyB0byByZWdpc3RlciBmb3IgdGhlIHZpcnR1YWwgSUVURiBjYW4gYmUgZm91bmQgDQpoZXJl OiBodHRwczovL3JlZ2lzdHJhdGlvbi5pZXRmLm9yZy8xMTEvLg0KDQotLU1vaGl0DQoNCk9uIDcv MTQvMjEgMTE6NTQgQU0sIE5laWwgTWFkZGVuIHdyb3RlOg0KPg0KPj4gT24gNiBKdWwgMjAyMSwg YXQgMTI6MzMsIE1vaGl0IFNldGhpIE0gPG1vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1h cmMuaWV0Zi5vcmc+IHdyb3RlOg0KPj4NCj4+IDMuIGRyYWZ0LW1hZGRlbi1qb3NlLWVjZGgtMXB1 Og0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tYWRkZW4t am9zZS1lY2RoLTFwdS0wNA0KPiBVbmZvcnR1bmF0ZWx5IEkgd29u4oCZdCBiZSBhYmxlIHRvIGF0 dGVuZCB0aGlzIHNlc3Npb24gdG8gcHJlc2VudCB0aGlzIGluIHBlcnNvbi4gSXMgdGhlcmUgYW4g YWx0ZXJuYXRpdmUgd2F5IG9mIHByZXNlbnRpbmcgdGhpcyB3b3JrPyBPciB3b3VsZCBJRVRGIDEx MiBpbiBOb3ZlbWJlciBiZSB0aGUgbmV4dCBvcHBvcnR1bml0eT8NCj4NCj4gS2luZCByZWdhcmRz LA0KPg0KPiBOZWlsDQo+DQo+DQo= From nobody Wed Jul 14 02:05: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 BA9D33A19A9 for ; Wed, 14 Jul 2021 02:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=forgerock.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 Qt1I2veDEKaH for ; Wed, 14 Jul 2021 02:05:21 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 C89E83A19A7 for ; Wed, 14 Jul 2021 02:05:20 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id k4so2256338wrc.8 for ; Wed, 14 Jul 2021 02:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0Ma6x+DUW7UVHP7yUO8wFOrM9DmLal+01SfDDgXvo1s=; b=IMOx+otBgsmsuMbSDM1N/W/P5HgQhjFZmqHwoPLBg0rgf92v3GuJ6axagY+5JGA4mh SNXZzl0BBl9s8D88NgqBorrJYnC96h3I4N+a8nuDEv6vSrNz2lWVYZX7GB8l+QCKT5fo 2UHpWLixRz/g1D0t3Zxoz/+4lvUbnQBv7mF00= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0Ma6x+DUW7UVHP7yUO8wFOrM9DmLal+01SfDDgXvo1s=; b=npFO9m1mDkV4KoFu0uC+veI5TPwHY5hNYeFny2MCXFzNXZFrV0pbIMK9+ZuBJX5cA8 2sqIAK/HzeHAQaeDKLD9phfdYjWA4zt0f8k693muXuaih45mmw8OeuWSTBO9UEMSNyUG wNjx0q3Opl6aJSC7u3CT85NzRXlzizoT2rhXKmPasdQ3y2Sk0vceszvCpPCydkPsMPgw knBPxjvRjQXwp85wQ3pPMHg4yqhi5QKhjCtMuXuDEMteouK9Hcmnms6k6OgLv7GcMHzd Shpc+MtE3n32ySPa+UKDfBvMk8MyTwD3V9mhHxYLg9uMzVGt7Wf4l+sNkPWQXRkcrxqb gzIg== X-Gm-Message-State: AOAM532MXcz7R/PcJ9Lh9ekKDZ+jA/pe8Ob5JvrGZv+2Adrxr5MT+xjO zwBhcu/+q8KOtFACPigyGtGC4JNnQgrxE77G53DN4RGXCrjDv5AO4rfIcmWmaRGNXurnel8hus0 RUjWVS+xy75AqEP7u X-Google-Smtp-Source: ABdhPJxeVF9WOJmz42lMywNEZECxYu2HLa2ZwErLfDH4Anm7c+vypFd9hxUytl3cFJBP5w4TLyhGMQ== X-Received: by 2002:adf:fb05:: with SMTP id c5mr6161832wrr.55.1626253517913; Wed, 14 Jul 2021 02:05:17 -0700 (PDT) Received: from [172.16.130.222] (78-33-22-162.static.enta.net. [78.33.22.162]) by smtp.gmail.com with ESMTPSA id 11sm4660657wmo.10.2021.07.14.02.05.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jul 2021 02:05:17 -0700 (PDT) From: Neil Madden Message-Id: <7800E407-6706-47F2-BF90-C6BAD68EC49B@forgerock.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Wed, 14 Jul 2021 10:05:15 +0100 In-Reply-To: Cc: IETF SecDispatch To: Mohit Sethi M References: X-Mailer: Apple Mail (2.3608.120.23.2.7) Content-Type: multipart/alternative; boundary="Apple-Mail=_8D14C653-DD72-4ABF-8D76-A016E4758A15" Archived-At: Subject: Re: [Secdispatch] Call for agenda items - Secdispatch @ IETF 111 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: Wed, 14 Jul 2021 09:05:26 -0000 --Apple-Mail=_8D14C653-DD72-4ABF-8D76-A016E4758A15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Sorry, that was poor wording on my part - I mean I can=E2=80=99t make the s= ession at all due to other commitments. =E2=80=94 Neil > On 14 Jul 2021, at 10:00, Mohit Sethi M wrot= e: >=20 > =09 > Hi Neil, >=20 > IETF 111 will be online: https://www.ietf.org/how/meetings/111/. >=20 > Let us know if you will be able to join us virtually and present your=20 > draft. More info on how to register for the virtual IETF can be found=20 > here: https://registration.ietf.org/111/. >=20 > --Mohit >=20 > On 7/14/21 11:54 AM, Neil Madden wrote: > > > >> On 6 Jul 2021, at 12:33, Mohit Sethi M wrote: > >> > >> 3. draft-madden-jose-ecdh-1pu: > >> https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04 > > Unfortunately I won=E2=80=99t be able to attend this session to present= this in person. Is there an alternative way of presenting this work? Or wo= uld IETF 112 in November be the next opportunity? > > > > Kind regards, > > > > Neil > > > > --=20 ForgeRock values your Privacy --Apple-Mail=_8D14C653-DD72-4ABF-8D76-A016E4758A15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Sorry, that was poor wordi= ng on my part - I mean I can=E2=80=99t make the session at all due to other= commitments.

=E2=80=94= Neil

On 14 Jul 2021, at 10:00, Mohit Sethi M &= lt;mohit.m.sethi@e= ricsson.com> wrote:


Hi Neil,

IETF 111 will be onli= ne: https://w= ww.ietf.org/how/meetings/111/.

Let us know= if you will be able to join us virtually and present your
d= raft. More info on how to register for the virtual IETF can be found
here: ht= tps://registration.ietf.org/111/.

--Mohit<= br class=3D"">
On 7/14/21 11:54 AM, Neil Madden wrote:
>
>> On 6 Jul 2021, at 12:33, Mohit Sethi M = wrote:
>>
>= > 3. draft-madden-jose-ecdh-1pu:
>> = https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04
> Unfortunately I won=E2=80=99t be able to attend this sessio= n to present this in person. Is there an alternative way of presenting this= work? Or would IETF 112 in November be the next opportunity?
>
> Kind regards,
>
>= ; Neil
>
>


ForgeRock values your Privacy --Apple-Mail=_8D14C653-DD72-4ABF-8D76-A016E4758A15-- From nobody Wed Jul 14 04:42:16 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 E615D3A03FF for ; Wed, 14 Jul 2021 04:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pqshield-com.20150623.gappssmtp.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 0jHPXQEUOlhL for ; Wed, 14 Jul 2021 04:42:01 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 C4F813A0128 for ; Wed, 14 Jul 2021 04:41:53 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id h4so1656028ljo.6 for ; Wed, 14 Jul 2021 04:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqshield-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s2rwPkI1rGjaArzPBYSVknUwJsoNdv1jmNIMWsrBS+c=; b=X04zllDP29KkBehx9IC9R47WoC7lj7Q7imNDykDqh2BA6an3uRA6DTZnEoad5TZ51l 9Wj8L8+a4FTUaM4kYCCPz9eVm4eg63puLSCrr68Ss9iVNi7kTxeJ6BcLQGgHmBOd74TD KipTD7qKm6zsvK3wvcvhcLcGRFtTLaTpG+IegHiZEgMFTk+bFbMbtGpLH7mgu1yAwyT0 d1m42LfNCIScmcDRN/tjVtcjPbQI1wPoatap7k2Ulq3YRQDQjN+wRRGISMySRSFcp7uV A9gzRTBeslI/mjDXFjcDedDOBDJkK0iE5DXGuO8lwiYvSBn+yNE/9TGoh7ELmSo/kCNV o1Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s2rwPkI1rGjaArzPBYSVknUwJsoNdv1jmNIMWsrBS+c=; b=fe6apWy5vTu9S/1Og7kwRHCgYlxKrr9BOj9LvB8pdNxKqL/8ERShVpJdv2Z5Y6Qp0K NCbtZSOGnr9ZQsld5hcpzfAtPkweMoc0MtXlTMU1+BKoTB1FUElI1yNiG1jQvk+i4EEL +3FKPhQEenos4ftl2NXbWdzgsF1FEMXdL+WrT/11GEaeQi083Y3rUpl/08PXx/RLS7Ee k4lop63hTrFZewe6BYs/NqKb8r/H+LgBa0oQXRXhFLiZgi8hIpG+wpCNaox05UFLNKuD 5bqMrZ32A7hUZV+Wc5TnrtScApLZFHzVJMLZ+UYeNS8EuQrMD1bH/Gtz/Na+qRfRA0++ U1eQ== X-Gm-Message-State: AOAM532xcud5DG3xJY4NHzJCanFBWbqTc7AVIwHHgKcr7j0E2p91tcuc G9sRkQTFtpuspL+oCYb7NdJ9VamPg8IfJDXqX8/UOQ== X-Google-Smtp-Source: ABdhPJyjW6nZyroMjZWKjWIYsNMQv7ZEFb5B0QMHJQqFDxa8QBM4RKObGlBM5o/c4HvhuB1gd1bGy76hi5el8+5RGOw= X-Received: by 2002:a05:651c:2c1:: with SMTP id f1mr8896384ljo.128.1626262909881; Wed, 14 Jul 2021 04:41:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Markku-Juhani O. Saarinen" Date: Wed, 14 Jul 2021 12:41:38 +0100 Message-ID: To: Christine van Vredendaal Cc: IETF SecDispatch , SPASM , saag@ietf.org Content-Type: multipart/alternative; boundary="0000000000000e1e3305c713d7a1" Archived-At: Subject: Re: [Secdispatch] [lamps] Pre-draft QSC Key Serialization and Identification 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: Wed, 14 Jul 2021 11:42:14 -0000 --0000000000000e1e3305c713d7a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Some of this commentary is already commented inline in the google doc, but I'll paste it here too for the record. The document proposes OID identifiers for public and private key serialization draft Round3 PQC algorithms, which are likely to change when the NIST standard-writing process. The PQC algorithm specifications and reference implementations already contain serialization methods (that can be used as simple octet strings). The proposal is not using these serialization methods directly (as "octet string blobs" or similar). Suggest including some additional justification for proposing new serialization methods; either efficiency or security. I'd also like to hear comments on the relationship between this proposal and the "RawPublicKey" discussed in the new "KEM-based Authentication for TLS 1.3" draft https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/ Each NIST Submission comes with a set of KAT test vectors that are used to test compliance and also interoperability. Hence we already have de facto serialization methods for these algorithms, which are efficient, and created by the algorithm design teams (and hence have already had years of security testing). We have also used these serialization methods in hardware modules. If ASN.1 type encoding is desired, a transformation tool between the new ASN.1 format and the standard ones should be provided. Additionally, ASN.1 may introduce serious input validation security issues that must be carefully studied. Note that Elliptic Curve Cryptography has largely chosen to go with simplified octet string encodings for implementation security reasons. One could argue that new ASN.1 serialization a step backward in terms of interoperability and also potentially creates unnecessary security risks? The implementation security aspects arise e.g. in the input validation and constant-time encoding and decoding of KEM public keys, which are part of the PQC key exchange process. Cheers, - markku Dr. Markku-Juhani O. Saarinen PQShield, Oxford UK. On Wed, Jul 14, 2021 at 9:38 AM Christine van Vredendaal wrote: > Hello all, > > We (folks from NXP, IBM and Utimaco) have been working on a draft > specifying key serializations and OIDs for quantum-safe cryptography to > already start to prepare for the upcoming new public-key standard. > > We shared this with the CFRG for feedback and recommendations and would > now also like to share it for the same purpose in this broader community. > > > At the moment this is a pre-draft in the sense that it is not in an IETF > format yet, but all the content is there. > You can find the link to a comment-only Google Docs version here > > . > > > The abstract of the document is as follows: > > > With the NIST standardization effort still in full swing, companies > implementing post-quantum cryptography now are running into multiple > issues, such as: > > > > 1. Difficulty in managing algorithm versions and the compatibility of > associated keys > 2. Difficulty in interoperability testing > 3. Difficulty in evaluating the impact of integrating algorithms with > higher level standards > > > These difficulties result in delay of many follow-up activities for > algorithm integration and adoption. > > The document `Quantum Safe Key Identification and Serialization=E2=80=99 = specifies > the key formats of selected quantum safe algorithms, to hopefully resolve > some of these interoperability issues. > > Additionally it should serve to make choices in future standard clear and > prevent delays in adaption. > > > To this end the document contains parameter identifiers for the Round 3 > finalist parameter sets (specific OIDs in some cases to be added), as wel= l > as key descriptions, byte sizes, and their ASN.1 formatting. > > Open items that we would consider still adding (opinions are welcome) are > the addition of CBOR formats, and the serialization of signatures and > ciphertexts. > > We also note that the current OIDs are not useable or filled in yet. We > are investigating adding temporary OIDs, and in the end permanent OIDs > should be assigned by NIST upon standardization of a set of algorithms. > > > *(Current) authors: *Dieter Bong (Utimaco), Joppe Bos (NXP), Silvio > Dragone (IBM), Basil Hess (IBM), Christopher Meyer (Utimaco), Mike Osborn= e > (IBM), Christine Cloostermans (NXP, f.k.a. van Vredendaal), Karen > Willbrand (Utimaco) > > > Looking forward to your thoughts and suggestions, > > > Cheers on behalf of the team, > > > Christine > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --0000000000000e1e3305c713d7a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Some of this commentary = is already commented inline in the google doc, but I'll paste it here t= oo for the record.

The document proposes OID i= dentifiers for public and private key serialization draft Round3 PQC algori= thms, which are likely to change when the NIST standard-writing process.

The PQC algorithm specifications and reference = implementations already contain serialization methods (that can be used as = simple octet strings). The proposal is not using these serialization method= s directly (as "octet string blobs" or similar). Suggest includin= g some additional justification for proposing new serialization methods; ei= ther efficiency or security.

I'd als= o like to hear comments on the relationship between this proposal and the &= quot;RawPublicKey" discussed in the new "KEM-based Authentication= for TLS 1.3" draft

Each NIST Submission comes with a set of KAT test vectors that are used t= o test compliance and also interoperability. Hence we already have de facto= serialization methods for these algorithms, which are efficient, and creat= ed by the algorithm design teams (and hence have already had years of secur= ity testing).=C2=A0 We have also used these serialization methods in hardwa= re modules.

If ASN.1 type encoding is desired, a transformation tool= between the new ASN.1 format and the standard ones should be provided. Add= itionally, ASN.1 may introduce serious input validation security issues tha= t must be carefully studied. Note that Elliptic Curve Cryptography has larg= ely chosen to go with simplified octet string encodings for implementation = security reasons. One could argue that new ASN.1 serialization a step backw= ard in terms of interoperability and also potentially creates unnecessary s= ecurity risks? The implementation security aspects arise e.g. in the input = validation and constant-time encoding and decoding of KEM public keys, whic= h are part of the PQC key exchange process.

Cheers,
=
- markku

Dr. Markku-Juhani O. Saarinen <mjos@pqshield.com> PQShield, Oxford UK.=


On Wed, Jul 14, 2021 at 9:38 AM Christine van Vredend= aal <cvvrede@gmail.com> wrot= e:

Hello all,

We (folks from NXP, IBM and Utimaco) have be= en working on a draft specifying key serializations and OIDs for quantum-sa= fe cryptography to already start to prepare for the upcoming new public-key= standard.

We shared this with the CFRG for feedback and recommendations and would no= w also like to share it for the same purpose in this broader=C2=A0community.


At the moment this is a = pre-draft in the sense that it is not in an IETF format yet, but all the co= ntent is there.
You can find the link to a comment-only Google Docs vers= ion=C2=A0here.


<= /p>

The abstract of t= he document is as follows:


With the NIST standardization effort still in full swing, compa= nies implementing post-quantum cryptography now are running into multiple i= ssues, such as:


  1. Difficulty in managing algorithm versions and the compatib= ility of associated keys
  2. Difficulty in interoperability testing=
  3. Difficulty in evaluating the impact of integrating algorithms = with higher level standards

These difficulties result = in delay of many follow-up activities for algorithm integration and adoptio= n.

The doc= ument `Quantum Safe Key Identification and Serialization=E2=80=99 specifies= the key formats of selected quantum safe algorithms, to hopefully resolve = some of these interoperability issues.

Additionally it should serve to make choic= es in future standard clear and prevent delays in adaption.


To this end the document c= ontains parameter identifiers for the Round 3 finalist parameter sets (spec= ific OIDs in some cases to be added), as well as key descriptions, byte siz= es, and their ASN.1 formatting.

Open items that we would consider still adding (opini= ons are welcome) are the addition of CBOR formats, and the serialization of= signatures and ciphertexts.

We also note that the current OIDs are not useable or fi= lled in yet. We are investigating adding temporary OIDs, and in the end per= manent OIDs should be assigned by NIST upon standardization of a set of alg= orithms.

<= br>

(Cu= rrent) authors:=C2=A0Dieter Bong (Utimaco), Joppe Bos (NXP), Silvio Dragone (IB= M), Basil Hess (IBM), Christopher Meyer (Utimaco), Mike Osborne (IBM), Chri= stine Cloostermans (NXP,=C2=A0f.k.a. van Vredendaal), Karen Willbrand (Utimaco)=

<= span style=3D"font-size:10pt;font-family:Arial,sans-serif">

<= p style=3D"margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Looking forward to yo= ur thoughts and suggestions,


Cheers on behalf of the team,


Christine

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--0000000000000e1e3305c713d7a1-- From nobody Wed Jul 14 08:06:51 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 419FD3A1D6D for ; Wed, 14 Jul 2021 08:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pqshield-com.20150623.gappssmtp.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 FMv68uKrIbE6 for ; Wed, 14 Jul 2021 08:06:36 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 99C473A1D72 for ; Wed, 14 Jul 2021 08:06:35 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id bn5so3503995ljb.10 for ; Wed, 14 Jul 2021 08:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqshield-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V5CoIHU4El/Ru8f6J3cVp1GV7gRx754P8cPIk3QP5wk=; b=cglpmrY68mNBQ6XQYrpVJU9DhjZfSQUAc41rVUiSIKRUARhaDNNaVVhPhfMCgG0ceY 0clef5RJ5cmbFmyxXWzCVlr+CvWBG3DvBHJN6XC30ebcfShjIzfxtGmKgsIeJNvMQRw/ WErCKnST+ENNTblUkvJ3v29oRyx3MsrEWxLzMW4FsbIG4gWhYJYnuNEQT/JJ1hclCVIj WAqKUT+vhuYCGcWRjDTqx1foJ3f98J/X4cQwlRYECapxZNkx6JRdgdYemR19Ic70ihtU OPtVAi4m1Z/aWR9nbg0KXRw84NKuyeBnq5uI4KfQiIWlw5XspTHt0p2Nm4GFNNEGdWkE x2Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V5CoIHU4El/Ru8f6J3cVp1GV7gRx754P8cPIk3QP5wk=; b=CaAE0HfLsWMUNG5PaKUKuuEgC5edU7yY1EIFeh3TeR0xhkdGI/dW64H5VknOinPKsj m+ClaXL7LXTLmpOOg8sqqeSNV4JugHHFWnKv4gVlERvpYAURgQ3oB4Wzz5BqKObzKWpD XEWkX112+9FAe6rmaFSQ94ywdhk7Smxbm6f78rTuDXh/S1UufQRtzXoHMF6P/CU4o2KE AlDvwIiPD+Q/H/YSGdfWx8lCjU1nfygT/Mc2RzbKQyLudmy4bVtTyBWwQeHmNaosd7Fv T+ol2OjByX5cWlvx/96LvY9NXN5Ll1rmtJgBCCBRsQ5Awaj4bDhH7sWQet2kdPUb9SCY G+NA== X-Gm-Message-State: AOAM5311Z6hlPPNv+pehJTKUZZoinfjOl7W0AjHwVd8xWrgBJc8P9V2G L545+2dt5D14AP9mYs8tInGQJCDWAdoRpwyrSFg9oA== X-Google-Smtp-Source: ABdhPJxZzPAi7sDPF9OniBL/VkQUjH1l/C3aY3cM3LkGvGEeORxcz+MN4attcZwMBhuWXmDNByA0JEYgYXCEPzx59HU= X-Received: by 2002:a05:651c:4ca:: with SMTP id e10mr9377526lji.503.1626275191941; Wed, 14 Jul 2021 08:06:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Markku-Juhani O. Saarinen" Date: Wed, 14 Jul 2021 16:06:21 +0100 Message-ID: To: Christine van Vredendaal Cc: IETF SecDispatch , SPASM , saag@ietf.org Content-Type: multipart/alternative; boundary="0000000000001f83dc05c716b366" Archived-At: Subject: Re: [Secdispatch] [lamps] Pre-draft QSC Key Serialization and Identification 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: Wed, 14 Jul 2021 15:06:41 -0000 --0000000000001f83dc05c716b366 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I typed: "The document proposes OID identifiers for public and private key serialization draft Round3 PQC algorithms, which are likely to change when the NIST standard-writing process." trying again! This document proposes OID identifiers for draft Round3 PQC algorithms, together with an ASN.1 public and private key serialization mechanism that diverges from the serialization methods used in the NIST PQC competition. Since the algorithms are likely to change during the NIST standards-writing process, the applicability and lifetime of this document is very limited and it is unknown (and indeed, unlikely) that if it will be compatible with NIST standards. I should add that descriptive detail in the specification is insufficient for interoperable implementation. Hence I was asking for a conversion tool from the serialization format in algorithm specifications and implementations to the proposed ASN.1 format. Cheers, -markku Dr. Markku-Juhani O. Saarinen PQShield, Oxford UK. On Wed, Jul 14, 2021 at 12:41 PM Markku-Juhani O. Saarinen < mjos@pqshield.com> wrote: > Hi, > > Some of this commentary is already commented inline in the google doc, bu= t > I'll paste it here too for the record. > > The document proposes OID identifiers for public and private key > serialization draft Round3 PQC algorithms, which are likely to change whe= n > the NIST standard-writing process. > > The PQC algorithm specifications and reference implementations already > contain serialization methods (that can be used as simple octet strings). > The proposal is not using these serialization methods directly (as "octet > string blobs" or similar). Suggest including some additional justificatio= n > for proposing new serialization methods; either efficiency or security. > > I'd also like to hear comments on the relationship between this proposal > and the "RawPublicKey" discussed in the new "KEM-based Authentication for > TLS 1.3" draft > https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/ > > Each NIST Submission comes with a set of KAT test vectors that are used t= o > test compliance and also interoperability. Hence we already have de facto > serialization methods for these algorithms, which are efficient, and > created by the algorithm design teams (and hence have already had years o= f > security testing). We have also used these serialization methods in > hardware modules. > > If ASN.1 type encoding is desired, a transformation tool between the new > ASN.1 format and the standard ones should be provided. Additionally, ASN.= 1 > may introduce serious input validation security issues that must be > carefully studied. Note that Elliptic Curve Cryptography has largely chos= en > to go with simplified octet string encodings for implementation security > reasons. One could argue that new ASN.1 serialization a step backward in > terms of interoperability and also potentially creates unnecessary securi= ty > risks? The implementation security aspects arise e.g. in the input > validation and constant-time encoding and decoding of KEM public keys, > which are part of the PQC key exchange process. > > Cheers, > - markku > > Dr. Markku-Juhani O. Saarinen PQShield, Oxford UK. > > > On Wed, Jul 14, 2021 at 9:38 AM Christine van Vredendaal < > cvvrede@gmail.com> wrote: > >> Hello all, >> >> We (folks from NXP, IBM and Utimaco) have been working on a draft >> specifying key serializations and OIDs for quantum-safe cryptography to >> already start to prepare for the upcoming new public-key standard. >> >> We shared this with the CFRG for feedback and recommendations and would >> now also like to share it for the same purpose in this broader community= . >> >> >> At the moment this is a pre-draft in the sense that it is not in an IETF >> format yet, but all the content is there. >> You can find the link to a comment-only Google Docs version here >> >> . >> >> >> The abstract of the document is as follows: >> >> >> With the NIST standardization effort still in full swing, companies >> implementing post-quantum cryptography now are running into multiple >> issues, such as: >> >> >> >> 1. Difficulty in managing algorithm versions and the compatibility of >> associated keys >> 2. Difficulty in interoperability testing >> 3. Difficulty in evaluating the impact of integrating algorithms with >> higher level standards >> >> >> These difficulties result in delay of many follow-up activities for >> algorithm integration and adoption. >> >> The document `Quantum Safe Key Identification and Serialization=E2=80=99 >> specifies the key formats of selected quantum safe algorithms, to hopefu= lly >> resolve some of these interoperability issues. >> >> Additionally it should serve to make choices in future standard clear an= d >> prevent delays in adaption. >> >> >> To this end the document contains parameter identifiers for the Round 3 >> finalist parameter sets (specific OIDs in some cases to be added), as we= ll >> as key descriptions, byte sizes, and their ASN.1 formatting. >> >> Open items that we would consider still adding (opinions are welcome) ar= e >> the addition of CBOR formats, and the serialization of signatures and >> ciphertexts. >> >> We also note that the current OIDs are not useable or filled in yet. We >> are investigating adding temporary OIDs, and in the end permanent OIDs >> should be assigned by NIST upon standardization of a set of algorithms. >> >> >> *(Current) authors: *Dieter Bong (Utimaco), Joppe Bos (NXP), Silvio >> Dragone (IBM), Basil Hess (IBM), Christopher Meyer (Utimaco), Mike Osbor= ne >> (IBM), Christine Cloostermans (NXP, f.k.a. van Vredendaal), Karen >> Willbrand (Utimaco) >> >> >> Looking forward to your thoughts and suggestions, >> >> >> Cheers on behalf of the team, >> >> >> Christine >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> > --0000000000001f83dc05c716b366 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I typed:

&q= uot;The document proposes OID identifiers for public and private key serialization draft Round3 PQC algorithms, which are likely to change when the NIST standard-writing process."

trying again!

This document proposes OI= D identifiers for draft Round3 PQC algorithms, together with an ASN.1 publi= c and private key serialization mechanism that diverges from the serializat= ion methods used in the NIST PQC competition. Since the algorithms are like= ly to change during the NIST standards-writing process, the applicability a= nd lifetime of this document is very limited and it is unknown (and indeed,= unlikely) that if it will be compatible with NIST standards.
I should add that descriptive detail in the specification is in= sufficient for interoperable implementation. Hence I was asking for a conve= rsion tool from the serialization format in algorithm specifications and im= plementations to the proposed ASN.1 format.

C= heers,
-markku

Dr. M= arkku-Juhani O. Saarinen <mjos@pqshield.com> PQShield, Oxford UK.

On Wed, Jul 14, 2021 at 12:41 PM Markku-Juhani O. Saarinen <mjos@pqshield.com> wrote:
Hi,
=

Some of this commentary is already commented inline in = the google doc, but I'll paste it here too for the record.

The document proposes OID identifiers for public and priva= te key serialization draft Round3 PQC algorithms, which are likely to chang= e when the NIST standard-writing process.

The= PQC algorithm specifications and reference implementations already contain= serialization methods (that can be used as simple octet strings). The prop= osal is not using these serialization methods directly (as "octet stri= ng blobs" or similar). Suggest including some additional justification= for proposing new serialization methods; either efficiency or security.

I'd also like to hear comments on the = relationship between this proposal and the "RawPublicKey" discuss= ed in the new "KEM-based Authentication for TLS 1.3" draft

Each NIST S= ubmission comes with a set of KAT test vectors that are used to test compli= ance and also interoperability. Hence we already have de facto serializatio= n methods for these algorithms, which are efficient, and created by the alg= orithm design teams (and hence have already had years of security testing).= =C2=A0 We have also used these serialization methods in hardware modules.
If ASN.1 type encoding is desired, a transformation tool between the = new ASN.1 format and the standard ones should be provided. Additionally, AS= N.1 may introduce serious input validation security issues that must be car= efully studied. Note that Elliptic Curve Cryptography has largely chosen to= go with simplified octet string encodings for implementation security reas= ons. One could argue that new ASN.1 serialization a step backward in terms = of interoperability and also potentially creates unnecessary security risks= ? The implementation security aspects arise e.g. in the input validation an= d constant-time encoding and decoding of KEM public keys, which are part of= the PQC key exchange process.

Cheers,
- markku=

<= div dir=3D"ltr">Dr. Markku-Juhani O. Saarinen <mjos@pqshield.com> PQShield, Oxford UK= .


On Wed, Jul 14, 2021 at 9:38 AM Christine van Vreden= daal <cvvrede@gma= il.com> wrote:

Hello all,

We (folks from NXP, IBM and Utimaco) have be= en working on a draft specifying key serializations and OIDs for quantum-sa= fe cryptography to already start to prepare for the upcoming new public-key= standard.

We shared this with the CFRG for feedback and recommendations and would no= w also like to share it for the same purpose in this broader=C2=A0community.


At the moment this is a = pre-draft in the sense that it is not in an IETF format yet, but all the co= ntent is there.
You can find the link to a comment-only Google Docs vers= ion=C2=A0here.


<= /p>

The abstract of t= he document is as follows:


With the NIST standardization effort still in full swing, compa= nies implementing post-quantum cryptography now are running into multiple i= ssues, such as:


  1. Difficulty in managing algorithm versions and the compatib= ility of associated keys
  2. Difficulty in interoperability testing=
  3. Difficulty in evaluating the impact of integrating algorithms = with higher level standards

These difficulties result = in delay of many follow-up activities for algorithm integration and adoptio= n.

The doc= ument `Quantum Safe Key Identification and Serialization=E2=80=99 specifies= the key formats of selected quantum safe algorithms, to hopefully resolve = some of these interoperability issues.

Additionally it should serve to make choic= es in future standard clear and prevent delays in adaption.


To this end the document c= ontains parameter identifiers for the Round 3 finalist parameter sets (spec= ific OIDs in some cases to be added), as well as key descriptions, byte siz= es, and their ASN.1 formatting.

Open items that we would consider still adding (opini= ons are welcome) are the addition of CBOR formats, and the serialization of= signatures and ciphertexts.

We also note that the current OIDs are not useable or fi= lled in yet. We are investigating adding temporary OIDs, and in the end per= manent OIDs should be assigned by NIST upon standardization of a set of alg= orithms.

<= br>

(Cu= rrent) authors:=C2=A0Dieter Bong (Utimaco), Joppe Bos (NXP), Silvio Dragone (IB= M), Basil Hess (IBM), Christopher Meyer (Utimaco), Mike Osborne (IBM), Chri= stine Cloostermans (NXP,=C2=A0f.k.a. van Vredendaal), Karen Willbrand (Utimaco)=

<= span style=3D"font-size:10pt;font-family:Arial,sans-serif">

<= p style=3D"margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Looking forward to yo= ur thoughts and suggestions,


Cheers on behalf of the team,


Christine

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--0000000000001f83dc05c716b366-- From nobody Thu Jul 15 02:57:41 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 5A6C13A250D for ; Thu, 15 Jul 2021 02:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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 7itEgMnduf39 for ; Thu, 15 Jul 2021 02:57:35 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60088.outbound.protection.outlook.com [40.107.6.88]) (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 EF43E3A250B for ; Thu, 15 Jul 2021 02:57:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FBLMNPsbwq2nhoXLwDQeAu3HqPldvxgP9FmcKbMcbaw1n9ooZ9O2O63upUTtPo3PPcItKYdvUWsxJNkAoiwtdfeRFikczWJztK5nvjHArjyWmD3b/zis0WlQk84i9UgQuGHtrxd2G1pkD1MyA8kvYrRZ36QsBMzv/rcSlOX9otuybD6xiaeOXYXpqYaG157Djf/7jb/+jNgSftHLL6KRpnw6lZVReb5d3q4RTuQy2z+B5PRHz2VWXuEkcb4nWQnysd+IbvCqzRuPBo+o1X2iDnRXpbZPlUkUM2QjvQkGXVTGyaGvgWieOl3J3mUDfIk6m+KQilAv7H3EDaH677Y0Ng== 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=AWatde7MNrx7m2F3q3U8N90JTTljheVRFmrwszpfh+w=; b=Vk3KIVgMTxwHH4aGXcmQEdzw/X9aAiUgmRME8iytxIwREXJrGzfCTlnq/slFDlEKxUEdrJ669weUYh7BEkw+/Y03qPul4a5gfFreDkSC+r4cAMT6bzOcWrMiL7x9Phd77Zt3DeBerqdPBgHgKPgd5kNQkJ6BclPdlePU5XKDCWg9xV9S19JDCez8BMtvrGe543Tyl51Kp3wH2KhRLRFn5D3EEqZDvXQmB1SzUzr7urSikwjwTL3+0PgmlbzdvNyqBZVT93DFyYydOvZo7UoE8Xncvefcg+IrF53bJP/RLiLOOPDRnrwe8BI6NkrCwxmtyWPZINW7+WWDoLdWXohaOg== 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=AWatde7MNrx7m2F3q3U8N90JTTljheVRFmrwszpfh+w=; b=WWpYmMFW0xeTb0Bv4FJSAVtA4yTvv7l/cIcy4lOxsr8KKQaVZlu5/lshZHNkiwZQ9LANfuy8SEPbYrFWrAiwP/KMYo/6280WkYXuYcsBXRwckzV5nRO06cs8Jbpzst6ElLckdmw3tlqADDSen8boyJW+hh0DB11atLHs01OOwJc= Received: from HE1PR07MB3436.eurprd07.prod.outlook.com (2603:10a6:7:37::31) by HE1PR07MB3193.eurprd07.prod.outlook.com (2603:10a6:7:35::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.14; Thu, 15 Jul 2021 09:57:32 +0000 Received: from HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::c04b:9f4f:3494:b84c]) by HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::c04b:9f4f:3494:b84c%7]) with mapi id 15.20.4331.024; Thu, 15 Jul 2021 09:57:32 +0000 From: Mohit Sethi M To: IETF SecDispatch Thread-Topic: Preliminary agenda online Thread-Index: AQHXeV/URgqJeEzfwkGN/MMrkyIVPw== Date: Thu, 15 Jul 2021 09:57:32 +0000 Message-ID: <9218ba42-1a81-8a82-4850-be3ca57f2894@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bdda6e85-1412-482e-8f85-08d94776f703 x-ms-traffictypediagnostic: HE1PR07MB3193: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: i7kU8YxnNoaZkLGR8E86N7mYoQQTMlB3UmaFASJXhxIJgPw96Ct7NVrTVt5cV/UsMctLbnYNwnTi/sGIwU7xZC9u74ZYHMQGlIWpo03ip7HApdWvWnxLy3UW56Kz4ajImc2W4wugBp8H4cOU5TywwE0x6hGY487WaJZYrDXKSbL8NtjI42VQHA6xPjxJfFrn59pHnfktuzpKP//jMS12yD5MkrWxF+USNMkE7uMRXb9rFwAqhBqulU12DH76nPCBAOPzXVxd7Cm41fahJ64KYZCWwaLZGEdraAlwUOP94fNqdnzUjMGbWV4/GuTh1lKcHfxv5qD+8dp53unrqJLkeRKFB9iQ8gpjT0f5kR6jGdWTRO0KVTI8+phnPYK4qSlkhGmqK4UQe+Pqc9M21RHTIVuCjHKuwLSWX+w4KqG2PI57lHvKrwraUfDt5jFHt9rqPiT9ukyWFZkZfMbtWki3glLj0I+BEzsyfnzkL6bTeSyBCk7fhJS2QYvIpin+FNa52nmKauvnki1bdK2nG+sQzpqTvl0/GViYOEnkWlVNnPqZTNyFvTo9Db3gTt0VjgyAGzK1nmLvucnPNUwJc/AurmqtXdj41aM/dQljF5ln6PTtz56hLMfLhge3tJUfoGIcrrCOEeQwxRRHRYtV4vm6U8qXoa+zVkUOHFDYgEPM6zUjnAdGY2aVX1Y/UCmzkWJbIgEvVc8KMPR0WGnmk1+bPZuQoRH8WCH9TTCHLAtuWPBe4KpDLaEnVOgsZL4BrvxJ2nQWvRjYzRxL7wjLu55+J59eBSHVbmDEewEHt0jfP76AbvgiPFPm72IZXwc+fAr3ul+Cv3FYEPaHs+EiHMBsFzWAQbuhc7x4tuJLR/x/9Ew= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3436.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(186003)(64756008)(76116006)(83380400001)(66556008)(2906002)(86362001)(66946007)(66446008)(38100700002)(5660300002)(36756003)(3480700007)(71200400001)(478600001)(31696002)(6486002)(66476007)(4744005)(6512007)(966005)(8936002)(2616005)(31686004)(8676002)(7116003)(6506007)(316002)(6916009)(122000001)(45980500001)(38070700004)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QWp6a3RhdHllS1FtZnJnY1RzbDgrU3JTMWlTRElJdjVFNkdWVzgrN25PRGpL?= =?utf-8?B?S1QrYlRRMHpDNk5vM1FGSzhkY2tTR3lUWUpMQXpoQnczUmo2L2xFcmo0QytC?= =?utf-8?B?RkFtTkVsYXdXSURCQytJbzlNVlNTTE4reTVxaFFhMHBmQVMzZ0R6emo0cWJH?= =?utf-8?B?NDZ4ejVFRWxNSnlUbnNtcG05OHZwMWpUN2Q0elJJZWpFanNyTElWbk0xTzN2?= =?utf-8?B?MGxGeGRFaFVDNTIwRVRSWndtOFBET01Sc0lWcGZocEVRWVRsbjRBMmdkT1Yv?= =?utf-8?B?Wm5KdW5yMFZDckZIWnkxMHp3NmwraFFJdG9mLzZrMGk1WDdOcXdQSEwzcnE4?= =?utf-8?B?UFI4QUVSZ1k2SHpEaXZ2MGdpcXp2Rkl3cXFib04ybDJmU1hKMzh6WDFjVEpu?= =?utf-8?B?ektYY01Da3BKQkVQbkZwaUN6dEVadU1sOWIreGVRazkva1E1UnJORlZweExV?= =?utf-8?B?eXdKZ3p3ZmtVa0t4RU1FN3BnSWdTWVJxTE1zNTJCWisyYlFDa1B1Vktuc0tD?= =?utf-8?B?TW1mNkc2bFdqaFRxMFYrZVBUNGl2S1kveE9NOHprSGdjR1c0YmVlbzhCUnRS?= =?utf-8?B?RzkzOGt4Vk1tV29KZVdzeEo0d0FSYVgrTjZqcmRodk5FNkVhR1ZnSFE2SHgz?= =?utf-8?B?VjNKa0FzSm92VlVURHBDRnN2Y0N2SW42S3lBN3B1aDdXWDF5cDhLdlNpcm0v?= =?utf-8?B?U0ZwbTJsQWJnaW1nZWVOLzNFR2p3NXk5d3dKNnZlRUxxbmY0QUhQbnArdGNh?= =?utf-8?B?TFBod2dZU0ZSdzNFbW8ycmdBRE0xeXAybE05RzFNd2toSS9PMVRjVnBmd2to?= =?utf-8?B?OG9rT2NtWW9NZ0tGRVhZM1o0aFYzalY4MEhXY1ZnZlBRUDlhSU9BSTFNMjND?= =?utf-8?B?S0xzMFhJWFVPZzhjamdjbkJOSCtWK09UeVpZTmlXNW9KUG54akVtVjl0REtC?= =?utf-8?B?OHdBTnVpN0NGY0VXaU9wRTdjLzBPNnBMM09BUUtnQmZVbkpRT0NpVVl0UnBy?= =?utf-8?B?UFVmL0dacEFORmRCbXB3YnEzU2t0RURsSllpUU9KWkF3aEtIZWpncVcxd25h?= =?utf-8?B?WGtNdVNrRTBIZHFFN0ZIWDJhdU1EUEg0NTZQNzR6czJvOWpzRTF4ai9ReUdZ?= =?utf-8?B?ek5oMkNESEEreTZXVkxOTUU1YXkzeEpSVVVkSnhINS9VSDNuQTlZdy9jKzAx?= =?utf-8?B?a1EvU2YyL21OdmtZMS9VaVczbm9lTjNJenVoVS9SY3hOZHQyR2NtTll5YlNZ?= =?utf-8?B?S1B0bHlhVm44UEs2enQ2WDlvVEIva1dZYm5qUC9wem9CU21QNmU5OG1RMFRk?= =?utf-8?B?aUZpQ2FIdFAxZlF6VTJRZS9ZV3I5SDMyUG1kejlVaXl6c1N0RXdJTzFXc1FB?= =?utf-8?B?UGV4YTlBajFHNVJleDhJZkJQOVBKNU82WTVDUzR5ZTNOb0tyenFSQWtLcVo0?= =?utf-8?B?Y1M3YURDdFJvTlZyQ2J6QXNjbFNkWXBlYVlmMzh5a3piWFN4dlVaS0lKSWxO?= =?utf-8?B?MU1TaWtBbkpoVW1KVUgwbXc0Yzl1V1FCeTVPNmFTT1JpMEJra1grWndrQ1Nx?= =?utf-8?B?VEZMRG1MZGlqOENiazhEZ3Fhd1ZPaUR3a0I2aEpneFVxZ1hQL0cwOEFSbWNU?= =?utf-8?B?NFF4R2xyMjZNVVQrRjVsZC9mU1VQTkk0TmhFWURWRUNwZTdtTmc0a3d1U01G?= =?utf-8?B?NVdnUUJuTnhhQWhKU2NnNlN3Y2xQUHRZbGUxR1k4SFB5U25KY1JsZmtMdEho?= =?utf-8?B?T0o1VllxR25DalkzUllPQ0JhVERMRERJSmZkMG9kcVQxSGVQb3lUS1VQN0VN?= =?utf-8?B?Q2ppaU5ZT0VFaHlyQ1FJeDdLSHJUZ3hkUHZhS21vQ2d6ekZsTEtzZ1VBcUJ5?= =?utf-8?Q?9BIBJus1SnIcR?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <37063152A29EA349B6AB8F2327D85556@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3436.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bdda6e85-1412-482e-8f85-08d94776f703 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2021 09:57:32.4325 (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: QSep1BSvHBGk+02le5LWnPeFbrwgNxnjrgcOuR4nxzFSOHJyKbefDNtFmkxzxWwvjhDYos0m5Gohm9NhqY/N7SWXRiUpdL4iklcK7o1MFXs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3193 Archived-At: Subject: [Secdispatch] Preliminary agenda online 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, 15 Jul 2021 09:57:40 -0000 RGVhciBhbGwsDQoNClRoZSBwcmVsaW1pbmFyeSBhZ2VuZGEgZm9yIFNlY2Rpc3BhdGNoIEAgSUVU RiAxMTEgaXMgYXZhaWxhYmxlIG9ubGluZTogDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L21lZXRpbmcvMTExL21hdGVyaWFscy9hZ2VuZGEtMTExLXNlY2Rpc3BhdGNoDQoNCkxldCB1cyBr bm93IGlmIHlvdSBub3RpY2UgYW55IGRpc2NyZXBhbmNpZXMuDQoNCkBwcmVzZW50ZXJzL2F1dGhv cnM6IHBsZWFzZSBzZW5kIHlvdXIgc2xpZGVzIHRvIA0Kc2VjZGlzcGF0Y2gtY2hhaXJzQGlldGYu b3JnIGVhcmx5IGVub3VnaC4NCg0KS2F0aGxlZW4sIFJpY2hhcmQsIGFuZCBNb2hpdA0KDQo= From nobody Wed Jul 21 08:16:25 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 EF2843A1B73 for ; Wed, 21 Jul 2021 08:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 SWytIi9mM9v1 for ; Wed, 21 Jul 2021 08:16:00 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 B1BC23A1B7F for ; Wed, 21 Jul 2021 08:15:57 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id a10so1079888qvj.11 for ; Wed, 21 Jul 2021 08:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=tFRH0wohT+Zx3XC7IgSuI3UjZ3/AVKNkgOptlYp/7Ro=; b=ppBnWo/fbshAw4iJLTP6uCbgueg8SKyfVndMbddIr6FEez5r2mYmjNFw+CEzD2awfp iQIC8y09VIUNLcCufosVL86Fg4TERSLpwR1j5RQEa4RmnbFDLl2DinNgW/vrzrfazyOw Tu3D8WA3RMNe6J96qx6hvV6v8KDhCYJPaQsrRriIpx9kvo5bQ4lJSVsen5MWlNtoAWGu SXXOmZtV70dTrhFuFm1RTXMmnadzYPvmkI/QsKA6fWxVn2GXlhbJDhwofb92vuW3pwmq YFWIBndtbd+pPGquQQghdTIZk2ptpugnCrDcGZbN+od2lTJX4/gP3nfTzqZMY1kS0TPj UsqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=tFRH0wohT+Zx3XC7IgSuI3UjZ3/AVKNkgOptlYp/7Ro=; b=gipm6aqn6xQMumwsYHZx1v8aOiE78IFv2lhGof2XDJySi0EtnKmX5L1qJojU4i5tLs DZaMZL51mXn/390Gi2AiMt3Hw6aKh7SmPv/2sUXjvL6CasRWzKMNZq9MswkZdYe0RrL4 XLpu2rjiaGEp13z7FWrjOXPY4bEpzQNkZWihPjrK7EhYdfEopOaXTpzh0xOZGd4KDZn3 HKhN0pWD3K9hTSpqbkdHr6Bqar58NKE6y8l0Re0Zu9Yvvm49QUre5O78qJKAIaiByFjG DQNsIgffr5I/gI/hhbMtaIITGq+PyRncOt2Vtai3RzQo6a0BkCLSNY8R22oVfQPtJt6T JAIQ== X-Gm-Message-State: AOAM533V49UjTUW59O4/hZF0r14uylp0mGqoYI1DTmH7Gduq0rlGDoxq JsUOd2hwaT4vYtxCroNGpvsR9I2ybCk= X-Google-Smtp-Source: ABdhPJw0Ld1flUGaPatG8VRUrQvPkbjkiCyPRyQznab5BeSD7bix74S4ULJKMcPmhTyst8Dz69vpxw== X-Received: by 2002:ad4:4ae5:: with SMTP id cp5mr36231997qvb.38.1626880555762; Wed, 21 Jul 2021 08:15:55 -0700 (PDT) Received: from ?IPv6:2607:fea8:8a0:1397:f15e:13a1:2292:bf67? ([2607:fea8:8a0:1397:f15e:13a1:2292:bf67]) by smtp.gmail.com with ESMTPSA id x14sm3855002qts.13.2021.07.21.08.15.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jul 2021 08:15:55 -0700 (PDT) To: Mohit Sethi M , IETF SecDispatch References: <9218ba42-1a81-8a82-4850-be3ca57f2894@ericsson.com> From: Rene Struik Message-ID: <919f0c47-c5ab-6bfa-48a0-93a7b2f0856b@gmail.com> Date: Wed, 21 Jul 2021 11:15:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <9218ba42-1a81-8a82-4850-be3ca57f2894@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Secdispatch] Preliminary agenda online 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: Wed, 21 Jul 2021 15:16:05 -0000 Hi Mohit: I would like to discuss=20 https://datatracker.ietf.org/doc/draft-struik-secdispatch-verify-friendly= -ecdsa/=20 This draft discusses representation of ECDSA signatures that allow fast=20 single verification and batch verification and which is consistent with=20 ordinary ECDSA signatures for prime-order curves (such as with NIST=20 prime curves, Brainpool curves, secp256k1). To enable verifiers to reap=20 these benefits one simply needs a flag (code point, #) to indicate ECDSA = signatures have been put into this verification-friendly format. The=20 representation change can be made by any device, not just the signer,=20 and can thereby be made retroactively (without need for new signature). This draft does not deal with new crypto, only whipped-up=20 representations: it simply uses the well-known fact that if (r,s) is a=20 valid ECDSA signature, then so is (r,-s), to effectuate this switch=20 under certain conditions. Batch verification speed-ups (up to ~6x) have been known since the 90s;=20 single verification speed-ups (~1.3-1.4x) for at least 16 1/2 years. Intention is that IETF could (perhaps: should) use this across the=20 board, so as to reap benefits for verification devices that wish to do=20 so (one can still use slower techniques if one does not wish to change). = To realize this, one simply needs a brief description and registration=20 of flags to indicate this. {In other words, this could be a very short=20 project to get to wide-scale use. The current draft contains most info=20 already.} History with IETF: I discussed this with lamps at IETF-110 [1], but=20 despite positive feedback (from, e.g., Scott Fluhrer) lamps did not=20 include this with their recent re-charter yet. The simple technique is=20 broader than just lamps, though, and should be beneficial for any=20 deployment (certificate transparency, openpgp, pkix, etc.). This being=20 said, perhaps lamps would be a good starting point. Best regards, Rene Ref: [1]=20 https://datatracker.ietf.org/meeting/110/materials/slides-110-lamps-verif= ication-friendly-ecdsa-00=20 [2]=20 https://datatracker.ietf.org/meeting/110/materials/minutes-110-lamps-01.p= df On 2021-07-15 5:57 a.m., Mohit Sethi M wrote: > Dear all, > > The preliminary agenda for Secdispatch @ IETF 111 is available online: > https://datatracker.ietf.org/meeting/111/materials/agenda-111-secdispat= ch > > Let us know if you notice any discrepancies. > > @presenters/authors: please send your slides to > secdispatch-chairs@ietf.org early enough. > > Kathleen, Richard, and Mohit > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch --=20 email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 From nobody Mon Jul 26 07:40:40 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 F1A263A168D; Mon, 26 Jul 2021 07:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 kAP0Am3Nq4Vk; Mon, 26 Jul 2021 07:40:32 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (smtp.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A83A3A168B; Mon, 26 Jul 2021 07:40:32 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GYMzL23lvz2xLr; Mon, 26 Jul 2021 16:40:30 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 649003229.8576519-4d08c7421958c0521437717dc01c3458 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Mon, 26 Jul 2021 16:40:29 +0200 Message-Id: To: dispatch@ietf.org, secdispatch@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [Secdispatch] draft-jordan-jws-ct 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: Mon, 26 Jul 2021 14:40:35 -0000 I would have said the below on the microphone later today, but IOTOPS has been moved on top of SECDISPATCH, so I need to make my point on the list(s). As many of you know, I don=E2=80=99t care much about the mechanism = proposed, but then I=E2=80=99m not here to protect your feet from shotgun wounds. However, I am strongly opposed against labeling a proposed mechanism in a way that is misleading about its main characteristics. There is nothing, *absolutely nothing* "clear text" about extracting data from a JSON data model level input with an unspecified extraction mechanism(*), re-encoding and processing this into a (hopefully) deterministic(**) signing input, and then signing that with JWS (which at least is a standards-track specification). The latter employs base64 encoding, so it is even less "clear-text" than the essence described above would leave possible (RFC 7797, the only thing that might be called "clear-text" here, is explicitly excluded). I have already made this point repeatedly to the authors; this has been ignored. I'm therefore not very optimistic about the future veracity of claims about this effort. I have no interest in attempting to block this effort, but I would ask that we at least institute some language policing here. Gr=C3=BC=C3=9Fe, Carsten (*) The infamous `Transforms` in XMLDsig was at least specified. (**) Which, to increase the insult, requires a detour via UTF-16 input to create the deterministic signing input, cleartext ** *** (to paraphrase a well-known Apple executive). From nobody Mon Jul 26 09:28: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 B14603A1DDB for ; Mon, 26 Jul 2021 09:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 lnTbfzNCZmKi for ; Mon, 26 Jul 2021 09:28:41 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 AE2F73A1DD7 for ; Mon, 26 Jul 2021 09:28:11 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id y4so9566100ilp.0 for ; Mon, 26 Jul 2021 09:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=oTcDe4YxAwME2ZG8nE5Sg+BXd1M9bWbT+kQsU+P6rZ0=; b=PCpnd1yWbBRUiZxIxHVWF/yHw2MuLhyaCsO6/kLIZ0czzBfcLM1YPmYI+HYi3WgJnS FQ6Tuh5Jzn4xYx3Qz40Xx41C7vMZPG9pDOTIdt4FVbRYBWOo5gcFzLaBjt58+/NzpMiw d0t5iTH7Xx401tS+quuEdGnR+/ys25vzf21sT0NgIGgP/ppvU8hL3mvwMBdG4hkCIUTO /QVg3Vjz5IFQbPgaVBxEntPi1qAo4a2R/ARLrqRxt5qhHCJgQmEiQaaVBMz7uv77Y7UU hyWIBfc7RjXs/UZztpPdTNKMM7s9qaoxgES46GASo07Rph6ZT8Rz5R82waTWIIVCMxq3 ZZyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oTcDe4YxAwME2ZG8nE5Sg+BXd1M9bWbT+kQsU+P6rZ0=; b=N4lMTCuVzNoOYk4WFBCNVNVtij4nd0Xv4sRXHNkGWY3TxUzHkSAo9LYFIAuMhIwGtL g/tClx1l5FjUdiLiOcG960yRHrKBx/4OAW4NKX9eLgKvIhgugAa35dS5DiJhvRE3MTyo 0iBN6fXCWUKw372JADKJY4vCXKOasnEOYWU3RhPDPKieAk3JIzMjCLnHNIAWST5i+rKq 8NJePTzVXfHv9BZ6QHpz9elj1zHfJ6HI4Uj5ml8S0/WVxaymBbY8EQPGp6xhr/zlz0/T fPEvQpZ+K14fVKS5WLEWERqTZR1WShKSJFa0gQ1MlDu2JmfGWxsViz+rORgtyjolnVy9 Gmkg== X-Gm-Message-State: AOAM533lekdFLa2eQfXBI4fACsds52f2bwSD6iIoBiY7OgafpnGvFBsL +iKtq2DqzxhvVv7xWyHBtVEi5I+stT6qZMFbuqooByWF+2wOYoIz X-Google-Smtp-Source: ABdhPJyL+px1Y+Y+lr9iwTqVG8CJxR0ATpf8n/l9JWjvYn7nKdsdLfp2yXMbAUeE0qKM74hylVDhPCnO71O/NcEm7ro= X-Received: by 2002:a05:6e02:13d3:: with SMTP id v19mr14006182ilj.167.1627316890105; Mon, 26 Jul 2021 09:28:10 -0700 (PDT) MIME-Version: 1.0 From: Eric Rescorla Date: Mon, 26 Jul 2021 09:27:33 -0700 Message-ID: To: IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000002c0c8005c8093d16" Archived-At: Subject: [Secdispatch] Comments on draft-jordan-jws-ct-04.txt 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: Mon, 26 Jul 2021 16:28:46 -0000 --0000000000002c0c8005c8093d16 Content-Type: text/plain; charset="UTF-8" I took a quick look at this document and I continue to have the same concerns about the overall approach I had previously, namely that having allegedly signed data available in the "clear" is not in fact a feature because we want people to validate the signature before accessing the data and the validation process can then emit the validated signed data. For these reasons, I do not believe that this should be published by the IETF. If you feel it is important to have an RFC, I would suggest the Independent Stream. With that said, a few other finer-grained comments below. S 2. Note that this document is not on the IETF standards track. However, a conformant implementation is supposed to adhere to the specified behavior for security and interoperability reasons. This text uses BCP 14 to describe that necessary behavior. Is the point here that you don't want a ST document or are you merely acknowledging that it is not one? S 3.1.2. I understand why canonicalization is required if you want to move around cleartext JSON (ignoring the wisdom of this), but IMO you're doing this at the wrong layer. Rather than having the signing/validation system do canonicalization, instead require that your system pass JSON "unmodified". This leaves the implementor with two choices: - Actually have a clear path through the system - Canonicalize at the beginning and the end (thus effectively undoing whatever damage was done) You can then define the signature system as just operating on the text as given without requiring it to depend on canonicalization. S 3.1.4. It's not a good design to mix the metadata for the signed object with the object itself as you do in S 3.1.3. This makes the problem of the user understanding what is authenticated and what is not even more difficult (for instance, what if you need a key identifier or some other thing that isn't the signature?). I get that you want to decorate existing structures, but for the reasons above, I think that's bad and you should instead nest them as JWS contemplates. If we must decorate, we should instead have a single standardized key which holds its own structure that contains all signature-related data. --0000000000002c0c8005c8093d16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I took a quick look at this document and I continue to hav= e the same
concerns about the overall approach I had previously, namely = that
having allegedly signed data available in the "clear" is = not in fact a
feature because we want people to validate the signature b= efore
accessing the data and the validation process can then emit thevalidated signed data. For these reasons, I do not believe that this
sh= ould be published by the IETF. If you feel it is important to have
an RF= C, I would suggest the Independent Stream.


With that said, a few= other finer-grained comments below.


S 2.

=C2=A0 =C2=A0No= te that this document is not on the IETF standards track.=C2=A0 However,=C2=A0 =C2=A0a conformant implementation is supposed to adhere to the spec= ified
=C2=A0 =C2=A0behavior for security and interoperability reasons.= =C2=A0 This text uses
=C2=A0 =C2=A0BCP 14 to describe that necessary beh= avior.

Is the point here that you don't want a ST document or ar= e you
merely acknowledging that it is not one?


S 3.1.2.
I = understand why canonicalization is required if you want to move
around c= leartext JSON (ignoring the wisdom of this), but IMO
you're doing th= is at the wrong layer. Rather than having the
signing/validation system = do canonicalization, instead
require that your system pass JSON "un= modified". This leaves
the implementor with two choices:

- A= ctually have a clear path through the system
- Canonicalize at the begin= ning and the end (thus effectively
=C2=A0 undoing whatever damage was do= ne)

You can then define the signature system as just operating on th= e
text as given without requiring it to depend on canonicalization.
<= br>
S 3.1.4.
It's not a good design to mix the metadata for the s= igned
object with the object itself as you do in S 3.1.3. This
makes = the problem of the user understanding what is authenticated
and what is = not even more difficult (for instance, what if
you need a key identifier= or some other thing that isn't the
signature?).

I get that y= ou want to decorate existing structures, but for
the reasons above, I th= ink that's bad and you should instead
nest them as JWS contemplates.= If we must decorate, we
should instead have a single standardized key w= hich holds
its own structure that contains all signature-related
data= .


--0000000000002c0c8005c8093d16-- From nobody Mon Jul 26 16:08: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 8DFA33A0938 for ; Mon, 26 Jul 2021 16:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Ar4HtCJK7oa8 for ; Mon, 26 Jul 2021 16:08:31 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 BE3F63A0935 for ; Mon, 26 Jul 2021 16:08:30 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id n2so12772293eda.10 for ; Mon, 26 Jul 2021 16:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=VQOQu+PWvDMO77NJ9mBoYJeDK2dXSNmQGdBss2sCHXk=; b=SArg/alt35yBs6rSkZLN1ucGnSNfnTWSujvrG0onaKe/bfKB9hjyvafCQkYA53h9ME OBMUDhxQCLf/RgDf6mxxMD35bmhjHpSmyf+B0CUhgGpA0ldrfXoY87lB1P5hJfBC2rnX 9jXZxKi0mkex+7vPC+P/1r1GCgoIY0pXrM9yQfUm4NG8ARlmrsjfaeI2kWQl1RkZ8Nxm rIb1GMAp4u+bNpbXNUqmKz1Qpn6f7ADHPmyVHkJ8zHBj1fEwZRGwXPtInAh1JXsl1dQi GM0pGr5+292lPZio750lFaZZFGJ6k0I1XOA2NpmS3mPx4fHJi+F8m8Vz8gdQT5DuKeB4 Vnpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VQOQu+PWvDMO77NJ9mBoYJeDK2dXSNmQGdBss2sCHXk=; b=MfwMJAniHXOD4sGEa8sJTpKS63D7tA7/hMvYnzustAgao/aGGktgkCApYoHzB0IRmo jD1tpu5P08fIdQOxBJggKkRqSKVeTwFGNDHIzHvKpZEMhM8zQ4oiqh1siUdEopzfXmdX 4UptUaaRTJzAH6argSNY+JxI3h+Lcsx8QnyL83PrdzB34Z3qEmWb2szngJG85lRyc3Ez 5OkMJu2Gggq09GJMOYPy0a9JWKTuORaMc5FHZ1mZrd5Hb4RaMDLsNYypPCOVOGBQ+sxp j3OCkJIPMOyG1//3AmiPby6i9J95dWUxPk4tA6Qc9uwy9jkQOQElr2oKo7u9KzPd0CcN IhNQ== X-Gm-Message-State: AOAM533lp9BgtLQXye6Vqlc9ZJYMDHeVTAurVFEIPGduC0u9hyLh46l6 tsygGqBB6LbnUHsAumDZFqldjqRAFYERwDJu9Z3BQnUylng1JxR/ X-Google-Smtp-Source: ABdhPJzskAMSaYUfuCcIzf54zy8ywXX1nsdym6Zflj5BMwx/vlyrcauSOm+69/VYTUgldEsaR1zTuB5UwAEwW9Ko+Bo= X-Received: by 2002:a05:6402:13c3:: with SMTP id a3mr24168273edx.187.1627340907141; Mon, 26 Jul 2021 16:08:27 -0700 (PDT) MIME-Version: 1.0 From: Eric Rescorla Date: Mon, 26 Jul 2021 16:07:50 -0700 Message-ID: To: IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000b2eef005c80ed460" Archived-At: Subject: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 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: Mon, 26 Jul 2021 23:08:37 -0000 --000000000000b2eef005c80ed460 Content-Type: text/plain; charset="UTF-8" I took a look at this document. While I think it's valuable to have a definition of E2EE, IMO this document needs a fair bit of work, including quite a bit of trimming. Specifically, it seems to me that it's quite hard to talk about E2EE as an abstract property, because what's E2EE in one context (my TLS connection to Gmail) is not E2EE in another context (the email that I am reading that was sent to Gmail). I think what I would do instead is: 1. Provide a generic definition of what E2EE encryption means assuming the endpoints are defined (something like 3.1.) 2. Examine some specific cases of system types, such as (1) network connections (e.g., TLS) (2) e-mail and (3) messaging such as MLS and describe what we should view as the endpoints and the limitations of trying to provide E2E in those contexts. I would also note that there are other ways to be E2E that are not just "E2E encrypted". For instance, DNSSEC provides end-to-end authentication/integrity. Another example would be "E2E" voting systems. OVERALL It seems to me that the most difficult problem here is that being E2EE isn't an absolute property but one that applies with respect to a certain set of endpoints. As an example, if I use HTTPS to search with Google, that's arguably E2E encrypted to Google. If I used HTTPS to read my email, though, we don't think that's E2EE (absent S/MIME, obviously). So I think you need to treat this more of a relation and then talk about some common cases and who we should view as the communications endpoints. End-to-end encryption (E2EE) is an application of cryptography in communications systems between endpoints. E2EE systems are unique in providing features of confidentiality, integrity and authenticity for users. Improvements to E2EE strive to maximise the system's security while balancing usability and availability. Users of E2EE communications expect trustworthy providers of secure implementations to respect and protect their right to whisper. This last sentence seems weirdly hortatorial. I would stick to the technical points. DETAILED S 2.1. However despite the nuance for engineers, it is now widely accepted that the communication system itself begins and ends with the user [RFC8890]. We imagine people (through an application's user interface, or user agent) as components in a subsystem's design. An important exception to this in E2EE systems might be the use of public key infrastructure where a third party is often used in the authentication phase to enhance the larger system's trust model. Responsible use of of public key infrastructure is required in such cases, such that the E2EE system does not admit third parties under the user's identity. I don't understand this point at all. The third parties aren't communications endpoints. It's incredibly common to have "e2e" systems which have third parties such as CAs. We cannot equate user agent and user, yet we also cannot fully separate them. As user-agent computing becomes more complex and often more proprietary, the user agent becomes less of an "advocate" for the best interests of the user. This seems like it needs to be supported, or perhaps just omitted. S 2.2. identity and end identity. This creates a tree hierarchy with the end user as the root at the top, and all potential end points being under their direct control, without third party access. As an This seems far more strict than is possible. Consider the case of a piece of software which allows for remote updates. Does that mean it is not capable of doing E2EE? Even if we assume BT and reproducible builds, it still would not meet this definition because there is third-party access. S 2.3. This seems oddly detailed. The question of whether authentication is symmetric or asymmetric or whether there is a ratched doesn't define if something is E2EE. The adversary successfully subverts an end-to-end encrypted system if it can succeed in either of the following: 1) the adversary can produce the participant's local state (meaning the adversary has learned the contents of participant's messages), or 2) the states of conversation participants do not match (meaning that the adversary has influenced their communication in some way). To prevent the adversary from trivially winning, we do not allow the adversary to compromise the participants' local state. We can say that a system is end-to-end secure if the adversary has negligible probability of success in either of these two scenarios [komlo]. I'm not sure if this is intended to be a formal definition, but it seems to me that it has a number of edge cases which are problematic: 1. Consider the case where I persuade you to install a new E2E messenger and then send you a message. At this point, I know your state, but presumably I have not violated the defn. 2. Consider the case where A sends a message to B but I succeeed in blocking that message by (for instance) jamming B's network. In this case, the states don't match, but again we wouldn't say E2EE was violated. S 3.1.1. I of course agree with these features, but I feel like they need to come with some sort of definition of the endpoints and who it is you trust. To take some examples: - I think we agree that TLS between me and Google is E2EE, right? But actually, with Google I connect to GFE which then decrypts the data. - I think we would also agree that TLS between me and Google is not E2EE if there is a MITM proxy. But what feature out of this CIA list is it missing? - When I connect to a site which is fronted by a CDN, is that E2EE? Maybe? S 3.1.2. I feel like the / in "optional/desirable" is doing a lot of work here. There are contexts in which "deniable" is important but also ones in which "undeniable" is important! More generally, Availability, FS, and PCS seem desirable whether we are end-to-end or not. S 3.2. I would strike all of this. It's too specific to a particular set of systems and not really helpful to a definition. S 4.1. I agree that "a conversation is confidential" is a good thing to happen, but it's out of step with the rest of this document to root it in 7624 or human rights. Let's just stick to technical points here. S 4.3. message is sent to the recipient" [GEC-EU]. Third party access also covers cases without scanning - namely, it should be possible for any third-party end point to access the data regardless of reason. I assume you mean "not"? --000000000000b2eef005c80ed460 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I took a look at this document. While I think it's val= uable to have a
definition of E2EE, IMO this document needs a fair bit o= f work,
including quite a bit of trimming.

Specifically, it seems= to me that it's quite hard to talk about E2EE
as an abstract proper= ty, because what's E2EE in one context (my TLS
connection to Gmail) = is not E2EE in another context (the email that I
am reading that was sen= t to Gmail). I think what I would do instead
is:

1. Provide a gen= eric definition of what E2EE encryption means
=C2=A0 =C2=A0assuming the = endpoints are defined (something like 3.1.)

2. Examine some specific= cases of system types, such as
=C2=A0 =C2=A0(1) network connections (e.= g., TLS) (2) e-mail and (3) messaging
=C2=A0 =C2=A0such as MLS and descr= ibe what we should view as the endpoints
=C2=A0 =C2=A0and the limitation= s of trying to provide E2E in those
=C2=A0 =C2=A0contexts.

I woul= d also note that there are other ways to be E2E that
are not just "= E2E encrypted". For instance, DNSSEC provides
end-to-end authentica= tion/integrity. Another example would
be "E2E" voting systems.=


OVERALL
It seems to me that the most difficult problem here = is that being
E2EE isn't an absolute property but one that applies w= ith respect
to a certain set of endpoints. As an example, if I use HTTPS= to
search with Google, that's arguably E2E encrypted to Google. If<= br>I used HTTPS to read my email, though, we don't think that's E2E= E
(absent S/MIME, obviously). So I think you need to treat this more
= of a relation and then talk about some common cases and who we
should vi= ew as the communications endpoints.


=C2=A0 =C2=A0End-to-end encr= yption (E2EE) is an application of cryptography in
=C2=A0 =C2=A0communic= ations systems between endpoints.=C2=A0 E2EE systems are unique in
=C2= =A0 =C2=A0providing features of confidentiality, integrity and authenticity= for
=C2=A0 =C2=A0users.=C2=A0 Improvements to E2EE strive to maximise t= he system's security
=C2=A0 =C2=A0while balancing usability and avai= lability.=C2=A0 Users of E2EE
=C2=A0 =C2=A0communications expect trustwo= rthy providers of secure implementations
=C2=A0 =C2=A0to respect and pro= tect their right to whisper.

This last sentence seems weirdly hortat= orial. I would stick to
the technical points.


DETAILED
S 2= .1.
=C2=A0 =C2=A0However despite the nuance for engineers, it is now wid= ely accepted
=C2=A0 =C2=A0that the communication system itself begins an= d ends with the user
=C2=A0 =C2=A0[RFC8890].=C2=A0 We imagine people (th= rough an application's user
=C2=A0 =C2=A0interface, or user agent) a= s components in a subsystem's design.=C2=A0 An
=C2=A0 =C2=A0importan= t exception to this in E2EE systems might be the use of
=C2=A0 =C2=A0pub= lic key infrastructure where a third party is often used in the
=C2=A0 = =C2=A0authentication phase to enhance the larger system's trust model.<= br>=C2=A0 =C2=A0Responsible use of of public key infrastructure is required= in such
=C2=A0 =C2=A0cases, such that the E2EE system does not admit th= ird parties under
=C2=A0 =C2=A0the user's identity.

I don'= ;t understand this point at all. The third parties aren't
communicat= ions endpoints. It's incredibly common to have "e2e" systems<= br>which have third parties such as CAs.


=C2=A0 =C2=A0We cannot = equate user agent and user, yet we also cannot fully
=C2=A0 =C2=A0separa= te them.=C2=A0 As user-agent computing becomes more complex and
=C2=A0 = =C2=A0often more proprietary, the user agent becomes less of an "advoc= ate"
=C2=A0 =C2=A0for the best interests of the user.

This s= eems like it needs to be supported, or perhaps just omitted.


S 2= .2.

=C2=A0 =C2=A0identity and end identity.=C2=A0 This creates a tre= e hierarchy with the
=C2=A0 =C2=A0end user as the root at the top, and a= ll potential end points being
=C2=A0 =C2=A0under their direct control, w= ithout third party access.=C2=A0 As an

This seems far more strict th= an is possible. Consider the case of
a piece of software which allows fo= r remote updates. Does that
mean it is not capable of doing E2EE? Even i= f we assume BT and
reproducible builds, it still would not meet this def= inition
because there is third-party access.


S 2.3.
This s= eems oddly detailed. The question of whether authentication
is symmetric= or asymmetric or whether there is a ratched doesn't
define if somet= hing is E2EE.

=C2=A0 =C2=A0The adversary successfully subverts an en= d-to-end encrypted system if
=C2=A0 =C2=A0it can succeed in either of th= e following: 1) the adversary can
=C2=A0 =C2=A0produce the participant&#= 39;s local state (meaning the adversary has
=C2=A0 =C2=A0learned the con= tents of participant's messages), or 2) the states of
=C2=A0 =C2=A0c= onversation participants do not match (meaning that the adversary
=C2=A0= =C2=A0has influenced their communication in some way).=C2=A0 To prevent th= e
=C2=A0 =C2=A0adversary from trivially winning, we do not allow the adv= ersary to
=C2=A0 =C2=A0compromise the participants' local state.
=
=C2=A0 =C2=A0We can say that a system is end-to-end secure if the adver= sary has
=C2=A0 =C2=A0negligible probability of success in either of the= se two scenarios
=C2=A0 =C2=A0[komlo].

I'm not sure if this i= s intended to be a formal definition, but
it seems to me that it has a n= umber of edge cases which are
problematic:

1. Consider the case w= here I persuade you to install a new E2E
=C2=A0 =C2=A0messenger and then= send you a message. At this point, I know
=C2=A0 =C2=A0your state, but = presumably I have not violated the defn.

2. Consider the case where = A sends a message to B but I succeeed
=C2=A0 =C2=A0in blocking that mess= age by (for instance) jamming B's network.
=C2=A0 =C2=A0In this case= , the states don't match, but again we wouldn't
=C2=A0 =C2=A0say= E2EE was violated.


S 3.1.1.
I of course agree with these fea= tures, but I feel like they
need to come with some sort of definition of= the endpoints
and who it is you trust. To take some examples:

- = I think we agree that TLS between me and Google is E2EE,
=C2=A0 right? B= ut actually, with Google I connect to GFE which
=C2=A0 then decrypts the= data.

- I think we would also agree that TLS between me and Google<= br>=C2=A0 is not E2EE if there is a MITM proxy. But what feature
=C2=A0 = out of this CIA list is it missing?

- When I connect to a site which= is fronted by a CDN,
=C2=A0 is that E2EE? Maybe?


S 3.1.2.I feel like the / in "optional/desirable" is doing a lot of work=
here. There are contexts in which "deniable" is important but=
also ones in which "undeniable" is important! More generally,=
Availability, FS, and PCS seem desirable whether we are end-to-end
o= r not.

S 3.2.
I would strike all of this. It's too specific t= o a particular
set of systems and not really helpful to a definition.
S 4.1.
I agree that "a conversation is confidential" is a= good thing
to happen, but it's out of step with the rest of this do= cument
to root it in 7624 or human rights. Let's just stick to
te= chnical points here.


S 4.3.
=C2=A0 =C2=A0message is sent to t= he recipient" [GEC-EU].=C2=A0 Third party access also
=C2=A0 =C2=A0= covers cases without scanning - namely, it should be possible for any
= =C2=A0 =C2=A0third-party end point to access the data regardless of reason.=

I assume you mean "not"?



=C2=A0


--000000000000b2eef005c80ed460-- From nobody Mon Jul 26 16:10: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 30CD33A096B for ; Mon, 26 Jul 2021 16:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=akamai.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 ZvTDQCmTnNqr for ; Mon, 26 Jul 2021 16:10:53 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 4CF123A0962 for ; Mon, 26 Jul 2021 16:10:52 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 16QNAQ0O013047; Tue, 27 Jul 2021 00:10:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=sDbtDOILmcFvwRU2OtupQ//vbCEcmbtGW9RYrftPkN8=; b=UheNo1sockmO7Xr+mzCwYFm9ds9U2Lu9IPGojk8TbZOQCMSfd21RJkw/QqccNSDaF2bd hAGuihwLbqeYZfcHcQkSL5s/S8fOdhGD5kdpt9vMfYpbYY+K3NsvuLLumb+8+fQy0TsZ bkDn4qogL/CfZfizDDZNxtLsp5pGXi2E3rqX5tY6dGYTjZFnpn++YTnyC/fFyqndEUt0 ZvD/bJnVEZY62tL2bM3L42Jp9b1cMHYB6+PqNAT9nZaYmWNWzJTqEh42l+4bOeM0lsjV NTZ7VKfK9iEZvQhrV+sWjb/mtGAOpV4VTFEREvHpvENMSmfnJn/bUTmLDflniiyY8lG9 Hg== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 3a236qe1q5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Jul 2021 00:10:51 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 16QN4dYZ005274; Mon, 26 Jul 2021 19:10:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint8.akamai.com with ESMTP id 3a23e5s1eu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 26 Jul 2021 19:10:50 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 26 Jul 2021 18:10:49 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.018; Mon, 26 Jul 2021 18:10:49 -0500 From: "Salz, Rich" To: Eric Rescorla , IETF SecDispatch Thread-Topic: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 Thread-Index: AQHXgnMvZOeW0gM1mUyhMikJrLTT2KtV8ssA Date: Mon, 26 Jul 2021 23:10:48 +0000 Message-ID: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.51.21071101 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_99F30413451840E6A7402DA1049A3D1Bakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-26_14:2021-07-26, 2021-07-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 spamscore=0 phishscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2107260134 X-Proofpoint-GUID: khZ4th1KUAksRO7Edx6lW1oPy3W60ObH X-Proofpoint-ORIG-GUID: khZ4th1KUAksRO7Edx6lW1oPy3W60ObH X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-26_14:2021-07-26, 2021-07-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 priorityscore=1501 phishscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0 spamscore=0 impostorscore=0 mlxscore=0 suspectscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2107260135 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint8 Archived-At: Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 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: Mon, 26 Jul 2021 23:10:58 -0000 --_000_99F30413451840E6A7402DA1049A3D1Bakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgUHJvdmlkZSBhIGdlbmVyaWMgZGVmaW5pdGlvbiBvZiB3aGF0IEUyRUUgZW5jcnlwdGlv biBtZWFucw0KICAgYXNzdW1pbmcgdGhlIGVuZHBvaW50cyBhcmUgZGVmaW5lZCAoc29tZXRoaW5n IGxpa2UgMy4xLikNCg0KWW91IG1pZ2h0IGZpbmQgQWxleOKAmXMgcHJlc2VudGF0aW9uIGF0IENG UkcgdXNlZnVsLg0KDQo= --_000_99F30413451840E6A7402DA1049A3D1Bakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <2CCDC5D191CE2745A724BF908E21C5EC@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjU3ODQzOTg3NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTIwMzIzNDEyMiA2OTM4MjI2MjAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo0OTsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpi cmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPHVsIHN0eWxl PSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPg0KUHJvdmlkZSBhIGdlbmVyaWMgZGVmaW5pdGlvbiBvZiB3aGF0IEUy RUUgZW5jcnlwdGlvbiBtZWFuczxicj4NCiZuYnNwOyAmbmJzcDthc3N1bWluZyB0aGUgZW5kcG9p bnRzIGFyZSBkZWZpbmVkIChzb21ldGhpbmcgbGlrZSAzLjEuKTxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5Zb3UgbWlnaHQgZmluZCBBbGV44oCZcyBwcmVzZW50YXRpb24gYXQgQ0ZSRyB1c2Vm dWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_99F30413451840E6A7402DA1049A3D1Bakamaicom_-- From nobody Mon Jul 26 16:51:29 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 689CB3A0BCA for ; Mon, 26 Jul 2021 16:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 yh8SE-4THF0h for ; Mon, 26 Jul 2021 16:51:14 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 C837B3A0BA5 for ; Mon, 26 Jul 2021 16:51:14 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id w6so6047340qvh.3 for ; Mon, 26 Jul 2021 16:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=fPTRp27uWRPAqFyR9F06IIyhWUwzZtQkQzgGmCcp6FQ=; b=RPdQOcdE2K9vCKDZNAPu6NlX2hQOwxRavt9mA/mKDnGz9ieGo+qSMR6IidKnukgqTe YnhcgCgGVRZ2YSHKqTqtT4nEex+dgNj2ZfcAtU9bC2nI6LQszy6Fk//Jm3Iv28tgMMVB I2LJRGniFwOVhTnCEtLMZtLUSrdV8IlzJv1qg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=fPTRp27uWRPAqFyR9F06IIyhWUwzZtQkQzgGmCcp6FQ=; b=FxMWIj40qIOZU7VAmNLnPzK4HVfZ4AqFk6w1WZOqlDmp0pPEXA3VbU+AQBJ5U3SsMs +ftTlZbpj/5ZW7xrS8zq7eBY48MUgQjOuoWoOeONM/y9oD2ZWNEJxGcxEnpTNRjsLlC5 CPx8XC8H0ldSuEIqDRgvOWcAL7WtlIVj4oYaptAW0KmXRYhiuu0y6PEAYaZbZr4byXGO JiDB3Xj2u3zgn34lrnf6tckOep2V7spQXDJS7VbW3Jz4Iqvxy2WEsHjhqrqUFoK53tcg Lox8rrmH8dvj10BWCDgSrW8fRfjZPaQbq2SJTDErFc0LeslP2wm25+RMnwkA8C06nx/x Afwg== X-Gm-Message-State: AOAM533vJuqyOFH+wGDnQQPtwATnG79URSb5V3Ez39vRUOImdc2E7Yze Tn5WSRdewK2qespV/v8SsfVEeHUZekHJkM93 X-Google-Smtp-Source: ABdhPJz2+YheJDO+A/hck8w0jaPbhS3QObcZdegUmwMePa8CQJJtwU+3I+tteySeF7y4aq0S70oAgQ== X-Received: by 2002:a05:6214:d6d:: with SMTP id 13mr20228081qvs.3.1627343472583; Mon, 26 Jul 2021 16:51:12 -0700 (PDT) Received: from ?IPV6:2601:14d:8300:7fa0:2c06:a262:f9cd:1896? ([2601:14d:8300:7fa0:2c06:a262:f9cd:1896]) by smtp.gmail.com with UTF8SMTPSA id r16sm817023qke.73.2021.07.26.16.51.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jul 2021 16:51:12 -0700 (PDT) Message-ID: Date: Mon, 26 Jul 2021 19:51:11 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.0 Content-Language: en-US To: "Salz, Rich" , Eric Rescorla , IETF SecDispatch References: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> From: Mallory Knodel In-Reply-To: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 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: Mon, 26 Jul 2021 23:51:28 -0000 Hi, On 7/26/21 7:10 PM, Salz, Rich wrote: > * Provide a generic definition of what E2EE encryption means > assuming the endpoints are defined (something like 3.1.) > > You might find Alex’s presentation at CFRG useful. I think if we got to this place in the first section, we would summarize this concise definition in the abstract of the draft so that it's the Very First Thing. -M -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Mon Jul 26 16:51:44 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 37FD73A0BCA for ; Mon, 26 Jul 2021 16:51:37 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 c2pKaTQ1laYg for ; Mon, 26 Jul 2021 16:51:33 -0700 (PDT) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 9E35D3A0BEE for ; Mon, 26 Jul 2021 16:51:32 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id gs8so5678796ejc.13 for ; Mon, 26 Jul 2021 16:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TgtBY5Iw3oWTty6ZGNy8Q5wbXcdHUVMtggVbwTtrFyk=; b=gejn/BSpDWX4JPvkEVTNN5bx5OljMLyNIs/soDFfg9UqhY8WAuB0j+2WstNVPn9xjV B6/69acxP3duXy0D1aTIwRu9+LopWxXC5HpUlkPBkpepLUEI9SzlSAgyxFmn9zQs2dKq aiJSVW++qrf9Dn1jMOS/vmdrfv/jZLcRuATL2Cj+ehdTqeG+ScqzHK11L3iklswWXQj1 J9p+XJpaTyZtspxN1das6QUx2NwH9LPNKFwIoWJhWDYVKCAbItetPDjM8CEUbqCrTqI6 IlM2om2ZrW/fQQHNXnQWaMm6uGFnYmhrY6IM8DGZ9YRTlIA92mgFtvYUYt2Cp2ambPz9 /C2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TgtBY5Iw3oWTty6ZGNy8Q5wbXcdHUVMtggVbwTtrFyk=; b=OgocLpYd8d+TiQbnRSxoSOk4axqY4hPz1JGp24X2l7JKtlZ3r8HGredX+5qDJj9lew z5Vrn6PAorvfzeKf3P18ELUBUGkZ/9dgm31gDtxhayozMyk0JAlxLLXnJMTQ9fkl+JX9 QOvlAOic+Xs74aW65vjb2mlJ6/GVfRhq68eMU6Hnjl2eQangdzKndUF6tAdd5zt1pwT0 Guj5Q7ByefVQgSIdgy6SXbLxXZA+BH3128hPIjOAIvi6wHRQeUlr4tUfHvriAMjjuqiW a0gk4euvNu8aBTyIocfHIamHZE+lHDNDiq67YQ39jORMPYi1B56D/KNIl17gOzY+b1CT LV/Q== X-Gm-Message-State: AOAM533vW+TO4Qpx9EnqBPDLZAZ6+irCTJ+oGRwvyGEEw4wmF670FIHM xwTTjAJcn64dhUUlSaFCpeIL9jCB44q1GQ2GoGeWPw== X-Google-Smtp-Source: ABdhPJy6zPrdO4Xw0dcGlMr9GEoycel5SRzxpNjFDrTCLrIfreaMr0f7gFC/tWvmZ/XPg9voI6oDypOYw4yBuJSgaTw= X-Received: by 2002:a17:906:c7c2:: with SMTP id dc2mr19785352ejb.472.1627343490244; Mon, 26 Jul 2021 16:51:30 -0700 (PDT) MIME-Version: 1.0 References: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> In-Reply-To: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> From: Eric Rescorla Date: Mon, 26 Jul 2021 16:50:53 -0700 Message-ID: To: "Salz, Rich" Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000a9fab405c80f6e52" Archived-At: Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 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: Mon, 26 Jul 2021 23:51:43 -0000 --000000000000a9fab405c80f6e52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I took a quick look at his draft and it seems like there is useful stuff there as well. Perhaps some kind of merger is possible? On Mon, Jul 26, 2021 at 4:10 PM Salz, Rich wrote: > > - Provide a generic definition of what E2EE encryption means > assuming the endpoints are defined (something like 3.1.) > > > You might find Alex=E2=80=99s presentation at CFRG useful. > > > --000000000000a9fab405c80f6e52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I took a quick look at his draft and it seems like there i= s useful stuff there as well. Perhaps some kind of merger is possible?
<= /div>
O= n Mon, Jul 26, 2021 at 4:10 PM Salz, Rich <rsalz@akamai.com> wrote:
  • Provide a generic definition of what E2EE encryption means
    =C2=A0 =C2=A0assuming the endpoints are defined (something like 3.1.)

You might find Alex=E2= =80=99s presentation at CFRG useful.

=C2=A0

--000000000000a9fab405c80f6e52-- From nobody Mon Jul 26 16:53:28 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 3C2603A0BAC; Mon, 26 Jul 2021 16:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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=akamai.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 5cLniCZZW0Yc; Mon, 26 Jul 2021 16:53:22 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 7BF653A0BFC; Mon, 26 Jul 2021 16:53:22 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 16QNiOZK023663; Tue, 27 Jul 2021 00:53:18 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=vwabJpPP3U2778bYb2wr1xnUVSktK8rUSlJrmjKsAgQ=; b=McEB+5I+aKg9EYLyZQVglT7+IPXKarZPAvxyCx2iOi4maFuHHCNF+/pldPbUNndnqaPP 2wwyaItVn01mQ1+f2wFHSRexi6AJUvzZumNyDkrD9Yx9E5PxZY5iZxKRMX9vWhYYwQ2i u5bfHvSwTl7JmWG94R+3/WS/aYpLOP7W8X6u1E4n2/FubqNxmzuf2Y69fGFKK5j8hlTg WxVXbNyIuobVIzQYxCPPbxOClqRI2ZsQJAL/QIkje1gFaUr2tCCjc5X+dTX6d1cftCHf CLngKqPs6JMuipBzX2iZYVQ3q6/uWy1RyCXdVGQU5PFFLX2td0ObcM/I0/EHrMK/senZ Sw== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 3a236qf8t7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Jul 2021 00:53:18 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 16QNZpDD016091; Mon, 26 Jul 2021 19:53:17 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint3.akamai.com with ESMTP id 3a240j0y29-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 26 Jul 2021 19:53:17 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 26 Jul 2021 18:53:16 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.018; Mon, 26 Jul 2021 18:53:16 -0500 From: "Salz, Rich" To: Mallory Knodel , "Salz, Rich" , Eric Rescorla , "IETF SecDispatch" Thread-Topic: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 Thread-Index: AQHXgnMvZOeW0gM1mUyhMikJrLTT2KtV8ssAgABOWYD//72EAA== Date: Mon, 26 Jul 2021 23:53:15 +0000 Message-ID: <416C1A8D-4F95-4E25-884E-1A18EEDA6988@akamai.com> References: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.51.21071101 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-26_14:2021-07-26, 2021-07-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 malwarescore=0 phishscore=0 mlxscore=0 mlxlogscore=799 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2107260137 X-Proofpoint-GUID: nBK0XcinGpLvjMzxhm4N2XMvOzAZsh57 X-Proofpoint-ORIG-GUID: nBK0XcinGpLvjMzxhm4N2XMvOzAZsh57 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-26_14:2021-07-26, 2021-07-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 priorityscore=1501 phishscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0 spamscore=0 impostorscore=0 mlxscore=0 suspectscore=0 mlxlogscore=764 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2107260138 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.31) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint3 Archived-At: Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 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: Mon, 26 Jul 2021 23:53:27 -0000 PiAgIEkgdGhpbmsgaWYgd2UgZ290IHRvIHRoaXMgcGxhY2UgaW4gdGhlIGZpcnN0IHNlY3Rpb24s IHdlIHdvdWxkIHN1bW1hcml6ZSANCiAgICB0aGlzIGNvbmNpc2UgZGVmaW5pdGlvbiBpbiB0aGUg YWJzdHJhY3Qgb2YgdGhlIGRyYWZ0IHNvIHRoYXQgaXQncyB0aGUgDQogICAgVmVyeSBGaXJzdCBU aGluZy4NCg0KSSBkb24ndCB0aGluayBJIHVuZGVyc3RhbmQuICBBcmUgeW91IHNheWluZyB0aGF0 IHlvdSBzdXBwb3J0IGEgbWVyZ2VkIGRvYyB1c2luZyBBbGVjJ3MgYXMgdGhlIG5ldyAicGFydCBv bmUiID8NCg0KDQo= From nobody Mon Jul 26 16:55:03 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 5CAA53A0035 for ; Mon, 26 Jul 2021 16:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 7hJHMh2zWIqx for ; Mon, 26 Jul 2021 16:54:56 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 19F953A0028 for ; Mon, 26 Jul 2021 16:54:55 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id t66so10737655qkb.0 for ; Mon, 26 Jul 2021 16:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xWstsJdmuTyuS2Jnx6yBggweYb4v6CsOM6oVf0HSYEQ=; b=iXkV4meBbXwpgHE22KaG7AlRGT69T3+gWUM4GTe05hStufVrVwINSYSr96vV2yzEgQ uh3m/ZPqYT4YqlG6PpJ6nbZp1FRhuFmVbaGyKAmkTwZkHwj1lIxaQlayhGl8nG/LbIpt yuZmFszJnwAyASMLtlM2oRRMfeESVx8IXI80cx7MCSmEY6xCuG5l2eKzztsVkbDyZbP4 odtnFmL3svdZZQQGoXKsp1Ux0u/FrvM0+nxdrBhyoJRlNE2X0SVnkVn8Wz5yLo9NrKIV JOu6XzhkdKe0yyr/1SB2/tOaxxJdRgyJFFD+gykP55//IjYlRVolGE2o7ZWH6ZhhlBLV dqCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xWstsJdmuTyuS2Jnx6yBggweYb4v6CsOM6oVf0HSYEQ=; b=KAB3b7rKU6T+kVDbhnvYomM1c4NvbeKj1uMKX+LbRAJDPGxVw0nj0C4/e1Ec3tg8// eVwR/xlTmI5PWKKKqGX+khyTXNC6wIO6WLFYtAsEWDioXvkYx3gzIqVAS/bmqp8UN6Uh fVhv8CZsgXogSmryDnc+U75SqLbiWKrQOvPmFC8iGWKhFzSkqmbUcZDHIfM68I0GFQ4t v4YaZ4QyqaPOP9KR7bsdrKOVLh9VdCi1Q/BkgKA7NdJ1hJFWnyAriUZGpHwI8qj447Ni qs1fdQx/HuxiGlWnABu4rCxnE/bm1UxKkm61SOpGZEs9dM7H8LlPVflv5jWzcUZfO6rY oSYg== X-Gm-Message-State: AOAM531QhNtYM1/meRrvjOjKNC3TEjAdtla74PhnI6XpualX5xQQoG60 C52G6IHXsc3Hp44/mijigpD9TwfXZGFOHh8HKic= X-Google-Smtp-Source: ABdhPJyry6OT5WucK5Woa6e47WSOh/TZ/MdvXZatN1W3dIzIeXY7PeXqT6NL+/Y1JBpN60LJlQwU9ewWrBM5S7p6AyY= X-Received: by 2002:a37:670e:: with SMTP id b14mr20025456qkc.240.1627343694080; Mon, 26 Jul 2021 16:54:54 -0700 (PDT) MIME-Version: 1.0 References: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> In-Reply-To: From: Alec Muffett Date: Tue, 27 Jul 2021 00:54:17 +0100 Message-ID: To: Eric Rescorla Cc: "Salz, Rich" , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000d02de705c80f7aca" Archived-At: Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 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: Mon, 26 Jul 2021 23:55:01 -0000 --000000000000d02de705c80f7aca Content-Type: text/plain; charset="UTF-8" On Tue, 27 Jul 2021 at 00:51, Eric Rescorla wrote: > > I took a quick look at his draft and it seems like there is useful stuff there as well. Perhaps some kind of merger is possible? > Alas I missed most of Mallory's session (late feed + putting baby to bed) up-to the point where ekr was asking questions; I'm hoping that I can catch-up somewhere. However I just submitted my deck to CFRG, and it's also available at https://alecmuffett.com/alecm/tmp/draft-muffett-e2esm.pdf - I think the deck will help clarify the differences in approach. - alec -- https://alecmuffett.com/about --000000000000d02de705c80f7aca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 27 Jul 2021 at 00:51, Eric Rescorla <ekr@rtfm.com> wrote:
>
> I= took a quick look at his draft and it seems like there is useful stuff the= re as well. Perhaps some kind of merger is possible?
>

Al= as I missed most of Mallory's session (late feed + putting baby to bed)= up-to the point where ekr was asking questions; I'm hoping that I can = catch-up somewhere.

However I just submitted my deck to CFRG, and it= 's also available at=C2=A0


- I t= hink the=C2=A0deck will help clarify the differences in approach.

=C2=A0 =C2=A0 =C2=A0- alec
--
https://alecmuffett.com/about
--000000000000d02de705c80f7aca-- From nobody Mon Jul 26 17:20: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 139E33A084F for ; Mon, 26 Jul 2021 17:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 irEOWiYKLhP1 for ; Mon, 26 Jul 2021 17:20:52 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 2A3B03A0847 for ; Mon, 26 Jul 2021 17:20:51 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id h14so18631756lfv.7 for ; Mon, 26 Jul 2021 17:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IqgyhOU6XijE/I7/yoPMwLvoYDwNarGzNzUPt+1LJNs=; b=M5YozTOZfSIi4m7PCW5k4s/pket3ucicIHT7Vd3dMiNfbLje1U9GY7J5zJ249PES/+ XbtTF2aNl4TeE3Y/zm0X8WLMqVe8Xf4veoPteaqzBQGc1VCYnaNxt1HcEjl93Lvvjt8W +f4Tc+siq3hDGdJU3MHXRLTb+OZH/Pm4Er1NaLdgi+N/DE6kutOwIfhflSjsBTmtPmQ/ 6m2f1jTy5DcdXeDRrmBUxOP062fCCGTyM1CFFt9zJ5YhFegnhULZ2LL47taE7FRV904B Nwm0ieUvf6S5eBAG8CiWQJaqoxl1pINkoDHmUNZ5WE7OA3fMyLtp5gvZIOWVvmI8S+2c vG0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IqgyhOU6XijE/I7/yoPMwLvoYDwNarGzNzUPt+1LJNs=; b=nNu2DUJbKXr/Ha68vk2MZxY7pNhxydtUB9aGn6zlu4eWzMnlPd0fv0J57/GR7+/DoJ e6Og5BOGpG5fiDaQKgbmCcT8VUEzn1qcRBRT23VkWItbB9tultgsWOvvlfcFVY+66ap9 duku7S+VwwDWZrMtdh+L0TQjcMrmCmARAB4GZpdY0I40GwPduGms/nLkJsHOf5+uf+Rg OBcSr5sjJ9mIjTJnOLR5Ki9KcpBosKXKo88PWfzloK1ojTb5C11C7Vn/q2bDFYnXBQu4 NN6dEWWBr3g2OrQM4qv0fmmpxAEpMG/4Hk8ImZ425zyqGaRZOcpVI8axsQMPDdTK/A75 futA== X-Gm-Message-State: AOAM5316jIn5ajMtB0Q/IqNn1Xjkll0gCUVnfISDkojXat3CIZOePcRU idYjJEiZWST1f2hsr4SDiuV9d2IAiBdqzxOhxWcjmo66 X-Google-Smtp-Source: ABdhPJzH4UVBRG47pgvF1CDd85eOwWgUWZLb9P0VA+W+EunAkJVLSwaouk+9V0iTvk6dXgEBlnRFaRXQSWhawcAWBrs= X-Received: by 2002:a05:6512:3497:: with SMTP id v23mr15102332lfr.286.1627345247999; Mon, 26 Jul 2021 17:20:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Chelsea Komlo Date: Mon, 26 Jul 2021 18:20:34 -0600 Message-ID: To: Eric Rescorla Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000006f18f605c80fd78f" Archived-At: Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 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: Tue, 27 Jul 2021 00:20:57 -0000 --0000000000006f18f605c80fd78f Content-Type: text/plain; charset="UTF-8" Hi Eric, Thanks for this review; responses specifically for the succinct definition. On Mon, Jul 26, 2021 at 5:08 PM Eric Rescorla wrote: > > The adversary successfully subverts an end-to-end encrypted system if > it can succeed in either of the following: 1) the adversary can > produce the participant's local state (meaning the adversary has > learned the contents of participant's messages), or 2) the states of > conversation participants do not match (meaning that the adversary > has influenced their communication in some way). To prevent the > adversary from trivially winning, we do not allow the adversary to > compromise the participants' local state. > > We can say that a system is end-to-end secure if the adversary has > negligible probability of success in either of these two scenarios > [komlo]. > > I'm not sure if this is intended to be a formal definition, but > it seems to me that it has a number of edge cases which are > problematic: > > 1. Consider the case where I persuade you to install a new E2E > messenger and then send you a message. At this point, I know > your state, but presumably I have not violated the defn. > Sure, this is a trivial win condition. This is considered in the citation but should be reflected in this draft. 2. Consider the case where A sends a message to B but I succeeed > in blocking that message by (for instance) jamming B's network. > In this case, the states don't match, but again we wouldn't > say E2EE was violated. > DoS is another trivial win condition; it is considered in the citation and should also be reflected in this draft. Note that while protocols/systems should try to protect against this case, it cannot be ruled out entirely. I'll work with Mallory to make these edits. Thanks, Chelsea --0000000000006f18f605c80fd78f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

Thanks for th= is review; responses specifically for the succinct definition.=C2=A0
<= /div>
O= n Mon, Jul 26, 2021 at 5:08 PM Eric Rescorla <ekr@rtfm.com> wrote:

=C2=A0 =C2=A0The adversary successfully = subverts an end-to-end encrypted system if
=C2=A0 =C2=A0it can succeed i= n either of the following: 1) the adversary can
=C2=A0 =C2=A0produce the= participant's local state (meaning the adversary has
=C2=A0 =C2=A0l= earned the contents of participant's messages), or 2) the states of
= =C2=A0 =C2=A0conversation participants do not match (meaning that the adver= sary
=C2=A0 =C2=A0has influenced their communication in some way).=C2=A0= To prevent the
=C2=A0 =C2=A0adversary from trivially winning, we do not= allow the adversary to
=C2=A0 =C2=A0compromise the participants' lo= cal state.

=C2=A0 =C2=A0We can say that a system is end-to-end secur= e if the adversary has
=C2=A0 =C2=A0negligible probability of success in= either of these two scenarios
=C2=A0 =C2=A0[komlo].

I'm not = sure if this is intended to be a formal definition, but
it seems to me t= hat it has a number of edge cases which are
problematic:

1. Consi= der the case where I persuade you to install a new E2E
=C2=A0 =C2=A0mess= enger and then send you a message. At this point, I know
=C2=A0 =C2=A0yo= ur state, but presumably I have not violated the defn.

Sure, this is a trivial win condition.=C2=A0 This is = considered in the citation but should be reflected in this draft.

2. Consider the case where A sends a message to B but I succeeed
=C2= =A0 =C2=A0in blocking that message by (for instance) jamming B's networ= k.
=C2=A0 =C2=A0In this case, the states don't match, but again we w= ouldn't
=C2=A0 =C2=A0say E2EE was violated.

DoS is another trivial win condition; it is conside= red in the citation and should also be reflected in this draft. Note that w= hile protocols/systems should try to protect against this case, it cannot b= e ruled out entirely.

I'll work with Mallory t= o make these edits.

Thanks,
Chelsea

--0000000000006f18f605c80fd78f-- From nobody Mon Jul 26 17:53:35 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 BEFC53A0BC5 for ; Mon, 26 Jul 2021 17:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 vqWfJjXxvGhT for ; Mon, 26 Jul 2021 17:53:28 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 7E4D53A0BCC for ; Mon, 26 Jul 2021 17:53:13 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id z24so10786232qkz.7 for ; Mon, 26 Jul 2021 17:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:content-language:to :references:from:subject:in-reply-to:content-transfer-encoding; bh=GW7I4rEWzoEG6Do1GVl/uWzAjJ7eCBg7KzKZeNag+fc=; b=OdQhlZ/w+eN0w3xIfsqmJspnEqekGIbqLz5PLQK+eIpk/yR2JJoD6W5mbAwqDkKmlk Us2aLdeO2Xpk7XBIeVGq8N9i8tOQ5jPAVhBJHHhibsAR7qnyljWBqUJ7adm/elhDbg3L p1A1/W6trEw8VWChzftVJuIOSzzgpwgin1cPg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to :content-transfer-encoding; bh=GW7I4rEWzoEG6Do1GVl/uWzAjJ7eCBg7KzKZeNag+fc=; b=rwR55ilDmcx9H27uC2Kdn5gJaPCoo3Ek0gJzWN8PSHZOoBHTgPgaBpgUCqN9N4A3vA P5c4aW5UHPTtraybUwMXxeuvUJwlj0eETrAWsx3qjvnF1DHzy1mLadgp1qZG5Kf+xIJd eiPFQ8pveDsDTvM0u6gizpYRgmV/7f3MljWM2Rr9SFyNY4zvBdhWDIafW5vDFaHjkM9s 1COe0kh7J1FGIH2meJGkIfUENcfmzu5pNkNEJ+B2APWVUe2QY3ny92QdcP4YkUt/VZGh 0zNW1d2G5rzAkdSHoT8ASS9i8zhGk30tZo9g1JyudUxiPduI0wF27jPuyE+LJIFoHgj0 UzBQ== X-Gm-Message-State: AOAM531DvBrnS1vD+nO+pgm4CluKTtF4/RjVJ9b8cNlKsz8apmPTquIT QVEaEs+vPQfs3dcitAaYXTlnOQ== X-Google-Smtp-Source: ABdhPJyWi/gxWkuvnBt1rMiQdyeiTJq5U8Y/WAwZHA44s+MoO7Hkqnzcg/eDhjcyujSwY1tx8iTXrA== X-Received: by 2002:a37:b983:: with SMTP id j125mr19185280qkf.482.1627347191867; Mon, 26 Jul 2021 17:53:11 -0700 (PDT) Received: from ?IPV6:2601:14d:8300:7fa0:2c06:a262:f9cd:1896? ([2601:14d:8300:7fa0:2c06:a262:f9cd:1896]) by smtp.gmail.com with UTF8SMTPSA id d25sm737936qtq.55.2021.07.26.17.53.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jul 2021 17:53:11 -0700 (PDT) Message-ID: <593fc980-7549-81a0-8618-a5c1a481b1bb@cdt.org> Date: Mon, 26 Jul 2021 20:53:10 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.0 Content-Language: en-US To: "Salz, Rich" , "Salz, Rich" , Eric Rescorla , IETF SecDispatch References: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> <416C1A8D-4F95-4E25-884E-1A18EEDA6988@akamai.com> From: Mallory Knodel In-Reply-To: <416C1A8D-4F95-4E25-884E-1A18EEDA6988@akamai.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 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: Tue, 27 Jul 2021 00:53:34 -0000 Hi, On 7/26/21 7:53 PM, Salz, Rich wrote: >> I think if we got to this place in the first section, we would summarize > this concise definition in the abstract of the draft so that it's the > Very First Thing. > > I don't think I understand. Are you saying that you support a merged doc using Alec's as the new "part one" ? Only commenting on concision: A concise definition would be nice. Putting such a concise definition would be best placed as early as possible in the text, such as in the document abstract. However we might belabor the formal definition section such that the concise definition is sufficiently built up (eg end, e2e, e2ee) in the first section on formal definition. -Mallory > -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Mon Jul 26 18:05: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 283EC3A0C87 for ; Mon, 26 Jul 2021 18:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 h-U-1XXQn7Rj for ; Mon, 26 Jul 2021 18:05:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC343A0C79 for ; Mon, 26 Jul 2021 18:05:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BEDA7389B7; Mon, 26 Jul 2021 21:09:13 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8eDHS7eDd9Ez; Mon, 26 Jul 2021 21:09:10 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 36D6E389B5; Mon, 26 Jul 2021 21:09:10 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 83194454; Mon, 26 Jul 2021 21:05:26 -0400 (EDT) From: Michael Richardson To: Eric Rescorla , IETF SecDispatch In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] Comments on draft-jordan-jws-ct-04.txt 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: Tue, 27 Jul 2021 01:05:37 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > I took a quick look at this document and I continue to have the same > concerns about the overall approach I had previously, namely that > having allegedly signed data available in the "clear" is not in fact a > feature because we want people to validate the signature before While I agree with you that this is the right thing for data in transit, I think that you are presupposing a particular use case. For instance, some systems have a need to provide for a third-party witness= for data. The transfer between producer and consumer may itself be "secure". The witness signature has to be detached; it might not even ever enter the systems of the first and second party. But, I agree with what you said at the mic, that either make the transport not screw with the content, or make it the application's problem. As I understood Carsten's suggestion, we should canonicalize the data by turning it into CBOR, and using COSE. > You can then define the signature system as just operating on the > text as given without requiring it to depend on canonicalization. I think that the problem that they have is that they don't actually keep the text. Someone decided it was too expensive. They put it into some databas= e. I agree that it's probably not wise, and it creates a very poor audit trail. I don't feel as strongly as you about ISE. I don't know what I think. Mostly, I'd rather that there were inside the tent... (OTH, I've complained about too many WGs) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmD/W9YACgkQgItw+93Q 3WWFGwgAnvPJojJ6Oy4e+f+rKbKlfwiqZquEF2Sog0c30v3NGQYAGo9+V+2wUKnl AdV6uCWLuLPPiJ4XJXEyc0ujEGQz/K5y9YB5pUYzzCOgxDViwbEy/IjhqdsZ0dIX wxD/t6axtapyCoQGL4kNPj9NDOTM/pF+eEbFhb3y8uTFTNgZK1fuC3wUwB1RdQWY PrptjpadTA62kKjlxIli2Qp5NlJHkEdh59oID2GEURocWUksaxg29MIawnNMC2op jmE/pZD494M+r1liidvNP2C0TyH9wHowolQSnXX0hqmw0B54gQHcKV/xsUFUFQiv +2lhYYO/sA0jV/kHZKZLDcmEzAAiZQ== =Y4Dq -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 26 18:23:17 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 C6B2B3A0D7A for ; Mon, 26 Jul 2021 18:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 OddTcJkZ-E-Y for ; Mon, 26 Jul 2021 18:23:10 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB16E3A0D75 for ; Mon, 26 Jul 2021 18:23:10 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GYfDp36mJz31LW; Tue, 27 Jul 2021 03:23:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <656.1627347926@localhost> Date: Tue, 27 Jul 2021 03:23:05 +0200 Cc: Eric Rescorla , IETF SecDispatch X-Mao-Original-Outgoing-Id: 649041785.909597-9bded545182f3a4ba5af31561c829d64 Content-Transfer-Encoding: quoted-printable Message-Id: <3E3EBA99-16A7-44C2-9829-47AD681BEDDD@tzi.org> References: <656.1627347926@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Secdispatch] Comments on draft-jordan-jws-ct-04.txt 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: Tue, 27 Jul 2021 01:23:16 -0000 > As I understood Carsten's suggestion, we should canonicalize the data = by > turning it into CBOR, and using COSE. Actually, when I started saying that, I meant it as a reduction ad = absurdum. But after thinking about it, it is actually not so absurd, but the best = way to handle the use case =E2=80=94 everything is already in place for = that. But that simple change is just a different function to compute a signing = input from data at rest =E2=80=94 the more difficult question is what is = it that you compute the signing input of, and the fact that you now have = a signature for something that is in a complex and not entirely = well-defined relationship to the data that is in your database and that = you might think some subset of which you maybe have a signature for. If your application design can take care of that part, then you win (and = can use CBOR-deterministic + COSE, or if you must, translate to XML = first and do an XMLDsig, etc.). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 27 00:41: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 87ADE3A0A3D for ; Tue, 27 Jul 2021 00:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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=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 GWzk_eO6UEC0 for ; Tue, 27 Jul 2021 00:41:32 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 143233A0A29 for ; Tue, 27 Jul 2021 00:41:31 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id b7so13994724wri.8 for ; Tue, 27 Jul 2021 00:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OoQ7H8Gh9Swgx6HjYbMf2l57Oq3RDkxMN/HKeqCnmMM=; b=gJRn+Wz+Dn7j1YvuHWaaE8kuLskQfB8ZnAXa+kYPZ/oP5SJScWIROs/r+3MFXH7ASG HWJDO9xdpsxs1eldOaIdVC0+XSaEJ+UfifiG0bXjvbbyrGqQ2bemKyiUlYVVn7L02IGp gyM4DVSY+sJPM+ZZzjcBMQNprWJyLSWzHqmkso5X7xa473LjMbYyPJiEYQxHmGVh8J4s YRpU14G0r6LJOhpwf1eFbshO7EPeWsCFfQzNpWFVSyIFKWKq2GeJqix83zfAOget+45J h6pKCumSUNvICg59DeXdPyoWVJdk5PyfWx0g6yFIgKTa8HWy2YyQ1qg8+AY9t3c8rWaQ jL0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OoQ7H8Gh9Swgx6HjYbMf2l57Oq3RDkxMN/HKeqCnmMM=; b=sjqxHI9nUQz+57jczK5zcIcFhcoynv6cPqiOY5E9WCDKVtfM1CYEi7MqRnFp2DPxBv hWDqFDN1TscA9SAvdRf7Zhcqdlwk3P4wjCyTqLOyvnYtAPWmASuNN3sgSRXF3Dy1/7gg ZKXi5hVMy4oeOJxYRYi79ggWeR6MxAtxvV9mB/5cdNUga9Bv/xHcqOSSkL05CWrMEh3Z 1aFvDCPbYZytvMBSh+iZ1zDJcrHmArARkYjyZkEWymL92mQ7vynOwGJjs9sp26p1mSW5 GUbUa5nGA+uuQabWchFTZmBfcdyOLHveOgULXN+EHi98/Q5S0fu3YQm5QtPJW7HIWiUh C6wA== X-Gm-Message-State: AOAM530SLUfk4M/wP/cZLPZob39ADF59Jjz8LiHWahuYHW05MqhQnQgu nF7Y13xfihiFgEFyvHUNGnEG0mBAZSbEQg== X-Google-Smtp-Source: ABdhPJzACGbUvUhnIOdjU1ackx2SfuKV5JHTEnjXyOI1MIA4j4Rol08sa6ORVCHODYfBLySR046Lig== X-Received: by 2002:a5d:5987:: with SMTP id n7mr23149512wri.263.1627371688367; Tue, 27 Jul 2021 00:41:28 -0700 (PDT) Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id u2sm1915749wmm.37.2021.07.27.00.41.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jul 2021 00:41:27 -0700 (PDT) To: Carsten Bormann , Michael Richardson Cc: Eric Rescorla , IETF SecDispatch References: <656.1627347926@localhost> <3E3EBA99-16A7-44C2-9829-47AD681BEDDD@tzi.org> From: Anders Rundgren Message-ID: <22ea0a96-345d-6272-b287-a2ca78d87e33@gmail.com> Date: Tue, 27 Jul 2021 09:41:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <3E3EBA99-16A7-44C2-9829-47AD681BEDDD@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Secdispatch] Comments on draft-jordan-jws-ct-04.txt 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: Tue, 27 Jul 2021 07:41:37 -0000 Unlike JSON which nowadays [1] have a working deterministic representation [2], CBOR leaves a good portion of this crucial part to application developers to figure out. The net result is a fragmented CBOR space with groups like FIDO creating their own unique definition called CTAP2. The authors will consider the ISE path for the proposed work-item. thanx, Anders 1] Encountered floating point parsing and serialization issues have been fixed by the platform vendors which makes the task creating an RFC 8785-compatible canonicalizer quite simple. 2] By constraining the Number type to IEEE 754 double and requiring the String type to be immutable. On 2021-07-27 3:23, Carsten Bormann wrote: >> As I understood Carsten's suggestion, we should canonicalize the data by >> turning it into CBOR, and using COSE. > > Actually, when I started saying that, I meant it as a reduction ad absurdum. > > But after thinking about it, it is actually not so absurd, but the best way to handle the use case — everything is already in place for that. > > But that simple change is just a different function to compute a signing input from data at rest — the more difficult question is what is it that you compute the signing input of, and the fact that you now have a signature for something that is in a complex and not entirely well-defined relationship to the data that is in your database and that you might think some subset of which you maybe have a signature for. > > If your application design can take care of that part, then you win (and can use CBOR-deterministic + COSE, or if you must, translate to XML first and do an XMLDsig, etc.). > > Grüße, Carsten > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > From nobody Tue Jul 27 03:12:41 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 A08E43A1E46 for ; Tue, 27 Jul 2021 03:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=mslSf89/; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=mslSf89/ 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 K5hKsdCetUqK for ; Tue, 27 Jul 2021 03:12:35 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2063.outbound.protection.outlook.com [40.107.20.63]) (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 7AB0A3A1E41 for ; Tue, 27 Jul 2021 03:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=34y+LuASu5u4a48wErn9nKoHdP+Gb+okMaAEAxYAFAI=; b=mslSf89/gZIgj46zUFZJ1PfxT//qmobx+L6AQAd5mQXQfunfgjbyt+RAbtlD931U6ZIntTBkMUb2JWCJ5imMVK5/k1OfdXH8E5Ph3E+p0b8CP6I0OaLmCMo9zafYZrREgTBS4KRdNeEOuffJB926Y1DFbciCFxeV2YmWunfXh+k= Received: from AM6P195CA0057.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::34) by AM0PR08MB4194.eurprd08.prod.outlook.com (2603:10a6:208:130::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.26; Tue, 27 Jul 2021 10:12:32 +0000 Received: from VE1EUR03FT041.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:87:cafe::fc) by AM6P195CA0057.outlook.office365.com (2603:10a6:209:87::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18 via Frontend Transport; Tue, 27 Jul 2021 10:12:32 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT041.mail.protection.outlook.com (10.152.19.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.24 via Frontend Transport; Tue, 27 Jul 2021 10:12:32 +0000 Received: ("Tessian outbound 31e6e3649d31:v100"); Tue, 27 Jul 2021 10:12:32 +0000 X-CR-MTA-TID: 64aa7808 Received: from 105736e04c14.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8F23122E-DB3A-45B0-894E-B1E718163380.1; Tue, 27 Jul 2021 10:12:25 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 105736e04c14.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 27 Jul 2021 10:12:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KXbBPqs7sHSbr7FpmDTxbvO5KOPi7GgyBPV6DxMo+/n7NAbqGTvK7+M7FKQmrSJYmeV9GDoFqw7qgmEtQZPx74blicM2ToBa8UEK7HHCl8rNrBLQiA+fD5iUd66nB0UnnveQC6h/J0eXDpxrFCbx398tGku6SchzlYv2B9frQYyeOO6HiPb2WHtxHlJwLte+AUggC1wHFaACNwXfC2XhtxdT/wwIWHSSUyFJIo/wLENZmikIHHou7DX5Q8vIPxSF51D93jy1SqAMcmDYiGOxJ6uPgZuvaWJYirqR5o+s8UJks8dUIO4hZtqAIPCmbBbpXiyE1xFfQ2cowVNf6iRpZg== 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=34y+LuASu5u4a48wErn9nKoHdP+Gb+okMaAEAxYAFAI=; b=PX2bL6gUU/ZnkdNXtqaefVkt+a3Jxo8dR6z01ySXHU3YEMaSUN8kI6TKG50smXelkLz6qpnww5qXTvIEvFvPPqrpxFeupc9MYQdNGfccfj5/Cp82Z4ehQK9CoVdSwpn8UfpJKa2pCUD0yFQePeoT7ABTPeD3ptTc8NZtkyBAJb3BJnWO6mBFBuEA7Z7qwQ2nGGDSzNQUnYIVyVduUYzw3cBdbzy7hpiRAN/Vzh6voyUPwyocogsKPNthxZwBjLVc8LuQYP3rmBInpUOpqJtJ4I6K0WxOQNlKrjfIiBkTqlvCNMiNRkwmtYppjlwTJkfBCswr8U7mvgPF8BSHPivPZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=34y+LuASu5u4a48wErn9nKoHdP+Gb+okMaAEAxYAFAI=; b=mslSf89/gZIgj46zUFZJ1PfxT//qmobx+L6AQAd5mQXQfunfgjbyt+RAbtlD931U6ZIntTBkMUb2JWCJ5imMVK5/k1OfdXH8E5Ph3E+p0b8CP6I0OaLmCMo9zafYZrREgTBS4KRdNeEOuffJB926Y1DFbciCFxeV2YmWunfXh+k= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DB6PR08MB2790.eurprd08.prod.outlook.com (2603:10a6:6:1d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.25; Tue, 27 Jul 2021 10:12:24 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::55c7:8f34:351:9518]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::55c7:8f34:351:9518%3]) with mapi id 15.20.4352.032; Tue, 27 Jul 2021 10:12:24 +0000 From: Hannes Tschofenig To: Mallory Knodel , "Salz, Rich" , "Salz, Rich" , Eric Rescorla , IETF SecDispatch Thread-Topic: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 Thread-Index: AQHXgnMxzHpGF+J25E+iZ6PzfThCvKtV4gkAgAALSYCAAACUgIAAEL0AgACZFcA= Date: Tue, 27 Jul 2021 10:12:24 +0000 Message-ID: References: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> <416C1A8D-4F95-4E25-884E-1A18EEDA6988@akamai.com> <593fc980-7549-81a0-8618-a5c1a481b1bb@cdt.org> In-Reply-To: <593fc980-7549-81a0-8618-a5c1a481b1bb@cdt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 214EEA68751C264CBC19CD136514D2FE.0 x-checkrecipientchecked: true Authentication-Results-Original: cdt.org; dkim=none (message not signed) header.d=none;cdt.org; dmarc=none action=none header.from=arm.com; x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: db8f19ee-856b-4d27-8a98-08d950e70c76 x-ms-traffictypediagnostic: DB6PR08MB2790:|AM0PR08MB4194: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6108;OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: XFhp3Ebd8BZ/0m/JEWDvImftIiGA3ODCg0ANhnIsd+uWaxulu5GSkcEqQEG2J1UbJpHe1ZjWFGH98pgERbM6VpnxjHTU8O91YPfTbTUAvV0amKTbtNDAlethvw/SdBjsejb0KjkDqPem6xYDS/87Hcnee9cC55pAPIvFnlrtOesZptWyapAfG0xSwSqOswt/zEq+dbJ+UrMNNvlH3z3d6czZo2Sb9NVAYUCHKuN4qRz2GrCRt0C2z3+ZySwICbILNzU0CCC8aNiCWdGkU4UfdLa2bfds/xOt76xHZdE9/VoS8Y9jdKBZAQQaklQAh2OUuDERub4WGwS2U5Th6mUgAWBrGVIMaaXYoYFOw/f3l4lNgT2MQ3aFvzrCX+TwThr2nTB6JqKx+cY3AfCCp/OXwUBFfA2nGOsbMDla/K+GvGhWsYtRoG3HU9aRPRDf4VXmy/wUSA5QWj6hCUrBYAuKb08C2m6daLsu4lDsN22s8dwEbaGycAJ8Z/HoUiAeegRcl1EkFrKCa75qAK9h0awPt9A814gPdzRVBIlrhaZFJUx4ImSIRwJ5Fn0GzhEsRFTno2U87Q63b3ULOixeqbiGbxpPWyyUT2f11XI3FWjY1fBnUh0K2xv20D75DEG21EYP5gUQyh9TXse9ShFz+iKPMueWvyctcAoOo+NnjSm/J1ZA2DpSjcCLOH17Xy7xlQ07FP9EaaJdNBicrBQ5v5+LRGGQ5r4UgOYlzmzqsAlwypZ37oZjPjLyClBfBexcYN4rB2k+m545fUonMyUeD0NZXAGox+A5OjO1lUwgurBh99A= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(376002)(136003)(346002)(39850400004)(66446008)(33656002)(86362001)(110136005)(7696005)(8676002)(186003)(478600001)(122000001)(6506007)(966005)(53546011)(26005)(38100700002)(76116006)(9686003)(316002)(83380400001)(8936002)(66946007)(52536014)(55016002)(2906002)(66476007)(71200400001)(66556008)(64756008)(5660300002)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?EeWHVvLAToy+O/1wz6WCPN2Z9jiS2KKBq10zd41P86Vool0IPaxoNDxL7jvQ?= =?us-ascii?Q?G0wypj5M17DgQOqgN2jJ3kakLKnfdNwRsEAplf0tOsRslnWUWyow/rG8284u?= =?us-ascii?Q?3JPDyLu/7/Rn/DDm5EEvnI8Kb/h2ASDMQEpp/EW24VPL5DSkmu++dm5g8qW9?= =?us-ascii?Q?7UfxjpW1Hd899AxI4nK6KPJqJ0N1DcFUrI6n5bNjXgoRTVFQjjiYaZoFIiQ4?= =?us-ascii?Q?OQwgnlZ+1pJNp0wmwSPPgmwYTat+4aRJiv0XP9gJkq6qOzSneB0V5kyF1EJo?= =?us-ascii?Q?H4yDibKbL6MATtaMJHZF3pP82V2nwEVNggPKtalIO8UC5cronxT/i5E/CbME?= =?us-ascii?Q?3nLBoM2YPQI72zbu8dCapzyRpKTSVMpOEgO/0ckCdYFhoNWn3hRTYSnLSGoU?= =?us-ascii?Q?v9U+g116xNtsWHGhJ9NBkmqzMxgd2HaDcdeurQHqye7SRj8Rxo1Nh0tJDDTm?= =?us-ascii?Q?Wflz7+RW3dWlkCQ/Qj3f8z8Ya9r0zsTiZsGF/5gE19GwlGHrfFP7VT2gopFY?= =?us-ascii?Q?dYRwtXUj4MKddlM08LtMKo7/pEQB4/AMXkoZyRiFjF9L8hH/K9PE8N0hQmzF?= =?us-ascii?Q?bPSaln5TNYgSfW7BvT2jth55ztNwa4ibN5rLoIJkkooJmxGXSUMcaRzlZG9b?= =?us-ascii?Q?pKn9or+1y0QjfatYnvzGWwJOD7FaRItuQhwTX3oMi7A8ircBWRA5Qvz/mjZh?= =?us-ascii?Q?C+chX6a3NtJs9tirwkLInHIC0RrRjdeefxHzLUUIUoWDseS/Q3qTKxkJ9Mq8?= =?us-ascii?Q?1YQQqX8br2D12pOSMUEBqpNA4kN8IXtSWrrQPOSvFV64PoDcZ7J29TmwgLjM?= =?us-ascii?Q?7DFDQnIoEr75lKyO+z2kI3SqYclWd8XjqyLuSQaxK4gLY0l5Kebd51/MFvIx?= =?us-ascii?Q?fJu7FV4kmkmcGvivhO7nZWjpwIgLd8jUmwwPy1RvfrCQVPPFPlZEpewWBJWA?= =?us-ascii?Q?PRL+TJG+bN9oS+1WE5lMZ3UAVDt3L+hUDgaXXo/4oREIHKZVe89fIN6F10hM?= =?us-ascii?Q?ukSyjLBppLE5M261SJfLGtZxVUixI8Xao0gxl1u/ABRTAyvFPrR8jLqV7+Ra?= =?us-ascii?Q?x3iFBdOpcEHFj4XtJzrngsQoiypxXN1iH/WG2kmafnaUIvBcMxTROGHeH6I1?= =?us-ascii?Q?W4qxsjU71QuEUNf23zqA4BtGcrCzSUOIPvv1tlyp/kfZJ8ntx5KTMRSTYKbx?= =?us-ascii?Q?warBYMCzbgSxFhvPC9mOv4iovxZQUIVPHQA6iQK0wOEAXD7B4C7v9vPKVGyy?= =?us-ascii?Q?ua+y/+UCI307P1llDagoqoX2FjdqiVSkhhJoHD/Iniz75d4GqiqFBJ96D9TC?= =?us-ascii?Q?/KI=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2790 Original-Authentication-Results: cdt.org; dkim=none (message not signed) header.d=none;cdt.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT041.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: b4af2872-84c0-45cd-79c9-08d950e707b7 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: P7Ez8HNtYKuLoknH/hQlHQl4pGcoqhXPl/67udin3hJUk/uPwSOLd8fYRpn8qzAUUARHsvRXjrftOtT744DThFvp0VDhDrM6GFpCGB+b7ZI4SWTtugRLUpUpEGrVuGlWgU/h6tGSwbFfrueBU8dQYxzBoT3xoiphkNNxcDbpIwc3agkxv52vR7llu7/Mdj5VzeijnHi1+jB15J0bBBafGJrjencyWa0ULJS40eHYBlegm45qRx9JL7Vgmy03o1YAhDJyPFE7C8twTnu+mslpkUQyaKxaIZ1OzxLgj1D0HDR79G0JC/tH8Fj2xLQBALiLJVcIbl1vjmgz+hIExc8Wbv7+ZDKxdk+CugRjBUMHwhI38L417eQLX36rLcm9ajBZ3eHrqpgce5lHRH6VYmkxoiBgfaJwlmbuqgKhuX7oxiZEDRJ0sWrv/jJTzmu4eNT5F5qveWwxZchMz207gwmD4CV5G/teCOkjVwZWlYxS8ZhVf7ahkNA7p+Q4amRpKs/OLvgVHm9QSzgIlQlUjbbLVM0tSJbLU5PPe9lNgyyrbcRiSPs7IHdUiSRsLnZkefQ569Mr9g0V1SQNrtWYCyK4bYo9kodMEN61i3u4Q2YaSCEcaDSJKIUT2sT8ouQl9lmx9nAkSpQTnzvBMK+BGBAKFepqm0+820Wonl1YuJxHVhQn1lNFokNgjWkrrNCs8QeeW96a5wyeYsW+wYGbjP+A/Gu384GssVpRfsUVvACh64G7VVOamThPW5eutLRfCVzTrN64NJs4ix+JuDqKQy8TANUjhe9YuZKPlpEkj6N9Mw4= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(46966006)(36840700001)(316002)(110136005)(5660300002)(70206006)(70586007)(7696005)(9686003)(6506007)(53546011)(8676002)(55016002)(356005)(83380400001)(26005)(8936002)(47076005)(52536014)(82310400003)(86362001)(336012)(2906002)(966005)(508600001)(81166007)(33656002)(186003)(36860700001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jul 2021 10:12:32.5189 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: db8f19ee-856b-4d27-8a98-08d950e70c76 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT041.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4194 Archived-At: Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 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: Tue, 27 Jul 2021 10:12:40 -0000 There are a few challenges with the use of the term "e2e security": * First, it became a marketing term. Many want to label their solution as s= omething that provides e2e security. * The end points have different meanings to different people. A VPN is an e= 2e security solution if the endpoints are the laptop and the VPN gateway. * There are other security aspects that play a role in the benefits it prov= ides (e.g. who has access to the long-term keys). Ciao Hannes -----Original Message----- From: Secdispatch On Behalf Of Mallory Knode= l Sent: Tuesday, July 27, 2021 2:53 AM To: Salz, Rich ; Salz, Rich ; Eric Rescorla ; IETF SecDispatch Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 Hi, On 7/26/21 7:53 PM, Salz, Rich wrote: >> I think if we got to this place in the first section, we would >> summarize > this concise definition in the abstract of the draft so that it's th= e > Very First Thing. > > I don't think I understand. Are you saying that you support a merged doc= using Alec's as the new "part one" ? Only commenting on concision: A concise definition would be nice. Putting such a concise definition would be best placed as early as possible= in the text, such as in the document abstract. However we might belabor the formal definition section such that the concis= e definition is sufficiently built up (eg end, e2e, e2ee) in the first sect= ion on formal definition. -Mallory > -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 = B240 BCD9 B071 0C32 A271 BD3C C780 _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue Jul 27 03:58:22 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 B50A93A1FE0 for ; Tue, 27 Jul 2021 03:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 y7Q3EdXcOPgm for ; Tue, 27 Jul 2021 03:58:12 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 926303A1FD5 for ; Tue, 27 Jul 2021 03:58:11 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GYv0C4bYXz31M1; Tue, 27 Jul 2021 12:58:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <22ea0a96-345d-6272-b287-a2ca78d87e33@gmail.com> Date: Tue, 27 Jul 2021 12:58:03 +0200 Cc: Michael Richardson , Eric Rescorla , IETF SecDispatch X-Mao-Original-Outgoing-Id: 649076283.17739-f776201577c97c8954d228535c59effc Content-Transfer-Encoding: quoted-printable Message-Id: <01DD5A19-C35F-4757-B7D1-D94C5B180918@tzi.org> References: <656.1627347926@localhost> <3E3EBA99-16A7-44C2-9829-47AD681BEDDD@tzi.org> <22ea0a96-345d-6272-b287-a2ca78d87e33@gmail.com> To: Anders Rundgren X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Secdispatch] Comments on draft-jordan-jws-ct-04.txt 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: Tue, 27 Jul 2021 10:58:21 -0000 On 2021-07-27, at 09:41, Anders Rundgren = wrote: >=20 > Unlike JSON which nowadays [1] have a working deterministic = representation [2], CBOR leaves a good portion of this crucial part to = application developers to figure out. > The net result is a fragmented CBOR space with groups like FIDO = creating their own unique definition called CTAP2. Statements like this are a reason why I=E2=80=99m calling for some = supervision here. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 27 04:45:42 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 418E03A2118 for ; Tue, 27 Jul 2021 04:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 BCWTcDzlZmTt for ; Tue, 27 Jul 2021 04:45:36 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 B41143A2115 for ; Tue, 27 Jul 2021 04:45:35 -0700 (PDT) Received: from [IPv6:2a02:aa15:4101:2a80:cc8a:6ce0:76e7:c1a7] ([IPv6:2a02:aa15:4101:2a80:cc8a:6ce0:76e7:c1a7]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16RBjVQb052543 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 27 Jul 2021 13:45:32 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1627386333; bh=mKR2XDTfF46QsIm36sirxrelEo2G0tqqMtVLk2VQ9mk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=d6vXc6fSQMciSLkJIHqiMiu80zbq3wBtmcT4DoYiTirmWNTqkz+OxM4AvkuSh+mmA N9UCo/j/5X/w6jzjXEBZt7PVvv8l9PggzlwpBDeDo29vmQiViokZNXGuyMQlroxu2u 3nzjARK5wVWFXUGiZnT1V9AXb5N2eSK9b+G4QNJM= To: Eric Rescorla Cc: IETF SecDispatch References: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> From: Eliot Lear Message-ID: <2411598a-8989-59a0-0fd6-a06976e84287@lear.ch> Date: Tue, 27 Jul 2021 13:45:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0gevKm1yGKMqRtRJx9LdwmwVLYaTcCL7P" Archived-At: Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 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: Tue, 27 Jul 2021 11:45:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0gevKm1yGKMqRtRJx9LdwmwVLYaTcCL7P Content-Type: multipart/mixed; boundary="678Ztx2e38POb1tWX6uJ8EvYbu0yZK6xI"; protected-headers="v1" From: Eliot Lear To: Eric Rescorla Cc: IETF SecDispatch Message-ID: <2411598a-8989-59a0-0fd6-a06976e84287@lear.ch> Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 References: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> In-Reply-To: --678Ztx2e38POb1tWX6uJ8EvYbu0yZK6xI Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 27.07.21 01:50, Eric Rescorla wrote: > I took a quick look at his draft and it seems like there is useful=20 > stuff there as well. Perhaps some kind of merger is possible? > Yes, please.=C2=A0 Alec's work seems like a nice, formal, and most=20 importantly easily understood approach.=C2=A0 That makes it a great start= ing=20 point. Eliot --678Ztx2e38POb1tWX6uJ8EvYbu0yZK6xI-- --0gevKm1yGKMqRtRJx9LdwmwVLYaTcCL7P Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmD/8dcFAwAAAAAACgkQh7ZrRtnSejOW 4ggAtrzfwITXdixkfcwVwFRY8g4UtCJVfgJE/BkBrnrwmbUaaf9QELYEXDnH2QJpWnsyopewEKtJ xM94IyuKw0PxDPBKbx9mzHXcJWnqVhK+KB2zYXMz8eEm+FZizPvsRZps3P09+qTC5n2OxyipRdUD PT/Gc3pfMmfG7/aYiOnt+CfaWvkMIfhxTEqlFRGS11IhpIJjSjmCCjmZ7uio0IujeNg3ZaovmFTs uribWoYWfR/TaHrVCmWKl1b9cKhyvR+rjdstCewcxPBxhbKsWwIC19/4FvAJ6fwOvhK0DsAtl0X4 oExru1yeJ8OAzOFIvdFwBLQTglO0rB8uWre3H/7SXQ== =kr6F -----END PGP SIGNATURE----- --0gevKm1yGKMqRtRJx9LdwmwVLYaTcCL7P-- From nobody Tue Jul 27 06:21:00 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 189CB3A0818 for ; Tue, 27 Jul 2021 06:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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=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 plYIAOHSbSfZ for ; Tue, 27 Jul 2021 06:20:54 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 AA07A3A0811 for ; Tue, 27 Jul 2021 06:20:54 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id l24so9477124qtj.4 for ; Tue, 27 Jul 2021 06:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:subject:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=9QWMGZQ6prXcxdZYVgi3x2C9tbm92JEDdf6BwTjIEkk=; b=IB6YnQLG2aOj9PR0kI9zcmjjt79VjIRoQaSqI0eDuG/JnAZDz79wr5wUsLGrnA3cVf IWeP0VNS4VrjCDTni+cb2vfk6XvsPy5c+92Gn1xSXPX0gdRyYJneyADQ1f6StDshaFo6 7JauIXs1GixadLJpzdzuzZRxlbGQxccx4H5lEye4GEut4bVWYp0ZAmFTriFLgvo7kcVr 1sU6B0hJjO+mLQv2DdU0KaZ5Yp4yYgoVC7zEdveKjuCZoHmeoh8mlShcdSXAXjJDBhvh Ij6U7zAGZPJKKOl5gbV1V6AKeqgkbN5kQQGVoiwnEJRlZlgKxXmkRnnkXyyfc+tSOF// MBWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:subject:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=9QWMGZQ6prXcxdZYVgi3x2C9tbm92JEDdf6BwTjIEkk=; b=rjrmlsBocoTEiJOHEU94JUrpQLdPabC5buGOkVjcirBN8fO9PLHMI9fyNJzlZpDvjU Im75wBjpd0YpyeiuhQb+aHDIEiHo8MLz6TpJABLoJhRAgeHaSHHi1gLuxj5pzql2Oqbf svPOkO3lCBTYlPdbcNamC2MS2qOFSIR+Hn7GS68/Wbmz8BuajcUpPH1t2/5mjD1cUh6S zSuPtUCXzr3T3sNR4BPc7iYagKC7WthQQQLtVWgcJXoNGSdM1kmdcZPevIgexHC4NAoK eJjsa1x2xGwRbD6kBszWHOUMRmHufioou1HbNesXMdoQveGVu2bg5ByzxcRz7szV8kYc DZ4w== X-Gm-Message-State: AOAM530GLMorPxQ5zrhTiumAkj8AcIlyjUECik8MTSPfBEURYND5mMG6 zVUWNPaMofiZYMvMO6MHsGigccXurB8= X-Google-Smtp-Source: ABdhPJxSXH/pQ0LBJ3emgXbXeWQ2SVg5/J3HKB5/KdXlvCochYRKAfGyHZL9MybXOXKpSMH9cpCWMg== X-Received: by 2002:ac8:4e88:: with SMTP id 8mr9036830qtp.269.1627392052833; Tue, 27 Jul 2021 06:20:52 -0700 (PDT) Received: from ?IPv6:2607:fea8:8a0:1397:a588:19a7:b0c1:ab84? ([2607:fea8:8a0:1397:a588:19a7:b0c1:ab84]) by smtp.gmail.com with ESMTPSA id 141sm1705667qki.15.2021.07.27.06.20.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jul 2021 06:20:52 -0700 (PDT) From: Rene Struik To: Mohit Sethi M , IETF SecDispatch References: <9218ba42-1a81-8a82-4850-be3ca57f2894@ericsson.com> <919f0c47-c5ab-6bfa-48a0-93a7b2f0856b@gmail.com> Message-ID: <37f39465-0373-0a33-475c-2584706814ed@gmail.com> Date: Tue, 27 Jul 2021 09:20:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <919f0c47-c5ab-6bfa-48a0-93a7b2f0856b@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Secdispatch] Preliminary agenda online 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: Tue, 27 Jul 2021 13:20:59 -0000 Dear colleagues: At the end of my presentation yesterday, Ben Kaduk asked about batch=20 ECDSA verification speed-ups with single signer and with multiple=20 signers. The suggested speed-ups in the draft [1] are ~1.3x for single=20 verification and up to ~6x for batch verification. If all signatures=20 have been produced by different signers, one can achieve a speed-up of=20 ~2.5x (still respectable). Usual caveats that these are ballpark figures = (which depend on, e.g., relative cost of field multiplication and adds)=20 apply. Ballparks above are for NIST curves with Jacobian addition rules. As already indicated in the email below (July 21st), the draft does not=20 contain new crypto and only uses a public and reversible (r,s) to (r,-s) = signature transformation, if need be. This should therefore allow for a=20 very quick start-to-finish project, where enabling this simply depends=20 on defining code points or another unique cross-reference and getting=20 this out of the door. Best regards, Rene Ref: [1] draft-struik-secdispatch-verify-friendly-ecdsa-00 On 2021-07-21 11:15 a.m., Rene Struik wrote: > Hi Mohit: > > I would like to discuss=20 > https://datatracker.ietf.org/doc/draft-struik-secdispatch-verify-friend= ly-ecdsa/=20 > > > This draft discusses representation of ECDSA signatures that allow=20 > fast single verification and batch verification and which is=20 > consistent with ordinary ECDSA signatures for prime-order curves (such = > as with NIST prime curves, Brainpool curves, secp256k1). To enable=20 > verifiers to reap these benefits one simply needs a flag (code point,=20 > #) to indicate ECDSA signatures have been put into this=20 > verification-friendly format. The representation change can be made by = > any device, not just the signer, and can thereby be made retroactively = > (without need for new signature). > > This draft does not deal with new crypto, only whipped-up=20 > representations: it simply uses the well-known fact that if (r,s) is a = > valid ECDSA signature, then so is (r,-s), to effectuate this switch=20 > under certain conditions. > > Batch verification speed-ups (up to ~6x) have been known since the=20 > 90s; single verification speed-ups (~1.3-1.4x) for at least 16 1/2 year= s. > > Intention is that IETF could (perhaps: should) use this across the=20 > board, so as to reap benefits for verification devices that wish to do = > so (one can still use slower techniques if one does not wish to=20 > change). To realize this, one simply needs a brief description and=20 > registration of flags to indicate this. {In other words, this could be = > a very short project to get to wide-scale use. The current draft=20 > contains most info already.} > > History with IETF: I discussed this with lamps at IETF-110 [1], but=20 > despite positive feedback (from, e.g., Scott Fluhrer) lamps did not=20 > include this with their recent re-charter yet. The simple technique is = > broader than just lamps, though, and should be beneficial for any=20 > deployment (certificate transparency, openpgp, pkix, etc.). This being = > said, perhaps lamps would be a good starting point. > > Best regards, Rene > > Ref: [1]=20 > https://datatracker.ietf.org/meeting/110/materials/slides-110-lamps-ver= ification-friendly-ecdsa-00=20 > > [2]=20 > https://datatracker.ietf.org/meeting/110/materials/minutes-110-lamps-01= =2Epdf > > > On 2021-07-15 5:57 a.m., Mohit Sethi M wrote: >> Dear all, >> >> The preliminary agenda for Secdispatch @ IETF 111 is available online:= >> https://datatracker.ietf.org/meeting/111/materials/agenda-111-secdispa= tch=20 >> >> >> Let us know if you notice any discrepancies. >> >> @presenters/authors: please send your slides to >> secdispatch-chairs@ietf.org early enough. >> >> Kathleen, Richard, and Mohit >> >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch > > --=20 email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 From nobody Tue Jul 27 06:29: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 3969B3A08A6; Tue, 27 Jul 2021 06:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=akamai.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 45jmf_Hx02jA; Tue, 27 Jul 2021 06:28:57 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 8B9D03A08A9; Tue, 27 Jul 2021 06:28:57 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16RDEvCO003615; Tue, 27 Jul 2021 14:28:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Wg6rHz64SUU2UpvPF6gtdJz6zYT7AfztsBl3IJ0tHiA=; b=bWLFZxMDWRihm4OGvr8FQhTZqPBn01/RLCa2labF9+gZ1pEKBKUq5W5cXLb+wrvpQtvu TIK70KdUiHNwrNJ0XzTpw4gsgf2kyQOXf4RMMhH5U/NDzgQMDUokRRR2Vr0JRY3MmBKr j3QlqJbp5N5ko53Dqx3QxA3RaqC+tgowIYfAesF566Mh4xJsJtNMPttcVIBzYDDZGbLK 4PUDCUlp0bHv6Z6LdlwtDiex0wOL/3EHwmy0bx/aUav6Hy58xPn7/IE1nO2ch3yxdBtz m6HpPnF7YTmJHKZzSUsOC75TqFKy3+Qjk2cAB/h68YqHrmGfnjutRo9bNL08CM5+QTGk UQ== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 3a236qde23-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Jul 2021 14:28:52 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 16RDJlRv028493; Tue, 27 Jul 2021 09:28:51 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.118]) by prod-mail-ppoint4.akamai.com with ESMTP id 3a23cvnkc2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 27 Jul 2021 09:28:51 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Tue, 27 Jul 2021 08:28:50 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.023; Tue, 27 Jul 2021 08:28:50 -0500 From: "Salz, Rich" To: Hannes Tschofenig , Mallory Knodel , "Salz, Rich" , "Eric Rescorla" , IETF SecDispatch Thread-Topic: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 Thread-Index: AQHXgnMvZOeW0gM1mUyhMikJrLTT2KtV8ssAgABOWYD//72EAIAAU80AgACcQAD///PSgA== Date: Tue, 27 Jul 2021 13:28:49 +0000 Message-ID: <453379FF-231D-4A51-8885-A24498569E5E@akamai.com> References: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> <416C1A8D-4F95-4E25-884E-1A18EEDA6988@akamai.com> <593fc980-7549-81a0-8618-a5c1a481b1bb@cdt.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.51.21071101 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: <3870BDF1C7ECC6429094EF82F48C8E9F@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-27_07:2021-07-27, 2021-07-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 spamscore=0 mlxscore=0 suspectscore=0 phishscore=0 bulkscore=0 mlxlogscore=732 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2107270079 X-Proofpoint-ORIG-GUID: RXoWZ_UCl7_eH1Htp6ovXUydl4bYPRTY X-Proofpoint-GUID: RXoWZ_UCl7_eH1Htp6ovXUydl4bYPRTY X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-27_07:2021-07-27, 2021-07-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 phishscore=0 adultscore=0 impostorscore=0 priorityscore=1501 mlxlogscore=697 clxscore=1011 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2107270079 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.32) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint4 Archived-At: Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 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: Tue, 27 Jul 2021 13:29:02 -0000 PiAgICAqIEZpcnN0LCBpdCBiZWNhbWUgYSBtYXJrZXRpbmcgdGVybS4gTWFueSB3YW50IHRvIGxh YmVsIHRoZWlyIHNvbHV0aW9uIGFzIHNvbWV0aGluZyB0aGF0IHByb3ZpZGVzIGUyZSBzZWN1cml0 eS4NCg0KVGhhdCBpcyBpbXBvcnRhbnQsIGVzcGVjaWFsbHkgaWYgd2UgYXJlIHRyeWluZyB0byB3 aW4gd2hhdCBpcyBhICJ3YXIgb2Ygd29yZHMiIGFnYWluc3QgcGVvcGxlIHdobyBjYW4gc2F5ICJs YXdmdWwgaW50ZXJjZXB0Ig0KDQoNCg== From nobody Tue Jul 27 07:29:14 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 15A453A0D78 for ; Tue, 27 Jul 2021 07:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 p-2abGFXRLms for ; Tue, 27 Jul 2021 07:29:07 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30085.outbound.protection.outlook.com [40.107.3.85]) (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 598BE3A0D81 for ; Tue, 27 Jul 2021 07:29:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LCvfuZn9ZGxn4Jormmq8CPi1mvRqgexL18N3NB8bxHGpCRL8b1IA7uYYYlf6wuW6/IrhOkfgD6sviS/ueFiZVrJufzm8eguVtZcQAvDEXJNGXFpevtZb8R9r87mE2to8Pio0XcSrZMHmiBfi62yUWsA5qqKyMWZjKYr9R/mQo9l73e0+OgbN7Nnmawf9kW1I1gcrrZGvMh5EnnhB9TMpVWAFWFIXz25Hvj231KREYCwRP8FP6TGMn9SEVNKHYq+aFRftmg9nIYFwdCX5Aqfqadw1wQtDA+WAbyKecyO5BGTvSp6tt7u62MU6vrsdxWZLapCb04APL9LtvG6ZMAlifw== 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=a9oEA59hGwBLbpOiIsC1Db3p2br+n3g35+Ct36kTEhs=; b=L3L/r/ov0WHUjR7jxU5JvVFAoAR624a9Iac/1arTjAncsvJ0g49xVAmy4qoFq4HribZFefbyoHCKW0+ozPtBPsN4sZ2TtmDE/ZA9vxEkfk3cogYbhI76wznjA2pzLi8dpuUZK+r4m3Txhf2GhK6j1fgydvKAf4djQeaC1gsunbkcagLoO8lU/shBo6hZWTDB/1w8SLqoNSVZwGCF8gPb1WmjTbWGmSXZRPbXWVCIvD+k2KmsxwlH7nfRI8jVVJuZLE3QX2UzHBaNxZlbY4zyt4hA3NTHb+BXT5kgUfWMdCSENUYuKfW3vahsGncySYP96gTbAJslu1zU6Vh30y1ACQ== 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=a9oEA59hGwBLbpOiIsC1Db3p2br+n3g35+Ct36kTEhs=; b=NCuzFU1fB+WQVfb3wsOmtwFr307xYCYQCp1oxsmnRrj5FWz33p16T9k4bzTdDjqdE08fyMIWm0qD1Y2rTMpuM1h1jjoz2VB0JX0zJd7awnk29kTzFCzMQ9nKpQ67/Pne2OW7JpC5o7KqYuUTMNvneR1jnbGktp4wU5hRH8fm9rs= Received: from HE1PR07MB3436.eurprd07.prod.outlook.com (2603:10a6:7:37::31) by HE1PR0701MB2731.eurprd07.prod.outlook.com (2603:10a6:3:91::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.12; Tue, 27 Jul 2021 14:29:04 +0000 Received: from HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::c04b:9f4f:3494:b84c]) by HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::c04b:9f4f:3494:b84c%7]) with mapi id 15.20.4373.018; Tue, 27 Jul 2021 14:29:04 +0000 From: Mohit Sethi M To: IETF SecDispatch Thread-Topic: Minutes from secdispatch @ IETF 111 Thread-Index: AQHXgvPAP+QI/ES7WU2hJxsRgvWBRQ== Date: Tue, 27 Jul 2021 14:29:04 +0000 Message-ID: <121a0538-da61-e4e4-bba1-20574456576a@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9466d67c-d671-4544-4213-08d9510ae2e4 x-ms-traffictypediagnostic: HE1PR0701MB2731: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OMKwhOTq3p/LRf+oQPAp160l0pUiPoTciLEA2k9ccn2WI5NKrW5yyQYAROu5UUGy6krtGp/9sTin+vuoNe2LAIWadrNopCRmhfyQT1A5FVh45JPwKT8ag/rbkxbFK+OjBWUoMqW3PImwJkXXvApS/ZwWw/PqnUUDM6AL3HmgStsD/hz9DNR9Lwi7bLr02xdWGyG72eiBTW8Yc8eofODUwBvBqm9BXdDxnPWUCaWTCgx4vJS9SE6uOgo2H1SwceEsHF69rVsxcS5+ep/AfUghC2U88NDHnB0SPBAFz4f4W34OhYnMoglvO/vF435THmSGCK8SX132wuFQgZUQucFe417PrBqJnGFptuay9B2Bb8D7xMBsNLlnU9zn1W1OA64nuRx2o0kd/hNjPPsCJlFHUz8sa/X+eBgrZ19ipo0mkc/CmUR6Jv0MolF8h3XGtFlG2Q7F0TwoDFFcFuaxKE7vScre55qzZ7axtxbg+QIpv+kgiSmJKNuj8Iw4lCF3QUfH13UVVwZUBgp4Zz09Jf0NkGXIkzNxQBg3oEBXXexEfVnaSw095BGREgblVroTUOuCRwtKhXKh891iH0iydnydnWPsL+NoVZ3usr3sXXAxA1uDl8SipJ+60QXAZBhP0b6NRttKkZ0qo87t2zk2SYtejabIggKCukx0rkwL1ykhRsKNEh+gBqqdjCd/0fIVsu67BplucWzu/abE0f1WQvFlZeOLN92hz8S+IdcDOxi98+uPtf05BANeBNw3+1W/fhnkgQZB/7eTB3pcEhhId9Qm/beLnmj42cPExIS9osnjnJvCy8qM4LQT8bA6ujtl3OI/MiOSdAtAShjRRetzMAjfLg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3436.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(376002)(136003)(366004)(396003)(5660300002)(8676002)(966005)(31686004)(66446008)(186003)(31696002)(6506007)(2616005)(6916009)(38100700002)(26005)(8936002)(64756008)(66556008)(122000001)(83380400001)(76116006)(66476007)(6486002)(86362001)(316002)(36756003)(71200400001)(66946007)(4744005)(478600001)(6512007)(2906002)(38070700004)(43740500002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?b0RJS2YxSHhFNW91QnlvZEJXTkNXUXgrR29Ydi9HUFhxREVmS0k3aUNuaTNZ?= =?utf-8?B?emRwVSsrN1VnWDFPeGpIaTl3cEZ1T2dOdm1jdSsydGNmc3V6cVVNNjB0OXg2?= =?utf-8?B?czE2OUlvK2NFVWVMTTZoZ1pwamJWUDlmTGVnVXUrS0gwYWVTV2NoTm42MVRV?= =?utf-8?B?WnYvdmhrUit2bzkzNlVyVWFBK25OQXpkSVU2TEIxWXdtVnB6N2hWbW5oc2lE?= =?utf-8?B?d1N4L3E5UnhsTzUwRTBPNExFRjUvSjN0WkFkbTAzNkRpMmZkOEIvZDhLYkh2?= =?utf-8?B?UEdUN1BsSUl6SEw5RXhCZUdBQ1JYcTh6RUFEN2VFNndpTkZoT3JBYjJzclhY?= =?utf-8?B?KzJrampCVEFvUUZJR1JWTTFBVzNkdGNTaGtGWGRTZjc5VWh0MzVCWUhaWXJv?= =?utf-8?B?Rzg0REV4UnFtSWl2azNWbTZNUlBOYXBxN3pJNzJpQXVkcmxPNEdMVnlvVTI2?= =?utf-8?B?bW44RnNtTTRHanl1OGM3ZDNyWFZpN3N6dEJpSFRGKzRJY2hYa1VLdGNub2Rm?= =?utf-8?B?OHdzOHp4QzhwZTJmYU5rc0ZDS2s0ZzRmQmhpY1BkZ0FJVU1OM1N0a0Nod2tK?= =?utf-8?B?ckYweGZEdGNRQ1hmeU1UcDFpdks1NEdGZjBndnpOakI0NnEzL080bERWUkxn?= =?utf-8?B?M3J3NTB4UGFkcUM3SlVKNHZvZkpIMWtYcTlEdzA4emY4SUFEQWZDZkVRN2s3?= =?utf-8?B?YWpVQW1MRGpXLzRDZDREOG5za2pEcjBKRWFTSXVxWjJlRjFzbUxYOXhKeXo5?= =?utf-8?B?Zmo3WnBjdmV5Njk2cTNRNGRIM1pFN2I5MlJyc3hYV2JzUi93cmdvRGtMdTRF?= =?utf-8?B?TDk2THhUWkdlcmh0UWswdHZxNVFZZEhlVWppOUlER01rNWFkeUlqUC9wdXBX?= =?utf-8?B?NlFTZWFEaGprNDlUMGNEVWU3K2dIQmVheUdLYW5wZUtPQ0FQakZ5Q0hkN2F1?= =?utf-8?B?UlZ2M0poSjByeEhWR3RVZmNtTFhHNVVLNXF0bUFTVVJKT2ZIbVlLRDJZMTU2?= =?utf-8?B?VWtXQjlKWk1mRmF3UzJLUVYwcGlpWlowQTQzdkJSN3ZrVDhNUGJ2TWZnUWJ1?= =?utf-8?B?Sjl1NVRWaVV1WEZYNUJTL0djUDBSdnE2dnlmUTk5RnBwYXFUK2F0eGxhWEM3?= =?utf-8?B?aitLRkViZ3NyUHRYYzNEdy9nVnFoelpOM09laitwMnRIQ1dIbWhJUTFRU29u?= =?utf-8?B?dlBtYnpPTmcrQVBzTlZTU0pJbkNyS3ZMM2h5Q2I4N2IzMmZtZTU4Y2xFTzBm?= =?utf-8?B?bnRaZko5SGg0RS9nakZCMXBlaVcycmNpT3ZONHlObU0zR2tVejNEc21yNGl4?= =?utf-8?B?TnI0bmV2QnE5bTkzWkxtNmd0VnpsdkZhOTVvNjdia0cvRjZqby9OSno5M0M4?= =?utf-8?B?TndHV3VGKytKZkdCWVhoM0habTdJT2dJWEVjOU5KNzdrMzNoNjNBcGhnSUZp?= =?utf-8?B?Mlk0U0ZXTDZNY3lEbklicTl2SGRxT3NoUHB1ZlRUc1JiL0xHMVNDcjFVTGFq?= =?utf-8?B?L3pVMll1RVE4WXJsODZRUHIvMkVManlaNUFqUDVuQVlwSEloNEY1WjlQN01J?= =?utf-8?B?SkxNeTdQRUFMNUJ0cGZDYStKd2dUTks4VGNCWkRrdXhCK2JPaUJCRG9WcjRG?= =?utf-8?B?aUY5WGRMS1ZxK284eElrS2t4d3RUaGFmKzdselFrWFBpMjJ2R01Pc3REK0c1?= =?utf-8?B?Mkh6VEpEem9iT0hOc3lzTisvVHhGMEZEWUpUUWFDbmFIZU9hTTBOY2pKYUlK?= =?utf-8?Q?T3dy/9GR8qOQgdNvi0=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <82C1FCF4793FC34D8B27364DAE0A48CA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3436.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9466d67c-d671-4544-4213-08d9510ae2e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2021 14:29:04.6149 (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: 6QeXoMcH6x8vn8hz7fxbzks2tbJZXcVENFv4Je3waESRrqZjyOEN7qZWAjZyCLJqJ+DzSuqEiGd/xy9GpC/ldWFQ3OV+FPrCC9lu95TuneU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2731 Archived-At: Subject: [Secdispatch] Minutes from secdispatch @ IETF 111 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: Tue, 27 Jul 2021 14:29:13 -0000 RGVhciBhbGwsDQoNClRoYW5rIHlvdSBmb3IgcGFydGljaXBhdGluZyBpbiB0aGUgc2VjZGlzcGF0 Y2ggc2Vzc2lvbiBhdCBJRVRGIDExMS4gQSANCmJpZyB0aGFua3MgdG8gb3VyIG1pbnV0ZSB0YWtl cjogUnVzcyBIb3VzbGV5Lg0KDQpNaW51dGVzIGZyb20gdGhlIHNlY2Rpc3BhdGNoIHNlc3Npb24g YXQgSUVURiAxMTEgaGF2ZSBub3cgYmVlbiB1cGxvYWRlZDogDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL21lZXRpbmcvMTExL21hdGVyaWFscy9taW51dGVzLTExMS1zZWNkaXNwYXRjaC0w MA0KDQpQbGVhc2UgcmVwb3J0IGFueSBpc3N1ZXMgYnkgQXVndXN0IDZ0aCwgMjAyMS4NCg0KS2F0 aGxlZW4sIFJpY2hhcmQsIGFuZCBNb2hpdA0KDQotLQ0KDQoxLiBUTFMgMS4zIHRyYW5zcG9ydCBt b2RlbCBmb3IgU05NUHYzIC0+IFNFQyBBRHMgd2lsbCBjaGVjayB3aXRoIE9QUyBBRHMgDQpmb3Ig YXNzaXN0YW5jZSB3aXRoIFNOTVAgZXhwZXJ0aXNlLiBXaWxsIGJlIGRpc3BhdGNoZWQgdG8gZWl0 aGVyIHNvbWUgV0cgDQppbiBPUFMgb3IgdG8gYSBzbWFsbCBmb2N1c2VkIFNFQyBXRy4NCg0KMi4g RGVmaW5pdGlvbiBvZiBFbmQtdG8tZW5kIEVuY3J5cHRpb24gLT4gU2V0IHVwIGEgbWFpbGluZyBs aXN0IHRvIA0KZnVydGhlciB0aGUgZGlzY3Vzc2lvbi4NCg0KMy4gRmFzdCBUcmFuc2l0aW9uIGZv ciBPcHBvcnR1bmlzdGljIFdpcmVsZXNzIEVuY3J5cHRpb24gLT4gU3RhcnQgd2l0aCBhIA0KbGlh aXNvbiBzdGF0ZW1lbnQgdG8gSUVFRSA4MDIuMTEuDQoNCjQuIEVDRFNBIFNpZ25hdHVyZXMgaW4g VmVyaWZpY2F0aW9uLUZyaWVuZGx5IEZvcm1hdCAtPiBDRlJHIHJldmlldyANCm5lZWRlZCBiZWZv cmUgYW55IGNvZGVwb2ludHMgY2FuIGJlIGFzc2lnbmVkLg0KDQo1LiBKV1MgQ2xlYXIgVGV4dCBK U09OIFNpZ25hdHVyZSBPcHRpb24gLT4gSVNFIHN0cmVhbS4NCg0K From nobody Tue Jul 27 08:08:10 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 9EE903A08EA for ; Tue, 27 Jul 2021 08:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 1x9SdUXRhP7S for ; Tue, 27 Jul 2021 08:08:02 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 76CDA3A08F8 for ; Tue, 27 Jul 2021 08:08:02 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id m20-20020a05600c4f54b029024e75a15716so2571657wmq.2 for ; Tue, 27 Jul 2021 08:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+VvOkSl2Ls4cuFV0jVFpymlrQ9s+CnFAzFAv1NEJQLE=; b=ngXx3pPvqKTbDS/bwhOnErGXF6s9bXBZxzSkzmBdmcW1SgJ4kMmW0DMI331vZnhEUd iTBpemuUojM7D2qu6hLM4RC9IiBGNn8RVnGTehP/CtWBc2Mq1Mhiu17vPWb4TzdMLTFU DnECmpHlq4WYlfcsSkJZ6tQjWXthskXvuvavJ20Koroso3ptETZneJXiQ/m6D4owLhe/ dHbS4J+25dVOFbbPUM79FzfCNjRhokqWVls7sRBqTtu2YZMjh5kB3lWzkDsgkxVMBLW6 5afhfxA9hjcu71DgZrVkZNU/gmjiRaeWt7XJGCfOYYiuxEriys8qHfMW28Ndlkk5v5tF b5Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+VvOkSl2Ls4cuFV0jVFpymlrQ9s+CnFAzFAv1NEJQLE=; b=SRZ62+LzUCrDDcwCn/+6tVp5UZSp88c60OUaX3/cje/jo3niFKsnnaumpcmLAlNB8A E9QW7vHHlFdT0IMyDAikVCnvwbdYOpWGv982slSH9f+T0inHfSxKBwGAOOMCC3Ic/vN8 CMc8o8g+OC/hlmcbWcaLg9lACQOGqYYuWsFUJ3H9fyrcmOFD47r2uNCItGv2HqD8UQ4F ZrtPgOiZvCGfFSYis6OMGmUKYQ2TPHOtfCTZCU9ps8GPnA8aHwLVGObScFb5x1seq8Ih U5WjrX+t9tewcKwqnSRyEVjKtrHjwHAVLxd8rXlYhSAQ6AA+4y0yHN9XazihRJ4tJTzL qIPg== X-Gm-Message-State: AOAM533EZlNPqm4VjJrOZRZQZL9ZNM/Y66EL2CEJZA6UX9GhKPFehllr HDnkGurZl5ms7ilsmer2KVb7aAH/HhEiuQ== X-Google-Smtp-Source: ABdhPJyFCyodahXLJxQZO5qXRQ+2XvuKBrlM0bYty51Nh5GlxAmfz3c0GWAgQJRpL9ndXtOjTxA5hg== X-Received: by 2002:a05:600c:2f01:: with SMTP id r1mr13142941wmn.178.1627398480099; Tue, 27 Jul 2021 08:08:00 -0700 (PDT) Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id c16sm3568809wru.82.2021.07.27.08.07.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jul 2021 08:07:59 -0700 (PDT) To: Carsten Bormann Cc: IETF SecDispatch References: <656.1627347926@localhost> <3E3EBA99-16A7-44C2-9829-47AD681BEDDD@tzi.org> <22ea0a96-345d-6272-b287-a2ca78d87e33@gmail.com> <01DD5A19-C35F-4757-B7D1-D94C5B180918@tzi.org> From: Anders Rundgren Message-ID: <4e86a2d0-0df3-8392-7342-4529957b5e38@gmail.com> Date: Tue, 27 Jul 2021 17:08:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <01DD5A19-C35F-4757-B7D1-D94C5B180918@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Secdispatch] Comments on draft-jordan-jws-ct-04.txt 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: Tue, 27 Jul 2021 15:08:09 -0000 On 2021-07-27 12:58, Carsten Bormann wrote: > On 2021-07-27, at 09:41, Anders Rundgren wrote: >> >> Unlike JSON which nowadays [1] have a working deterministic representation [2], CBOR leaves a good portion of this crucial part to application developers to figure out. >> The net result is a fragmented CBOR space with groups like FIDO creating their own unique definition called CTAP2. > > Statements like this are a reason why I’m calling for some supervision here. Another action could be to consider co-creating(!) an "I-CBOR" profile that would not only address documented CBOR interoperability issues for normal data exchange [1], but also make CBOR usable in cryptographic contexts without necessary embedding data-to-signed in bstr like COSE. thanx, Anders 1] https://github.com/w3c/webauthn/issues/1624#issuecomment-862672788 From nobody Tue Jul 27 08:42:11 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 E7A343A0E8C for ; Tue, 27 Jul 2021 08:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 NiFVx4lo7dPA for ; Tue, 27 Jul 2021 08:42:05 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273BA3A0E88 for ; Tue, 27 Jul 2021 08:42:05 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GZ1Hr0sq8z31N0; Tue, 27 Jul 2021 17:42:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <4e86a2d0-0df3-8392-7342-4529957b5e38@gmail.com> Date: Tue, 27 Jul 2021 17:41:59 +0200 Cc: IETF SecDispatch X-Mao-Original-Outgoing-Id: 649093319.763059-330d75aa142b9e5974b29925f5ad9448 Content-Transfer-Encoding: quoted-printable Message-Id: References: <656.1627347926@localhost> <3E3EBA99-16A7-44C2-9829-47AD681BEDDD@tzi.org> <22ea0a96-345d-6272-b287-a2ca78d87e33@gmail.com> <01DD5A19-C35F-4757-B7D1-D94C5B180918@tzi.org> <4e86a2d0-0df3-8392-7342-4529957b5e38@gmail.com> To: Anders Rundgren X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Secdispatch] Comments on draft-jordan-jws-ct-04.txt 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: Tue, 27 Jul 2021 15:42:11 -0000 On 2021-07-27, at 17:08, Anders Rundgren = wrote: >=20 > Another action could be to consider co-creating(!) an "I-CBOR" profile = that would not only address documented CBOR interoperability issues for = normal data exchange [1], but also make CBOR usable in cryptographic = contexts without necessary embedding data-to-signed in bstr like COSE. [Not in citation given.] [1] discusses a case where, in two unimplemented extensions, application = developers wanted to ship floating point values in the specific format = they happen to have them. That would have been fine, but it means there = would have been a deviation from 4.2.1. 4.2.1 *is* the interoperable = set of deterministic encoding rules; deviations are explicitly allowed, = but indeed mean a deviation. And then there is the old =E2=80=9Ccanonical=E2=80=9D encoding from 7049 = that is described in 4.2.3 of 8949. We are genuinely sorry about that, = that was a design that got sufficient negative feedback from = implementers over the years that we decided to upgrade it by providing a = preferred deterministic serialization as well. So I currently have = exactly two implementations: cbor-canonical, which implements 7049=E2=80=99= s old =E2=80=9Ccanonical" serialization, and cbor-deterministic, which = implements 8949=E2=80=99s deterministic serialization. They are 44 = lines each (and don=E2=80=99t differ much, obviously). In my case, I = can=E2=80=99t even implement =E2=80=9Cin the specific format I happen to = have=E2=80=9D, because I don=E2=80=99t have floating point values in = specific formats; if this is ever needed, this could be supported by = adding new application types for these formats, of course. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 27 11:46:34 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 AA58A3A0A46 for ; Tue, 27 Jul 2021 11:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=cdt.org 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 rc86OubxRhlT for ; Tue, 27 Jul 2021 11:46:29 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 27E3A3A0A42 for ; Tue, 27 Jul 2021 11:46:28 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id t4so248168qvj.0 for ; Tue, 27 Jul 2021 11:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:subject:references :content-language:to:from:in-reply-to; bh=CzXJSjNhlg+3ugnUkMj0efN9eFPcN2mzPml7DeVtYPA=; b=YXG8gYyfb3ME5VZ/+ossby8zFNsBzIpuBuhKkG3acLHwez3w6xJxC3cpSR0g3uH4Rf VtLMCnDhpfIdt8bfDOkxRN2R9AeR0L0JXlGdUSJk/JgO+urYdEleK1wo88PVqZ2fG2c9 Bgf+y8sfazDcM1ID8pelKCd8dvX0IEDvnBbvY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :references:content-language:to:from:in-reply-to; bh=CzXJSjNhlg+3ugnUkMj0efN9eFPcN2mzPml7DeVtYPA=; b=hQszmopvy3xqQwG4b3mdWxqWImAabJ1qfvS5NY70hHW+xyPePhQbTMBffo7mo8+vj7 jHQSg92nQ+Q92SrpIR6WnMhiGzAa8UVs7We75lZ/HO4EMW7ZOaxqvHCkQMwwt12q/WWZ VH0tryA2GlRXeCzQGWSLhY3QTFIBPX3e76LG5R6dmLje5h7OL5V7f8d8n8sm9hc1BlJx wyQ36FbolQ2txVKRXmG7lYy1P+v7PXD+WtdknjtEXipuSMBoNKCqSoc/E15Y7pAz1o4L 28FWMNh93O+msHVl+O2GLov7lwxGs+gvYPQWBAV1WvUByXlWTUq0/kRWV7zue3SzpaiL QrGw== X-Gm-Message-State: AOAM533Od+cYmQ4t5l1oXYjWSm8nhRzfoIGsqBBfwec7bWB38L7Gwr5b cUJo+8+dShdt1UB00YXB0eSEP8vI4dnlYvli X-Google-Smtp-Source: ABdhPJyP9izGOI/0r3f0RE5wBLJ1lxp9QFZXh/Nz0fJalEcSaeAkzE6/9FYIqfAmYTvnhnzwgKBZZA== X-Received: by 2002:a05:6214:ca5:: with SMTP id s5mr24193524qvs.58.1627411586805; Tue, 27 Jul 2021 11:46:26 -0700 (PDT) Received: from ?IPV6:2601:14d:8300:7fa0:c09d:5ede:216:755f? ([2601:14d:8300:7fa0:c09d:5ede:216:755f]) by smtp.gmail.com with UTF8SMTPSA id o1sm1665752qta.87.2021.07.27.11.46.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jul 2021 11:46:26 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------96V1b7AiAh41ZG4Zb1qPd0Ur" Message-ID: Date: Tue, 27 Jul 2021 14:46:25 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.0 References: <162741053103.16732.5392965248951377999@ietfa.amsl.com> Content-Language: en-US To: IETF SecDispatch From: Mallory Knodel In-Reply-To: <162741053103.16732.5392965248951377999@ietfa.amsl.com> X-Forwarded-Message-Id: <162741053103.16732.5392965248951377999@ietfa.amsl.com> Archived-At: Subject: [Secdispatch] Fwd: New Non-WG Mailing List: e2ee 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: Tue, 27 Jul 2021 18:46:34 -0000 This is a multi-part message in MIME format. --------------96V1b7AiAh41ZG4Zb1qPd0Ur Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi folks, Please see below the information for joining the e2ee mailing list to discuss the draft e2ee definition: https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/ Thanks so much to the security area directors for getting this going so quickly, -Mallory -------- Forwarded Message -------- Subject: New Non-WG Mailing List: e2ee Date: Tue, 27 Jul 2021 11:28:51 -0700 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List CC: e2ee@ietf.org, mknodel@cdt.org A new IETF non-working group email list has been created. List address: e2ee@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/e2ee To subscribe: https://www.ietf.org/mailman/listinfo/e2ee Purpose: This mailing list exists to discuss how to best document a definition of end-to-end encryption (E2EE). In brief, it is an application of cryptography in communications systems between endpoints. E2EE systems are unique in providing features of confidentiality, integrity and authenticity for users. Improvements to E2EE strive to maximise the system's security while balancing usability and availability. Users of E2EE communications expect trustworthy providers of secure implementations to respect and protect their right to whisper. The IETF is the appropriate venue for this discussion and hopes the mailing list discussion results in a published RFC series document. This list belongs to IETF area: SEC For additional information, please contact the list administrators. --------------96V1b7AiAh41ZG4Zb1qPd0Ur Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi folks,

Please see below the information for joining the e2ee mailing list to discuss the draft e2ee definition: https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/

Thanks so much to the security area directors for getting this going so quickly,

-Mallory



-------- Forwarded Message --------
Subject: New Non-WG Mailing List: e2ee
Date: Tue, 27 Jul 2021 11:28:51 -0700
From: IETF Secretariat <ietf-secretariat@ietf.org>
Reply-To: ietf@ietf.org
To: IETF Announcement List <ietf-announce@ietf.org>
CC: e2ee@ietf.org, mknodel@cdt.org


A new IETF non-working group email list has been created.

List address: e2ee@ietf.org
Archive: https://mailarchive.ietf.org/arch/browse/e2ee
To subscribe: https://www.ietf.org/mailman/listinfo/e2ee

Purpose:
This mailing list exists to discuss how to best document a definition of end-to-end encryption (E2EE).
In brief, it is an application of cryptography in communications systems between endpoints. E2EE systems are unique in providing features of confidentiality, integrity and authenticity for users. Improvements to E2EE strive to maximise the system's security while balancing usability and availability.
Users of E2EE communications expect trustworthy providers of secure implementations to respect and protect their right to whisper. The IETF is the appropriate venue for this discussion and hopes the mailing list discussion
results in a published RFC series document.

This list belongs to IETF area: SEC

For additional information, please contact the list administrators.
--------------96V1b7AiAh41ZG4Zb1qPd0Ur-- From nobody Thu Jul 29 19:39:20 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 70CA73A16E4 for ; Thu, 29 Jul 2021 19:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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=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 cZo0ddkHXNmc for ; Thu, 29 Jul 2021 19:39:13 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 9292F3A16E1 for ; Thu, 29 Jul 2021 19:39:13 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id o13so8040496qkk.9 for ; Thu, 29 Jul 2021 19:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9sxVrzWdFkfV4WxIc0hBLSpi8dAXtbyTQ1cj4gO6ZKU=; b=IKfTth3yOtWXOjVvYQcYI0W4dOksKEPnjovEzjOCVl6jiJqy9tLv+t/aqIQSlor7X/ js7xBzD7gfUBKBpJCsdzRHT3Y6K5qekKWb/BMmm1AVmI/ORZNHtCBqnemNNFofLFPBQ7 tPEmMIjK5Yh79bBi7DCULQuyVrXg5DRLuH5eQNVuG9F2mufRdyj8YlMTnrbPqQeoCFew EWqUO8jIse57aS0zI92DKG1GTZsO5r/6W4pq2c2UDmUOqT4nj1/+kK0yiA+uN8dsqVB8 TpgY8oNBHJWL74tczH7YFaoJI3QfnohVl7duOvAboYwBnkiA0Kz63VViZs2+GsiwLbjn XNYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9sxVrzWdFkfV4WxIc0hBLSpi8dAXtbyTQ1cj4gO6ZKU=; b=JYp6q9RlEYYcLAIMUnVE1lakkDaDfwZoCMBVT6PegWMUT+iWTXsLGZBIs74ZBbptWW F/OJ9PK3blgxOJg60gFM71Dr5mf/hOdeh9WAJNFUKzM+BPCp+rqnW8K0KIBj71Hsk6Ka ZpwZ/GKooDcxevDnUoomgG5v6iRVWAMbCzZIxd9fTy58eYPXKDNwB6VJqaxiF1ky9Aw1 yp2UOWYWwRRz2+5jbBaKq8LDUu1qAy0PzuL+EQvF73ilKVpFz2c9jph3tFJSUmQw2s4C p2AsU2gc4NQIKRfGNE8JecwmzPTCyegzfFIkpu+73YtaQHGaOPIG/QP1jcjMh6C1Yv+u KRoQ== X-Gm-Message-State: AOAM531e12bpD5wAc180+n7/OHzhoP0vuxcN42Arq4Yu4VAbb2sQPDgx Q4bnG8KBkwNo2M2nH/3R2OigfkYQgyLRIvD5dSs= X-Google-Smtp-Source: ABdhPJyiqCOhKc3cJ9ZJV3auQ1nPu0wrNZfBFay2+zAPQ98PKxsWw6MyW4LjcOy/jLb7jGFNQDTTfRiv8rtVvY0Ooa4= X-Received: by 2002:a05:620a:2452:: with SMTP id h18mr149462qkn.207.1627612751321; Thu, 29 Jul 2021 19:39:11 -0700 (PDT) MIME-Version: 1.0 References: <99F30413-4518-40E6-A740-2DA1049A3D1B@akamai.com> <416C1A8D-4F95-4E25-884E-1A18EEDA6988@akamai.com> <593fc980-7549-81a0-8618-a5c1a481b1bb@cdt.org> <453379FF-231D-4A51-8885-A24498569E5E@akamai.com> In-Reply-To: <453379FF-231D-4A51-8885-A24498569E5E@akamai.com> From: Alec Muffett Date: Fri, 30 Jul 2021 03:38:35 +0100 Message-ID: To: "Salz, Rich" Cc: Hannes Tschofenig , Mallory Knodel , Eric Rescorla , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000dfe05d05c84e1fe4" Archived-At: Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02 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, 30 Jul 2021 02:39:19 -0000 --000000000000dfe05d05c84e1fe4 Content-Type: text/plain; charset="UTF-8" On Tue, 27 Jul 2021 at 14:29, Salz, Rich wrote: > > * First, it became a marketing term. Many want to label their > solution as something that provides e2e security. > > That is important, especially if we are trying to win what is a "war of > words" against people who can say "lawful intercept" > Hey all; copying from my recent email to CFRG: I will be presenting "draft-muffett-end-to-end-secure-messaging" tomorrow at the CFRG meeting*, but my slide deck is packed, it will be late in the evening in the UK, I'm sleep-deprived from a new baby, and my experience of Meetecho so far has involved rather a lot of lag. So I thought I would put in some effort up-front and entirely spoiler myself. Attached is a YouTube video with my entire slide deck for tomorrow, and voiceover, running for 9:42s, so at least in theory it is possible for me to run to time. https://www.youtube.com/watch?v=QmL9HYywrHg I am sharing the video openly, and depending on "tech" I may try showing it tomorrow, reusing the audio, or else I may attempt to "wing it" and repeat it verbatim, live; but if you're enthusiastic about the draft, you're hereby invited to prep your slings and arrows by watching the video beforehand. -a -- https://alecmuffett.com/about --000000000000dfe05d05c84e1fe4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 27 Jul 2021 at 14:29, Salz, Rich = <rsalz=3D40akamai.com@dma= rc.ietf.org> wrote:
>=C2=A0 =C2=A0 * First, it became a marketing term. Many want to la= bel their solution as something that provides e2e security.

That is important, especially if we are trying to win what is a "war o= f words" against people who can say "lawful intercept"

Hey all; copying from my recent email to CFR= G:

I will be presenting "draft-muffett-end-to= -end-secure-messaging" tomorrow at the CFRG meeting*, but my slide dec= k is packed, it will be late in the evening in the UK, I'm sleep-depriv= ed from a new baby, and my experience of Meetecho so far has involved rathe= r a lot of lag.

So I thought I would put in some e= ffort up-front and entirely spoiler myself. Attached is a YouTube video wit= h my entire slide deck for tomorrow, and voiceover, running for 9:42s, so a= t least in theory it is possible for me to run to time.

http= s://www.youtube.com/watch?v=3DQmL9HYywrHg

I am sharing the video= openly, and depending on "tech" I may try showing it tomorrow, r= eusing the audio, or else I may attempt to "wing it" and repeat i= t verbatim, live; but if you're enthusiastic about the draft, you'r= e hereby invited to prep your slings and arrows by watching the video befor= ehand.

=C2=A0 =C2=A0 -a

--
--000000000000dfe05d05c84e1fe4-- From nobody Fri Jul 30 11:18:57 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 467473A093B for ; Fri, 30 Jul 2021 11:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=ibiblio-org.20150623.gappssmtp.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 JyavZ380Qv_M for ; Fri, 30 Jul 2021 11:18:51 -0700 (PDT) Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) (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 139973A093A for ; Fri, 30 Jul 2021 11:18:50 -0700 (PDT) Received: by mail-ej1-x644.google.com with SMTP id gn26so18371044ejc.3 for ; Fri, 30 Jul 2021 11:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibiblio-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=2Ya0gzYC9qqCEDJE5zDAgNWT4MB5z8uOxpRBHuT9MjY=; b=cdr9tIScvCW7gwv/Nnvf/RGtq8LTujdVZ2Z/kG5YK4ohkaZyWKfIegBSxaCHJhbwdO BFPkMMF/VDyX7VogDUwuPIHv8iZ0hzJdcr05nX+6J9+FwSDuEj9TNuqxEc9YK/EruEVP MUxZ2QvCB94/qernT+MnGFkAtRa7npUO7+o86Z0sdq6W6ft0+eNd1jzxU40DNaQn6luJ M3gqe0GBTxc+eso/qdnb50tkCF60zl6lwFR0nFZ5ZACR6NLicgVhDM/rh9sVpogiyLDk MAdp5EWYbVpgmLTXvla7SW6XEl+ai2rliKH7NiTtelE74Z1upGvyvXgv5r+Uth2feDPs RRWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2Ya0gzYC9qqCEDJE5zDAgNWT4MB5z8uOxpRBHuT9MjY=; b=fVdVRMCVj1nmQK6Fq/VOl1G0qwXmHWYltfTM33V6jxAEH/+938r5c2ok/zYSK6/2tb UxBVLt+rDl3jPActcoPpUKxCgxrWftM2NuXaVwN6iIgKR9Nt5NprHCri/CPpvycPH+Tf B58wDPI4QcYXPFFj2ZP3VAMdcJyUH34zM6OzD2Exh2TExNAMppnPaZUp6ma65PplV4qm eAU8i+1mkCzLdJ7lQ/NmiayBfnNL+DWZb3wie+NY3YTGOLWgfBH9WwVwWdrAqoq3nVNT 9kWTvDsVoxlZ0Wdns57lVyfjEN59ZNOltyiIFmjchrsS8iEDfdvD0w2FpV5o94R7fvsB iVtQ== X-Gm-Message-State: AOAM533HW4fIxCnPs0YYlJEcI0XwSZsyusclvui1K7uEt4wvjBnkWm6F Svmw6MqrmsHNxGjAI1W0vcmFJfKYq516ZL3SDwh0yCO97d0RivP2jpg= X-Google-Smtp-Source: ABdhPJyadwfgkqfOmc+tGOL38j37ABmqGhcQsqajFAjMom8q//c6t8c1N7OPUxlpMnh3iPBGRaOSMoCIInzpxN3UlVI= X-Received: by 2002:a17:906:4b56:: with SMTP id j22mr3905689ejv.551.1627669127359; Fri, 30 Jul 2021 11:18:47 -0700 (PDT) MIME-Version: 1.0 From: Harry Halpin Date: Fri, 30 Jul 2021 20:18:36 +0200 Message-ID: To: secdispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000002606d805c85b402f" Archived-At: Subject: [Secdispatch] Interest COVID-19 'passport' standardization? 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, 30 Jul 2021 18:18:55 -0000 --0000000000002606d805c85b402f Content-Type: text/plain; charset="UTF-8" Everyone [and apologies if you already got this message on CFRG or SAAG], While the research community and industry was very quick to work on privacy-enhanced contact tracing, I've seen very few people taking the much more pressing issue of COVID-19 passports. If this IETF111 was in person, we could have done an informal BoF, but as its' not, I'm sending out an email to gauge interest. I've earlier seen some very badly done academic work using W3C "Verified Credentials" and W3C Decentralized Identifier (DID) standards [1]. However, while a bunch of sketchy blockchain technology has not been adopted (so far, although I believe IATA and WHO are still being heavily lobbied in this direction), there has been the release of the EU "Green" Digital Credentials that actually uses digital signatures. However, there's a number of problems: * No revocation in case of compromise * Privacy issues, i.e. leaking metadata * Limited key management (booster shots might require) * No use of standards for cross-app interoperability Furthermore, there appears to be differences between countries, and some countries do not use cryptography at all (the US). Therefore, as an American in France who flew home ASAP to get vaccinated in the US, as a consequence of this lack of interoperability I can't travel on trains or eat at restaurants easily, despite being vaccinated. I imagine this will become a larger problem. I have a report I'm willing to share, but I'd first like to know if there's any interest in standardization on this front at the IETF despite this topic being, I suspect, a bit of astretch of our remit. However, we live in interesting times. I don't think the W3C (or the ITU, etc.) has the security expertise, and while the crypto and security/privacy here is pretty simple, I think it should happen somewhere. While I originally polled it by CFRG IRTF to see if there was any interest whatsoever, Benjamin Kaduk pointed out SAAG and SECDISPATCH would be better places to start. I'd like to know what others think. yours, harry [1] https://arxiv.org/abs/2012.00136 --0000000000002606d805c85b402f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Everyone [and= apologies if you already got this message on CFRG or SAAG],
=
While the=20 research community and industry was very quick to work on=20 privacy-enhanced contact tracing, I've seen very few people taking the= =20 much more pressing issue of COVID-19 passports.

If= this IETF111 was in person, we could have done an informal BoF, but as its= ' not, I'm sending out an email to gauge interest.
<= br>
I've earlier seen some very badly done academic work using W3C "Verified= =20 Credentials" and W3C Decentralized Identifier (DID) standards [1].=20 However, while a bunch of sketchy blockchain technology has not been=20 adopted (so far, although I believe IATA and WHO are still being heavily lobbied in this direction), there has been the release of the EU=20 "Green" Digital Credentials that actually uses digital signatures= .

However, there's a number of problems:
<= /div>

* No revocation in case of compromise
* Privacy issues, i.e. leaking metadata
* Limited key managemen= t (booster shots might require)
* No use of standards for cross-a= pp interoperability

Furthermore, there appears to be differences between countries, and some countries=20 do not use cryptography at all (the US). Therefore, as an American in=20 France who flew home ASAP to get vaccinated in the US, as a consequence=20 of this lack of interoperability I can't travel on trains or eat at=20 restaurants easily, despite being vaccinated. I imagine this will become a larger problem.

I have a report I'm=20 willing to share, but I'd first like to know if there's any interes= t in=20 standardization on this front at the IETF despite this topic being, I=20 suspect, a bit of=C2=A0 astretch of our remit. However, we live in=20 interesting times.

I don't think the W3C= =20 (or the ITU, etc.) has the security expertise, and while the crypto and=20 security/privacy here is pretty simple, I think it should happen=20 somewhere.

While I originally polled it by CF= RG IRTF to see if there was any interest whatsoever, Benjamin Kaduk pointed= out SAAG and SECDISPATCH would be better places to start. I'd like to = know what others think.

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yours,
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 harry

=
--0000000000002606d805c85b402f-- From nobody Fri Jul 30 11:30: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 88AB03A097B for ; Fri, 30 Jul 2021 11:30:42 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 UKOXQflhQ6zG for ; Fri, 30 Jul 2021 11:30:35 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 0C23E3A09CD for ; Fri, 30 Jul 2021 11:30:28 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id f8so7096351ilr.4 for ; Fri, 30 Jul 2021 11:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GTHiU9lP47PQb4DtuPH4rbQdUsH712ryEJnPbbnjzyA=; b=afAClasfPyvB9koiqqZDkOB8CmiBiL+TWHSjiDGY6MDoBaSPRc2myxQGCH4YppP8v7 73NVLNN39P8UZQ+8ML5aqdy0VmLEse1oWB9CA2nbZ0aYnpRoBJsXltbOkiYKMaVDWO77 Q+hPzgMu/vNGBYnCLBInD1t5TBEOLoPuUBs6ocqWfqNG68eTybHu2qdjLXR1vF6WYbkG QLi2GRlkwfWwky+qhqhgVOVeFnYXmv1qw7KFaAWnrbDA6oAiJUMmFwgsWR16msRFJtsk 5fccRfN5IuzFf8ybW4N4aF/fDkqy0pvccwsMUCJ9I45zF8NkBZMCk379a0SyKVNZrEp0 9OfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GTHiU9lP47PQb4DtuPH4rbQdUsH712ryEJnPbbnjzyA=; b=XAsfQjgBQShVqJBKsHZ/iICYRbhCB73XiGNMJeerc6aOLr4uLEx0yqJSljtBj7bv2d Fe65cO1iY956Z/Hc+VK5MxGGXGtQSUQpztaRpewfXYjHHuHffpU02nk+S6Nr6f4Bp3Bs FMsgnRCcJZqMQ0xQ4xyZvKEjs9DI2pPWObie7CBQng3PzRa+Fom4VrcwTqKjpjFeLCZq sVhF4rZKGBjilMPO9WjDLBx1lVOxEw0bztMgqsbAXnzGOZdnMYp9btG4lfSwux1bttzt WzVWGoa01k5mCGYSYEgw+UqZh2DmSMAOD9g5aBNEQR1vfPCxgk5mDSOyZnSZDZQUjQ0j 7dug== X-Gm-Message-State: AOAM531hNpoYYc41RLDClqtCYu9LZ9RoXDIMv5GxvQa8LgCBda9jBvPJ rRfFa9UxsWWP07qa/3svOmrPnwwjIiDlkulUCO3zHQ== X-Google-Smtp-Source: ABdhPJzyypIDrINSfAxxoqZ3t58i4+MRpNU7eMGzpfwJwoiIW/ybRdOODJMugIOhndXr9Xq6zlAAgz685zPdm4l6P24= X-Received: by 2002:a05:6e02:f54:: with SMTP id y20mr2045146ilj.56.1627669826137; Fri, 30 Jul 2021 11:30:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 30 Jul 2021 11:29:49 -0700 Message-ID: To: Harry Halpin , IETF SecDispatch Cc: IETF SAAG Content-Type: multipart/alternative; boundary="000000000000cc883605c85b6973" Archived-At: Subject: Re: [Secdispatch] [saag] Interest COVID-19 'passport' standardization? 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, 30 Jul 2021 18:30:43 -0000 --000000000000cc883605c85b6973 Content-Type: text/plain; charset="UTF-8" To recap my comments on CFRG: There seems to be a lot of enthusiasm for this in various forums, and it's largely not well coordinated, with each group (the EU, VCI, etc.) doing their own thing, and producing work of various levels of quality. Before the IETF got involved, I'd want to see some evidence that the various players are interested in a common standard and want to do one here, lest we end up with XKCD 927. FWIW, I've spent a bunch of time looking at the various proposals. If people are interested they can find it at: https://educatedguesswork.org/tags/vaccine%20passports/ -Ekr On Fri, Jul 30, 2021 at 11:18 AM Harry Halpin wrote: > Everyone [and apologies if you already got this message on CFRG or > SECDISPATCH], > > While the research community and industry was very quick to work on > privacy-enhanced contact tracing, I've seen very few people taking the much > more pressing issue of COVID-19 passports. > > If this IETF111 was in person, we could have done an informal BoF, but as > its' not, I'm sending out an email to gauge interest. > > I've earlier seen some very badly done academic work using W3C "Verified > Credentials" and W3C Decentralized Identifier (DID) standards [1]. However, > while a bunch of sketchy blockchain technology has not been adopted (so > far, although I believe IATA and WHO are still being heavily lobbied in > this direction), there has been the release of the EU "Green" Digital > Credentials that actually uses digital signatures. > > However, there's a number of problems: > > * No revocation in case of compromise > * Privacy issues, i.e. leaking metadata > * Limited key management (booster shots might require) > * No use of standards for cross-app interoperability > > Furthermore, there appears to be differences between countries, and some > countries do not use cryptography at all (the US). Therefore, as an > American in France who flew home ASAP to get vaccinated in the US, as a > consequence of this lack of interoperability I can't travel on trains or > eat at restaurants easily, despite being vaccinated. I imagine this will > become a larger problem. > > I have a report I'm willing to share, but I'd first like to know if > there's any interest in standardization on this front at the IETF despite > this topic being, I suspect, a bit of astretch of our remit. However, we > live in interesting times. > > I don't think the W3C (or the ITU, etc.) has the security expertise, and > while the crypto and security/privacy here is pretty simple, I think it > should happen somewhere. > > While I originally polled it by CFRG IRTF to see if there was any interest > whatsoever, Benjamin Kaduk pointed out SAAG and SECDISPATCH would be better > places to start. I'd like to know what others think. > > yours, > harry > > [1] https://arxiv.org/abs/2012.00136 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --000000000000cc883605c85b6973 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To recap my comments on CFRG:
There seems t= o be a lot of enthusiasm for this in various forums, and it's largely n= ot well coordinated, with each group (the EU, VCI, etc.) doing their own th= ing, and producing work of various levels of quality. Before the IETF got i= nvolved, I'd want to see some evidence that the various players are int= erested in a common standard and want to do one here, lest we end up with X= KCD 927.

FWIW, I've spent a bunch of time look= ing at the various proposals. If people are interested they can find it at:=

-Ekr




On Fri, Jul 30, 2021 at 11:18 AM Harry Halpin <hhalpin@ibiblio.org> wro= te:
Everyone [and apologies if you = already got this message on CFRG or SECDISPATCH],

<= div>While the=20 research community and industry was very quick to work on=20 privacy-enhanced contact tracing, I've seen very few people taking the= =20 much more pressing issue of COVID-19 passports.

If= this IETF111 was in person, we could have done an informal BoF, but as its= ' not, I'm sending out an email to gauge interest.
<= br>
I've earlier seen some very badly done academic work using W3C "Verified= =20 Credentials" and W3C Decentralized Identifier (DID) standards [1].=20 However, while a bunch of sketchy blockchain technology has not been=20 adopted (so far, although I believe IATA and WHO are still being heavily lobbied in this direction), there has been the release of the EU=20 "Green" Digital Credentials that actually uses digital signatures= .

However, there's a number of problems:
<= /div>

* No revocation in case of compromise
* Privacy issues, i.e. leaking metadata
* Limited key managemen= t (booster shots might require)
* No use of standards for cross-a= pp interoperability

Furthermore, there appears to be differences between countries, and some countries=20 do not use cryptography at all (the US). Therefore, as an American in=20 France who flew home ASAP to get vaccinated in the US, as a consequence=20 of this lack of interoperability I can't travel on trains or eat at=20 restaurants easily, despite being vaccinated. I imagine this will become a larger problem.

I have a report I'm=20 willing to share, but I'd first like to know if there's any interes= t in=20 standardization on this front at the IETF despite this topic being, I=20 suspect, a bit of=C2=A0 astretch of our remit. However, we live in=20 interesting times.

I don't think the W3C= =20 (or the ITU, etc.) has the security expertise, and while the crypto and=20 security/privacy here is pretty simple, I think it should happen=20 somewhere.

While I originally polled it by CF= RG IRTF to see if there was any interest whatsoever, Benjamin Kaduk pointed= out SAAG and SECDISPATCH would be better places to start. I'd like to = know what others think.

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yours,
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 harry

=
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--000000000000cc883605c85b6973-- From nobody Fri Jul 30 11:31: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 B86853A09BB for ; Fri, 30 Jul 2021 11:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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=fraunhofer.onmicrosoft.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 UYlkrWtRa61k for ; Fri, 30 Jul 2021 11:31:52 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (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 654623A09BE for ; Fri, 30 Jul 2021 11:31:51 -0700 (PDT) IronPort-SDR: 9iePDZjaTfeKkxCHx7aZb8NIwBSf/qgNqC9WfIvhbBR0nLl+zIrH+TRxYva9hr68DZ55RKzxZ5 NrzOvxQpt+A0ZUaTQd772C54ycFDYTRveJro4mUeKM3zVfXHu3b+kb1+/WQpIuBKaCBKqyCm8x aMLEdvYZGvypm67RmePi3NELuxfSX2raYp8LDcj9thU3c+uwmM5/s2hHRBnu8wMYvVbBmUT7ny tmfo1Lbxdbio2BFjOP0goDTSYYVdtRBRtZLZhyy5jgDIIlob1WBpOqfNGCPQo26kprHSYoucvN 3oA= IronPort-PHdr: =?us-ascii?q?A9a23=3A3/cxmhHsBWUFAGnPK/IcKZ1GfsIY04WdBeZdw?= =?us-ascii?q?psql7wIdb6srNzuP03asPNqilKBHYDW8OlNhOeetaf8EXcB7pCMvDFnEtRMW?= =?us-ascii?q?hYJhN9Qk1kmB8iIWkz2MPCsaDY1T4xOUVZ/9CS9Nk5YUM/1e1zVpCi06jgfU?= =?us-ascii?q?hXyPAZ4PKL7AInX2t+2y6a84ZTOZQVPijenJ79/f32L?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EzCABIRARh/xoHYZlagQmBW4E8AhM?= =?us-ascii?q?pKH6BQoRIg0kBAYU5iDEtA5VihFGBQoERAxgWGwsBCgEBAQEBAQEBAQgBKgs?= =?us-ascii?q?KAgQBAQMDhA1FAjWCSQElOBMCBAEBARIBAQYBAQEBAQYEAgKBIIVoDUABDAG?= =?us-ascii?q?CImOBCAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCDQc?= =?us-ascii?q?tHgciDBIBHwEBAQMBARARDwEFCAEBKQMMDwkCDgoCAiYCAicLJQYBDAYCAQE?= =?us-ascii?q?QDoJPAYJVAy4CAwuPcY80AYE6AoofeoExgQGCBwEBBgQEgTYBgRqCSxhagVo?= =?us-ascii?q?DBgkBgQYoAgEBgnqJVIEfJxCBVUSBFScPgm8+gmIBAYEXFAELBwGDOIJkgks?= =?us-ascii?q?0GDEtUxAgAi0MKkA+KQcrGZEOjWSLCZJlLAeCAIEqgTEGC4h2k3sGFCaVUAa?= =?us-ascii?q?REZYOjDiYWwIEAgQFAg4BAQaBd4EOcE0kT4JpUBkOjisWgQMBCIJDhRSFTHE?= =?us-ascii?q?4AgYBCgEBAwlbgTCFfoJHAQE?= X-IPAS-Result: =?us-ascii?q?A2EzCABIRARh/xoHYZlagQmBW4E8AhMpKH6BQoRIg0kBA?= =?us-ascii?q?YU5iDEtA5VihFGBQoERAxgWGwsBCgEBAQEBAQEBAQgBKgsKAgQBAQMDhA1FA?= =?us-ascii?q?jWCSQElOBMCBAEBARIBAQYBAQEBAQYEAgKBIIVoDUABDAGCImOBCAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCDQctHgciDBIBHwEBA?= =?us-ascii?q?QMBARARDwEFCAEBKQMMDwkCDgoCAiYCAicLJQYBDAYCAQEQDoJPAYJVAy4CA?= =?us-ascii?q?wuPcY80AYE6AoofeoExgQGCBwEBBgQEgTYBgRqCSxhagVoDBgkBgQYoAgEBg?= =?us-ascii?q?nqJVIEfJxCBVUSBFScPgm8+gmIBAYEXFAELBwGDOIJkgks0GDEtUxAgAi0MK?= =?us-ascii?q?kA+KQcrGZEOjWSLCZJlLAeCAIEqgTEGC4h2k3sGFCaVUAaREZYOjDiYWwIEA?= =?us-ascii?q?gQFAg4BAQaBd4EOcE0kT4JpUBkOjisWgQMBCIJDhRSFTHE4AgYBCgEBAwlbg?= =?us-ascii?q?TCFfoJHAQE?= X-IronPort-AV: E=Sophos;i="5.84,282,1620684000"; d="scan'208";a="34715882" Received: from mail-mtas26.fraunhofer.de ([153.97.7.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jul 2021 20:31:48 +0200 IronPort-SDR: KLYBPyng8vQd6hehHiJKqK38hm2OndeDLy9FzWeQEtlrnP26a6D122VUxAOcfqDTph7wNg6v7D u+LV1FucbKSt+8bcAyxMjCXLJGlzBUAj8= IronPort-PHdr: =?us-ascii?q?A9a23=3AWgEMLB3sdipiWn3nsmDPS1BlVkEcU/3cPwMJ5?= =?us-ascii?q?Nwgkb0dOqig/pG3OkvZ6L0tiVLSRozU5rpCjPaeqKHvX2EMoPPj+HAPeZBBT?= =?us-ascii?q?VkJ3MMRmQFzAcOZBwv8NvG5JyA/Fd5JAVli+XzzOENJGcH4MlvVpHD67TMbF?= =?us-ascii?q?hjlcwRvIeGgAY/Oycqt3v20+5rdbh8OiDfuCY4=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AYsyy2qNSs8p+/MBcT1H155DYdb4zR+YMi2?= =?us-ascii?q?TDiHofdfUFSKClfp6V8cjztSWUtN9jYgBcpTnmAtj9fZq8z+8O3WB1B9mftW?= =?us-ascii?q?bdyRKVxe1ZnOzfKnjbalbDH41mpNZdmspFebvN5DFB5K6QimnIcKdS/DDEyt?= =?us-ascii?q?HNuQ639QYScegAUdAD0+4WMHf/LqQ7fng/OXJvf6Dsmfav6gDQNEg/X4CePD?= =?us-ascii?q?0oTuLDr9rEmNbPZgMHPQcu7E2rgSmz4LD3PhCE1lNGOgk/josKwCzgqUjU96?= =?us-ascii?q?+ju/a0xlv10HLS1Y1fnJ/ExsFYDMKBp8AJInHHixquZq5mR7qe1QpF7N2H2R?= =?us-ascii?q?IPqp3hsh0gN8N85zf4eXy0mwLk303a3DMn+xbZuBelqEqmhfa8aCMxCsJHi4?= =?us-ascii?q?4cWADe8VAcsNZ1178O936FtrJMZCmw3BjV1pztbVVHh0C0qX0tnao4lHpES7?= =?us-ascii?q?YTb7dXsMg24F5VKpEdByj3gbpXUdWGNPuspsq+TGnqKkww5gJUsZiRtzUIb1?= =?us-ascii?q?m7q3E5y4+oO2M8pgE/86Nwr/Zv7kvp9/oGOtB5Dqr/Q+JVfYp1P7orhJRGdZ?= =?us-ascii?q?E8qPuMex7wqC33QRavyHTcZeo60iH22tTKCItc3pDcRHVP9upqpKj8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdGQCQRARh/z6wYZlagQkJgVKBPAI?= =?us-ascii?q?TKSgHTCtZJkOER4NJAQGFOYY7gXYtAzgBlSmEUYFCgREDVAEKAQMBAQEBAQg?= =?us-ascii?q?BBCYLCQECBAEBhBNFAjWCRgImOBMCBAEBARIBAQUBAQECAQYEgREThWgNQAE?= =?us-ascii?q?MAYV1AQEBAwEBEBEPAQUIAQEUFQMMDwkCDgoCAiYCAicLBx4GAQwGAgEBEA6?= =?us-ascii?q?CTwGCVQMuAgMLj3OPNAGBOgKKH3qBMYEBggcBAQYEBIE2AYEagksYWoFaAwY?= =?us-ascii?q?JAYEGKAIBAYJ6iVSBHzeBVUSBFScPgm8+gmIBAYEXFAELBwGDOIJkgks0GDE?= =?us-ascii?q?tUxAgAi0MKkA+KQcrGZEOjWSLCZJlLAeCAIEqgTEGC4h2k3sGFCaVUAaREZY?= =?us-ascii?q?OjDiYWwIEAgQFAg4BAQaBdyRpcE0kT4JpUBkOjisWgQMBCIJDhRSFTEEwOAI?= =?us-ascii?q?GAQoBAQMJWQEBgTCFfoJHAQE?= X-IronPort-AV: E=Sophos;i="5.84,282,1620684000"; d="scan'208";a="149596124" Received: from 153-97-176-62.vm.c.fraunhofer.de (HELO mobile.exch.fraunhofer.de) ([153.97.176.62]) by mail-mtaS26.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jul 2021 20:31:44 +0200 Received: from XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) by XCH-HYBRID-02.ads.fraunhofer.de (10.225.8.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.12; Fri, 30 Jul 2021 20:31:44 +0200 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (10.225.8.37) by XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.12 via Frontend Transport; Fri, 30 Jul 2021 20:31:44 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XGsBIUFuXRVuR/Fn/itdk5vGENeZQ+Md5AfFGvmiie52R/bl0LdBuvMLek5EPhkfJUzoANSGxIes01eZBG8IXtHiePHRHg5j0eo7Bex4AdzwN6LMvBbnzhgZ6Xqx9RXxYqsh4oPaTdx/JHlXmR+nROtT/gHfHy/xGyBBr3TOSDdEmMP2aoh74H27TgdRXB2RT350dNzi4dymDGh+k0jW9xAkb4961VA7a9eb0AV5huZYEFgNLi/kci2eq4qJJkZX1gKIov9cZy3+fUOEtUd5SRwqnm4mNiXJdMP2bdyex8qsWTayHNawqONVD9NGr5T9B8zTmqR5p2x2pVNc6xNY3Q== 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=eXgDw73wvgr9PgzFdN75Q9LrZF5wMEAfjh766+3RtWQ=; b=CXvGM+1jbfSMUHYI/OlAWObjnK/+JcEzfzqqWxBO/ysIK5HnCeolOCgSk8XmFfHo0ARMAO0U2500gTOT+OH/tTfqWWD2rBDS4EU7vD8H3ySJiDmzYvotlHNG0rsId1Jv3fTYep8+qbkSEpZPH7ZsnUxxD0Uhh6TIMcCgFDGlMw9LuD69VLUR1Xf41lBJplr0+tiflah6ZxLrhLHoN0VcqHdgw7UfkgzZ6QCAEZBJj711mICeYeGJv4erBWEy+ehllCWRpySrcUBlV6gMpyzsJzhyQtlp480bAA421CpKW2Lq4ZyiJ1H/MV0tcmbh662inMxPtdIz1ytJoeoMmO6T0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sit.fraunhofer.de; dmarc=pass action=none header.from=sit.fraunhofer.de; dkim=pass header.d=sit.fraunhofer.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fraunhofer.onmicrosoft.com; s=selector2-fraunhofer-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eXgDw73wvgr9PgzFdN75Q9LrZF5wMEAfjh766+3RtWQ=; b=FfHw3JvAY841WfBn0ezvby1kex3lHA5brnO3h73WgytW5Zp2a0Vi1U+lpCaFAQbhoAWZWdlKa66vZXqJGOGpdaoxyhIx9PwNzuLOyzvTkz5GdzAK0gLjVQoQ8irGHDlihyJdbKSyrDl7hvADMuONo5QN4+YrAAJzlYQoN6GhGjg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=sit.fraunhofer.de; Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) by DU2P194MB1680.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:275::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.25; Fri, 30 Jul 2021 18:31:42 +0000 Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::f1ba:74f3:e031:5b32]) by DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::f1ba:74f3:e031:5b32%6]) with mapi id 15.20.4373.025; Fri, 30 Jul 2021 18:31:42 +0000 To: Harry Halpin , References: From: Henk Birkholz Message-ID: <6f1c1251-dfc9-97da-73fb-c42d36780b04@sit.fraunhofer.de> Date: Fri, 30 Jul 2021 20:31:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM4PR0902CA0015.eurprd09.prod.outlook.com (2603:10a6:200:9b::25) To DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.16.50] (79.206.151.153) by AM4PR0902CA0015.eurprd09.prod.outlook.com (2603:10a6:200:9b::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18 via Frontend Transport; Fri, 30 Jul 2021 18:31:42 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9c56c73d-91ed-4bb9-8b78-08d953884708 X-MS-TrafficTypeDiagnostic: DU2P194MB1680: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ygrgUnwF8UjmGKvIpxAKv9Ksb+N0KhUTcL37VN8EAhqpNfepQqjeMBZk8dXrlSb2cNVEu0YcO8+z20DH1xCmUDILAtulbJo9PA6RhoYsScAyaVw6vsahT8m9wLTnj3c2v54nxYV/Q7+XHDlkiHrpG2SgcQQE7Lvsmy3ZhnzXiN12LJFWUr653iTEj382uZzdZdZBy4I/lsEpaPK956fD6O6tmcMZaVGvEHyInY7EfGa7TnoDyFH9D3FEO48pIx/ROj7+hPZFmbISaGgfCbFxC49YRitFI2Kz0KU4PdUj6T0ZmCgEhimDWSiNlspUieVjtIGBIm/juMlWdE82nxzWdjkdKEJZ/HK9S3ZTS5jnX8YNEhAoeK9tRRMLC1vvnGo5xBc+493FYpFnErXZCoIgs3RB63tv/QIFmU5pt6hDmVEPPPzKAS4mH/7+vYilKimQ6GKO/NbJliJi9C1AwKbqp4GRHLcxvTgummXwGh+VN2Dv31RpcU2jSx+msUOBLp8+dVC7PoqlQ4ON5JJm7Y+N9WvgaiatrXxHql6cnPvsKuOS/yh5EayoS0ea3391WgoTOt3Jo9lyflIPChbZ9ZilOyCEc/vCWBcSB/eb3xtI6fXr0FyO01kvyHWdc3H7L2BtP7trV0VrTV2ThZfEgfmed8g6hHE13S9hIID5voaLCV1oq4zkjHtAQmf9FjdNoN3AzcO1ZVk/tEb1/1yUxOa6t0kIj/s9f8jRSTD3U88NuKyQc8hPt9grRXt97hdIAd67v1bgrWaTJ01uJB3D1Psxj2zJ3tYmXh2YObUoYRdmn/82cXxwbVKbj7PjnOpuaYuZqSWlhh0OnVm7TGVVrXDhsqhTxh2OEwug7OkR0QxQl3EOIGdFZYL2KcU7ZuBgk1ZJ X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU2P194MB1709.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(39850400004)(396003)(376002)(366004)(86362001)(478600001)(16576012)(66946007)(8676002)(2616005)(53546011)(66476007)(316002)(83380400001)(52116002)(956004)(31686004)(31696002)(2906002)(38100700002)(66556008)(6486002)(26005)(44832011)(38350700002)(8936002)(966005)(5660300002)(186003)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VElSYW5HcHc1TlRLa29WaHc0SFp1WmM5UWVpckVLMXBkK3R2R1hyNkVHN0c2?= =?utf-8?B?RHVVa2JvSmtwcGJHaDA4Z0N0OHlaZjdSNWxpV0xCWjNacko1RjZMbzVjT1RX?= =?utf-8?B?TXZrZjJBcmJJN09QMXh1cjRoais4UzFHdm9LSFhNNzZUYnVqZ3c0TjBYOVlW?= =?utf-8?B?a0dPL3RsOVRVZjZpNHJIZ053UXY1MmFKbEQ2amdkYU1JVXYyT254Myt5M3ZO?= =?utf-8?B?eW41UHUrRHNzM3NnWDZzMndmNUVtb3d0QzBiakgxNEtQcmhGaGZXSEY4dDdy?= =?utf-8?B?WmJ5Tnc1UUlLOVk1QTNiclpMaGVhOXZ2WDBMbXN1NWRvL2gyaTJRb0hMUzlJ?= =?utf-8?B?OUlJSW1ZckRKL0ZPYmpneTVEaGNXbG9KL1FTMXoycVJVQ25Bem1tbjB4WWxh?= =?utf-8?B?VFZXb3Q1OVpNN25iWi9QRDN3L211dTJ5TGFVTG9WQVpHaXBZN01lbDgxQ1lR?= =?utf-8?B?Qm4vY2VEUTJ5YkRHRlMzZzlSQVFKcHU2Q1Y5TTc1RFB2RVI0VklvSHhVNEhu?= =?utf-8?B?R0JOT1NnVzBLWDNteXJ0cXJIRnZaMmJYdmhTUjNGak9ZS3d5T1RHa0lkUGxC?= =?utf-8?B?b3N3LzlRTHVyemxvZ05Wcm1USmxxRVBwUGIxczhGR05Ha2xKUTBQcE8wSndX?= =?utf-8?B?aHpSdHJZU1I2M3VKTTVXVWFkSUM2S2dBaWR1dzhzNmxJOW9qNEo0SlBod25G?= =?utf-8?B?aWpWUDBVbmVxUElNRmhoL0NYMFdyUVF1K202UnF6ZHkxaEk3UHhFWndzdkgr?= =?utf-8?B?MjlBZHpkZ3BVb1RsODc4OGdwbkY2ZjloQmdyUWhRQ2NxSTk5WGIzY1I1UFd3?= =?utf-8?B?WkVBZStOemlqQ3JCcml2Z3RqMHFnTG4wNFc4R1FaNEx5TFowUGxXWDZoWHNl?= =?utf-8?B?TEJFZk4zd0gycGM0TE1SUlRON0tQbTg1aW9SOEt1dCtnUGVIcmcxTnJja0VF?= =?utf-8?B?WHlFUU5OTjUvbU91aG1uYnRqMExGMWRSc2JvaEtHRG9la29aaG90em51b0Vy?= =?utf-8?B?aWE1OVllN0JabmxNSnJVTldyNWFtUkN2TFdrSGxXemFFdGFQclVRakN5TW1R?= =?utf-8?B?ZzRGYlRrd3B2ZWJ4eDRIY0dJckExNDJhaDJBeFF0RzhYVjFhSzdzZXJoWi9K?= =?utf-8?B?a25QN0tJWE1NLzFoenBJdXBlYlBnMTZKYXRIQVRIK3hUQ0RhQitzU2ZCV2Jm?= =?utf-8?B?YmFMQklIWXQySC9UNkxFYmRKSlpNUGNDOW9wVXFrMWdxRWtraUVsVURGTEJ2?= =?utf-8?B?ZDJxVXl3YXY0QjFjRkk2ZzNocEUxQTdQWm9jTGZTRWVJY3dQOUNzNDBMMzNy?= =?utf-8?B?bEZlQWpQdCtNQWRxU3FoOWE4QnBjSGduY2k3SnU1d3UxSEZGei9oOXAzT0FZ?= =?utf-8?B?Nno0dHhlR3JLOHVmQ09lbkp2NCtlUWs4bXhiN0tJbUIvM3l4VTJrUUZMSWtN?= =?utf-8?B?a3cydGpjd3BWSERsdkN1MVJldFdHMEpLUlJWL2taMlN4MWJyTisxUXJPUkhP?= =?utf-8?B?eGh0c3laN3Q0Q1hqSEc3aWdrK0RXRE11OENQc3JuOUdyUmhoM3RWRWpZdll2?= =?utf-8?B?NU0rUlBpK3VzVW00QWdsajNNRFZSRExNNnZiaDJYYlRxOUljdUJRNDVNbFVv?= =?utf-8?B?NkdoZVJzVFBqZ3V3SFF6U2FOeVVxQVBzbDNXNzRYcTYvZkl3TDY3VGVyNk1G?= =?utf-8?B?YUx2SmRTRTAyUXphc1cxcTY5Z3ZBUjF5aVpPMmZ1VFRjQnUyRzB3VTVhWC9x?= =?utf-8?Q?KEg1Gt8VQKrFaTn85C3ngqauLZYkxctFKUdmdMa?= X-MS-Exchange-CrossTenant-Network-Message-Id: 9c56c73d-91ed-4bb9-8b78-08d953884708 X-MS-Exchange-CrossTenant-AuthSource: DU2P194MB1709.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2021 18:31:42.3439 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f930300c-c97d-4019-be03-add650a171c4 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: GV9KbJwXjwbI+AN9DA3Xk9YO27HROyEDcvOQiBueP7v4mDwdv5X88XigSNbW4vL5OPfjVR6MRSO8vIA2Z6DS78RTR41IeCGlvbAKru5wGPY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2P194MB1680 X-OriginatorOrg: sit.fraunhofer.de Archived-At: Subject: Re: [Secdispatch] Interest COVID-19 'passport' standardization? 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, 30 Jul 2021 18:31:57 -0000 Maybe getting some of the individuals involved that use IETF technologies to do [1] something like that [2] currently could be a good starting point. Viele Grüße, Henk [1] https://github.com/ehn-dcc-development/hcert-spec [2] https://github.com/eu-digital-green-certificates/dgc-overview On 30.07.21 20:18, Harry Halpin wrote: > Everyone [and apologies if you already got this message on CFRG or SAAG], > > While the research community and industry was very quick to work on > privacy-enhanced contact tracing, I've seen very few people taking the > much more pressing issue of COVID-19 passports. > > If this IETF111 was in person, we could have done an informal BoF, but > as its' not, I'm sending out an email to gauge interest. > > I've earlier seen some very badly done academic work using W3C "Verified > Credentials" and W3C Decentralized Identifier (DID) standards [1]. > However, while a bunch of sketchy blockchain technology has not been > adopted (so far, although I believe IATA and WHO are still being heavily > lobbied in this direction), there has been the release of the EU "Green" > Digital Credentials that actually uses digital signatures. > > However, there's a number of problems: > > * No revocation in case of compromise > * Privacy issues, i.e. leaking metadata > * Limited key management (booster shots might require) > * No use of standards for cross-app interoperability > > Furthermore, there appears to be differences between countries, and some > countries do not use cryptography at all (the US). Therefore, as an > American in France who flew home ASAP to get vaccinated in the US, as a > consequence of this lack of interoperability I can't travel on trains or > eat at restaurants easily, despite being vaccinated. I imagine this will > become a larger problem. > > I have a report I'm willing to share, but I'd first like to know if > there's any interest in standardization on this front at the IETF > despite this topic being, I suspect, a bit of  astretch of our remit. > However, we live in interesting times. > > I don't think the W3C (or the ITU, etc.) has the security expertise, and > while the crypto and security/privacy here is pretty simple, I think it > should happen somewhere. > > While I originally polled it by CFRG IRTF to see if there was any > interest whatsoever, Benjamin Kaduk pointed out SAAG and SECDISPATCH > would be better places to start. I'd like to know what others think. > >           yours, >              harry > > [1] https://arxiv.org/abs/2012.00136 > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > From nobody Fri Jul 30 11:51:14 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 551693A0A62 for ; Fri, 30 Jul 2021 11:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 WQIHvOpdXePN for ; Fri, 30 Jul 2021 11:51:07 -0700 (PDT) Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) (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 87DD13A0A41 for ; Fri, 30 Jul 2021 11:51:07 -0700 (PDT) Received: by mail-yb1-f171.google.com with SMTP id g76so17602606ybf.4 for ; Fri, 30 Jul 2021 11:51:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lwQskSOSc3QMd71kK9p92jMqKbBO/xpsP/O7vUfQsAA=; b=deR3puVhM1vVvqCVJxXONVbhowAovTZOl44spIHkB3aRd/4x1E1Xy5FaGGlixFuC00 SG6VYCN06GiKvOzDmxEZwc74S9UzUZfFYoUy8/NmcS6xGZqfrdeOfYtXeFHHD0ZhCZMH XW+w7dHfpPh4CUqI16HvD17GYawpmJk/dSgmtqEfPyGltlsuCbn+FyfiOM8sY5PU6PNo 4PGL9/5E6LXBk3SU7F/VSyFLBMqBH1alb0wxknaqJouNxfpQ5kGQnJwu+b1kWXlT5xVF 5+oDJFD3TVQI53IEqLzXSAnTw/IIa6+6t8LtkWu7Pn5q/EgELPKA1Qk4PK5QWOc4Jcjs bMBw== X-Gm-Message-State: AOAM532ElfPtCLvNVPdWD4GOpKUNNVR1hSSLp9s/TyrKoTx7lAjdu3kR PnXyWJOf/Z1T+Oo5hT6ZifkofhgSwIh2dRKvtxA= X-Google-Smtp-Source: ABdhPJxMpUaDaVympA0J0/FRr65qFj7SnTtlwLAfk8YsoZS91ZsQsavLNp4+0I7nhsZocCj2Nih28m0O1M7hg/KzvtY= X-Received: by 2002:a25:e60a:: with SMTP id d10mr4782969ybh.56.1627671066396; Fri, 30 Jul 2021 11:51:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Fri, 30 Jul 2021 14:50:55 -0400 Message-ID: To: Harry Halpin Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000b94a5005c85bb324" Archived-At: Subject: Re: [Secdispatch] Interest COVID-19 'passport' standardization? 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, 30 Jul 2021 18:51:12 -0000 --000000000000b94a5005c85bb324 Content-Type: text/plain; charset="UTF-8" While I would be interested in working on this, I don't see a role for the IETF unless the government bodies come to IETF asking for the spec. Get the stakeholders round the table before we start talking or it is pointless. The problem here of course is that the governments/airlines etc. don't typically have people with the direct experience of designing this sort of infrastructure. So the most likely outcome is some sort of committee process where almost nobody in the room has the confidence to do the job from scratch and so they start with 'lets build from an existing system it will be quicker' and end up in the mud. Looking at the paper, it does not mention SAML which is actually the only cryptographic assertion format that was expressly designed for this type of use case. The OASIS TC had a much more narrow scope but the original work I did on TAXI (Trust Assertion XML Infrastructure) is the work that was adopted to become the A in SAML. If I was going to revisit that area, I would definitely start from the SAML semantics. People could recast them in JSON or even CBOR if they really wanted but it would be rather pointless. I would certainly avoid PKIX because the TAXI work was begin to address major shortcomings in the semantics of X.509v3 attribute assertions that we had discovered trying to apply them to this type of application. I would also be less interested in OATH, OAUTH, OpenID, etc because they are all designed as Web authentication/authorization schemes and 80% of the specs are working around the constraints of that environment, none of which are relevant to this application. You might as well start with DNSSEC as a starting point. The Mesh has a scheme in which a URL which can be presented as a QR code contains both a locator and a decryption key which can be used to retrieve a static encrypted blob from a Web server and decrypt and authenticate it: Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint. (ietf.org) The intended field of application was to make it easy to transfer from paper driven processes to digital (and back if needed). There are many bureaucratic processes that are paper driven. So digital forms end up being printed out on paper. The EARL scheme allows the paper to have a QR code from which the digital version of the data can be recovered. So electricity company sends me a bill on paper, I scan the QR code, it goes to my payments app. The data on the Web server is inaccessible to any party unless they have the QR code. So this makes a paper document (e.g. patient record) a bearer token for access to the plaintext. The way I would apply this to COVID passports is that I would print out a QR code on a sticker and stick it on the back of the passport. So airline etc. can scan the sticker and get the vaccination status. This can then be correlated to the data obtained from the passport scan. To source the data, I would have each clinic issue signed SAML assertions under a signing key validated by a PKIX credential. I would not use PKIX for the vaccination assertions, the semantics don't match. But I would take advantage of the fact that DigiCert, Sectigo, etc. already have all the CA/LRA etc infrastructure deployed and could spin up private CAs for this in a matter of days. If audit transparency was required, I would not go to Blockchain, I would go to Certificate Transparency. But that is very much a secondary issue. On Fri, Jul 30, 2021 at 2:19 PM Harry Halpin wrote: > Everyone [and apologies if you already got this message on CFRG or SAAG], > > While the research community and industry was very quick to work on > privacy-enhanced contact tracing, I've seen very few people taking the much > more pressing issue of COVID-19 passports. > > If this IETF111 was in person, we could have done an informal BoF, but as > its' not, I'm sending out an email to gauge interest. > > I've earlier seen some very badly done academic work using W3C "Verified > Credentials" and W3C Decentralized Identifier (DID) standards [1]. However, > while a bunch of sketchy blockchain technology has not been adopted (so > far, although I believe IATA and WHO are still being heavily lobbied in > this direction), there has been the release of the EU "Green" Digital > Credentials that actually uses digital signatures. > > However, there's a number of problems: > > * No revocation in case of compromise > * Privacy issues, i.e. leaking metadata > * Limited key management (booster shots might require) > * No use of standards for cross-app interoperability > > Furthermore, there appears to be differences between countries, and some > countries do not use cryptography at all (the US). Therefore, as an > American in France who flew home ASAP to get vaccinated in the US, as a > consequence of this lack of interoperability I can't travel on trains or > eat at restaurants easily, despite being vaccinated. I imagine this will > become a larger problem. > > I have a report I'm willing to share, but I'd first like to know if > there's any interest in standardization on this front at the IETF despite > this topic being, I suspect, a bit of astretch of our remit. However, we > live in interesting times. > > I don't think the W3C (or the ITU, etc.) has the security expertise, and > while the crypto and security/privacy here is pretty simple, I think it > should happen somewhere. > > While I originally polled it by CFRG IRTF to see if there was any interest > whatsoever, Benjamin Kaduk pointed out SAAG and SECDISPATCH would be better > places to start. I'd like to know what others think. > > yours, > harry > > [1] https://arxiv.org/abs/2012.00136 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000b94a5005c85bb324 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While I would be interested in working on this, I don't s= ee a role for the IETF unless the government bodies come to IETF asking for= the spec. Get the stakeholders round the table before we start talking or = it is pointless.

The prob= lem here of course is that the governments/airlines etc. don't typicall= y have people with the direct experience of designing this sort of infrastr= ucture. So the most likely outcome is some sort of committee process where = almost nobody in the room has the confidence to do the job from scratch and= so they start with 'lets build from an existing system it will be quic= ker' and end up in the mud.


Loo= king at the paper, it does not mention SAML which is actually the only cryp= tographic assertion format that was expressly designed for this type of use= case. The OASIS TC had a much more narrow=C2=A0scope but the original work= I did on TAXI (Trust Assertion XML Infrastructure) is the work that was ad= opted to become the A in SAML.

If I was going to revisit that area, I would definitely start from th= e SAML semantics. People could recast them in JSON or even CBOR if they rea= lly wanted but it would be rather pointless.

I would certainly avoid PKIX because the TAXI work was= begin to address major shortcomings in the semantics of X.509v3 attribute = assertions that we had discovered trying to apply them to this type of appl= ication.

I would also be = less interested in OATH, OAUTH, OpenID, etc because they are all designed a= s Web authentication/authorization schemes and 80% of the specs are working= around the constraints of that environment, none of which are relevant to = this application. You might as well start with DNSSEC as a starting point.<= /div>


The Mesh has a scheme in which a UR= L which can be presented as a QR code contains both a locator and a decrypt= ion key which can be used to retrieve=C2=A0a static encrypted blob from a W= eb server and decrypt and authenticate it:

Mathematical Mesh 3.0 Part II: Uniform Data Fingerpri= nt. (ietf.org)

The in= tended field of application was to make it easy to transfer from paper driv= en processes to digital (and back if needed). There are many bureaucratic= =C2=A0processes that are paper driven. So digital forms end up being printe= d out on paper. The EARL scheme allows the paper to have a QR code from whi= ch the digital version of the data can be recovered.

So electricity company sends me a bill on paper= , I scan the QR code, it goes to my payments app.=C2=A0

The data on the Web server is inaccessible t= o any party unless they have the QR code. So this makes a paper document (e= .g. patient record) a bearer token for access to the plaintext.


The way I would apply this to COVID passports = is that I would print out a QR code on a sticker and stick it on the back o= f the passport. So airline etc. can scan the sticker and get the vaccinatio= n status. This can then be correlated to the data obtained from the passpor= t scan.

To source the dat= a, I would have each clinic issue signed SAML assertions under a signing ke= y validated by a PKIX credential. I would not use PKIX for the vaccination = assertions, the semantics don't match. But I would take advantage of th= e fact that DigiCert, Sectigo, etc. already=C2=A0have all the CA/LRA etc in= frastructure deployed and could spin up private CAs for this in a matter of= days.

If audit transpare= ncy was required, I would not go to Blockchain, I would go to Certificate T= ransparency. But that is very much a secondary issue.





On Fri, Jul 30, 2021 at 2:19 PM Harry Halpin <= ;hhalpin@ibiblio.org> wrote:<= br>
=
Everyone [and apologies if= you already got this message on CFRG or SAAG],

While the=20 research community and industry was very quick to work on=20 privacy-enhanced contact tracing, I've seen very few people taking the= =20 much more pressing issue of COVID-19 passports.

If= this IETF111 was in person, we could have done an informal BoF, but as its= ' not, I'm sending out an email to gauge interest.
<= br>
I've earlier seen some very badly done academic work using W3C "Verified= =20 Credentials" and W3C Decentralized Identifier (DID) standards [1].=20 However, while a bunch of sketchy blockchain technology has not been=20 adopted (so far, although I believe IATA and WHO are still being heavily lobbied in this direction), there has been the release of the EU=20 "Green" Digital Credentials that actually uses digital signatures= .

However, there's a number of problems:
<= /div>

* No revocation in case of compromise
* Privacy issues, i.e. leaking metadata
* Limited key managemen= t (booster shots might require)
* No use of standards for cross-a= pp interoperability

Furthermore, there appears to be differences between countries, and some countries=20 do not use cryptography at all (the US). Therefore, as an American in=20 France who flew home ASAP to get vaccinated in the US, as a consequence=20 of this lack of interoperability I can't travel on trains or eat at=20 restaurants easily, despite being vaccinated. I imagine this will become a larger problem.

I have a report I'm=20 willing to share, but I'd first like to know if there's any interes= t in=20 standardization on this front at the IETF despite this topic being, I=20 suspect, a bit of=C2=A0 astretch of our remit. However, we live in=20 interesting times.

I don't think the W3C= =20 (or the ITU, etc.) has the security expertise, and while the crypto and=20 security/privacy here is pretty simple, I think it should happen=20 somewhere.

While I originally polled it by CF= RG IRTF to see if there was any interest whatsoever, Benjamin Kaduk pointed= out SAAG and SECDISPATCH would be better places to start. I'd like to = know what others think.

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yours,
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 harry

=
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000b94a5005c85bb324-- From nobody Fri Jul 30 14:19:13 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 D8AC23A1150; Fri, 30 Jul 2021 14:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, 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=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 t4i08zK8l3FE; Fri, 30 Jul 2021 14:19:06 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 B72DE3A114B; Fri, 30 Jul 2021 14:19:05 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id n11so6768911wmd.2; Fri, 30 Jul 2021 14:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YM39zn9eBMKwJ/7I1RrxKDJ7F4VpKrbmQ9686GWEt44=; b=NHJgnOVOCNcO07IEWU9cyNzKgLhrIRSnHwTp5bdMEx2lhX52xXFKxScoKHL/8XYn6Y 3QGf9uaZUr60KL3McTdD0mFqJasyIlCvzNnOYnQBc4UbdJ4dloG7SB5IkkEg+T3c1nIu TtDDolwmgaB4sxzWBu4RAK0FWt7HPAQBN2Jbu7tkMnZq4EJuiRnYKQctQ5K/aR0CCKbD 7OdwB+qUkNv090Idln6JVsqYIN/wprlFq0cIR+YNhF8RerSDzLGrogog9VF/GVFZU1F8 fBAJly4alb53gEnEYORSqW2nbphX+A780R4cfcU1ADv6c+bgV5z7+/Jt0VnJPGYX8Kz6 bylQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YM39zn9eBMKwJ/7I1RrxKDJ7F4VpKrbmQ9686GWEt44=; b=stLU677ADnmIkU+riulmb4ogxY62S7J87igg7Wh8G9mrlTZLusyAbuoQqndIcbGbUn EDBxzbnun5UK7+DtZ4+Ut+x7PqewrPlQcS0v5PlO9WWcEJ3NeOPRVOXz/esFcfxqA5gF 901f1sHrrP9kth3Kqg96mvvIDaHcLCjYWXKQUrHgCIGukmUQwcDWc4vTrNQM1PbR8INI YTY+0m8egTpN9pIFHQNjpglZAgnNe8jz//ITp9NDe9lIaQwyeLF0p86TaC951qmH7JFg HRPiLMqUIRaBKQIGrnyEfp9D2UftjESFBkcARVjC+HTeVOqv9ryeNP16R6zDPCI5HeTo CZzg== X-Gm-Message-State: AOAM532QMhKz49x2sISpqdeZnfFYBl4KKn7CToNFT+1AkgKx0Dy5UVYD WfaiKVWxOsiVqVYmphbNYuk= X-Google-Smtp-Source: ABdhPJxvTMl6kCsZkHGIzwO/caEp6r6AyqhckTpxE2yK2TF2XBjEdMrDCaeZ2MM+DTw1pNBlhfvOBQ== X-Received: by 2002:a05:600c:2181:: with SMTP id e1mr5330816wme.112.1627679943476; Fri, 30 Jul 2021 14:19:03 -0700 (PDT) Received: from smtpclient.apple (p200300cf1706260094ff9c7bbf6e9ada.dip0.t-ipconnect.de. [2003:cf:1706:2600:94ff:9c7b:bf6e:9ada]) by smtp.gmail.com with ESMTPSA id n4sm2706262wmq.1.2021.07.30.14.19.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jul 2021 14:19:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3686.0.1.2.1\)) From: Henry Story In-Reply-To: Date: Fri, 30 Jul 2021 23:19:01 +0200 Cc: IETF SecDispatch , IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: <7F5A47B0-4E26-4C51-AA21-6A6038A80A95@gmail.com> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3686.0.1.2.1) Archived-At: Subject: Re: [Secdispatch] [saag] Interest COVID-19 'passport' standardization? 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, 30 Jul 2021 21:19:11 -0000 I doubt that the problem with Covid credentials has to do with the=20 format of the credentials, or even the signature technology used to=20 sign them. The knowledge about the virus and the responses to it are evolving very quickly, and so the flexibility of W3C Verifiable Credentials=20 comes in very handy here, as it is built on semantic web standards built on top of first order logic, hypergraphs, and designed for=20 decentralisation, and evolvability.=20 This flexibility is particularly important in a geo-political reality=20 that covers many nations, with many different languages, different laws=20= and no center of control.=20 =20 The verifiable Credentials standards do provide one important element of the puzzle, but it does not solve help to tell which institutions=20 are authorized by a country to give out such credentials. That is = something each=20 country can only decide for itself, each differently as each country=20 has different health systems, regulations, policing, etc=E2=80=A6=20 So what is needed is a way to link these countries together so that=20 a verifying software can tell at any time if the institution that signed a credential is entitled to make such claims by its country, and a way to allow different vocabularies to evolve in a way that makes = convergence possible. This requires a Web of Nations (WoN), which I wrote up here: https://co-operating.systems/2020/06/01/ Technologically we have all the pieces to build such a system. But it requires many different parties to come together to get it to = work. Henry Story > On 30. Jul 2021, at 20:29, Eric Rescorla wrote: >=20 > To recap my comments on CFRG: > There seems to be a lot of enthusiasm for this in various forums, and = it's largely not well coordinated, with each group (the EU, VCI, etc.) = doing their own thing, and producing work of various levels of quality. = Before the IETF got involved, I'd want to see some evidence that the = various players are interested in a common standard and want to do one = here, lest we end up with XKCD 927. >=20 > FWIW, I've spent a bunch of time looking at the various proposals. If = people are interested they can find it at: > https://educatedguesswork.org/tags/vaccine%20passports/ >=20 > -Ekr >=20 >=20 >=20 >=20 > On Fri, Jul 30, 2021 at 11:18 AM Harry Halpin = wrote: > Everyone [and apologies if you already got this message on CFRG or = SECDISPATCH], >=20 > While the research community and industry was very quick to work on = privacy-enhanced contact tracing, I've seen very few people taking the = much more pressing issue of COVID-19 passports. >=20 > If this IETF111 was in person, we could have done an informal BoF, but = as its' not, I'm sending out an email to gauge interest.=20 >=20 > I've earlier seen some very badly done academic work using W3C = "Verified Credentials" and W3C Decentralized Identifier (DID) standards = [1]. However, while a bunch of sketchy blockchain technology has not = been adopted (so far, although I believe IATA and WHO are still being = heavily lobbied in this direction), there has been the release of the EU = "Green" Digital Credentials that actually uses digital signatures. >=20 > However, there's a number of problems:=20 >=20 > * No revocation in case of compromise > * Privacy issues, i.e. leaking metadata > * Limited key management (booster shots might require) > * No use of standards for cross-app interoperability >=20 > Furthermore, there appears to be differences between countries, and = some countries do not use cryptography at all (the US). Therefore, as an = American in France who flew home ASAP to get vaccinated in the US, as a = consequence of this lack of interoperability I can't travel on trains or = eat at restaurants easily, despite being vaccinated. I imagine this will = become a larger problem.=20 >=20 > I have a report I'm willing to share, but I'd first like to know if = there's any interest in standardization on this front at the IETF = despite this topic being, I suspect, a bit of astretch of our remit. = However, we live in interesting times.=20 >=20 > I don't think the W3C (or the ITU, etc.) has the security expertise, = and while the crypto and security/privacy here is pretty simple, I think = it should happen somewhere.=20 >=20 > While I originally polled it by CFRG IRTF to see if there was any = interest whatsoever, Benjamin Kaduk pointed out SAAG and SECDISPATCH = would be better places to start. I'd like to know what others think. >=20 > yours, > harry >=20 > [1] https://arxiv.org/abs/2012.00136 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Jul 30 14:23:51 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 0F0203A1177 for ; Fri, 30 Jul 2021 14:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 iDbXFc61Nv1D for ; Fri, 30 Jul 2021 14:23:48 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 E240B3A1176 for ; Fri, 30 Jul 2021 14:23:47 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id a14so10813351ila.1 for ; Fri, 30 Jul 2021 14:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gpYBwL9WY9RCzWvqEHP0frc7Wt6GKEJYMnFnsjd/foI=; b=qn/FTVWG5NKdSh6G+1B7xdPy6vjuCGiThPvapBkAlgQMc+l8OWkfx/PXnrPoaEivpC kAdwfOMLLja26WfhhinUrXJz9zeT6ovMpWQrVwRcKxugvYWkft05cb+4xIbGmkYEqQCt KxGsOIausdc+1Z5earZizGfv9gThSX4vowl7UtAYFCKlL/ooc7Tjd5cfLAspPqZj2rNr vgL9NGzHPw+zPJCFkASL4Y7MYAcy9oOhgiXy/uOn7P68OZPIeh96wYkXeydh7CLU43bs jqPBw0D162ABmTBqBu/NwBbIVGRh/LYQO8QXqIjnX+FciapVtJRfMLettmrD2Ucj2aWa c4CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gpYBwL9WY9RCzWvqEHP0frc7Wt6GKEJYMnFnsjd/foI=; b=aUBNnZ1WSd3BjILDcU8kwpFv/VWsy/htqlZK2Hhh+GZYf+7zOj1jJAk4cHEovFMm7j /TKxaq9UXRBAQj8Gj2Mpyt1eAU5dk2PptdZJ1y/8NEgdTHIghKIpxzZLZYS9Jegady+L t7gtxR84dGpNWIuhwvUI0C3C78LofhoYKgZxwDG6qcTlXPhm7c2EBvtcqL65gHx3wXcZ LVl+QQQmNBidBFXAwM0ftMAm0EznwlURu4mxUYF9ctvwFQtCN+YW7pR/kDaVIRGZygX+ JU39+J1rBeU2eVGjQFPICE3Oi0XRnGLW8kyCcM0SY29nRPHeuo0jAk+y/VOVomWPihiQ 6gKQ== X-Gm-Message-State: AOAM532Gf3+mb9fwGOvL2kGTqZ7nS3on9kUkJonqI+73DOYIHasiewEk WnWOuS1OIp1AoNblIAbk+Y1gDZF1/07oLCceCCWbGA== X-Google-Smtp-Source: ABdhPJxh62p2h2MQ8UgNoK42H/xGyDi8cmGPzQXx5NdWrO3+wm/KHp2AqE+VUuH25DyE0xStrO/HId0k7FX6ayGSg2M= X-Received: by 2002:a05:6e02:1aae:: with SMTP id l14mr1520095ilv.35.1627680225735; Fri, 30 Jul 2021 14:23:45 -0700 (PDT) MIME-Version: 1.0 References: <7F5A47B0-4E26-4C51-AA21-6A6038A80A95@gmail.com> In-Reply-To: <7F5A47B0-4E26-4C51-AA21-6A6038A80A95@gmail.com> From: Eric Rescorla Date: Fri, 30 Jul 2021 14:23:09 -0700 Message-ID: To: Henry Story Cc: IETF SecDispatch , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000a9d3b005c85dd585" Archived-At: Subject: Re: [Secdispatch] [saag] Interest COVID-19 'passport' standardization? 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, 30 Jul 2021 21:23:49 -0000 --000000000000a9d3b005c85dd585 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 30, 2021 at 2:19 PM Henry Story wrote: > The knowledge about the virus and the responses to it are evolving > very quickly, and so the flexibility of W3C Verifiable Credentials > comes in very handy here, as it is built on semantic web standards > built on top of first order logic, hypergraphs, and designed for > decentralisation, and evolvability. > I don't really agree with this claim. Some of the proposals here use VC and some do not, but they all seem roughly equally capable and flexible to me. -Ekr > --000000000000a9d3b005c85dd585 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jul 30, 2021 at 2:19 PM Henry= Story <henry= .story@gmail.com> wrote:
The knowledge about the virus and the responses to it are e= volving
very quickly, and so the flexibility of W3C Verifiable Credentials
comes in very handy here, as it is built on semantic web standards
built on top of first order logic, hypergraphs, and designed for
decentralisation, and evolvability.

I = don't really agree with this claim. Some of the proposals here use
VC and some do not, but they all seem roughly equally capable and
flexible to me.

-Ekr





--000000000000a9d3b005c85dd585-- From nobody Fri Jul 30 14:33:25 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 232103A11D4 for ; Fri, 30 Jul 2021 14:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 kOQnkmz7yaif for ; Fri, 30 Jul 2021 14:33:19 -0700 (PDT) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (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 40F5D3A11CA for ; Fri, 30 Jul 2021 14:33:19 -0700 (PDT) Received: from smtpclient.apple (77-63-38-235.mobile.kpn.net [77.63.38.235]) (authenticated bits=0) by weser.webweaving.org (8.16.1/8.16.1) with ESMTPSA id 16ULUfkg033796 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Jul 2021 23:30:43 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 77-63-38-235.mobile.kpn.net [77.63.38.235] claimed to be smtpclient.apple Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Dirk-Willem van Gulik In-Reply-To: <7F5A47B0-4E26-4C51-AA21-6A6038A80A95@gmail.com> Date: Fri, 30 Jul 2021 23:29:40 +0200 Cc: Eric Rescorla , IETF SecDispatch , IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: <6E36F759-3840-423D-B946-A9B5FF991056@webweaving.org> References: <7F5A47B0-4E26-4C51-AA21-6A6038A80A95@gmail.com> To: Henry Story X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (weser.webweaving.org [148.251.234.232]); Fri, 30 Jul 2021 23:30:44 +0200 (CEST) Archived-At: Subject: Re: [Secdispatch] [saag] Interest COVID-19 'passport' standardization? 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, 30 Jul 2021 21:33:24 -0000 On 30 Jul 2021, at 23:19, Henry Story wrote: > So what is needed is a way to link these countries together so that=20 > a verifying software can tell at any time if the institution that = signed ..snip.. >=20 > This requires a Web of Nations (WoN), which I wrote up here: > https://co-operating.systems/2020/06/01/ >=20 > Technologically we have all the pieces to build such a system. Indeed. > But it requires many different parties to come together to get it to = work. The DCC / European system (well, eHealth Network to be precise) consists = of a technical system (code at = https://github.com/eu-digital-green-certificates/dgc-gateway) that = collects =E2=80=98root certificates=E2=80=99 of each countries within = the context of the pandemic. These sign document signer certificates - = which in turn sign the Qr codes. This is very similar to the ICAO master = lists used for electronic cross board passports. Joining this network is a technical and legal/governance process:=20 = https://ec.europa.eu/health/sites/default/files/ehealth/docs/covid-certifi= cate_equivalence-decision_en.pdf > a credential is entitled to make such claims by its country, and a way > to allow different vocabularies to evolve in a way that makes = convergence > possible. And this is handled by the technical working groups; with the = vocabulary, schema and similar kept at: https://github.com/ehn-dcc-development/ehn-dcc-valuesets https://github.com/ehn-dcc-development/ehn-dcc-schema https://github.com/ehn-dcc-development/dgc-business-rules And changing/evolving almost as rapidly as the pandemic response. Dw= From nobody Fri Jul 30 14:39:41 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 B07293A120C for ; Fri, 30 Jul 2021 14:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 HEGkbrnREke3 for ; Fri, 30 Jul 2021 14:39:35 -0700 (PDT) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (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 C0E5E3A1204 for ; Fri, 30 Jul 2021 14:39:33 -0700 (PDT) Received: from smtpclient.apple (77-63-38-235.mobile.kpn.net [77.63.38.235]) (authenticated bits=0) by weser.webweaving.org (8.16.1/8.16.1) with ESMTPSA id 16ULav39033922 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Jul 2021 23:36:58 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 77-63-38-235.mobile.kpn.net [77.63.38.235] claimed to be smtpclient.apple From: Dirk-Willem van Gulik Message-Id: <66D90DC4-9BCF-4279-868E-61D5731EC2A4@webweaving.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_8494C909-B4CF-48B7-A22E-9DDEDD023388" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Fri, 30 Jul 2021 23:35:57 +0200 In-Reply-To: Cc: Henry Story , IETF SecDispatch , IETF SAAG To: Eric Rescorla References: <7F5A47B0-4E26-4C51-AA21-6A6038A80A95@gmail.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (weser.webweaving.org [148.251.234.232]); Fri, 30 Jul 2021 23:36:59 +0200 (CEST) Archived-At: Subject: Re: [Secdispatch] [saag] Interest COVID-19 'passport' standardization? 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, 30 Jul 2021 21:39:40 -0000 --Apple-Mail=_8494C909-B4CF-48B7-A22E-9DDEDD023388 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 30 Jul 2021, at 23:23, Eric Rescorla wrote: > On Fri, Jul 30, 2021 at 2:19 PM Henry Story > wrote: > The knowledge about the virus and the responses to it are evolving > very quickly, and so the flexibility of W3C Verifiable Credentials=20 > comes in very handy here, as it is built on semantic web standards > built on top of first order logic, hypergraphs, and designed for=20 > decentralisation, and evolvability.=20 >=20 > I don't really agree with this claim. Some of the proposals here use > VC and some do not, but they all seem roughly equally capable and=20 > flexible to me. =46rom an implementor/designing perspective (both the NL domestic = version -and- the EU DCC version) =E2=80=94 and although we tried very = very hard - the absolute need for totally off-line use & preventing = surveillance*, also, or especially by the issuing entities (or blind = trust in) combined with the inflexible state of the available = semi-usable VC implementations and the very strong desire to have = nothing =E2=80=98central=E2=80=99 and no =E2=80=98central trust=E2=80=99 = - had us gradually evolve to something not quite VC. Despite this being = the stated goal. So I think we have some useful lessons learned w.r.t. the importance of = off-line / totally local validation. Dw *: e.g. spiked certificates with something unlikely to be cached or = requiring a very unique lookup/OCSP, etc.= --Apple-Mail=_8494C909-B4CF-48B7-A22E-9DDEDD023388 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 30 Jul 2021, at 23:23, Eric Rescorla <ekr@rtfm.com> wrote:
On Fri, Jul = 30, 2021 at 2:19 PM Henry Story <henry.story@gmail.com> wrote:
The knowledge about the virus and the = responses to it are evolving
very quickly, and so the flexibility of W3C Verifiable Credentials
comes in very handy here, as it is built on semantic web standards
built on top of first order logic, hypergraphs, and designed for
decentralisation, and evolvability.

I don't really agree = with this claim. Some of the proposals here use
VC = and some do not, but they all seem roughly equally capable and
flexible to = me.

=46rom = an implementor/designing perspective (both the NL domestic version -and- = the EU DCC version)  =E2=80=94 and although we tried very very hard = - the absolute need for totally off-line use & preventing = surveillance*, also, or especially by the issuing entities  (or = blind trust in) combined with the inflexible state of the available = semi-usable VC implementations and the very strong desire to have = nothing =E2=80=98central=E2=80=99 and no =E2=80=98central trust=E2=80=99 = - had us gradually evolve to something not quite VC. Despite this being = the stated goal.

So I think we have = some useful lessons learned w.r.t. the importance of off-line / totally = local validation.

Dw

*:  e.g. spiked certificates with = something unlikely to be cached or requiring a very unique lookup/OCSP, = etc.
= --Apple-Mail=_8494C909-B4CF-48B7-A22E-9DDEDD023388-- From nobody Fri Jul 30 15:09:32 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 338E73A1326 for ; Fri, 30 Jul 2021 15:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=ibiblio-org.20150623.gappssmtp.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 mgqW4LXD5wsW for ; Fri, 30 Jul 2021 15:09:25 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 CF2C03A1320 for ; Fri, 30 Jul 2021 15:09:24 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id cf5so3629779edb.2 for ; Fri, 30 Jul 2021 15:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibiblio-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HrIh+RcS2eTIh6l4IrDym/kQzORY5J7tvcL0WCGmmxI=; b=p1igT820tEQEshXxLEVgOERSJDpKNAoexJXjP+7FB0sN8YQN2qtgfxV4Jbh6HVdU4f fH5eOoVJUe1V3xRPpVzDjeVQNzLAB0QFobMtoOeq4DYEdcumyy9jCTrGBxBVrm2JRhGi W9fWcWr6e5YFQ9fYaq0Y4Or4KElR0uy5htEbLubAGvQtnyJW5j3GW62xgOhsKROfNpcr gpuqIee+W3dCpXKBlKVytH027u1EeXcL5qvVGm7vRIRO8jr2CPj/GbI0u4dLfnQEdMhA VaDw5vc1zv90zZ8iPWJvTBgYr7hVFEcaOBYHsZUGN90YkXfXzNWX1SRD4uMCpg+DZDBx 16+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HrIh+RcS2eTIh6l4IrDym/kQzORY5J7tvcL0WCGmmxI=; b=H1OmoIG+Ax6n/5sT/F4K+hngYE1NuFkZersyW8czfx24ddtshx0lluB3TUAfMTi3in URLXq9kXGEOBhBTc/cy5+ZDWfoCBklLDmGBey6Ag8qGvt/KanQQfcJDTgksiG383/o5L hx2tv19F/W/qGzIH0cc3AFGzhv6Ri11KvWNVajyp21RQEdhkySAZbyd1neBS1fy6qjFF D284pfWHWot4q3b3KzPvmthbPcjH50xJxzgQK7wSF6sTw1MvuZQSP3XSABxFQfFLeS/y QppbGRrLiutww25v/tXdxNbPvDkSs+gqQD6PDgoZbDa2ZpuW84lWJW6qwAYZgWa+nLUX O99Q== X-Gm-Message-State: AOAM530deSJLmebSdhr87s1u1gbNXJzO642FPE++yzWqWCDj/LkUdD3b a2UPXJ2C6ttsslLw14lOY/RU00Nb9iSBaHGgMY6ctw== X-Google-Smtp-Source: ABdhPJy3pTmS/u9QLGy/ENKYag0PJArs/KGaCoEjDOqOJNWNz96aMagxVekR00d1WIKBEf6jtvmU4Jc7IFJPF7L8YHc= X-Received: by 2002:aa7:c857:: with SMTP id g23mr5682970edt.100.1627682962541; Fri, 30 Jul 2021 15:09:22 -0700 (PDT) MIME-Version: 1.0 References: <7F5A47B0-4E26-4C51-AA21-6A6038A80A95@gmail.com> <66D90DC4-9BCF-4279-868E-61D5731EC2A4@webweaving.org> In-Reply-To: <66D90DC4-9BCF-4279-868E-61D5731EC2A4@webweaving.org> From: Harry Halpin Date: Sat, 31 Jul 2021 00:09:11 +0200 Message-ID: To: Dirk-Willem van Gulik Cc: Eric Rescorla , IETF SecDispatch , Henry Story , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000ca1e1d05c85e7811" Archived-At: Subject: Re: [Secdispatch] [saag] Interest COVID-19 'passport' standardization? 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, 30 Jul 2021 22:09:30 -0000 --000000000000ca1e1d05c85e7811 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Everyone, Good to see this conversation, and the contributions from Dirk have been exceptionally relevant. In particular, I would put out of scope requiring any verifier to be online and I would also put out of scope data formats with limited real-world uptake, like W3C RDF and Verified Credentials. I would focus on widely deployed standards, such as JOSE/COSE and TLS. In this regard, the EU DGC has done well. I'd like to see international comparison though, as I can imagine many other "proposals" or even working systems are not using modern cryptography. I suspect there is definitely a need for a privacy analysis that is more thorough than DGC has done (surprised to see linkable signatures, centralized databases, and so on and so forth) when we know how to build better and more in the EU GDPR-compliant standards - although I suspect COVID-19 falls under a national security derogation and so GDPR does not apply. Not sure how many people are actually interested in chartering something and the scope, but I'd be happy to host a meeting if someone is attending IETF 111. Although it may be rather late for some, I will be hosting a "side meeting" virtually at the IETF 111 meeting today right after the CFRG IRTF meeting ends. See the wiki for the link: https://trac.ietf.org/trac/ietf/meeting/wiki/111sidemeetings yours, harry On Fri, Jul 30, 2021 at 11:39 PM Dirk-Willem van Gulik wrote: > On 30 Jul 2021, at 23:23, Eric Rescorla wrote: > > On Fri, Jul 30, 2021 at 2:19 PM Henry Story wrote= : > >> The knowledge about the virus and the responses to it are evolving >> very quickly, and so the flexibility of W3C Verifiable Credentials >> comes in very handy here, as it is built on semantic web standards >> built on top of first order logic, hypergraphs, and designed for >> decentralisation, and evolvability. >> > > I don't really agree with this claim. Some of the proposals here use > VC and some do not, but they all seem roughly equally capable and > flexible to me. > > > From an implementor/designing perspective (both the NL domestic version > -and- the EU DCC version) =E2=80=94 and although we tried very very hard= - the > absolute need for totally off-line use & preventing surveillance*, also, = or > especially by the issuing entities (or blind trust in) combined with the > inflexible state of the available semi-usable VC implementations and the > very strong desire to have nothing =E2=80=98central=E2=80=99 and no =E2= =80=98central trust=E2=80=99 - had > us gradually evolve to something not quite VC. Despite this being the > stated goal. > > So I think we have some useful lessons learned w.r.t. the importance of > off-line / totally local validation. > > Dw > > *: e.g. spiked certificates with something unlikely to be cached or > requiring a very unique lookup/OCSP, etc. > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000ca1e1d05c85e7811 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Everyone,

Good to see this c= onversation, and the contributions from Dirk have been exceptionally releva= nt. In particular, I would put out of scope requiring any verifier to be on= line and I would also put out of scope data formats with limited real-world= uptake, like W3C RDF and Verified Credentials. I would focus on widely dep= loyed standards, such as JOSE/COSE and TLS. In this regard, the EU DGC has = done well. I'd like to see international comparison though, as I can im= agine many other "proposals" or even working systems are not usin= g modern cryptography. I suspect there is definitely a need for a privacy a= nalysis that is more thorough than DGC has done (surprised to see linkable = signatures, centralized databases, and so on and so forth) when we know how= to build better and more in the EU GDPR-compliant standards - although I s= uspect COVID-19 falls under a national security derogation and so GDPR does= not apply.

Not sure how many people are actu= ally interested in chartering something and the scope, but I'd be happy= to host a meeting if someone is attending IETF 111.

Although it may be rather late for some, I will be hosting a "side = meeting" virtually at the IETF 111 meeting today right after the CFRG = IRTF meeting ends. See the wiki for the link: https://trac.ietf.org/trac/ietf= /meeting/wiki/111sidemeetings

=C2=A0 yours,
=C2=A0=C2=A0=C2=A0 harry


On Fri, Jul 30, 2021= at 11:39 PM Dirk-Willem van Gulik <dirkx@webweaving.org> wrote:
On 30 Jul= 2021, at 23:23, Eric Rescorla <ekr@rtfm.com> wrote:
<= div>
On Fri, Jul 30, 2021 at 2:19 PM Henry Story <henry.story@gmail.com> wr= ote:
The knowled= ge about the virus and the responses to it are evolving
very quickly, and so the flexibility of W3C Verifiable Credentials
comes in very handy here, as it is built on semantic web standards
built on top of first order logic, hypergraphs, and designed for
decentralisation, and evolvability.

I = don't really agree with this claim. Some of the proposals here use
VC and some do not, but they all seem roughly equally capable and
flexible to me.

<= div>From an implementor/designing perspective (both the NL domestic version= -and- the EU DCC version) =C2=A0=E2=80=94 and although we tried very very = hard - the absolute need for totally off-line use & preventing surveill= ance*, also, or especially by the issuing entities =C2=A0(or blind trust in= ) combined with the inflexible state of the available semi-usable VC implem= entations and the very strong desire to have nothing =E2=80=98central=E2=80= =99 and no =E2=80=98central trust=E2=80=99 - had us gradually evolve to som= ething not quite VC. Despite this being the stated goal.

So I think we have some useful lessons learned w.r.t. the importance= of off-line / totally local validation.

Dw
<= br>
*: =C2=A0e.g. spiked certificates with something unlikely to be cac= hed or requiring a very unique lookup/OCSP, etc.
_______________= ________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000ca1e1d05c85e7811-- From nobody Sat Jul 31 03:07: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 A31573A2065 for ; Sat, 31 Jul 2021 03:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 qu2gmFG3HJxz for ; Sat, 31 Jul 2021 03:07:39 -0700 (PDT) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (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 0AAA53A2062 for ; Sat, 31 Jul 2021 03:07:35 -0700 (PDT) Received: from smtpclient.apple (77-63-50-29.mobile.kpn.net [77.63.50.29]) (authenticated bits=0) by weser.webweaving.org (8.16.1/8.16.1) with ESMTPSA id 16VA3PHj062515 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 31 Jul 2021 12:03:26 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 77-63-50-29.mobile.kpn.net [77.63.50.29] claimed to be smtpclient.apple From: Dirk-Willem van Gulik Message-Id: <7D1A5E18-4369-47DC-9FC6-A88AF1876AA9@webweaving.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_9A6F9668-00DE-4FFD-BE88-9956B89EC056" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Sat, 31 Jul 2021 12:02:22 +0200 In-Reply-To: Cc: Eric Rescorla , IETF SecDispatch , Henry Story , IETF SAAG To: Harry Halpin References: <7F5A47B0-4E26-4C51-AA21-6A6038A80A95@gmail.com> <66D90DC4-9BCF-4279-868E-61D5731EC2A4@webweaving.org> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (weser.webweaving.org [148.251.234.232]); Sat, 31 Jul 2021 12:03:31 +0200 (CEST) Archived-At: Subject: Re: [Secdispatch] [saag] Interest COVID-19 'passport' standardization? 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, 31 Jul 2021 10:07:44 -0000 --Apple-Mail=_9A6F9668-00DE-4FFD-BE88-9956B89EC056 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 31 Jul 2021, at 00:09, Harry Halpin wrote: > working systems are not using modern cryptography. I suspect there is = definitely a need for a privacy analysis that is more thorough than DGC = has done Fully agreed -and with the worst of the crisis over - this is a good = time. Also as it is very likely that this is the time for changes/fixes.=20= We are getting the first from the field experience, mis-implementations = (e.g. the UK got the KeyIdentifier wrong, some countries have URNs that = are not valid URIs, etc), the type of fraud that makes economic or = political sense and start to see where the trust model is hard from a = national governance perspective (e.g. due to delegation of sovereignty = of overseas territories). But also as the DCC system is now pushed = beyond its design - from a governance perspective (the majority of = countries using it may soon well be non EU/EC & EEA /), from a = technical perspective (as countries are now considering boosters & = similar) and from a use case perspective - - domestic / private sector = scanning is now becoming a thing.=20 So the timing is right to address this. And the IETF would be a good & = neutral place - as this is first and foremost a standards exercise = (actual code is almost laughably trivial[1] - so it is not a essential = to start own the open source / code side). > (surprised to see linkable signatures, centralized databases, and so = on and so forth) when we know how to build better and Note tha the DCC does not have a centralised database (and in fact, a = lot of countries do not have any central database either - but rely on = very distributed, delegate and often offline/non-API approachable data = holdings in the country. Nor is the trust list centralised - each member = state manages this essentially itself. The main central elements are the = design, the joint list of =E2=80=98valid=E2=80=99 (that include = =E2=80=9Cvalids=E2=80=9D that are not generally accepted; e.g. the codes = for Sinovac en Sputnik) that is jointly maintained and a convenience = =E2=80=99trust list=E2=80=99 that is jointly managed for countries that = are under the (privacy) regulation or have some adequacy/equivalence = regulation or law in place. > more in the EU GDPR-compliant standards - although I suspect COVID-19 = falls under a national security derogation and so GDPR does not apply. Currently - the engineering design assumption is that the GDPR fully = applies - and both EUPD and the various national privacy regulators are = heavily involved/heavily influenced the design. The final regulation = actually goes quite a few steps further than the GDPR - and disallows = certain things (around PII handling, revocation lists and especially the = retention of any data post scan) that could conceivable be reasonable = and proportional under the GDPR for certain goals. > Not sure how many people are actually interested in chartering = something and the scope, but I'd be happy to host a meeting if someone = is attending IETF 111. Happy to help out / provide information on what was done & why. As I = realise that both speed and the international collaboration processes = used were not that easy to follow from afar. With kind regards, Dw 1: Basically line 126 in = https://github.com/ehn-dcc-development/ehn-sign-verify-python-trivial/blob= /main/hc1_sign.py =E2=80=94 CBOR package your JSON, COSE sign it; = Zlib-deflate compress and put it into Base45[2] so it becomes Qr = friendly (QRs then have a a 5.5bit efficient mode that is more scanner = in the field-resistant than a raw 8bit Qr - yet is almost the same # of = pixels). 2: https://datatracker.ietf.org/doc/draft-faltstrom-base45/ --Apple-Mail=_9A6F9668-00DE-4FFD-BE88-9956B89EC056 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 31 Jul 2021, at 00:09, Harry Halpin <hhalpin@ibiblio.org>= wrote:

working systems are not using modern = cryptography. I suspect there is definitely a need for a privacy = analysis that is more thorough than DGC has = done

Fully = agreed -and with the worst of the crisis over - this is a good time. = Also as it is very likely that this is the time for = changes/fixes. 

We are getting = the first from the field experience, mis-implementations (e.g. the UK = got the KeyIdentifier wrong, some countries have URNs that are not valid = URIs, etc), the type of fraud that makes economic or political sense and = start to see where the trust model is hard from a national governance = perspective (e.g. due to delegation of sovereignty of overseas = territories). But also as the DCC system is now pushed beyond its design = - from a governance perspective (the majority of countries using it may = soon well be non EU/EC & EEA /), from a  technical perspective = (as countries are now considering boosters & similar) and from a use = case perspective - - domestic / private sector scanning is now becoming = a thing. 

So the timing is = right to address this. And the IETF would be a good & neutral place = - as this is first and foremost a standards exercise (actual code is = almost laughably trivial[1] - so it is not a essential to start own the = open source / code side).

(surprised to see = linkable signatures, centralized databases, and so on and so forth) when = we know how to build better and

Note tha the DCC does not have a centralised database = (and in fact, a lot of countries do not have any central database either = - but rely on very distributed, delegate and often offline/non-API = approachable data holdings in the country. Nor is the trust list = centralised - each member state manages this essentially itself. The = main central elements are the design, the joint list of =E2=80=98valid=E2=80= =99 (that include =E2=80=9Cvalids=E2=80=9D that are not generally = accepted; e.g. the codes for Sinovac en Sputnik) that is jointly = maintained and a convenience =E2=80=99trust list=E2=80=99 that is = jointly managed for countries that are under the (privacy) regulation or = have some adequacy/equivalence regulation or law in place.

more in the EU = GDPR-compliant standards - although I suspect COVID-19 falls under a = national security derogation and so GDPR does not = apply.

Currently - the engineering design assumption is = that the GDPR fully applies - and both EUPD and the various national = privacy regulators are heavily involved/heavily influenced the design. = The final regulation actually goes quite a few steps further than the = GDPR - and disallows certain things (around PII handling, revocation = lists and especially the retention of any data post scan) that could = conceivable be reasonable and proportional under the GDPR for certain = goals.

Not sure how many = people are actually interested in chartering something and the scope, = but I'd be happy to host a meeting if someone is attending IETF = 111.

Happy to = help out / provide information on what was done & why. As I realise = that both speed and the international collaboration processes used were = not that easy to follow from afar.

With kind regards,

Dw


1: Basically line 126 in https://github.com/ehn-dcc-development/ehn-sign-verify-python-t= rivial/blob/main/hc1_sign.py =E2=80=94 CBOR package your JSON, COSE = sign it; Zlib-deflate compress and put it into Base45[2] so it becomes = Qr friendly (QRs then have a a 5.5bit efficient mode that is more = scanner in the field-resistant than a raw 8bit Qr - yet is almost the = same # of pixels).

2: https://datatracker.ietf.org/doc/draft-faltstrom-base45/




= --Apple-Mail=_9A6F9668-00DE-4FFD-BE88-9956B89EC056--