From nobody Thu Jul 2 17:22:30 2020 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 620003A0A3B; Thu, 2 Jul 2020 17:20:35 -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.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373563538.30173.13903748164436459463@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:20:35 -0700 Archived-At: Subject: [Secdispatch] secdispatch - Requested session has been scheduled for IETF 108 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, 03 Jul 2020 00:20:46 -0000 Dear Francesca Palombini, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. secdispatch Session 1 (1:40 requested) Thursday, 30 July 2020, Session I 1100-1240 Room Name: Room 5 size: 5 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/secdispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Security Dispatch Area Name: Security Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 200 Conflicts to Avoid: Chair Conflict: cbor core gendispatch httpbis Technology Overlap: saag dispatch ace acme cose curdle dots emu i2nsf ipsecme kitten lake lamps mile mls oauth rats sacm secevent suit teep tls tokbind trans People who must be present: Kathleen Moriarty Roman Danyliw Richard Barnes Benjamin Kaduk Francesca Palombini Resources Requested: Special Requests: Please avoid conflict with any Security related BoF. --------------------------------------------------------- From nobody Mon Jul 6 03:26:37 2020 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 4085E3A1317; Mon, 6 Jul 2020 03:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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 XbktO596D33A; Mon, 6 Jul 2020 03:26:30 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140084.outbound.protection.outlook.com [40.107.14.84]) (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 88E5E3A1319; Mon, 6 Jul 2020 03:26:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OsUO1fo/G38J78MTxKOd+H3u9r9GJdqjFXnzsfg3SHWRjKQlH31Xh+z+ionWL8tmaIP7cqi4IVQbuZdpawb65gDx0hBoagvN52spS8y5REIUtsypLZ3tDN2YnzFL6KaldvfXgIhq/BkEhStJerfhMR2YOb0qkzPc78I+D9JYUweCwibPbjjTSgRNSlNjcuNd4jxDCKn3XLZO23X6BNiyl2YDIOD1HH8/XNIfErH5AdKlKRHhhrEW0LoKAyCW2E4hithcr9pL902gh6h2rm3QW39FVnLSgl3V5Efg1KetqLcgJc9k5K8MCNWBUwl9ZBDwQcBm2RM0dB96NxF+DAPy8Q== 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=bR0+OMwb0Y5nSXAsxVROqL9j3bY694w13K4T0cao8EA=; b=dACG8OFJgSQA3XpQIcX6hxHzXddOcCO2j+Q+Vvrsxf2puFbw5G/GIa1ENrJk7khcvjNCe3cwthLgJTDUwTo+mI3QBDqpPA+QGBc2JsQworKYPB5+gA4+EUKXPLm59vHp4pvwojTAWySniItLAEUSvzCWcLaj+2lFMEHbCO1zkVvbxrTZ4aCEfa2P/8S6xaiG9AiEaQOHjVhysx9s4tSDcFB/wM/4T5rk3Lq6AEoZGBv+NVYX0OkumV2LAhqSz8t9ky/CGpnRJVE7ixuo4IfiKlmVanQhaKNtpG4Ctx9rSmInR7RyfoHRPsmr7FM9KWPmEP+S9IoIvAKfwsBFYKAO/A== 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=bR0+OMwb0Y5nSXAsxVROqL9j3bY694w13K4T0cao8EA=; b=al+qT2g/pjZSgAqa3XmZzAmj5mH9FBMwCXy56TmY56vDzX0jMOJ8cffhmdIwrs9iy7sthWOa02atWkX480rnXJHNDeBIg0HHCB8/FsNajSqaFQSTGgM9sfcIxSjP563yAcbPGIZH066OwCtc0c3wGYM7POCe5oSO/EdK7C7owWU= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR07MB4156.eurprd07.prod.outlook.com (2603:10a6:7:9b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.8; Mon, 6 Jul 2020 10:26:23 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3174.019; Mon, 6 Jul 2020 10:26:23 +0000 From: Francesca Palombini To: "secdispatch@ietf.org" , "ietf@ietf.org" CC: "secdispatch-chairs@ietf.org" Thread-Topic: Call for agenda items Secdispatch IETF108 Thread-Index: AQHWU3/l96KrcBEYoEm+H9aeeiEAVw== Date: Mon, 6 Jul 2020 10:26:23 +0000 Message-ID: <07A18D3F-D738-4C0A-A0FF-D4A61D9B6065@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.153.190.14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4508954e-222c-4d75-13d2-08d82197087e x-ms-traffictypediagnostic: HE1PR07MB4156: 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: MlEGHq/Ws67HfaVekI4g4KoKVYn1KPUG4mCpjqjVx+6Vy3KLqCB3NG6ZemjV6lR0jP4s0rmvR2HjCX09Z5ihloVPHju2TmOxhWCvCCQEGqJhEM2Il+ahuIgdh3zqLpvahlDMcVtQnR6fGpww/OAyJgh6BqRNlJIoCdIzpGUOdCPF4QSlgMSmqSuhSRqjIhDyio034jRWZKpD4krf9T/zeS1qfH0vD9h0cHXJaM7kt7yTbM0FlDhyc5HSQdoWGxfNaw2sFIquMQARHHfO03d7qrJ0Dxhej9Orxe2YUf868ea9TIvt93HcpoEPyUC65CKKTvS4wljnx9jzOFhnGQu6L+UNHybfPJ7JYQIblBhqMChiYDKHL/lcISHl7F5Ci9D8vnDTreYD2PCuW4GEOgk9mA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(376002)(136003)(39860400002)(346002)(8936002)(26005)(83380400001)(2616005)(44832011)(4326008)(478600001)(36756003)(450100002)(2906002)(6486002)(71200400001)(8676002)(966005)(64756008)(66446008)(66556008)(6512007)(186003)(33656002)(5660300002)(66946007)(66476007)(316002)(76116006)(91956017)(86362001)(6506007)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: tTAaHkRlEDWtPpprki5lP6hZv9hI6lmqY9vQsGM+BL7cf0/e9dVwsQdylGUuuF7LoEpxGwhWW/ZFY9Qmv3ghy9xGYFWtOsf8xQcn3ocXtt7MLuXrcTg/MEQgdZ/1Isrf1pjmXMYdRZQQXBrlh/Qa3Zzp6jcT7DkqT80pdFMGuJt12AvezdHtN0tGnhxTfzudATBIpdCFyrk4cDMQaaIkuFaBzuVJGppftPnX0N8WUaf8/0yEDEFGv3ltWQLNEA1oleaA5AOgEkIbYluZjpPFx30PMzXIhM2wOO/Hu8c3bGMfN2KhFRI3fKL5JEShW7yhQwcPPdeTD/s8Ny7c/W+5DOq5GMaVWQtHkyryKVphFobEQDMJDRpWAv8RBvlSKciy3qL/ytJO37+XD/SPlV0bC35CZz4fpDhc9hcKZ7m3BlgxWh2/hVZE46SyMMdrbRd6JHCaahp9qRNNopsipCz0OEQ4wfCxKcVtrTBk1d/AlvhCwZXZZAkURItESNIhD19c x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4508954e-222c-4d75-13d2-08d82197087e X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2020 10:26:23.8024 (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: 0IoVDMds+sGRK72VXhOP9A+j1hWkV9cCKvXnzggCKesPRs8w2sTyTFIi7zlWGRl37oAq3mr9fv/pR440rROHtS+IkRcbPQuJYivmJpK4n35qrCIOfl2/SPy/nHbzd0s9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4156 Archived-At: Subject: [Secdispatch] Call for agenda items Secdispatch IETF108 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, 06 Jul 2020 10:26:31 -0000 SGkgYWxsLA0KDQpBcyB5b3UgbWlnaHQgaGF2ZSBzZWVuLCBTZWNkaXNwYXRjaCBoYXMgYmVlbiBz Y2hlZHVsZWQgdG8gaGF2ZSBhbiBhbGwgdmlydHVhbCBtZWV0aW5nIG9uIFRodXJzZGF5LCAzMCBK dWx5IDIwMjAsIDExOjAwLTEyOjQwIFVUQy4NClRoZSBzZXNzaW9uIHdpbGwgaGFwcGVuIG92ZXIg TWVldGVjaG8sIGFuZCB5b3Ugd2lsbCBuZWVkIHRvIHJlZ2lzdGVyIHRvIElFVEYgdG8gcGFydGlj aXBhdGUuIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIGhvdyB0byBwYXJ0aWNpcGF0ZTogaHR0cHM6 Ly9pZXRmLm9yZy9ob3cvbWVldGluZ3MvMTA4L3Nlc3Npb24tcGFydGljaXBhbnQtZ3VpZGUvDQoN CldlIGFyZSB3b3JraW5nIG9uIHRoZSBhZ2VuZGEuIEN1cnJlbnRseSB3ZSBoYXZlIDIgYWdlbmRh IGl0ZW1zLCB3aGljaCB5b3UgY2FuIGZpbmQgaW4gdGhlIHdpa2k6IGh0dHBzOi8vdHJhYy5pZXRm Lm9yZy90cmFjL3NlY2Rpc3BhdGNoL3dpa2kvaWV0ZjEwOCANCg0KVGhpcyBpcyBvdXIgc2Vjb25k IGNhbGwgZm9yIGFnZW5kYSBpdGVtcy4gSWYgeW91IHdvdWxkIGxpa2UgdGltZSBvbiB0aGUgYWdl bmRhLCBzZW5kIHlvdXIgcmVxdWVzdCB0byB0aGUgbWFpbGluZyBsaXN0IGJlZm9yZSBUdWVzZGF5 LCBKdWx5IDE0dGguICBIZWxwZnVsIGl0ZW1zIHRvIGluY2x1ZGUgaW4geW91ciByZXF1ZXN0IChp ZiBrbm93bi9hcHBsaWNhYmxlKSBhcmU6DQoNCigxKSBwb2ludGVycyB0byBhIGRyYWZ0KHMpDQoo MikgcG9pbnRlcnMgdG8gb25nb2luZy9wcmlvciBkaXNjdXNzaW9ucw0KKDMpIHBvaW50ZXJzIHRv IGltcGxlbWVudGF0aW9ucw0KKDQpIHBvaW50ZXJzIHRvIGFueSBvdGhlciBiYWNrZ3JvdW5kIG1h dGVyaWFscw0KKDUpIHN1bW1hcml6aW5nIHByaW9yIGVuZ2FnZW1lbnQgd2l0aCBleGlzdGluZyBX R3MNCig2KSBzdW1tYXJpemluZyB3aG8gd291bGQgd2FudCB0byBhZHZhbmNlIHRoaXMgd29yaw0K KDcpIGRlc2lyZWQgbmV4dCBzdGVwcw0KKDgpIGRlc2lyZWQgdGltZSBmb3IgZGlzY3Vzc2lvbg0K DQpJZiBuZWVkZWQsIHByZWNlZGVuY2UgaW4gdGhlIG1lZXRpbmcgd2lsbCBiZSBnaXZlbiB0byBk b2N1bWVudHMgdGhhdCBoYXZlIGRlbW9uc3RyYXRlZCBpbnRlcmVzdCBpbiB0aGUgZm9ybSBvZiBh Y3RpdmUgZHJhZnRzIGFuZCBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbi4NCklmIHlvdSBoYXZlIHF1 ZXN0aW9ucywgcGxlYXNlIHJlYWNoIG91dCB0byB0aGUgY2hhaXJzLg0KDQpUaGFua3MsDQpGcmFu Y2VzY2ENCg0K77u/T24gMDMvMDcvMjAyMCwgMDI6MjAsICIiSUVURiBTZWNyZXRhcmlhdCIiIDxh Z2VuZGFAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgRGVhciBGcmFuY2VzY2EgUGFsb21iaW5pLA0K DQogICAgVGhlIHNlc3Npb24ocykgdGhhdCB5b3UgaGF2ZSByZXF1ZXN0ZWQgaGF2ZSBiZWVuIHNj aGVkdWxlZC4NCiAgICBCZWxvdyBpcyB0aGUgc2NoZWR1bGVkIHNlc3Npb24gaW5mb3JtYXRpb24g Zm9sbG93ZWQgYnkNCiAgICB0aGUgb3JpZ2luYWwgcmVxdWVzdC4gDQoNCg0KICAgICAgICBzZWNk aXNwYXRjaCBTZXNzaW9uIDEgKDE6NDAgcmVxdWVzdGVkKQ0KICAgICAgICBUaHVyc2RheSwgMzAg SnVseSAyMDIwLCBTZXNzaW9uIEkgMTEwMC0xMjQwDQogICAgICAgIFJvb20gTmFtZTogUm9vbSA1 IHNpemU6IDUNCiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCg0KICAgIGlDYWxlbmRhcjogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9t ZWV0aW5nLzEwOC9zZXNzaW9ucy9zZWNkaXNwYXRjaC5pY3MNCg0KICAgIFJlcXVlc3QgSW5mb3Jt YXRpb246DQoNCg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgIFdvcmtpbmcgR3JvdXAgTmFtZTogU2VjdXJpdHkgRGlzcGF0 Y2gNCiAgICBBcmVhIE5hbWU6IFNlY3VyaXR5IEFyZWENCiAgICBTZXNzaW9uIFJlcXVlc3Rlcjog RnJhbmNlc2NhIFBhbG9tYmluaQ0KDQoNCiAgICBOdW1iZXIgb2YgU2Vzc2lvbnM6IDENCiAgICBM ZW5ndGggb2YgU2Vzc2lvbihzKTogIDEwMCBNaW51dGVzDQogICAgTnVtYmVyIG9mIEF0dGVuZGVl czogMjAwDQogICAgQ29uZmxpY3RzIHRvIEF2b2lkOiANCiAgICAgQ2hhaXIgQ29uZmxpY3Q6IGNi b3IgY29yZSBnZW5kaXNwYXRjaCBodHRwYmlzDQogICAgIFRlY2hub2xvZ3kgT3ZlcmxhcDogc2Fh ZyBkaXNwYXRjaCBhY2UgYWNtZSBjb3NlIGN1cmRsZSBkb3RzIGVtdSBpMm5zZiBpcHNlY21lIGtp dHRlbiBsYWtlIGxhbXBzIG1pbGUgbWxzIG9hdXRoIHJhdHMgc2FjbSBzZWNldmVudCBzdWl0IHRl ZXAgdGxzIHRva2JpbmQgdHJhbnMNCg0KDQoNCg0KDQoNCiAgICBQZW9wbGUgd2hvIG11c3QgYmUg cHJlc2VudDoNCiAgICAgIEthdGhsZWVuIE1vcmlhcnR5DQogICAgICBSb21hbiBEYW55bGl3DQog ICAgICBSaWNoYXJkIEJhcm5lcw0KICAgICAgQmVuamFtaW4gS2FkdWsNCiAgICAgIEZyYW5jZXNj YSBQYWxvbWJpbmkNCg0KICAgIFJlc291cmNlcyBSZXF1ZXN0ZWQ6DQoNCiAgICBTcGVjaWFsIFJl cXVlc3RzOg0KICAgICAgUGxlYXNlIGF2b2lkIGNvbmZsaWN0IHdpdGggYW55IFNlY3VyaXR5IHJl bGF0ZWQgQm9GLg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0K From nobody Mon Jul 13 02:37:53 2020 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 4C4C33A0CF0; Mon, 13 Jul 2020 02:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=qqoKaBJp; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=qqoKaBJp 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 lnuv8_J1xwP3; Mon, 13 Jul 2020 02:37:50 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60070.outbound.protection.outlook.com [40.107.6.70]) (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 18D493A0CEC; Mon, 13 Jul 2020 02:37:49 -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=9JN94xcnMnFyY9Wmps6/J8sEhzX+tsiFqWc9Be3J1X0=; b=qqoKaBJp3F2eOT5hrGGaNg6zNzXCZE+xCdfImJEjs3sWM9RJQxXnWU+5R+ZZ949ol7RwJCeyDdW7sPmjUouIX1z6G1V+mRE1jasNWYcTay1frxuAbfMY0ccfLT4kuJ2LuksyyXwzglcBQ5u3BUEoScA53vyk9bkDFeaFlLgtwmI= Received: from DB7PR03CA0108.eurprd03.prod.outlook.com (2603:10a6:10:72::49) by AM6PR08MB2967.eurprd08.prod.outlook.com (2603:10a6:209:44::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.22; Mon, 13 Jul 2020 09:37:47 +0000 Received: from DB5EUR03FT035.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:72:cafe::d0) by DB7PR03CA0108.outlook.office365.com (2603:10a6:10:72::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20 via Frontend Transport; Mon, 13 Jul 2020 09:37:47 +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=bestguesspass 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 DB5EUR03FT035.mail.protection.outlook.com (10.152.20.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Mon, 13 Jul 2020 09:37:47 +0000 Received: ("Tessian outbound 7de93d801f24:v62"); Mon, 13 Jul 2020 09:37:47 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 46e88ae17fe2b7ef X-CR-MTA-TID: 64aa7808 Received: from f31f979f247d.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 0CD46286-6910-4B94-8268-A71EE7F7A15C.1; Mon, 13 Jul 2020 09:37:41 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f31f979f247d.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 13 Jul 2020 09:37:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q0Ziwjzxi6C0Rpqy9aNP0BdxzfAaEKzPg6M1m96gZh2VB7cNszyLUjEKz2DuPNmcb7xzMtwrYsyQYxDH+uIc1XoMTUk+McCTdoCaCLn2DE/q3mKD0rKCZZlqAsjeq4X1AltnCnRCT2m+Y48LcIwObrggYDugO1i4iyAukXpzSq26aymkuDL2ZYFT9IZKNsIbOqXX9ar3D8R3xBcDm9LwTrPgKH9VX0pVgcXDlZ5mpnAtn9OKz+dkXPU/gIab5GdDf6SMwUza+DPXvrvAMXehFoLCQyLM5V1Iox61gb2wj0L/XR8b9oTfMNn2iJ3AemmhwgGRk4ya4wgt9z9AHTeE8Q== 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=9JN94xcnMnFyY9Wmps6/J8sEhzX+tsiFqWc9Be3J1X0=; b=P1Yjc8PdyJknq91ZYFmELoWQd8WP2clIZy0TXdQXQCB1N11E9CX3mAA/jYaJnFYiGj43LKWm2g4VoPcQkiFgcyPkPxAuaSePJ+XKyeqwfRMtYI+CdAKc7jvBCDpZARGMkwL+tUip2jkMUDLDEvotSeVCB6jadWGAeSvFFikgx7wkzIvSN4waPrD1V69aYorYZHRrbfI5i1z3GxMd/AAt29Bcq0/2u7uFkzeD3UVowoygWTm1BMAhL695r+DDaabP47rVB6+47Heo60mk3moYx0VfyVFevZWb66vo/UNtV9tYifI4gOZElPGEoNfe2bWRJb68oul/4DznvUGzVnBQRQ== 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=9JN94xcnMnFyY9Wmps6/J8sEhzX+tsiFqWc9Be3J1X0=; b=qqoKaBJp3F2eOT5hrGGaNg6zNzXCZE+xCdfImJEjs3sWM9RJQxXnWU+5R+ZZ949ol7RwJCeyDdW7sPmjUouIX1z6G1V+mRE1jasNWYcTay1frxuAbfMY0ccfLT4kuJ2LuksyyXwzglcBQ5u3BUEoScA53vyk9bkDFeaFlLgtwmI= Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (2603:10a6:20b:cf::10) by AM6PR08MB4087.eurprd08.prod.outlook.com (2603:10a6:20b:ac::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Mon, 13 Jul 2020 09:37:40 +0000 Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56%3]) with mapi id 15.20.3174.025; Mon, 13 Jul 2020 09:37:40 +0000 From: Brendan Moran To: "secdispatch@ietf.org" CC: suit Thread-Topic: [Secdispatch] Call for agenda items Secdispatch IETF108 Thread-Index: AQHWWPlACqwgVPV7rESd8DxbMRHyvA== Date: Mon, 13 Jul 2020 09:37:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.20.19.206] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 0a5a3bef-399f-4f49-1188-08d8271066f5 x-ms-traffictypediagnostic: AM6PR08MB4087:|AM6PR08MB2967: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: qRQQNDBwb3bExJD9SQyahkC6Ot+r8OROtIgg0w20S6PxOz2rk02tRKneNJP2C3WHRvVCLEpe9I5xNuOtYP27JFzGMYnjt2BGkb7Ce++W3/LcQGhs7GQrqlK4pMyDB6B/uw3H4WMQCzv6V99r03o2qB6ZGnFDMS30HIhBXTY60EXgVxAylvFirM+NAXcDHuHYmI7GSwKxIFOtTIFOtNfVvlmI8F4suy/oYqHypu9YBz7G4RXuCwEqIr/Q8UhhxrtSrN7CPtIgiFi5nSI4PXAoc58Kuwt8jdUwAMYLGugtmGSDXzR9419S0Acf1o/EmayNoTeVUZJ7XkRECyO71QQKYCN2ceTMqvdKV8UnhREPmQNHk2m0O/qrwGRkSZSlRsPTKH9IMEKSRiCLNa30ggiNRg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4738.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(346002)(136003)(366004)(39860400002)(478600001)(6916009)(83380400001)(26005)(71200400001)(5660300002)(8676002)(33656002)(76116006)(66556008)(6512007)(6486002)(316002)(8936002)(86362001)(6506007)(66446008)(66946007)(91956017)(64756008)(66476007)(2906002)(2616005)(450100002)(36756003)(4326008)(966005)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: DPAVDsEtbztFwl2QjlGMhgmbTq24db5oUbqnzg98ACcFcdwvMgrB3TVQQOzf+i79iFsGDEpUQ1fgF8JxWjA8I36De4CFnz9OevJK6WfMvQHSrTag4ahLKX4LlM9LAZnhmWmbk+NuebMbcjedrvjgSKij0nDiUG+Hk0BzE0W1H2EtLEvqNN5IxHWS3ZEgxQP0uZX94Flm9sS2VhTPjKTNC76DlFOaqvTcADLeDTHGiOOS2ezMUOTCWKAzJzv3JcRoAx/2BgUBEwb26DO2JK0BzNDRzrsn+/w3kZYQd1FarMQmPuAealmMo3sveMOCkSdP+MgE1ND3BsFEqwqnu0rkm74jxUfNfwAAzvtVRzYwLvrjd0/PsvBMVlcNFBb5w/LOnA6211wo09xwVcFvLw3pSAZ6Z3AxxwUhO14dTMafx21a1HScjylW9sNAtAZT51g934SfdQmoSTEIaF1oUN9kmvxhBT8e7jBGFJ8p02bhSPs= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <5799DD415A9D0C46A5C3AE23249A1630@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4087 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT035.eop-EUR03.prod.protection.outlook.com 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; SFTY:; SFS:(4636009)(136003)(376002)(39860400002)(346002)(396003)(46966005)(8676002)(70206006)(70586007)(336012)(356005)(5660300002)(86362001)(8936002)(83380400001)(2616005)(82310400002)(81166007)(966005)(26005)(186003)(6506007)(478600001)(6916009)(316002)(6486002)(36756003)(33656002)(2906002)(450100002)(47076004)(4326008)(6512007)(82740400003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: c59699a1-5caf-47bf-f048-08d8271062e7 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2Inz0YWEcggg/xZfs+iUG+MRNAUp1vPUmCSfr7PKPjUmSZOAgNjMgA5YzHjrNpjvH6w8XvfKX2Sk+fKS7COFX6HMCu3VkTPaCIO4gjmOSnhm25zXYiybbmgMPJeSHRhn5RqWgyE86skR8agmWSClKPtktoNscBUYrGEfk2F4JMLguc6DDZVkrHsjtal/w10z7JawnPSACvtNefznGO6lDDFENy/ZtIrZRGC3JSGQDeO3Oe/sr10cgK+jmpBPlYPIe0T4stBbnb5QmiBSZP4w0UXs0g++ifVnP/P04uDFcmwF/8thzWvO3VFOeuCSd66YH3R0pJiuSBktjDF728xv38rWd0NwI1hZxKXPAOoMgnqAm3/QNh3T3hFUmozvzGDrnKFgansShUacxwzqofUPu1Ex4R8q/hZPD7QT6morwvc0u9Gl6bFd5YPBsN8xZyULgtgMZrIcH6vMXZ2FDrus7Gpmp5bAy91gd34IKPBt4FU= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jul 2020 09:37:47.3132 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0a5a3bef-399f-4f49-1188-08d8271066f5 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: DB5EUR03FT035.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB2967 Archived-At: Subject: Re: [Secdispatch] Call for agenda items Secdispatch IETF108 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, 13 Jul 2020 09:37:52 -0000 I would like to address draft-moran-suit-mud-00 in Secdispatch at IETF108. Draft location: https://datatracker.ietf.org/doc/draft-moran-suit-mud/ Prior discussion: https://mailarchive.ietf.org/arch/msg/suit/z0pU6ERSH1sapk= 15UM0fAGeoEvY/ Discussion of other work in the area: https://datatracker.ietf.org/doc/html= /draft-richardson-opsawg-mud-acceptable-urls-00 This draft was raised with suit, since it would involve an extension to dra= ft-ietf-suit-manifest, however the suit chairs suggested that it should go = to Secdispatch before being sent to suit. This draft would be pursued by me and Hannes Tschofenig, but there may be o= ther authors who wish to contribute as well. I would like to see this draft sent to a working group for consideration fo= r adoption. Discussion should be reasonably short. I expect to give a 2-3 minute briefi= ng on the draft. Best Regards, Brendan 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 21 11:55:53 2020 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 C55043A07C2; Tue, 21 Jul 2020 11:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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 EnNJFwvc4HXa; Tue, 21 Jul 2020 11:55:50 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40047.outbound.protection.outlook.com [40.107.4.47]) (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 CEAFA3A07BD; Tue, 21 Jul 2020 11:55:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VYnXnJmVQFIvE2TgrYVNnNf52m9nOms6F2igefeba/WP4sWOYR5+S341FIqzoGEAToJlS17hkL0ovUllPbmwMev5eWhSaYRFe/+XsVqesQ6Fugt5jnbhRn3Uc8mC/qRMFPKUykMqZESwoKrrE+FQAIxMd66vK/SauUWg7otECxyPaOowXxNJIft7QNPMRtPRIFsxzGPKSqYGiB02+2M5WksornBNuqzskEGzeqHxaQEF8OVj7sR9+wm/jfUGH6/Lx4Djz6M4+SvQjCiJ+WgmScKzy7MkR3g91rYPtdaJbrHGBwhGEbRUU8MNPzZ8pXAtlcXEQGswHo8x7XGk5V696Q== 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=aHuor/JlMbCGVrvGs12jVRVECp3NkDis1HvtwFjKLrk=; b=keA+H0nBhYJQBJMixy4vcNtwl6/FmXXfWP/+D83XaXFSPn4YOMCYBC6k/e/ZTpFQKCKmHeJde3C1YMfcjROWyDTGrdESUuxyFtX/r+SNH9SWOkNsSMRdW136azZeX+pBjZAgOVqLzqNgp6MX/7+t8FOaowilIrKJDHLwhpIIN0L4rU1XbGwgSp0lTygBxWZX4vrPSwKiHtArz5yx/HYnV0dH1cTi2iOdBluFOPzueJUcrXRkjnqXl2+5OmEXbnq+2ZMvxX3M8Xzl7dDNLAFfj6Pk0RFG4vgO6Jb3akQEqcW/pw9kMmIT1wn6fvym7oRH+hjc8zXX5o1MN50xB9Fjrw== 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=aHuor/JlMbCGVrvGs12jVRVECp3NkDis1HvtwFjKLrk=; b=qpFU4E6/eZmPXNixJiZX/t8DiJtHpZ+P/oH74wOgyRbchp3CmbVaJ3Ch+8Jml5I4s1JEubmYCVRRZ5sDKGnOC0lFOzOrcRMsYFjPIyvkykfUbwvlMelODtOV4j4Ju8cYp2V40bqCkrRhZYbv/WaXGamYhULYgnNTA4KK3v+LXEI= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0701MB2441.eurprd07.prod.outlook.com (2603:10a6:3:73::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.14; Tue, 21 Jul 2020 18:55:41 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3216.015; Tue, 21 Jul 2020 18:55:40 +0000 From: Francesca Palombini To: "secdispatch@ietf.org" CC: "secdispatch-chairs@ietf.org" , "draft-schanzen-gns@ietf.org" , "draft-richardson-secdispatch-idevid-considerations@ietf.org" , "draft-moran-suit-mud@ietf.org" Thread-Topic: IETF 108 Thread-Index: AQHWX5CHz8v6FCHmCE66Kkw0ke3pSQ== Date: Tue, 21 Jul 2020 18:55:40 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.12.182.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d01ca088-b2a5-4da4-19ac-08d82da7a9fb x-ms-traffictypediagnostic: HE1PR0701MB2441: 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: 09FA1lSWqpJvxKtt5hDeC6aFXIVT2BcjiZhgUTPleFEAvmwpOBqTKvCMNybSx0qjf9NjLaGUzHMks+YurJC4bpYhSUNg3nDHfSusWqeaAHLHD6UNtdh3CgJ9FLS+EFV5cF6Mo4H7jgaMajrEXU1OBGY1Sv6QFPcW/OZkuhWwAdhQn2Q+eQDZdf7nW6RJU+JtuVUDapmiXT5ybPEkaKcPTbYmkw4rhIIbFl8+qCZ4AAcUqWLNjRMySBH8v0dJ33RyOgVRr3gO+TrHh4R2wGCYP9v8Te00RfFxwRXBmJ+wVnsaFn2M0LvLTcHX+ImDu1RaDZHeC5E6kYiIOrJLDfsxr6dX4zbsoiA3/+YNDfDWu8Y3+hHzK3uTXAyHj3UQKO61wtKLdoFzd4n4g89lk0kwPw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(136003)(366004)(346002)(376002)(36756003)(6486002)(66556008)(66946007)(64756008)(66446008)(66476007)(966005)(44832011)(478600001)(76116006)(91956017)(71200400001)(5660300002)(2616005)(6916009)(4326008)(54906003)(6512007)(316002)(2906002)(33656002)(450100002)(7116003)(8936002)(4744005)(83380400001)(6506007)(26005)(8676002)(86362001)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: R980W/yoeUzxijHse/WDAfSdL8xz8eGxE1sG8VvAuNbz74MU9tsTMabUZUmkUzvKWAEJZo8+INVsqjVMV8Z3nT2mQH4KmeBd2spo8nMcQMKhj+eqS4ojtCqUnldnh3KOwFgMRXbZIUKPljKGlR/jmj6rQpQl6gKlTTdlpUQtv5me6sPPx2TwhANovu74SaRfVkofxRBTvAsTVGHvDqJ26x3IhbkMvzQKXObhod25F+hZBdubRzl1CmrPCZXXvdUafdfTbeNdQ40+D5s7vC9B4U1vEMnzChLMZZz9WXp0OXZD4zY31FPnQg36fK/U0xThddKVDwkQBTi680pvjHOkZ9Tio2ViR12TDxHDCe1m+rkLO1eFButmESlmkWVuDtN2Sak3rSxbsOijlbnugQa01KDm0qmG353nsPQ4O6HFHFM0L37zDZsBIk3x77TZxCosc28oyWM/SmqBAcdgEVk3JE2ry/em6Z6cySBPrcBtGEg= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <650C4BFCD58565448F89114D42E084B1@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: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d01ca088-b2a5-4da4-19ac-08d82da7a9fb X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2020 18:55:40.3801 (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: t9Bt8XOcDc7pY/xAr4C4enfTnKQ8LeY/w0lAJXQdcQGhvQQJxtkVX7wLoyTmE9xFT6QmCDXkffqC1zAFrKu9AV2p4OKGHsvJtX2YQ9vT6ZrqgeEcQSNTLLZp90+lLPdM X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2441 Archived-At: Subject: [Secdispatch] IETF 108 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, 21 Jul 2020 18:55:52 -0000 SGksDQoNCkFuIGFnZW5kYSBmb3IgdGhlIGNvbWluZyBtZWV0aW5nIGhhcyBiZWVuIHBvc3RlZDog aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMTA4L2FnZW5kYS9hZ2VuZGEtMTA4LXNl Y2Rpc3BhdGNoLTAxLmh0bWwgIFBsZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93IGlmIHlvdSBoYXZl IGFueSBjb21tZW50Lg0KDQpXZSBhcmUgbG9va2luZyBmb3IgbWludXRlIHRha2VycyBhbmQgamFi YmVyIHNjcmliZS4gUGxlYXNlIGNvbnNpZGVyIHZvbHVudGVlcmluZyBpZiB5b3UgYXJlIHBsYW5u aW5nIHRvIGpvaW4gdGhlIHNlc3Npb24uDQoNClByZXNlbnRlcnM6IHBsZWFzZSBzZW5kIHlvdXIg c2xpZGVzIGFzIGVhcmx5IGFzIHBvc3NpYmxlIGFuZCBubyBsYXRlciB0aGFuIFN1bmRheSAyNnRo IG9mIEp1bHkgRU9ELiBGb3IgbW9yZSBndWlkZWxpbmVzIG9uIHdoYXQgdG8gaW5jbHVkZSBhbmQg d2hhdCB0byBleHBlY3QgZnJvbSB0aGUgc2Vzc2lvbiwgc2VlIHRoZSB3aWtpOiBodHRwczovL3Ry YWMuaWV0Zi5vcmcvdHJhYy9zZWNkaXNwYXRjaC93aWtpIC4NCg0KVGFsayB0byB5b3UgYWxsIHNv b24hDQpGcmFuY2VzY2ENCg0K From nobody Tue Jul 21 14:57:00 2020 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 EE7913A0ADC; Tue, 21 Jul 2020 14:56:58 -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 ApJzpeIj3NM6; Tue, 21 Jul 2020 14:56:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378A33A0ADA; Tue, 21 Jul 2020 14:56:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2DBC038A24; Tue, 21 Jul 2020 17:36:30 -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 mqRMz5836WjF; Tue, 21 Jul 2020 17:36:29 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E46C38A23; Tue, 21 Jul 2020 17:36:29 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CA4683F; Tue, 21 Jul 2020 17:56:54 -0400 (EDT) From: Michael Richardson To: "secdispatch\@ietf.org" , "draft-schanzen-gns\@ietf.org" 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: [Secdispatch] GNU Name System 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, 21 Jul 2020 21:56:59 -0000 --=-=-= Content-Type: text/plain Hi, I read through draft-schanzen-gns just now. First, I generally like the idea. I particularly like the reference to pet names and SDSI. The SDSI work *not* been paid attention to enough, so I'm glad that this document goes with it. I'm perfectly fine with having to say "ICANN's ietf.org" as a petname for a DNS rooted in ICANN's DNSSEC root. Some may find that this may be a stepping stone towards multiple roots, but I see it differently, because it enable's stuff like "Michael's Neighbour's Work-Server" {I didn't get to a part where the presentation of this was discussed, and how I'd type this into a Location box} The document is a bit rough, and could definitely benefit from more implementer feedback, but that's of course, why you are here :-) There are probably some algorithm agility issues, but I suspect that they aren't worse that for ICANN DNSSEC, because the decision to change algorithm types can be a partially local decision. DHT just sort of pops up in the section 3 description. And then it isn't until section 6 that we learn that there is a DHT. I thought I'd learn more in section 8, but I didn't. And then section 9.4 says it's out of scope? I didn't quite figure out how it was used at all actually. Since all names are local... wouldn't I always know how to find my relationships? I see that GNUnet is being funded by nlnet and NGI, and this is rather good. I don't see a clear connection to FSF, and I wonder if they will be happy about the naming. I.e. do you have RMS' blessing here? Better to get the name right early. If this work is worth doing at the IETF, it probably needs it's own WG. There are some RGs that deal with far more distributed networking than the IETF has been interested in yet, so maybe that's a route. How would it get deploy as other than a niche effort of geeks? Do you think that it will be possible to build a GNS Service for Android, or for iOS? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8XZKYACgkQgItw+93Q 3WWeFggAoAgXJiGZFSbPDCZK89STEDXAcwTlsQtIjyJge44oVFOhhpvuNNH42AoV sQR1h0riHweXzs66lO0tUIlL7W/cALMH3BsBXVr+9jKhuUD+DgOyjupTi0Z6CzAM h8e3/u+wHx6/Z/29+gGot5xwi8XRUQrCcIFN8/Ty02+V8XewtsXjXo3HXWIIyGXk MgOkZocVhni/2/7GTtGgLLusxwqyARIs1l5FlebEdGzkll+8kbbSEHDn5rim2irl 7bavvKUoHeQA30Bl/HhZbpMwYwcOuUcCB7F3aMIJS5TYjTEAXKoAWwUfN4YFkBDz cxubuU2Ek8SFFNv2Iun7jzJFQgQB3g== =srYb -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 21 15:07:19 2020 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 135D43A0AFE; Tue, 21 Jul 2020 15:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] 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 RJsHWjTCY2v7; Tue, 21 Jul 2020 15:07:16 -0700 (PDT) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) (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 43D173A0AE9; Tue, 21 Jul 2020 15:07:15 -0700 (PDT) Received: from fencepost.gnu.org ([2001:470:142:3::e]:36979) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jy0Po-0004UG-Kj; Tue, 21 Jul 2020 18:07:12 -0400 Received: from [2001:1620:fe9:0:7285:c2ff:fe62:b4c9] (port=48230) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1jy0Ph-0001VQ-KL; Tue, 21 Jul 2020 18:07:12 -0400 To: Michael Richardson , "secdispatch@ietf.org" , "draft-schanzen-gns@ietf.org" References: <31625.1595368614@localhost> From: Christian Grothoff Autocrypt: addr=grothoff@gnunet.org; prefer-encrypt=mutual; keydata= mQINBFSG/g0BEADfUtc2WA8+OWiNVuNuaU5CIFB/6Netaem0tXAc5VF8c/Dr/BbteSG4ZAWg CGioO/sqQ08XbYSdot1/zybFqAaD2Tlz99+GFLDYSMSDv6SkaAww0cGbobjkAO3h1ojeR8gw j2+V2DuM9VLsmB0ITH3zXlLg1wbDUeIpOtk12DWqOTFN0v6xhV3JVdFsMmiM21iyo14FIxZm RTJulrwQFi/LcrUR7kDSjuwv3GzmVy6KSArri6fSZec4os6WJM69+N3kV3SwoWxjikfUodaF +kOMXRyfEDX2ebyvveIvMl2BxNu7JUnFY0AHXnxeNbfkpLCuFnH4cVvK14I+hHOa/JTnF77f 7sWb+E0588YLL7geWucJfw94OzM1z4l/BLSyYiY3PJWRUHwkY7FV3cQGgTfrvbX3afa9Vi2b KHbgsgnOpe55FFJTRhZlGJMrgeNsoRKeivFaSa3HLhkV56VG268IM7iao+soVfeWKTOOSQGV eG6VrY7MUjhNfBbYfuSOW9CdF3p3XbI8DF68id0OQRUIihS42+kSGCZVY31Mx8+bZj+7+Qhs hZrARdrdmDg5IvJykEpn7aKpfyhf1sCfu/gwrpZ90IcaYoeafk6qWcf8JL+5VYHewWjfZ7pF tlurt+hlrdNbqDQ9oHtIsevbgsPlh40BZ0kv2vLK5b+hQ5gd3QARAQABtChDaHJpc3RpYW4g R3JvdGhvZmYgPGdyb3Rob2ZmQGdudW5ldC5vcmc+iQI4BBMBAgAiBQJUhwfWAhsDBgsJCAcD AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCTnmvh4p/DzLo3EADDO4FO9ZSwG2dWMVqzSflJF2G1 SdNS0AnzP1B7YBv6WNqjtwDhYbo4txZiz+R3e0RSguhcURHCa1EVsTErBU9zHV9+p0mGJ310 rhst3Q54pXdQSVAU8wteKjghRoX+Tn0dldVfowRdYNHYb+g1ReuDc6V7yZV3/T3dQMOg4MTj ZbZGAF5qaYTmB8Tofuv5xtsqoXkj0h71qEMEbBbkekjZwYW35awloFfIEXFAM6d6ZBHDQ+TJ oTZN+RGAvSzirGTKhhS91vDsJ94DaoPiWtqaQm55cBxYZY/UMDSfGlsvkZDqGeT+aL/uBnvL O3KinYPCtYRbVzaEtaJ1r+CsZknB9eDuG7kuzVHMI8HkyqD/CaTKc5qk5a28vPvcbkupZzsr qJDu/e3CD16cJStwhLM79+CVp/ihDUS8yGiBS76ROfwOqI6niWw+oti7oGieb3QIxnRqYxDU b6UOe0mvGcrwxdrin1StvcW9HVghrvN4Mx+Ec1Us7SOcrybdL6ILgu9zMJTFJemPiuL6AGZL mzJ3m3uTu10WkqmG6Rj4fU5t7vBzNtFdj3E637jSMH2Fgkz3Athrad4+9tMBlvJXpzNJvYZ2 EzAIXLNYOCI5Cjhz5DguSIBJYc1EzTgwCPQv4w0Qg5aik9De24DHaghsdXrI3L1k78m88kjd vBzu3fmEzbkCDQRUhv4NARAAoi0SvMUnd5XSZVSmbwfge2p9KeGVVcaz99fgrUTgCwfovVd1 MEXh8FCtxja4xZiuwSGUARuPAXpzhcK1L9vai25GV+y4SALp3wg1/GrsHtEsm+wm7AeIq0ut XnjfnUzfliIIKwt0aGW/zGp/8rHNKh7JVUo0mPSMQfe+6tE2XOnuGDHj1ZyZalmBjVLJYMws I0tfAzU1fa0MOSnhvyP5TFFj6PWKSajEOsFuIR/zceZFtJbN24lbXYwohBDBY2Ajb0y8uYBi /h350UY2mwjKHYM3mxJD3AogWIBz5HD+ueWGUTBpKwLYmN7zVxDMdL7FqGonSw9NV1XxJ3IN 1DYPPdFKStRIUiSMzyj/pp6410ms+N1MtPXDIDdcOcmNHqcnkWqBYHXGi+sYyFpe+825N75d otpEipCnIcTCBjn3RdqFOzT4+airtL7eOkzmooqtPwvNO+4Uza8+W1PLibXqXWqD0uyi1Wn2 9asF+uOEfNA4TpTXT6Df5B1X88eoHccCpPUhiNqs7dX1ye78m9oicD9IoXj3PZ0le2tHXuFc lXjuffpOW6Wt+rbqMrFp4LA4H4UXafai9B5F1JMp+xdK+V0YUT0aQSZwdHyvNsGReRnuuZKH be0xokpVM+ndra2EpsV0C3csoDOWyu7yjUyFeTfAlYBb8rn8WuLnT8xzSJEAEQEAAYkCHwQY AQIACQUCVIb+DQIbDAAKCRCTnmvh4p/DzKGQD/wLhO70IEI06MqaP41im4X7suk4zGOAcBXA csZONq450CA/WHvoMKFoCPHfoC4e1jsoifG8+emfTQhWKwW3a5G/H90a8lY8pH9tqkVUPds5 m6fbWf16xkWUQpH8QQyLwhBIF8onclrDWAHPflpnWp+wso1vxN+WRh5vL1k8dpQLUkOBmE1o vl79/z1zzOYDkOWdQ1crU2EbOXalCmOASmiFhWiYk2aosBxbzGX0JKX5NyIUzz56i9vDYqjk DFYcMMx1Z9YXsvTjglMwnIfwPmvBBgQlwqg+LOts7XF0ZoBZ3NBLpIES0wheVjXtG/T7kZey 7XABVbxK2B4mIRFIvXnHbTEGzSyY7hLCshyCMQTDCoHDOKiNZmteqhHU4zXVgyhrxkYG9iID j9yb6PCjaFwgp42rz0lLqTgmpDEIrz1MaCglhTB68wTsHYx3SH+ClNGmgWTa8dS+l/s0hgE+ WknVGn6ShMkdyYLn3QxTRhZSmRv2hG7AYSemtLxi4lLoJ3kDHLMYAponhzxLYOtc8IyNrrRU 4Tj4keG2ssHSkC9kDIMqzX53ObGkVWN6Rvu+pmZ9iumrNqI/4PyrPi3mOE7ooIkh1L/MEu2c LNWaTG5QmOK0VtYN+3G2qzcjKEpQPIDgRdZ6i7fO6jgb0iy1UJUbAoLQgUTaX99KUKeyCuiG UA== Message-ID: Date: Wed, 22 Jul 2020 00:06:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <31625.1595368614@localhost> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="koCSjSp2s8wttWDcpBWdXAG2usuo9ZMsj" Archived-At: Subject: Re: [Secdispatch] GNU Name System 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, 21 Jul 2020 22:07:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --koCSjSp2s8wttWDcpBWdXAG2usuo9ZMsj Content-Type: multipart/mixed; boundary="BGqE5cQl9SB0InXDyFDo6qS8QG9Kk90L9"; protected-headers="v1" From: Christian Grothoff To: Michael Richardson , "secdispatch@ietf.org" , "draft-schanzen-gns@ietf.org" Message-ID: Subject: Re: GNU Name System References: <31625.1595368614@localhost> In-Reply-To: <31625.1595368614@localhost> --BGqE5cQl9SB0InXDyFDo6qS8QG9Kk90L9 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi! First of all, thanks for reading the draft! On 7/21/20 11:56 PM, Michael Richardson wrote: > The document is a bit rough, and could definitely benefit from more > implementer feedback, but that's of course, why you are here :-) Indeed. > There are probably some algorithm agility issues, but I suspect that th= ey > aren't worse that for ICANN DNSSEC, because the decision to change algo= rithm > types can be a partially local decision. This is actually an area where we already had some feedback via other channels and are planning on 1) fixing some agility issues, and 2) improving the explanation and write-up to make it easier to see how agility can be achieved *and* actually give a 2nd instantiation. Alas, this will require significant changes to the draft and implementation(s). > DHT just sort of pops up in the section 3 description. > And then it isn't until section 6 that we learn that there is a DHT. Yes, we were already told to improve this part of the write-up. We'll try, specific suggestions welcome. > I thought I'd learn more in section 8, but I didn't. > And then section 9.4 says it's out of scope? The exact specification, yes. It's way too much for one draft to include it IMO -- not to mention that GNS can be instantiated over virtually any DHT. > I didn't quite figure out how it was used at all actually. > Since all names are local... wouldn't I always know how to find my > relationships? Suppose you have alice.bob.dave.carol. You must have 'carol' locally, but you would (typically) lookup 'dave' in carol's namespace in the DHT already. Basically, the root is local, but the rest is resolved via the D= HT. > I see that GNUnet is being funded by nlnet and NGI, and this is rather = good. > I don't see a clear connection to FSF, and I wonder if they will be hap= py > about the naming. I.e. do you have RMS' blessing here? > Better to get the name right early. We do indeed have RMS's blessing. > If this work is worth doing at the IETF, it probably needs it's own WG.= > There are some RGs that deal with far more distributed networking than = the > IETF has been interested in yet, so maybe that's a route. Well, we hope to find out what the best home at IETF would be. > How would it get deploy as other than a niche effort of geeks? Our plan is to initially integrate it with applications that are underserved by DNS, like decentralized communication platforms / social networking applications, identity management (see reclaim:ID) and IoT applications. > Do you think that it will be possible to build a GNS Service for Androi= d, or > for iOS? For Google and Apple, certainly ;-). And Apps could certainly link in a GNS stack for name resolution bypassing the OS resolver entirely if desir= ed. --BGqE5cQl9SB0InXDyFDo6qS8QG9Kk90L9-- --koCSjSp2s8wttWDcpBWdXAG2usuo9ZMsj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE2EI7yzJseQcDOSnHk55r4eKfw8wFAl8XZwEACgkQk55r4eKf w8xOXA/8DOwzWkzLkcuxjUw88Qvowamw/LUFLewYwZCTCmR/HeUhDtsfxgUi7aXi vjOvQsaIU5XnOhsfMdF2ZhTMcrrvbyPlZzUqPmN06QIPIAnRu+i15Tk9F9tyMNfw oe3FlB2zxYYLG+kiNCS936mMErmCaxwzFoHqwZ8RJ0MiLxEWu8g7nnX8lTJ0/3z+ AxvZqOMy/Osm4QY+6N82GeX0D9CnP9MJt3TzG9IMNE9Z0SsiT/DJrnAwjLf0yk6t J09H2tATn79FvdEonqn1qnEe1O3hL6TTgyB4VTEAHvNl62RTfeAHHClrFWo7/c3u 0qrwq0SVcpoGZroaIfL52k3sh7xwamrzBIMcIGiIM+sFCzkun9MiQv8CRjFVl5Ow omk5W9hfpknBZ1sPCCOpfFg0Zr0wZyNOQg7wWnNq6ZWNX/UMnnH4X1kcD0N74phT Ho3Ku1od92CVrHkngtRK5L+WT/2t9lg/A9ytkKujX0tFUP4qfTG0jEzl9wYK8qsg bmeRTVMQYvBjJu0XOc84p7lBv7TRT7SVhBD/aajS6ZJ4pCc9/Af4GirUGFSxMK3w 5qfnpHBtskR5VFdc9eka051KIFpXMdJ36qYdk8BWAXf1VsnDyGCI3qzp4C4na33M 0vJ3Wq10ALW7jLAFEaZI+cM1RVHTuipNt2VF0kzMJh8kgDbdeg0= =+9VQ -----END PGP SIGNATURE----- --koCSjSp2s8wttWDcpBWdXAG2usuo9ZMsj-- From nobody Tue Jul 21 16:18:32 2020 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 F006B3A07C3; Tue, 21 Jul 2020 16:18:30 -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 yiepH0MgHb65; Tue, 21 Jul 2020 16:18:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAE33A07C2; Tue, 21 Jul 2020 16:18:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4790438A1F; Tue, 21 Jul 2020 18:58:01 -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 k0uEc6jR9jLN; Tue, 21 Jul 2020 18:58:00 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C66B3899F; Tue, 21 Jul 2020 18:57:59 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 276EEA8; Tue, 21 Jul 2020 19:18:25 -0400 (EDT) From: Michael Richardson To: "Brockhaus\, Hendrik" , "secdispatch\@ietf.org" , "spasm\@ietf.org" , Tomas Gustavsson In-Reply-To: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> 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] [lamps] IDevID considerations document to secdispatch 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, 21 Jul 2020 23:18:31 -0000 --=-=-= Content-Type: text/plain Brockhaus, Hendrik wrote: >> In particular, the self-generated (_invivo_) key suffers because the device >> needs to do a write/read operation from the infrastructure. That involves the >> highest possible latency for interaction with the CA and therefore would slow >> the assembly line the most. > We make use of the key-pair generated on the fly on the device and do > not see major delay on the manufacturing line due to CA communication. I hear this complaint as heresay, and I have yet to hear it directly from someone who would know. They always seem two or three layers of indirection away. I would be very happy to kill this issue as a non-issue. I'm aware of a major VoIP phone supplier whose CA is on a different continent, and it's not an issue. > Finally it is a question of how you arrange your manufacturing > procedures. If you experience delay due to waiting for the certificate > delivery, you can do other meaningful things in the meantime. yes, that's certainly true, but it also take some interactions among different layers. >> The invitro and shared-secret methods allows the infrastructure to generate a >> few keys in advance (and get them signed, assigning DN-serialNumber at the >> same time), and then injecting that key via JTAG at the same time as the >> firmware. This overlaps the CA interaction with other steps. > Finally this method puts higher security burden on the manufacturing > infrastructure to securely handle the pre-generated key pairs. This is > why I do not like it, but sometimes it is needed. The -02 version of the document cites: "Factoring RSA keys from certified smart cards: Coppersmith in the wild", September 2013, . for a story of not-quite-random-enough issues! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8Xd8AACgkQgItw+93Q 3WUMGQf+In/nhpmLhdutkBOle7Mx+ANnBxCYsWYlYRBNSsszvOpoMZpev77pLgAY pep2UHka1yRd4+9EJyN9ijp1q+NFT+/jAbvvH7jFGC7cg9W++yEO+LEo9kEqVo86 +fBxeekQ6ovkjRIKKxgApcBfUp3Uo2P96+5mD3oHTtxvbSUOfGRnafTyWO+T+hZu kFZMFY9GVKfIaq+A7k2VSVkxncLhUztnOSP3jbg3CDD49eZ5eVgQjaELx5Jd4M9L 3Or2gN5m3drgwhejlP2dRSoEsHsjVDRr2iWt8kH4i7YkUVevKOzulb98coRdZRcL dMDxTFuSBfCrWTyWlr6CtAUWzZXpbg== =o9+p -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 21 16:31:47 2020 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 BDD2F3A0805; Tue, 21 Jul 2020 16:31:45 -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 eQ4iYh3n1pnc; Tue, 21 Jul 2020 16:31:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A2D3A0802; Tue, 21 Jul 2020 16:31:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C691E38A26; Tue, 21 Jul 2020 19:11:16 -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 bD7QivpLNRCA; Tue, 21 Jul 2020 19:11:15 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5BF4F38A20; Tue, 21 Jul 2020 19:11:15 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E9F63A8; Tue, 21 Jul 2020 19:31:40 -0400 (EDT) From: Michael Richardson To: Tomas Gustavsson , secdispatch@ietf.org, spasm@ietf.org In-Reply-To: <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> 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] [lamps] IDevID considerations document to secdispatch 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, 21 Jul 2020 23:31:46 -0000 --=-=-= Content-Type: text/plain Tomas Gustavsson wrote: > On 2020-06-28 22:51, Michael Richardson wrote: >> >> Thank you again for reviewing the document! >> >> I know that primekey is involved in creating Birth Certificates for >> many product lines. (Your website's term, not mine, but a good >> one) > It wasn't my (ours) terminology unfortunately :-). We found it > elsewhere. I don't remember where "birth" came from. 3GPP 33.310 have > the same concept, but calling Vendor certificate. I think birth > certificate is a little better, as it's more generic than specifying a > vendor relationship. I do like the birth concept, and I am thinking if changing the document name to include it would make sense. Perhaps someone with expertise in attachment parenting can provide some interesting words about how trust anchors are installed. >> I wonder if you can comment on which of the three methods you >> support? Do you have any suggestions on names for the three >> methods? To me, just getting three good names is 90% of the value >> of this document. > We support: > 2.1.1. On-device private key generation > Standard CSR-submitted-to-CA process I have named this: a) _device-generated_ / _mechanically-transfered_ b) _device-generated_ / _network-transfered_ I know that you are blown away by my imagination here. Perhaps someone can feed this through a mechanical translator, run it English->German->Mandarin->Swahili->English, and see what comes back. I think that it's useful for the entity that needs to examine the risk for the process to distinguish the two transfer methods. > 2.1.2. Off-device private key generation > Typically CA-generates-keystore process. Some protocols, i.e. > CMP/RFC4210 have standard support for encrypting the private key sent > back to the client I have named this: a) _factory-generated_ / _mechanically-transfered_ Like a serial console connection, or a JTAG flash writer. for b) _factory-generated_/ _network-transfered_ yes, but what key would you use? :-) The device has nothing.... So I think that it really has to always be used in the factory with a physically secure network connection. > 2.1.3. Key setup based on 256-bit secret seed > We haven't seen this. Albeit, it's not so much related to the PKI > part, so it can still be supported/used if the certificate issuance is > done using a CSR process to the CA. I have named this: device/factory-co-generated I had not seen this either. Laurence Lundblade, formerly of Qualcomm says that it's a thing. While the interface to the CA could still be via CSR, the CSR is generated by the OEM, possibly not in the factory at all. The private key can be generated, used to sign a CSR and create a certificate, and then destroyed. This can occur completely asynchronously to the manufacturing process. It can occur in advance, in which case the certificate can be loaded via a (pipelined) write operation to the device, which will generate the same private key. It can also occur after the device has been built and provisioned. The device might never actually have it's certificate internally: the onboarding infrastructure could retrieve it from the OEM when the device first shows up. Or the device could retrieve it when it first boots up as part of the QA process. But, ultimately, what's happening is that >> Thinking about "birth" concept, I am trying to think if this helps >> with terms. Invivo <- self-generated private key, with >> enrollment. Invitro <- private key generated in test-tub, deployed >> to device. > Good idea to have naming for these. I like the idea. I don't have any > immediate ideas. Are there any naming from TMP/SE vendors/standards > that can be re-used? (I'm not very familiar with those specs myself). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8XetwACgkQgItw+93Q 3WV2nwf/T/NQp6uh9YhFHpuirbdyOLBS1xCxYbswQZ3edO+QOUXEy0WWEZT4urK0 CVLSLdpNt1HKgFtNdnWXBhAFS9V8yksHzbnDK/ozj8BQ3xvP0ATtzrSM9PmkxSty 4L5LTbIUBlXZPC4mkiBiasS/2lN8rrfKHCB16CuX2NS7NMt/ro7MT+hkEiYeYoiT M+Wt69J4KYP9yfYjcNOjmFD42bY4rAuGEhEBBJEgArdu/Zjr1jt5GFT0zPcD7WNX o2QmfHVszLd7AUnWQTwe48Lz8NEhT50Vacm++9HdAODPDW3mCaKfzN9xPrvD7neT 2Ai4ge3ne4ZjMc49Rp86lBO5k/7sFQ== =Matd -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 21 22:22:59 2020 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 B9C3A3A0DDF; Tue, 21 Jul 2020 22:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=primekey.se header.b=5PxX9SNt; dkim=pass (1024-bit key) header.d=primekey.se header.b=5PxX9SNt 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 uHdkXO2okdmN; Tue, 21 Jul 2020 22:22:49 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770103A0DDD; Tue, 21 Jul 2020 22:22:47 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 3DFB16AA061E; Wed, 22 Jul 2020 07:22:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.se; s=mail; t=1595395345; bh=4xFd0v9RTqcGwEbPDd1flPzGzwpCi8HOVlkudM9kZZo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=5PxX9SNtF9efkf4IuPu+MJbL1dQ/O1Ec6DdxQve2dIFuIgxPm3KumDiQl62XlpKhM bu04QXU/tOS2XOrmzXMVu9SS7oAqrT2koKkX7DTNnx+9T7KhmG8RnFM1u/rz1KcrwN fFPVe4yb2QsxC/x0OJAHhBXK6ENlmeuhQridbc/Q= Received: from [192.168.1.113] (unknown [85.24.187.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 0D4936AA0618; Wed, 22 Jul 2020 07:22:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.se; s=mail; t=1595395345; bh=4xFd0v9RTqcGwEbPDd1flPzGzwpCi8HOVlkudM9kZZo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=5PxX9SNtF9efkf4IuPu+MJbL1dQ/O1Ec6DdxQve2dIFuIgxPm3KumDiQl62XlpKhM bu04QXU/tOS2XOrmzXMVu9SS7oAqrT2koKkX7DTNnx+9T7KhmG8RnFM1u/rz1KcrwN fFPVe4yb2QsxC/x0OJAHhBXK6ENlmeuhQridbc/Q= To: Michael Richardson , secdispatch@ietf.org, spasm@ietf.org References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> From: Tomas Gustavsson Autocrypt: addr=tomas@primekey.se; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> Date: Wed, 22 Jul 2020 07:22:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <22303.1595374300@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch 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, 22 Jul 2020 05:22:52 -0000 On 2020-07-22 01:31, Michael Richardson wrote: > > Tomas Gustavsson wrote: > > On 2020-06-28 22:51, Michael Richardson wrote: > >> > >> Thank you again for reviewing the document! > >> > >> I know that primekey is involved in creating Birth Certificates for > >> many product lines. (Your website's term, not mine, but a good > >> one) > > > It wasn't my (ours) terminology unfortunately :-). We found it > > elsewhere. I don't remember where "birth" came from. 3GPP 33.310 have > > the same concept, but calling Vendor certificate. I think birth > > certificate is a little better, as it's more generic than specifying a > > vendor relationship. > > I do like the birth concept, and I am thinking if changing the document name to > include it would make sense. > Perhaps someone with expertise in attachment parenting can provide some > interesting words about how trust anchors are installed. > > >> I wonder if you can comment on which of the three methods you > >> support? Do you have any suggestions on names for the three > >> methods? To me, just getting three good names is 90% of the value > >> of this document. > > > We support: > > 2.1.1. On-device private key generation > > Standard CSR-submitted-to-CA process > > I have named this: > a) _device-generated_ / _mechanically-transfered_ > b) _device-generated_ / _network-transfered_ > > I know that you are blown away by my imagination here. > Perhaps someone can feed this through a mechanical translator, run it > English->German->Mandarin->Swahili->English, and see what comes back. > > I think that it's useful for the entity that needs to examine the risk for > the process to distinguish the two transfer methods. > > > > 2.1.2. Off-device private key generation > > Typically CA-generates-keystore process. Some protocols, i.e. > > CMP/RFC4210 have standard support for encrypting the private key sent > > back to the client > > I have named this: > a) _factory-generated_ / _mechanically-transfered_ > Like a serial console connection, or a JTAG flash writer. > > for b) _factory-generated_/ _network-transfered_ > > yes, but what key would you use? :-) > The device has nothing.... Very good question, I thought the same. In the case I see, the device don't talk directly with the PKI. There can be a secure HW device in the factory interacting with production line on one side, and the CA on the other. It can talk something device specific, direct connect, with the device on the production line, and make the CMP calls to the PKI. The private key generated (by the CA) is then encrypted with the gateways public key (where the private key is kept in an HSM/TPM/SmartCard). Yes, the "gateway" becomes a point where the private key is decrypted and vulnerable for a short time, so it's not for every scenario. The CA can be off-site, not in the factory, i.e. central organization PKI. The the term _factory_generated_ can be a bit misleading. The CA can of course be in the factory as well, I just don't want to trigger a specific architecture image in the readers mind. > So I think that it really has to always be used in the factory with a > physically secure network connection. Physically secure on the production line itself, but can be internet between the gateway on the production line and the CA. > > > 2.1.3. Key setup based on 256-bit secret seed > > We haven't seen this. Albeit, it's not so much related to the PKI > > part, so it can still be supported/used if the certificate issuance is > > done using a CSR process to the CA. > > I have named this: device/factory-co-generated > > I had not seen this either. > Laurence Lundblade, formerly of Qualcomm says that it's a thing. > While the interface to the CA could still be via CSR, the CSR is generated > by the OEM, possibly not in the factory at all. > > The private key can be generated, used to sign a CSR and create a > certificate, and then destroyed. > > This can occur completely asynchronously to the manufacturing process. > > It can occur in advance, in which case the certificate can be loaded via a > (pipelined) write operation to the device, which will generate the same > private key. > > It can also occur after the device has been built and provisioned. > The device might never actually have it's certificate internally: the > onboarding infrastructure could retrieve it from the OEM when the device > first shows up. Or the device could retrieve it when it first boots up as > part of the QA process. > > But, ultimately, what's happening is that > > >> Thinking about "birth" concept, I am trying to think if this helps > >> with terms. Invivo <- self-generated private key, with > >> enrollment. Invitro <- private key generated in test-tub, deployed > >> to device. > > > Good idea to have naming for these. I like the idea. I don't have any > > immediate ideas. Are there any naming from TMP/SE vendors/standards > > that can be re-used? (I'm not very familiar with those specs myself). > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Wed Jul 22 01:15:01 2020 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 135773A0FB0; Wed, 22 Jul 2020 01:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=siemens.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 WlxnmTB8axRK; Wed, 22 Jul 2020 01:14:24 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70070.outbound.protection.outlook.com [40.107.7.70]) (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 4DFF83A0FAF; Wed, 22 Jul 2020 01:14:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WNLwrt4Wykme5oXH1prRcNs0vYOOjhIqde5U4lU6yyyd+bqPYnww0VdDCSMhAOmKXQMXGkiP4UTS4DYUvPGcY2YJOJpAzr9Jz0lplatFgGuuny15I/1ez0Fu8xxMWxnnMYD8YRpjPhsx42bhU6b+VmkCV+uKZSsutW2lSAbvq/dIkSGT2rn75kY/9Yk/PuuTPp0V0YW+1dcNdDeNOwDwcQjlh6orYCvxrpVVIEIa+OH/bAD02YnXmAa+9M8tt1Joc32VQ7OsFHwyLWF275RgMP+DyNhL7qs5q93YnvwEc0YpHYsUhnan+BEekZoym0g3zF5Vob3DnnXHTX98skwEUw== 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=SbdlfhpJYCYGsQQcuUTjQUQT+W12VkpY+HdlNyN70AI=; b=hCvYpNtEjvedDWSr//vIB5C6mpeoZCbu7R2hlrAYMHJPIF89Keg49oI27jNCq36G1KCtJW6g5QcXoWVZNWdo0X/h/cFZyJfeDBQ2eXdPp8ttTCuYhdC+gwChF11dQu5BN0X5IJUTGgezwl9mhjP78MaJLGrl5EG0SPo0hyNtYd3S6ZtUa8qxfd//wMz0l8OQ2AB5+uU2LVRqNPmpB8ZMoHLSPnUASc6KvV8V/PewiR/X++Ygf7os98SADTP8MOrJyCUliaFX5ZCHoFa75sXfse/3vx2BkW58k+6Wby253DRMPRSAdFY7ZPLeH6b40LS8a17HwCsHfA+z1ahijQYFkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SbdlfhpJYCYGsQQcuUTjQUQT+W12VkpY+HdlNyN70AI=; b=icXjQhb/EJXM+eGHQ+/k0MOSX6w46CAv0nViK7zKblD/8So7kxgApWdVAjt3kAPbeeq/pv5gVIASwAJOmdola7qZSquRvmDWPvJoDcgLHjLuU5IV6sqOVUvkIi7UBhCD0SsYAvommTeISEbwW+ze1OHg/4dl4S9hhljO3/QcfeM= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB2787.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:132::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Wed, 22 Jul 2020 08:14:20 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3195.028; Wed, 22 Jul 2020 08:14:20 +0000 From: "Brockhaus, Hendrik" To: Michael Richardson CC: "secdispatch@ietf.org" , "spasm@ietf.org" , Tomas Gustavsson Thread-Topic: [lamps] IDevID considerations document to secdispatch Thread-Index: AQHWP8N6k88ddaiq9U6Bs/QsBzthBajTsr2AgAV/EICAFWp0gIAApgFAgCOoroCAAJIagA== Date: Wed, 22 Jul 2020 08:14:20 +0000 Message-ID: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <19437.1595373505@localhost> In-Reply-To: <19437.1595373505@localhost> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=e01786dd-8b4d-436f-b3f0-0000287cb7ac; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-22T08:01:20Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; x-document-confidentiality: NotClassified authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.158] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3c8c4795-9433-4be2-b801-08d82e173c75 x-ms-traffictypediagnostic: AM0PR10MB2787: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: E2GGaBiS9A/JRbNEukF1eoHTEcAFgJDxnLW0zQYoSMvfxwmayHwrzo7ujSG/ND8kldo6kDBjFpxSjOeCrfL3qCtCn61cXjkbtK+ewsEuvtPH/d1MxyyYDpo8TwXpMag/jf7GnyyzjxaeKorRdcgGicqD/Cmd542RQpkOCokBlUjxMfc5HWO30rCmPPQ99jw6b+9qFQ4JIh9vhNu8u3kKd6de0VZkNcwqgbM+XLZD2M7IhVZkGvKxNhn/qzgxRJXSlrYpjEsTE6btouqclHN8nmOui07B7HiCY4SbH7vPDRVQHbVDjqrk6gQ78xKZyyVbVdFch7OqGcCycLVDz4CQ16DHEtZhmRDFCY5F0Wh/+v/JOVgie8bhzhgfLHc4tagGenWaAAiOcR9GCwpqwQOKrg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(376002)(366004)(396003)(39860400002)(55016002)(9686003)(8676002)(478600001)(186003)(55236004)(52536014)(66446008)(7696005)(66556008)(6506007)(66476007)(64756008)(83380400001)(76116006)(66946007)(316002)(26005)(33656002)(15974865002)(54906003)(8936002)(5660300002)(4326008)(2906002)(86362001)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: t131DU3FebnTjLyxN4EmqdCCUrZAyvlyhiOcHuwy72SKieuLDc3gBA8dyHqYCipQEcYCaGqitSV4YvpDE85RInY8yM8wnNShFixUbwgYv7VtomZtQhKexCdPENJnn7jIlI08ai5/i2Te4EONjdRWDSBGN/QYGe9F7k0GHeHOJ2ek5d3ZfDefPBSR0wnBsR7jINeE074z3L9kFEmMNLZ272nSICyWixoO6xzIt84FK8CISzID7RgFlFaoHw4Gl1jwcky23uPHhDZKu9pKpeSLEczLCntP/BA8nq1fCnIT6GKj+nefAhHnkFQ6UZ9IZfYmpDyIwWxkhJQAMnvpQm1dblIr5e5qxSFhYcelVpGiBvOAKZ6oXKToBytsitvlLmhqVUKDM6h868vbS/X5YX3G0CYeCwN8u27J/h9HUIpjw4EpfZB3Al3QTO6EE70kl0uy8zBSa2CwRfotvvBi/GtHIeWbk25MuYInQpO/JmIhVVf88CRBQIEUVmUFpdVaqKTd x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3c8c4795-9433-4be2-b801-08d82e173c75 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 08:14:20.5552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OtfCidSDhn8oHtKmwO1SAkKf8K0p/rR2r/H1DB3BvQGL6I3TXf71AGeUc9oP8rWtsWtUTb5cyDibQuLXvJQ6nXoIMeNs42Evb1KlBFauJY0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2787 Archived-At: Subject: Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch 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, 22 Jul 2020 08:14:30 -0000 > Von: Michael Richardson >=20 > Brockhaus, Hendrik wrote: > >> In particular, the self-generated (_invivo_) key suffers because t= he device > >> needs to do a write/read operation from the infrastructure. That = involves > the > >> highest possible latency for interaction with the CA and therefore= would > slow > >> the assembly line the most. >=20 > > We make use of the key-pair generated on the fly on the device and = do > > not see major delay on the manufacturing line due to CA communicati= on. >=20 > I hear this complaint as heresay, and I have yet to hear it directly from > someone who would know. They always seem two or three layers of > indirection away. I would be very happy to kill this issue as a non-issu= e. > I'm aware of a major VoIP phone supplier whose CA is on a different conti= nent, > and it's not an issue. We make used of a CA across continents for some years now and it works fine= . >=20 > > Finally it is a question of how you arrange your manufacturing > > procedures. If you experience delay due to waiting for the certific= ate > > delivery, you can do other meaningful things in the meantime. >=20 > yes, that's certainly true, but it also take some interactions among diff= erent > layers. >=20 > >> The invitro and shared-secret methods allows the infrastructure to > generate a > >> few keys in advance (and get them signed, assigning DN-serialNumbe= r at > the > >> same time), and then injecting that key via JTAG at the same time = as the > >> firmware. This overlaps the CA interaction with other steps. >=20 > > Finally this method puts higher security burden on the manufacturin= g > > infrastructure to securely handle the pre-generated key pairs. This= is > > why I do not like it, but sometimes it is needed. >=20 > The -02 version of the document cites: > "Factoring RSA keys from certified smart cards: > Coppersmith in the wild", September 2013, > . >=20 > for a story of not-quite-random-enough issues! For smart card production the pre-generation of keys is often used. Especia= lly if RSA keys are required. Key generation for RSA keys is much slower and duration is unpredictable, c= ompared to generating ECC keys. Actually I mainly see ECC keys on embedded devices today. Today the require= d key length for long term used RSA keys gets inacceptable, as ECC keys key= length is still acceptable. See section 4.6 in www.ecrypt.eu.org/csa/docum= ents/D5.4-FinalAlgKeySizeProt.pdf - Hendrik From nobody Wed Jul 22 01:45:35 2020 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 11F653A00E4; Wed, 22 Jul 2020 01:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=siemens.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 Al5c_f17MIN8; Wed, 22 Jul 2020 01:45:29 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80079.outbound.protection.outlook.com [40.107.8.79]) (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 9B25B3A00D4; Wed, 22 Jul 2020 01:45:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BCmMZTEP8j+4QxjWjD/csecS8VqOGjaTPB/oCW1gPaAAyXwewifJu9uUTibdu33K5lmfSpbjJPfl3hjEZ+p8SOPuzpOeOih9Sjyhz+dDAA1ACOnFpbp5kuK40/+jLbIfJ56CHQ/o4y+yL1OpNWDVkYejHrwi6hX4Vf40qciUvA62J0ZwclVFlIbuT/ZvFe5CyX0vGMlRUDYZATjPLt9EarbvFpAJqOvkSwRkOdZpaJZl/b5b9MZZh+mPGLEdvZ1ZeoiSUv8QAQt+NkdW6xkdtq3tNiu4IQzDEQLcy92PaCkg0mSPpzz6h3wUJK1tupbY9y+oTbOExRRzvVKx0Inlmg== 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=z2sBVPz4f8QRohXLpBCxqTMOKNED7lmoRF34eQXi3YA=; b=a45c3EArpgYi1KgEjVZ/k6Ix68jwi3mg630h6UJ2LZGcQG47i3HvqbVwUVKCMOOsXUL61hB7ZF9noAlj+OlSHmyhKwn/A5/1PIwmRlVXr9jkESG8YnWgVRz+DqCT3Z1Rl+VN9dOZ2H4lO2lII+rBr79RHyxrPUw7/CXxHHBrXBpeySfrUGUhl62XdWaHSfP4jAha00tlfzS8yCAC7harNJu6EW9UT56dMc79KEcyOhzZbhsn9QzYhwqSfIfxlVE0f0QEvvXmhWT8e3jsk9oO6l2N9tYWhfnJ7Hnk3C1PhRrqH3BpzuJzPxn8tPusr356oQfUIyo+eGd3UjUASQhgYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z2sBVPz4f8QRohXLpBCxqTMOKNED7lmoRF34eQXi3YA=; b=LAMYXqDEZf0yKNKgYwgtyl6KPkvtj4APihiDhW2Y8AlNJXlGN9oKTMiHZ9NxcF85CfJ3N+iA+ISc3uHn9nSvtUkF/+Xe4MPPL8obNjaMCLwssnOrUflU3tLj4pQDl6XwbjvdAuQ7wlWOMy3nEKQWCaC3Dz8m6jybXIy9Km3goUE= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB3474.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:154::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Wed, 22 Jul 2020 08:45:26 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3195.028; Wed, 22 Jul 2020 08:45:26 +0000 From: "Brockhaus, Hendrik" To: Michael Richardson CC: Tomas Gustavsson , "secdispatch@ietf.org" , "spasm@ietf.org" Thread-Topic: [lamps] IDevID considerations document to secdispatch Thread-Index: AQHWP8N6k88ddaiq9U6Bs/QsBzthBajTsr2AgAV/EICAFWp0gIAAvESAgCOWHwCAAJRy4A== Date: Wed, 22 Jul 2020 08:45:26 +0000 Message-ID: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> In-Reply-To: <22303.1595374300@localhost> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=6f010863-e5e4-4555-aa03-0000e8b22546; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-22T08:22:59Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; x-document-confidentiality: NotClassified authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.158] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9db08c61-6f89-4b28-9ddb-08d82e1b94a3 x-ms-traffictypediagnostic: AM0PR10MB3474: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GYKzc1kzwhC4iArveau3KDtaiXiBTliitsyI8LHETrHN+eHX+Ufhuosq++DxKOvr++AzT2A1ia8Wgg2zzVN7eyJvEHt1AYz9GOFPkwGoF24sRpxqCAOzaVuKUjf328sk+cErgIwGRkKKGO4PgKQa+twTeWIHryLvAZx8Cj5XC//uTkb3nEr2ORTTFacEGivxI1CMvjMeZhcIUvzwHA0ZYBdemND9Mb0tv16HjDIjDm+6TAjMl/O8LTc8l7xczrJeBd4fjqA0/FxKtyE3zzJzWRGjAanrh5cuRVN1s8WGhTY5pYqlYpUyINkXYDh7oeeC5XI+u8grjskS0sTVFtNUrw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(366004)(346002)(136003)(39860400002)(26005)(5660300002)(55236004)(186003)(54906003)(33656002)(7696005)(8676002)(83380400001)(316002)(66446008)(66556008)(55016002)(52536014)(71200400001)(76116006)(53546011)(6506007)(4326008)(8936002)(2906002)(66476007)(66946007)(478600001)(86362001)(9686003)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: wAm0HRW3iilu7AfKcpAQ5MUSbXX9tiEtI9hVL1TAZR6e7lOEihCycN2U/itqHRDflsIUioyJTY+42N8bQIt81sd+My78ma1DdAX5baVZ9wMtyAndpb7utanPMiBLnKXmLtQplQXKMNklI4nXpDoUUCBD6lGe0kfYQ7ni4IOUpVnp5ZjrSQYNof67ESucrYAvJjxT9ozJzlN73jyqBlP7+fmqZ1fnb3kj8pM/twqLJgCwFTik2jw1K765JSC7Scu/1ca4FyJlJ0crIitee+qbkh//D0sSgPNSoYUsM/5AdmbsIUvr5yJ7OGU7gMBChv6Jd/rX6svW4Wl58zDrEuG8uMBspmhDOKt434UWIGv2sc06nRwnILwXGp682mW5PkXs+CZSQ4T4aCZ/QAYkwiB7IYrhBcQcsg3s7wGD2UbTAXNKLx42qP2INVxGwRDONtiM6XOVMG6j5JEDrWnirfmBCO4PawfnZFNxje5U2e5Z+RXtI8sjVYPXW7JUeDWxN464 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9db08c61-6f89-4b28-9ddb-08d82e1b94a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 08:45:26.5222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1zexfqWeMvoLGwP/A96LRj67MzQA8buFZDaC5JlTxyMbImhh43+j6nghLlz0Jd9QILhsp6KTSEOpec1ApO/FQW5WHBcC3tJfEXzx4IcGSpk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3474 Archived-At: Subject: Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch 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, 22 Jul 2020 08:45:31 -0000 > Von: Spasm Im Auftrag von Michael Richardson >=20 > Tomas Gustavsson wrote: > > On 2020-06-28 22:51, Michael Richardson wrote: > >> > >> Thank you again for reviewing the document! > >> > >> I know that primekey is involved in creating Birth Certificates fo= r > >> many product lines. (Your website's term, not mine, but a good > >> one) >=20 > > It wasn't my (ours) terminology unfortunately :-). We found it > > elsewhere. I don't remember where "birth" came from. 3GPP 33.310 ha= ve > > the same concept, but calling Vendor certificate. I think birth > > certificate is a little better, as it's more generic than specifyin= g a > > vendor relationship. >=20 > I do like the birth concept, and I am thinking if changing the document n= ame to > include it would make sense. > Perhaps someone with expertise in attachment parenting can provide some > interesting words about how trust anchors are installed. >=20 I use the image of the "birth certificate" to better explain the attributes= of an IDevID certificate. - Issued at manufacturing time (in Germany the birth certificate is a simpl= e sheet stamped and signed by the local register office) - The enrollment process requires some organizational/physical security, as= there is nothing to derive trust from at that point in time (in Germany th= e father or mother have to request the birth certificate personally. They n= eed to define the name of the child in front of the register officer and ne= ed present a conformation letter from the hospital or midwife about the dat= e of birth) - It lasts as long as the device is used (in Germany a birth certificate ha= s no validity and it is difficult to get a new one, if you lost yours) - It is required for initial authentication to request an operational certi= ficate (in Germany the birth certificate is required if you request a natio= nal ID card or a passport) - It should not be used for day-to-day operational tasks (you would not use= the birth certificate to identify yourself other than to the register offi= ce. Only rarely it is requested, e.g., when becoming a governmental or publ= ic official) > >> I wonder if you can comment on which of the three methods you > >> support? Do you have any suggestions on names for the three > >> methods? To me, just getting three good names is 90% of the value > >> of this document. >=20 > > We support: > > 2.1.1. On-device private key generation > > Standard CSR-submitted-to-CA process >=20 > I have named this: > a) _device-generated_ / _mechanically-transfered_ > b) _device-generated_ / _network-transfered_ >=20 > I know that you are blown away by my imagination here. > Perhaps someone can feed this through a mechanical translator, run it > English->German->Mandarin->Swahili->English, and see what comes back. >=20 > I think that it's useful for the entity that needs to examine the risk fo= r the > process to distinguish the two transfer methods. >=20 >=20 > > 2.1.2. Off-device private key generation > > Typically CA-generates-keystore process. Some protocols, i.e. > > CMP/RFC4210 have standard support for encrypting the private key se= nt > > back to the client >=20 > I have named this: > a) _factory-generated_ / _mechanically-transfered_ > Like a serial console connection, or a JTAG flash writer. >=20 > for b) _factory-generated_/ _network-transfered_ >=20 > yes, but what key would you use? :-) > The device has nothing.... > So I think that it really has to always be used in the factory with a phy= sically > secure network connection. I personally would prefer to say '_infrastructure-generated_' than '_factor= y-generated_', because the generation on the device will most likely also t= ake place in the factory. >=20 > > 2.1.3. Key setup based on 256-bit secret seed > > We haven't seen this. Albeit, it's not so much related to the PKI > > part, so it can still be supported/used if the certificate issuance= is > > done using a CSR process to the CA. >=20 > I have named this: device/factory-co-generated Same here: 'device/infrastructure-co-generated'. - Hendrik From nobody Wed Jul 22 01:56:23 2020 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 D79843A03FF; Wed, 22 Jul 2020 01:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=siemens.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 7fAjZipvjS1w; Wed, 22 Jul 2020 01:56:16 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2061.outbound.protection.outlook.com [40.107.22.61]) (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 01B323A03F3; Wed, 22 Jul 2020 01:56:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cTG5R3uo2IpKhT8kq3psXUyrbwStwjFlUP3ZRNdn1MVzk1AFHE4IH+F3Kjx5TUKpV69nIf0yUp/a9EDB9NEhsB/7C7UN4kGrYH+pajJk3zbGAEva6nhjVigHTgj/YegjEwqyb3g30PA8c5ooHnWl59QGh/ARJiyC/6fZZb328HAI0LpnmRYjqvy2LmxTVxmovhxVo6LUnoLRED/0TKZ/OEM1RRDD+tu2z/LWXytTsydirno0pkpeZUkAZosZhkKWFF0bp3usYu9em85ONRzNZKVHx9MWeAssUdRh6oHx2kCF3b3cR4v6D8t38t4TUPnj2F7x13FusAU+YdYb198I1A== 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=iSWQZK6CT+BT6bvxdxhLk2rf9uj5DwjITaxcfOVQBrk=; b=TCkzDnfvutquuO6ce76m+94GTe2m0xPzWRCW7RX+QQ3YiUiY41xDZCAPulw5fSRH7babyybQLZzpKeX4yjBgG+sqSHMn832HQRQafvpGBYf+CX/078EIQ5mqGy1MW2q4Zmp0+tMaFu1pDsH84S74M6cuTan0SzHn3vJzCyYkd75h0xPpeM88tB5Q/de8miHdyRUNFoXblrngFVxqwQ1YAQU39UrRRYfkU1yKevhXjIKrSnZVxB4tScvws3jDjpytEbGQPUtTSHOMOeXYp+Ez4jFfHoI9o+10LyoeDYoCNA2MG7Hcdwch3qf0CUF1u1q+V0g89vO0rd/HVGkH2JfoGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iSWQZK6CT+BT6bvxdxhLk2rf9uj5DwjITaxcfOVQBrk=; b=oUDRdZgLX93Ro2o6Q0BeAU0R0MD8Sb1aBJCNrYKXPOcIdTcFqLL5VJsUsgzVzR92RE0Hu/nM6QtNX8wlpOSgJ0sRX5mL78g4Zh6E+fw+w4F7MW4bsDMFMg6zBA2lgpYd5b3EXwKl1Z9QZdUzJc6H/grVMxyeAfG4tdUbBjvoa+U= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB3457.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:154::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.22; Wed, 22 Jul 2020 08:56:13 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3195.028; Wed, 22 Jul 2020 08:56:13 +0000 From: "Brockhaus, Hendrik" To: Tomas Gustavsson , Michael Richardson CC: "secdispatch@ietf.org" , "spasm@ietf.org" Thread-Topic: [lamps] IDevID considerations document to secdispatch Thread-Index: AQHWP8N6k88ddaiq9U6Bs/QsBzthBajTsr2AgAV/EICAFWp0gIAAvESAgCOWHwCAAGIVgIAAOgCg Date: Wed, 22 Jul 2020 08:56:13 +0000 Message-ID: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> In-Reply-To: <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=564c554f-cedb-425c-a34c-0000f7674392; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-22T08:50:19Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; x-document-confidentiality: NotClassified authentication-results: primekey.se; dkim=none (message not signed) header.d=none;primekey.se; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.158] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9614d11e-53da-4fa0-c0cb-08d82e1d1679 x-ms-traffictypediagnostic: AM0PR10MB3457: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LHgzG0IpzzKjliD8tqIzURGiolA3ozxnCjZT1fc6C8RrUFbJcCgqX2oVsyJcsxbgkg7xfJcc9EVwjP3PuuJXWhvUr5mie3Yya47eDfY/fSX7rtHrqrIN54ZCyMdNxJrfvp1JHGCsvKopR4mhfRPFtzaRDpwJ6ErojfBDPE4TpI38KvUQ4J1W4f3vN4zNK/j+Y9aP82itpmUKCUo3/onZoM+xj2ppGlwG9pYyN/mk15wLD+52JDIv2U3q2M8Vz0gN4GpobJ6cToVM9NW6xB8uXSYR9Jbr0Eg1pjUSGXuoGJ1YAA43n84b/ILjRYru/wM7uxTOTtMXC8jK1392R9yUxg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(366004)(396003)(39860400002)(376002)(52536014)(8676002)(186003)(83380400001)(6506007)(316002)(71200400001)(2906002)(26005)(8936002)(5660300002)(478600001)(66476007)(66946007)(55236004)(76116006)(66556008)(7696005)(9686003)(55016002)(53546011)(110136005)(54906003)(86362001)(4326008)(33656002)(64756008)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: gWK2EenDW8O9O1ZslEEzVPd99JKCFbcZjbp5kfiyIPw0FbsqossLaEw68x7Ymp5SPxp2WxBEQO7ZCFwkye0l3fS0vi4djCXZcLUBDaaOlpfcomwk5fmDLvKEGiFrj90SFn/ydewYk0r7DW+8VfjD6z1i5XLQyJS9XpPVc/Jg8jdd9GC4Rbru+loWGPJg0HURyCgUgcCI7YL6/DRmZKSOl5eWyOh+5VayDvsgGe6afp1ZuuomvWtaseb18sDfTgTtCnaVUfIypdzso/e3nalnyzguwYz0GizQWHYgX4l7mXIG5vYrMgtS1T5p0K1YkTZUBCs0M3yg7hnFopdIbQTQY1yA35JuzDiqBRyVeQGnQnwEpblX0FdMubnqWaZXVAtfS23UQgMxRSSUZeUyhtr7AZw21o9FxZa++ToMRm/k5Mm8OnnGqwofRNlrvx2pnuupZUPVPfewBMC0flC9E5HsUdkhAG6pHbcrPizgFjjw48RiTrTr/NB/ZnVQcucVPnIE x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9614d11e-53da-4fa0-c0cb-08d82e1d1679 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 08:56:13.7737 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: V2fnxPjgE5a0ErMcsyfGxwumNwySeYteJz74bLOt3WxNkrLqWnc6BSkgewke44ZW6Sgfz18/v9bsL8I/kMnud5BAamScBMV7ZPHOH1f447Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3457 Archived-At: Subject: Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch 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, 22 Jul 2020 08:56:18 -0000 > Von: Spasm Im Auftrag von Tomas Gustavsson >=20 > On 2020-07-22 01:31, Michael Richardson wrote: > > > > Tomas Gustavsson wrote: > > > > > On 2020-06-28 22:51, Michael Richardson wrote: > > > 2.1.2. Off-device private key generation > > > Typically CA-generates-keystore process. Some protocols, i.e. > > > CMP/RFC4210 have standard support for encrypting the private key = sent > > > back to the client > > > > I have named this: > > a) _factory-generated_ / _mechanically-transfered_ > > Like a serial console connection, or a JTAG flash writer. > > > > for b) _factory-generated_/ _network-transfered_ > > > > yes, but what key would you use? :-) > > The device has nothing.... >=20 > Very good question, I thought the same. > In the case I see, the device don't talk directly with the PKI. > There can be a secure HW device in the factory interacting with productio= n line > on one side, and the CA on the other. It can talk something device specif= ic, > direct connect, with the device on the production line, and make the CMP = calls > to the PKI. The private key generated (by the CA) is then encrypted with = the > gateways public key (where the private key is kept in an HSM/TPM/SmartCar= d). > Yes, the "gateway" becomes a point where the private key is decrypted and > vulnerable for a short time, so it's not for every scenario. I wrote down some thoughts on central key generation in tools.ietf.org/html= /draft-ietf-lamps-lightweight-cmp-profile-02#section-4.1.6. There are some cases where an EE is not able or not willing to locally generate the new key pair. Reasons for this may be the following: o Lack of sufficient initial entropy. Note: Good random numbers are not only needed for key generation, but also for session keys and nonces in any security protocol. Therefore, we believe that a decent security architecture should anyways support good random number generation on the EE side or provide enough entropy for the RNG seed during manufacturing to guarantee good initial pseudo-random number generation. o Due to lack of computational resources, e.g., in case of RSA keys. Note: As key generation can be performed in advance to the certificate enrollment communication, it is typical not time critical. Note: Besides the initial enrollment right after the very first bootup of the device, where entropy available on the device may be insufficient, we do not see any good reason for central key generation. Note: As mentioned in Section 2.1 central key generation may be required in a push model, where the certificate response message is transferred by the PKI management entity to the EE without receiving a previous request message. - Hendrik From nobody Wed Jul 22 08:40:06 2020 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 BFD6D3A0916; Wed, 22 Jul 2020 08:39: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, 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 6uhuoty_7HGd; Wed, 22 Jul 2020 08:39:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3E43A090B; Wed, 22 Jul 2020 08:39:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6F7F238A26; Wed, 22 Jul 2020 11:19:26 -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 2cJHfdR22g9q; Wed, 22 Jul 2020 11:19:25 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 07E2538A24; Wed, 22 Jul 2020 11:19:25 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 322FF1CC; Wed, 22 Jul 2020 11:39:51 -0400 (EDT) From: Michael Richardson To: Tomas Gustavsson cc: secdispatch@ietf.org, spasm@ietf.org In-Reply-To: <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> 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] [lamps] IDevID considerations document to secdispatch 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, 22 Jul 2020 15:39:57 -0000 --=-=-= Content-Type: text/plain Tomas Gustavsson wrote: >> > 2.1.2. Off-device private key generation >> > Typically CA-generates-keystore process. Some protocols, i.e. >> > CMP/RFC4210 have standard support for encrypting the private key sent >> > back to the client >> >> I have named this: >> a) _factory-generated_ / _mechanically-transfered_ >> Like a serial console connection, or a JTAG flash writer. >> >> for b) _factory-generated_/ _network-transfered_ >> >> yes, but what key would you use? :-) >> The device has nothing.... > Very good question, I thought the same. > In the case I see, the device don't talk directly with the PKI. > There can be a secure HW device in the factory interacting with > production line on one side, and the CA on the other. It can talk > something device specific, direct connect, with the device on the > production line, and make the CMP calls to the PKI. The private key > generated (by the CA) is then encrypted with the gateways public key > (where the private key is kept in an HSM/TPM/SmartCard). > Yes, the "gateway" becomes a point where the private key is decrypted > and vulnerable for a short time, so it's not for every scenario. > The CA can be off-site, not in the factory, i.e. central organization > PKI. The the term _factory_generated_ can be a bit misleading. The CA > can of course be in the factory as well, I just don't want to trigger a > specific architecture image in the readers mind. Should I say _ca-generated_ then? >> So I think that it really has to always be used in the factory with a >> physically secure network connection. > Physically secure on the production line itself, but can be internet > between the gateway on the production line and the CA. Agreed. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8YXcYACgkQgItw+93Q 3WUnLQf+MHxRB1ZLzTykok6hRqG7iWuI+LiPf5v9th8H5QfxaYtWXWczOClJn/bE yHek+G3X6Z//ahYcAPKdUYKi4dnZkn7Bjh8FGXNclY8t/TCTyais4dkCceEYSzmJ oA4rAWR2kjxUDxVI8pL2IL+TysKIUCchgM9LFHxUt56vqb9iVvbR/2RvgGfIH0wF PYfoGpLcGZyTRScvmSxarBrVMwqY4n48cC8XfL2pVuAI7aZLTbIac+inppXydq7S qeCxovzq0zlsRVRNKyQGkquGl1iEh1+xo1BVwQ6t83GRW2PntOp2VwGMrekGDTB+ ceMp43+NMoA8MSDjDkyXnw6lDRMpkw== =Dx21 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 22 16:07:36 2020 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 32FF23A090B for ; Wed, 22 Jul 2020 16:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.339 X-Spam-Level: X-Spam-Status: No, score=-17.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 O8LrFZfhabih for ; Wed, 22 Jul 2020 16:07:32 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 A42553A0915 for ; Wed, 22 Jul 2020 16:07:32 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id lx13so4296509ejb.4 for ; Wed, 22 Jul 2020 16:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MfhtrUXmJu/mCUrcr6QcbAzP54gs78h0EzabbtuhLgU=; b=nq6Y+Mp31DCGX8ZDpHVoaZP8egWrr9B7/dAZSqRwMp/C6UqeqIT6svphaofbI8JUCO DNJzgV1ec1NyX9SphUC3DFcPRbCq+FjAXhxQMUeWzMv5K6ngS3Xxo3F+BRdZ5TB8QyqF t5fowXDRxGz+7xofEgeHQLJRg6D8ensIdcvAoMnX9RV5LQpA0VLDaVjZpoZIOWpYsKle PEKt9J3g2wS2254eJQ1sKep+rieAoRjL6xbKz/2gD7dsNRcdMAkcYXL0j0u1HUPKEmJL hHK7NHzdEdB8KG917H7UaUxDanJdnLv3u2zenHzstn7cf9FeSp8SUgqvEVrkSHvodkhc nRmA== 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=MfhtrUXmJu/mCUrcr6QcbAzP54gs78h0EzabbtuhLgU=; b=Td0QENvue2z/x3iNZ3lChn76WaEa9nCa4/KyPPHtThM/itS5TBFZXVVw5TDYQEAbjV QcSTZ/mcl7lea6JNaunQEVYnPUWXVGFvziQq4qpVcCsEmXoCTQOffXwdVRQzQNAuPwWp Q+PamQ+6BtDIG4wFFRYxCgZ6RfVSX+LUQvZIB9K2laqpY6TwlE3oAFdU+wXR5qxl4+dS aooJMZS8dmQFIEGglnuYQEY9oJvq13a2QkfYEZfpUaMhkd8sHm9bMGFJQ3UxZzCiSW0U tK34BmH2HpoT6YyoueNgBYEXRb+Q/fOFO6zybA9tS0NXhcUyHy1QSZTnhZ/FQNrNUHjf JPMA== X-Gm-Message-State: AOAM5313vW5uA/PPFoahi8qmPKl60ZbrHcyFjL6OqDMUIXjnvbyTxy74 gUT0/agNDSIgN+jKO7QEDmBipwtOU3A1h7lJ2OtIPgvArdQC X-Google-Smtp-Source: ABdhPJxe1c9qV1qZbkJSrIx8df9dturzSPu3k0YVrnsQgkSRxC9l0bympRA7Pb61FYCiQQWvBKmxaiUrtobvOPcCp5c= X-Received: by 2002:a17:906:ae56:: with SMTP id lf22mr1728421ejb.59.1595459250603; Wed, 22 Jul 2020 16:07:30 -0700 (PDT) MIME-Version: 1.0 From: Emad Omara Date: Wed, 22 Jul 2020 16:07:19 -0700 Message-ID: To: secdispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000e34b7405ab0fcd06" Archived-At: Subject: [Secdispatch] SFrame: new proposal for E2EE in video conferencing 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, 22 Jul 2020 23:07:34 -0000 --000000000000e34b7405ab0fcd06 Content-Type: text/plain; charset="UTF-8" Hi Security dispatch, I will present the SFrame proposal to the Dispatch on Monday and discuss the possible next steps for this work. This might be interesting for the folks here, so please feel free to provide feedback and join the discussion on Monday. Thanks Emad --000000000000e34b7405ab0fcd06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Security dispatch,

I will present th= e SFrame = proposal to the Dispatch=C2=A0on Monday and discuss the possible next steps = for this work. This might be interesting=C2=A0for the folks here, so please= feel free to provide feedback and join the discussion on Monday.

Thanks
Emad
--000000000000e34b7405ab0fcd06-- From nobody Thu Jul 23 07:39:04 2020 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 BA0543A07FF for ; Thu, 23 Jul 2020 07:39:02 -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=ipv-sx.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 wQSCY-gEiz-1 for ; Thu, 23 Jul 2020 07:38:59 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 9C2553A07FB for ; Thu, 23 Jul 2020 07:38:59 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id g26so5544840qka.3 for ; Thu, 23 Jul 2020 07:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ETdUhHERw9J2u5FXYknGs5JhPbs1dmfsq/R1oTtFN8=; b=sLj+GAY6conkullVraCgU3jvPwcVVrmuY5l/J7uE6WZRNiyc+fRL8dSfa6gV1B7MPw re7xgO3GEB9zlyTCzhU6hBEvqCH/moBFRd7SEmw+RyI6nmT5lgGKAHsXN63AJJxvE4Tq VFUdsfgra/dClbLjyoaeJBo+g6/On0PoS7xjHuHr+jSmfwUnBcZR4gsbMAJ6hQcs+xLr HgfvCTGBKWlGJp+FAOeJwVCPPv5TgV/7X+kz6qLGo+O8vPOyP6Sjki/zMzixvcpI0fGF RD/FhqqaWIienx9uzrei94DamXKTsIVW5gtsXmcvP6XL9+flQ4NpJwhGhrvEkaePTVdk 7qmQ== 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=1ETdUhHERw9J2u5FXYknGs5JhPbs1dmfsq/R1oTtFN8=; b=Mg8Lgz/DmDAMYuxvoMxjkaNpc0bcBAHtb6I4Yw63lVqSs+1acWqNSi6mEUJ6NWQQp2 yXyQrxA7aTlWCUF1SFtO8iUtFCHqMdak0e48JRLQhzb7pkE28r8F7huy3v7sw+xGaTwp smiu+YNgUyX+wZrN8myGSsrW4TzsHjtudtpu1BhO9a5LjEYfpgSGscdZJUT7jed/exYA dvbz8GVbgEnSr8czqLMCk7YOCF3KiO7TdPDsShLsHiqWFmiCgBgoMxiqnVzRWsvpvcfi zjwF1etZg24Cg2AZF8lnJC4AciNM6gleLFji5OrtZHI6PjsZNTXOvi7TOtERj85OEnpZ g9Ig== X-Gm-Message-State: AOAM532ub1BRpb9zsKPtWIRdEgLEAimqIFsaRpA7IgsaSi87moS8yMYL Sz19JExskxb5ro3U3LIypTY5D8szXDfx8m9b6P25mggXw/g= X-Google-Smtp-Source: ABdhPJyMel29U63OERe1J5ViHoKmjfmY+DK30lpn952yZGBAMNrdjUFjU4qNMv/PsMMtkd+YlIqesos/QeJcQybZfCA= X-Received: by 2002:a05:620a:63a:: with SMTP id 26mr5538336qkv.490.1595515138380; Thu, 23 Jul 2020 07:38:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Thu, 23 Jul 2020 10:38:31 -0400 Message-ID: To: Emad Omara Cc: secdispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000000ea41a05ab1cd106" Archived-At: Subject: Re: [Secdispatch] SFrame: new proposal for E2EE in video conferencing 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, 23 Jul 2020 14:39:03 -0000 --0000000000000ea41a05ab1cd106 Content-Type: text/plain; charset="UTF-8" A little bit of additional context for folks: SFrame is designed to provide E2E protections on top of what is provided by a base media transport like SRTP. It has some similarities to the PERC work, but is also learning from that experience. --Richard On Wed, Jul 22, 2020 at 7:07 PM Emad Omara wrote: > Hi Security dispatch, > > I will present the SFrame > proposal to the > Dispatch on > Monday and discuss the possible next steps for this work. This might be > interesting for the folks here, so please feel free to provide feedback and > join the discussion on Monday. > > Thanks > Emad > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000000ea41a05ab1cd106 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A little bit of additional context for folks: SFrame = is designed to provide E2E protections on top of what is provided by a base= media transport like SRTP.=C2=A0 It has some similarities to the PERC work= , but is also learning from that experience.

--Ric= hard

On Wed, Jul 22, 2020 at 7:07 PM Emad Omara <emadomara=3D= 40google.com@dmarc.ietf.org<= /a>> wrote:
<= div dir=3D"ltr">Hi Security dispatch,

I will present the= SFrame proposal to the Dispatch=C2=A0on Monday a= nd discuss the possible next steps for this work. This might be interesting= =C2=A0for the folks here, so please feel free to provide feedback and join = the discussion on Monday.

Thanks
Emad
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000000ea41a05ab1cd106-- From nobody Thu Jul 23 10:33:25 2020 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 79EC93A0C63; Thu, 23 Jul 2020 10:33:24 -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_DNSWL_BLOCKED=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 ocA71TTpg8CT; Thu, 23 Jul 2020 10:33:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB9A3A0C64; Thu, 23 Jul 2020 10:33:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 231F838A30; Thu, 23 Jul 2020 13:12:51 -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 dY7-hBsZd7gp; Thu, 23 Jul 2020 13:12:50 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 40B1E389AA; Thu, 23 Jul 2020 13:12:50 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 640939A; Thu, 23 Jul 2020 13:33:17 -0400 (EDT) From: Michael Richardson To: "Brockhaus\, Hendrik" cc: "spasm\@ietf.org" , "secdispatch\@ietf.org" , Tomas Gustavsson In-Reply-To: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> 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] [lamps] IDevID considerations document to secdispatch 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, 23 Jul 2020 17:33:25 -0000 --=-=-= Content-Type: text/plain Brockhaus, Hendrik wrote: > I use the image of the "birth certificate" to better explain the attributes of an IDevID certificate. > - Issued at manufacturing time (in Germany the birth certificate is a > simple sheet stamped and signed by the local register office) > - The enrollment process requires some organizational/physical > security, as there is nothing to derive trust from at that point in > time (in Germany the father or mother have to request the birth > certificate personally. They need to define the name of the child in > front of the register officer and need present a conformation letter > from the hospital or midwife about the date of birth) In Canada, I think the birth certificate is signed by doctor or midwife. > - It lasts as long as the device is used (in Germany a birth > certificate has no validity and it is difficult to get a new one, if > you lost yours) Thus IDevID never expire. > - It is required for initial authentication to request an operational > certificate (in Germany the birth certificate is required if you > request a national ID card or a passport) > - It should not be used for day-to-day operational tasks (you would not > use the birth certificate to identify yourself other than to the > register office. Only rarely it is requested, e.g., when becoming a > governmental or public official) But, you don't use your IDevID for day-to-day activities. One needs an onboarding protocol to talk to an organizational CA to get the LDevID. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8Zyd0ACgkQgItw+93Q 3WVggQf/b9SvHfuMXB3LsWAatnEA6kb4w2mvbg2zi07/0n5TEI3vWKVWEJW5svYQ YfSYlB2dMbjH5+lfJyPHsznJ8FJqYcx5+iLDhIUITZUsF1uwKFR5UF0jnvsSsE0r m30A5GE8+W08Oes4vFq/2p6E/l3nKZGi8XFB/FG75SdbOKGV9qLEbGd5LH1lwDY+ cXW6EKQa5mz1f4+iTuOD0pp1N8FpU8Zfu/AMHSvK+At4ai8PGgrBOd1I6rLxMD8M 4T/q/iI+mGp4SAtD17ka8GWECuuTV9EnyNbxf/XcDa7qgwBzJwMFMBT9VyEUo3dV /ZIiK60GjLHC6yXQgEwlwKj45gbW/Q== =OlPZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 23 12:35:05 2020 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 059F43A0CF3; Thu, 23 Jul 2020 12:35:01 -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 CUXcAJ7CMsSS; Thu, 23 Jul 2020 12:34:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CB03A0C4D; Thu, 23 Jul 2020 12:34:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DD94438A32; Thu, 23 Jul 2020 15:14:29 -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 TsC2yniYBvz5; Thu, 23 Jul 2020 15:14:29 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D397638A06; Thu, 23 Jul 2020 15:14:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1D8851CB; Thu, 23 Jul 2020 15:34:56 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker , SPASM , secdispatch@ietf.org In-Reply-To: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> <19924.1595432391@localhost> <995a966c-bd9e-ca25-18a2-1e90b3c530e7@primekey.com> <19403.1595518388@localhost> 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] [lamps] IDevID considerations document to secdispatch 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, 23 Jul 2020 19:35:01 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker wrote: > Just thought I would weigh in with some points. Thank you. I don't quite understand how XKMS can be used to provision private keys, but I do agree that I do agree that the rest is a mess. My goal is to just collect and describe the methods. I originally started with the idea of being prescriptive about the shape of of the PKI that is used to provision the certificates. I am pulling back from the prescriptive part, and instead I intend to just describe the different considerations, giving them names. > There are no good choices for creating key pairs. All have drawbacks. > * Any key generated by the manufacturer can leak at multiple points i= n the > supply chain. But it can be welded to the device in such a way that it > cannot be extracted without extreme persuasion. > * Any key that is generated by the device can also be compromised thr= ough > an intentional side channel or by weak key generation. And once gener= ated > can usually be extracted. I am interested in why you say that the key can be welded into place by the factory, but a key generated internally can't be welded in place in the same way. I think both strong and weak ways are possible in each case. > * Any key that is installed from an external source during onboarding= can > be compromised during that process. Agreed. > So none of the solutions are good. What should we do? The best answer= is to > do all of them and combine the keys using threshold techniques. That = allows > us to get a key that combines all the properties we want and is only > vulnerable if there are multiple failures. > The math is explained in this draft: > https://tools.ietf.org/id/draft-hallambaker-threshold-02.html I would like to include this in my list, but we have a chicken and egg situation on it. > There are some caveats. While the private key is as strong as the str= ongest > of the input keys, the public key is only as good as the weakest publ= ic > key. Which means that the validation process has to be carefully desi= gned. > There are approaches I took out of the drafts that are secure but onl= y when > implemented exactly right so I have described a conservative approach. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8Z5l8ACgkQgItw+93Q 3WVMoggAs1LtngZYGQKV16PwX6++J5WeWlLMeQbOG1AM80zUL1LkgCZGmvYri8Ha 07SKo4NTjS0ZFGv2/9nPbx7Zfkub7Bzj68HgkKFsGaCWO6Ss+1Qduh/qDOAOQg8O 90W555c+dcdgQDNKPtabd8ApjrgV+cbzoYLqKViVFWzotkMQ33C4+isDNALw54Os uTDTRznp6pIIyOA7dWl6IJDA2eCigXcR8VOk7YjoGC27P44NAVbSxQ/CY27IF8X/ mcS+STW4EteWVqEtBQIZMsJBPtvt4/ksO+L1jsz+ktVFfCFIsYnyfbM/SNIsv6ok zgGyCTCg7EB5d7jZ8Ah8YpgNTkvv4Q== =uyML -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 23 18:12:19 2020 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 ABEFD3A076C for ; Thu, 23 Jul 2020 18:12:18 -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, 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=callas.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 lIDbsrmW3BJq for ; Thu, 23 Jul 2020 18:12:16 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 8B4033A0772 for ; Thu, 23 Jul 2020 18:12:16 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id w126so3961641pfw.8 for ; Thu, 23 Jul 2020 18:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l2EsPj5rj3+CLk94KVhb4xGlnZZFlguATb5RlStL5xI=; b=BP1zbYy78k0mD11jXF7apLY9q8/NjbB167qVtnfl/982XpBuZdslits6U3cnUki0s3 jZFKFB+1+nYCf0D2zOQM6cLFcdBGBoz+exA3vROz2874dXFv1H0VjPqdDvXaxRL44F62 GxHrlpq5b76xqJJHwUkayQb+a8V562aUOdMF//WMZ/Vpdlxt5NvsYptxouGL0ZpX91Il oWqM+oMyht6TKpZLDPvuCVYhdiX+UJmN/p02idsA89Jz9d8NMIv7lv8fxNpq7YazVBwh JoMtum6x2/k2JUF8hW7wdXqgW67xsmVZA9rXH5o5QvDtwi/50Xpv4es0hTtBCjvbj8D+ twTQ== 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=l2EsPj5rj3+CLk94KVhb4xGlnZZFlguATb5RlStL5xI=; b=GnXm3VJbsqihdcILyytKiYdFy7Lml4cwl0qcmFdsGzl2bquacEqAzkmxYzi0bQhR+s 77+UG3MrKUslQEAtJcc3UKN9sK0eKQke/dUFEkUJetqEdgKKApatR8fpHN7Ff5TxG1Gu ep29n345hOKFB4vp4jLTNwxLkJJjyuddtmSfP1en5RyyjOXrDZ5h58r+n0Sh1S3JXSV1 Sls2f1sF/q9b4b+ybY5Lwc+6+WlxPzDSnveme061shOIDJr63DROBKoUHv+LVnRi1nEC HShBpwJl1+IQxOd7lZMl7Zgk6NiStRUO0eLsYIHWZOsMzKZU9rlWTMFspmCkDQqV9g86 2JUQ== X-Gm-Message-State: AOAM530z3C98K1qjFuuyAAr2N36l1Bdqtl04jGCJr7TbwSLdF/RJCGmL yy4a0UHP9bKb8vtw6p+DxlfXyqUABefUUw== X-Google-Smtp-Source: ABdhPJxaNNMfDZ8TIalX+fAZJwwNvZP5sudfWicyrRnHAIANrIOcf71vGRfxHTUB1nbUs5ZfBO9r7A== X-Received: by 2002:a65:6714:: with SMTP id u20mr6570528pgf.121.1595553135444; Thu, 23 Jul 2020 18:12:15 -0700 (PDT) Received: from ?IPv6:2600:1700:38c4:12bf:f579:6371:4362:c1bf? ([2600:1700:38c4:12bf:f579:6371:4362:c1bf]) by smtp.gmail.com with ESMTPSA id j16sm4230911pgb.33.2020.07.23.18.12.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2020 18:12:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Jon Callas In-Reply-To: <31625.1595368614@localhost> Date: Thu, 23 Jul 2020 18:12:14 -0700 Cc: Jon Callas Content-Transfer-Encoding: quoted-printable Message-Id: <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org> References: <31625.1595368614@localhost> To: "secdispatch@ietf.org" , "draft-schanzen-gns@ietf.org" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Secdispatch] GNU Name System 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, 24 Jul 2020 01:12:19 -0000 I've also read through the GNS draft and have some comments: * Like Michael Richardson, I have a great love for SDSI and love to see = it used. I think there's a large discussion we should have about what = the use cases can and should be. Alternate roots etc. are an issue, but = I'm not sure it would be so bad to be able to say "ICANN's ietf.org" = other than that it implies there could be someone else's "ietf.org" and = that this is obviously problematic, particularly in how it would enable = things like phishing. I take the opposite take on user experience. = Protocol documents shouldn't be talking UX. Anyway, I think there's a = discussion point as to whether this is a good idea. As much as I would = like to be able to say "the media server I have at home" (for a number = of reasons, not the least of which that that implies I'm not at home"), = it's not clear this is really a good idea in the general case. My = security auditor's mind is having a field day in thinking of cool = (meaning confusing or malicious) ways to use this. Yet, I think it's a = discussion point. * If this gets put into a working group, I think it needs an IETF name = for it, not GNS and not something that contains "GNU." Other standards = have had their institutional links filed off; SSL became TLS, SSH became = SECSH. Notably, OpenPGP did not, and I think that this was unfortunate. = Despite all good intentions at the time, it's created confusion, and I = say that as an RFC editor and as an implementer. There's nothing wrong = with GNUnet's GNS being a reference implementation of , and my = advice to both the IETF and the GNS people, you'll be happier if you = change the protocol name. * There are a number of eccentric things in the protocol now. I don't = mean that as a pejorative -- there are lots of eccentric things I like, = SDSI, for example. I also like CFB mode as well as Twofish. Why, though, = are they here? Are the design decisions leading to these? There's not a = lot in the draft about these decisions. In general, it's better to stick = to the well-trodden paths, to pick algorithms, modes, etc. that are in = common use. In specific there are often reasons to do something on its = own; I can see that a naming system might have reasons for going its own = way. We just need a discussion of them. New code, new algorithms mean = new bugs. If you can write about these decisions, "Most people do X, we = are doing Y, because Z" that helps understand why the decisions are = there. Some can be guessed -- CFB means no CBC padding, and no keying = issues of a stream cipher like CTR mode. Tell us, though. I also really = want to see what's going on and why with the record data encryption ini = 4.3.=20 * There are a number of other features in this that are interestingly = eccentric, but leave me with a raised eyebrow. For example, a resource = record for a VPN. That's interesting, but why? Zone revocation with = proof-of-work -- why, as time and time again proof-of-work proves not to = work? (I refer also to section 9.5 where you recommend pre-generating = proofs of work. Where should these be stored, how should they be = protected?)=20 * The Security considerations need more work. 9.1 discusses the ECDSA = decision, but not other crypto considerations. It refers us to the = relevant papers without really saying more. =20 9.2 points out that unrestricted Unicode names can lead to phishing, but = says nothing more than, "zone administrators must take into account this = attack vector and incorporate rules in order to mitigate it." That's not = helpful. Or perhaps, 'this enables phishing, and it's your problem not = ours, and we're not going to tell you what to do' is the actual security = consideration. The second paragraph essentially says that protocol = prevents taking down phishing site because authoritarian governments are = bad. Um, okay. 9.3 is also pretty scary, a direct quote (and not my paraphrase) is: = "Zone administrators, and for GNS this includes end-users, are required = to responsibly and dilligently [sic] protect their cryptographic keys." = That's a pretty big security consideration that everyone has to do their = own key management and get it 100% right. I do have a question -- what happens if the keys are lost? Does this = mean the domain is essentially gone forever? I can't quite tell. 9.4 says that we need to pick the right DHT, if we pick the wrong one = bad stuff will happen, and if we pick different ones interoperability is = "unlikely." I don't have further things to say about revocations, except that it's = tetchy and brittle, by design. All in all, the security considerations don't leave me thinking this is = anything like a safe protocol. * Despite all my comments above, I think that there's something = interesting in the protocol and the issues can be fixed. Nonetheless, = this is being positioned as an Informational RFC and I think that's a = bad idea. This should either be standards track or continue to be off on = its own and not part of the IETF. The major risk is that this is an alternative to DNS that could lead to = fragmentation of the most basic service on the Internet, naming. Yet it = requires everyone to do key management perfectly and optimizes against = easy management through proof of work and so on. I know I've done silly = things managing my own DNS, and it seems that I'd be unhappily doing = proof-of-work to undo every typo. There are exciting ideas here. I believe that many of the issues I've = brought up have relatively simple solutions. I also believe that it's no = where near ready to deploy or standardize in the IETF. An informational = RFC is not a good idea; this is too big and too experimental for that. = While we in the IETF understand the difference, most people think and = RFC is an RFC is an RFC is an RFC. The belief is that informational RFCs = are standards. (Again, I am a sinner here, too. I have at times gotten = tired of saying "informational" when someone incorrectly says "standard" = and just let them go on.) The agenda for Secdispatch says simply that this item is, "objective: = find a home at IETF" which seems to be presupposing that the decision is = not if it should be in some working group, but which one. I think it's = premature for that. Much more work needs to be done. Jon From nobody Thu Jul 23 20:00:16 2020 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 1E2943A0812; Thu, 23 Jul 2020 20:00:15 -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, 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 Hk6QLQxgbxnj; Thu, 23 Jul 2020 20:00:12 -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 829AC3A0815; Thu, 23 Jul 2020 20:00:12 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id 88so6947797wrh.3; Thu, 23 Jul 2020 20:00:12 -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=X33zKYiTD+gXuKu07yg5/bXy3bEMRLZuUx98OsNlvW4=; b=lZHGmgvL3pKibPhWLU3Si450yXiiKhqZQFs8polzB9jX5279WcDhKVRSq86M78VUob Z99Cq2IwJEouoOzi5/VICnCRLkvQ8TP70qDTYcWL5VLUZ8yEEFo6+YhB/yJgJMNCcwo6 qy5qGiexB+KLrkQ71/3KgcTAE03N6CAeW++ukBuUmCIOW3l1aJL3H6Dcj0GxivSWZaMj qbGONTWOe0iYcOE7b/QnlvM7x5Ic6IIDeTU9pvWga5gqnWYyFQ6d7K4Ora5ZUeytMDLy 36OlMPWYwDJ25WO7aZC4I+MVL3+fCHmNcufXwtlB/SgfXPRlevwFpH9TA+1ZXCCw4PlJ n6qQ== 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=X33zKYiTD+gXuKu07yg5/bXy3bEMRLZuUx98OsNlvW4=; b=WwVHi3RBEE10mJU423YarDjcOnhnIAB+jV8uw1p5FsXMt93mtreJnEBM9eLhvNra6u LeQog2p2kCgWHLiwUPqriWpAur9TlkaoQssUlPSGsqEqg6/A2XHYmAIyHGsrpoM0podT jLTC3AAUlrY5jN060+Ozbg4KUW9Q3Vf1WPWktcPWgZIosW/1fEqqPKklMi2CvBKJ0G8j JNNI6IKySfIwidgwjDEOnhpctNHL+Txqbm3ftdb0tTORSns8TKNdVNcv31gAo6PgA9iN l8IIxsDfnwDYTIV2essOg9srtfdnLTc9IsBuk2b0VMdjywOMXfb5u/9PMJNco19Gxq0E N5cQ== X-Gm-Message-State: AOAM531IZnkFx3wl1gZgGqe4TCilE0LoY7bIy1XW+yAu7d+AzVlyFu+M 65fbR3lvNwuBCuv3v2dIimDWqCDbE1JFtOTdIkx94P6JV9M= X-Google-Smtp-Source: ABdhPJzMhcbMj2VYDUmAYVD/7YS+BpXtYUs8HiCAvMoiL75fqftH2xLcW67rXpquPCU6C1eVH7LgPEekzUp7LX7pPBY= X-Received: by 2002:adf:8024:: with SMTP id 33mr6700016wrk.135.1595559610464; Thu, 23 Jul 2020 20:00:10 -0700 (PDT) MIME-Version: 1.0 References: <31625.1595368614@localhost> <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org> In-Reply-To: <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org> From: Chelsea Komlo Date: Thu, 23 Jul 2020 20:59:57 -0600 Message-ID: To: "secdispatch@ietf.org" Cc: "draft-schanzen-gns@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ccbdaf05ab272b74" Archived-At: Subject: Re: [Secdispatch] GNU Name System 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, 24 Jul 2020 03:00:15 -0000 --000000000000ccbdaf05ab272b74 Content-Type: text/plain; charset="UTF-8" I looked over the GNS draft and have a few comments regarding how the terms "censorship resistance" and "privacy-preserving" are used in the draft. The draft says that "This specification describes a censorship-resistant, privacy-preserving and decentralized name system: The GNU Name System (GNS)." The term "censorship-resistance" here refers to the ability for the system to resist removal of domain names by someone that does not directly control the domain. However, this definition of censorship resistance is in fact quite limited, and doesn't consider other factors like namesquatting, doppelgangers, and other variations of abuse that prevent use of the system. While some of these considerations may be outside the scope of this draft, identifying and describing the implications of these assumptions is important to ensure the system is viable in practice (Section 9.2 currently just says that zone administrators must take abuse into account and develop rules to mitigate it). Further, this draft implicitly assumes that users have access to some censorship-resistant channel (such as Tor) in order to perform lookups. For example, this system will likely be blocked in countries that also can successfully block Tor (such as China without the use of bridges). This draft should clearly specify the assumption that users have access to some censorship-resistant channel. Finally, the draft should explicitly define what "privacy-enhancing" means in the description that "GNS provides a privacy-enhancing alternative to the Domain Name System (DNS)"; i.e, whose privacy is being enhanced, and under what circumstances. The draft describes how user lookups are performed over resource record blocks, which hides a user's lookup within a single block (which seem to contain multiple domains?), but of course the privacy guarantees of this approach are much weaker than systems that provide a single anonymity set for lookups. Chelsea On Thu, Jul 23, 2020 at 7:12 PM Jon Callas wrote: > I've also read through the GNS draft and have some comments: > > * Like Michael Richardson, I have a great love for SDSI and love to see it > used. I think there's a large discussion we should have about what the use > cases can and should be. Alternate roots etc. are an issue, but I'm not > sure it would be so bad to be able to say "ICANN's ietf.org" other than > that it implies there could be someone else's "ietf.org" and that this is > obviously problematic, particularly in how it would enable things like > phishing. I take the opposite take on user experience. Protocol documents > shouldn't be talking UX. Anyway, I think there's a discussion point as to > whether this is a good idea. As much as I would like to be able to say "the > media server I have at home" (for a number of reasons, not the least of > which that that implies I'm not at home"), it's not clear this is really a > good idea in the general case. My security auditor's mind is having a field > day in thinking of cool (meaning confusing or malicious) ways to use this. > Yet, I think it's a discussion point. > > * If this gets put into a working group, I think it needs an IETF name for > it, not GNS and not something that contains "GNU." Other standards have had > their institutional links filed off; SSL became TLS, SSH became SECSH. > Notably, OpenPGP did not, and I think that this was unfortunate. Despite > all good intentions at the time, it's created confusion, and I say that as > an RFC editor and as an implementer. There's nothing wrong with GNUnet's > GNS being a reference implementation of , and my advice to both > the IETF and the GNS people, you'll be happier if you change the protocol > name. > > * There are a number of eccentric things in the protocol now. I don't mean > that as a pejorative -- there are lots of eccentric things I like, SDSI, > for example. I also like CFB mode as well as Twofish. Why, though, are they > here? Are the design decisions leading to these? There's not a lot in the > draft about these decisions. In general, it's better to stick to the > well-trodden paths, to pick algorithms, modes, etc. that are in common use. > In specific there are often reasons to do something on its own; I can see > that a naming system might have reasons for going its own way. We just need > a discussion of them. New code, new algorithms mean new bugs. If you can > write about these decisions, "Most people do X, we are doing Y, because Z" > that helps understand why the decisions are there. Some can be guessed -- > CFB means no CBC padding, and no keying issues of a stream cipher like CTR > mode. Tell us, though. I also really want to see what's going on and why > with the record data encryption ini > 4.3. > > * There are a number of other features in this that are interestingly > eccentric, but leave me with a raised eyebrow. For example, a resource > record for a VPN. That's interesting, but why? Zone revocation with > proof-of-work -- why, as time and time again proof-of-work proves not to > work? (I refer also to section 9.5 where you recommend pre-generating > proofs of work. Where should these be stored, how should they be > protected?) > > * The Security considerations need more work. 9.1 discusses the ECDSA > decision, but not other crypto considerations. It refers us to the relevant > papers without really saying more. > > 9.2 points out that unrestricted Unicode names can lead to phishing, but > says nothing more than, "zone administrators must take into account this > attack vector and incorporate rules in order to mitigate it." That's not > helpful. Or perhaps, 'this enables phishing, and it's your problem not > ours, and we're not going to tell you what to do' is the actual security > consideration. The second paragraph essentially says that protocol prevents > taking down phishing site because authoritarian governments are bad. Um, > okay. > > 9.3 is also pretty scary, a direct quote (and not my paraphrase) is: "Zone > administrators, and for GNS this includes end-users, are required to > responsibly and dilligently [sic] protect their cryptographic keys." That's > a pretty big security consideration that everyone has to do their own key > management and get it 100% right. > > I do have a question -- what happens if the keys are lost? Does this mean > the domain is essentially gone forever? I can't quite tell. > > 9.4 says that we need to pick the right DHT, if we pick the wrong one bad > stuff will happen, and if we pick different ones interoperability is > "unlikely." > > I don't have further things to say about revocations, except that it's > tetchy and brittle, by design. > > All in all, the security considerations don't leave me thinking this is > anything like a safe protocol. > > * Despite all my comments above, I think that there's something > interesting in the protocol and the issues can be fixed. Nonetheless, this > is being positioned as an Informational RFC and I think that's a bad idea. > This should either be standards track or continue to be off on its own and > not part of the IETF. > > The major risk is that this is an alternative to DNS that could lead to > fragmentation of the most basic service on the Internet, naming. Yet it > requires everyone to do key management perfectly and optimizes against easy > management through proof of work and so on. I know I've done silly things > managing my own DNS, and it seems that I'd be unhappily doing proof-of-work > to undo every typo. > > There are exciting ideas here. I believe that many of the issues I've > brought up have relatively simple solutions. I also believe that it's no > where near ready to deploy or standardize in the IETF. An informational RFC > is not a good idea; this is too big and too experimental for that. While we > in the IETF understand the difference, most people think and RFC is an RFC > is an RFC is an RFC. The belief is that informational RFCs are standards. > (Again, I am a sinner here, too. I have at times gotten tired of saying > "informational" when someone incorrectly says "standard" and just let them > go on.) > > The agenda for Secdispatch says simply that this item is, "objective: find > a home at IETF" which seems to be presupposing that the decision is not if > it should be in some working group, but which one. I think it's premature > for that. Much more work needs to be done. > > Jon > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > -- Chelsea H. Komlo | chelseakomlo.com --000000000000ccbdaf05ab272b74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I looked over the GNS draft and have=C2=A0a few comments r= egarding how the terms "censorship resistance" and "privacy-= preserving" are used in the draft.=C2=A0

The draft = says that "This specification describes a censorship-resistant, privac= y-preserving and decentralized name system: The GNU Name System (GNS)."= ; The term "censorship-resistance" here refers to the ability for= the system to resist removal of domain names by someone that does not dire= ctly control the domain.=C2=A0

However, this defin= ition of censorship resistance is in fact quite limited, and doesn't co= nsider other factors like namesquatting, doppelgangers, and other variation= s of abuse that prevent use of the system. While some of these consideratio= ns may be outside the scope of this draft, identifying and describing the i= mplications of these assumptions is important to ensure the system is viabl= e in practice (Section 9.2 currently just says that zone administrators mus= t take abuse into account and develop rules to mitigate it).=C2=A0

Further, this draft implicitly assumes that users have acc= ess to some censorship-resistant channel (such as Tor) in order to perform = lookups.=C2=A0 For example, this system will likely be blocked in countries= that also can successfully block Tor (such as China without the use of bri= dges). This draft should clearly specify the assumption that users have acc= ess to some censorship-resistant channel.

Finally,= the draft should explicitly define what "privacy-enhancing" mean= s in the description that "GNS provides a privacy-enhancing alternativ= e to the Domain Name System (DNS)"; i.e, whose privacy is being enhanc= ed, and under what circumstances. The draft=C2=A0describes how user lookups= are performed over resource record blocks, which hides a user's lookup= within a single block (which seem to contain multiple domains?), but of co= urse the privacy guarantees of this approach are much weaker=C2=A0than syst= ems that provide a single anonymity set for lookups.=C2=A0

Chelsea

On Thu, Jul 23, 2020 at 7:12 PM Jon Callas <jon@callas.org> wrote:
I've also read through the GN= S draft and have some comments:

* Like Michael Richardson, I have a great love for SDSI and love to see it = used. I think there's a large discussion we should have about what the = use cases can and should be. Alternate roots etc. are an issue, but I'm= not sure it would be so bad to be able to say "ICANN's ietf.org" o= ther than that it implies there could be someone else's "ietf.org"= ; and that this is obviously problematic, particularly in how it would enab= le things like phishing. I take the opposite take on user experience. Proto= col documents shouldn't be talking UX. Anyway, I think there's a di= scussion point as to whether this is a good idea. As much as I would like t= o be able to say "the media server I have at home" (for a number = of reasons, not the least of which that that implies I'm not at home&qu= ot;), it's not clear this is really a good idea in the general case. My= security auditor's mind is having a field day in thinking of cool (mea= ning confusing or malicious) ways to use this. Yet, I think it's a disc= ussion point.

* If this gets put into a working group, I think it needs an IETF name for = it, not GNS and not something that contains "GNU." Other standard= s have had their institutional links filed off; SSL became TLS, SSH became = SECSH. Notably, OpenPGP did not, and I think that this was unfortunate. Des= pite all good intentions at the time, it's created confusion, and I say= that as an RFC editor and as an implementer. There's nothing wrong wit= h GNUnet's GNS being a reference implementation of <protocol>, an= d my advice to both the IETF and the GNS people, you'll be happier if y= ou change the protocol name.

* There are a number of eccentric things in the protocol now. I don't m= ean that as a pejorative -- there are lots of eccentric things I like, SDSI= , for example. I also like CFB mode as well as Twofish. Why, though, are th= ey here? Are the design decisions leading to these? There's not a lot i= n the draft about these decisions. In general, it's better to stick to = the well-trodden paths, to pick algorithms, modes, etc. that are in common = use. In specific there are often reasons to do something on its own; I can = see that a naming system might have reasons for going its own way. We just = need a discussion of them. New code, new algorithms mean new bugs. If you c= an write about these decisions, "Most people do X, we are doing Y, bec= ause Z" that helps understand why the decisions are there. Some can be= guessed -- CFB means no CBC padding, and no keying issues of a stream ciph= er like CTR mode. Tell us, though. I also really want to see what's goi= ng on and why with the record data encryption ini
=C2=A0 4.3.

* There are a number of other features in this that are interestingly eccen= tric, but leave me with a raised eyebrow. For example, a resource record fo= r a VPN. That's interesting, but why? Zone revocation with proof-of-wor= k -- why, as time and time again proof-of-work proves not to work? (I refer= also to section 9.5 where you recommend pre-generating proofs of work. Whe= re should these be stored, how should they be protected?)

* The Security considerations need more work. 9.1 discusses the ECDSA decis= ion, but not other crypto considerations. It refers us to the relevant pape= rs without really saying more.=C2=A0

9.2 points out that unrestricted Unicode names can lead to phishing, but sa= ys nothing more than, "zone administrators must take into account this= attack vector and incorporate rules in order to mitigate it." That= 9;s not helpful. Or perhaps, 'this enables phishing, and it's your = problem not ours, and we're not going to tell you what to do' is th= e actual security consideration. The second paragraph essentially says that= protocol prevents taking down phishing site because authoritarian governme= nts are bad. Um, okay.

9.3 is also pretty scary, a direct quote (and not my paraphrase) is: "= Zone administrators, and for GNS this includes end-users, are required to r= esponsibly and dilligently [sic] protect their cryptographic keys." Th= at's a pretty big security consideration that everyone has to do their = own key management and get it 100% right.

I do have a question -- what happens if the keys are lost? Does this mean t= he domain is essentially gone forever? I can't quite tell.

9.4 says that we need to pick the right DHT, if we pick the wrong one bad s= tuff will happen, and if we pick different ones interoperability is "u= nlikely."

I don't have further things to say about revocations, except that it= 9;s tetchy and brittle, by design.

All in all, the security considerations don't leave me thinking this is= anything like a safe protocol.

* Despite all my comments above, I think that there's something interes= ting in the protocol and the issues can be fixed. Nonetheless, this is bein= g positioned as an Informational RFC and I think that's a bad idea. Thi= s should either be standards track or continue to be off on its own and not= part of the IETF.

The major risk is that this is an alternative to DNS that could lead to fra= gmentation of the most basic service on the Internet, naming. Yet it requir= es everyone to do key management perfectly and optimizes against easy manag= ement through proof of work and so on. I know I've done silly things ma= naging my own DNS, and it seems that I'd be unhappily doing proof-of-wo= rk to undo every typo.

There are exciting ideas here. I believe that many of the issues I've b= rought up have relatively simple solutions. I also believe that it's no= where near ready to deploy or standardize in the IETF. An informational RF= C is not a good idea; this is too big and too experimental for that. While = we in the IETF understand the difference, most people think and RFC is an R= FC is an RFC is an RFC. The belief is that informational RFCs are standards= . (Again, I am a sinner here, too. I have at times gotten tired of saying &= quot;informational" when someone incorrectly says "standard"= and just let them go on.)

The agenda for Secdispatch says simply that this item is, "objective: = find a home at IETF" which seems to be presupposing that the decision = is not if it should be in some working group, but which one. I think it'= ;s premature for that. Much more work needs to be done.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jon


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


--
--000000000000ccbdaf05ab272b74-- From nobody Fri Jul 24 06:34:52 2020 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 EE41F3A08A6 for ; Fri, 24 Jul 2020 06:34:51 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 minou8WlkTqN for ; Fri, 24 Jul 2020 06:34:50 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575F53A0AF5 for ; Fri, 24 Jul 2020 06:34:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C2C3E300B6A for ; Fri, 24 Jul 2020 09:34:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5VRIgZnG-2XW for ; Fri, 24 Jul 2020 09:34:46 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 18933300A48; Fri, 24 Jul 2020 09:34:46 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D813475A-AC73-4179-A2D8-25DDCB2C99B5" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Fri, 24 Jul 2020 09:34:47 -0400 In-Reply-To: <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org> Cc: IETF SecDispatch , "draft-schanzen-gns@ietf.org" To: Jon Callas References: <31625.1595368614@localhost> <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Secdispatch] GNU Name System 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, 24 Jul 2020 13:34:52 -0000 --Apple-Mail=_D813475A-AC73-4179-A2D8-25DDCB2C99B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jon: > * There are a number of eccentric things in the protocol now. I don't = mean that as a pejorative -- there are lots of eccentric things I like, = SDSI, for example. I also like CFB mode as well as Twofish. Why, though, = are they here? Are the design decisions leading to these? There's not a = lot in the draft about these decisions. In general, it's better to stick = to the well-trodden paths, to pick algorithms, modes, etc. that are in = common use. In specific there are often reasons to do something on its = own; I can see that a naming system might have reasons for going its own = way. We just need a discussion of them. New code, new algorithms mean = new bugs. If you can write about these decisions, "Most people do X, we = are doing Y, because Z" that helps understand why the decisions are = there. Some can be guessed -- CFB means no CBC padding, and no keying = issues of a stream cipher like CTR mode. Tell us, though. I also really = want to see what's going on and why with the record data encryption ini > 4.3.=20 These days, I ask why an AEAD is not being used. Russ= --Apple-Mail=_D813475A-AC73-4179-A2D8-25DDCB2C99B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Jon:

* There are a number of eccentric things in the protocol now. = I don't mean that as a pejorative -- there are lots of eccentric things = I like, SDSI, for example. I also like CFB mode as well as Twofish. Why, = though, are they here? Are the design decisions leading to these? = There's not a lot in the draft about these decisions. In general, it's = better to stick to the well-trodden paths, to pick algorithms, modes, = etc. that are in common use. In specific there are often reasons to do = something on its own; I can see that a naming system might have reasons = for going its own way. We just need a discussion of them. New code, new = algorithms mean new bugs. If you can write about these decisions, "Most = people do X, we are doing Y, because Z" that helps understand why the = decisions are there. Some can be guessed -- CFB means no CBC padding, = and no keying issues of a stream cipher like CTR mode. Tell us, though. = I also really want to see what's going on and why with the record data = encryption ini
 4.3. 

These = days, I ask why an AEAD is not being used.

Russ
= --Apple-Mail=_D813475A-AC73-4179-A2D8-25DDCB2C99B5-- From nobody Fri Jul 24 13:02:45 2020 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 9D9F73A0B01 for ; Fri, 24 Jul 2020 13:02:43 -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, 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=callas.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 hMKoBs6Ca_rT for ; Fri, 24 Jul 2020 13:02:42 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 4D35A3A0B00 for ; Fri, 24 Jul 2020 13:02:42 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id f7so239665pln.13 for ; Fri, 24 Jul 2020 13:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0HAwko5GFx0iHW2MKeftIya3bQYZ5BarzyyKppVxtAI=; b=IN//Sn2v4SHo8Q9GCBv3mxj/ZvDibLKNsSFy6yuM8GVC/Zu5hp2lYTjw0qUd77KCXz EIGbAbL5B7gRAqMPYuOCMeRNBWqiQ7fS+SNFXqwjAclWENPbC5D7zXGDL+gdCAHHsGJR MoVe1YLQ2BTTqbd+PcyqNzEog9KVldzmd3VJhCIc6pFr2yVHvjpPRIt/dcoSj9NtI+nl 1Zr3Q/mJQpLGgOPJYX8Gm2GIGHBL59HqsFoiFjMWlHa1GN5GLq/M26EVijgMpGGqnFzF eGQ5ytwqdkL8I9uiq43GzWVEpOClw4WkFa6Y1nO0gsA6hnC+TgtxUZSp+7KWPkfO7DeY 1ZnQ== 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=0HAwko5GFx0iHW2MKeftIya3bQYZ5BarzyyKppVxtAI=; b=ROU03ugXnt9kphyeMqqAAxwR9XJ2UfxdBuCzr7WANxdQhlsMJfoGQ3DtJAXvNfr1vv tVVOKixkLwDuUw5ywyL526GH3FTFgjCw5BRnHwg74dospBG49+6KcL3oCrAPbaMOAa6p 7PpuHKD/SKOQailcAJrXQOP9HcmF5G62fLvnF34iZNLQPazlCpFkfjWkEqKjTordvJqe hMRf36DAF6eMZF2uNkD49QjrnYqh3oGAPj7Jia82pSA9WT0otedCdfVYt20aEywpQKcL OY/IfqLUS270VZCjNwLTSnmUfi1VGVWHkUdFv4vZJlujPGTWatblmP1UEymbmekfXbLf /O4g== X-Gm-Message-State: AOAM531NcMdJeou/q/2xGiiDh7+U2fC7o6uiR6narK0A8iF+2NpfAaYD EWrWMUjUbItcDw0+k8N4xiQV5A== X-Google-Smtp-Source: ABdhPJyXJ6pBSe9es1IpldP74SR+5PYAaA+ROO7qL8WIdAgQR97ybtEbx6tH0tsnNvRPCgnXvA1fIg== X-Received: by 2002:a17:90b:3750:: with SMTP id ne16mr6932218pjb.6.1595620961674; Fri, 24 Jul 2020 13:02:41 -0700 (PDT) Received: from ?IPv6:2600:1700:38c4:12bf:9d37:7e34:323c:582b? ([2600:1700:38c4:12bf:9d37:7e34:323c:582b]) by smtp.gmail.com with ESMTPSA id 2sm7289026pfa.110.2020.07.24.13.02.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2020 13:02:41 -0700 (PDT) From: Jon Callas Message-Id: <49DED701-CB78-4228-AFED-1E4421CE5EA7@callas.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_17E40F7C-9C17-41AC-9E02-E95C56622DDD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 24 Jul 2020 13:02:40 -0700 In-Reply-To: Cc: Jon Callas , IETF SecDispatch , "draft-schanzen-gns@ietf.org" To: Russ Housley References: <31625.1595368614@localhost> <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Secdispatch] GNU Name System 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, 24 Jul 2020 20:02:44 -0000 --Apple-Mail=_17E40F7C-9C17-41AC-9E02-E95C56622DDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 24, 2020, at 6:34 AM, Russ Housley = wrote: >=20 > Jon: >=20 >> * There are a number of eccentric things in the protocol now. I don't = mean that as a pejorative -- there are lots of eccentric things I like, = SDSI, for example. I also like CFB mode as well as Twofish. Why, though, = are they here? Are the design decisions leading to these? There's not a = lot in the draft about these decisions. In general, it's better to stick = to the well-trodden paths, to pick algorithms, modes, etc. that are in = common use. In specific there are often reasons to do something on its = own; I can see that a naming system might have reasons for going its own = way. We just need a discussion of them. New code, new algorithms mean = new bugs. If you can write about these decisions, "Most people do X, we = are doing Y, because Z" that helps understand why the decisions are = there. Some can be guessed -- CFB means no CBC padding, and no keying = issues of a stream cipher like CTR mode. Tell us, though. I also really = want to see what's going on and why with the record data encryption ini >> 4.3.=20 >=20 > These days, I ask why an AEAD is not being used. That's why I framed it in terms of CBC or CTR.=20 Jon --Apple-Mail=_17E40F7C-9C17-41AC-9E02-E95C56622DDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Jul 24, 2020, at 6:34 AM, Russ Housley <housley@vigilsec.com> wrote:

Jon:

* There are a = number of eccentric things in the protocol now. I don't mean that as a = pejorative -- there are lots of eccentric things I like, SDSI, for = example. I also like CFB mode as well as Twofish. Why, though, are they = here? Are the design decisions leading to these? There's not a lot in = the draft about these decisions. In general, it's better to stick to the = well-trodden paths, to pick algorithms, modes, etc. that are in common = use. In specific there are often reasons to do something on its own; I = can see that a naming system might have reasons for going its own way. = We just need a discussion of them. New code, new algorithms mean new = bugs. If you can write about these decisions, "Most people do X, we are = doing Y, because Z" that helps understand why the decisions are there. = Some can be guessed -- CFB means no CBC padding, and no keying issues of = a stream cipher like CTR mode. Tell us, though. I also really want to = see what's going on and why with the record data encryption = ini
 4.3. 

These = days, I ask why an AEAD is not being = used.

That's why I framed it in terms of CBC or = CTR. 

= Jon


= --Apple-Mail=_17E40F7C-9C17-41AC-9E02-E95C56622DDD-- From nobody Fri Jul 24 17:48:51 2020 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 D875D3A0E37 for ; Fri, 24 Jul 2020 17:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 bFB0iGq8a6QE for ; Fri, 24 Jul 2020 17:48:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C382A3A0E41 for ; Fri, 24 Jul 2020 17:48:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DB7A8389F1 for ; Fri, 24 Jul 2020 20:28:17 -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 eLnLNEvfo4QX for ; Fri, 24 Jul 2020 20:28:17 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1A9F1389EC for ; Fri, 24 Jul 2020 20:28:17 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 330EB42 for ; Fri, 24 Jul 2020 20:48:45 -0400 (EDT) To: secdispatch@ietf.org References: From: Michael Richardson Message-ID: <561fe6e8-ff15-df9e-d495-37dbd530a37e@sandelman.ca> Date: Fri, 24 Jul 2020 20:48:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Secdispatch] SFrame: new proposal for E2EE in video conferencing 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, 25 Jul 2020 00:48:50 -0000 On 2020-07-22 7:07 p.m., Emad Omara wrote: > Hi Security dispatch, > > I will present the SFrame > proposal to the > Dispatch  on > Monday and discuss the possible next steps for this work. This might be > interesting for the folks here, so please feel free to provide feedback > and join the discussion on Monday. Can it work within EBML (RFC8794, just out), based Matroska? From nobody Fri Jul 24 19:42:15 2020 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 DB5ED3A1125 for ; Fri, 24 Jul 2020 19:42:14 -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=ipv-sx.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 CD9tNqSiKA0v for ; Fri, 24 Jul 2020 19:42:13 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 42F5A3A1124 for ; Fri, 24 Jul 2020 19:42:13 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id a32so8347497qtb.5 for ; Fri, 24 Jul 2020 19:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gM/xnjFkt/sJeLIIZJntkM76yWe3rB4Zcc6u/cG6VXM=; b=dJ/Ofu2A1Sd8bUPTNgYm4IrHsCherdnJPp+soNfruAS0Zp44+wbmrKELMZfEynvM/g 4qgt8U3MUXZWy9B1giL6EcGNKDO5X4CKodkjpLMkp9d7hNFD2kyqUpjoIomg+bTYF29B 3qTHxeHOG7dkYIF8A26Bs613Hi9cIbZWn4sdbM5GSYFwAeovSr6ej0SnDegucEYiGVP+ Qvt3HFp4RvBV9OAz2BKuLZ7lweG36VB6BPgZwKzwqh12Pw1DwWvqT38Vmkg8kalL4MK2 bbGeqYRu9rJX9/4UsrhpOWO0zmDkG4sZw1VmUHVUsIzvtCZ46RLnMK0xeWdJwgVVORxF jdnQ== 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=gM/xnjFkt/sJeLIIZJntkM76yWe3rB4Zcc6u/cG6VXM=; b=S1Cs88sC+MFDxo0RmHULkzPfbD9d0tMKHcu7ztCZnxloCWWJqFWyY1UbkgySrlUNRa +NCsZpLGL7seIRbbdhxJjhqKJrLgApHJ9AiYyei9uyDENNqDAGWMnjDW22FZwdLB0HhY 70f/3cn92l/VvnV3WPQxGEPwEORjMmYbLW1rCK/6E4CnduRNQLeDF0+5+qaNpbib9lqS IrUUxG/nY0dL5jSlJvH9vstzsmhWaZy7BBmKKvylxDqppa51w1AIfBmmATg1LRzw19C1 0dErYIMbSha7rFluoEF4zk93vZd1n3RarcV1wRIDCEuGgCtQ6W28r8+bAY9QjSGikeDh +cFw== X-Gm-Message-State: AOAM533TESGMfNLjO722O9ITfBtDaLkUKUvGe6/UCwfP7GPoFybj57+B Fl6mfKTCQ7E96eMQp+nHMO9TKjqofmjzGs39LGvtWQ== X-Google-Smtp-Source: ABdhPJyGIv1llwHPZrPbxzpF4SizLthw7gf1dHdg15e2GWgkinKzyQzmd7UuxyAEf6IZFrhahW47KeBVyS13dctMalI= X-Received: by 2002:ac8:7454:: with SMTP id h20mr11967527qtr.84.1595644932002; Fri, 24 Jul 2020 19:42:12 -0700 (PDT) MIME-Version: 1.0 References: <561fe6e8-ff15-df9e-d495-37dbd530a37e@sandelman.ca> In-Reply-To: <561fe6e8-ff15-df9e-d495-37dbd530a37e@sandelman.ca> From: Richard Barnes Date: Fri, 24 Jul 2020 22:42:01 -0400 Message-ID: To: Michael Richardson Cc: secdispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000005c27aa05ab3b0945" Archived-At: Subject: Re: [Secdispatch] SFrame: new proposal for E2EE in video conferencing 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, 25 Jul 2020 02:42:15 -0000 --0000000000005c27aa05ab3b0945 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 24, 2020 at 20:48 Michael Richardson wrote: > On 2020-07-22 7:07 p.m., Emad Omara wrote: > > Hi Security dispatch, > > > > I will present the SFrame > > proposal to the > > Dispatch on > > Monday and discuss the possible next steps for this work. This might be > > interesting for the folks here, so please feel free to provide feedback > > and join the discussion on Monday. > > Can it work within EBML (RFC8794, just out), based Matroska? Short answer, no. Longer answer, real time not files. =E2=80=94RLB > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000005c27aa05ab3b0945 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 24, 2020 at 20:48 Michael Richardson <= ;mcr+ietf@sandelman.ca> w= rote:
On 20= 20-07-22 7:07 p.m., Emad Omara wrote:
> Hi Security dispatch,
>
> I will present the SFrame
> <https://tools.ietf.org/html/draft-omara-s= frame-00> proposal to the
> Dispatch <https://datatracker.ietf.= org/meeting/108/session/dispatch>=C2=A0on
> Monday and discuss the possible next steps for this work. This might b= e
> interesting=C2=A0for the folks here, so please feel free to provide fe= edback
> and join the discussion on Monday.

Can it work within EBML (RFC8794, just out), based Matroska?

Short answer, no.=C2=A0

Longer answer, real time not fi= les.=C2=A0

=E2=80=94RLB<= /div>





_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000005c27aa05ab3b0945-- From nobody Sat Jul 25 06:09:30 2020 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 2B2283A0920 for ; Sat, 25 Jul 2020 06:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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=posteo.de 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 1G6cZCafUjYf for ; Sat, 25 Jul 2020 06:09:26 -0700 (PDT) Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) (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 6F6963A10C5 for ; Sat, 25 Jul 2020 06:09:25 -0700 (PDT) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id E4C1F2400FB for ; Sat, 25 Jul 2020 15:09:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1595682562; bh=EsSHMQpNZSi00OJEedKDyw8kTNpyjbG73eIjfiWOwP8=; h=From:Subject:Date:Cc:To:From; b=TCctC5IrIwRtAmft9xFO8or1ZL858J3N279MaEs1+4JdD7jmhMMFBGPIVIZCht2vx FBxPD6YoDikDTvaTUStMORBWu5I+lbZMMhYmHaBr5obZ7SuDXF9il/prQkTEwn7sS4 /2Ece2kJgva3adn5MTOWQ2fLtDY/nCeyOwvX8PsiOLeBO3/T2mdpH9VYfD7+OIzRyO SuCF5RuCc+qFl3J+2oCSRsRurp3LJwRrlV1f+2oxPc1kz5bZklCpRpQriZxO2tjCUL 10oZjv0wdco5Be70Uv5P/8PkrOqcvJ0bgpxwWXEFyfx9XON26Vhmoho0FkTJzaK4e6 6NEZvolsfb/rg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4BDRH56QKyz6tmG; Sat, 25 Jul 2020 15:09:21 +0200 (CEST) From: "Schanzenbach, Martin" Message-Id: <2F442F72-E779-464A-B8D9-2AD76313F6C6@posteo.de> Content-Type: multipart/signed; boundary="Apple-Mail=_35971949-20B2-473D-B5FD-3BE0CA65D782"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 25 Jul 2020 15:09:21 +0200 In-Reply-To: <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org> Cc: "secdispatch@ietf.org" , "draft-schanzen-gns@ietf.org" To: Jon Callas References: <31625.1595368614@localhost> <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Secdispatch] GNU Name System 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, 25 Jul 2020 13:09:29 -0000 --Apple-Mail=_35971949-20B2-473D-B5FD-3BE0CA65D782 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jon! > On 24. Jul 2020, at 03:12, Jon Callas wrote: >=20 > I've also read through the GNS draft and have some comments: >=20 > * Like Michael Richardson, I have a great love for SDSI and love to = see it used. I think there's a large discussion we should have about = what the use cases can and should be. Alternate roots etc. are an issue, = but I'm not sure it would be so bad to be able to say "ICANN's ietf.org" = other than that it implies there could be someone else's "ietf.org" and = that this is obviously problematic, particularly in how it would enable = things like phishing. I take the opposite take on user experience. = Protocol documents shouldn't be talking UX. Anyway, I think there's a = discussion point as to whether this is a good idea. As much as I would = like to be able to say "the media server I have at home" (for a number = of reasons, not the least of which that that implies I'm not at home"), = it's not clear this is really a good idea in the general case. My = security auditor's mind is having a field day in thinking of cool = (meaning confusing or malicious) ways to use this. Yet, I think it's a = discussion point. Good point. I think I agree that the UX / Governance shouldn't be = focussed too much in the protocol spec. I guess we anticipated questions = regarding this point too much here. >=20 > * If this gets put into a working group, I think it needs an IETF name = for it, not GNS and not something that contains "GNU." Other standards = have had their institutional links filed off; SSL became TLS, SSH became = SECSH. Notably, OpenPGP did not, and I think that this was unfortunate. = Despite all good intentions at the time, it's created confusion, and I = say that as an RFC editor and as an implementer. There's nothing wrong = with GNUnet's GNS being a reference implementation of , and my = advice to both the IETF and the GNS people, you'll be happier if you = change the protocol name. >=20 Interesting point. I think this is worth discussing, though. > * There are a number of eccentric things in the protocol now. I don't = mean that as a pejorative -- there are lots of eccentric things I like, = SDSI, for example. I also like CFB mode as well as Twofish. Why, though, = are they here? Are the design decisions leading to these? There's not a = lot in the draft about these decisions. In general, it's better to stick = to the well-trodden paths, to pick algorithms, modes, etc. that are in = common use. In specific there are often reasons to do something on its = own; I can see that a naming system might have reasons for going its own = way. We just need a discussion of them. New code, new algorithms mean = new bugs. If you can write about these decisions, "Most people do X, we = are doing Y, because Z" that helps understand why the decisions are = there. Some can be guessed -- CFB means no CBC padding, and no keying = issues of a stream cipher like CTR mode. Tell us, though. I also really = want to see what's going on and why with the record data encryption ini = 4.3. >=20 I think it is important to put the protocol draft a bit into context. It = currently not only serves as a proposal for an alternative/new name system, but also as a documentation of our current implementation. GNUnet's crypto has grown organically over time and parts are quite old. = We have received this feedback regarding CFB before and are already discussing a better alternative. In general I agree that the draft proposes very concrete schemes "out of = nowhere". We hope to address this by moving towards more crypto agility. This means restructuring the draft a bit and = formalising the requirements (of the crypto) better. > * There are a number of other features in this that are interestingly = eccentric, but leave me with a raised eyebrow. For example, a resource = record for a VPN. That's interesting, but why? Zone revocation with = proof-of-work -- why, as time and time again proof-of-work proves not to = work? (I refer also to section 9.5 where you recommend pre-generating = proofs of work. Where should these be stored, how should they be = protected?) This is likely also a result of the facts that it documents the current = implementation and with it also some application use cases. VPN is a specific application in GNUnet used to establish private = tunnels between endpoints through the network. It is always a question which (sub)set of already implemented record = types to include in the document and which record types to simply "register" at the type registry. This, however, would require = to settle on the registry first. (a section which, coincidentally, = nobody tripped over until now ;) Alternatives and improvements to our revocation are welcome in any = direction. In fact, we significantly reworked the revocation as part of = the writing. I guess we can agree that revocation should be addressed by the protocol = (?) so we are happy to consider alternative ideas. Of course, we can explain in more detail why we _currently_ use the = PoW-based approach better. >=20 > * The Security considerations need more work. 9.1 discusses the ECDSA = decision, but not other crypto considerations. It refers us to the = relevant papers without really saying more. >=20 > 9.2 points out that unrestricted Unicode names can lead to phishing, = but says nothing more than, "zone administrators must take into account = this attack vector and incorporate rules in order to mitigate it." = That's not helpful. Or perhaps, 'this enables phishing, and it's your = problem not ours, and we're not going to tell you what to do' is the = actual security consideration. The second paragraph essentially says = that protocol prevents taking down phishing site because authoritarian = governments are bad. Um, okay. Well the last point is a reference to governance. Maybe it should be = phrased in this context as well. >=20 > 9.3 is also pretty scary, a direct quote (and not my paraphrase) is: = "Zone administrators, and for GNS this includes end-users, are required = to responsibly and dilligently [sic] protect their cryptographic keys." = That's a pretty big security consideration that everyone has to do their = own key management and get it 100% right. >=20 > I do have a question -- what happens if the keys are lost? Does this = mean the domain is essentially gone forever? I can't quite tell. As a "pure" user, you are not required to manage any private keys. As a = zone admin (which any end-user can be) you do. Protecting your keys is = not in scope. Think: key management in DNSSEC for zone admins. Pretty sure DNSSEC does = not tell you _how_ to secure your keys. "Rebuilding" a zone using a new key is similar to how you would do in = DNSSEC. If the key of a zone is lost which is a "root" zone for a user, the same applies (same as loosing DNSSEC key for a TLD). >=20 > 9.4 says that we need to pick the right DHT, if we pick the wrong one = bad stuff will happen, and if we pick different ones interoperability is = "unlikely." This is also a point brought to us before. Of course, ideally we would = have specified the DHT first, and then GNS. Alas, our funding funds the GNS spec at this time. The point we are trying to make is that the underlying stack (obviously) = affects GNS's security properties. Similar to how DNS vs "DNS over TLS" vs "DNS over HTTPS" have very = different security properties. Bad things can happen if you run DNS over UDP w/o TLS. Other bad things = may happen with DNS over HTTPS. Depends on the attacker model. You also cannot expect to resolve the same names if you run DNS in a = private internal network when compared to the Internet DNS. (this partially brings us back to governance of course) >=20 > I don't have further things to say about revocations, except that it's = tetchy and brittle, by design. >=20 > All in all, the security considerations don't leave me thinking this = is anything like a safe protocol. >=20 > * Despite all my comments above, I think that there's something = interesting in the protocol and the issues can be fixed. Nonetheless, = this is being positioned as an Informational RFC and I think that's a = bad idea. This should either be standards track or continue to be off on = its own and not part of the IETF. >=20 > The major risk is that this is an alternative to DNS that could lead = to fragmentation of the most basic service on the Internet, naming. Yet = it requires everyone to do key management perfectly and optimizes = against easy management through proof of work and so on. I know I've = done silly things managing my own DNS, and it seems that I'd be = unhappily doing proof-of-work to undo every typo. >=20 > There are exciting ideas here. I believe that many of the issues I've = brought up have relatively simple solutions. I also believe that it's no = where near ready to deploy or standardize in the IETF. An informational = RFC is not a good idea; this is too big and too experimental for that. = While we in the IETF understand the difference, most people think and = RFC is an RFC is an RFC is an RFC. The belief is that informational RFCs = are standards. (Again, I am a sinner here, too. I have at times gotten = tired of saying "informational" when someone incorrectly says "standard" = and just let them go on.) >=20 > The agenda for Secdispatch says simply that this item is, "objective: = find a home at IETF" which seems to be presupposing that the decision is = not if it should be in some working group, but which one. I think it's = premature for that. Much more work needs to be done. Well our primary objective is not to "push this into IETF" but to = collect feedback on the protocol and the specification with technical = experts outside of academia and GNUnet (which was the primary audience = until now). I think I may have copied the email subject (from which that = text is taken) from another email sent to this ML in the past. It would be great if any existing WG finds this interesting and could = imagine adopting it for improvement, of course. Thank you for the detailed feedback! I did not get around to addressing = all of this here, but it is very helpful and we will certainly update = our draft using it! Best Martin >=20 > Jon >=20 >=20 --Apple-Mail=_35971949-20B2-473D-B5FD-3BE0CA65D782 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPREGPBD5jRS9JNFHCwmY74b1m2oFAl8cLwEACgkQCwmY74b1 m2pjghAApOK61vOZFv8i5hXsrggm675GiZbIAofM489azj0zHk/LQQpchP8EHxtU nSyefOOcBbzFKipyaKwc5iaTthSNfdKxbYe2UDDzDk5XXYqgSIrjCUN1xmQvdx2F iG75jWPIw56MYVMnvXczhRdj0fNFwU7PvKKg+Bh7cnezRYVE+NH7nEyjgt/Y4RZk JHNeOj5NIbE/rRtZUyPurfCTw48Uk2RdyWo9ZEtnqtEr2uP+a4Z0kwQ2F3Vzmx6e D95YAPaXIYVG+wHtYpMB+1MtjhKULtU61vRfxFcAXONrd5STVo+EaLPNeTlqjBLZ UtBeQcXWsksiaubGWUIGgi4qY5xA9yG0zlKEF1RfT3zWULWRJtac9RWojiOVYok1 W2wnwybJquST+PyyjMVvchzbsXJudSbglyF8yriku5VF8pm1J5wrBpxUlgZfEIrb xkC4g+ld0a8sWAVPOqQfZeunA6NuunCkLHRBS8htlQtIS56srPw4DAR8sQuk7f3B GI4UOahR6Q9KJLbflb5RwqCXMP6zE70aIFkHYvsndlZvZo7Twf5El82VjcMz34vS hqrXZAoLs33WGlvliA5KMgpV/QGI303bJjcFwP47WL+l3NlsXq/ZLpvhe0CwV6cz J3XTvX+lsKBvrtZkNI3z6U6XS5URv/MgZMIdbAv4Y2HRjWJhmzU= =sdxa -----END PGP SIGNATURE----- --Apple-Mail=_35971949-20B2-473D-B5FD-3BE0CA65D782-- From nobody Sun Jul 26 02:38:33 2020 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 3C3433A0D09; Sun, 26 Jul 2020 02:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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 IzevWlWgXMDS; Sun, 26 Jul 2020 02:38:30 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10040.outbound.protection.outlook.com [40.107.1.40]) (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 9CB393A0D08; Sun, 26 Jul 2020 02:38:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P4OkFVNk3jylhPAh26wvMwHNSjPJoWea+cIOavOfLO8AUDS6+ouGL8tf8qS+f8n2ksU+xRkjKDjbyKXa8o9c4FJal7AAl24OnkDFAYmENXzLsEltEgOcJXvHl+h+RFRpDk8NOTyyd2vi5PQW3domPKp0FiIgxJVAkpFhoDKjCIVs/S6JZXhuOQAAHQU/LQ11i3ak3ieG8Bo/tAt5mf0fY+m4N30hT1V861QquTqnfLmkTlADDepSRjTKX+Kwa118jSd+4OCVVYkwy8cMggIfB+fK5H8WQzPW/3wpe6hhYwxW1gKolRb9ObN62dLOX/4vSkCjPDF7+l1bBkjzZ42N9w== 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=cXhXbdU0ELLKyjT4CwtMPV71iz1M17E1v0xTv1CbbxM=; b=EfM6yzDJOl+0kkXf6hJMZQIxCyzaDXQLEY9bSDqwika8kVivOAJlZea9Qc+QaN9fZDnU27CRj3NcIWh0vv79RXTzoxCpqFM9mkgDE/F6ZBHZO52z4hX7Vea9Gd62uuPVVQmX1nJBYOu2q6rmoTdpQQyU8M1o8oAjYHENmCJOHun0P+0+rVuF0Etx7FWSinxzkK7CZ7TM82PJFsacvssf1UmAYd7rr5S20XdnNvGGgEuA/TXrDW9E3a6z6URQIk7d8lg+VDH200V0lXjlm7wAIK/wm+MBrPe2EIiYK1TUZaAOsNIKpwSNesvBXNyK6aTE97WpskraQ0KT3NydaMTkXQ== 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=cXhXbdU0ELLKyjT4CwtMPV71iz1M17E1v0xTv1CbbxM=; b=T1NHxCWxDHCjRGhcF6yuEKrDFfgGiRGhX3ghhS86sozyKMcXENZagbLXELpocjPLe74pmX38N1gvSodeWb7xpkhMld0/MtB8apPnkI9Qw1yGHe74x/a5khHBjlaO9ffargberGWcsf8El5X2lYGxjbSFd6WilDQCScWj6HCRBTU= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR07MB4153.eurprd07.prod.outlook.com (2603:10a6:7:9d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.11; Sun, 26 Jul 2020 09:38:26 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3239.013; Sun, 26 Jul 2020 09:38:26 +0000 From: Francesca Palombini To: "secdispatch@ietf.org" CC: "secdispatch-chairs@ietf.org" Thread-Topic: Looking for minute takers and jabber scribe Thread-Index: AQHWYzCCzfeOBgp5aEOc49iEH+SSQg== Date: Sun, 26 Jul 2020 09:38:26 +0000 Message-ID: <1EDC515F-5927-4433-B5CA-DD904A0A16C6@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.12.182.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 48614b0d-86ab-43fc-fa0c-08d83147a577 x-ms-traffictypediagnostic: HE1PR07MB4153: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wvV8dPYPJBHCzxlrr7u3HahhjER7T4Ze8I4jsquYfAVlmVqprk9gnkSkazOYS2tTion/GmUUpTPXm01AxW6fI8cOUORsBAjIkE3z6hs1z9NV8IzeaHT2CnfT20/W1+knYDT5b6M2mzwi52xXIYTeFOuDpMzYUa4PqwOzyNRFeWbF87w4Ee4ppc8m9e7VBhlPyG8Og6OrUeryzMwMyb/EisbXZ4Fi703qH81c7iNTFpCKSejSGUKPYrSJQlD7Yg4rkPieKtnf+FqF8iwia9oVw/yZb8mJVpf/aLX/HJb2QbX3dab3InCtiFBvySQQ7W0IMP2YR+39mVD886xHljRG7w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(346002)(39860400002)(376002)(366004)(66446008)(316002)(86362001)(66556008)(64756008)(6512007)(44832011)(2616005)(33656002)(66476007)(36756003)(558084003)(5660300002)(8936002)(4326008)(26005)(6916009)(71200400001)(2906002)(8676002)(76116006)(66946007)(478600001)(6506007)(450100002)(6486002)(91956017)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0RBSTC/DfIE8TBGkU7t6GdzMf4YjLARddl0bRh74ZGoD1kUdJecCP8KfBDNJutglNY0HjkZr6X2Nq5MVzTzmQjrb9RLSqWkCI4wMhg8FmQl/DD7HWINERznmCWXTaM1Mei7cSwqTaI19MiL3HUCUjRhWCMvrm6YT2SuIya1VH3Guj89G3l8snMuY+6Wsi3Ye6cKOubR4ikiH3e+g98ujUJwSaK+u5dOqsdHdSQ9onoPNZULqnxFmaPZr3JLgj5Lnjvfd98F1JZuzzgoR+Tg6cvX35COPfsQHrL16ISenlwE5nUvt/CXWtBV42JyxI6gcKdcbSELKdFVY+Mkx7P2HyuIfPJJ0Up4miztC90HrFHvaRoodsGzSSaDbO+6b6Ild83dxIDAHePYyehp7dzdqZuFo0fqGCTGVJVieeFYpUxtFLreTwsRpYfIQz+NHRYkEl4YwauJ0TH3t7S+K7UqTBD9BfhF7Akt+k2K5Aww2a4kpset0qQLSNXFrjA6BrZwFK1XUf0XDKQyO6hm6XJF4wRy3GB0iQyFD0012Bv2xSdWSHic4oy8PC4Ff3UTQqcJtX4pV+tz5zwMKj/xzyTjkmOAXJ5Po+vh+g3SHKcEodOHz/abCRVJdaGN6qQ/NqCLq6cQ8/21NU1Lt0XRQIKN3xQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 48614b0d-86ab-43fc-fa0c-08d83147a577 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2020 09:38:26.0318 (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: cGslzubEPAOfHcNxdYgOszspal/KdLqbb+WocHL36bNb0VLxfxN40oEL0CL0qwXW1xxGBHwaTKmJGrZkrPabc9EhpYmrF2OOLmKI8KnKRqd676/BM2MUL7pyHjvjZ5Er X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4153 Archived-At: Subject: [Secdispatch] Looking for minute takers and jabber scribe X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 09:38:31 -0000 IEhpLA0KDQpXZSBhcmUgc3RpbGwgbG9va2luZyBmb3Igdm9sdW50ZWVycyBmb3IgamFiYmVyIHNj cmliZSBhbmQgbWludXRlIHRha2VycyAoYXQgbGVhc3QgMSwgYnV0IGhvcGVmdWxseSAyKSBmb3Ig b3VyIHNlc3Npb24gb24gVGh1cnNkYXksIEp1bHkgMzAgMjAyMCwgMTE6MDAtMTI6NDAgVVRDLiAN Cg0KTWFueSB0aGFua3MgaW4gYWR2YW5jZSB0byBhbnlib2R5IHdobyB3aWxsIHN0ZXAgdXAhDQpG cmFuY2VzY2ENCg0K From nobody Wed Jul 29 08:22:49 2020 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 66DC33A0C50; Wed, 29 Jul 2020 08:22:48 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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=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 Mv2W-f8giFGv; Wed, 29 Jul 2020 08:22:46 -0700 (PDT) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (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 653FB3A0C4A; Wed, 29 Jul 2020 08:22:45 -0700 (PDT) Received: by mail-oi1-f181.google.com with SMTP id k22so21062825oib.0; Wed, 29 Jul 2020 08:22:45 -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=Mr40i66UCktCJo+VWijBOq4XSC+g1Ln4LvdN+u3LWx0=; b=fsJ+V4yYykTSgOc2he1dZgaDlyuWaZtCGfMzlBEVwST0fmS6CGX5FLXcFm8Uz1XwTh d2z8txa7Bz1mP4BFXt39Flvz/oGrELVeIVC1mwb2H3d6zPK0pO6XCYgkzLAM/j0Nkw9J LatqS/G/qRmRspBoLthVRnvEcR/EikDPMnDZiFUNzlWr3GhEQSHj4gw44hYJDjhfkP5b eYCXE8+WXTLsjFOy6jJDMgrqJHUwWa1XWhUWITKaoKGseS1cocc3snEDFcVmFS10wZ0g JlyUQ94aESci5rfyrTdgArRpyIp5CqizuP/XiTfRYIarSpiyfqG90hRvDGiWg1WbHHlC HCGA== X-Gm-Message-State: AOAM532GyDrEuga3upKbZmZzSPe/KZnIkAWMOzw2EhCZHCZuy5cuddOr yH+sYHxtlYEY/WpiUgPprY1ZcXEjwev8YYCqYx5WY3doN0s= X-Google-Smtp-Source: ABdhPJyMmQgQks2TF/CCCCyTCFohfrEoL+FQskarjAGm0tYjMz3Qn8oGu+/OyD2ogb0yUNZdrKzBHPXXfNef2eEstxE= X-Received: by 2002:aca:fcd2:: with SMTP id a201mr6040989oii.166.1596036164439; Wed, 29 Jul 2020 08:22:44 -0700 (PDT) MIME-Version: 1.0 References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> <19924.1595432391@localhost> <995a966c-bd9e-ca25-18a2-1e90b3c530e7@primekey.com> <19403.1595518388@localhost> <15413.1595532896@localhost> In-Reply-To: <15413.1595532896@localhost> From: Phillip Hallam-Baker Date: Wed, 29 Jul 2020 11:22:33 -0400 Message-ID: To: Michael Richardson Cc: SPASM , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000a152e705ab962038" Archived-At: Subject: Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch 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, 29 Jul 2020 15:22:48 -0000 --000000000000a152e705ab962038 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 23, 2020 at 3:35 PM Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > Just thought I would weigh in with some points. > > Thank you. > I don't quite understand how XKMS can be used to provision private keys, > but > I do agree that I do agree that the rest is a mess > There is a key provisioning protocol in the spec. > My goal is to just collect and describe the methods. > > I originally started with the idea of being prescriptive about the shape of > of the PKI that is used to provision the certificates. I am pulling back > from the prescriptive part, and instead I intend to just describe the > different considerations, giving them names. > > > There are no good choices for creating key pairs. All have drawbacks. > > > * Any key generated by the manufacturer can leak at multiple points > in the > > supply chain. But it can be welded to the device in such a way that > it > > cannot be extracted without extreme persuasion. > > > * Any key that is generated by the device can also be compromised > through > > an intentional side channel or by weak key generation. And once > generated > > can usually be extracted. > > I am interested in why you say that the key can be welded into place > by the factory, but a key generated internally can't be welded in place in > the same way. > I have been through a bunch of designs where the manufacturer key can be replaced by a user one. I don't think they actually add value. What I am proposing for a threshold co-processor to address SPECTRE, ROWHAMMER etc. attacks is the following: Secret key key installed during manufacture are ka, ks Operation Threshold Agree: P, a, c -> (a.ka+c).P Operation Threshold Sign: Rin, a, c, m1, m2 -> r.P, r + H(m1 || (r.P+Rin) || m2). (a.ks+c) Such a co-processor should always offer operations on (a.k+c) rather than just k. This allows the platform to make use of Lagrange/Shamir sharing approaches and to construct as many virtual application keys as are needed . Changing the manufacturer key just introduces a point of possible failure without really achieving anything because the application should always be adding in its own mix-in. Unless one is prohibited from using the manufacturer key because of a doctrine, I can't see why it would be a requirement. The manufacturer key should never be used except in the process of application key provisioning. And there the benefit of being able to print a QR Code on the device that has real meaning probably outweighs that concern. Doctrines can be a useful tool but we cannot develop specification responsive to classified doctrines in an open process. > > So none of the solutions are good. What should we do? The best > answer is to > > do all of them and combine the keys using threshold techniques. That > allows > > us to get a key that combines all the properties we want and is only > > vulnerable if there are multiple failures. > > > The math is explained in this draft: > > https://tools.ietf.org/id/draft-hallambaker-threshold-02.html > > I would like to include this in my list, but we have a chicken and egg > situation on it. > There is a NIST program looking at threshold. It is certainly an option even if IETF isn't supporting it right now. --000000000000a152e705ab962038 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=

= On Thu, Jul 23, 2020 at 3:35 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=C2=A0 =C2=A0 > Just thought I would weigh in with some points.

Thank you.
I don't quite understand how XKMS can be used to provision private keys= , but
I do agree that I do agree that the rest is a mess
There is= a key provisioning protocol in the spec.



=C2=A0
My goal is to just collect and describe the methods.

I originally started with the idea of being prescriptive about the shape of=
of the PKI that is used to provision the certificates.=C2=A0 I am pulling b= ack
from the prescriptive part, and instead I intend to just describe the
different considerations, giving them names.

=C2=A0 =C2=A0 > There are no good choices for creating key pairs. All ha= ve drawbacks.

=C2=A0 =C2=A0 > * Any key generated by the manufacturer can leak at mult= iple points in the
=C2=A0 =C2=A0 > supply chain. But it can be welded to the device in such= a way that it
=C2=A0 =C2=A0 > cannot be extracted without extreme persuasion.

=C2=A0 =C2=A0 > * Any key that is generated by the device can also be co= mpromised through
=C2=A0 =C2=A0 > an intentional side channel or by weak key generation. A= nd once generated
=C2=A0 =C2=A0 > can usually be extracted.

I am interested in why you say that the key can be welded into place
by the factory, but a key generated internally can't be welded in place= in
the same way.

I have been through a bunch of designs where = the manufacturer key can be replaced by a user one. I don't think they = actually add value.

What = I am proposing for a threshold co-processor to address SPECTRE, ROWHAMMER e= tc. attacks is the following:

Secret key key installed during manufacture are ka, ks

Operation Threshold Agree: P, a, c ->= (a.ka+c).P
Operation Thr= eshold=C2=A0Sign: Rin, a, c, m1, m2 -> r.P,=C2=A0 r + H(m1 ||=C2=A0 (r.P= +Rin) || m2). (a.ks+c)

Such a co-processor should always offer operations o= n (a.k+c) rather than just k. This allows the platform to make use of Lagra= nge/Shamir sharing approaches and to construct as many virtual application = keys as are needed .

Changing the manufacturer key just introduces a point = of possible failure without really achieving anything because the applicati= on should always be adding in its own mix-in.

Unless one is prohibited from using the manufacturer k= ey because of a doctrine, I can't see why it would be a requirement. Th= e manufacturer key should never be used except in the process of applicatio= n key provisioning. And there the benefit of being able to print a QR Code = on the device that has real meaning probably outweighs that concern.
<= /div>
Doctrines can be a usefu= l tool but we cannot develop specification responsive to classified doctrin= es in an open process.


=C2=A0
=C2=A0 =C2=A0 > So none of the solutions are good. What should we do? Th= e best answer is to
=C2=A0 =C2=A0 > do all of them and combine the keys using threshold tech= niques. That allows
=C2=A0 =C2=A0 > us to get a key that combines all the properties we want= and is only
=C2=A0 =C2=A0 > vulnerable if there are multiple failures.

=C2=A0 =C2=A0 > The math is explained in this draft:
=C2=A0 =C2=A0 > https://tools.ietf.o= rg/id/draft-hallambaker-threshold-02.html

I would like to include this in my list, but we have a chicken and egg
situation on it.

There is a NIST program looking at threshold. I= t is certainly an option even if IETF isn't supporting it right now.
--000000000000a152e705ab962038-- From nobody Thu Jul 30 02:24:35 2020 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 DFE113A0FF2; Thu, 30 Jul 2020 02:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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 jl36u-rSZ1E1; Thu, 30 Jul 2020 02:24:31 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50075.outbound.protection.outlook.com [40.107.5.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 294603A0AE6; Thu, 30 Jul 2020 02:24:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ag7viVswM0RbSaIp13skLCv52hRlTDJoVugLQ67ejy4DvnDcRTlVRissT8Tt9DTQpiI184eplgAxPEqxbw3V3AGX99SpElTda6OLPnL+82PMu0HvsIWksQis9eSPEVIXnY5UAbM6Ez6fB7ffv9kyjGqsBV61GIqqZuQpwNQdEDnvhOkDnRw0MWEbkMOxRZsdiTX06hfM3CxlTl5cl+WvIhYnk9GOWd8iqcfBy6IYFdhTrEgd9QqwOa9dYXicMtu15IWxDrOmIon2n0dOAlRLpxPcV28V0BF0gqpQxRYmMos4cRACVXNALMIc/fGlh7o8nKuUjUQ54ZBJOnQ9lL0KCg== 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=0Dm5qqmQGchfrGXj0lU5x9jcN+1IArmHxGBD0apcltE=; b=NnfBQyCgranbP8wBWen2eyYK+MLPPtgDUi7qmSMGfFCrh5zXcBfgxT2MgnuTOCOPhcyI3GxpjRvp4qOZtxf9cfEN5oCHtJP+IuaDE/36KhsO/S46AQqH8M1An1GsGzGt7W3qcNUFvl6YGP4csBasVUTvPmqlvKNjb58PjRByHyzAZ5HI06lvKCq9bGj+Rr5+RuNc93eSsH/oHR5vGWNoJokB6RdsVWnLtY+1xqjuo2odQB0/tnMxiOFTLeRwmexiY8YaFqpCS5Oz5PdJNFxFwtmYXpoSOtrNOx0Kn4o6ehyHHklGd87Qq05AcLQDtef3GLSp0O3pCaXcWCFnzrDApw== 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=0Dm5qqmQGchfrGXj0lU5x9jcN+1IArmHxGBD0apcltE=; b=IoqPagnZP7E5xwy1b8CZOAgDNR6IBFLTeTh19w5Kwj23ti1B3BQOBsiVWlvO71BLjUN/dsb/RMkjFVZCKL2DSD+IcHDUTLWMA9yfOvfT5N/p5xlcqZvmpvpCftIyTM+p02Vubvzy04/YQhsDNN/xU8shFa6aBJae5lUQ3MOtbvA= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR07MB3196.eurprd07.prod.outlook.com (2603:10a6:7:2e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.12; Thu, 30 Jul 2020 09:24:22 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3239.017; Thu, 30 Jul 2020 09:24:22 +0000 From: Francesca Palombini To: Jon Callas , "secdispatch@ietf.org" , "draft-schanzen-gns@ietf.org" Thread-Topic: [Secdispatch] GNU Name System Thread-Index: AQHWX6njABA4iPTbNkynRAtKC7sfXKkV75oAgAoZAQA= Date: Thu, 30 Jul 2020 09:24:21 +0000 Message-ID: References: <31625.1595368614@localhost> <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org> In-Reply-To: <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: callas.org; dkim=none (message not signed) header.d=none;callas.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.12.182.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d2048fe5-0c65-4df2-e1dc-08d8346a587f x-ms-traffictypediagnostic: HE1PR07MB3196: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: b3Ko03HWKvO188UCCa3poW9KXgbVLGTEa+drT0EX6W3oI9SezDiNqiYpnIJvPaLKnW+b3MjXlioiXMQs/ew7w+QIBu+lrbcBDS1B/xzy9R5KPjDn9xU67gZrAdEJNBqf7GKXUKfUxfAQbEZ2zeZcW5XGgKi7crLHIfFQw5EVtRbkJ3ITfwyDJ+zuEldmL1ZWjlXtS0RkRYMxHmxsTm9vH53WWArxZOxWDiwkGw1CV1citn/TwghlKYAnyMxuUvfG9OkojunoeJ2ko7fo3fyNhcWqDLaPUwhxIS0mY1sKrW2Y1n2yT4rP3MfAMiq7pC86IOjsG4UdSWB3kByDSCxgOmyugUfKJa5U7z11NQ01+z3StmUXQ/zxyqazmhNSIFl5kvgxO7yreZm59hhgAszAnw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(39860400002)(136003)(396003)(366004)(478600001)(5660300002)(66946007)(44832011)(66556008)(66446008)(66476007)(64756008)(76116006)(91956017)(33656002)(966005)(71200400001)(2616005)(6512007)(6486002)(316002)(83380400001)(86362001)(110136005)(8676002)(66574015)(2906002)(186003)(6506007)(26005)(8936002)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ygWUA3j1UPRb1isDwtGBnCpM8BDyJ4ZsMI0r2EUlx/zH/64tiIBXxmvyMhr/ncVuLUBGkdNd3cR2UGege1CLNQa8BFlBL0AEK7ixptjZfTmXmv2ZE7Fs7w1niLZZoZWyO9oGEaHX/jgxbJFfABHB0PaR75VlIS9gkF77hX39+j8agvWFMAQ9U9ABkRazvjZgo4OycSOAT2c0WrshnhVI0Lio8uF7qTaw9YA7hS99kscct9yh5ggPjlJX0xBJbmOlmt/q9eNUtfbftziwSYkDzc+iBuEMUAPU/bxTUgo+Adb6MBw/rjrGyIOsc189JBSuEHTMS3a1c2eC3dDAxBZKHPnCr6fPGVC+Y82MxH1eNLSfxOZoVSgDfbtRf/erOdQgK4V9fmhKiDSUyxg/54jWCd+6BEIDaQAZYrV7VbKUvUoztB4T4Z6EUXNI/L6cXFJWOQ613tvSBPNXng/M0kFTMsu9cBG0mfPFWr0s8MB2Mv+Ur4Yk/cUPdEltD7QMJEEcx7lz2PwZx+MmEtT4qneY6Ah7YuH8j4YMv+l1KtfwJv59Es/5qN7mOML/R6McPJ7n+sBqvYsx7Mo0kzN1EN67BRU2xH+wmC2sGF/drsvAQY6XQcKeeoh6oRCSA7nsqhBMkLsCIr+l7cRsOiEQ5qm00A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d2048fe5-0c65-4df2-e1dc-08d8346a587f X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 09:24:22.0983 (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: hlQRBYn7OUThzMc+vOSFbt08upKghx28EPusV7st41icNb38jKPKJH0ZVeF2W6XUfdWaFygfEQ17YJmu2kVUloU3BmwO+PHRcqqMHo/Xf0+nCLVEwmFyHIcgGUGdlSEC X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3196 Archived-At: Subject: Re: [Secdispatch] GNU Name System 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, 30 Jul 2020 09:24:33 -0000 SGkgSm9uLA0KDQpKdXN0IHRvIHRvdWNoIG9uIHRoZSBsYXN0IHBhcnQgb2YgeW91ciBtYWlsLCB0 aGUgb2JqZWN0aXZlIHN0YXRlZCBpbiB0aGUgYWdlbmRhICh3aGljaCBJIGRyYWZ0ZWQpOiB0aGF0 IGlzIG1lYW50IHRvIGJlIHRoZSBvYmplY3RpdmUgdGhhdCBwcmVzZW50ZXJzIHNoYXJlZCB3aXRo IHVzIGNoYWlycywgdG8gc3RhcnQgIHRoZSBkaXNwYXRjaGluZyBkaXNjdXNzaW9uIG9uIHdoYXQg dGhlaXIgcHJlZmVycmVkIG91dHB1dCB3b3VsZCBiZSwgaWYgdGhleSBjb21lIHdpdGggYSBwcm9w b3NhbC4gQnkgbm8gbWVhbiB0aGF0IHByZXN1cHBvc2VzIHRoZSBkZWNpc2lvbiB0aGF0IHRoZSBk cmFmdCBpcyB0byBiZSBpbiB0aGUgSUVURi4gDQoNClRoYW5rIHlvdSBmb3IgeW91ciBmZWVkYmFj aywgYW5kIGVzcGVjaWFsbHkgZm9yIHRoZSBvbmUgdG8gdGhlIHBvaW50IG9mIHRoZSBwb3RlbnRp YWwgdHJhY2sgYW5kIGRpc3BhdGNoaW5nIHF1ZXN0aW9uLiANCkZyYW5jZXNjYQ0KDQrvu79PbiAy NC8wNy8yMDIwLCAwMzoxMiwgIlNlY2Rpc3BhdGNoIG9uIGJlaGFsZiBvZiBKb24gQ2FsbGFzIiA8 c2VjZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygam9uQGNhbGxhcy5vcmc+ IHdyb3RlOg0KDQogICAgSSd2ZSBhbHNvIHJlYWQgdGhyb3VnaCB0aGUgR05TIGRyYWZ0IGFuZCBo YXZlIHNvbWUgY29tbWVudHM6DQoNCiAgICAqIExpa2UgTWljaGFlbCBSaWNoYXJkc29uLCBJIGhh dmUgYSBncmVhdCBsb3ZlIGZvciBTRFNJIGFuZCBsb3ZlIHRvIHNlZSBpdCB1c2VkLiBJIHRoaW5r IHRoZXJlJ3MgYSBsYXJnZSBkaXNjdXNzaW9uIHdlIHNob3VsZCBoYXZlIGFib3V0IHdoYXQgdGhl IHVzZSBjYXNlcyBjYW4gYW5kIHNob3VsZCBiZS4gQWx0ZXJuYXRlIHJvb3RzIGV0Yy4gYXJlIGFu IGlzc3VlLCBidXQgSSdtIG5vdCBzdXJlIGl0IHdvdWxkIGJlIHNvIGJhZCB0byBiZSBhYmxlIHRv IHNheSAiSUNBTk4ncyBpZXRmLm9yZyIgb3RoZXIgdGhhbiB0aGF0IGl0IGltcGxpZXMgdGhlcmUg Y291bGQgYmUgc29tZW9uZSBlbHNlJ3MgImlldGYub3JnIiBhbmQgdGhhdCB0aGlzIGlzIG9idmlv dXNseSBwcm9ibGVtYXRpYywgcGFydGljdWxhcmx5IGluIGhvdyBpdCB3b3VsZCBlbmFibGUgdGhp bmdzIGxpa2UgcGhpc2hpbmcuIEkgdGFrZSB0aGUgb3Bwb3NpdGUgdGFrZSBvbiB1c2VyIGV4cGVy aWVuY2UuIFByb3RvY29sIGRvY3VtZW50cyBzaG91bGRuJ3QgYmUgdGFsa2luZyBVWC4gQW55d2F5 LCBJIHRoaW5rIHRoZXJlJ3MgYSBkaXNjdXNzaW9uIHBvaW50IGFzIHRvIHdoZXRoZXIgdGhpcyBp cyBhIGdvb2QgaWRlYS4gQXMgbXVjaCBhcyBJIHdvdWxkIGxpa2UgdG8gYmUgYWJsZSB0byBzYXkg InRoZSBtZWRpYSBzZXJ2ZXIgSSBoYXZlIGF0IGhvbWUiIChmb3IgYSBudW1iZXIgb2YgcmVhc29u cywgbm90IHRoZSBsZWFzdCBvZiB3aGljaCB0aGF0IHRoYXQgaW1wbGllcyBJJ20gbm90IGF0IGhv bWUiKSwgaXQncyBub3QgY2xlYXIgdGhpcyBpcyByZWFsbHkgYSBnb29kIGlkZWEgaW4gdGhlIGdl bmVyYWwgY2FzZS4gTXkgc2VjdXJpdHkgYXVkaXRvcidzIG1pbmQgaXMgaGF2aW5nIGEgZmllbGQg ZGF5IGluIHRoaW5raW5nIG9mIGNvb2wgKG1lYW5pbmcgY29uZnVzaW5nIG9yIG1hbGljaW91cykg d2F5cyB0byB1c2UgdGhpcy4gWWV0LCBJIHRoaW5rIGl0J3MgYSBkaXNjdXNzaW9uIHBvaW50Lg0K DQogICAgKiBJZiB0aGlzIGdldHMgcHV0IGludG8gYSB3b3JraW5nIGdyb3VwLCBJIHRoaW5rIGl0 IG5lZWRzIGFuIElFVEYgbmFtZSBmb3IgaXQsIG5vdCBHTlMgYW5kIG5vdCBzb21ldGhpbmcgdGhh dCBjb250YWlucyAiR05VLiIgT3RoZXIgc3RhbmRhcmRzIGhhdmUgaGFkIHRoZWlyIGluc3RpdHV0 aW9uYWwgbGlua3MgZmlsZWQgb2ZmOyBTU0wgYmVjYW1lIFRMUywgU1NIIGJlY2FtZSBTRUNTSC4g Tm90YWJseSwgT3BlblBHUCBkaWQgbm90LCBhbmQgSSB0aGluayB0aGF0IHRoaXMgd2FzIHVuZm9y dHVuYXRlLiBEZXNwaXRlIGFsbCBnb29kIGludGVudGlvbnMgYXQgdGhlIHRpbWUsIGl0J3MgY3Jl YXRlZCBjb25mdXNpb24sIGFuZCBJIHNheSB0aGF0IGFzIGFuIFJGQyBlZGl0b3IgYW5kIGFzIGFu IGltcGxlbWVudGVyLiBUaGVyZSdzIG5vdGhpbmcgd3Jvbmcgd2l0aCBHTlVuZXQncyBHTlMgYmVp bmcgYSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gb2YgPHByb3RvY29sPiwgYW5kIG15IGFkdmlj ZSB0byBib3RoIHRoZSBJRVRGIGFuZCB0aGUgR05TIHBlb3BsZSwgeW91J2xsIGJlIGhhcHBpZXIg aWYgeW91IGNoYW5nZSB0aGUgcHJvdG9jb2wgbmFtZS4NCg0KICAgICogVGhlcmUgYXJlIGEgbnVt YmVyIG9mIGVjY2VudHJpYyB0aGluZ3MgaW4gdGhlIHByb3RvY29sIG5vdy4gSSBkb24ndCBtZWFu IHRoYXQgYXMgYSBwZWpvcmF0aXZlIC0tIHRoZXJlIGFyZSBsb3RzIG9mIGVjY2VudHJpYyB0aGlu Z3MgSSBsaWtlLCBTRFNJLCBmb3IgZXhhbXBsZS4gSSBhbHNvIGxpa2UgQ0ZCIG1vZGUgYXMgd2Vs bCBhcyBUd29maXNoLiBXaHksIHRob3VnaCwgYXJlIHRoZXkgaGVyZT8gQXJlIHRoZSBkZXNpZ24g ZGVjaXNpb25zIGxlYWRpbmcgdG8gdGhlc2U/IFRoZXJlJ3Mgbm90IGEgbG90IGluIHRoZSBkcmFm dCBhYm91dCB0aGVzZSBkZWNpc2lvbnMuIEluIGdlbmVyYWwsIGl0J3MgYmV0dGVyIHRvIHN0aWNr IHRvIHRoZSB3ZWxsLXRyb2RkZW4gcGF0aHMsIHRvIHBpY2sgYWxnb3JpdGhtcywgbW9kZXMsIGV0 Yy4gdGhhdCBhcmUgaW4gY29tbW9uIHVzZS4gSW4gc3BlY2lmaWMgdGhlcmUgYXJlIG9mdGVuIHJl YXNvbnMgdG8gZG8gc29tZXRoaW5nIG9uIGl0cyBvd247IEkgY2FuIHNlZSB0aGF0IGEgbmFtaW5n IHN5c3RlbSBtaWdodCBoYXZlIHJlYXNvbnMgZm9yIGdvaW5nIGl0cyBvd24gd2F5LiBXZSBqdXN0 IG5lZWQgYSBkaXNjdXNzaW9uIG9mIHRoZW0uIE5ldyBjb2RlLCBuZXcgYWxnb3JpdGhtcyBtZWFu IG5ldyBidWdzLiBJZiB5b3UgY2FuIHdyaXRlIGFib3V0IHRoZXNlIGRlY2lzaW9ucywgIk1vc3Qg cGVvcGxlIGRvIFgsIHdlIGFyZSBkb2luZyBZLCBiZWNhdXNlIFoiIHRoYXQgaGVscHMgdW5kZXJz dGFuZCB3aHkgdGhlIGRlY2lzaW9ucyBhcmUgdGhlcmUuIFNvbWUgY2FuIGJlIGd1ZXNzZWQgLS0g Q0ZCIG1lYW5zIG5vIENCQyBwYWRkaW5nLCBhbmQgbm8ga2V5aW5nIGlzc3VlcyBvZiBhIHN0cmVh bSBjaXBoZXIgbGlrZSBDVFIgbW9kZS4gVGVsbCB1cywgdGhvdWdoLiBJIGFsc28gcmVhbGx5IHdh bnQgdG8gc2VlIHdoYXQncyBnb2luZyBvbiBhbmQgd2h5IHdpdGggdGhlIHJlY29yZCBkYXRhIGVu Y3J5cHRpb24gaW5pDQogICAgICA0LjMuIA0KDQogICAgKiBUaGVyZSBhcmUgYSBudW1iZXIgb2Yg b3RoZXIgZmVhdHVyZXMgaW4gdGhpcyB0aGF0IGFyZSBpbnRlcmVzdGluZ2x5IGVjY2VudHJpYywg YnV0IGxlYXZlIG1lIHdpdGggYSByYWlzZWQgZXllYnJvdy4gRm9yIGV4YW1wbGUsIGEgcmVzb3Vy Y2UgcmVjb3JkIGZvciBhIFZQTi4gVGhhdCdzIGludGVyZXN0aW5nLCBidXQgd2h5PyBab25lIHJl dm9jYXRpb24gd2l0aCBwcm9vZi1vZi13b3JrIC0tIHdoeSwgYXMgdGltZSBhbmQgdGltZSBhZ2Fp biBwcm9vZi1vZi13b3JrIHByb3ZlcyBub3QgdG8gd29yaz8gKEkgcmVmZXIgYWxzbyB0byBzZWN0 aW9uIDkuNSB3aGVyZSB5b3UgcmVjb21tZW5kIHByZS1nZW5lcmF0aW5nIHByb29mcyBvZiB3b3Jr LiBXaGVyZSBzaG91bGQgdGhlc2UgYmUgc3RvcmVkLCBob3cgc2hvdWxkIHRoZXkgYmUgcHJvdGVj dGVkPykgDQoNCiAgICAqIFRoZSBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBuZWVkIG1vcmUgd29y ay4gOS4xIGRpc2N1c3NlcyB0aGUgRUNEU0EgZGVjaXNpb24sIGJ1dCBub3Qgb3RoZXIgY3J5cHRv IGNvbnNpZGVyYXRpb25zLiBJdCByZWZlcnMgdXMgdG8gdGhlIHJlbGV2YW50IHBhcGVycyB3aXRo b3V0IHJlYWxseSBzYXlpbmcgbW9yZS4gIA0KDQogICAgOS4yIHBvaW50cyBvdXQgdGhhdCB1bnJl c3RyaWN0ZWQgVW5pY29kZSBuYW1lcyBjYW4gbGVhZCB0byBwaGlzaGluZywgYnV0IHNheXMgbm90 aGluZyBtb3JlIHRoYW4sICJ6b25lIGFkbWluaXN0cmF0b3JzIG11c3QgdGFrZSBpbnRvIGFjY291 bnQgdGhpcyBhdHRhY2sgdmVjdG9yIGFuZCBpbmNvcnBvcmF0ZSBydWxlcyBpbiBvcmRlciB0byBt aXRpZ2F0ZSBpdC4iIFRoYXQncyBub3QgaGVscGZ1bC4gT3IgcGVyaGFwcywgJ3RoaXMgZW5hYmxl cyBwaGlzaGluZywgYW5kIGl0J3MgeW91ciBwcm9ibGVtIG5vdCBvdXJzLCBhbmQgd2UncmUgbm90 IGdvaW5nIHRvIHRlbGwgeW91IHdoYXQgdG8gZG8nIGlzIHRoZSBhY3R1YWwgc2VjdXJpdHkgY29u c2lkZXJhdGlvbi4gVGhlIHNlY29uZCBwYXJhZ3JhcGggZXNzZW50aWFsbHkgc2F5cyB0aGF0IHBy b3RvY29sIHByZXZlbnRzIHRha2luZyBkb3duIHBoaXNoaW5nIHNpdGUgYmVjYXVzZSBhdXRob3Jp dGFyaWFuIGdvdmVybm1lbnRzIGFyZSBiYWQuIFVtLCBva2F5Lg0KDQogICAgOS4zIGlzIGFsc28g cHJldHR5IHNjYXJ5LCBhIGRpcmVjdCBxdW90ZSAoYW5kIG5vdCBteSBwYXJhcGhyYXNlKSBpczog IlpvbmUgYWRtaW5pc3RyYXRvcnMsIGFuZCBmb3IgR05TIHRoaXMgaW5jbHVkZXMgZW5kLXVzZXJz LCBhcmUgcmVxdWlyZWQgdG8gcmVzcG9uc2libHkgYW5kIGRpbGxpZ2VudGx5IFtzaWNdIHByb3Rl Y3QgdGhlaXIgY3J5cHRvZ3JhcGhpYyBrZXlzLiIgVGhhdCdzIGEgcHJldHR5IGJpZyBzZWN1cml0 eSBjb25zaWRlcmF0aW9uIHRoYXQgZXZlcnlvbmUgaGFzIHRvIGRvIHRoZWlyIG93biBrZXkgbWFu YWdlbWVudCBhbmQgZ2V0IGl0IDEwMCUgcmlnaHQuDQoNCiAgICBJIGRvIGhhdmUgYSBxdWVzdGlv biAtLSB3aGF0IGhhcHBlbnMgaWYgdGhlIGtleXMgYXJlIGxvc3Q/IERvZXMgdGhpcyBtZWFuIHRo ZSBkb21haW4gaXMgZXNzZW50aWFsbHkgZ29uZSBmb3JldmVyPyBJIGNhbid0IHF1aXRlIHRlbGwu DQoNCiAgICA5LjQgc2F5cyB0aGF0IHdlIG5lZWQgdG8gcGljayB0aGUgcmlnaHQgREhULCBpZiB3 ZSBwaWNrIHRoZSB3cm9uZyBvbmUgYmFkIHN0dWZmIHdpbGwgaGFwcGVuLCBhbmQgaWYgd2UgcGlj ayBkaWZmZXJlbnQgb25lcyBpbnRlcm9wZXJhYmlsaXR5IGlzICJ1bmxpa2VseS4iDQoNCiAgICBJ IGRvbid0IGhhdmUgZnVydGhlciB0aGluZ3MgdG8gc2F5IGFib3V0IHJldm9jYXRpb25zLCBleGNl cHQgdGhhdCBpdCdzIHRldGNoeSBhbmQgYnJpdHRsZSwgYnkgZGVzaWduLg0KDQogICAgQWxsIGlu IGFsbCwgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRvbid0IGxlYXZlIG1lIHRoaW5raW5n IHRoaXMgaXMgYW55dGhpbmcgbGlrZSBhIHNhZmUgcHJvdG9jb2wuDQoNCiAgICAqIERlc3BpdGUg YWxsIG15IGNvbW1lbnRzIGFib3ZlLCBJIHRoaW5rIHRoYXQgdGhlcmUncyBzb21ldGhpbmcgaW50 ZXJlc3RpbmcgaW4gdGhlIHByb3RvY29sIGFuZCB0aGUgaXNzdWVzIGNhbiBiZSBmaXhlZC4gTm9u ZXRoZWxlc3MsIHRoaXMgaXMgYmVpbmcgcG9zaXRpb25lZCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJG QyBhbmQgSSB0aGluayB0aGF0J3MgYSBiYWQgaWRlYS4gVGhpcyBzaG91bGQgZWl0aGVyIGJlIHN0 YW5kYXJkcyB0cmFjayBvciBjb250aW51ZSB0byBiZSBvZmYgb24gaXRzIG93biBhbmQgbm90IHBh cnQgb2YgdGhlIElFVEYuDQoNCiAgICBUaGUgbWFqb3IgcmlzayBpcyB0aGF0IHRoaXMgaXMgYW4g YWx0ZXJuYXRpdmUgdG8gRE5TIHRoYXQgY291bGQgbGVhZCB0byBmcmFnbWVudGF0aW9uIG9mIHRo ZSBtb3N0IGJhc2ljIHNlcnZpY2Ugb24gdGhlIEludGVybmV0LCBuYW1pbmcuIFlldCBpdCByZXF1 aXJlcyBldmVyeW9uZSB0byBkbyBrZXkgbWFuYWdlbWVudCBwZXJmZWN0bHkgYW5kIG9wdGltaXpl cyBhZ2FpbnN0IGVhc3kgbWFuYWdlbWVudCB0aHJvdWdoIHByb29mIG9mIHdvcmsgYW5kIHNvIG9u LiBJIGtub3cgSSd2ZSBkb25lIHNpbGx5IHRoaW5ncyBtYW5hZ2luZyBteSBvd24gRE5TLCBhbmQg aXQgc2VlbXMgdGhhdCBJJ2QgYmUgdW5oYXBwaWx5IGRvaW5nIHByb29mLW9mLXdvcmsgdG8gdW5k byBldmVyeSB0eXBvLg0KDQogICAgVGhlcmUgYXJlIGV4Y2l0aW5nIGlkZWFzIGhlcmUuIEkgYmVs aWV2ZSB0aGF0IG1hbnkgb2YgdGhlIGlzc3VlcyBJJ3ZlIGJyb3VnaHQgdXAgaGF2ZSByZWxhdGl2 ZWx5IHNpbXBsZSBzb2x1dGlvbnMuIEkgYWxzbyBiZWxpZXZlIHRoYXQgaXQncyBubyB3aGVyZSBu ZWFyIHJlYWR5IHRvIGRlcGxveSBvciBzdGFuZGFyZGl6ZSBpbiB0aGUgSUVURi4gQW4gaW5mb3Jt YXRpb25hbCBSRkMgaXMgbm90IGEgZ29vZCBpZGVhOyB0aGlzIGlzIHRvbyBiaWcgYW5kIHRvbyBl eHBlcmltZW50YWwgZm9yIHRoYXQuIFdoaWxlIHdlIGluIHRoZSBJRVRGIHVuZGVyc3RhbmQgdGhl IGRpZmZlcmVuY2UsIG1vc3QgcGVvcGxlIHRoaW5rIGFuZCBSRkMgaXMgYW4gUkZDIGlzIGFuIFJG QyBpcyBhbiBSRkMuIFRoZSBiZWxpZWYgaXMgdGhhdCBpbmZvcm1hdGlvbmFsIFJGQ3MgYXJlIHN0 YW5kYXJkcy4gKEFnYWluLCBJIGFtIGEgc2lubmVyIGhlcmUsIHRvby4gSSBoYXZlIGF0IHRpbWVz IGdvdHRlbiB0aXJlZCBvZiBzYXlpbmcgImluZm9ybWF0aW9uYWwiIHdoZW4gc29tZW9uZSBpbmNv cnJlY3RseSBzYXlzICJzdGFuZGFyZCIgYW5kIGp1c3QgbGV0IHRoZW0gZ28gb24uKQ0KDQogICAg VGhlIGFnZW5kYSBmb3IgU2VjZGlzcGF0Y2ggc2F5cyBzaW1wbHkgdGhhdCB0aGlzIGl0ZW0gaXMs ICJvYmplY3RpdmU6IGZpbmQgYSBob21lIGF0IElFVEYiIHdoaWNoIHNlZW1zIHRvIGJlIHByZXN1 cHBvc2luZyB0aGF0IHRoZSBkZWNpc2lvbiBpcyBub3QgaWYgaXQgc2hvdWxkIGJlIGluIHNvbWUg d29ya2luZyBncm91cCwgYnV0IHdoaWNoIG9uZS4gSSB0aGluayBpdCdzIHByZW1hdHVyZSBmb3Ig dGhhdC4gTXVjaCBtb3JlIHdvcmsgbmVlZHMgdG8gYmUgZG9uZS4NCg0KICAgIAlKb24NCg0KDQog ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBT ZWNkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCiAgICBTZWNkaXNwYXRjaEBpZXRmLm9yZw0KICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlzcGF0Y2gNCg0K From nobody Thu Jul 30 05:58:13 2020 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 8BA083A1102 for ; Thu, 30 Jul 2020 05:58:10 -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, 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=nomountain-net.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 FC4S_gcFR5T2 for ; Thu, 30 Jul 2020 05:58:09 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 1A3413A10FE for ; Thu, 30 Jul 2020 05:58:08 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id t10so8703609plz.10 for ; Thu, 30 Jul 2020 05:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version; bh=46Rkbj55GklcKyo5OK/22zk1md7zDdlEnW4yLSdCVS0=; b=C35IIOBVWi1ywL6H5EAFhk03SIWgP7HdshW74OrETYvV1yv4WbJYFQuk+5uD31D9rX PDe0rLo19RljsNHqmuf65UhGssSe7SOm1NcGsKntkH8b0nm6REWQO874/fMjyIuCG0mt 2P8No8acijoJFCDyjP6+eFeJKqrXM8MoLj+DU+pz5er51npgHQ//fJIX8PFbYxMU7Ut8 g6KiO4iffDEAcf+ZPAyoswp1jm1qOVxpDeS5OjFFwNudl+uJcGDhJl5THHsBnEfST437 lGt2J76prJWETLgfSHq8NnpRvZOdY7Szkw741v+qtHE/D9sTLNS9+42f9EPzNoE78f5e BKVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version; bh=46Rkbj55GklcKyo5OK/22zk1md7zDdlEnW4yLSdCVS0=; b=PVYglP4/J3rUQVJbilE/avVWTjkZdTgo5ayUoctO6AfVNUHzB5f/6YP9o5hE0fQUKQ HlGLlGYtuczQeV26VtFwljMpvZkPxTMr7L4fdZqW7J1DeB0x+zv/kQUjbtcqsHh0Qk1C eY8YNVQcRLsOBToiXMf7uKEm9GRSwGYmHAj6CrEjmvn57J23QA9V9QmW3jN37x2PPhSm k4Fix52MZkrHYFtUKDqNgomf4Z7LUkQPdCpt93vxDiipU/5VDYTTpOjHXw21CwLK1b3n XHQSoAGYyukJV7GEU/kYArIbWLewjt/agaxQRpU98vs74EctFnPkB+4OaEbmqWbjo/8K XCvw== X-Gm-Message-State: AOAM532ruTg5Gb1qBpFd60iyxIIVdaOhUmNN30UZNvM5IcTERl/3fnYD Numubvkh0IbgooUOupV2HrrmSGmLrA== X-Google-Smtp-Source: ABdhPJwUQTjQSkr6SXax0Tt0H5vh0P5mbEP0EZLqDsBqqYMmOf+nFmBGCMR/7kQsAW2X91jdqffYWQ== X-Received: by 2002:a65:43c9:: with SMTP id n9mr33474915pgp.452.1596113888069; Thu, 30 Jul 2020 05:58:08 -0700 (PDT) Received: from aspen.local (63-140-73-54-rb1.jnu.dsl.dynamic.acsalaska.net. [63.140.73.54]) by smtp.gmail.com with ESMTPSA id g12sm5793374pfb.190.2020.07.30.05.58.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2020 05:58:07 -0700 (PDT) To: secdispatch@ietf.org From: Melinda Shore Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: <00a64a56-3c85-49ca-636c-25e39d4f659f@nomountain.net> Date: Thu, 30 Jul 2020 04:58:04 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mXP9dQsZSmWKm5mmjESlRlsbNr4LnVRlB" Archived-At: Subject: [Secdispatch] GNS at dinrg 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, 30 Jul 2020 12:58:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mXP9dQsZSmWKm5mmjESlRlsbNr4LnVRlB Content-Type: multipart/mixed; boundary="CHofRLLUshVbHfTQV42M2P5noT5HTAYlH" --CHofRLLUshVbHfTQV42M2P5noT5HTAYlH Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I had a conflict this morning and wasn't able to participate in the secdispatch session, but I've been asked about the GNS presentation at dinrg at IETF 104 (dinrg is an IRTF research group investigating decentralizing internet infrastructure elements). The question of adopting GNS as an RG deliverable never came up. Research groups operate differently from IETF working groups and are not heavily driven by deliverables. In general, the feedback from the floor expressed concern about scalability and key management, DHT performance, and (as always), governance. I do think, however, that GNS remains more of a research project than a standardizable technology, as one of the bottom-line questions for the standardization of pretty much anything is whether or not it's deployable on the public internet. Even if the technical questions about GNS are resolvable (little DNS joke in there) the governance question looks intractible ("we would advise ICANN not to assign any more names" doesn't seem as if something ICANN would be likely to act on). Also, it's become more common to talk about DNS as part of the internet control plane and we're seeing increased use of the DNS to bind things other than addresses to domain names. That has implications for performance and scalability (see above), as well as the security model. Perhaps that was addressed in today's presentation - I'll watch it once the video is posted. It's interesting technology but unless they can both work out a very incremental deployment model and deal with the governance question (and I expect those two things can be linked) I'm not that optimistic about its deployability as a core piece of internet infrastructure. (I'd love to be wrong about that!). Melinda --=20 Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis --CHofRLLUshVbHfTQV42M2P5noT5HTAYlH-- --mXP9dQsZSmWKm5mmjESlRlsbNr4LnVRlB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl8iw90ACgkQ37iRcpp2 249GpBAArY7TOR0JsULuhhzKd2au5Hqzmsylu3euDVQJQlPflnDNywV+Sua3ZIw7 LaiAuDgbx2FLOhdsJnxTreLOCaVU/Iz7pfFRtdsn6NznhBOIvNJ+uyD0nJ1IO/bf mStQbRlj2brEEd6tV1DOfFcfLntV/B8aJ0oqs/TZSlWWmKxT5v+m/JbGRilHVMbH j6+I6CGdUTntp2Ay9oehIW3a+pF/jut6pFwC7INYB8pEENIWeK4S6MI64ZJMY+pu 9w7p8wyAC1Dju/Li++muXizAWjyNUlUVkwBpI27rV0l+Rv8hZVebEo01jJFOoPj0 oE0n3Tz2OyqQd7aiUh/AeNuFr5aub+TEyi0ohtt/C86L1fd241+4WpD07naJU7Nw YU1/MfYNLcXO8OHKa+WuKMfgiw/GHDpuHvYp1Jw1yq4MsId+j7d/6nRce2l1eWYt B0z06je5ibL0cf58iZscVWI8Gsv5T7UtG1h5weRfpTuHENVPoiy/bb9rpjb8JPoD GK8y1mSfhd1Yx9jEAuL4PKoeHOVLGrSlBZqvOvesVUczNkc8MrvD/3VuhleRXI2o rJguhsI20aX+WyK7zvqebPP7NBVwm+7kq1j99xykcbnMeTJAnQTlyld3nzHGhFye iygxVrSod1thiFFaQtnB16gWiKdD2ttDKygyW0Sbw5ABxFYqO70= =JQmv -----END PGP SIGNATURE----- --mXP9dQsZSmWKm5mmjESlRlsbNr4LnVRlB-- From nobody Thu Jul 30 10:26:49 2020 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 BC9A73A1116; Thu, 30 Jul 2020 10:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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 8N9W5HTikXDE; Thu, 30 Jul 2020 10:26:41 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2079.outbound.protection.outlook.com [40.107.20.79]) (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 988E63A0FDA; Thu, 30 Jul 2020 10:26:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=alktC0B7Gqk6yhpKSPdWp27GVXbUjt1YHrnGmWZlL49CNtpG2ScvSMOzuVn/Yf1+FzkSKz67PsNES30Fo3rqSoDvHaohn8HbOOM7neG4iZfXPJl4s5e/TdH7JKlpy2p9ilPFZXsN2v2ZaF8ovr4/Fx483zfuNCMTaDA/ILxtjjPOJwZaIHLVK08npJbpJ62SyYo7ZC5qat8u0kIyaXMDRqUH9bl9YB6Gzm6krIm0yhN4m9oOWiBFGPXiTudTdmKBgCR8sAG66IB7cW6T34ES4Kl2TnEgJPBJ+DRtCv0lrCphGnL5UjVaX41yY0g+oth6yW04lt4CoHwf0hAJK3vPgQ== 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=oj+aAyYGdMNu3A/JhRxdgrKWVyewGV1thQYnq0/HXRY=; b=EkuP/hzWUAIoCfpKZYuyx7XyQULLZF/pBostcjaNaYdLz5kLwmEtwpwFUb45O2kftkw1gG9wEynV18sG4gyYwJ2ZQij2Cl9H/w9CjRUkdSMNwaeddpJQ05AduHdn2jeiY8EJ4lDY9qj12pytqjp5a8SZLpTfJZSaMpoVd4N7pF1Ff+gaEZqqPF22olVF65PRdhd4v2F8OTCaQt8oQmfZmG9rZBz9Nmmu/gcxfN5+6Sa55CC24WdQuo8tamT6blKBeijTTKOv9bLRYqhkJNcUkJPZHfYRxLywVmgovKvgfoqykXyM3E5hjqVCRyI7EgAd9VaCovpJtuYi+3Rf+Ej51Q== 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=oj+aAyYGdMNu3A/JhRxdgrKWVyewGV1thQYnq0/HXRY=; b=ltt165RlgZSiMtgRYOM1jakPgXSL0YRnV3MKo64OZuCJbxvyr1T1gEbau+JMHz4vuv8ZoKr8XqOdj1p4KVjQdgwtP0B1P4HkP5TaakCFTi13ROToq1fSksztQgjIMTL9OgLAc36RU0LsBcbdo93eTLpz/tYWjccS2WPvojE5EZI= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0701MB2250.eurprd07.prod.outlook.com (2603:10a6:3:2c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Thu, 30 Jul 2020 17:26:17 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3239.017; Thu, 30 Jul 2020 17:26:16 +0000 From: Francesca Palombini To: "secdispatch@ietf.org" CC: "secdispatch-chairs@ietf.org" , "sec-ads@ietf.org" Thread-Topic: Minutes IETF 108 Thread-Index: AQHWZpaIIGsiXh0C2E2FcT/4gkDu+A== Date: Thu, 30 Jul 2020 17:26:16 +0000 Message-ID: <9B95C14D-C7D4-462E-988A-883FD95A5383@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.12.182.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb49fd4f-8799-4fa8-73f7-08d834adaaa5 x-ms-traffictypediagnostic: HE1PR0701MB2250: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tSTEhSaNGUG6yyklLZbNAL3xYhMb4IbL4DLC23/aCgu7k/p2FeFugJTmfeAnN9skfu9jKJq9OJzogbiDAVF6ekMLs8bhZrbGAzFtrWwBkZuE6XZyDO8YgS6hg/uNARkzzdlJpNWysLcSrP7FBtpIwGsYDt6RMMuUV6Fyhd8qntfDCXBMrSyKH6mKPL4C/c4Q66dMmpRFDheKPIZeZyMekw71pi532p/QWE+SS4rekqhfZzJ/L04MP/3Tenyjck5FayjbzCDu/eXg0Q1lsneDfqTdvN1XloZ0nZt9ZuYWl2zMz71mZ6PAuyDzyVvjLY4DOpJRsYtpqGezL9RNwIugTWHb9NKlB+sbsXOnXog8m29XfIcTJkBIQEaa37Az9rEoEz+PQWCdVYWLtGVzp4DnBw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(136003)(346002)(376002)(396003)(8936002)(8676002)(83380400001)(478600001)(66946007)(66476007)(71200400001)(86362001)(6506007)(54906003)(6916009)(76116006)(91956017)(6486002)(450100002)(4326008)(66556008)(36756003)(316002)(2906002)(33656002)(44832011)(5660300002)(6512007)(26005)(2616005)(966005)(66446008)(64756008)(186003)(7116003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 72ehh1jexvSgqHEx8jT3tfdrTRv02BUtt/Q/8LiOhMQUbU55cLCNpIgfQ1UE2LKCJEfpQa4pOdV16LblZWYXtzC1O1dmuu4j+Qw4RqfXUAQtCk4nhRKjE3h7Fdxy7UaTedvilGSqpiVAevEmrwZZxHXi/oaqt1c1JGvo6XrlOARtFRC9AGQ6fmntSU+2tQ9UNzZxTD4jd87vSNVFWXkDrzB8Ri0V5QOdRxhPBk1FYpzqGpNh40wTm+Lio8ggLoeNXGlxlN1GD5547o0bbMjTF/M5CX0badAa2uhi0NLJANLnWlVWncynlo/AqA8PS85ubyzuGaNRMlNKz0jnK4qZQpW1MEOJ8Mx1S474EniCgU09iLGDDBWNR2reSzTwsxuZvMt6jUn8pxfpTcLd2ng3HlgB+8nBPoIpH/mLdtBuz8rr2X+CPNw0aKBFeVgAokVUoDed1TTZJDrXXGdjRDqkol+kJlrCLHD1fmyEkEGa0tWEKvbG8hKclalscGt6rKPXjl0juevmm4VgMpuB5LRP6y0lLi4Jibv6eVsmGNjL6QstwJABRGqniueEYAi9Gv540CyFFU8y8B5Lj16PjlM2veYNn+NSpbSIm7Q9zB2t+hZjRnsggpHYlQdMlkDUDpi6yAgcAXEzv1NRu2fo+WAomw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <6F7A15018A3DCE4397D6F04E40628E1E@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: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb49fd4f-8799-4fa8-73f7-08d834adaaa5 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 17:26:16.8982 (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: 8KHELSc6Jd3yU7RRIul68X6yLiryaRJbvbuXfLu/kJxpi03JTerdEuWG5ORyJtu2QV1/8TqSXBHvLS5mdy3nLyl0tDdBJW3ZueWeNfMwTZvUnY6esMHrX50cByCnEzZt X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2250 Archived-At: Subject: [Secdispatch] Minutes IETF 108 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, 30 Jul 2020 17:26:47 -0000 SGksDQoNClRoYW5rcyBhbGwgZm9yIGEgcHJvZHVjdGl2ZSBtZWV0aW5nIHRvZGF5LCBhbmQgc3Bl Y2lhbCB0aGFua3MgdG8gb3VyIHN1cGVyc3RhciBtaW51dGUgdGFrZXJzLCBDYXJyaWNrIEJhcnRs ZSBhbmQgRGFuIFlvcmsuDQoNClRoZSBhZ2VuZGEgaXRlbXMgd2VyZSBkaXNwYXRjaGVkIGFzIGZv bGxvd3M6DQoNCigxKSBJRGV2SUQgY29uc2lkZXJhdGlvbnMgKE1pY2hhZWwgUmljaGFyZHNvbikN Ciogc3BlY2lmaWNhdGlvbjogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hh cmRzb24tc2VjZGlzcGF0Y2gtaWRldmlkLWNvbnNpZGVyYXRpb25zLTAwIA0KLS0+IE5lZWRzIHZl bmRvciBpbnZvbHZlbWVudCAtIGdldCBtb3JlIHBlb3BsZSBmcm9tIHRoZSBpbmR1c3RyeSBhbmQg dGhlbiBwb3NzaWJseSBicmluZyBpdCBiYWNrLg0KIA0KKDIpIFN0cm9uZyBBc3NlcnRpb25zIG9m IElvVCBOZXR3b3JrIEFjY2VzcyBSZXF1aXJlbWVudHMgKEJyZW5kYW4gTW9yYW4pDQoqIHNwZWNp ZmljYXRpb246IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb3Jhbi1zdWl0LW11 ZC0wMCANCi0tPiBEaXNwYXRjaGVkIHRvIFNVSVQuDQogDQooMykgVGhlIEdOVSBOYW1lIFN5c3Rl bSAoTWFydGluIFNjaGFuemVuYmFjaCkNCiogc3BlY2lmaWNhdGlvbjogaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXNjaGFuemVuLWducy0wMCANCi0tPiBJZiB0aGlzIGlzIHRvIGJl IGRvbmUgdG8gdGhlIElFVEYsIHRoaXMgc2hvdWxkIGJlIGEgQm9GOyBndWlkYW5jZSB0byB0aGUg QURzIGZvciB0aGUgQm9GIHRvIGNvb3JkaW5hdGUvZGVjb25mbGljdCB3aXRoIERJTlJHLg0KDQpU aGUgZGV0YWlsZWQgbWludXRlcyBjYW4gYmUgZm91bmQgYXQgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvMTA4L21pbnV0ZXMvbWludXRlcy0xMDgtc2VjZGlzcGF0Y2gtMDQNCklmIHlv dXIgY29tbWVudCB3YXMgbm90IGNhcHR1cmVkIGNvcnJlY3RseSwgcGxlYXNlIHNlbmQgYW4gZW1h aWwgdG8gdGhlIGNoYWlycy4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCg== From nobody Fri Jul 31 09:31:37 2020 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 EC1FE3A0AEB for ; Fri, 31 Jul 2020 09:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=posteo.de 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 7RZiWLn_3sni for ; Fri, 31 Jul 2020 09:31:33 -0700 (PDT) Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (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 C40463A0AD9 for ; Fri, 31 Jul 2020 09:31:30 -0700 (PDT) Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 8029E160060 for ; Fri, 31 Jul 2020 18:31:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1596213088; bh=nb4MkwgRDwt8fdw3gKcYZJ2M4cx8bxp8Pvyw+hbhxhk=; h=From:Subject:Date:Cc:To:From; b=Qj80LCFjo/p3vOqoj8G4cNmR5XBHj8UL3IipD834s3aZtFzbAVZktkME2MgKzd9XL eVhKZypGjutnfKqFIgnWtn9L1uwSNyVMvgFjbnY/QRbplDq3E6Gyg91MeZbO01cvmK +VHQuWqTjIhBNpRgM+G9BRwHay8JmcsLs2twXwCdab5ha//W6z1hMiHAJaj/NC7JWa uArasRWPC5seiHLZnFjqMdfTcdV9xPKG+Z0xsxodk+3cPJcu0sF/O6v+eznTEOU1Qo ax6apfXKTYz6L3bsgC2BoLGNiz5AzUt6y/K40kpdxcVk+vb3BzxX7VMw7uxcxhbHei JnJ33RqS8GsEQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4BJCTW1Fv7z6tmM; Fri, 31 Jul 2020 18:31:26 +0200 (CEST) From: "Schanzenbach, Martin" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_19C86469-103E-495B-B77A-33D84BE9389A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 31 Jul 2020 18:31:16 +0200 In-Reply-To: <00a64a56-3c85-49ca-636c-25e39d4f659f@nomountain.net> Cc: secdispatch@ietf.org To: Melinda Shore References: <00a64a56-3c85-49ca-636c-25e39d4f659f@nomountain.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Secdispatch] GNS at dinrg 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, 31 Jul 2020 16:31:35 -0000 --Apple-Mail=_19C86469-103E-495B-B77A-33D84BE9389A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Melinda, > On 30. Jul 2020, at 14:58, Melinda Shore = wrote: >=20 > Signed PGP part > I had a conflict this morning and wasn't able to participate > in the secdispatch session, but I've been asked about the GNS > presentation at dinrg at IETF 104 (dinrg is an IRTF research > group investigating decentralizing internet infrastructure > elements). >=20 > The question of adopting GNS as an RG deliverable never came > up. Research groups operate differently from IETF working groups > and are not heavily driven by deliverables. In general, the > feedback from the floor expressed concern about scalability and > key management, DHT performance, and (as always), governance. the DHT is not part of this draft. It is specifically out of scope. Anyway, not the point I would like to make. > I do think, however, that GNS remains more of a research project > than a standardizable technology, as one of the bottom-line > questions for the standardization of pretty much anything is > whether or not it's deployable on the public internet. Even > if the technical questions about GNS are resolvable (little > DNS joke in there) the governance question looks intractible > ("we would advise ICANN not to assign any more names" doesn't > seem as if something ICANN would be likely to act on). >=20 > Also, it's become more common to talk about DNS as part of > the internet control plane and we're seeing increased use of > the DNS to bind things other than addresses to domain names. > That has implications for performance and scalability (see > above), as well as the security model. Perhaps that was > addressed in today's presentation - I'll watch it once the > video is posted. It's interesting technology but unless > they can both work out a very incremental deployment model > and deal with the governance question (and I expect those two > things can be linked) I'm not that optimistic about its > deployability as a core piece of internet infrastructure. > (I'd love to be wrong about that!). I hope I understand all of your points. The way I read the charter of DINRG correctly, our draft would fit into the goals and objectives of this WG, right? Specifically: "Some examples include name resolution (Namecoin, Ethereum Name Service) = [...]" (This point also came up in the discussions in secdispatch.) And: "Now is a good time to investigate these systems from an Internet = technologies perspective, and to connect the domain expertise in the = IRTF and IETF with the distributed systems and decentralized ledgers = community." The charter explicitly gives two name services that can be argued to = have open questions with respect to governance and scalability as well and completely open questions, for example with = respect to sustainability. And we are trying to address issues IETF/IRTF experts may have by initiating discussions and did so at IETF meetings on multiple = occasions. So my question would be: Is DINRG the proper place to discuss those = issues as well as improve the draft and protocol? Best Martin >=20 > Melinda >=20 > -- > Melinda Shore > melinda.shore@nomountain.net >=20 > Software longa, hardware brevis >=20 >=20 >=20 --Apple-Mail=_19C86469-103E-495B-B77A-33D84BE9389A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPREGPBD5jRS9JNFHCwmY74b1m2oFAl8kR1QACgkQCwmY74b1 m2qEYxAAmAqh1EsvHRS6l+0mh2KPP20tIZQbVvvOKLVroq0shGy6AkGZwqfcD+et UR7CdZWHkGb8GE8lddBXAgeisA/7d+6MSYiAn2xhVq+WRiIetnmuwdeFwvlYRZmA 943IeLXex0GqjnfVyQ2jqkagx0im0msg+d81CGLhoU695+aOm6lE9MfmhC0IL2zD zm86OnwLJRAiUKmXz4xyok/n1RPumOrVtw19EU95qeKv0b7iWhUFpSOsvwBNAGni mDMBdiy/EiaTbg5g0oH8CEBrLWSXbPEe5M1EBzLI0Bn24Vdx3029zqU00gAAROco Me/MUp9MJsuCa1GB6ONnSBFdD80bzxBOYss9TEEM97gqvqaxfeiRp/+2Z8t42bpX jFmUwcr3HvyDsRfJbyCjyuPKSp0FKEVniAotELP0c3wG2bFPKmGsMSL/9UOuI/OD VDnabbPI11Nb+bPhRdzu1p1OCrvLyH54SN39TDVMjSkUS3XH/5a7zuY3GhpKVP/6 SbDQZGwdaC00R4SwPxJohpIP98D2acwW8N6f4ifSGGNcGizOQxOv505278m/jMRr GT93fup/WhsNgYfhHxY+tfHUVtrJ4Pb0KEO5DAs4+DvFMu5OSX/Cy5QsaqWsj8jR hQApVNtIsyD6YzSnl8qO20BxmGAUO0v3zHPwf4dga4kra6rnJFk= =1991 -----END PGP SIGNATURE----- --Apple-Mail=_19C86469-103E-495B-B77A-33D84BE9389A--