From nobody Sun Dec 1 16:46:34 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995B012011B; Sun, 1 Dec 2019 16:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 VHjndzuhHZWh; Sun, 1 Dec 2019 16:46:22 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CBCA8120052; Sun, 1 Dec 2019 16:46:21 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xB20kEc0032079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 1 Dec 2019 19:46:17 -0500 Date: Sun, 1 Dec 2019 16:46:14 -0800 From: Benjamin Kaduk To: Christian Huitema Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, tls@ietf.org Message-ID: <20191202004614.GB32847@mit.edu> References: <157498929764.5575.7815291384505057169@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157498929764.5575.7815291384505057169@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-certificate-compression-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 00:46:24 -0000 Hi Christian, Thanks for the constant vigilance on the privacy front; it's good to work through what the differential exposure is, here, both with and without ESNI. Authors, please consider how you would like to handle this topic in the document. Thanks, Ben On Thu, Nov 28, 2019 at 05:01:37PM -0800, Christian Huitema via Datatracker wrote: > Reviewer: Christian Huitema > Review result: Has Issues > > I have reviewed draft-ietf-tls-certificate-compression-07 as part of the > security directorate's ongoing effort to review all IETF documents being > processed by the IESG. These comments were written primarily for the benefit of > the security area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > Draft-ietf-tls-certificate-compression-07 defines two new TLS extensions to > negotiate and then apply compression of the Certificate message. The draft is > clear and well written, and the extensions are already widely deployed. I would > like to say "ready", but I have to say "almost". > > This document is almost ready, except for one nit and one issue. > > First, one nit. The draft references the "Certificate message", but there is no > formal reference section 4.4.2 of RFC8446. Please add that, maybe at the > beginning of section 4. It may seem obvious to members of the TLS WG, but > uninformed readers will appreciate. > > Second, my actual concern. Compression may leak information, because different > certificate chains will compress differently. The authors mention that an > attacker will not be able to inject data in the certificate chain, and thus > that attacks of the CRIME variety are unlikely. That's correct, but that's not > the entire story. > > TLS 1.3 will encrypt the compressed certificate message but the length of that > message could be deduced from the length of the server's encrypted message. > Attackers might be able to derive from that length the identity of the server, > even if the SNI is encrypted. > > One could say that in the absence of compression the length of the certificate > chain is also available. Indeed, the problem is flagged in > draft-ietf-tls-esni-05, which states in section 5.3 that "it (the server) > SHOULD pad the Certificate message, via padding at the record layer, such that > its length equals the size of the largest possible Certificate (message) > covered by the same ESNI key." > > Certificate compression introduces a level of complexity here. If only some > servers in the anonymity set support compression, attackers can work with a > smaller anonymity subset. If all attackers support compression, the padding > should try to match the largest Compressed Certificate. > > It might be good to discuss this issue in the security consideration section. > > From nobody Mon Dec 2 10:19:37 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 398AB12020A; Mon, 2 Dec 2019 10:19:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: last-call@ietf.org, opsec@ietf.org, draft-ietf-opsec-v6.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Linda Dunbar Message-ID: <157531076719.24879.6243454588694388546@ietfa.amsl.com> Date: Mon, 02 Dec 2019 10:19:27 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-opsec-v6-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 18:19:27 -0000 Reviewer: Linda Dunbar Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is really good, it summarizes the IPv6 security issues from multiple RFCs. I think IETF should do more of this kind of summary documents that collect high lights from multiple RFCs, to make it easier for network operators. Linda Dunbar From nobody Tue Dec 3 03:20:04 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7AF1200E6; Tue, 3 Dec 2019 03:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lDf2/mpX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sLOLe2ty 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 l3s7hYvoU9eO; Tue, 3 Dec 2019 03:19:56 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1401200D7; Tue, 3 Dec 2019 03:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1216; q=dns/txt; s=iport; t=1575371996; x=1576581596; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nwydH8ThBkg6WYpHiwR8vSl7dKaiTqKg1uta9/kadaw=; b=lDf2/mpX1/N+2lzMG7xA+4Ak8vJbFuNizgltS5+dzu8Ox9xCHDB1EKgO zuYSQ3Rjlx/PEv7RfBK0RN4VLM3z49NRn0rJiMEeD97K4UKUHdlOgclms /7x2ZYDcifKzXrj9OCqoqHwVyEhRDQgs5X7IR7ANLcVZeghG1BHMhHORZ s=; IronPort-PHdr: =?us-ascii?q?9a23=3Axc3/GBcUCtuCCruqnm4P4YR7lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YjIrGs9BWXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAQAhROZd/5xdJa1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBfoFLUAWBRCAECyqEK4NGA4p2mmOCUgNUCQEBAQwBAS0?= =?us-ascii?q?CAQGEQAIXgXYkOBMCAw0BAQQBAQECAQUEbYU3DIVTAgEDEhERDAEBNwEPAgE?= =?us-ascii?q?IGgImAgICMBUQAgQOBSKDAIJHAy4BpWwCgTiIYHWBMoJ+AQEFhQgYghcJgQ4?= =?us-ascii?q?ojBYagUE/gREnIIJMPoRggnkygiyQHp4oCoIukUKEFxuCQYwsizaoYwIEAgQ?= =?us-ascii?q?FAg4BAQWBaSKBWHAVZQGCQVARFIxmg3OKU3SBKJAkAQE?= X-IronPort-AV: E=Sophos;i="5.69,272,1571702400"; d="scan'208";a="385954369" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Dec 2019 11:19:55 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xB3BJt8P030460 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2019 11:19:55 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 3 Dec 2019 05:19:54 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 3 Dec 2019 06:19:53 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 3 Dec 2019 05:19:53 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UKujt7h9f9/2KqLPtFG3Zyj/K5EhDJXLsvGduG6JVd2B1ccb9wDzfYDTqrfW8DP80zPVfXVKEfVVh7cki4xlp3rd4OjEwkE/FzuCkeLduSxOar6YEvnaogyoOYeH09H/XNM3C/06CnKouN3sz7vpZnsbtMxRge6vETEPdaYLmB4sAr/cE8TkStA2yC7prvzdYHnOTqCsz0JZpxIYJG/PMmL6d+CXjQHtH4VA4DVaTfPZJXOI+I19P+hnB+NsCpvbZbGU5E8cpPM+PGxEO5rtVjxrWQSBO1PpUjDEOfE837ro7N4RxLdJa0utHcGgeEsAbEtQlfQWiBtdBI4qx36X7g== 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=nwydH8ThBkg6WYpHiwR8vSl7dKaiTqKg1uta9/kadaw=; b=EFW7Uh8nboidoAvW9uIlML8+IUVXxHhM+JY8EhNr6f7L0THT47X+5IKkq/BD65tYTTYEJZn7UlHy2djpAf9RIW9ONVS++HHsz0/KD8kTFyH7s0Mnqk2uwILua4vHMs9jX/V85f32trxuws82d8Oyj5vc8uo5BJA9oawAwtTrCDEMy1VAxBPPXW/yFdRCmvcq1P+cgmntrYj/BAbctJkZXj4y1RuWU2meX354/2vBiLbs4mu7+HaTBsaQDL5A5ypiWWe4/NsBYAeUpCLBVebTL1pKSIojPLNN7jhOpMilfmEF3b1jMb3bRnjYU7NMCmMidzcd4LrPPplNlWmFmd25eQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nwydH8ThBkg6WYpHiwR8vSl7dKaiTqKg1uta9/kadaw=; b=sLOLe2tyd/P4zCaauge4wUqG89IzysGpYzW2tX+wfKvJiWxV2uJe1BjvUzkh6DVkSsSQL9B+0anvGmhYgXm19sBcFrXHiGPWw5Ok8sruglHMpO6vPgD17wzv3klypuNEt7e1kNzysJrmHUQhV3aUhh9mWOj8ry4+sX+LEzcYOAM= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB1994.namprd11.prod.outlook.com (10.168.105.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18; Tue, 3 Dec 2019 11:19:52 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::6c99:679c:82cd:b955]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::6c99:679c:82cd:b955%12]) with mapi id 15.20.2495.014; Tue, 3 Dec 2019 11:19:52 +0000 From: "Eric Vyncke (evyncke)" To: Linda Dunbar CC: "secdir@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-v6.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-opsec-v6-21 Thread-Index: AQHVqT0QyzpJyAWuykm/lQI034gl4qeoysqA Date: Tue, 3 Dec 2019 11:19:52 +0000 Message-ID: <71D1F5A4-C67D-4B1B-84DA-CEC269FA024A@cisco.com> References: <157531076719.24879.6243454588694388546@ietfa.amsl.com> In-Reply-To: <157531076719.24879.6243454588694388546@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:65a6:1ca9:4607:70e9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3158de7e-ff74-48bc-3955-08d777e2b7e3 x-ms-traffictypediagnostic: DM5PR11MB1994: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(396003)(366004)(39860400002)(136003)(189003)(199004)(6512007)(99286004)(2616005)(446003)(71190400001)(71200400001)(4744005)(91956017)(478600001)(11346002)(6916009)(76116006)(66446008)(66476007)(6486002)(229853002)(25786009)(46003)(86362001)(64756008)(36756003)(256004)(66556008)(66946007)(186003)(14444005)(33656002)(305945005)(81166006)(316002)(58126008)(2906002)(54906003)(81156014)(76176011)(14454004)(5660300002)(6506007)(6116002)(6246003)(6436002)(4326008)(7736002)(8676002)(8936002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1994; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HECLfXSU5WY5fH1O+GHkCmwdTM47eO9+N2oF78IVbfkZUGBIyUUTNoHJY8aHXDtgZXBUyAWTqaCXEoPwxMvPxsWTd875FB9Hzyvjnaa2oCut4xSK2XIlSrfHW/8T+B3jPgmgXeuYcSpgnhAUUlMMPGz2pLmYAv1bTt3SyZ8syxgVEjNa5k0bLfdyRek5XvJKKO7zSZEm2nBYs2NfHum63CPDKiEXQF25TUEFcoW5iX1cgOXbTrCMh7FkoP25dhweILEUCENvoD4keQrjtCgWC42Y5zISFRdWVPk0Z1vlkQ/zONZTbvYSogQuaYfIHC3gJGs5RVOOB+P4mX/UpNHAOGyG7RXQ562wJcC90G/KpJoMj0Pupun9+zOUYRd/i9qI2LZoJs9tmkiPfLeet3qFcpr0zaF08GaSy8I6ro9jrFfqpMXf6YsFSZ3yhITXeYQc x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <514D61D7B6782C4A85292A77F6A94E7B@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3158de7e-ff74-48bc-3955-08d777e2b7e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2019 11:19:52.6850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DfF6iV/OmXLKPE4B/rG5K6q9KtYSDrkLmb7mJoU1ukQoMnKOLMwg7NpXjPjet26MjiNd4g5yv9lA/6nkcxALTQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1994 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-opsec-v6-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 11:19:58 -0000 VGhhbmsgeW91IHZlcnkgbXVjaCBMaW5kYTogdGhpcyB3YXMgYSBsb25nIGRvY3VtZW50IHRvIHJl YWQgYW5kIHJldmlldyA7LSkNCg0KLcOpcmljDQoNCu+7v09uIDAyLzEyLzIwMTksIDE5OjE5LCAi TGluZGEgRHVuYmFyIHZpYSBEYXRhdHJhY2tlciIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0K DQogICAgUmV2aWV3ZXI6IExpbmRhIER1bmJhcg0KICAgIFJldmlldyByZXN1bHQ6IFJlYWR5DQog ICAgDQogICAgSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2Vj dXJpdHkgZGlyZWN0b3JhdGUncw0KICAgIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVU RiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZQ0KICAgIElFU0cuICBUaGVzZSBjb21t ZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUNCiAgICBz ZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBz aG91bGQgdHJlYXQNCiAgICB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3Qg Y2FsbCBjb21tZW50cy4NCiAgICANCiAgICBUaGlzIGRvY3VtZW50IGlzIHJlYWxseSBnb29kLCBp dCBzdW1tYXJpemVzICB0aGUgSVB2NiBzZWN1cml0eSBpc3N1ZXMgZnJvbQ0KICAgIG11bHRpcGxl IFJGQ3MuIEkgdGhpbmsgSUVURiBzaG91bGQgZG8gbW9yZSBvZiB0aGlzIGtpbmQgb2Ygc3VtbWFy eSBkb2N1bWVudHMNCiAgICB0aGF0IGNvbGxlY3QgaGlnaCBsaWdodHMgZnJvbSBtdWx0aXBsZSBS RkNzLCB0byBtYWtlIGl0IGVhc2llciBmb3IgbmV0d29yaw0KICAgIG9wZXJhdG9ycy4NCiAgICAN CiAgICBMaW5kYSBEdW5iYXINCiAgICANCiAgICANCg0K From nobody Tue Dec 3 13:49:53 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738C8120044 for ; Tue, 3 Dec 2019 13:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 vzmEBomc4LfN for ; Tue, 3 Dec 2019 13:49:50 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2A5C212003E for ; Tue, 3 Dec 2019 13:49:50 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xB3Lnil7020489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 3 Dec 2019 16:49:48 -0500 Date: Tue, 3 Dec 2019 13:49:44 -0800 From: Benjamin Kaduk To: Carl Wallace Cc: secdir@ietf.org Message-ID: <20191203214944.GP32847@mit.edu> References: <2572EB02-5F21-451B-95EA-B7D8D2207AC8@redhoundsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2572EB02-5F21-451B-95EA-B7D8D2207AC8@redhoundsoftware.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-pim-drlb-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 21:49:52 -0000 Hi Carl, Thanks for the review! I'm also unclear on why migration is out of scope, and filed a Discuss ballot to seek clarity. (I also asked for clarity improvements on a couple other points that are not particularly security-related.) -Ben On Sat, Nov 09, 2019 at 05:49:33AM -0500, Carl Wallace wrote: > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > This document defines an extension to the PIM-SM protocol to allow some responsibilities of is Designated Router to be distributed amongst a set of routers instead of the router elected as DR. > > The document is well written and has clear examples. The security considerations references those of the DR as applicable to the new mechanism. This seems fine. One minor comment, the last sentence in the operational considerations section seemed odd to me. It wasn't clear to me why migration between different hash algorithms is not considered in this document (or why this is much different from changes in DR priority, which is also required to be considered as a GDR candidate). > > The document is ready to my eye. > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Thu Dec 5 08:42:24 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0508120870; Thu, 5 Dec 2019 08:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ghedini.me 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 TH9x63BEUnpP; Thu, 5 Dec 2019 08:42:20 -0800 (PST) Received: from blastoise.ghedini.me (blastoise.ghedini.me [IPv6:2001:19f0:6c01:a56:5400:1ff:fe4a:5694]) (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 6A625120865; Thu, 5 Dec 2019 08:42:18 -0800 (PST) Received: from localhost (unknown [IPv6:2a02:8010:6241:1:dd55:accf:56f0:dc88]) by blastoise.ghedini.me (Postfix) with ESMTPSA id 0840ADF287; Thu, 5 Dec 2019 16:42:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1575564136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KpZLPiYmt/m1coi0nQXt8YhbFG98w2KwkdUUeDqNK3U=; b=VSgq/asPqJ9njj3XNg/B9C9LAeSzxbNoCQomPrLPsi8SQYyaREnaStD9KU5gGYpOBuKulQ r9wYCW58IIi+jEfuV7bYY+DTz6hhgtSIU/17XI5EQ7Ulf0Gf9JERcH/Xq+jf7ImRFBbNiN 0nNBf1ji7/v8yUlcomy65iutVWAAp/k= Date: Thu, 5 Dec 2019 16:42:12 +0000 From: Alessandro Ghedini To: Christian Huitema Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, tls@ietf.org Message-ID: <20191205164212.GB12839@sokka.flat11.house> References: <157498929764.5575.7815291384505057169@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157498929764.5575.7815291384505057169@ietfa.amsl.com> User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [secdir] [TLS] Secdir last call review of draft-ietf-tls-certificate-compression-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 16:42:23 -0000 On Thu, Nov 28, 2019 at 05:01:37PM -0800, Christian Huitema via Datatracker wrote: > Reviewer: Christian Huitema > Review result: Has Issues > > I have reviewed draft-ietf-tls-certificate-compression-07 as part of the > security directorate's ongoing effort to review all IETF documents being > processed by the IESG. These comments were written primarily for the benefit of > the security area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. Thank you for the review! > Draft-ietf-tls-certificate-compression-07 defines two new TLS extensions to > negotiate and then apply compression of the Certificate message. The draft is > clear and well written, and the extensions are already widely deployed. I would > like to say "ready", but I have to say "almost". > > This document is almost ready, except for one nit and one issue. > > First, one nit. The draft references the "Certificate message", but there is no > formal reference section 4.4.2 of RFC8446. Please add that, maybe at the > beginning of section 4. It may seem obvious to members of the TLS WG, but > uninformed readers will appreciate. Makes sense. I created https://github.com/tlswg/certificate-compression/pull/30 to address this. > Second, my actual concern. Compression may leak information, because different > certificate chains will compress differently. The authors mention that an > attacker will not be able to inject data in the certificate chain, and thus > that attacks of the CRIME variety are unlikely. That's correct, but that's not > the entire story. > > TLS 1.3 will encrypt the compressed certificate message but the length of that > message could be deduced from the length of the server's encrypted message. > Attackers might be able to derive from that length the identity of the server, > even if the SNI is encrypted. > > One could say that in the absence of compression the length of the certificate > chain is also available. Indeed, the problem is flagged in > draft-ietf-tls-esni-05, which states in section 5.3 that "it (the server) > SHOULD pad the Certificate message, via padding at the record layer, such that > its length equals the size of the largest possible Certificate (message) > covered by the same ESNI key." > > Certificate compression introduces a level of complexity here. If only some > servers in the anonymity set support compression, attackers can work with a > smaller anonymity subset. If all attackers support compression, the padding > should try to match the largest Compressed Certificate. > > It might be good to discuss this issue in the security consideration section. I agree tha this is worth discussing, but it seems like it belongs in the ESNI draft itself, so implementers of ESNI will be more likely to take compression into consideration. That is, we can expand the section you quoted to also explicitly mention certificate compression. What do you think? I can look into proposing a PR for this. Cheers From nobody Thu Dec 5 09:22:26 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6537F120891 for ; Thu, 5 Dec 2019 09:22:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157556654541.16408.13759220519735452314.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2019 09:22:25 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 17:22:25 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-12-05 Reviewer LC end Draft John Bradley 2019-11-22 draft-schaad-cbor-content-02 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-11 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 For telechat 2019-12-19 Reviewer LC end Draft Alan DeKok 2019-11-27 draft-ietf-6man-ra-pref64-08 Shawn Emery R2019-05-31 draft-ietf-bfd-vxlan-09 Daniel Franke 2019-12-02 draft-ietf-mboned-driad-amt-discovery-09 Melinda Shore R2019-11-07 draft-thaler-iftype-reg-06 Sean Turner 2019-11-25 draft-ietf-nfsv4-rfc5661sesqui-msns-03 Last calls: Reviewer LC end Draft John Bradley 2019-11-22 draft-schaad-cbor-content-02 Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-06 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-17 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Alan DeKok 2019-11-27 draft-ietf-6man-ra-pref64-08 Donald Eastlake 2019-12-16 draft-nottingham-rfc7320bis-02 Donald Eastlake 2019-11-14 draft-ietf-hip-dex-11 Shawn Emery R2019-05-31 draft-ietf-bfd-vxlan-09 Daniel Franke 2019-12-02 draft-ietf-mboned-driad-amt-discovery-09 Tobias Gondrom 2019-12-02 draft-ietf-tls-tls13-cert-with-extern-psk-03 Dan Harkins R2019-10-03 draft-ietf-dtn-bpsec-13 Leif Johansson 2019-12-19 draft-ietf-jmap-websocket-04 Charlie Kaufman 2019-12-13 draft-ietf-ace-oauth-params-06 Scott Kelly 2019-12-13 draft-ietf-bess-nsh-bgp-control-plane-12 Stephen Kent 2019-12-13 draft-ietf-ace-oauth-authz-27 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Melinda Shore R2019-11-07 draft-thaler-iftype-reg-06 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Sean Turner 2019-11-25 draft-ietf-nfsv4-rfc5661sesqui-msns-03 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-11 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Tero Kivinen Watson Ladd Ben Laurie Barry Leiba Chris Lonvick Aanchal Malhotra David Mandelberg Catherine Meadows Alexey Melnikov Daniel Migault From nobody Thu Dec 5 13:42:47 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADE6120861 for ; Thu, 5 Dec 2019 13:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 DqT5ah7OitQc for ; Thu, 5 Dec 2019 13:42:42 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 23E6112080C for ; Thu, 5 Dec 2019 13:42:29 -0800 (PST) Received: from xse482.mail2web.com ([66.113.197.228] helo=xse.mail2web.com) by mx105.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1icyt3-0006nY-Hr for secdir@ietf.org; Thu, 05 Dec 2019 22:42:22 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 47TTgr06FFz1sNM for ; Thu, 5 Dec 2019 13:41:44 -0800 (PST) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1icysZ-0000pm-SX for secdir@ietf.org; Thu, 05 Dec 2019 13:41:43 -0800 Received: (qmail 20224 invoked from network); 5 Dec 2019 21:41:43 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Dec 2019 21:41:43 -0000 To: Alessandro Ghedini Cc: last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, tls@ietf.org, secdir@ietf.org References: <157498929764.5575.7815291384505057169@ietfa.amsl.com> <20191205164212.GB12839@sokka.flat11.house> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <1740c80a-498f-e706-5622-82d8115cf773@huitema.net> Date: Fri, 6 Dec 2019 05:41:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191205164212.GB12839@sokka.flat11.house> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.197.228 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0fKZ8wcD78QFAaYhvfMzLIKpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcQkv3rfK9nOh84B6FNp+WsRX qYbtEQV1z/L435ZRxFRNOTp+0x+QL97/ONliqti8+rYZvu7UEJiU3s27VgKHO7lwS3dBJTnTxDoD vBGGxph9w6EwXICYy0ePXtGEMhqrwBb733ZN4jAbrTI5wHo5JWU6UgOqKJ9sMwhVoOBGSAIboXtx P9OF0EfNs5TqNq2Yhy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8afR67T7N272aMX0YT5C7M3G9grJ4FLXB655ZOcUVvzzuxEmGYqVhUwHt3FyBle89H2 ie80q3LAG2MiIaIREzT1xNjuO97khcUFBr/guEWv1bdCp3Zd9clP8wSiJZWbJCj+xRrjVmRxpGtS cvUmgj1Lh2ucww3d57GlK6qetf1rVl2jZAOanSBpz6Rja2u/0jLtD+OxCJVVhiVLuak5RqKY4yQh OdVBLH3+FamZQxSxsvysta6u1iHEyuS7GD1uvcqLeOYbpEKKp/lSShLrjKR7JOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [secdir] [Last-Call] [TLS] Secdir last call review of draft-ietf-tls-certificate-compression-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 21:42:44 -0000 On 12/6/2019 12:42 AM, Alessandro Ghedini wrote: > On Thu, Nov 28, 2019 at 05:01:37PM -0800, Christian Huitema via Datatra= cker wrote: >> Reviewer: Christian Huitema >> Review result: Has Issues >> >> I have reviewed draft-ietf-tls-certificate-compression-07 as part of t= he >> security directorate's ongoing effort to review all IETF documents bei= ng >> processed by the IESG. These comments were written primarily for the b= enefit of >> the security area directors. Document editors and WG chairs should tre= at these >> comments just like any other last call comments. > Thank you for the review! > >> Draft-ietf-tls-certificate-compression-07 defines two new TLS extensio= ns to >> negotiate and then apply compression of the Certificate message. The d= raft is >> clear and well written, and the extensions are already widely deployed= =2E I would >> like to say "ready", but I have to say "almost". >> >> This document is almost ready, except for one nit and one issue. >> >> First, one nit. The draft references the "Certificate message", but th= ere is no >> formal reference section 4.4.2 of RFC8446. Please add that, maybe at t= he >> beginning of section 4. It may seem obvious to members of the TLS WG, = but >> uninformed readers will appreciate. > Makes sense. I created https://github.com/tlswg/certificate-compression= /pull/30 > to address this. Thanks. > >> Second, my actual concern. Compression may leak information, because d= ifferent >> certificate chains will compress differently. The authors mention that= an >> attacker will not be able to inject data in the certificate chain, and= thus >> that attacks of the CRIME variety are unlikely. That's correct, but th= at's not >> the entire story. >> >> TLS 1.3 will encrypt the compressed certificate message but the length= of that >> message could be deduced from the length of the server's encrypted mes= sage. >> Attackers might be able to derive from that length the identity of the= server, >> even if the SNI is encrypted. >> >> One could say that in the absence of compression the length of the cer= tificate >> chain is also available. Indeed, the problem is flagged in >> draft-ietf-tls-esni-05, which states in section 5.3 that "it (the serv= er) >> SHOULD pad the Certificate message, via padding at the record layer, s= uch that >> its length equals the size of the largest possible Certificate (messag= e) >> covered by the same ESNI key." >> >> Certificate compression introduces a level of complexity here. If only= some >> servers in the anonymity set support compression, attackers can work w= ith a >> smaller anonymity subset. If all attackers support compression, the pa= dding >> should try to match the largest Compressed Certificate. >> >> It might be good to discuss this issue in the security consideration s= ection. > I agree tha this is worth discussing, but it seems like it belongs in t= he ESNI > draft itself, so implementers of ESNI will be more likely to take compr= ession > into consideration. That is, we can expand the section you quoted to al= so > explicitly mention certificate compression. What do you think? I can lo= ok into > proposing a PR for this. I agree with you that the bulk of the work belongs in the ESNI draft. However, it would be nice to have a short reminder of the issue in the security section of the compression draft. Something like: Although the Certificate extension is encrypted in TLS 1.3, third parties can deduce some information about the certificate from the length of the handshake messages. Compression does not prevent this issue, as different certificate chains will compress to different lengths. When privacy is desired, implementers need to consider appropriate padding strategies. Discussion of these padding strategies is out of scope for this document. -- Christian Huitema From nobody Fri Dec 6 09:45:41 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E90A6120170; Fri, 6 Dec 2019 09:44:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1575654251; bh=jhAEsbQnvB4LK9Y2zeRRZ8CbX5grb2A2e76bIOfSR7c=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=scs3+5a8BlMfOclVTpNfWnnONPqNmxGpCZCHnHX2gni5z6Ni12G0ObI7FQwyLFfOo nXPMy0/RKZOp5qVhYETobRye/NpfdMXjxkbbSy6DPUVrwZYgYUporMN9ifd5Tg6Gbo EQLdn9Klt3ITbAbZAnM9OtXTTCOlinRcqqMiCItg= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Dec 6 09:44:03 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB5E1209B1; Fri, 6 Dec 2019 09:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1575654238; bh=jhAEsbQnvB4LK9Y2zeRRZ8CbX5grb2A2e76bIOfSR7c=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=ny118l9RWWaWkHmGYn7urgMeSeAoH8mLzDjbVGNEUIRfkPtJGjC8yAwmyT4/GRYzl ydAE+2oBnp2y5yf4jM+KyolT2Mg5O/GpDhuDJ4DGs2l/iqfBJa6nYhNRO8phKvPe/0 IpiSZlS3HADbjYm6qP2Vfp8qrn5Ge/0LVyYOqHA4= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC63A1200A3 for ; Fri, 6 Dec 2019 09:43:51 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <157565423170.20984.10933325566958796825.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2019 09:43:51 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 06 Dec 2019 09:45:38 -0800 Subject: [secdir] [new-work] WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 17:44:15 -0000 The JSON Mail Access Protocol (jmap) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2019-12-16. JSON Mail Access Protocol (jmap) ----------------------------------------------------------------------- Current status: Active WG Chairs: Bron Gondwana Jim Fenton Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Alexey Melnikov Barry Leiba Mailing list: Address: jmap@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/jmap Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap Group page: https://datatracker.ietf.org/group/jmap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/ The JMAP protocol defined in draft-ietf-jmap-core is designed to be extensible to multiple datatypes which are useful for personal information management related to email stores. Now that draft-ietf-jmap-mail is completed, the working group will produce specifications for related data types, beginning with calendars and contacts. The calendar work will be based on draft-ietf-calext-jscalandar as the data format. This working group will consult with the CALEXT working group to ensure that calendar access via JMAP remains compatible with existing calendar standards. The contact work will begin with a JSON format for contact data based upon the work begun in draft-stepanek-jscontact, and in consultation with other users of contact data within the IETF and outside to build an extensible format. Where possible, this format will retain the ability to convert backwards and forwards to RFC6350 vCard format. This format will then be used as the basis of JMAP object types for contacts. Extensions to the existing core and mail JMAP specifications are also within scope for this working group, for example any additional parts of SIEVE, IMAP, SMTP submission, as well as transport of JMAP over WSS (WebSocket over TLS, RFC 6455). Work on JMAP extensions will be bound by the following constraints: 1) The work of this group is limited to developing protocols for a client synchronising data with a server. Any server-to-server issues are out of scope for this working group. 2) Object models will use existing IETF work where possible. 3) JMAP Extensions will be built following the core principles: 3.1) The server will not be required to perform work not explicitly requested by the client, and the default should always be the mode which requires the least server work. 3.2) The client can discover limits enforced by the server on resources or request complexity. 3.3) Where side effects generated by the server are optional, the protocol will default to no side effects, and the client must explicitly request that those side effects happen (for example: sending a calendar invitation or reply when updating an event) The working group will deliver documents for the following: - JMAP access to calendars using the JSCalendar format - JSON formats for representing contacts and groups of contacts (JSContact) - JMAP access to addressbooks using the JSContact format - Accessing JMAP over Websockets - Handling of S/MIME email messages (e.g. signature verification) over JMAP - Message Disposition Notifications (RFC 8098) via JMAP - Other extensions which the working group considers related to email and compatible with the constraints listed above Also within scope for this working group are informational documents for converting between JMAP data representation and other formats already in wide use which can be used to specify the same underlying data. Milestones: Dec 2019 - Submit Message Disposition Notification document to the IESG Jan 2020 - Adopt a document for a JSON Contact format (after recharter) Feb 2020 - Submit JMAP Quotas document to the IESG Feb 2020 - Submit JMAP S/MIME signature validation document to the IESG Feb 2020 - Adopt a document for S/MIME key management and server side signing/encryption Jul 2020 - Adopt a document defining JMAP access to addressbooks Nov 2020 - Submit JMAP Calendars document to the IESG Dec 2020 - Submit document with guidance for implementation of IMAP servers and proxies (Informational) Dec 2020 - Submit JSON Contact document to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Dec 6 11:39:34 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18B912004A; Fri, 6 Dec 2019 11:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=heapingbits.net header.b=h3KrKBu1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZU2A6nE4 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 XDVJDKhYBBUx; Fri, 6 Dec 2019 11:39:29 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D351200FE; Fri, 6 Dec 2019 11:39:29 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id AAE55229C7; Fri, 6 Dec 2019 14:39:28 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Fri, 06 Dec 2019 14:39:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm3; bh=It zHUsl8ExaNvY3ONA3dhdKKicHCpUF6j9QdP+t6ll4=; b=h3KrKBu1ujADkBZQyh +dUYRFd36xHyydGpvzPZeY82Fgj6e0sz7b4dP45BcDkl5H4rQsXo8+x9qbVPStUy +q0pncFwy/84IfZvmGQEGAHH2lGFyudwYvwSUp4iYKY8wCwUY59aRY0Tgu+8BNh8 PIzJcdn/MrOrb+VEEv5jLibddEc6qFEE5baNmPaywvZatGh8iYSm4+ybiXy6vuNC ENzisXDn0FT+3x+9TuG/XbU+uNHTwWhLXZux7lnAXXjuMmkPXoTRXzSn6BtlE4Sz /Vh3OSpDtHFRVFjTx6n1mzTBqmn7RrSKf8TjJupU1JpqT50o29gb2SowkESH+lYH Dvng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ItzHUsl8ExaNvY3ONA3dhdKKicHCpUF6j9QdP+t6l l4=; b=ZU2A6nE4vc9raIwCK/YKpugZpwtls0xcVe5szboo9WA9mTahYz7n2io/e E6lJ8DEZC0PLxyky0JlXDbNYs2/LeOvWndjjwKWJ8tca0Op5O/NLw554lDkBExqm 4Ikb9rDolMgeDzesi9XmxVO7mrEHb/fqWfnynk8fma5xdkC9Zn4qZ44E4zlBNf92 HuPOGz4tWWs3td3RZ0/6W9BR6+usW2PhiNN2WoX2lBl0EiqgUYwBrmnIxiBDK4Cx bIz6yQHrJXzlyF2lHbzouIIpnDjcw93Ad5vGO8nWzpo/OgDpO1Wg6zDLBYw74myc hdqne83nb/yRuxIWFi7wpjs4CVRkg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudekfedguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdev hhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnh gvtheqnecuffhomhgrihhnpehmihhtrhgvrdhorhhgpdhivghtfhdrohhrghenucfrrghr rghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvthenucevlh hushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 55EC63C00A1; Fri, 6 Dec 2019 14:39:28 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-612-g13027cc-fmstable-20191203v1 Mime-Version: 1.0 Message-Id: <325f1938-7028-4f0c-ae16-6251a9ca4d6d@www.fastmail.com> In-Reply-To: References: <157309030845.20168.4543125034732217684@ietfa.amsl.com> <576b4769-ae0f-4821-a127-12a8a3d05de1@www.fastmail.com> Date: Fri, 06 Dec 2019 11:39:08 -0800 From: "Christopher Wood" To: "Brian Sipos" , "secdir@ietf.org" Cc: "draft-ietf-dtn-tcpclv4.all@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-dtn-tcpclv4-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 19:39:33 -0000 Thanks for the updates, Brian! And apologies for the delay in my respons= e. I reviewed the diff and the changes look good to me. I only have one = nit: I might rename the title of section 8.4 to "Active Transport Securi= ty Stripping" to distinguish this from the previous passive attacks. Best, Chris On Mon, Nov 25, 2019, at 1:39 PM, Brian Sipos wrote: > =20 > Christopher, > A new draft has been posted [1] which should address all of your=20 > comments on the -15 draft. Most of the changes [2] are to either fix=20= > typos and inconsistencies or to add requirements supporting TLS use an= d=20 > threat modeling. > Our AD has requested a re-review of the new draft to verify that ther= e=20 > are no more issues present. Would you be able to review the new draft=20= > version? > Thank you, > Brian S. >=20 > [1] https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-16 > [2] =20 > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dtn-tcpclv4-15&url2=3Dd= raft-ietf-dtn-tcpclv4-16&difftype=3D--html > *From:* Brian Sipos > *Sent:* Wednesday, November 13, 2019 10:53 > *To:* Christopher Wood ; secdir@ietf.org=20 > > *Cc:* last-call@ietf.org ;=20 > draft-ietf-dtn-tcpclv4.all@ietf.org=20 > ; dtn@ietf.org > *Subject:* Re: [Last-Call] Secdir last call review of=20 > draft-ietf-dtn-tcpclv4-15=20 > Christopher, > Thank you for these comments. My responses are inline below with=20 > prefix "BS: ". I have been making edits to a future draft which is not= =20 > yet uploaded. >=20 > *From:* Christopher Wood > *Sent:* Wednesday, November 6, 2019 20:57 > *To:* secdir@ietf.org > *Cc:* last-call@ietf.org ;=20 > draft-ietf-dtn-tcpclv4.all@ietf.org=20 > ; dtn@ietf.org > *Subject:* Re: [Last-Call] Secdir last call review of=20 > draft-ietf-dtn-tcpclv4-15=20 > Oops. Datatracker butchered the formatting. Let's try that again: >=20 > ~~~ >=20 > Reviewer: Christopher Wood > Review result: Has Issues >=20 > Comments: > - Section 1.1, fourth bullet: I assume certificate revocation is also= =20 > out of scope. If so, listing this explicitly might be useful. If not,=20= > why not? Relatedly, is pre-shared key authentication supported? If so,= =20 > perhaps we should mention that this too is out of scope? > BS: I added explicit out-of-scope indication for both revocation and=20= > PSK (and other non-certificate) use. >=20 > - If TLS sits below TCPCL and if resumption is used, what is the=20 > definition of a session's lifetime? Is it still bound to the underlyin= g=20 > TCP connection lifetime? I would suggest that the definition be=20 > generalized to accommodate TLS, e.g., perhaps the lifetime is bound to= =20 > the underlying transport state lifetime. Relatedly, is TLS session=20 > resumption supported (or encouraged)? When discussing TLS session=20 > establishment in Section 4, this seems to be omitted. > BS: I added text to Section 4 to indicate both the lifetime of TLS=20 > sessions and the ability to attempt to resume sessions. >=20 > - Section 3.2, first paragraph: What does "initiate TLS security"=20 > mean, exactly? Does this mean the initiator sends a TLS ClientHello=20= > upon TCP connection establishment, or only after some other TCPCL=20 > headers are exchanged? Similarly, is the Node ID transferred used in=20= > authenticating such a TLS connection? If so, how? Is the Node ID sent=20= > as the TLS SNI, as hinted at in Section 4.4.1 and 4.4.2, is it include= d=20 > in the responder's certificate SAN list, etc? I think specific details= =20 > are needed here, perhaps with forward pointers to Section 4 as needed.= > BS: I rephrased the first paragraph and added a reference to Section 4= .=20 > The text in Section 3 is supposed to be higher-level and informative,=20= > where Section 4 is requirements. >=20 > - Section 3.2: It's not clear to me how SESS_TERM translates to=20 > graceful TLS termination (to avoid truncation attacks). The state=20 > machine diagram outlined in Section 3.3 suggests that SESS_TERM, once=20= > negotiated, does imply the end of the data transfer. It therefore seem= s=20 > possible for an attacker to truncate data sent between receipt of=20 > SESS_TERM and TCP FIN by simply closing the TCP connection. It would b= e=20 > good to require use of a TLS closure alert when finished to avoid this= =20 > type of truncation. (Maybe BP prevents this by marking data transfer=20= > lengths. However, even if that's the case, proper use of TLS seems=20 > prudent.) > =E2=80=8BBS: I added a requirement to send Closure Alert before shutti= ng down=20 > the TLS session. The TCPCL messages are all fixed-length or=20 > self-indicated length so there is no possibility of data truncation. >=20 > - Section 4, first paragraph: If entities are encouraged to keep=20 > sessions alive for as long as possible, guidance on how to update TLS=20= > keying material (via key updates or explicitly tearing down the=20 > connection and starting anew) seems prudent. TLS has a bound on how=20= > much data can be encrypted under one key.=20 > BS: I added text to Security Considerations section to include a=20 > reference about key use limits and key updates. >=20 > - Section 4: This text: >=20 > Once a TCP connection is established, each entity MUST immediately > transmit a contact header over the TCP connection. >=20 > suggests that TLS does *not* proceed as normal upon TCP connection=20= > establishment. This is quite problematic, since any active attacker ca= n=20 > simply muck with the ContactHeader CAN_TLS bit to disable TLS, right?=20= > Is this threat not considered in scope? Relatedly, what is the threat=20= > model? (SSL stripping is mentioned in Section 8, but without mention o= f=20 > a threat model.) "Secure" sessions subject to active downgrade do not=20= > offer much in the way of security, and the document should acknowledge= =20 > that in the Security Considerations. Concretely, how about the=20 > following text to replace the second paragraph in Section 8? >=20 > TCPCL does not protect against active network attackers. In particula= r, an > active man-in-the-middle attackers to set the CAN_TLS flag to 0 on ei= ther=20 > side of a TCPCL ContactHeader exchange. This leads to the "SSL Stripp= ing"=20 > attack described in [RFC7457].=20 >=20 > If TLS is desired for use on any TCPCL network, it is strongly=20 > encouraged that > the security policy disallow use of TCPCL when "Enable TLS" is > negotiated to false. This requires that the TLS handshake occurs, > regardless of the policy-driven parameters of the handshake and > policy-driven handling of the handshake outcome. > BS: Your statements are definitely true. The purpose of the CAN_TLS=20= > flag has been clarified in Section 4.2 "Contact Header", and Section 8= =20 > is updated to have a stronger recommendation for policy to require TLS= =20 > use when TLS is available. > The purpose of the CAN_TLS flag is to allow the use of TCPCL on=20 > entities which simply do not have a TLS implementation available. This= =20 > was a stated goal of the DTN WG due to the desire to use TCPCL in=20 > environments where the entities are constrained (TLS is unavailable)=20= > but the network is trusted. > Regarding the threat model, this is something I need to look into and=20= > find some examples of in other RFCs. >=20 > - Section 4.4.2: Why is the recommendation that entities "SHOULD=20 > terminate the session" if the peer's certificate is untrusted, rather=20= > than "MUST terminate the session"? In what circumstances would an=20 > entity not want to terminate the connection? (Later text mentions that= =20 > this may be allowed by "security policy," in which case we should=20 > mention that here.) > BS: I updated these requirements to SHALL and made sure they are all=20= > conditioned on policy rules. >=20 > - Section 4.4.2, fourth paragraph: Why is host name validation done=20= > *after* TLS completes, rather than during the connection? This seems=20= > wrong, though I suspect I'm misunderstanding the details. > BS: I updated the text to read "Either during or immediately after the= =20 > TLS handshake..." The only reason for this is some TLS implementations= =20 > allow interrupting the handshake but some only allow inspecting the=20= > results of the handshake. >=20 > - 4.7, Enable TLS: If security policy allows the absence of TLS, why=20= > not just always use TLS and have that policy tune TLS peer=20 > authentication? (See https://tools.ietf.org/html/rfc7858#section-4.1=20= > for an example of this.) It seems strange that opportunistic security=20= > is supported (and desired as a feature?) yet not always used. > BS: Per the earlier response to Section 4 text, the reason to allow=20= > non-TLS sessions is purely for constrained entities. The text in=20 > Section 4.2 and Section 8 are updated to clarify the CAN_TLS flag to=20= > indicate the presence of TLS in the network stack, not really a=20 > configuration parameter. >=20 > - Section 8: I see no reason why one would want to use TLS for=20 > authentication without any form of confidentiality. I would remove tex= t=20 > referencing this use case. > BS: I removed this text to avoid confusion. >=20 > - Section 8: In describing volumetric DoS attacks, it might help to=20= > consider the "opposite" sort of attack, e.g., similar to what the=20 > HTTPT/2 data dribble attack exploited?=20 > (https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2019-9511) > BS: This is a good catch, I added Section 8 text to warn against=20 > accepting too-small Segment MRU or Transfer MRU parameters. >=20 > Nits: > - Section 2.1, TCP Connection: typo in "and other states association"= =20 > (should be associated?) > BS: Fixed this typo. > - Section 2.1, Transmission Intermediate Progress: typo "transferr"=20= > (and elsewhere) > BS: Fixed this typo. > - Inconsistent notation of SESS_TERM (it's referred to as SESSTERM in=20= > lots of places) > BS: The "SESS_TERM" was a message while a "SESSTERM" was an activity. = I=20 > renamed the activity to "ST" to be consistent with other abbreviated=20= > activity names. > - Section 3.4, last paragraph: typo "from from" > BS: Fixed this typo. > - Section: typo "negotating" > BS: Fixed several of this typo. > From nobody Sun Dec 8 10:19:01 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1871E12002E; Sun, 8 Dec 2019 10:18:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Stephen Kent via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ace-oauth-authz.all@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stephen Kent Message-ID: <157582913296.4934.15140560361782598959@ietfa.amsl.com> Date: Sun, 08 Dec 2019 10:18:53 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ace-oauth-authz-27 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2019 18:18:53 -0000 Reviewer: Stephen Kent Review result: Has Issues SECDIR review of draft-ietf-ace-oauth-authz-27 The summary of the review is almost ready, but needs some revisions. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This is a long document- 86 pages! It is a proposal for how to use OAuth 2.0 and CoAP to provide authorization security for Internet of Things (IoT) devices. IoT devices are often criticized as not being very secure, so this seems like a useful initiative. RFC 7228 (Technology for Constrained-Node Networks, and Informational document) is cited as inspiration and reference for this work. CoAP (RFC 7252) is expressly designed for the sort of environment that characterizes many IoT devices, hence is seems a natural choice for this authorization-focused framework. OAuth is not as obvious a candidate building block in this context, e.g., it is expressly designed for the HTTP context, yet CoAP is cited as the replacement for HTTP. This document adapts OAuth for the CoAp context. This document has an extensive, 6-page Security Considerations section, appropriate for a document specifying an authorization framework. It begins by citing the OAuth 2.0 specification, the OAuth 2.0 threat model (RFC 6819), and OAuth 2.0 Token Introspection (RFC 7662). All three of these documents are relevant, and they contain substantial Security Consideration sections. Section 6.1 deals with security for the tokens that are transmitted to convey authorization information. In general the requirements and advice provided here are good; I would prefer to see the admonition against use of a shared secret key for a group of serves to be a MUST NOT, as opposed to just NOT RECOMMENDED. I am not convinced that the suggestion for short lifetime tokens is necessary; we have seen how short duration certificate lifetimes and frequent CRL issuance in PKI contexts often is neither required nor advisable. This section ends by noting that only client-initiated revocation of tokens is addressed by RFC 7009. The authors note that revocation of long lifetime token remains an open issue. If this is likely to be a common case for IoT devices, leaving this as a TBD is not great. Section 6.2 addresses communication security issues. The section opens by requiring an authorization server to offer confidentiality for client interactions, but the wording implies that a client need not make use of such protection. The reader is reminded that security requirements expressed in Section 5 of this document (a 25-page long section) MUST be addressed by a profile. I’d prefer to see references to specific parts of Section 5 that expressly addresses confidentiality, so that a reader can better understand when it is safe to reject the offer of confidentiality by a server. Encryption of CWTs is used as an example, which is appropriate because CBOR CWT is the default token format. The final paragraph of this section says that “developers MUST ensure that … ephemeral credentials … are not leaked to third parties.” This is good advice, but since adversaries are assumed to have physical access to IoT devices, the scope of this mandate is not clear. For example, is this text arguing for use of tamper-resistant hardware for storing private or session keys in IoT devices? Section 6.3 focuses on long-term credentials. The sections begins by noting the challenges associated with providing protection for such credentials in devices in publicly-accessible locations, explicitly referring to specialized hardware. This a good, clear statement, not like the ambiguous MUST at the end of 6.2. The text requires that compromise of a credential at one device MUST NOT lead to compromise of other credentials not linked to the device in question. However, the next sentence says that sharing of secret (and, presumably, private) keys is NOT RECOMMENDED. This is a somewhat inconsistent pair of statements; if secret keys are shared, then the MUST NOT will be violated, right? Why not just say that secret keys MUST NIOT be shared across devices? The section states that operators should have procedures to replace credentials that have been (or are suspected to have been) compromised. Why is this admonition not a SHOULD? The mildly-worded (“… also need to …) advice about decommissioning devices seems minimally helpful. If this is important than make it a SHOULD, if it’s not, then RECOMMEND it. Section 6.4 discusses the challenges associated with securing initial communication between a client and a resource server (RS). This communication makes use of the (appropriately-named) Creation Hints message defined in 5.1.2. The basis mechanism suggested here is use of a (possibly hard coded) list of trusted authorization servers (AS’s) and associated credentials, e.g., certificate fingerprints. The discussion here notes the potential for a DoS attack against an AS by a compromised RS, by having clients sends requests to the targeted AS. This is a useful comment, after noting that compromise of an RS would not cause an AS to grant requests to clients that it is not serving. Section 6.5 summarizes the “minimal” communication security requirements for the elements of the system described in this document (clients, AS’s and RS’s). I think it’s useful to collect these requirements in one place, although they have been described in various parts of Section 5. Unfortunately, the first sub-section seems to contradict Section 6.2! Specifically the text here says that all communication between a client and an AS MUST be encrypted, where as 6.2 requires only that an AS offer confidentiality. This inconsistency needs to be reconciled. The next subsection seems to be consistent. The final subsection (C-RS) notes the challenges of initial C/RS communication, and offers some suggested approaches. Some of the wording here is awkward. For example, the text notes that DTLS with server-side authentication “can be possible and are RECOMMENDED if supported by both parties.” It would be better to state that “DTLS with server-side authentication is a RECOMMENDED mechanism for use in this context, and SHOULD be employed if supported by both the C and the RS.” Section 6.6 deals with token lifetimes. The section begins by suggesting use of nonces (as described in 5.1.2) to counter replay attacks in the event of “clock drift” between an RS and an AS. I appreciate the analysis of mechanisms that can be used to address the clock drift issue, including the discussion of potential problems associated with using nonces in the face of a reboot. However, the text provides no indication of how much “drift” is tolerable, vs. when use of nonces is needed, and 5.1.2 does not even mention clock drift. Perhaps the text can be revised to provide additional advice re clock drift. Section 6.7 very briefly discussed the issue of combining profiles. The bottom line is that the security of a profile MUST NOT depend on the assumption that the profile is used exclusively throughout a given deployment. That’s a nice, straightforward warning! Section 6.8 discusses circumstances in which data is transmitted and may not encrypted, e.g., error messages. The discussion here is fairly clear, and includes a RECOMMENTATION and a MUST, as well as an analysis of potential risks associated with transmitting different types of information w/o confidentiality protection. The section title says “unprotected” but this discussion focuses only on confidentiality, so a more descriptive title might help. Section 6.9 provides guidance on how to deal with the ambiguity of how to match an “audience” value to a specific resource server. The authors admit that the Section 5 discussion about the (optional) audience parameter in the OAuth token is vague. They note that this is intentional, to accommodate a wide range of deployment scenarios. Thus the discussion in this section provides guidance for several scenarios. This is a reasonable way to deal with the ambiguity from Section 5. Section 6.10 examines denial of service attacks in the context of “introspection,” an optional aspect of OAuth which may be employed in this framework. The text examines two DoS attacks, one against resource servers and one against authorization servers, and suggests mitigations for both. Section 7 discusses privacy implications of the proposed framework. The discussion here is useful, addressing a set of concerns that arise due to client interactions with the AS and RS elements of the framework. From nobody Sun Dec 8 13:26:53 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42483120059; Sun, 8 Dec 2019 13:26:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Melinda Shore via Datatracker To: Cc: last-call@ietf.org, draft-thaler-iftype-reg.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Melinda Shore Message-ID: <157584040819.5236.7473007997550218170@ietfa.amsl.com> Date: Sun, 08 Dec 2019 13:26:48 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-thaler-iftype-reg-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2019 21:26:48 -0000 Reviewer: Melinda Shore Review result: Ready This revision addresses the concerns I had with the -05 version of the document. From nobody Mon Dec 9 01:13:54 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70E112004D for ; Mon, 9 Dec 2019 01:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 FIiRgCfluxmG for ; Mon, 9 Dec 2019 01:13:51 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 CB958120168 for ; Mon, 9 Dec 2019 01:13:50 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id y19so10051811lfl.9 for ; Mon, 09 Dec 2019 01:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5hy2x8RiB0o7SG7DsRtAm56omGvRAzKw1uXMVHRAJU8=; b=ujcx81nAyeREwPg7RxCL2PhQ+jcapYvk1WPLkQaL9xS4kfYkSo1zssyNjEzfTMgI89 3XQS93NXTeikKytH4VehleAXPtAH5YYbzhUJq5ilhFLf029/5tqwYDAXQ8XGfQP2ZRTo +WkFDFmLOAPOU6irQGvbGfoUl9fvj8k7fC8Jmp3kOgUnhfS+rYot5Rg1NxbXvp98jDiY QXBH9Dz7bVyvhk1ujMTzWyHyYITKAFr2S2o2HXWfuNaQhIOwGxchJanEYQVYUTh1ENED bGE+UigNwLTgr3ix1+2QMS7Vz2HOf8hm6PYBUt53050KPR5PbG99nQa9qMgLAndPtFv0 TrMA== 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=5hy2x8RiB0o7SG7DsRtAm56omGvRAzKw1uXMVHRAJU8=; b=i97nGjyHTdkgDVDuL6aNKS+QrEB6vb9t2jEAyD+xhnO+PtdlcqlB52FnmwaAkMK7al zSODkwwO7WMP11j80Hdkiygj0HY8jBL5ZyS9DLGHnCgg37f2Xo6cEo6n5mRBQ1WDx3jl DrSz78dEM5A3/i4uz/6+AXjFrnRCGpsd/OFPkqam3hs9prVppsrzYZnghj/oFLYV/FzD BoUSsLeSdn+i1Ww2gXQ3nXQkZpAkFQkW/5apNlBw/fuXyVsYMjv/KEcCCLwu75bEPdJ0 IkT2wO/XG0vldRWdYFO3gQXNmAgpM0wwvRX0ckYxGH3mWXUepFjGfQW4hxBlbTfiTuNz 4x+g== X-Gm-Message-State: APjAAAX3lCnLQqrtmpSqf1E8vVUa0Mc+Nztn07YpUjAfAYp3gEH9CaHS ZDCX3bwVPcg50ovL/CzCaOoolvY73FXNHC0XjGK/Tw== X-Google-Smtp-Source: APXvYqwu8jqgC3QOIoXl07K5nCZJf7w1bFyLrjLsQuvuhZQ0+noHazt9+UeNVjuhK6V4vMoXl61O2CDRrvet0PuTKis= X-Received: by 2002:ac2:5549:: with SMTP id l9mr14613172lfk.53.1575882828621; Mon, 09 Dec 2019 01:13:48 -0800 (PST) MIME-Version: 1.0 References: <157498929764.5575.7815291384505057169@ietfa.amsl.com> <20191205164212.GB12839@sokka.flat11.house> <1740c80a-498f-e706-5622-82d8115cf773@huitema.net> In-Reply-To: <1740c80a-498f-e706-5622-82d8115cf773@huitema.net> From: Victor Vasiliev Date: Mon, 9 Dec 2019 04:13:37 -0500 Message-ID: To: Christian Huitema Cc: Alessandro Ghedini , last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, "tls@ietf.org" , secdir@ietf.org Content-Type: multipart/alternative; boundary="00000000000035a0aa059941d0c2" Archived-At: Subject: Re: [secdir] [Last-Call] [TLS] Secdir last call review of draft-ietf-tls-certificate-compression-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 09:13:53 -0000 --00000000000035a0aa059941d0c2 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 4:42 PM Christian Huitema wrote: > >> Second, my actual concern. Compression may leak information, because > different > >> certificate chains will compress differently. The authors mention that > an > >> attacker will not be able to inject data in the certificate chain, and > thus > >> that attacks of the CRIME variety are unlikely. That's correct, but > that's not > >> the entire story. > >> > >> TLS 1.3 will encrypt the compressed certificate message but the length > of that > >> message could be deduced from the length of the server's encrypted > message. > >> Attackers might be able to derive from that length the identity of the > server, > >> even if the SNI is encrypted. > >> > >> One could say that in the absence of compression the length of the > certificate > >> chain is also available. Indeed, the problem is flagged in > >> draft-ietf-tls-esni-05, which states in section 5.3 that "it (the > server) > >> SHOULD pad the Certificate message, via padding at the record layer, > such that > >> its length equals the size of the largest possible Certificate (message) > >> covered by the same ESNI key." > >> > >> Certificate compression introduces a level of complexity here. If only > some > >> servers in the anonymity set support compression, attackers can work > with a > >> smaller anonymity subset. If all attackers support compression, the > padding > >> should try to match the largest Compressed Certificate. > >> > >> It might be good to discuss this issue in the security consideration > section. > > I agree tha this is worth discussing, but it seems like it belongs in > the ESNI > > draft itself, so implementers of ESNI will be more likely to take > compression > > into consideration. That is, we can expand the section you quoted to also > > explicitly mention certificate compression. What do you think? I can > look into > > proposing a PR for this. > > I agree with you that the bulk of the work belongs in the ESNI draft. > However, it would be nice to have a short reminder of the issue in the > security section of the compression draft. Something like: > > Although the Certificate extension is encrypted in TLS 1.3, third > parties can deduce some information about the certificate from the > length of the handshake messages. Compression does not prevent this > issue, as different certificate chains will compress to different > lengths. When privacy is desired, implementers need to consider > appropriate padding strategies. Discussion of these padding strategies > is out of scope for this document. > > -- Christian Huitema > Thanks! Filed a PR addressing this issue: https://github.com/tlswg/certificate-compression/pull/31 Cheers, Victor. --00000000000035a0aa059941d0c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 4:42 PM Christian = Huitema <huitema@huitema.net&= gt; wrote:
>> Second, my actual concern. Compression may leak information, becau= se different
>> certificate chains will compress differently. The authors mention = that an
>> attacker will not be able to inject data in the certificate chain,= and thus
>> that attacks of the CRIME variety are unlikely. That's correct= , but that's not
>> the entire story.
>>
>> TLS 1.3 will encrypt the compressed certificate message but the le= ngth of that
>> message could be deduced from the length of the server's encry= pted message.
>> Attackers might be able to derive from that length the identity of= the server,
>> even if the SNI is encrypted.
>>
>> One could say that in the absence of compression the length of the= certificate
>> chain is also available. Indeed, the problem is flagged in
>> draft-ietf-tls-esni-05, which states in section 5.3 that "it = (the server)
>> SHOULD pad the Certificate message, via padding at the record laye= r, such that
>> its length equals the size of the largest possible Certificate (me= ssage)
>> covered by the same ESNI key."
>>
>> Certificate compression introduces a level of complexity here. If = only some
>> servers in the anonymity set support compression, attackers can wo= rk with a
>> smaller anonymity subset. If all attackers support compression, th= e padding
>> should try to match the largest Compressed Certificate.
>>
>> It might be good to discuss this issue in the security considerati= on section.
> I agree tha this is worth discussing, but it seems like it belongs in = the ESNI
> draft itself, so implementers of ESNI will be more likely to take comp= ression
> into consideration. That is, we can expand the section you quoted to a= lso
> explicitly mention certificate compression. What do you think? I can l= ook into
> proposing a PR for this.

I agree with you that the bulk of the work belongs in the ESNI draft.
However, it would be nice to have a short reminder of the issue in the
security section of the compression draft. Something like:

Although the Certificate extension is encrypted in TLS 1.3, third
parties can deduce some information about the certificate from the
length of the handshake messages. Compression does not prevent this
issue, as different certificate chains will compress to different
lengths. When privacy is desired, implementers need to consider
appropriate padding strategies. Discussion of these padding strategies
is out of scope for this document.

-- Christian Huitema

Thanks!
=
Filed a PR addressing this issue:=C2=A0https://github.com/tlswg/ce= rtificate-compression/pull/31

Cheers,
=C2=A0 Victor.=C2=A0
--00000000000035a0aa059941d0c2-- From nobody Mon Dec 9 11:37:23 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DD712012A; Mon, 9 Dec 2019 11:37:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: Cc: last-call@ietf.org, nfsv4@ietf.org, draft-ietf-nfsv4-rfc5661sesqui-msns.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Sean Turner Message-ID: <157592023668.2110.4367333458987159995@ietfa.amsl.com> Date: Mon, 09 Dec 2019 11:37:16 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-nfsv4-rfc5661sesqui-msns-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 19:37:17 -0000 Reviewer: Sean Turner Review result: Ready I'm no NFS expert, but I did review draft-ietf-nfsv4-mv1-msns-update [0], which dealt with fixes in RFC5661 for multi-server namespace. This draft replaces that draft and obsoletes RFC5661 to incorporate changes documented in draft-ietf-nfsv4-mv1-msns-update. Almost all of the changes are to section 11 and 21. I briefly examined the changes in this draft and those noted in draft-ietf-nfsv4-mv1-msns-update, and it appears the changes are incorporated (I trust the authors faithfully made the changes). As far as the changes I suggested during my previous review [1], it appears as if the authors have: - major: 0-2 accepted and incorporated. The spirit of 3 was incorporated; makes it clear that AUTH_SYS provides "no provision to avoid modification of data in flight". - nits: incorporated 0-4, 6-8, and 10. I see the point to not making the changes suggested in 5 and 9. Cheers, spt [0] https://datatracker.ietf.org/doc/review-ietf-nfsv4-mv1-msns-update-04-secdir-lc-turner-2019-02-27/ [1] https://mailarchive.ietf.org/arch/msg/secdir/zjgQKz0KnQbQHrJmQGwWioNwEpg From nobody Mon Dec 9 17:30:26 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801A412002F; Mon, 9 Dec 2019 16:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, T_SPF_PERMERROR=0.01] 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 xVXms2fiCSlH; Mon, 9 Dec 2019 16:51:48 -0800 (PST) Received: from exchange.uccs.edu (uccs-ex1.uccs.edu [128.198.1.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF076120020; Mon, 9 Dec 2019 16:51:44 -0800 (PST) Received: from mail-ed1-f45.google.com (209.85.208.45) by UCCS-EX1.uccs.edu (128.198.1.101) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 9 Dec 2019 17:51:42 -0700 Received: by mail-ed1-f45.google.com with SMTP id r21so3787978edq.0; Mon, 09 Dec 2019 16:51:42 -0800 (PST) X-Gm-Message-State: APjAAAULFwWxMI+FS7GHEzxhKoKIUN9nS6PQSWPFlGJnF+9h9/l8GgFJ PuqeRWRcjQ9DArdHqdd5AI9RaUNwOXbVqexPSmA= X-Google-Smtp-Source: APXvYqzffZlOsluialHaQK4iAkNFFZHUqo0B2XACqgAhX5taXfPI1+JGyxL8sO2+Ls3hfXxSqa9kIs+ZZbteHFSikrA= X-Received: by 2002:a05:6402:1435:: with SMTP id c21mr35958275edx.1.1575939101160; Mon, 09 Dec 2019 16:51:41 -0800 (PST) MIME-Version: 1.0 From: "Shawn M. Emery" Date: Mon, 9 Dec 2019 17:51:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: , secdir Content-Type: multipart/alternative; boundary="0000000000004ffae405994eeacb" X-Originating-IP: [209.85.208.45] X-ClientProxiedBy: UCCS-EX3.uccs.edu (128.198.1.103) To UCCS-EX1.uccs.edu (128.198.1.101) Archived-At: X-Mailman-Approved-At: Mon, 09 Dec 2019 17:30:24 -0800 Subject: [secdir] Review of draft-ietf-bfd-vxlan-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 00:51:50 -0000 --0000000000004ffae405994eeacb Content-Type: text/plain; charset="UTF-8" Reviewer: Shawn M. Emery Review result: Ready with nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a review of the changes since my original review of the 07 draft. Most of my comments have been addressed, thank you. The remaining questions were: 1. Relating to privacy: I believe that this section [security considerations] should also document the security impact of deploying BFD on VXLANs for monitoring tunnel traffic. Which additional information, if any, can now be obtained with BFD usage? 2. Editorial: Echo BFD is out of scope for the document, but does not describe the reason for this or why state this at all? They were discussed in the thread of the review but I don't know why the draft was not updated with this information. Shawn. -- --0000000000004ffae405994eeacb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewer: Shawn M. Emery
Review result: Ready with nits=

I have reviewed this document as part of the security directorate&#= 39;s
ongoing effort to review all IETF documents being processed by the = IESG.
These comments were written primarily for the benefit of the secur= ity
area directors. Document editors and WG chairs should treat thesecomments just like any other last call comments.

Th= is is a review of the changes since my original review of the 07 draft.
Most of my comments have been addressed, thank you.=C2=A0 The remain= ing
questions were:=C2=A0

1. Relating to= privacy:
I believe that this section [security considerations] should= also document
the security impact of deploying BFD on VXLANs for monit= oring tunnel traffic.
Which additional information, if any, can n= ow be obtained with BFD usage?

2. Editorial:
Ec= ho BFD is out of scope for the document, but does not describe the
reaso= n for this or why state this at all?

They were discussed= in the thread of the review but I don't know why the
draft w= as not updated with this information.

Shawn.
--
--0000000000004ffae405994eeacb-- From nobody Tue Dec 10 07:48:03 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC891120100; Tue, 10 Dec 2019 07:48:02 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDpsOrzNksSC; Tue, 10 Dec 2019 07:48:01 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2E2120045; Tue, 10 Dec 2019 07:48:01 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 370731E2F6; Tue, 10 Dec 2019 10:52:22 -0500 (EST) Date: Tue, 10 Dec 2019 10:52:21 -0500 From: Jeffrey Haas To: "Shawn M. Emery" Cc: draft-ietf-bfd-vxlan.all@ietf.org, secdir , Shawn Emery Message-ID: <20191210155221.GB29250@pfrc.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 15:48:03 -0000 Shawn, On Mon, Dec 09, 2019 at 05:51:30PM -0700, Shawn M. Emery wrote: > Reviewer: Shawn M. Emery > Review result: Ready with nits [...] > 1. Relating to privacy: > I believe that this section [security considerations] should also document > the security impact of deploying BFD on VXLANs for monitoring tunnel > traffic. > Which additional information, if any, can now be obtained with BFD usage? BFD protects transport between two systems and, in the profile envisaged in this document, does not typically involve itself in protecting user-managed endpoints. (In such circumstances, they might consider standard RFC 5880/5881 BFD as a user-provisioned mechanism.) The traffic for this mechanism is thus between two systems at the tunnel level and only covers the information necessary to permit the BFD protocol to execute, including any BFD security mechanisms that may be applied to that session. There are thus no end user privacy considerations for this mechanism. > 2. Editorial: > Echo BFD is out of scope for the document, but does not describe the > reason for this or why state this at all? This is covered by RFC 5880 section 5. Similar to most other IETF documents, when documenting extensions and we do not conflict with the base behavior, we don't try to copy and paste the motivations as it waters down the normative text. (If we were IEEE, we'd reissue the entire suite every time we touched something...) Our preference is to leave it alone. At best, we could say "See RFC 5880, section 5." -- Jeff From nobody Tue Dec 10 13:38:20 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA77120019; Tue, 10 Dec 2019 13:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcyAu0U31h6L; Tue, 10 Dec 2019 13:36:49 -0800 (PST) Received: from exchange.uccs.edu (uccs-ex1.uccs.edu [128.198.1.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E702C120005; Tue, 10 Dec 2019 13:36:48 -0800 (PST) Received: from mail-ed1-f49.google.com (209.85.208.49) by UCCS-EX1.uccs.edu (128.198.1.101) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 10 Dec 2019 14:36:46 -0700 Received: by mail-ed1-f49.google.com with SMTP id cy15so17369524edb.4; Tue, 10 Dec 2019 13:36:46 -0800 (PST) X-Gm-Message-State: APjAAAXj7NJKR03UI8jxIERlocxBuXMg0dW8W9rH1n7DuoWQuCHhvswg HFCh18YF0zLhJcJfX9J7gHT1y1CN2pJVg4QwCQg= X-Google-Smtp-Source: APXvYqzoVQn3bFL6gdvs4Cua/mGOYgS1Yt1g4g+hpevP/nKSbgIG54JSR+nmvnApINro6oEj15lvzhQjwUWiwODMFZ0= X-Received: by 2002:a50:fa87:: with SMTP id w7mr42506594edr.0.1576013805546; Tue, 10 Dec 2019 13:36:45 -0800 (PST) MIME-Version: 1.0 References: <20191210155221.GB29250@pfrc.org> In-Reply-To: <20191210155221.GB29250@pfrc.org> From: "Shawn M. Emery" Date: Tue, 10 Dec 2019 14:36:34 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Jeffrey Haas CC: , secdir Content-Type: multipart/alternative; boundary="0000000000000a75430599604faa" X-Originating-IP: [209.85.208.49] X-ClientProxiedBy: UCCS-EX3.uccs.edu (128.198.1.103) To UCCS-EX1.uccs.edu (128.198.1.101) Archived-At: X-Mailman-Approved-At: Tue, 10 Dec 2019 13:38:19 -0800 Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 21:36:52 -0000 --0000000000000a75430599604faa Content-Type: text/plain; charset="UTF-8" Hi Jeff, Comments begin with SME... On Tue, Dec 10, 2019 at 8:48 AM Jeffrey Haas wrote: > Shawn, > > On Mon, Dec 09, 2019 at 05:51:30PM -0700, Shawn M. Emery wrote: > > Reviewer: Shawn M. Emery > > Review result: Ready with nits > > [...] > > > 1. Relating to privacy: > > I believe that this section [security considerations] should also > document > > the security impact of deploying BFD on VXLANs for monitoring tunnel > > traffic. > > Which additional information, if any, can now be obtained with BFD usage? > > BFD protects transport between two systems and, in the profile envisaged in > this document, does not typically involve itself in protecting user-managed > endpoints. (In such circumstances, they might consider standard RFC > 5880/5881 BFD as a user-provisioned mechanism.) > > The traffic for this mechanism is thus between two systems at the tunnel > level and only covers the information necessary to permit the BFD protocol > to execute, including any BFD security mechanisms that may be applied to > that session. There are thus no end user privacy considerations for this > mechanism. > SME: This was not clear to me when reading the draft and think that the text above would help in defending that there are no privacy concerns that this specification introduces. > > 2. Editorial: > > Echo BFD is out of scope for the document, but does not describe the > > reason for this or why state this at all? > > This is covered by RFC 5880 section 5. Similar to most other IETF > documents, when documenting extensions and we do not conflict with the base > behavior, we don't try to copy and paste the motivations as it waters down > the normative text. (If we were IEEE, we'd reissue the entire suite every > time we touched something...) > > Our preference is to leave it alone. > > At best, we could say "See RFC 5880, section 5." > SME: This was also not clear to me, as my initial investigation did not lead me to this text. Shawn. -- --0000000000000a75430599604faa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,

Comments begin with= SME...

On Tue, Dec 10, 2019 at 8:48 AM Jeffrey Haas <jhaas@pfrc.org> wrote:
Shawn,

On Mon, Dec 09, 2019 at 05:51:30PM -0700, Shawn M. Emery wrote:
> Reviewer: Shawn M. Emery
> Review result: Ready with nits

[...]

> 1. Relating to privacy:
> I believe that this section [security considerations] should also docu= ment
> the security impact of deploying BFD on VXLANs for monitoring tunnel > traffic.
> Which additional information, if any, can now be obtained with BFD usa= ge?

BFD protects transport between two systems and, in the profile envisaged in=
this document, does not typically involve itself in protecting user-managed=
endpoints.=C2=A0 (In such circumstances, they might consider standard RFC 5880/5881 BFD as a user-provisioned mechanism.)

The traffic for this mechanism is thus between two systems at the tunnel level and only covers the information necessary to permit the BFD protocol<= br> to execute, including any BFD security mechanisms that may be applied to that session.=C2=A0 There are thus no end user privacy considerations for t= his
mechanism.

SME: This was not clear to m= e when reading the draft and think that the text above would help in defend= ing that there are no privacy concerns that this specification introduces.<= /div>
=C2=A0
> 2. Editorial:
> Echo BFD is out of scope for the document, but does not describe the > reason for this or why state this at all?

This is covered by RFC 5880 section 5.=C2=A0 Similar to most other IETF
documents, when documenting extensions and we do not conflict with the base=
behavior, we don't try to copy and paste the motivations as it waters d= own
the normative text.=C2=A0 (If we were IEEE, we'd reissue the entire sui= te every
time we touched something...)

Our preference is to leave it alone.

At best, we could say "See RFC 5880, section 5."
=

SME: This was also not clear to me, as my initial inves= tigation did not lead me to this text.

Shawn.
--
--0000000000000a75430599604faa-- From nobody Tue Dec 10 14:00:25 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BE912018D; Tue, 10 Dec 2019 14:00:23 -0800 (PST) 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, HTML_MESSAGE=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 7FEH_0dbj9GY; Tue, 10 Dec 2019 14:00:21 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0591201E0; Tue, 10 Dec 2019 14:00:21 -0800 (PST) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 31C6A1E2F5; Tue, 10 Dec 2019 17:04:41 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BF64ECE6-53AF-4B85-8DCF-A7A40A32449F" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Jeffrey Haas In-Reply-To: Date: Tue, 10 Dec 2019 17:00:18 -0500 Cc: draft-ietf-bfd-vxlan.all@ietf.org, secdir Message-Id: References: <20191210155221.GB29250@pfrc.org> To: "Shawn M. Emery" X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 22:00:24 -0000 --Apple-Mail=_BF64ECE6-53AF-4B85-8DCF-A7A40A32449F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Shawn, The fundamental issue you're running into is you don't implement bfd for = vxlan without also implementing base BFD (RFC 5880). IETF specs don't = typically try to spell out all considerations from the base = specification in each extension. And yes, it's a common criticism of = IETF documents vs. other SDO docs such as IEEE or ITU-T. Given this [see below] > On Dec 10, 2019, at 4:36 PM, Shawn M. Emery wrote: >=20 > Hi Jeff, >=20 > Comments begin with SME... >=20 > On Tue, Dec 10, 2019 at 8:48 AM Jeffrey Haas > wrote: > Shawn, >=20 > On Mon, Dec 09, 2019 at 05:51:30PM -0700, Shawn M. Emery wrote: > > Reviewer: Shawn M. Emery > > Review result: Ready with nits >=20 > [...] >=20 > > 1. Relating to privacy: > > I believe that this section [security considerations] should also = document > > the security impact of deploying BFD on VXLANs for monitoring tunnel > > traffic. > > Which additional information, if any, can now be obtained with BFD = usage? >=20 > BFD protects transport between two systems and, in the profile = envisaged in > this document, does not typically involve itself in protecting = user-managed > endpoints. (In such circumstances, they might consider standard RFC > 5880/5881 BFD as a user-provisioned mechanism.) >=20 > The traffic for this mechanism is thus between two systems at the = tunnel > level and only covers the information necessary to permit the BFD = protocol > to execute, including any BFD security mechanisms that may be applied = to > that session. There are thus no end user privacy considerations for = this > mechanism. >=20 > SME: This was not clear to me when reading the draft and think that = the text above would help in defending that there are no privacy = concerns that this specification introduces. Adding in these considerations in an extension document to base BFD = seems weird. > =20 > > 2. Editorial: > > Echo BFD is out of scope for the document, but does not describe the > > reason for this or why state this at all? >=20 > This is covered by RFC 5880 section 5. Similar to most other IETF > documents, when documenting extensions and we do not conflict with the = base > behavior, we don't try to copy and paste the motivations as it waters = down > the normative text. (If we were IEEE, we'd reissue the entire suite = every > time we touched something...) >=20 > Our preference is to leave it alone. >=20 > At best, we could say "See RFC 5880, section 5." >=20 > SME: This was also not clear to me, as my initial investigation did = not lead me to this text. Understood. But again, spelling out all such considerations from the = base document in the extension document isn't very IETF. My request would be to review RFC 5880 and see if you come to the same = conclusions. -- Jeff >=20 > Shawn. > -- --Apple-Mail=_BF64ECE6-53AF-4B85-8DCF-A7A40A32449F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Shawn,

The = fundamental issue you're running into is you don't implement bfd for = vxlan without also implementing base BFD (RFC 5880).  IETF specs = don't typically try to spell out all considerations from the base = specification in each extension.  And yes, it's a common criticism = of IETF documents vs. other SDO docs such as IEEE or ITU-T.

Given this [see = below]

On Dec 10, 2019, at 4:36 PM, Shawn M. Emery = <semery@uccs.edu> = wrote:

Hi Jeff,

Comments begin with SME...

On Tue, Dec 10, 2019 at 8:48 AM Jeffrey = Haas <jhaas@pfrc.org> wrote:
Shawn,

On Mon, Dec 09, 2019 at 05:51:30PM -0700, Shawn M. Emery = wrote:
> Reviewer: Shawn M. Emery
> = Review result: Ready with nits

[...]

> 1. Relating to privacy:
> = I believe that this section [security considerations] should also = document
> the security impact of deploying BFD on = VXLANs for monitoring tunnel
> traffic.
> Which additional information, if any, can now be = obtained with BFD usage?

BFD protects = transport between two systems and, in the profile envisaged in
this document, does not typically involve itself in = protecting user-managed
endpoints.  (In such = circumstances, they might consider standard RFC
5880/5881 = BFD as a user-provisioned mechanism.)

The = traffic for this mechanism is thus between two systems at the tunnel
level and only covers the information necessary to permit the = BFD protocol
to execute, including any BFD security = mechanisms that may be applied to
that session.  = There are thus no end user privacy considerations for this
mechanism.

SME: This was not clear to me when = reading the draft and think that the text above would help in defending = that there are no privacy concerns that this specification = introduces.

Adding in these considerations in an extension document = to base BFD seems weird.

 
> 2. Editorial:
> Echo BFD is out of scope for the document, but does not = describe the
> reason for this or why state this at = all?

This is covered by RFC 5880 section = 5.  Similar to most other IETF
documents, when = documenting extensions and we do not conflict with the base
behavior, we don't try to copy and paste the motivations as = it waters down
the normative text.  (If we were IEEE, = we'd reissue the entire suite every
time we touched = something...)

Our preference is to leave it = alone.

At best, we could say "See RFC 5880, = section 5."

SME: This was also not clear to me, as = my initial investigation did not lead me to this = text.

Understood.  But again, spelling out all such = considerations from the base document in the extension document isn't = very IETF.

My request would be to = review RFC 5880 and see if you come to the same = conclusions.

-- Jeff


Shawn.
--

= --Apple-Mail=_BF64ECE6-53AF-4B85-8DCF-A7A40A32449F-- From nobody Tue Dec 10 22:39:28 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0868D12022D; Tue, 10 Dec 2019 22:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 9Dh0pKGAeYhh; Tue, 10 Dec 2019 22:39:11 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5C41112006E; Tue, 10 Dec 2019 22:39:11 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBB6d5v5001034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Dec 2019 01:39:07 -0500 Date: Tue, 10 Dec 2019 22:39:04 -0800 From: Benjamin Kaduk To: Stephen Kent Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-ace-oauth-authz.all@ietf.org, ace@ietf.org Message-ID: <20191211063904.GK13890@kduck.mit.edu> References: <157582913296.4934.15140560361782598959@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <157582913296.4934.15140560361782598959@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ace-oauth-authz-27 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 06:39:15 -0000 Hi Steve, Thanks for the thoughtful and in-depth commentary; I look forward to seeing the authors' response. I'll make a few notes inline in the interim... On Sun, Dec 08, 2019 at 10:18:53AM -0800, Stephen Kent via Datatracker wrote: > Reviewer: Stephen Kent > Review result: Has Issues > > SECDIR review of draft-ietf-ace-oauth-authz-27 > > The summary of the review is almost ready, but needs some revisions. > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving security requirements and > considerations in IETF drafts. Comments not addressed in last call may be > included in AD reviews during the IESG review. Document editors and WG chairs > should treat these comments just like any other last call comments. > > This is a long document- 86 pages! It is a proposal for how to use OAuth 2.0 > and CoAP to provide authorization security for Internet of Things (IoT) > devices. IoT devices are often criticized as not being very secure, so this > seems like a useful initiative. RFC 7228 (Technology for Constrained-Node > Networks, and Informational document) is cited as inspiration and reference for > this work. CoAP (RFC 7252) is expressly designed for the sort of environment > that characterizes many IoT devices, hence is seems a natural choice for this > authorization-focused framework. OAuth is not as obvious a candidate building > block in this context, e.g., it is expressly designed for the HTTP context, yet > CoAP is cited as the replacement for HTTP. This document adapts OAuth for the > CoAp context. The WG did consider a variety of options before settling on the OAuth architecture, so we can probably say that "the other extant options were worse". > This document has an extensive, 6-page Security Considerations section, > appropriate for a document specifying an authorization framework. It begins by > citing the OAuth 2.0 specification, the OAuth 2.0 threat model (RFC 6819), and > OAuth 2.0 Token Introspection (RFC 7662). All three of these documents are > relevant, and they contain substantial Security Consideration sections. > > Section 6.1 deals with security for the tokens that are transmitted to convey > authorization information. In general the requirements and advice provided here > are good; I would prefer to see the admonition against use of a shared secret > key for a group of serves to be a MUST NOT, as opposed to just NOT RECOMMENDED. > I am not convinced that the suggestion for short lifetime tokens is necessary; > we have seen how short duration certificate lifetimes and frequent CRL issuance > in PKI contexts often is neither required nor advisable. This section ends by > noting that only client-initiated revocation of tokens is addressed by RFC > 7009. The authors note that revocation of long lifetime token remains an open > issue. If this is likely to be a common case for IoT devices, leaving this as a > TBD is not great. I think that there's a significant difference between the PKIX and OAuth workflows as deployed here, that's relevant -- in PKIX the CA has the "one-time" certification decision with some follow-on revocation status information that many things don't make use of or don't put in the critical path; in the OAuth world most deployments have the AS regularly involved in authentication decisions, whether that's the RS querying "is this token still valid?" or having a refresh token periodically refreshed into a new access token on a timescale of hours. There's more of an expectation that the AS can actively break these ongoing/recurring authorization flows when something goes wrong, whereas when the CA issues a CRL it sometimes feels more like "toss it over the wall and hope that the relying party bothers to check". That's not to say that the OAuth way is perfect, of course, but hopefully gives some sense of why it feels more natural to the authors/WG. > Section 6.2 addresses communication security issues. The section opens by > requiring an authorization server to offer confidentiality for client > interactions, but the wording implies that a client need not make use of such > protection. The reader is reminded that security requirements expressed in > Section 5 of this document (a 25-page long section) MUST be addressed by a > profile. I’d prefer to see references to specific parts of Section 5 that > expressly addresses confidentiality, so that a reader can better understand > when it is safe to reject the offer of confidentiality by a server. Encryption > of CWTs is used as an example, which is appropriate because CBOR CWT is the > default token format. The final paragraph of this section says that “developers (I'll reiterate for everyone that CWTs are not necessarily encrypted, though they can be. In the Web/OAuth world, encrypted JWTs are hardly the norm.) > MUST ensure that … ephemeral credentials … are not leaked to third parties.” > This is good advice, but since adversaries are assumed to have physical access > to IoT devices, the scope of this mandate is not clear. For example, is this > text arguing for use of tamper-resistant hardware for storing private or > session keys in IoT devices? > > Section 6.3 focuses on long-term credentials. The sections begins by noting the > challenges associated with providing protection for such credentials in devices > in publicly-accessible locations, explicitly referring to specialized hardware. > This a good, clear statement, not like the ambiguous MUST at the end of 6.2. > The text requires that compromise of a credential at one device MUST NOT lead > to compromise of other credentials not linked to the device in question. > However, the next sentence says that sharing of secret (and, presumably, > private) keys is NOT RECOMMENDED. This is a somewhat inconsistent pair of > statements; if secret keys are shared, then the MUST NOT will be violated, > right? Why not just say that secret keys MUST NIOT be shared across devices? > The section states that operators should have procedures to replace credentials > that have been (or are suspected to have been) compromised. Why is this > admonition not a SHOULD? The mildly-worded (“… also need to …) advice about > decommissioning devices seems minimally helpful. If this is important than make > it a SHOULD, if it’s not, then RECOMMEND it. Doesn't RFC 2119 say that SHOULD and RECOMMENDED are synonymous? > Section 6.4 discusses the challenges associated with securing initial > communication between a client and a resource server (RS). This communication > makes use of the (appropriately-named) Creation Hints message defined in 5.1.2. > The basis mechanism suggested here is use of a (possibly hard coded) list of > trusted authorization servers (AS’s) and associated credentials, e.g., > certificate fingerprints. The discussion here notes the potential for a DoS > attack against an AS by a compromised RS, by having clients sends requests to > the targeted AS. This is a useful comment, after noting that compromise of an > RS would not cause an AS to grant requests to clients that it is not serving. > > Section 6.5 summarizes the “minimal” communication security requirements for > the elements of the system described in this document (clients, AS’s and RS’s). > I think it’s useful to collect these requirements in one place, although they > have been described in various parts of Section 5. Unfortunately, the first > sub-section seems to contradict Section 6.2! Specifically the text here says > that all communication between a client and an AS MUST be encrypted, where as > 6.2 requires only that an AS offer confidentiality. This inconsistency needs to > be reconciled. The next subsection seems to be consistent. The final subsection > (C-RS) notes the challenges of initial C/RS communication, and offers some > suggested approaches. Some of the wording here is awkward. For example, the > text notes that DTLS with server-side authentication “can be possible and are > RECOMMENDED if supported by both parties.” It would be better to state that > “DTLS with server-side authentication is a RECOMMENDED mechanism for use in > this context, and SHOULD be employed if supported by both the C and the RS.” (I'm told that there are devices for which DTLS is too heavyweight to be implementable, and I suspect that's related to this wording.) > Section 6.6 deals with token lifetimes. The section begins by suggesting use of > nonces (as described in 5.1.2) to counter replay attacks in the event of “clock > drift” between an RS and an AS. I appreciate the analysis of mechanisms that > can be used to address the clock drift issue, including the discussion of > potential problems associated with using nonces in the face of a reboot. > However, the text provides no indication of how much “drift” is tolerable, vs. > when use of nonces is needed, and 5.1.2 does not even mention clock drift. > Perhaps the text can be revised to provide additional advice re clock drift. It's always hard to give concrete advice about clock drift, but worth a re-think, as you note. Kerberos went with 5 minutes of slop back in '93, and that ends up being way more than you need if things are working decently well, but still not enough for some broken systems. Thanks again, Ben > Section 6.7 very briefly discussed the issue of combining profiles. The bottom > line is that the security of a profile MUST NOT depend on the assumption that > the profile is used exclusively throughout a given deployment. That’s a nice, > straightforward warning! > > Section 6.8 discusses circumstances in which data is transmitted and may not > encrypted, e.g., error messages. The discussion here is fairly clear, and > includes a RECOMMENTATION and a MUST, as well as an analysis of potential risks > associated with transmitting different types of information w/o confidentiality > protection. The section title says “unprotected” but this discussion focuses > only on confidentiality, so a more descriptive title might help. > > Section 6.9 provides guidance on how to deal with the ambiguity of how to match > an “audience” value to a specific resource server. The authors admit that the > Section 5 discussion about the (optional) audience parameter in the OAuth token > is vague. They note that this is intentional, to accommodate a wide range of > deployment scenarios. Thus the discussion in this section provides guidance > for several scenarios. This is a reasonable way to deal with the ambiguity from > Section 5. > > Section 6.10 examines denial of service attacks in the context of > “introspection,” an optional aspect of OAuth which may be employed in this > framework. The text examines two DoS attacks, one against resource servers and > one against authorization servers, and suggests mitigations for both. > > Section 7 discusses privacy implications of the proposed framework. The > discussion here is useful, addressing a set of concerns that arise due to > client interactions with the AS and RS elements of the framework. > > From nobody Thu Dec 12 11:47:28 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2249120024 for ; Thu, 12 Dec 2019 11:47:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157618004798.20861.5601460242681070850.idtracker@ietfa.amsl.com> Date: Thu, 12 Dec 2019 11:47:27 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2019 19:47:28 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-12-19 Reviewer LC end Draft Alan DeKok 2019-11-27 draft-ietf-6man-ra-pref64-08 Daniel Franke 2019-12-02 draft-ietf-mboned-driad-amt-discovery-10 Tobias Gondrom 2019-12-02 draft-ietf-tls-tls13-cert-with-extern-psk-03 Yaron Sheffer R2019-10-18 draft-ietf-ace-coap-est-17 Last calls: Reviewer LC end Draft John Bradley 2019-11-22 draft-schaad-cbor-content-02 Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-07 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-17 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Alan DeKok 2019-11-27 draft-ietf-6man-ra-pref64-08 Donald Eastlake 2019-12-16 draft-nottingham-rfc7320bis-02 Donald Eastlake 2019-11-14 draft-ietf-hip-dex-11 Daniel Franke 2019-12-02 draft-ietf-mboned-driad-amt-discovery-10 Tobias Gondrom 2019-12-02 draft-ietf-tls-tls13-cert-with-extern-psk-03 Dan Harkins R2019-10-03 draft-ietf-dtn-bpsec-13 Leif Johansson 2019-12-19 draft-ietf-jmap-websocket-04 Charlie Kaufman 2019-12-13 draft-ietf-ace-oauth-params-06 Scott Kelly 2019-12-13 draft-ietf-bess-nsh-bgp-control-plane-12 Tero Kivinen 2020-01-06 draft-foudil-securitytxt-08 Watson Ladd 2019-12-25 draft-ietf-ipsecme-qr-ikev2-09 Chris Lonvick 2019-12-25 draft-ietf-mpls-summary-frr-rsvpte-07 Aanchal Malhotra 2019-12-23 draft-ietf-pce-stateful-flags-00 David Mandelberg 2019-12-23 draft-ietf-mboned-deprecate-interdomain-asm-05 Catherine Meadows 2019-12-19 draft-ietf-dnsop-no-response-issue-14 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Yaron Sheffer R2019-10-18 draft-ietf-ace-coap-est-17 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-05 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-11 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Daniel Migault Adam Montville Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tirumaleswar Reddy.K From nobody Thu Dec 12 12:27:13 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4008120090 for ; Thu, 12 Dec 2019 12:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7JIYTjIuilS for ; Thu, 12 Dec 2019 12:27:11 -0800 (PST) Received: from Mail.Yoyodyne.COM (mail.yoyodyne.com [IPv6:2604:4ec0:0:2::d]) by ietfa.amsl.com (Postfix) with SMTP id 671F9120024 for ; Thu, 12 Dec 2019 12:27:11 -0800 (PST) Received: from [IPv6:2603:3024:1767:6000:4df:3d16:aa3b:445b] ([2603:3024:1767:6000:4df:3d16:aa3b:445b]) by Mail.Yoyodyne.COM via Internet for (and others); Thu, 12 Dec 2019 12:27:10 PST From: Derrell Piper Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0488B324-63A4-471B-A9FE-09C675B6DF72"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Thu, 12 Dec 2019 12:27:10 -0800 In-Reply-To: <157618004798.20861.5601460242681070850.idtracker@ietfa.amsl.com> Cc: secdir@ietf.org To: secdir-secretary@mit.edu, Tero Kivinen References: <157618004798.20861.5601460242681070850.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2019 20:27:13 -0000 --Apple-Mail=_0488B324-63A4-471B-A9FE-09C675B6DF72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please go ahead and assign me draft-ietf-nfsv4-rpc-tls-04. Thanks, Derrell > On Dec 12, 2019, at 11:47 AM, Tero Kivinen via Datatracker = wrote: >=20 > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 > For telechat 2019-12-19 >=20 > Reviewer LC end Draft > Alan DeKok 2019-11-27 draft-ietf-6man-ra-pref64-08 > Daniel Franke 2019-12-02 = draft-ietf-mboned-driad-amt-discovery-10 > Tobias Gondrom 2019-12-02 = draft-ietf-tls-tls13-cert-with-extern-psk-03 > Yaron Sheffer R2019-10-18 draft-ietf-ace-coap-est-17 >=20 > Last calls: >=20 > Reviewer LC end Draft > John Bradley 2019-11-22 draft-schaad-cbor-content-02 > Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-07 > Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-17 > Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 > Alan DeKok 2019-11-27 draft-ietf-6man-ra-pref64-08 > Donald Eastlake 2019-12-16 draft-nottingham-rfc7320bis-02 > Donald Eastlake 2019-11-14 draft-ietf-hip-dex-11 > Daniel Franke 2019-12-02 = draft-ietf-mboned-driad-amt-discovery-10 > Tobias Gondrom 2019-12-02 = draft-ietf-tls-tls13-cert-with-extern-psk-03 > Dan Harkins R2019-10-03 draft-ietf-dtn-bpsec-13 > Leif Johansson 2019-12-19 draft-ietf-jmap-websocket-04 > Charlie Kaufman 2019-12-13 draft-ietf-ace-oauth-params-06 > Scott Kelly 2019-12-13 = draft-ietf-bess-nsh-bgp-control-plane-12 > Tero Kivinen 2020-01-06 draft-foudil-securitytxt-08 > Watson Ladd 2019-12-25 draft-ietf-ipsecme-qr-ikev2-09 > Chris Lonvick 2019-12-25 = draft-ietf-mpls-summary-frr-rsvpte-07 > Aanchal Malhotra 2019-12-23 draft-ietf-pce-stateful-flags-00 > David Mandelberg 2019-12-23 = draft-ietf-mboned-deprecate-interdomain-asm-05 > Catherine Meadows 2019-12-19 = draft-ietf-dnsop-no-response-issue-14 > Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 > Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 > Magnus Nystrom 2019-04-10 = draft-ietf-avtcore-multiplex-guidelines-09 > Yaron Sheffer R2019-10-18 draft-ietf-ace-coap-est-17 > Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-05 > Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-11 > Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 >=20 > Next in the reviewer rotation: >=20 > Daniel Migault > Adam Montville > Russ Mundy > Sandra Murphy > Yoav Nir > Magnus Nystrom > Hilarie Orman > Radia Perlman > Derrell Piper > Tirumaleswar Reddy.K >=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail=_0488B324-63A4-471B-A9FE-09C675B6DF72 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCqUw ggUuMIIEFqADAgECAhBuYWaYcrycMAAAAABR05MeMA0GCSqGSIb3DQEBCwUAMIG+MQswCQYDVQQG EwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UECxMfU2VlIHd3dy5lbnRydXN0Lm5l dC9sZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMDkgRW50cnVzdCwgSW5jLiAtIGZvciBhdXRo b3JpemVkIHVzZSBvbmx5MTIwMAYDVQQDEylFbnRydXN0IFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkgLSBHMjAeFw0xOTA0MTYxNTM1NTJaFw0zMDExMTYxNjA1NTJaMIG3MQswCQYDVQQGEwJV UzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UECxMfU2VlIHd3dy5lbnRydXN0Lm5ldC9s ZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMTUgRW50cnVzdCwgSW5jLiAtIGZvciBhdXRob3Jp emVkIHVzZSBvbmx5MSswKQYDVQQDEyJFbnRydXN0IENsYXNzIDEgQ2xpZW50IENBIC0gU0hBMjU2 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2DmtXj1lwZOXaWXvERtOSP7QMI+Ts82R Qc2etqDeYwctILXqkwsQrZB6YjKa1BQnBmLHxn3cWxKJtqCT7ZP95YVxc0MXjP5ifP9xD/f59jlY d/7SPIxQUjX1+vsV6aY4tTzPiaOu3VHVGbD70si3WdUvJh367CMOU2o0mXi9MwW1fBwMHK99NKgp wpr4QhyT2aZ+os/hGGQLUYmse5Dfshq79eelXyFC1FIrvM0AhAk+T3NKFPmckKwyk30jkFMElSne TR7ganOTMeT1OEqVomyJsMzJugVaMzuSt4vhJFSt/XXRMPcPT9PEx39X78NNkWeTTkL1Ghq9O2We AStQNwIDAQABo4IBKzCCAScwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDsGA1UdIAQ0MDIwMAYEVR0gADAoMCYGCCsGAQUF BwIBFhpodHRwOi8vd3d3LmVudHJ1c3QubmV0L3JwYTAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUH MAGGF2h0dHA6Ly9vY3NwLmVudHJ1c3QubmV0MDAGA1UdHwQpMCcwJaAjoCGGH2h0dHA6Ly9jcmwu ZW50cnVzdC5uZXQvZzJjYS5jcmwwHQYDVR0OBBYEFOJJuewl3rcM3uVQGFtIzAyOFfKmMB8GA1Ud IwQYMBaAFGpyJnrQHu995ztpUdRsjZ+QEmarMA0GCSqGSIb3DQEBCwUAA4IBAQBVuaCwN5r85cQp hcyUe+RXqaYyUmVEqTWG/a98UJdX44vkCgzdD/+Cn4o6wbRun7Ak0kdCR3qfFA17/5QOQ8DLOyR5 X37Ytxby24lTLKKehNlc3japM8XQQFaJqLMq3MXXFYhWlFk4UHwXYLcDR7XyA3hYuaL6HU92h+uG SDEcBeV+nXrk4FRgEfGvilHfd+8ozBjSVKOF6L1+fuJNkaFWYvJ4Qi64nlmXDsk6K9f6P4FT8hXA 2Cn6tQGAqCz8t6bn7ljtaxCMJ10LE+omiZDfWXv4PrkvgWnNqZEzQw+E09HwEc7DjV9/fGqUhLR2 AKkjYE/78rlymYPvOf7bmpSYMIIFbzCCBFegAwIBAgIRAI534qzDm7xdAAAAAFVjsOwwDQYJKoZI hvcNAQELBQAwgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQL Ex9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRy dXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xh c3MgMSBDbGllbnQgQ0EgLSBTSEEyNTYwHhcNMTkwODE1MTgyMDAyWhcNMjAwODE0MTg1MDAwWjCB nzEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQLEy5FbnRydXN0IENsYXNz IDEgSWRlbnRpdHkgQ2VydGlmaWNhdGlvbiBTZXJ2aWNlMR4wHAYDVQQDDBVkZHBAZWxlY3RyaWMt bG9mdC5vcmcxJDAiBgkqhkiG9w0BCQEWFWRkcEBlbGVjdHJpYy1sb2Z0Lm9yZzCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANBA7jjvZSATUxJEdJNmz6N1fnajqmdDkVHOxA0yllROaJPo MNM03XQFa24aJ7fJ9wQhq9NXHq2w5xO2KK2PBJW8vxw38wuPdE14bHzuxtGKWnDhJ/SIEWtA7pB0 fFMua7OAtgTMvekxx0st8qw6yKufNtdv7Q2U3OWUYCWNdvZudJxHXkqHdCj6WTBE24sGSL/UrGLj H98ebxfANbX8Wfp/Sg34OtbFe305CyXlwNWplILN4UKg+r4EWRKgJ3ZLsxj2WH/tWdn7KU6eK315 F/PjH2NscqzNTSwZbHcwynAYd6239FQiombVk4PGnHRJq1NOi4n5M1lvl8mnrsQLYNkCAwEAAaOC AYowggGGMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQgYD VR0gBDswOTA3BgtghkgBhvpsCgEEATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LmVudHJ1c3Qu bmV0L3JwYTAJBgNVHRMEAjAAMGkGCCsGAQUFBwEBBF0wWzAjBggrBgEFBQcwAYYXaHR0cDovL29j c3AuZW50cnVzdC5uZXQwNAYIKwYBBQUHMAKGKGh0dHA6Ly9haWEuZW50cnVzdC5uZXQvY2xhc3Mx LXNoYTI1Ni5jZXIwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5lbnRydXN0Lm5ldC9jbGFz czEtc2hhMjU2LmNybDAgBgNVHREEGTAXgRVkZHBAZWxlY3RyaWMtbG9mdC5vcmcwHwYDVR0jBBgw FoAU4km57CXetwze5VAYW0jMDI4V8qYwHQYDVR0OBBYEFA3/q3e5a+oKODwIaREHDhpaK0YRMA0G CSqGSIb3DQEBCwUAA4IBAQCPmXPwIGtfjvyqW7WFgrG/mBV1KWgorjrzgDYZmZfI466I6zEurSnI 0pLAbkXrhuTfEYkm4lertjRBSkd9W3iRaBUUfOntAdANX8/3onjQI/WEvszc6tPUTfS/CixsR69M mE0/o5UmYzSBcHzF2ff01ceD8IrsPhyzf87xJvfWonFyGB3gt8kN9K5S1eCAj6WdgC1ZrFMXp8fR ezAA2BHiJCbj4T2e3Zg4xDoTH4r4Y9u+czDikS5InJL+Z0iqsNR50d7YgAEAeU3iYQx5GvO7Dqou vM9JajPccnpqDClNXP1sqIOvAE6GHSopTy6mEUB6phLVeWW342rsUvtgUntVMYIEKjCCBCYCAQEw gc0wgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQLEx9TZWUg d3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRydXN0LCBJ bmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xhc3MgMSBD bGllbnQgQ0EgLSBTSEEyNTYCEQCOd+Ksw5u8XQAAAABVY7DsMA0GCWCGSAFlAwQCAQUAoIICLTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTEyMTIyMDI3MTBaMC8G CSqGSIb3DQEJBDEiBCC3cYL7fTGq4JdLwriLi/S0eDe4/YYmlWXATxDaDfxmdzCB3gYJKwYBBAGC NxAEMYHQMIHNMIG3MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UE CxMfU2VlIHd3dy5lbnRydXN0Lm5ldC9sZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMTUgRW50 cnVzdCwgSW5jLiAtIGZvciBhdXRob3JpemVkIHVzZSBvbmx5MSswKQYDVQQDEyJFbnRydXN0IENs YXNzIDEgQ2xpZW50IENBIC0gU0hBMjU2AhEAjnfirMObvF0AAAAAVWOw7DCB4AYLKoZIhvcNAQkQ AgsxgdCggc0wgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQL Ex9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRy dXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xh c3MgMSBDbGllbnQgQ0EgLSBTSEEyNTYCEQCOd+Ksw5u8XQAAAABVY7DsMA0GCSqGSIb3DQEBAQUA BIIBACr2Zeh9pUflgvyIgNjO+mtFUycZF/hk1yS6dBSLKqSoh/G37gKay8sq+nWJPtkIZiQ6OT5G 5uR3p54XsbzNyRMLIIn8egXhh2bc2eWwSq8XFCC8RZaznwrmBAh72v/DPzEgDPLpDaHQNNtIxP32 bWXq6Q8BzuXQ5oL9kLDK6kHuAy+YJ/LMpRT3v2rVF/2JkWSqG/UJtVFuE/6Lc407S9ODLDiM8OFj p2Uw4EfSdHAQUGwQKvgnspz5oBzWv5YO6rP4Ri2TJTuuwMliDGAsQp5aWkTMBmndFnnCZJ9k+CCu 9cctbxSWXDwMNG1kx3NYA6k9ahNQLnLjGrDCRmzFCZMAAAAAAAA= --Apple-Mail=_0488B324-63A4-471B-A9FE-09C675B6DF72-- From nobody Thu Dec 12 23:48:28 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BDB1201EA; Thu, 12 Dec 2019 23:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 hYbEK5jbSj9U; Thu, 12 Dec 2019 23:48:24 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10olkn2035.outbound.protection.outlook.com [40.92.40.35]) (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 92CB71200F7; Thu, 12 Dec 2019 23:48:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ddMW9xa6+5H/+XQzAaSFuqw/TGYJwbx8bVDFLLqF5ga7pS1VaIWhxe8/GdeDiNRS7XAkYVZxdVVQU3gt4GCfuvSMXB11DD8ZEFTAxbrudalcAWWTUdv1q7jIGe0pf8aqi0Yv8G4IDjJDELNqg4Hu5ds5zyR+/+GRchYuzPYkU4E5rcf31Kj5OLHD3Ozy82CPYunRbOcnbIeRwSMrt8aMyjtZxTAcHLI8H8SRg5zb2GddgS06nLU+0tFYSC+vteMHRalaPBeJqUCBoiWb9i87NL0KPZ5EEFNoTp+31/wu14Lbtt3A67ZIOaMDgGWv34BP5cn0vmX6ZnA81wZzd1SrtA== 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=jO/Ioxyy2SBmn64K33adfWc3LWG8plRuN9Qt6t4pdKE=; b=DmOM+JwgdbFTfRCEI0gpUtRm7/PjxlNmLBng6NwO5ewhNWdZWdwuAbUmEa1FbWYV3EBt10BquqNJSiq4NhjadAGELTmFihys/DJyp3ytV7QI3xEucaCLTn53GJc0A3mckFCksCL8rGHzulG41UqErTAvS3IriL1mp8h+JQBC3dToi/YmuuSHtroUyUDLTR5Sqh5TTmDnTrcNxyvaB2Ym46wDAoQHvPNqm9VFhVVj03KZVFMMct635q+bsv4Ota9mGktr1WR77Qtz4NvzcYVqg9Sd4rXE3nYLTrOLbkXeNwejQ2cQgLoQXH/8R73HiHWB3apPAPVkd7RhcM8tj7kx4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jO/Ioxyy2SBmn64K33adfWc3LWG8plRuN9Qt6t4pdKE=; b=DDCGiEezIXS/YfusbezFlTJI7xsMTPev3ORUUlOAjoyB2vzcIF7waTtFVjD25CMhTPooPr/dBxNQGvyhJnuqTxHzsjRUVSYr8KnCey/yPfMJM6IYTTmDKXvFFqiWK9PPMDUMjoYCNB0IHsjA3kDqmT9K5GQ+7q8Y9FyOv4QWq5antyT6fbvmbafTGNtjQB/2hqrsflHiSJFwfZTT0YR28MT08kf+b7XIEngO8yY0gW+XD+dCnVmPoIawb6YdZIO1AZqZolaXeSp1cgv3eiQpZi1OjGJ4q+bNK4PBztnL0s/6WCYZmmyekc1soLA69gWsJgP67nbJdiru33R95PuzNQ== Received: from DM6NAM10FT063.eop-nam10.prod.protection.outlook.com (10.13.152.58) by DM6NAM10HT179.eop-nam10.prod.protection.outlook.com (10.13.153.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.14; Fri, 13 Dec 2019 07:48:23 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com (10.13.152.57) by DM6NAM10FT063.mail.protection.outlook.com (10.13.152.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.14 via Frontend Transport; Fri, 13 Dec 2019 07:48:23 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::1d83:aeb7:d1b7:ef79]) by MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::1d83:aeb7:d1b7:ef79%10]) with mapi id 15.20.2538.017; Fri, 13 Dec 2019 07:48:22 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ace-oauth-params.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-ace-oauth-params-06 Thread-Index: AQHVsYlz67iuRug560mk2vT/YE5oCg== Date: Fri, 13 Dec 2019 07:48:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:1C6F730ED9AFC6174B1000F7AE89873D243805D6B8334C9AD6BDE6DEDC65B2DF; UpperCasedChecksum:FC18AEA5B492A3A38559DC1F1DA202F8CCDD7119E451A1582DD0B430A8D23B18; SizeAsReceived:6998; Count:42 x-tmn: [BwndDDAu5zlDQ60kkAXifg6Nmbx8HuED97/GFVvcBaNBs4dtQ6m20YYeN6796Sze] x-ms-publictraffictype: Email x-incomingheadercount: 42 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 1c55bbf5-9530-4f92-c706-08d77fa0d450 x-ms-traffictypediagnostic: DM6NAM10HT179: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FhOpN7Y6WO5MdPJrkx5gr3jX6LiDb6FRHj0QQyOUNVKx1fZW4ExhNZAW3Js02VI4tDTTMMPwYbEcXQIFMh5UymW6XpVG3TmRHS1GNTJI7+c0Nc2XUTtRKKaOX5ZId+cuhNRPWbLX+gb0yy1h4JZaccbPtzJm4Lr5uy7cWfq0FJ/gclHw1Wjz4Wg7oOcQ/GvO x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR04MB036776E5D9FF69796005E730DF540MWHPR04MB0367namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 1c55bbf5-9530-4f92-c706-08d77fa0d450 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2019 07:48:22.8443 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM10HT179 Archived-At: Subject: [secdir] Secdir review of draft-ietf-ace-oauth-params-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2019 07:48:27 -0000 --_000_MWHPR04MB036776E5D9FF69796005E730DF540MWHPR04MB0367namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document only exists because of a scheduling issue between the ACE and= OAUTH working groups. The ACE working group needed some additional OAUTH e= xtensions added more quickly that the OAUTH group could manage to do it. Th= is document is intended to only exist until the OAUTH group can make the co= rresponding changes. As such, it really doesn't have security consideration= s beyond those in the document it modifies. The security considerations section says (and I agree): This document is an extension to [I-D.ietf-ace-oauth-authz]. All security c= onsiderations from that document apply here as well. Some acronyms that were not defined (but this might be OK in the context of= this being a modification to another document): AS, RS, CoAP, cnf, CBOR, p= op, CWT A few typos / odd phrasing: Abstract: whishes -> wishes Appendix A: possesion -> possession >From Section 2: Note that the term "endpoint" is used here following its OAuth 2.0 [RFC6749= ] definition, which is to denote resources such as token and introspection = at the AS and authz-info at the RS. Really? The term "endpoint" refers to tokens and authz-info data structures= ? This seems unlikely. Continuing in Section 2: The CoAP [RFC7252] definition, which is "An entity participating in the CoA= P protocol" is not used in this specification. Why is a definition that does not apply relevant to this document? --_000_MWHPR04MB036776E5D9FF69796005E730DF540MWHPR04MB0367namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. = ; These comments were written primarily for the benefit of the security are= a directors.  Document editors and WG chairs should treat these comments just like any other last call comments.=

This document only exists because of a scheduling issue between the AC= E and OAUTH working groups. The ACE working group needed some additional OA= UTH extensions added more quickly that the OAUTH group could manage to do i= t. This document is intended to only exist until the OAUTH group can make the corresponding changes. As su= ch, it really doesn't have security considerations beyond those in the docu= ment it modifies.

The security considerations section says (and I agree):

This document is an extension to [I-D.ietf-ace-oauth-authz]. All secur= ity considerations from that document apply here as well.

Some acronyms that were not defined (but this might be OK in the conte= xt of this being a modification to another document): AS, RS, CoAP, cnf, CB= OR, pop, CWT


A few typos / odd phrasing:

Abstract: whishes -> wishes
Appendix A: possesion -> possession

From Section 2:
Note that the term "endpoint" is used here following its OAuth 2.= 0 [RFC6749] definition, which is to denote resources such as token and intr= ospection at the AS and authz-info at the RS.

Really? The term "endpoint" refers to tokens and authz-info = data structures? This seems unlikely.

Continuing in Section 2:
The CoAP [RFC7252] definition, which is "An entity participating in th= e CoAP protocol" is not used in this specification.

Why is a definition that does not apply relevant to this document?

--_000_MWHPR04MB036776E5D9FF69796005E730DF540MWHPR04MB0367namp_-- From nobody Sat Dec 14 03:58:46 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDC412007C; Sat, 14 Dec 2019 03:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 7pbg6ysrBLxU; Sat, 14 Dec 2019 03:58:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 16A7812006B; Sat, 14 Dec 2019 03:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576324709; bh=4heapEDiKbnSADfYNhNKEJBr53zZBckMHqqWNiCnCBo=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=aVOPiRQxLDaUTUCDsLUxTO/wbF0sloY5H9vzFUH4eQn4gWayLnd+/ixUA4MV3jf2m ee78+duYSjBnGtYyYRXVzcisNzTA/oLhE8MzT2KqdaSrW35voaJ6W0m3dZrS2uzBTS 5zZGGPl/q1+pGb3fwXO6FK4K/SFYhr+nGqNXIRYQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MjS5A-1i0jhH24Zm-00kxyN; Sat, 14 Dec 2019 12:58:29 +0100 To: kent@alum.mit.edu, secdir@ietf.org References: <157582913296.4934.15140560361782598959@ietfa.amsl.com> Cc: ace@ietf.org, last-call@ietf.org, draft-ietf-ace-oauth-authz.all@ietf.org From: Ludwig Seitz Message-ID: Date: Sat, 14 Dec 2019 12:58:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <157582913296.4934.15140560361782598959@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:+mkxzRcWwP0fa7gDAha7g44bWMAK4REqDro7md6batoFV41eG+l zllYqfO0SV0qAx4gCCZB5IHEqWUxJT9i3DR0YaifrPpGm+uLvOFXw8mw067ESI6OUPmoGFH tVIhE52yM0mnSOYBAN080y1oDTttRjJsy2xHBk5oWdvdAqzCBnY4WBVU868qTIznT3SLIxH tG/doB6osIe1rpi/tIdpg== X-UI-Out-Filterresults: notjunk:1;V03:K0:tWM5mC1rLfo=:wEtnKc0lXjs34KvXsgMqv5 +T503+YAPW8QpI3CQPPx2gH9lvccvSbsIICyuGZptgegwh2U5a3kOleAo/ofccT3o9/u8q2WE HvH+g/bmn2aOz8pKdKQdo/f9Ot3YLsvFicT7JU4lncAbuPagkQAzRIHj9LC4d8gugMBoewniA IcouvYnVIExbUN+8NlHO4f5TV4Gn0e1exks5Lu2MTtczrTtxdOy92rEih04nDoRw5AWkj5MTU YT8YLZ9wISRJZpGRDcYf0f+F1wBn3Vd8Xaqa1gbEp0mgF/cvIVEhkr4FwaY/jz/CtbDJ+HLyW Hw9PQdg+iogVMvrNIqPfBSxNdqPRnJ835ACssK+BhDE8wLOD++35xi8HKNq6w4kQIGlrBBQqj SfsjcyCxWkCg+VKIJpJeGPQmAsLVPB2Q+OL/LWt1Y2yI61+TG63UCW/DK28V5LaiUkRORZ2Yt s5vTR4OqbHVY4jDpfDwzpaSPxfv5oLIHZni93YvK2k7R5qzBodBBzxvU7PZkAgRS6OsKav2zf l1hU3XJlpilSQe8UppaDmOMbyvL4Z+Mg0tT5PVE2JuKiGCopFF/wD52CfB/KVul/SBeR4Zldi PxDQ23mjnXXgfPPfnsaLGTWc/x11x1SRiMugfZaS3c/fqWh1Fke2x98x0oyEtF2KxC6ehH9Or MGwR+uA6kxiqTZ08F5T2rusDG+75oAHYw+p4v1MKQtIVXhGd8qaoqLv+107MLrxj57iwb3pRV b9Jb+hZZ66KtCG4NDw8AZ+fiRmByGtdlPtKTuqjGUSoWzSjzONc0MX0L3bFNelELO4vApBHvm p5jBOT5GLK93/MeynT7J5rgFGZvN1shm/YJOB8Q+ieM9oYlbUF3LM5II+cr8pSA4xCIXRuTKA n2V96beza4nAR/D4rU1NUNRhMDG2ohxhBLqQx2aNIYuls88jzdxaNy6VWBpl7O20PD23ew0zu IzJE73oc7ame0j1ne0qaKuMpRfRsPuzySVUds5JzR1Pzjc246z7dBzPnzHe7ZOW7oH4A/mWdh ZG7yh4hXperPU18m3akMgQT8PiRdGYG38KzqFsQEDJsyQy1mLnJ3vASvnMatd9BWJtiu0fcJP YzxfUf/Pn9R2GNCmf1yGtkNh4MUgrsUOnH7kNSuBdxJRv21kfFJhG/mTTOFBpP1dv2+zHKJNG 8EC6+Q6GrtnTe5+fVni0b39d3VMXtdl53+OdeZJDfOKEo2/6Np1JgixniiUlGBijqKArmDMa8 YB21M3orDoSIB+y8X3Zp2ILN2pk76vE9k103ra0XBf1QVYiTEUgTNlmgybRE= Archived-At: Subject: Re: [secdir] [Ace] Secdir last call review of draft-ietf-ace-oauth-authz-27 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2019 11:58:40 -0000 On 2019-12-08 19:18, Stephen Kent via Datatracker wrote: > Reviewer: Stephen Kent > Review result: Has Issues > > SECDIR review of draft-ietf-ace-oauth-authz-27 > > The summary of the review is almost ready, but needs some revisions. > > I have reviewed this document as part of the security directorate's ongo= ing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving security requirements= and > considerations in IETF drafts. Comments not addressed in last call may = be > included in AD reviews during the IESG review. Document editors and WG = chairs > should treat these comments just like any other last call comments. > Thank you for your helpful review Stephen. I have some follow-up questions inline. I will submit a draft update as soon as possible, note that this may be delayed by my affiliation change. Regards, Ludwig > This is a long document- 86 pages! It is a proposal for how to use OAuth= 2.0 > and CoAP to provide authorization security for Internet of Things (IoT) > devices. IoT devices are often criticized as not being very secure, so t= his > seems like a useful initiative. RFC 7228 (Technology for Constrained-Nod= e > Networks, and Informational document) is cited as inspiration and refere= nce for > this work. CoAP (RFC 7252) is expressly designed for the sort of environ= ment > that characterizes many IoT devices, hence is seems a natural choice for= this > authorization-focused framework. OAuth is not as obvious a candidate bui= lding > block in this context, e.g., it is expressly designed for the HTTP conte= xt, yet > CoAP is cited as the replacement for HTTP. This document adapts OAuth fo= r the > CoAp context. As Ben stated the ACE WG has had extensive discussions on which solution to choose, and the OAuth model has the advantage of being able to temporally decouple the authorization decision from the actual resource access, which enables several use cases involving devices with intermittent connectivity (note that several other proposals had the same design property). Furthermore the possible re-use of OAuth specifications was seen as favorable when the final decision was made to go forward with this solution. > This document has an extensive, 6-page Security Considerations section, > appropriate for a document specifying an authorization framework. It beg= ins by > citing the OAuth 2.0 specification, the OAuth 2.0 threat model (RFC 6819= ), and > OAuth 2.0 Token Introspection (RFC 7662). All three of these documents = are > relevant, and they contain substantial Security Consideration sections. > > Section 6.1 deals with security for the tokens that are transmitted to c= onvey > authorization information. In general the requirements and advice provid= ed here > are good; I would prefer to see the admonition against use of a shared s= ecret > key for a group of serves to be a MUST NOT, as opposed to just NOT RECOM= MENDED. Ok, will fix. > I am not convinced that the suggestion for short lifetime tokens is nece= ssary; > we have seen how short duration certificate lifetimes and frequent CRL i= ssuance > in PKI contexts often is neither required nor advisable. In constrained environments with intermittent connectivity, short token lifetime is seen as an advantage, as it might be hard to convey revocation decisions or other changes of access rights to offline devices. The short token lifetime limits the window of exposure, if a token and the corresponding proof-of-possession credentials get stolen. I would therefore prefer to keep that paragraph as it is. > This section ends by > noting that only client-initiated revocation of tokens is addressed by R= FC > 7009. The authors note that revocation of long lifetime token remains an= open > issue. If this is likely to be a common case for IoT devices, leaving th= is as a > TBD is not great. The situation is the same as for OAuth 2.0. The short token lifetime is often given as an explanation why a revocation mechanism is not really needed. We have however submitted a proposal for a revocation mechanism in https://datatracker.ietf.org/doc/draft-tiloca-ace-revoked-token-notificati= on > > Section 6.2 addresses communication security issues. The section opens b= y > requiring an authorization server to offer confidentiality for client > interactions, but the wording implies that a client need not make use of= such > protection. The reader is reminded that security requirements expressed = in > Section 5 of this document (a 25-page long section) MUST be addressed by= a > profile. I=E2=80=99d prefer to see references to specific parts of Secti= on 5 that > expressly addresses confidentiality, so that a reader can better underst= and > when it is safe to reject the offer of confidentiality by a server. The implication you read from the text was not intended, section 5 clearly specifies that confidentiality is mandatory. This is addressed in the body part of that section (4th paragraph). I'm a bit at a loss on how to make that more apparent, so that the reader does not go an a fruitless hunt in the subsections of section 5. Any suggestions are most welcome. In the meantime I will adjust the wording to clarify that confidentiality is mandatory. Note that Appendix C collects all requirements on profiles and lists the specific subsection where they appears. > Encryption > of CWTs is used as an example, which is appropriate because CBOR CWT is = the > default token format. The final paragraph of this section says that =E2= =80=9Cdevelopers > MUST ensure that =E2=80=A6 ephemeral credentials =E2=80=A6 are not leake= d to third parties.=E2=80=9D > This is good advice, but since adversaries are assumed to have physical = access > to IoT devices, the scope of this mandate is not clear. For example, is = this > text arguing for use of tamper-resistant hardware for storing private or > session keys in IoT devices? I guess it is up to the security level required by the specific application. I physical key extraction attack is not trivial, so the value of the protected asset has to be gauged against the additional cost for tamper-resistant hardware. A more simple, but less secure mitigation could e.g. be to glue over interfaces that an attacker could use for key extraction (e.g. debug ports) if they are not needed for normal operations. Would you like to have such considerations added to this section? > > Section 6.3 focuses on long-term credentials. The sections begins by not= ing the > challenges associated with providing protection for such credentials in = devices > in publicly-accessible locations, explicitly referring to specialized ha= rdware. > This a good, clear statement, not like the ambiguous MUST at the end of = 6.2. > The text requires that compromise of a credential at one device MUST NOT= lead > to compromise of other credentials not linked to the device in question. > However, the next sentence says that sharing of secret (and, presumably, > private) keys is NOT RECOMMENDED. This is a somewhat inconsistent pair o= f > statements; if secret keys are shared, then the MUST NOT will be violate= d, > right? Why not just say that secret keys MUST NIOT be shared across devi= ces? Agreed, will fix. > The section states that operators should have procedures to replace cred= entials > that have been (or are suspected to have been) compromised. Why is this > admonition not a SHOULD? The mildly-worded (=E2=80=9C=E2=80=A6 also need= to =E2=80=A6) advice about > decommissioning devices seems minimally helpful. If this is important th= an make > it a SHOULD, if it=E2=80=99s not, then RECOMMEND it. Ageed, I will make both a SHOULD. > > Section 6.5 summarizes the =E2=80=9Cminimal=E2=80=9D communication secur= ity requirements for > the elements of the system described in this document (clients, AS=E2=80= =99s and RS=E2=80=99s). > I think it=E2=80=99s useful to collect these requirements in one place, = although they > have been described in various parts of Section 5. Unfortunately, the fi= rst > sub-section seems to contradict Section 6.2! Specifically the text here = says > that all communication between a client and an AS MUST be encrypted, whe= re as > 6.2 requires only that an AS offer confidentiality. This inconsistency n= eeds to > be reconciled. The rewriting of 6.2 should fix this inconsistency. > The next subsection seems to be consistent. The final subsection > (C-RS) notes the challenges of initial C/RS communication, and offers so= me > suggested approaches. Some of the wording here is awkward. For example, = the > text notes that DTLS with server-side authentication =E2=80=9Ccan be pos= sible and are > RECOMMENDED if supported by both parties.=E2=80=9D It would be better t= o state that > =E2=80=9CDTLS with server-side authentication is a RECOMMENDED mechanism= for use in > this context, and SHOULD be employed if supported by both the C and the = RS.=E2=80=9D > I'll try to rephrase to make it more readable. > Section 6.6 deals with token lifetimes. The section begins by suggesting= use of > nonces (as described in 5.1.2) to counter replay attacks in the event of= =E2=80=9Cclock > drift=E2=80=9D between an RS and an AS. I appreciate the analysis of mec= hanisms that > can be used to address the clock drift issue, including the discussion o= f > potential problems associated with using nonces in the face of a reboot. > However, the text provides no indication of how much =E2=80=9Cdrift=E2= =80=9D is tolerable, vs. > when use of nonces is needed, and 5.1.2 does not even mention clock drif= t. > Perhaps the text can be revised to provide additional advice re clock dr= ift. > I will add a paragraph about that noting that the critical factors are the lifetime time of a token (lifetime >> clock drift), and the criticality of timely expiration. > Section 6.7 very briefly discussed the issue of combining profiles. The = bottom > line is that the security of a profile MUST NOT depend on the assumption= that > the profile is used exclusively throughout a given deployment. That=E2= =80=99s a nice, > straightforward warning! > > Section 6.8 discusses circumstances in which data is transmitted and may= not > encrypted, e.g., error messages. The discussion here is fairly clear, an= d > includes a RECOMMENTATION and a MUST, as well as an analysis of potentia= l risks > associated with transmitting different types of information w/o confiden= tiality > protection. The section title says =E2=80=9Cunprotected=E2=80=9D but thi= s discussion focuses > only on confidentiality, so a more descriptive title might help. I added a sentence instead that also points out the option that active attackers may manipulate unprotected information to induce incorrect behavior. /Ludwig From nobody Sat Dec 14 10:02:45 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7F8120046; Sat, 14 Dec 2019 10:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jUfX52ehJ8N; Sat, 14 Dec 2019 10:02:37 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 F3E6C12004F; Sat, 14 Dec 2019 10:02:36 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id v18so1905853iol.2; Sat, 14 Dec 2019 10:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=480vtdoP3CdZIv+SML28HrwC0u2tYd4VyUGJ5k9O078=; b=FAYGoWTTPDbu/Q5qAC8YKvHLahD4FD6e7cjCdL2xyrNr8G4/gDioa9qzbgsQFfYllC yQZVyREYB14tNvAQ6JHRMVaiL9BtCJsZKBlI9NgoSU38X99qw23V3LJyIfa6qz93U9nx TrJhcZRcNRGmzmkpUJQ3Ccr7WMo8QQ89trYbmToHMJKbQvx31im3gdixQ4id5KxRX+uI nrgRAb6UxCttfRfxhJDGd9/vfu5/CfiIEzCrZ2kckZiRv4P8OTrJur13e+KAYzWsRDE1 ssMpmRJeEIe9H/v04KmP5DL8dtP3NRbkhIw8ITVrVB262mHsntx/s6xeMm7ot65pLVK2 CLeg== 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:cc; bh=480vtdoP3CdZIv+SML28HrwC0u2tYd4VyUGJ5k9O078=; b=BBS1iAMyWRC8z6hGTtSgJ0G60hfq1XvTVi5kPAAvlLiga8rdsWr3M92hlnmPE40IBD 88QTgiHcoHAodggCMo83FtYpY7CDlJLhZD38d4v0eq2cvYc3dfVgqILMlmq3sd3bPJli RXJAY+/4e/xVB+JInhukD0d5/RnSVJkYaU5m0SWDKjmxUgj0yNYX4Ste1MjCnudKvacz HqrP47L4igH4PdEoHAA6CC6ay3xkCsz4BK5ncfaXnWInZqybwYNpJA/P8KQi4zXv0qaq Iifpgad1Jm96rdt0MMC4Of7vobVMBwYhlZ0DWTeJFop6lrYWUagceNRHNLzCOlYJPJCi 4HJw== X-Gm-Message-State: APjAAAVx1nGxRCIFHw01jJRj6IvYzXjYYy/aFPXuDviaVrZidTIBq1im aRK5h/sNTA2kN7+O+KxfvgTkRqVjte5/vZJuAHwqZwEh X-Google-Smtp-Source: APXvYqwmFHPolU6SX2Dww8IqNop1OVuhJUgYUhJeefTCAvDjwRMyD6MlMxsCnwRw7OOzREzRs5kt3or82FY2S4vgX2c= X-Received: by 2002:a5e:d50a:: with SMTP id e10mr12727795iom.83.1576346555627; Sat, 14 Dec 2019 10:02:35 -0800 (PST) MIME-Version: 1.0 From: Donald Eastlake Date: Sat, 14 Dec 2019 13:02:24 -0500 Message-ID: To: draft-nottingham-rfc7320bis.all@ietf.org Cc: secdir , "iesg@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007dbdf70599adc82d" Archived-At: Subject: [secdir] SECDIR Review of draft-nottingham-rfc7320bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2019 18:02:38 -0000 --0000000000007dbdf70599adc82d Content-Type: text/plain; charset="UTF-8" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with Nits. This draft looks fine from a security point of view. I agree with the Security Considerations that the draft prohibits some URI specification practices that could lead to security problems. However, maybe I was being dense, but I found it pretty hard to grasp the details of exactly what the draft was saying. No doubt someone who lives in the world of URIs all the time would have had an easier time. Nevertheless, I think the draft would be vastly improved by adding 10 to 20 examples showing URIs that are both good and bad rather than having only descriptive text of what were good and bad practices. At least I think that would make it much easier for me to have understood and reduced, perhaps to one, the number of times I needed to read the draft to feel that I really understood it. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com --0000000000007dbdf70599adc82d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dire= ctorate's ongoing effort to review all IETF documents being processed b= y the IESG.=C2=A0Document editors and WG chairs should treat these comments= just like any other last call comments.

The summary of the review i= s Ready with Nits.

This draft looks fine from a security= point of view. I agree with the Security Considerations that the draft pro= hibits some URI specification practices that could lead to security problem= s.

However, maybe I was being dense, but I found i= t pretty hard to grasp the details of exactly what the draft was saying. No= doubt someone who lives in the world of URIs all the time would have had a= n easier time. Nevertheless, I think the draft would be vastly improved by = adding 10 to 20 examples showing URIs that are both good and bad rather tha= n having only descriptive text of what were good and bad practices. At leas= t I think that would make it much easier for me to have understood and redu= ced, perhaps to one, the number of times I needed to read the draft to feel= that I really understood it.

Thanks,Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-50= 8-333-2270 (cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
= =C2=A0d3e3e3@gmail.co= m
--0000000000007dbdf70599adc82d-- From nobody Sun Dec 15 13:41:38 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9258120096; Sun, 15 Dec 2019 13:41:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ace-coap-est.all@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yaron Sheffer Message-ID: <157644608676.11574.11677986393566128538@ietfa.amsl.com> Date: Sun, 15 Dec 2019 13:41:26 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-ace-coap-est-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2019 21:41:27 -0000 Reviewer: Yaron Sheffer Review result: Ready All my previous review comments have been addressed, either through a mail exchange or in version -16/17. Thank you! From nobody Sun Dec 15 14:08:35 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D7B120098 for ; Sun, 15 Dec 2019 14:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.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 PHROCk_T6kDx for ; Sun, 15 Dec 2019 14:08:33 -0800 (PST) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 740E0120073 for ; Sun, 15 Dec 2019 14:08:33 -0800 (PST) X_CMAE_Category: , , X-CNFS-Analysis: v=2.3 cv=WOMBoUkR c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=TbrmGLU8W_AA:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=pxVhFHJ0LMsA:10 a=bmmO2AaSJ7QA:10 a=iiazv-oawmH03g7Men8A:9 a=QEXdDO2ut3YA:10 a=Z5ABNNGmrOfJ6cZ5bIyy:22 a=SsAZrZ5W_gNWK9tOzrEV:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp03.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp03.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:55000] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 12/AB-36082-FDEA6FD5; Sun, 15 Dec 2019 17:08:32 -0500 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 893581C6045; Sun, 15 Dec 2019 17:08:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=201909; t=1576447709; bh=9lSPqYYF8enYZVSZq/bVGmJ+zMgi/i47RdvCliNsjHk=; h=To:From:Subject:Date:From; b=S+e7DrfBsNVfXDojKNrzjlmMxxlKBHu2BfFZDzwFXxuNVMuGeJgEmwoC0Acmaz8c0 xx/Yh94JoHTANaEeCaYGjM6xeWCJFLfi56y5JUFIusi+R3VQtC3fq+MquEjFi6dF6G OT3+KTb3E2J0aKlaNjPOF5nUh6Cw94EAcw0rFjxPh6gRhQgQsOEmerl7zqhKMukjkU bXHi7z3MzeSTZ3bmEhw3q0lkNl969e7XEnPpwV8V6kSAINo5lETfHTLjI343I0sBPs 0lrKe/9/Cp4txO1qw8CjXzrBySEW6CaswHpJMJgiBFWK3DLZwefYbBd6e9vFz/H8hF 3I6SJbQsdv8vw== To: secdir@ietf.org, iesg@ietf.org, draft-ietf-mboned-deprecate-interdomain-asm.all@ietf.org From: David Mandelberg Message-ID: <58b3d90c-185d-b285-865f-d02e23dd22ae@mandelberg.org> Date: Sun, 15 Dec 2019 17:08:27 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-mboned-deprecate-interdomain-asm-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2019 22:08:34 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with issues. Section 3.2.3 talks about using source addresses for security. Doesn't that security rely on adoption of BCP38? (Or does the multicast destination address make BCP38 irrelevant here?) From nobody Mon Dec 16 08:53:07 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 621DF120052; Mon, 16 Dec 2019 08:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1576515120; bh=wyktEU6euL0sPX1zMwN/GikFH9Td/fopZww9e1y1dHc=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=yA8kzAK59Dw10CmuarYrMiRpGvpxk5nMrZuPHJs5rmEbqQUqz/WHzyaRBPcgmcRLR cQ9YgPXAAD/4V7DW5IWy9317vFKPdNkGQw7gdhST41buWwrDxcBkCFXx8fVJ31tpcG AKB3dOOTbg5YRtPr3v2iiw7mpSQpXFM5s1RCipHE= X-Mailbox-Line: From new-work-bounces@ietf.org Mon Dec 16 08:52:00 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B16B1200B2; Mon, 16 Dec 2019 08:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1576515120; bh=JWtrlmpPMrh9LbdzFPFEIJxN5q3BHbmov4qw0/5+CSI=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=MPUjGOAAZYNR0XeOohY81986bPsh9yD0Eyu0aAHE5FFZmUALe50lidau2YXQ1w6SQ SPbir45MgE8jTxi/EwjmvcPKLV+O9YQ+SkxJWi+QpxLRicHYq9dTY4n3qa/ZNVFGaZ BCaXiuTDX42CL5xgPEhGY6vHmYp8SmXa9kSRXyA8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE84D12089F for ; Mon, 16 Dec 2019 08:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 v8v3W7aJW9Jy for ; Mon, 16 Dec 2019 08:51:56 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7DF120052 for ; Mon, 16 Dec 2019 08:51:56 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id 21so3023359qky.4 for ; Mon, 16 Dec 2019 08:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=bOeIacuE4PHH4o14PUeZuLmv5KjeTlv8QPXoAkPiVA4=; b=bDuPTPewg25rfRDYQorM5PUI6OI7M8GFa0E7lYHObjFO9xZNQr7rhSEf1f/K043Gsg piQpsOw51S0hcu+rNctRlzSaxHeWezmwQ3UdpNDQaq7wj7AebsQ7eWXkRpISl38Tcsfl ZroUsQmsUUjFqqOtic0YWmgItP1d5nW0Y7OhkGd67s/c4ukyYZ7PJUL9dSHt7Hu+JtcT fI5s3tN3WtjGWIQ5kglmeUQEwCOUq7TDL+cXqC6jVxfuvVzatDjPlh78uUMfcC3UBYa0 4CdLpbxxcLPtn7z9y97ocwhW544h/M+cMonS/OHX580je2kMjLMFILQUYoLSBzLYC7fg vKbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=bOeIacuE4PHH4o14PUeZuLmv5KjeTlv8QPXoAkPiVA4=; b=bpDK8Pj7iJ9+2rGUoY4ja7oyjuOfXBybvc85Y2qLfeFLM5XBd2jolQon75d/8st2/L SMeAUE95BiEQaT9CLY/t8Yk+XhYDft5GfKApKRh8xCOpAuAhGsPHUB4RIqkOlAlmKvwU 2FDVChSKHm2ROQ+0Ibzts0m0AEnpB9wxGS+ucctAZ2LdLK1TSWpdLmmgwetZdML7yTHE N5x9Zkl5m6zghtIHHtfK/qL/+olQJOwrMG6i27wEGLv5MBdqOaGCOK2dT7Rts0259D/K vlS5ufiMuWo581s/pVnIU6joIOILPmrEiB2guoczEDf0a1cx0jSEFcDzZoBCdfOwzdNZ ZEVQ== X-Gm-Message-State: APjAAAXUNPTgLlG8wrRabOeL0RyMghTron/XKAx8aF6uaFlVVYHXHIT8 QUE6OP7thw9kIehN7wvU0CPHcQj7 X-Google-Smtp-Source: APXvYqyAfYNu6+CBHwBWvSHy0Bx8k93jPsI0HtWqL8kos/PO7cN7IP1l3sEEj0CezAkNi7M5lK+mgA== X-Received: by 2002:ae9:ef50:: with SMTP id d77mr157508qkg.71.1576515115132; Mon, 16 Dec 2019 08:51:55 -0800 (PST) Received: from DESKTOP6VF5FH7 ([152.208.106.92]) by smtp.gmail.com with ESMTPSA id v2sm6110045qkj.29.2019.12.16.08.51.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Dec 2019 08:51:54 -0800 (PST) From: To: , "Paul Nikolich" Date: Mon, 16 Dec 2019 11:52:03 -0500 Message-ID: <092b01d5b431$26097990$721c6cb0$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdW0J7rnyvgYP4yNTSiV1K5S/r0BQg== Content-Language: en-us Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Type: multipart/mixed; boundary="===============2804557988322389054==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 16 Dec 2019 08:53:06 -0800 Subject: [secdir] [new-work] IEEE 802 Nov 2019 Plenary - New Study Groups X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 16:52:01 -0000 This is a multipart message in MIME format. --===============2804557988322389054== Content-Type: multipart/alternative; boundary="----=_NextPart_000_092C_01D5B407.3D3434E0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_092C_01D5B407.3D3434E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Members of the IETF: In the spirit of continuing cooperation between IEEE 802 and IETF, the following letter addresses new work items for information and potential coordination with the respective IEEE 802 WG. One of the first steps in the IEEE Standards Association's standards development process is the creation of a Study Group. Study groups are chartered to create a formal Project Authorization Request (PAR) document that includes a description of the project's scope and purpose. The following Study Groups were approved at the Nov 2019 IEEE 802 Plenary - * IEEE 802.3 100 Gb/s wavelength Short Reach PHYs PAR Study Group * IEEE 802.11 Sensing PAR Study Group * IEEE 802.15 Reduced Spectral Bandwidth PHY Study Group Please note, per the IEEE 802 Policies and Procedures that a Study Group is chartered to operate until the next plenary session, a period of four months and, if it wishes to continue, must request a charter extension. Study Groups may also terminate between plenary sessions if their proposed project is approved by the IEEE Standards Association Standards Board. Additionally, within the IEEE 802 family of standards, there is a requirement that each new project proposal attaches additional documentation that describes its engineering feasibility, market potential, assurance of coexistence and distinct identity relative to previous standards (referred to as the "The Criteria for Standards Development (CSD)" in 802, which also includes the "5 criteria"). The CSD used by IEEE 802 can be found in document: https://mentor.ieee.org/802-ec/dcn/14/ec-14-0028-00-00EC-csd-informative-ext ract.pdf Also please note that IEEE meetings are open and may be attended by any individuals who register and fulfill any registration fees. Details regarding future IEEE 802 plenary meeting schedules may be found at http://802world.org/plenary/future-plenary-sessions/. Please refer to individual working groups for their interim meeting schedules. A listing of all working groups may be found at http://www.ieee802.org/. Sincerely, John D'Ambrosia Recording Secretary, IEEE 802 LMSC jdambrosia@ieee.org ------=_NextPart_000_092C_01D5B407.3D3434E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Members of the IETF:

In the spirit of continuing cooperation between IEEE = 802 and IETF, the following letter addresses new work items for = information and potential coordination with the respective IEEE 802 = WG.  

 

One of the = first steps in the IEEE Standards Association’s standards = development process is the creation of a Study Group. Study groups are = chartered to create a formal Project Authorization Request (PAR) = document that includes a description of the project’s scope and = purpose. 

 

The following Study Groups were approved = at the Nov 2019 IEEE 802 Plenary –

  • IEEE 802.3 100 Gb/s = wavelength Short Reach PHYs PAR Study Group
  • IEEE 802.11 Sensing PAR Study Group
  • IEEE 802.15 Reduced Spectral Bandwidth PHY Study = Group

 

Please note, per the IEEE 802 Policies and Procedures = that a Study Group is chartered to operate until the next plenary = session, a period of four months and, if it wishes to continue, must = request a charter extension. Study Groups may also terminate between = plenary sessions if their proposed project is approved by the IEEE = Standards Association Standards Board. 

 

Additionally, within the IEEE 802 family of standards, = there is a requirement that each new project proposal attaches = additional documentation that describes its engineering feasibility, = market potential, assurance of coexistence and distinct identity = relative to previous standards (referred to as the “The Criteria = for Standards Development (CSD)” in 802, which also includes the = “5 criteria”).  The CSD used by IEEE 802 can be found = in document: 

 

https://mentor.ieee.org/802-ec/dcn/14/ec-14-0028-00-= 00EC-csd-informative-extract.pdf   

 

Also please = note that IEEE meetings are open and may be attended by any individuals = who register and fulfill any registration fees. Details regarding future = IEEE 802 plenary meeting schedules may be found at http://802w= orld.org/plenary/future-plenary-sessions/.  Please refer to = individual working groups for their interim meeting schedules. A listing = of all working groups may be found at http://www.ieee802.org/. =     

 

Sincerely,  

 

John = D’Ambrosia 

Recording = Secretary, IEEE 802 LMSC 

jdambrosia@ieee.org =    

 

------=_NextPart_000_092C_01D5B407.3D3434E0-- --===============2804557988322389054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============2804557988322389054==-- From nobody Mon Dec 16 17:59:42 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C1C12009C; Mon, 16 Dec 2019 17:59:40 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-XGr2i90TYy; Mon, 16 Dec 2019 17:59:39 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 45A0A12092C; Mon, 16 Dec 2019 17:59:36 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id a15so11607901otf.1; Mon, 16 Dec 2019 17:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=lgwycyuxy76X032H+DymZLJXg3pIWmj6t0IUMrCDkJ0=; b=tNZXONr26dXLmPiSZBvNPEl56xrBN+mSTME5ieobITq+dn+du4Fkv7517pWZiSMbgs 6Tko9o4mHqlNKLnDvq1DF6L+h/g61RFUbtnUTk5IYFABMawJBlebSFEcIcKXMKyQv7Xt 1RZZvsI18jDd/fXQ0sKqRpFRQd/3knLpSHcWFulFytWYcqIwQv1Fg1YRC0OLLpA5aOZO 1jBsAzO+1XOZfmhCAeiucr+bRFZ4ZuLIzeGMKhXgkZM4qxyIXmNBC0lFlKUfGPne20DW 9jYvLyKisG+422H0Fp49JXt+psxqEOq73yn75yzA9RK17tWmLu8O0vUq1rpYQbaFSdh3 9GuA== 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:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=lgwycyuxy76X032H+DymZLJXg3pIWmj6t0IUMrCDkJ0=; b=aiZWg+CdroNfnpU6SwphDh2VciztfAzaMnG7avN8VIwAi9zDGXs48tRvUTYqMtLDs/ udRMRmqevouYOT061zZIHyroEpDaw5LKGckKZ6tumhbrYqqBxizgMxUvFFczDcmgUPNi Rr6TyTob3oe+p6c4AcTT8qxSy1sGu3+04M6z+cIqtFh9SZWZuyIi6/izZ3SL1ur/Vj5S JBqpJSX/9F8n9MqSSepxbt40Y1ACzt5U9szW925wm4lxmWNQLY2PmaHjvLsEd9HHGtu8 kUvE0BaC6r6GUn5765PesZTMDtFud8zrzG7xBdG0QBKf/vw7EtafyxM+Ksq+BpL9Bv34 iqMw== X-Gm-Message-State: APjAAAUbgZw2fE0DDQsajOGvKdGJgtZ9oUXn4L9tmU+lruEKug70k7mT VJKcr09R2GZOU+QIXRohlUvwzfAG X-Google-Smtp-Source: APXvYqyCGvqRUd8lHwk5x+EOSP/QUWMiAzyJoAX71qGhXowIRhSQkwnEV75UYjvFk0dPil4N+famOA== X-Received: by 2002:a9d:7305:: with SMTP id e5mr33955541otk.64.1576547975414; Mon, 16 Dec 2019 17:59:35 -0800 (PST) Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:bd1e:d437:4a83:2bad]) by smtp.googlemail.com with ESMTPSA id q7sm7584202otn.9.2019.12.16.17.59.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Dec 2019 17:59:35 -0800 (PST) To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-mpls-summary-frr-rsvpte.all@ietf.org From: Chris Lonvick Message-ID: Date: Mon, 16 Dec 2019 19:59:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [secdir] SECDIR review of draft-ietf-mpls-summary-frr-rsvpte X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 01:59:40 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY. The Security Considerations section is a bit thin, but it appropriately addresses the issue that an implementation will increase the attack surface of an RSVP object. Since this is an extension to the protocol, the security considerations sections of the controlling RFCs are identified. I skimmed the draft a few times but did not see any nits or other issues. Overall, the draft appears to be well written and well thought out. Regards, Chris From nobody Tue Dec 17 09:15:02 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5391C120B85; Tue, 17 Dec 2019 09:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=JfICdOmp; dkim=pass (1024-bit key) header.d=juniper.net header.b=jx/7L8iM 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 498fwMQdGap5; Tue, 17 Dec 2019 09:14:57 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 B93DB120B80; Tue, 17 Dec 2019 09:14:57 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBHH8cAw020207; Tue, 17 Dec 2019 09:14:44 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=date : from : to : cc : subject : in-reply-to : message-id : references : mime-version : content-type; s=PPS1017; bh=WgK76I74TWx6tAih2/zC9m2PV+jq5bEmEnHtVlv+OtE=; b=JfICdOmp3aurEx6QO0blgeGl4EQzPb4GTaHOhv0ogmKJ8LMOHFCDz6Pflm9KnhBd1Ml5 C2MQ9LlFO55OGwA5q6WrUMx3CDltk+bQeNc4sjh8infsx34xhdn+oc1A/jnkuX1G4xqh YWeuw993AhvTmPlQej+pZ698lrjmFSHJBPkTtf6qzkvT0vYX/3fTa8BfOP1PKe6dOU0J BxS6e+C87ZKErx9TEEEj7qBjyxbTXUH3ncg1pX1WHBEcFAPyfZNkIvwjalT5aYrrG5UN X4rnGDc1S8zQHCwk3yvTerniJYqGwb1D4ohsnL5Gj+x+nF2uTgab0W9rVCpXeDeOZjXE uA== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2168.outbound.protection.outlook.com [104.47.55.168]) by mx0a-00273201.pphosted.com with ESMTP id 2wy1u4r63r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Dec 2019 09:14:44 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VGWGpmgjiOvrv03ExMfdP81f9JDOOYPFa0dzLoBy6q4G9Ha2XG/+kzbxQiZi5kiUgtUKdyIDNHtekjv2MMVMYZa1bAmFi24+XDdwT06eGjFrEG0aCnscdP/bJclEPKLk57vurvHPwhN176Jh9MPfx7Ryl8TKdIwS+x+wD/AsxUOb3RQO6GTdo7mre2N4awXZwLxIgflnZx2OrKNqpl4HDLmyaEPa+4iAxx1Y/gpcK9xZEu21bd+9jew1VQopFaMl3eRbsI3LR/X+U4QI7TYYpRPqvmaHiqRaHmdH4BtQsf/84YsmR/beaZViOh4OCOFgv1TRbo3hdugdizLa9RYxig== 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=WgK76I74TWx6tAih2/zC9m2PV+jq5bEmEnHtVlv+OtE=; b=Wc1odn0kszb7c3TW9xpvuPzf5JfSnwdYriScG/+qTKPiSo2RLV9wNn3ettkq5dPiMa3lVV32It4iNiKPbv/9oepK6j2bhioSdiQxM/NHZ0XCJc6LEQfuQSHNi9w6Jv6NkBvORRVf8GtSWAL5eJZN/TCjOjjgSOimYnzgMCxl2GeLh7qrbDigcWXfhSuyvCOEVCmWrRpoeYbXcFHLvdUXqKDI/z9T9Ic+axxPNCgTBP/xc9iyxzQszjDGlhp659O4aOHwlPFvfH7S+Dn6PmpglhS7eYl9+NYajiyork+rpiO0/yy90wdbIQhZLCLUD02f5Diu5ZXRK5BQ8y+i+OYPQA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.242.12) smtp.rcpttodomain=t-systems.se smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WgK76I74TWx6tAih2/zC9m2PV+jq5bEmEnHtVlv+OtE=; b=jx/7L8iMjhyCwibpnh+ORCSNgraixXy5aPIFeVzzoFe+NohqcwcCtbSGdwsmY16z7KXO4CkzIFlod4a+YI1PGPON96AiWFvOjqXiAb2ZjhVNiqASpjKZywvocPE1Ga2pvV9RBX0w6eWqeiaiaRBnRCsSCJQf+rwUg+udXChaqS4= Received: from BN3PR05CA0034.namprd05.prod.outlook.com (2603:10b6:400::44) by MWHPR05MB3150.namprd05.prod.outlook.com (2603:10b6:300:b3::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.11; Tue, 17 Dec 2019 17:14:41 +0000 Received: from CO1NAM05FT005.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::206) by BN3PR05CA0034.outlook.office365.com (2603:10b6:400::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.9 via Frontend Transport; Tue, 17 Dec 2019 17:14:40 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.242.12 as permitted sender) Received: from P-EXFEND-EQX-01.jnpr.net (66.129.242.12) by CO1NAM05FT005.mail.protection.outlook.com (10.152.96.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2559.8 via Frontend Transport; Tue, 17 Dec 2019 17:14:40 +0000 Received: from P-EXBEND-EQX-01.jnpr.net (10.104.8.52) by P-EXFEND-EQX-01.jnpr.net (10.104.8.54) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 17 Dec 2019 09:14:38 -0800 Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXBEND-EQX-01.jnpr.net (10.104.8.52) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 17 Dec 2019 09:14:37 -0800 Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 17 Dec 2019 09:14:37 -0800 Received: from contrail-ubm-wing.svec1.juniper.net ([10.163.18.88]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id xBHHEYN7019805; Tue, 17 Dec 2019 09:14:34 -0800 (envelope-from lenny@juniper.net) Received: by contrail-ubm-wing.svec1.juniper.net (Postfix, from userid 1709) id 239AE1236F2; Tue, 17 Dec 2019 09:14:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by contrail-ubm-wing.svec1.juniper.net (Postfix) with ESMTP id 1610A120AFE; Tue, 17 Dec 2019 09:14:34 -0800 (PST) Date: Tue, 17 Dec 2019 09:14:33 -0800 From: Leonard Giuliano X-X-Sender: lenny@contrail-ubm-wing.svec1.juniper.net To: David Mandelberg CC: , , , , , , , , , Colin Doyle In-Reply-To: <58b3d90c-185d-b285-865f-d02e23dd22ae@mandelberg.org> Message-ID: References: <58b3d90c-185d-b285-865f-d02e23dd22ae@mandelberg.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.242.12; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(136003)(396003)(199004)(189003)(8676002)(54906003)(6266002)(107886003)(2906002)(336012)(426003)(6916009)(81156014)(5660300002)(81166006)(7416002)(86362001)(186003)(356004)(8936002)(70586007)(478600001)(76130400001)(316002)(4326008)(26005)(26826003)(70206006)(7126003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3150; H:P-EXFEND-EQX-01.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0aaec9c1-2e8c-42f4-7a8d-08d7831499f1 X-MS-TrafficTypeDiagnostic: MWHPR05MB3150: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 02543CD7CD X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ErRPqcx4e1s0nEgJjGadHGg1PDey9NXVuR6eAtB8GKQXFWbY1Wnkj8VEHg/glRnXQWMqQNEkKBoCv1/bd1ubrQCSpYagMVfBLpWbsSsiDVoHFmYfuWbll2apYt91BCHljHpBqXB7A12OJgBhOeTm3AXWSItQ237kBeQj/MgVwfGeAFrwp31KTexbbDppCsm4jJmBgLzdKuyyFoiAtBhqeMjQZAY+xn13VQ7cD/9vd5dPpoAcS6a/tCqMFOjc1KTk/SckE4zcUfIgok161jeamSWaLT9S/WylYpfl5BGGh4Koqc1V6UhWR8DEIqqH9tas3gukeGU4m9oxW+wSbfrLBYdgqH0/45ds4v8n312c3MZ50/6RqytxUjITnfOj8hj0GSA1st8EK3lrkb73AWfjla75glpBq0Yc6EKO3oVVv+6zCCwf89rE6OYiRly1g7hp X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2019 17:14:40.0527 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0aaec9c1-2e8c-42f4-7a8d-08d7831499f1 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.242.12]; Helo=[P-EXFEND-EQX-01.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3150 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-17_03:2019-12-17,2019-12-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 adultscore=0 clxscore=1011 mlxscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912170135 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-mboned-deprecate-interdomain-asm-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 17:14:59 -0000 David, Thank you for your review. BCP38 is not really relevant for multicast, as RPF is baked into the cake when it comes to multicast. If anything, BCP38 can be thought of as making unicast behave the way multicast has always operated, as multicast forwarding is inherently based on the source address. Please let me know if this answers your question, or if I'm missing anything. Thanks, Lenny On Sun, 15 Dec 2019, David Mandelberg wrote: | I have reviewed this document as part of the security directorate's | ongoing effort to review all IETF documents being processed by the | IESG. These comments were written primarily for the benefit of the | security area directors. Document editors and WG chairs should treat | these comments just like any other last call comments. | | The summary of the review is Ready with issues. | | Section 3.2.3 talks about using source addresses for security. Doesn't that | security rely on adoption of BCP38? (Or does the multicast destination address | make BCP38 irrelevant here?) | From nobody Tue Dec 17 09:21:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8CD120BBD for ; Tue, 17 Dec 2019 09:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.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 ntk21W8_1XRV for ; Tue, 17 Dec 2019 09:21:19 -0800 (PST) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 B472E120BB9 for ; Tue, 17 Dec 2019 09:21:19 -0800 (PST) X_CMAE_Category: , , X-CNFS-Analysis: v=2.3 cv=WOMBoUkR c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=pxVhFHJ0LMsA:10 a=bmmO2AaSJ7QA:10 a=aWNCq2tAMQIAjycbqW4A:9 a=1mlC-N17ibfXqSNF:21 a=2efB-V6qrHRURD4V:21 a=QEXdDO2ut3YA:10 a=pHzHmUro8NiASowvMSCR:22 a=n87TN5wuljxrRezIQYnT:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp03.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp03.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:55552] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 05/1B-36082-E8E09FD5; Tue, 17 Dec 2019 12:21:18 -0500 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 22CA81C6045; Tue, 17 Dec 2019 12:21:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=201909; t=1576603276; bh=aXH//XYu4cPIANIWSz7UGD6arTonmk1iL4uufb8+Cfk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=g6kquT/tlbP0jKL+ZdgtMEngOn+ucuNyDMHS84cdmbf/EwQVSp1qZsrg26d2WMYJ5 O/O4Kx7oiLZCzH1RXNJIYIoJLwrvpQUTabxHkXoj8amknc/aujv3nIbrLDc0XkqRCi b78/dTRBsjAW26YbA57Y4Buo9DbLj+/lrb3IL+s82HlwIk3alFSWawX+CSVLaygGt5 KQGW3AnF71iCoF3gUoz/3PW5vMxzM4yuEMdnxfCeXOGkclx/4/CEwDx4EMp+WoPY8b dDPYCDPQlh+ctHHz3Q2YTNm1UNWg7U8MYUZ8qCsiPQ6t8opHf02mRLMJ1nEks9NQmZ 5KAJG0b/pIhUQ== To: Leonard Giuliano Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-mboned-deprecate-interdomain-asm.all@ietf.org, mikael.abrahamsson@t-systems.se, tim.chown@jisc.ac.uk, tte+ietf@cs.fau.de, gjshep@gmail.com, ibagdona@gmail.com, warren@kumari.net, Colin Doyle References: <58b3d90c-185d-b285-865f-d02e23dd22ae@mandelberg.org> From: David Mandelberg Message-ID: <01bbde3d-dd1d-f224-e007-c6fcf33663e0@mandelberg.org> Date: Tue, 17 Dec 2019 12:21:13 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-mboned-deprecate-interdomain-asm-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 17:21:22 -0000 Yup, that answers my question, thanks. On 12/17/19 12:14 PM, Leonard Giuliano wrote: > David, > > Thank you for your review. BCP38 is not really relevant for multicast, as > RPF is baked into the cake when it comes to multicast. If anything, BCP38 > can be thought of as making unicast behave the way multicast has always > operated, as multicast forwarding is inherently based on the source > address. > > Please let me know if this answers your question, or if I'm missing > anything. > > Thanks, > Lenny > > On Sun, 15 Dec 2019, David Mandelberg wrote: > > | I have reviewed this document as part of the security directorate's > | ongoing effort to review all IETF documents being processed by the > | IESG. These comments were written primarily for the benefit of the > | security area directors. Document editors and WG chairs should treat > | these comments just like any other last call comments. > | > | The summary of the review is Ready with issues. > | > | Section 3.2.3 talks about using source addresses for security. Doesn't that > | security rely on adoption of BCP38? (Or does the multicast destination address > | make BCP38 irrelevant here?) > | > From nobody Tue Dec 17 14:02:08 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E92120044; Tue, 17 Dec 2019 14:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 da0Wt8piSuxN; Tue, 17 Dec 2019 14:02:02 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6BEF712004D; Tue, 17 Dec 2019 14:02:02 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBHM1vHB013099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Dec 2019 17:01:59 -0500 Date: Tue, 17 Dec 2019 14:01:57 -0800 From: Benjamin Kaduk To: Charlie Kaufman Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ace-oauth-params.all@ietf.org" Message-ID: <20191217220157.GH81833@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-ace-oauth-params-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 22:02:06 -0000 Hi Charlie, Thanks for the review! On Fri, Dec 13, 2019 at 07:48:22AM +0000, Charlie Kaufman wrote: > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > This document only exists because of a scheduling issue between the ACE and OAUTH working groups. The ACE working group needed some additional OAUTH extensions added more quickly that the OAUTH group could manage to do it. This document is intended to only exist until the OAUTH group can make the corresponding changes. As such, it really doesn't have security considerations beyond those in the document it modifies. > > The security considerations section says (and I agree): > > This document is an extension to [I-D.ietf-ace-oauth-authz]. All security considerations from that document apply here as well. > > Some acronyms that were not defined (but this might be OK in the context of this being a modification to another document): AS, RS, CoAP, cnf, CBOR, pop, CWT > > > A few typos / odd phrasing: > > Abstract: whishes -> wishes > Appendix A: possesion -> possession > > >From Section 2: > Note that the term "endpoint" is used here following its OAuth 2.0 [RFC6749] definition, which is to denote resources such as token and introspection at the AS and authz-info at the RS. > > Really? The term "endpoint" refers to tokens and authz-info data structures? This seems unlikely. Not data structures, but (HTTP/CoAP) resources -- "things you can POST to". > Continuing in Section 2: > The CoAP [RFC7252] definition, which is "An entity participating in the CoAP protocol" is not used in this specification. > > Why is a definition that does not apply relevant to this document? This document is at the intersection of two worlds: CoAP and OAuth. Both define "endpoint" but in contradictory ways. Since at least one has to lose, giving the reader a pretty explicit hint that they're wrong to use a given definition seems to have value. But maybe I'm in the rough; we'll see :) -Ben From nobody Wed Dec 18 05:45:48 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B4E12004C; Wed, 18 Dec 2019 05:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.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 9m5bf7MOtWEu; Wed, 18 Dec 2019 05:45:36 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4A512003E; Wed, 18 Dec 2019 05:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=t7zDSOCjt6kFf2vidi2Wqcl8nV3C8Q2rZiWCV70y0fs=; b=ezlBokCHSbHTO+1GHNDH/xt3HM A683IH1r1fDX665tH68yf3UC0f5gDHzL+GY5D+iX5p07gEtj42P2KWxi2JfpFfNCpraIWqPFgvItU o+R9z6UXkrI17tfSDVo0/4Ch2kn4UBRDFqnOOhVALAg2g+Pa9xZF3jhGgqoUBRXvTO51/oZf0p/80 2jlMaOAGwQCEyi729jD1VeTRJDdChASdLti+4BT3Z1XoMGsm14il8cdA5lKrioCKY52GE5F4kPrNG YgplWTb2/LqtoifTvVYTAiVWk2XDsCvucVGDrpVFiw37IgRYG8mcJAbJIx1ya3RS8ZowvF5dY+ocW d8LBfjKQ==; Received: from [2001:b98:204:102:fffa::2] (port=51553) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1ihZdq-0006DP-SS; Wed, 18 Dec 2019 13:45:34 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sara Dickinson In-Reply-To: <157504194893.4871.5551746255324168227@ietfa.amsl.com> Date: Wed, 18 Dec 2019 13:45:27 +0000 Cc: secdir@ietf.org, last-call@ietf.org, dns-privacy@ietf.org, draft-ietf-dprive-rfc7626-bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> References: <157504194893.4871.5551746255324168227@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3445.104.11) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 13:45:38 -0000 > On 29 Nov 2019, at 15:39, Stephen Farrell via Datatracker = wrote: >=20 > Reviewer: Stephen Farrell > Review result: Ready Hi Stephen,=20 Thanks for reviewing (again)! >=20 > I might not be the best reviewer for this one as I've read it a few = times > before. But anyway, I scanned the diff [1] with RFC7626 and figure it > seems fine.=20 >=20 > The only thing that occurred to me that seemed missing was to note > that while the new privacy analysis in 3.5.1.1 is already complex, = many > systems are mobile and hence an analysis that ignores that won't be=20 > sufficient. For a mobile device one really needs to analyse all of the=20= > possible setups, and hence it's even harder to get to a good answer.=20= > (It could be that that's elsewhere in the document but since I only=20 > read the diff, I didn't see it:-) There was a bit of discussion about this and the following text in 3.4.1 = was added: =E2=80=9C It is also noted that typically a device connected _only_ to a = modern cellular network is o directly configured with only the recursive resolvers of the IAP and o all traffic (including DNS) between the device and the cellular network is encrypted following an encryption profile edited by the Third Generation Partnership Project (3GPP [2]). The attack surface for this specific scenario is not considered = here." Which hopefully covers this? Sara From nobody Wed Dec 18 05:52:45 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1D61200D8 for ; Wed, 18 Dec 2019 05:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXXt9SxQx7vJ for ; Wed, 18 Dec 2019 05:52:32 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 82DE8120122 for ; Wed, 18 Dec 2019 05:52:32 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id j6so2239075lja.2 for ; Wed, 18 Dec 2019 05:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=li2j8mJJkaVungXNE/EyRnIDFFpV67eTXZpHbKVp4ec=; b=AKFDh3c371qVXS8reZJAJoizAGM9T8fS+swatPeM9V92ymZ3S9xs3PH+1lx6SE9fdm sVHKBYe8qmFJ+jtYEQME6ofAKwlc/p1nyuJFqVC9x7PpxRiF2vTWt3aYPwV/6PjLaxnk Cc+LUNhqM8foB6yo8ztvPhKkT5UecOmHwCynte9/SON/59xnpiHry/E3Kj+wdc2pM0p2 8UntLcK208l9t5IvPYZGC39d2YCF9iQwczc35GkuKPEDH13EV2FOlRpcXss66TOhhwV3 m1wUUpwHr5qJ3K/oBgzbMvYEUdN6rbYaPSJ/wASXI829nLQ5G5Sz80KEn7qzKbpO0umR 37tg== 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=li2j8mJJkaVungXNE/EyRnIDFFpV67eTXZpHbKVp4ec=; b=VTWIhj6IasPm0cabOA7A6kiKxqn1oAI+wqTI4/B1pxqQ4y08YhdSIV4FPq6pxNX5bM Q5jpVL2w4iELpGK7mF+1FRwrrTDDt8XwcHP7jK0kKzl02qTBoLfX8c+MQOXmLOw6EpEj J01Qz2SNH/OIicDrSNMo8hCTw+Pm37c0Gq1LSQdeHENm0p0NBJu5q4AI3gpU/xsUZ4bD b69/I4nLtcFTotBuyf7inq6YE2iwyxJsFmvmsHjNxulxaz2cZtKNP9zjAudq5qWZqz95 vbB63D11CyD8fxXbDiGemFTdkKibTHZMCnfxWjENw5yhEoiWzdz7ppMJPbWPslZa/54k YheQ== X-Gm-Message-State: APjAAAWLq5SQeI7/WVDX1JnzuGJEJre0Th+Aqd16lWLgyrBXssqbWHPD liQ0Atga/PR56t2rCiBwyE1R+JX7gLN+rUMgXUi6aw== X-Google-Smtp-Source: APXvYqyhLL4a7M77iQb7kPj3GUcNQGePbuFJfHZbR7xZYu97k85i+9JXSpqCx33zubbK4PwgqXPdqWB9h7Y2xQoWZ+Y= X-Received: by 2002:a2e:95c4:: with SMTP id y4mr1867410ljh.38.1576677150678; Wed, 18 Dec 2019 05:52:30 -0800 (PST) MIME-Version: 1.0 References: <157504194893.4871.5551746255324168227@ietfa.amsl.com> <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> In-Reply-To: <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> From: Eric Rescorla Date: Wed, 18 Dec 2019 05:51:54 -0800 Message-ID: To: Sara Dickinson Cc: Stephen Farrell , last-call@ietf.org, dns-privacy@ietf.org, draft-ietf-dprive-rfc7626-bis.all@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000007df5210599fac19f" Archived-At: Subject: Re: [secdir] [dns-privacy] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 13:52:35 -0000 --0000000000007df5210599fac19f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 18, 2019 at 5:45 AM Sara Dickinson wrote: > > > > On 29 Nov 2019, at 15:39, Stephen Farrell via Datatracker < > noreply@ietf.org> wrote: > > > > Reviewer: Stephen Farrell > > Review result: Ready > > Hi Stephen, > > Thanks for reviewing (again)! > > > > > I might not be the best reviewer for this one as I've read it a few tim= es > > before. But anyway, I scanned the diff [1] with RFC7626 and figure it > > seems fine. > > > > The only thing that occurred to me that seemed missing was to note > > that while the new privacy analysis in 3.5.1.1 is already complex, many > > systems are mobile and hence an analysis that ignores that won't be > > sufficient. For a mobile device one really needs to analyse all of the > > possible setups, and hence it's even harder to get to a good answer. > > (It could be that that's elsewhere in the document but since I only > > read the diff, I didn't see it:-) > > There was a bit of discussion about this and the following text in 3.4.1 > was added: > > =E2=80=9C It is also noted that typically a device connected _only_ to a = modern > cellular network is > > o directly configured with only the recursive resolvers of the IAP > and > o all traffic (including DNS) between the device and the cellular > network is encrypted following an encryption profile edited by the > Third Generation Partnership Project (3GPP [2]). > > The attack surface for this specific scenario is not considered here." > This seems insufficient. We don't generally assume that the encryption in mobile access networks is secure, if only for operational complexity reasons. So I think this case could do with rather more text. -Ekr > > Which hopefully covers this? > > Sara > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > --0000000000007df5210599fac19f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 18, 2019 at 5:45 AM Sara = Dickinson <sara@sinodun.com> = wrote:


> On 29 Nov 2019, at 15:39, Stephen Farrell via Datatracker <noreply@ietf.org> wro= te:
>
> Reviewer: Stephen Farrell
> Review result: Ready

Hi Stephen,

Thanks for reviewing (again)!

>
> I might not be the best reviewer for this one as I've read it a fe= w times
> before. But anyway, I scanned the diff [1] with RFC7626 and figure it<= br> > seems fine.
>
> The only thing that occurred to me that seemed missing was to note
> that while the new privacy analysis in 3.5.1.1 is already complex, man= y
> systems are mobile and hence an analysis that ignores that won't b= e
> sufficient. For a mobile device one really needs to analyse all of the=
> possible setups, and hence it's even harder to get to a good answe= r.
> (It could be that that's elsewhere in the document but since I onl= y
> read the diff, I didn't see it:-)

There was a bit of discussion about this and the following text in 3.4.1 wa= s added:

=E2=80=9C It is also noted that typically a device connected _only_ to a mo= dern
=C2=A0 =C2=A0cellular network is

=C2=A0 =C2=A0o=C2=A0 directly configured with only the recursive resolvers = of the IAP
=C2=A0 =C2=A0 =C2=A0 and

=C2=A0 =C2=A0o=C2=A0 all traffic (including DNS) between the device and the= cellular
=C2=A0 =C2=A0 =C2=A0 network is encrypted following an encryption profile e= dited by the
=C2=A0 =C2=A0 =C2=A0 Third Generation Partnership Project (3GPP [2]).

=C2=A0 =C2=A0The attack surface for this specific scenario is not considere= d here."

This seems insufficient. = We don't generally assume that the encryption in
mobile acces= s networks is secure, if only for operational complexity reasons.
So I think this case could do with rather more text.

-Ekr


=C2=A0

Which hopefully covers this?

Sara

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.= org
https://www.ietf.org/mailman/listinfo/dns-privacy
--0000000000007df5210599fac19f-- From nobody Wed Dec 18 06:01:05 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9547A12004C; Wed, 18 Dec 2019 06:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 u1fo6AmgG1J1; Wed, 18 Dec 2019 06:00:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91FA712003E; Wed, 18 Dec 2019 06:00:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 09B0BBE3E; Wed, 18 Dec 2019 14:00:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQs-AN3upCfc; Wed, 18 Dec 2019 14:00:46 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 92884BE2E; Wed, 18 Dec 2019 14:00:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1576677645; bh=zdSfsJdTboN5sU0T8lg9vsHCFUEehEqay2+9ZVJnkzc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HsiwsuSiPQ6UcEi2HhcthmxBUZzlfQnGEL1N9dks2tGpt5awmyK5S6hQCVvgh7mv5 ZzA+5CtdIiJw9SxkEG47cNVw2Hwn/VLj56yUtup/G73B1F6vIx929rW4Dr2KwaQdce 4sULrIJYTkqoIlJ/L1Lithw/wqgLjdUS3BfRiYLw= To: Sara Dickinson Cc: last-call@ietf.org, dns-privacy@ietf.org, draft-ietf-dprive-rfc7626-bis.all@ietf.org, secdir@ietf.org References: <157504194893.4871.5551746255324168227@ietfa.amsl.com> <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Wed, 18 Dec 2019 14:00:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="giHowYAmeM5rdp3Gd716LRmrS2eqNilcW" Archived-At: Subject: Re: [secdir] [dns-privacy] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 14:00:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --giHowYAmeM5rdp3Gd716LRmrS2eqNilcW Content-Type: multipart/mixed; boundary="hsMMyk8Jm1OXTVLTHmLscZRP9t0qtgKA8"; protected-headers="v1" From: Stephen Farrell To: Sara Dickinson Cc: last-call@ietf.org, dns-privacy@ietf.org, draft-ietf-dprive-rfc7626-bis.all@ietf.org, secdir@ietf.org Message-ID: Subject: Re: [dns-privacy] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03 References: <157504194893.4871.5551746255324168227@ietfa.amsl.com> <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> In-Reply-To: <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> --hsMMyk8Jm1OXTVLTHmLscZRP9t0qtgKA8 Content-Type: multipart/mixed; boundary="------------E0C90946869CBD1FCE7A8159" Content-Language: en-US This is a multi-part message in MIME format. --------------E0C90946869CBD1FCE7A8159 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 18/12/2019 13:45, Sara Dickinson wrote: >=20 >=20 >> On 29 Nov 2019, at 15:39, Stephen Farrell via Datatracker wrote: >> >> Reviewer: Stephen Farrell >> Review result: Ready >=20 > Hi Stephen,=20 >=20 > Thanks for reviewing (again)! >=20 >> >> I might not be the best reviewer for this one as I've read it a few ti= mes >> before. But anyway, I scanned the diff [1] with RFC7626 and figure it >> seems fine.=20 >> >> The only thing that occurred to me that seemed missing was to note >> that while the new privacy analysis in 3.5.1.1 is already complex, man= y >> systems are mobile and hence an analysis that ignores that won't be=20 >> sufficient. For a mobile device one really needs to analyse all of the= =20 >> possible setups, and hence it's even harder to get to a good answer.=20 >> (It could be that that's elsewhere in the document but since I only=20 >> read the diff, I didn't see it:-) >=20 > There was a bit of discussion about this and the following text in 3.4.= 1 was added: >=20 > =E2=80=9C It is also noted that typically a device connected _only_ to = a modern > cellular network is >=20 > o directly configured with only the recursive resolvers of the IAP > and >=20 > o all traffic (including DNS) between the device and the cellular > network is encrypted following an encryption profile edited by th= e > Third Generation Partnership Project (3GPP [2]). >=20 > The attack surface for this specific scenario is not considered here= =2E" >=20 > Which hopefully covers this? Not really, no. My point is that the analysis in 3.5.1.1 doesn't encompass the fact that hosts are often (or even mostly) mobile and hence connect to many networks, and that the results of a privacy analysis related to DoT/DoH will likely differ for each of those networks, from the POV of the user or device owner, and even those two may not agree in some cases. I don't believe that point is made in the document. But I'm ok that you and the ADs figure out if its needed or not. Cheers, S. >=20 > Sara >=20 > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy >=20 --------------E0C90946869CBD1FCE7A8159 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------E0C90946869CBD1FCE7A8159-- --hsMMyk8Jm1OXTVLTHmLscZRP9t0qtgKA8-- --giHowYAmeM5rdp3Gd716LRmrS2eqNilcW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl36MQ0ACgkQWrL68XsX K+rWYw/+Nq9DNYz2E2R7SUoC7XlgjPOxCPz+su70PIEvppKJ4oOcZv+V4u0tYjZ9 444t70CSmoudSKn45brxUSh46i6YHIh9aTq72Tt0ny/SLVItfEluKe221D1BNuPv 7RXdp5SbcBLJo+rBK2kTsE+0pBhKG4BJi/umBS62B9cpERnHiDk1ER1s/VzFpi9K wwx+RwbEVV5K0dM2rWenk12wS8XYoYXZpydlw3Lj8qzgKd4J/poopkYiCxWYLm4r vI4pnTeyaiB5sSiG3DqfqJgBGop++T+LGr2MLBdcCW8/K6oiGS72xV4iqu2rABm7 RZyo8P97k9ht1ghohqieS9jYJ7t90AdwYcvdY/zmmL6AD0rljhmSdtx9sPuGkP8T XB4YmxOiyZZgEXRNz/9d5ANRKRur2xq0n7jDiMJEeZjUYxrToz8TpzCp6tstdXn4 Nf6ucF7sGyh+3L0I+WrJUo7P3rSY6SKnS4XSZ+szAkVIJAp0ptEwpAxis/JyLPgJ OWDcTXPmckFyjKEqvUM/maKKd3DOa5C5+ydEpE9YSfso3CBXLvQ6FLnP+Ya74PAX LAfO6Wg7t2xFH+SU7CBzN537NnZPtVHoHuYKWvkbdEkQB+CFhE0dzmv/g73lMUDt HHisHrrE5Sm/yOQnyT4nGp3jB03FPtDuMGQJCTDY93pLvoZri6M= =G+PU -----END PGP SIGNATURE----- --giHowYAmeM5rdp3Gd716LRmrS2eqNilcW-- From nobody Wed Dec 18 17:49:53 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C17B120026; Wed, 18 Dec 2019 17:49:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Franke via Datatracker To: Cc: draft-ietf-mboned-driad-amt-discovery.all@ietf.org, last-call@ietf.org, mboned@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Daniel Franke Message-ID: <157672018216.4869.15864357654393087401@ietfa.amsl.com> Date: Wed, 18 Dec 2019 17:49:42 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mboned-driad-amt-discovery-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2019 01:49:42 -0000 Reviewer: Daniel Franke Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Sorry about the last minute review. This document is Ready. Its very intent gives me a little bit of anxiety: given the inherent DDoS amplification potential of any kind of UDP multicast, I tend to consider attempts to expand its usability beyond the most tightly-controlled and thoughtfully-configured environments to be ill-advised, but that is something the availability of auto-configuration protocols like this one will tend to encourage. However, this is something that clearly still has good uses and its security considerations section is thorough, which is all I can really ask. From nobody Wed Dec 18 20:15:13 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61ADE12004F; Wed, 18 Dec 2019 20:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_6aq_j2NrOZ; Wed, 18 Dec 2019 20:15:05 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 EAFDF120018; Wed, 18 Dec 2019 20:15:04 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 88EE9A8B6BF845C82E8B; Thu, 19 Dec 2019 04:15:02 +0000 (GMT) Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 19 Dec 2019 04:15:01 +0000 Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 19 Dec 2019 04:15:01 +0000 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 19 Dec 2019 04:15:01 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Thu, 19 Dec 2019 12:14:52 +0800 From: Tianran Zhou To: "secdir@ietf.org" , IETF IPPM WG CC: Caoli Thread-Topic: security considerations on the TWAMP Thread-Index: AdW2IE+K7R6ZTjm3QMWstOtse9zzeA== Date: Thu, 19 Dec 2019 04:14:51 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.162] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BF149C8CNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [secdir] security considerations on the TWAMP X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2019 04:15:06 -0000 --_000_BBA82579FD347748BEADC4C445EA0F21BF149C8CNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi IPPM and SecDir, When firstly set up the control session between the client and the server, = TWAMP(RFC5357) server will listen on a specific TCP port. By default, the w= ell-known port is 862. However, RFC 5357 does not provide mechanism to restrict the source IP addr= ess of the request. How do you think about the potential DDOS attack risk from the unknown IP s= ource addresses? Thanks, Tianran --_000_BBA82579FD347748BEADC4C445EA0F21BF149C8CNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi IPPM and SecDir,

 

When firstly set up the control session between the = client and the server, TWAMP(RFC5357) server will listen on a specific TCP = port. By default, the well-known port is 862.

However, RFC 5357 does not provide mechanism to rest= rict the source IP address of the request.

How do you think about the potential DDOS attack ris= k from the unknown IP source addresses?

 

Thanks,

Tianran

--_000_BBA82579FD347748BEADC4C445EA0F21BF149C8CNKGEML515MBXchi_-- From nobody Wed Dec 18 22:03:15 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A83120018; Wed, 18 Dec 2019 22:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEPapllhltxn; Wed, 18 Dec 2019 22:03:11 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C4112008B; Wed, 18 Dec 2019 22:03:11 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBJ62bod019653; Thu, 19 Dec 2019 06:03:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=aGr7eltAmzq0no/98Vs6nZJ/CZtFc6JE4aGsGVQAvu4=; b=LwAXGK1c8cOhRhE9RCSzev567L687ZVp5f37dmZJP2WjoG7ZTH2nvUOuIRZiLwNA8sD5 /NTnNWaG031cPpMLQ4K0jkeEXC6zF0EQy3fgKpRvr9TSMyF/Sw98ZTknd/e3fCqeSV3p MIl/JMpjxfhpOgWtZd/EBFMLYRgdU6pLtfLvKDjtsLULHF9m7XL4QZ+HQaRjwffpaYLC q1gt8bThgyQpACyyGYi1Yf8CjiVssGXpXslrQO17LG8//ziwPrMexQw1iPEn+SRyp7jB 9ZrqhQ6O7Pk13iZNUF0grDmVm8TXSRiyGXu2uXnBsXz/7Fj44c1uqRa9WsTzM/9M+wTd 2Q== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2wyyksrqcd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Dec 2019 06:03:11 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xBJ62Xr2016888; Thu, 19 Dec 2019 01:03:10 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint8.akamai.com with ESMTP id 2wvuy2h2g7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Dec 2019 01:03:10 -0500 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) by USTX2EX-DAG3MB2.msg.corp.akamai.com (172.27.165.126) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Dec 2019 22:03:09 -0800 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.165.124]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.165.124]) with mapi id 15.00.1473.005; Wed, 18 Dec 2019 22:03:09 -0800 From: "Holland, Jake" To: "Franke, Daniel" , "secdir@ietf.org" CC: "draft-ietf-mboned-driad-amt-discovery.all@ietf.org" , "last-call@ietf.org" , "mboned@ietf.org" Thread-Topic: [MBONED] Secdir last call review of draft-ietf-mboned-driad-amt-discovery-11 Thread-Index: AQHVtg6oHMwqpAy6pka1MO991KYBb6fA99qA Date: Thu, 19 Dec 2019 06:03:09 +0000 Message-ID: <76126E23-3913-4EDA-AE5E-B5EC62C69ED2@akamai.com> References: <157672018216.4869.15864357654393087401@ietfa.amsl.com> In-Reply-To: <157672018216.4869.15864357654393087401@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.80.63] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-18_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912190049 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-18_08:2019-12-17,2019-12-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 impostorscore=0 spamscore=0 suspectscore=0 clxscore=1011 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912190049 Archived-At: Subject: Re: [secdir] [MBONED] Secdir last call review of draft-ietf-mboned-driad-amt-discovery-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2019 06:03:14 -0000 SGkgRGFuaWVsLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuDQoNCkkgaGVhciBhbmQgdW5kZXJz dGFuZCB0aGUgYW54aWV0eS4gIEluIGNhc2UgaXQgaGVscHMgYW55LCBJJ20gdHJ5aW5nIHRvDQph ZGRyZXNzIGF0IGxlYXN0IHNvbWUgb2YgdGhvc2UgY29uY2VybnMgaW4gb3RoZXIgZG9jdW1lbnRz IChlLmcuDQpkcmFmdC1qaG9sbGFuZC1tYm9uZWQtY2JhY2MpLg0KDQpJIGFncmVlIGl0IHdpbGwg dGFrZSBzb21lIHRob3VnaHRmdWwgY29uZmlndXJhdGlvbiBhbmQgY2F1dGlvdXMgY29udHJvbHMN CnRvIGF2b2lkIHRyb3VibGVzLCBidXQgSSB0aGluayB0aGVyZSBhcmUgc29tZSBuZXR3b3JrcyB0 aGF0IGNhbiBibGF6ZSBhDQp1c2VmdWwgdHJhaWwgaGVyZS4NCg0KQmVzdCwNCkpha2UNCg0K77u/ T24gMjAxOS0xMi0xOCwgMTc6NTAsICJEYW5pZWwgRnJhbmtlIHZpYSBEYXRhdHJhY2tlciIgPG5v cmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KDQpSZXZpZXdlcjogRGFuaWVsIEZyYW5rZQ0KUmV2aWV3 IHJlc3VsdDogUmVhZHkNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBv ZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyAgb25nb2luZw0KZWZmb3J0IHRvIHJldmlldyBh bGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSAgSUVTRy4gIFRoZXNlDQpj b21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgIHNl Y3VyaXR5IGFyZWENCmRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBz aG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdA0KbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxs IGNvbW1lbnRzLg0KDQpTb3JyeSBhYm91dCB0aGUgbGFzdCBtaW51dGUgcmV2aWV3LiBUaGlzIGRv Y3VtZW50IGlzIFJlYWR5LiBJdHMgdmVyeSBpbnRlbnQNCmdpdmVzIG1lIGEgbGl0dGxlIGJpdCBv ZiBhbnhpZXR5OiBnaXZlbiB0aGUgaW5oZXJlbnQgRERvUyBhbXBsaWZpY2F0aW9uDQpwb3RlbnRp YWwgb2YgYW55IGtpbmQgb2YgVURQIG11bHRpY2FzdCwgSSB0ZW5kIHRvIGNvbnNpZGVyIGF0dGVt cHRzIHRvIGV4cGFuZA0KaXRzIHVzYWJpbGl0eSBiZXlvbmQgdGhlIG1vc3QgdGlnaHRseS1jb250 cm9sbGVkIGFuZCB0aG91Z2h0ZnVsbHktY29uZmlndXJlZA0KZW52aXJvbm1lbnRzIHRvIGJlIGls bC1hZHZpc2VkLCBidXQgdGhhdCBpcyBzb21ldGhpbmcgdGhlIGF2YWlsYWJpbGl0eSBvZg0KYXV0 by1jb25maWd1cmF0aW9uIHByb3RvY29scyBsaWtlIHRoaXMgb25lIHdpbGwgdGVuZCB0byBlbmNv dXJhZ2UuIEhvd2V2ZXIsDQp0aGlzIGlzIHNvbWV0aGluZyB0aGF0IGNsZWFybHkgc3RpbGwgaGFz IGdvb2QgdXNlcyBhbmQgaXRzIHNlY3VyaXR5DQpjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIHRo b3JvdWdoLCB3aGljaCBpcyBhbGwgSSBjYW4gcmVhbGx5IGFzay4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1CT05FRCBtYWlsaW5nIGxpc3QNCk1C T05FREBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYm9u ZWQNCg0K From nobody Thu Dec 19 05:39:00 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0E7120133; Thu, 19 Dec 2019 05:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 XwTcNDWb3PdR; Thu, 19 Dec 2019 05:38:50 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 AE55112023E; Thu, 19 Dec 2019 05:38:50 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xBJDP883030301; Thu, 19 Dec 2019 08:38:40 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049463.ppops.net-00191d01. with ESMTP id 2wys3dtatd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Dec 2019 08:38:40 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id xBJDcdhX109795; Thu, 19 Dec 2019 07:38:39 -0600 Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [135.46.181.149]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id xBJDcZBH109742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2019 07:38:35 -0600 Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [127.0.0.1]) by zlp30499.vci.att.com (Service) with ESMTP id 85C624000734; Thu, 19 Dec 2019 13:38:35 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30499.vci.att.com (Service) with ESMTP id 66F9D400072E; Thu, 19 Dec 2019 13:38:35 +0000 (GMT) Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id xBJDcZ7v003276; Thu, 19 Dec 2019 07:38:35 -0600 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id xBJDcNfb002559; Thu, 19 Dec 2019 07:38:24 -0600 Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.86]) by mail-azure.research.att.com (Postfix) with ESMTP id 358EEE5504; Thu, 19 Dec 2019 08:37:05 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas1.research.att.com ([fe80::e881:676b:51b6:905d%12]) with mapi id 14.03.0468.000; Thu, 19 Dec 2019 08:38:23 -0500 From: "MORTON, ALFRED C (AL)" To: Tianran Zhou , "secdir@ietf.org" , IETF IPPM WG CC: Caoli Thread-Topic: security considerations on the TWAMP Thread-Index: AdW2IE+K7R6ZTjm3QMWstOtse9zzeAAULTEg Date: Thu, 19 Dec 2019 13:38:22 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA6F0F0C2@njmtexg5.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.141.203.172] Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CFA6F0F0C2njmtexg5researc_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-19_01:2019-12-17,2019-12-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 phishscore=0 suspectscore=0 lowpriorityscore=0 adultscore=0 impostorscore=0 spamscore=0 mlxlogscore=719 clxscore=1011 mlxscore=0 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912190117 Archived-At: Subject: Re: [secdir] security considerations on the TWAMP X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2019 13:38:53 -0000 --_000_4D7F4AD313D3FC43A053B309F97543CFA6F0F0C2njmtexg5researc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Allow only known addresses, or block entire address blocks where most attacks are coming from. Use ACLs, IPtables, firewalls, etc. IOW, there are plenty of mechanisms beyond TWAMP to meet this need. Al From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Wednesday, December 18, 2019 11:15 PM To: secdir@ietf.org; IETF IPPM WG Cc: Caoli Subject: [ippm] security considerations on the TWAMP Hi IPPM and SecDir, When firstly set up the control session between the client and the server, = TWAMP(RFC5357) server will listen on a specific TCP port. By default, the w= ell-known port is 862. However, RFC 5357 does not provide mechanism to restrict the source IP addr= ess of the request. How do you think about the potential DDOS attack risk from the unknown IP s= ource addresses? Thanks, Tianran --_000_4D7F4AD313D3FC43A053B309F97543CFA6F0F0C2njmtexg5researc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Allow only known addresses, or block entire address blocks

where most attacks are coming from. Use ACLs, IPtables, firewal= ls,

etc.  IOW, there are plenty of mechanisms beyond TWAMP to<= o:p>

meet this need.

 

Al

 

From: ippm [mailto:ippm-bounces@ietf.org] = On Behalf Of Tianran Zhou
Sent: Wednesday, December 18, 2019 11:15 PM
To: secdir@ietf.org; IETF IPPM WG <ippm@ietf.org>
Cc: Caoli <caoli@huawei.com>
Subject: [ippm] security considerations on the TWAMP

 

Hi IPPM and SecDir,

 

When firstly set up the control session between the = client and the server, TWAMP(RFC5357) server will listen on a specific TCP = port. By default, the well-known port is 862.

However, RFC 5357 does not provide mechanism to rest= rict the source IP address of the request.

How do you think about the potential DDOS attack ris= k from the unknown IP source addresses?

 

Thanks,

Tianran

--_000_4D7F4AD313D3FC43A053B309F97543CFA6F0F0C2njmtexg5researc_-- From nobody Thu Dec 19 07:23:54 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1D5120883 for ; Thu, 19 Dec 2019 07:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97S18cgdXH5J for ; Thu, 19 Dec 2019 07:23:50 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7A61201DE for ; Thu, 19 Dec 2019 07:23:50 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBJFNfL9028144 for ; Thu, 19 Dec 2019 15:23:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=VSN6TnX0ZDz1SUxrxpH/FHnWeBAgsJKrjWCXhHHnid0=; b=GJGTazLoPY1lwR4Qp54quGsQcBMtrWmlbdzR4XRCnORpSr+Kn40d1R+jjgIflyuFwLNk O64Ud5AJ1v1BaoJEYqLUvJa9ZqC1laq9gmG0EdaHbFYl2jBp288Xveq2stUCrTcKuSPM +ESFzQKLr85q4tBD8PM6POs7pC5sM34B2RbYuo2PLZaIQR500vZ0MFkbuHFWczUh3hdM MRGsUXuzUJDyf/ILhDZgUm8/aK12G8avy0ni0MCcsnBPv/KBcer1xEP29o+w6HpEmcUN uzUMbXe7MFMtLw4Eqf1HyX4/DZrn10U6JEwGQqNlXJO+forchcgCEGPppUGqsZLRvZb7 bg== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2wyyv2tc40-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 19 Dec 2019 15:23:50 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xBJF2rm7005830 for ; Thu, 19 Dec 2019 10:23:49 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2wvuy2m11k-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 19 Dec 2019 10:23:47 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 10:23:09 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 10:23:09 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 19 Dec 2019 10:23:08 -0500 From: "Salz, Rich" To: "secdir@ietf.org" Thread-Topic: [Last-Call] [Gen-art] Genart last call review of draft-ietf-nfsv4-rfc5661sesqui-msns-03 Thread-Index: AQHVtfYMDfJN6pqsPUeUyP27Z1wWuqfByOUA///LnQA= Date: Thu, 19 Dec 2019 15:23:08 +0000 Message-ID: <2E92576E-34A1-4B49-A72A-9AE5DB0CCE63@akamai.com> References: <157662824941.4998.12199831329321073078@ietfa.amsl.com> <039F9191-49D4-42AE-AF9A-2E264F2B3EE3@cooperw.in> In-Reply-To: <039F9191-49D4-42AE-AF9A-2E264F2B3EE3@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.144] Content-Type: multipart/mixed; boundary="_004_2E92576E34A14B49A72A9AE5DB0CCE63akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-19_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912190127 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-19_04:2019-12-17,2019-12-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 impostorscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1011 adultscore=0 priorityscore=1501 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912190128 Archived-At: Subject: [secdir] FW: [Last-Call] [Gen-art] Genart last call review of draft-ietf-nfsv4-rfc5661sesqui-msns-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2019 15:23:53 -0000 --_004_2E92576E34A14B49A72A9AE5DB0CCE63akamaicom_ Content-Type: multipart/alternative; boundary="_000_2E92576E34A14B49A72A9AE5DB0CCE63akamaicom_" --_000_2E92576E34A14B49A72A9AE5DB0CCE63akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgbGlrZSB0aGUgU2VjIEFE4oCZcyB0byBjb25zaWRlciBkb2luZyBzb21ldGhpbmcgbGlr ZSB0aGlzOiBhIHRoYW5rcyBhbmQgYSBzdW1tYXJ5IG9mIHRoZSBBRCBhY3Rpb25zICh3aGljaCB3 aWxsIHByb2JhYmx5IG1vc3RseSBiZSDigJxJIGluY2x1ZGVkIHRoaXMgaW4gbXkgb3duIHBlcnNv bmFsIERJU0NVU1MgYmFsbG904oCdKS4NCg0KRnJvbTogQWxpc3NhIENvb3BlciA8YWxpc3NhQGNv b3BlcncuaW4+DQpEYXRlOiBUaHVyc2RheSwgRGVjZW1iZXIgMTksIDIwMTkgYXQgODozMiBBTQ0K VG86IFZpamF5IEd1cmJhbmkgPHZpamF5Lmd1cmJhbmlAZ21haWwuY29tPg0KQ2M6ICJsYXN0LWNh bGxAaWV0Zi5vcmciIDxsYXN0LWNhbGxAaWV0Zi5vcmc+LCAiZ2VuLWFydEBpZXRmLm9yZyIgPGdl bi1hcnRAaWV0Zi5vcmc+LCAibmZzdjRAaWV0Zi5vcmciIDxuZnN2NEBpZXRmLm9yZz4sICJkcmFm dC1pZXRmLW5mc3Y0LXJmYzU2NjFzZXNxdWktbXNucy5hbGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRm LW5mc3Y0LXJmYzU2NjFzZXNxdWktbXNucy5hbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0xh c3QtQ2FsbF0gW0dlbi1hcnRdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYt bmZzdjQtcmZjNTY2MXNlc3F1aS1tc25zLTAzDQoNClZpamF5LCB0aGFua3MgZm9yIHlvdXIgcmV2 aWV3IG9mIHRoaXMgZG9jdW1lbnQuIEkgZW50ZXJlZCBhIE5vIE9iamVjdGlvbiBiYWxsb3QuDQoN CkFsaXNzYQ0KDQoNCg0KT24gRGVjIDE4LCAyMDE5LCBhdCA1OjU0IFBNLCBWaWpheSBHdXJiYW5p IDx2aWpheS5ndXJiYW5pQGdtYWlsLmNvbTxtYWlsdG86dmlqYXkuZ3VyYmFuaUBnbWFpbC5jb20+ PiB3cm90ZToNCg0KQWxsOiBUaGlzIGVtYWlsIHNlcnZlcyBhcyB0aGUgc2Vjb25kIGhhbGYgb2Yg dGhlIHJldmlldyBvZiBkcmFmdC1pZXRmLW5zZnY0LXJmYzU2NjFzZXNxdWktbXNucy0wMy4NCg0K SSByZXZpZXdlZCBwYWdlcyAyOTcgdG8gdGhlIGVuZCBvZiB0aGUgZG9jdW1lbnQsIG1vc3RseSBm b3IgZWRpdG9yaWFsIGFuZCBzaW1pbGFyIGNvbW1lbnRzIGZyb20gYSBnZW5lcmFsaXN0IHBvaW50 IG9mIHZpZXcuDQoNClRoZSBkaXNwb3NpdGlvbiByZW1haW5zIHRoZSBzYW1lIGFzIGJlZm9yZSAo IlJlYWR5IHdpdGggTml0cyIpLiAgSW4gYWRkaXRpb24gdG8gdGhlIG5pdHMgSSBvdXRsaW5lZCBp biBteSBwcmV2aW91cyBlbWFpbCAocmVwcm9kdWNlZCBiZWxvdyksIGhlcmUgaXMgb25lIGFkZGl0 aW9uYWwgb25lOg0KDQoxLyBTMTguNTEuMTogV2hhdCBpcyB0aGUgdmFsdWUgb2YgYnJhY2tldGlu ZyB0aGUgY29kZSB3aXRoIDxDT0RFIEJFR0lOUz4gLi4uIDxDT0RFIEVORFM+IGluIHRoaXMsIGFu ZCB0aGUgbmV4dCBzZWN0aW9uPyAgQ2xlYXJseSwgeW91IGhhdmUgY29kZSBpbiB0aGUgcHJldmlv dXMgc2VjdGlvbiwgYW5kIGxhdGVyIHNlY3Rpb25zLCB3aXRob3V0IHN1Y2ggYnJhY2tldGluZy4g IFVuaWZvcm1pdHkgZGljdGF0ZXMgdGhhdCB0aGUgY29kZSBpbiB0aGVzZSB0d28gc2VjdGlvbnMg YmUgZ2l2ZW4gdGhlIHNhbWUgdHJlYXRtZW50IGFzIHRoZSBjb2RlIGluIHByZXZpb3VzIHNlY3Rp b25zLiAgSWYsIG9uIHRoZSBvdGhlciBoYW5kLCB0aGVyZSBpcyBzb21lIHNpZ25pZmljYW5jZSB0 byBzdWNoIGJyYWNrZXRpbmcsIGl0IG1heSBiZSBnb29kIHRvIGNvbW1lbnQgb24gc3VjaCBhIHNp Z25pZmljYW5jZSBpbiBTIDE4LjUxLjEuDQoNClRoYW5rcywNCg0KLSB2aWpheQ0KDQpPbiBUdWUs IERlYyAxNywgMjAxOSBhdCA2OjE3IFBNIFZpamF5IEd1cmJhbmkgdmlhIERhdGF0cmFja2VyIDxu b3JlcGx5QGlldGYub3JnPG1haWx0bzpub3JlcGx5QGlldGYub3JnPj4gd3JvdGU6DQpSZXZpZXdl cjogVmlqYXkgR3VyYmFuaQ0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRzDQoNCkkgYW0g dGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFs IEFyZWENClJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBi ZWluZyBwcm9jZXNzZWQNCmJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0 cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0DQpsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVu dHMuDQoNCkZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQNCg0KPGh0 dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZhcTxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3RyYWMuaWV0Zi5vcmdfdHJh Y19nZW5fd2lraV9HZW5BcnRmYXEmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9 NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZtPTN0LUExYjNSbTVZb1ZHY19YRTBQWTVNNHItU1BOYy1C NXBKQTB0UHVqU1Emcz1PY0hEeVI1eFlGckxmbE5Rbl91T05adnBwclZnd3hJY2FfS1hWU25ZNUNN JmU9Pj4uDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLW5mc3Y0LXJmYzU2NjFzZXNxdWktbXNucy0/ Pw0KUmV2aWV3ZXI6IFZpamF5IEsuIEd1cmJhbmkNClJldmlldyBEYXRlOiAyMDE5LTEyLTE3DQpJ RVRGIExDIEVuZCBEYXRlOiAyMDE5LTExLTI1DQpJRVNHIFRlbGVjaGF0IGRhdGU6IDIwMTktMTIt MTkNCg0KSSBoYXZlIHJldmlld2VkIGFib3V0IDEvMiBvZiB0aGUgSS1ELCB1cCB0byBTZWN0aW9u IDEyIChwYWdlIDI5NykuICBJIHdpbGwNCnJldmlldyB0aGUgcmVtYWluaW5nIDEvMiBiZWZvcmUg dGhlIHRlbGNoYXQsIGJ1dCBJIHN1c3BlY3QgdGhhdCBnaXZlbiBteSB2ZXJ5DQpoaWdoIGxldmVs IG92ZXJ2aWV3IG9mIHRoZSBkcmFmdCwgbXkgZGlzcG9zaXRpb24gd2lsbCBub3QgY2hhbmdlLg0K DQpTdW1tYXJ5OiAgVGhpcyBkcmFmdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24gYXMgYSBQcm9w b3NlZCBTdGFuZGFyZC4gIEluIHRoZQ0KcG9ydGlvbiBvZiB0aGUgZHJhZnQgSSByZXZpZXdlZCwg dGhlcmUgYXJlIHNvbWUgbWlub3Igbml0cyB0aGF0IGNhbiBlYXNpbHkgYmUNCmZpeGVkLg0KDQpN YWpvciBpc3N1ZXM6IDANCg0KTWlub3IgaXNzdWVzOiAwDQoNCk5pdHMvZWRpdG9yaWFsIGNvbW1l bnRzOiA0ICgiU24iIG1lYW5zIFNlY3Rpb24gbik6DQoxLyBBcHBlbmRpeCBBOiBzL05vIGNvcnJl ZXNwb25kaW5nIGV4cGxhbmF0aW9uL05vIGNvcnJlc3BvbmRpbmcgZXhwbGFuYXRpb24vDQoyLyBT MTogcy9hdXRob3JpdGF0aXZlIGNvbXBsZXRlL2F1dGhvcml0YXRpdmVseSBjb21wbGV0ZS8NCjMv IFMxLjcgKHBhZ2UgMTIpOiAiYXNzb2NpYWJsZSIgb3IgImFzc29jaWF0ZWQgdG8iDQo0LyBUaGVy ZSBhcmUgbWFueSBsb25nIGxpbmVzIHRoYXQgZ28gYmV5b25kIDgwIGNoYXJhY3RlcnMsIHNlZSBT MS45LCB0aGUgYnVsbGV0DQp0aGF0IHN0YXJ0cyB3aXRoIOKAnG8gIE9wZW4gZmlsZXMgY2FuIGJl IOKApuKAnSwgICBUYWJsZSAxLCBTNC4yLjEsIGV0Yy4NCg0KVGhhbmtzLA0KDQotIHZpamF5DQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkdlbi1h cnQgbWFpbGluZyBsaXN0DQpHZW4tYXJ0QGlldGYub3JnPG1haWx0bzpHZW4tYXJ0QGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW4tYXJ0PGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9fZ2VuLTJEYXJ0JmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBO NkxaZyZyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmbT0zdC1BMWIzUm01WW9WR2NfWEUwUFk1TTRy LVNQTmMtQjVwSkEwdFB1alNRJnM9LUNaLUZMcEpDeVhTZ3B4ZkVrS1hKMl9nX1RrUmI2MDdXVFgy UnJyZVJJQSZlPT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpHZW4tYXJ0IG1haWxpbmcgbGlzdA0KR2VuLWFydEBpZXRmLm9yZzxtYWlsdG86R2VuLWFy dEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VuLWFy dA0KDQo= --_000_2E92576E34A14B49A72A9AE5DB0CCE63akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <26EAC8A30F7FC64F86B781EA064C9EE1@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SeKAmWQgbGlrZSB0aGUgU2VjIEFE4oCZcyB0byBjb25zaWRlciBkb2lu ZyBzb21ldGhpbmcgbGlrZSB0aGlzOiBhIHRoYW5rcyBhbmQgYSBzdW1tYXJ5IG9mIHRoZSBBRCBh Y3Rpb25zICh3aGljaCB3aWxsIHByb2JhYmx5IG1vc3RseSBiZSDigJxJIGluY2x1ZGVkIHRoaXMg aW4gbXkgb3duIHBlcnNvbmFsIERJU0NVU1MgYmFsbG904oCdKS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkFsaXNzYSBDb29wZXIgJmx0O2FsaXNzYUBjb29wZXJ3 LmluJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgRGVjZW1iZXIgMTksIDIwMTkgYXQg ODozMiBBTTxicj4NCjxiPlRvOiA8L2I+VmlqYXkgR3VyYmFuaSAmbHQ7dmlqYXkuZ3VyYmFuaUBn bWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtsYXN0LWNhbGxAaWV0Zi5vcmcmcXVv dDsgJmx0O2xhc3QtY2FsbEBpZXRmLm9yZyZndDssICZxdW90O2dlbi1hcnRAaWV0Zi5vcmcmcXVv dDsgJmx0O2dlbi1hcnRAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtuZnN2NEBpZXRmLm9yZyZxdW90OyAm bHQ7bmZzdjRAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtkcmFmdC1pZXRmLW5mc3Y0LXJmYzU2NjFzZXNx dWktbXNucy5hbGxAaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtbmZzdjQtcmZjNTY2MXNl c3F1aS1tc25zLmFsbEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtMYXN0 LUNhbGxdIFtHZW4tYXJ0XSBHZW5hcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW5m c3Y0LXJmYzU2NjFzZXNxdWktbXNucy0wMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5WaWpheSwgdGhhbmtzIGZvciB5b3VyIHJldmlldyBvZiB0 aGlzIGRvY3VtZW50LiBJIGVudGVyZWQgYSBObyBPYmplY3Rpb24gYmFsbG90Lg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGlzc2E8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRGVjIDE4LCAyMDE5LCBhdCA1 OjU0IFBNLCBWaWpheSBHdXJiYW5pICZsdDs8YSBocmVmPSJtYWlsdG86dmlqYXkuZ3VyYmFuaUBn bWFpbC5jb20iPnZpamF5Lmd1cmJhbmlAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsOiBUaGlzIGVt YWlsIHNlcnZlcyBhcyB0aGUgc2Vjb25kIGhhbGYgb2YgdGhlIHJldmlldyBvZiBkcmFmdC1pZXRm LW5zZnY0LXJmYzU2NjFzZXNxdWktbXNucy0wMy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSByZXZpZXdlZCBwYWdlcyAyOTcgdG8gdGhlIGVu ZCBvZiB0aGUgZG9jdW1lbnQsIG1vc3RseSBmb3IgZWRpdG9yaWFsIGFuZCBzaW1pbGFyIGNvbW1l bnRzIGZyb20gYSBnZW5lcmFsaXN0IHBvaW50IG9mIHZpZXcuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkaXNwb3NpdGlvbiByZW1haW5z IHRoZSBzYW1lIGFzIGJlZm9yZSAoJnF1b3Q7UmVhZHkgd2l0aCBOaXRzJnF1b3Q7KS4mbmJzcDsg SW4gYWRkaXRpb24gdG8gdGhlIG5pdHMgSSBvdXRsaW5lZCBpbiBteSBwcmV2aW91cyBlbWFpbCAo cmVwcm9kdWNlZCBiZWxvdyksIGhlcmUgaXMgb25lIGFkZGl0aW9uYWwgb25lOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLyBTMTguNTEuMTog V2hhdCBpcyB0aGUgdmFsdWUgb2YgYnJhY2tldGluZyB0aGUgY29kZSB3aXRoICZsdDtDT0RFIEJF R0lOUyZndDsgLi4uICZsdDtDT0RFIEVORFMmZ3Q7IGluIHRoaXMsIGFuZCB0aGUgbmV4dCBzZWN0 aW9uPyZuYnNwOyBDbGVhcmx5LCB5b3UgaGF2ZSBjb2RlIGluIHRoZSBwcmV2aW91cyBzZWN0aW9u LCBhbmQgbGF0ZXIgc2VjdGlvbnMsIHdpdGhvdXQgc3VjaCBicmFja2V0aW5nLiZuYnNwOyBVbmlm b3JtaXR5IGRpY3RhdGVzIHRoYXQNCiB0aGUgY29kZSBpbiB0aGVzZSB0d28gc2VjdGlvbnMgYmUg Z2l2ZW4gdGhlIHNhbWUgdHJlYXRtZW50IGFzIHRoZSBjb2RlIGluIHByZXZpb3VzIHNlY3Rpb25z LiZuYnNwOyBJZiwgb24gdGhlIG90aGVyIGhhbmQsIHRoZXJlIGlzIHNvbWUgc2lnbmlmaWNhbmNl IHRvIHN1Y2ggYnJhY2tldGluZywgaXQgbWF5IGJlIGdvb2QgdG8gY29tbWVudCBvbiBzdWNoIGEg c2lnbmlmaWNhbmNlIGluIFMgMTguNTEuMS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHZpamF5PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIERlYyAxNywgMjAxOSBhdCA2OjE3IFBN IFZpamF5IEd1cmJhbmkgdmlhIERhdGF0cmFja2VyICZsdDs8YSBocmVmPSJtYWlsdG86bm9yZXBs eUBpZXRmLm9yZyI+bm9yZXBseUBpZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV2aWV3ZXI6IFZp amF5IEd1cmJhbmk8YnI+DQpSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5pdHM8YnI+DQo8YnI+ DQpJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUg R2VuZXJhbCBBcmVhPGJyPg0KUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYg ZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZDxicj4NCmJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBD aGFpci4mbmJzcDsgUGxlYXNlIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Q8YnI+DQpsaWtlIGFu eSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPGJyPg0KPGJyPg0KRm9yIG1vcmUgaW5mb3JtYXRp b24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdDxicj4NCjxicj4NCiZsdDs8YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3RyYWMuaWV0Zi5v cmdfdHJhY19nZW5fd2lraV9HZW5BcnRmYXEmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0 dzBGNGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT0zdC1BMWIzUm01 WW9WR2NfWEUwUFk1TTRyLVNQTmMtQjVwSkEwdFB1alNRJmFtcDtzPU9jSER5UjV4WUZyTGZsTlFu X3VPTlp2cHByVmd3eEljYV9LWFZTblk1Q00mYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly90cmFjLmlldGYub3JnL3RyYWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxPC9hPiZndDsuPGJyPg0KPGJy Pg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbmZzdjQtcmZjNTY2MXNlc3F1aS1tc25zLT8/PGJyPg0K UmV2aWV3ZXI6IFZpamF5IEsuIEd1cmJhbmk8YnI+DQpSZXZpZXcgRGF0ZTogMjAxOS0xMi0xNzxi cj4NCklFVEYgTEMgRW5kIERhdGU6IDIwMTktMTEtMjU8YnI+DQpJRVNHIFRlbGVjaGF0IGRhdGU6 IDIwMTktMTItMTk8YnI+DQo8YnI+DQpJIGhhdmUgcmV2aWV3ZWQgYWJvdXQgMS8yIG9mIHRoZSBJ LUQsIHVwIHRvIFNlY3Rpb24gMTIgKHBhZ2UgMjk3KS4mbmJzcDsgSSB3aWxsPGJyPg0KcmV2aWV3 IHRoZSByZW1haW5pbmcgMS8yIGJlZm9yZSB0aGUgdGVsY2hhdCwgYnV0IEkgc3VzcGVjdCB0aGF0 IGdpdmVuIG15IHZlcnk8YnI+DQpoaWdoIGxldmVsIG92ZXJ2aWV3IG9mIHRoZSBkcmFmdCwgbXkg ZGlzcG9zaXRpb24gd2lsbCBub3QgY2hhbmdlLjxicj4NCjxicj4NClN1bW1hcnk6Jm5ic3A7IFRo aXMgZHJhZnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQu Jm5ic3A7IEluIHRoZTxicj4NCnBvcnRpb24gb2YgdGhlIGRyYWZ0IEkgcmV2aWV3ZWQsIHRoZXJl IGFyZSBzb21lIG1pbm9yIG5pdHMgdGhhdCBjYW4gZWFzaWx5IGJlPGJyPg0KZml4ZWQuPGJyPg0K PGJyPg0KTWFqb3IgaXNzdWVzOiAwPGJyPg0KPGJyPg0KTWlub3IgaXNzdWVzOiAwPGJyPg0KPGJy Pg0KTml0cy9lZGl0b3JpYWwgY29tbWVudHM6IDQgKCZxdW90O1NuJnF1b3Q7IG1lYW5zIFNlY3Rp b24gbik6PGJyPg0KMS8gQXBwZW5kaXggQTogcy9ObyBjb3JyZWVzcG9uZGluZyBleHBsYW5hdGlv bi9ObyBjb3JyZXNwb25kaW5nIGV4cGxhbmF0aW9uLzxicj4NCjIvIFMxOiBzL2F1dGhvcml0YXRp dmUgY29tcGxldGUvYXV0aG9yaXRhdGl2ZWx5IGNvbXBsZXRlLzxicj4NCjMvIFMxLjcgKHBhZ2Ug MTIpOiAmcXVvdDthc3NvY2lhYmxlJnF1b3Q7IG9yICZxdW90O2Fzc29jaWF0ZWQgdG8mcXVvdDs8 YnI+DQo0LyBUaGVyZSBhcmUgbWFueSBsb25nIGxpbmVzIHRoYXQgZ28gYmV5b25kIDgwIGNoYXJh Y3RlcnMsIHNlZSBTMS45LCB0aGUgYnVsbGV0PGJyPg0KdGhhdCBzdGFydHMgd2l0aCDigJxvJm5i c3A7IE9wZW4gZmlsZXMgY2FuIGJlIOKApuKAnSwmbmJzcDsgJm5ic3A7VGFibGUgMSwgUzQuMi4x LCBldGMuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCjxicj4NCi0gdmlqYXk8YnI+DQo8YnI+DQo8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ckdlbi1hcnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkdlbi1hcnRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5HZW4tYXJ0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9fZ2VuLTJEYXJ0JmFtcDtkPUR3TUZhUSZhbXA7Yz05Nlpi WlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmYW1wO209M3Qt QTFiM1JtNVlvVkdjX1hFMFBZNU00ci1TUE5jLUI1cEpBMHRQdWpTUSZhbXA7cz0tQ1otRkxwSkN5 WFNncHhmRWtLWEoyX2dfVGtSYjYwN1dUWDJScnJlUklBJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VuLWFydDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ckdlbi1hcnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkdlbi1hcnRAaWV0Zi5v cmciPkdlbi1hcnRAaWV0Zi5vcmc8L2E+PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9nZW4tYXJ0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2E92576E34A14B49A72A9AE5DB0CCE63akamaicom_-- --_004_2E92576E34A14B49A72A9AE5DB0CCE63akamaicom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=98; creation-date="Thu, 19 Dec 2019 15:23:08 GMT"; modification-date="Thu, 19 Dec 2019 15:23:08 GMT" Content-ID: <41826E2E70887F4A9A1E93B384D12617@akamai.com> Content-Transfer-Encoding: base64 LS0gDQpsYXN0LWNhbGwgbWFpbGluZyBsaXN0DQpsYXN0LWNhbGxAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGFzdC1jYWxsDQo= --_004_2E92576E34A14B49A72A9AE5DB0CCE63akamaicom_-- From nobody Thu Dec 19 07:51:41 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFDF12018D; Thu, 19 Dec 2019 07:51:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Catherine Meadows via Datatracker To: Cc: last-call@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-no-response-issue.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Catherine Meadows Message-ID: <157677069055.27346.2427467441228883400@ietfa.amsl.com> Date: Thu, 19 Dec 2019 07:51:30 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dnsop-no-response-issue-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2019 15:51:31 -0000 Reviewer: Catherine Meadows Review result: Has Nits This draft concerns maintaining the correctness of DNS servers. It lists the common mistakes that noncompliant servers make in responding to queries and gives the correct ones. It also gives a set of tests operators can give to their servers ensure compliance, as well as directions for applying the tests. One of the main security issues discussed is the fact that many servers are configured not to respond to queries outside of their scope because these are construed as an attack, when in fact these are legal queries that should be responded too (generally with a message saying that these are not supported) and that failure to respond can give be misinterpreted as packet loss, given an incorrect picture of the state of the network. The document also discusses the security implications of such misleading responses. The document also warns about security risks of testing, and of removing non-compliant servers, and alternative means of handling these situations. All of the above information is summed up in the security considerations section , and most of it is discussed at more detail in the document itself. I think that the authors have done an excellent job of identifying and explaining security issues, and I consider the document Ready except for one nit. In the places where the security considerations section sums up issues that are discussed in more depth in the document itself (e. g. the first , on the fact that none of the tests should cause any harm to a protocol-compliant server), it would be useful to have a pointer to the section of sections where this information appears. From nobody Fri Dec 20 08:22:53 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EE412006E; Thu, 19 Dec 2019 23:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1576828228; bh=rhG4V1pTV03NVrSoHUSaHt/UPdDNRZNttS10Sc4QzKY=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=f+AXEj7DCzYFfK5bH7sCCKz/M+4y9VdBPW3BKnwK8HwFTsljkzc7LAAP+y6C4qlhK Jb5hoGc2z8BD/9Uc7OOXLos24lf4sgG9M5Vy9v6KUu68etY+o0D/6hA1y1CZZKsQ59 tq//mvXzTZTGXT6//9ltnmgcPm9SZyXRQ1jEaJ7I= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Dec 19 23:50:28 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12515120091; Thu, 19 Dec 2019 23:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1576828228; bh=rhG4V1pTV03NVrSoHUSaHt/UPdDNRZNttS10Sc4QzKY=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=f+AXEj7DCzYFfK5bH7sCCKz/M+4y9VdBPW3BKnwK8HwFTsljkzc7LAAP+y6C4qlhK Jb5hoGc2z8BD/9Uc7OOXLos24lf4sgG9M5Vy9v6KUu68etY+o0D/6hA1y1CZZKsQ59 tq//mvXzTZTGXT6//9ltnmgcPm9SZyXRQ1jEaJ7I= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F77120091 for ; Thu, 19 Dec 2019 23:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGA4k1WQnIHB for ; Thu, 19 Dec 2019 23:50:24 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 987DF12006E for ; Thu, 19 Dec 2019 23:50:24 -0800 (PST) Received: from moon.w3.org ([128.30.55.110] helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1iiD3F-0002kx-VY for new-work@ietf.org; Fri, 20 Dec 2019 07:50:22 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Fri, 20 Dec 2019 15:50:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 20 Dec 2019 08:22:51 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Audio Working Group (until 2020-01-27) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2019 07:50:30 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgQXVkaW8g V29ya2luZyBHcm91cDoKIMKgIGh0dHBzOi8vd3d3LnczLm9yZy8yMDExL2F1ZGlvL2NoYXJ0ZXIv YXVkaW8tMjAxOS1hYy5odG1sCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRoYXQgdGhlIGNvbW11bml0 eSBpcyBhd2FyZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBkcmFmdCBjaGFydGVyIGlz IHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZpZXcgcGVyaW9kLgoKVzND IGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2ggMjAyMC0wMS0yNyBvbiB0aGUKcHJvcG9z ZWQgY2hhcnRlci4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8KcHVibGljLW5ldy13b3JrQHczLm9y Zywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDCoCBodHRwOi8vbGlzdHMudzMub3JnL0Fy Y2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNvbW1lbnRzIHNlbnQg aW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkKQ29tbWl0dGVlIFJlcHJlc2VudGF0 aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0bwpjb21tZW50cy4gSWYgeW91 IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29yZGluYXRlCnlvdXIgY29tbWVu dHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZS4gRm9yCmV4YW1w bGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50cyB2aWEgdGhpcyBsaXN0IGFu ZApoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlIHJlZmVyIHRvIGl0 IGZyb20gaGlzCm9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKVGhlIGdyb3VwJ3MgY3Vy cmVudCBjaGFydGVyIGlzIGhlcmVieSBleHRlbmRlZCB1bnRpbCAxNCBGZWJydWFyeSAyMDIwLAp0 byBhY2NvbW1vZGF0ZSB0aGUgY2hhcnRlciByZXZpZXcgcGVyaW9kOgpodHRwczovL2xpc3RzLncz Lm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLWF1ZGlvLzIwMTlPY3REZWMvMDAyOC5odG1sCgpJ ZiB5b3Ugc2hvdWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRp b24sIHBsZWFzZQpjb250YWN0IENocmlzIExpbGxleSA8Y2hyaXNAdzMub3JnPiwgVzNDIEF1ZGlv IFdvcmtpbmcgR3JvdXAgVGVhbSBDb250YWN0LgoKVGhhbmsgeW91LAoKWHVleXVhbiBKaWEsIFcz QyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNv cnRpdW0vTWVtYmVyL0xpc3QKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Fri Dec 20 22:00:04 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5CD120A17; Fri, 20 Dec 2019 14:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1576881955; bh=MBzrHzPRtW3PcTchHP3XPG8R8l5dsR+WuvAmvYlMB0Y=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=zOXmcnmPWXYFxK0NT8CcUW1ViLgTh7DLYOc4DFpuKjFk81Qs9S5XH4sjjM+yq30yN 0TE9pbiT6xvq9HRudyG7G5fkXp0mEZnRW14rXpFBPhoi47CJDFuYkYNIZ/ph3Q1Ks1 nTf2hxj4QtOzICtMjGwftcW3F7A6jCIEKZ5g02Bg= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Dec 20 14:45:50 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FE2120927; Fri, 20 Dec 2019 14:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1576881949; bh=MBzrHzPRtW3PcTchHP3XPG8R8l5dsR+WuvAmvYlMB0Y=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=c0xAxgQgr/pNwCHY2CM7Uf/i45+Ppi9kDX/zZod3LmL9cSFfinx24qayf2PZ7CP7i +3WFcFls8k/DIZFNZpxelFBELNle62h03d0P7qxFu3PZLATpebK8ArQrBGu6LSDjIw 59NOg2ehkXXWu5lzRL0u6R/l3Rd8aU/DoDpO+F+c= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C084F12081C for ; Fri, 20 Dec 2019 14:45:42 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.114.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <157688194278.4174.5111988369369282250.idtracker@ietfa.amsl.com> Date: Fri, 20 Dec 2019 14:45:42 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 20 Dec 2019 22:00:03 -0800 Subject: [secdir] [new-work] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2019 22:46:01 -0000 The IP Security Maintenance and Extensions (ipsecme) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-01-06. IP Security Maintenance and Extensions (ipsecme) ----------------------------------------------------------------------- Current status: Active WG Chairs: Yoav Nir Tero Kivinen Assigned Area Director: Benjamin Kaduk Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: ipsec@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Group page: https://datatracker.ietf.org/group/ipsecme/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify the shared-secret mode of IKEv2 to have similar or better quantum resistant properties to those of IKEv1. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in the form of a counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2. Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys than conventional Diffie-Hellman public keys. Directly using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate to each other which signature format(s) they support. That leads to interoperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. A possible starting pointing is draft-boucadair-ipsecme-ipv6-ipv4-codes. Some systems support security labels (aka security context) as one of the selectors of the SPD. This label needs to be part of the IKE negotiation for the IPsec SA. Non-standard implementations exist for IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now using private space IPSEC Security Association Attribute 32001). The work is to standarize this for IKEv2, in a way that will be backwards compatible with old implementations, meaning it must not require any changes to implementations not supporting this. RFC8229, published in 2017, specifies how to encapsulate IKEv2 and ESP traffic in TCP. Implementation experience has revealed that not all situations are covered in RFC8229, and that may lead to interoperability problems or to suboptimal performance. The WG will provide a document to give implementors more guidance about how to use reliable stream transport in IKEv2 and clarify some issues that have been discovered. A possible starting point is draft-smyslov-ipsecme-tcp-guidelines. The demand for Traffic Flow Confidentiality has been increasing in the user community, but the current method defined in RFC4303 (adding null padding to each ESP payload) is very inefficient in its use of network resources. The working group will develop an alternative TFC solution that uses network resources more efficiently. Milestones: Dec 2019 - The internal address failure indication in IKEv2 to IESG May 2020 - G-DOI for IKEv2 to IESG May 2020 - Postquantum cryptography document for IKEv2 to IESG Aug 2020 - The security labels support for IKEv2 to IESG Aug 2020 - TCP-encapsulation guidelines document to IESG Nov 2020 - Traffic Flow Confidentiality document to IESG Jun 2021 - The ESP on contrained network to IESG Jun 2021 - Signature algorithm negotiation for IKEv2 to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sun Dec 22 17:29:07 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41052120047 for ; Sun, 22 Dec 2019 17:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 d_yB-4-PwYNT for ; Sun, 22 Dec 2019 17:29:03 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 BAEF9120013 for ; Sun, 22 Dec 2019 17:29:03 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBN1SvO9017797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 22 Dec 2019 20:28:59 -0500 Date: Sun, 22 Dec 2019 17:28:56 -0800 From: Benjamin Kaduk To: "Salz, Rich" Cc: "secdir@ietf.org" Message-ID: <20191223012856.GV35479@kduck.mit.edu> References: <157662824941.4998.12199831329321073078@ietfa.amsl.com> <039F9191-49D4-42AE-AF9A-2E264F2B3EE3@cooperw.in> <2E92576E-34A1-4B49-A72A-9AE5DB0CCE63@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2E92576E-34A1-4B49-A72A-9AE5DB0CCE63@akamai.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] FW: [Last-Call] [Gen-art] Genart last call review of draft-ietf-nfsv4-rfc5661sesqui-msns-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 01:29:06 -0000 I do it sometimes, though I'm inconsistent about whether I cc the list even within the limited subset where I send anything. Thanks for the suggestion! -Ben On Thu, Dec 19, 2019 at 03:23:08PM +0000, Salz, Rich wrote: > I’d like the Sec AD’s to consider doing something like this: a thanks and a summary of the AD actions (which will probably mostly be “I included this in my own personal DISCUSS ballot”). > > From: Alissa Cooper > Date: Thursday, December 19, 2019 at 8:32 AM > To: Vijay Gurbani > Cc: "last-call@ietf.org" , "gen-art@ietf.org" , "nfsv4@ietf.org" , "draft-ietf-nfsv4-rfc5661sesqui-msns.all@ietf.org" > Subject: Re: [Last-Call] [Gen-art] Genart last call review of draft-ietf-nfsv4-rfc5661sesqui-msns-03 > > Vijay, thanks for your review of this document. I entered a No Objection ballot. > > Alissa > > > > On Dec 18, 2019, at 5:54 PM, Vijay Gurbani > wrote: > > All: This email serves as the second half of the review of draft-ietf-nsfv4-rfc5661sesqui-msns-03. > > I reviewed pages 297 to the end of the document, mostly for editorial and similar comments from a generalist point of view. > > The disposition remains the same as before ("Ready with Nits"). In addition to the nits I outlined in my previous email (reproduced below), here is one additional one: > > 1/ S18.51.1: What is the value of bracketing the code with ... in this, and the next section? Clearly, you have code in the previous section, and later sections, without such bracketing. Uniformity dictates that the code in these two sections be given the same treatment as the code in previous sections. If, on the other hand, there is some significance to such bracketing, it may be good to comment on such a significance in S 18.51.1. > > Thanks, > > - vijay > > On Tue, Dec 17, 2019 at 6:17 PM Vijay Gurbani via Datatracker > wrote: > Reviewer: Vijay Gurbani > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > >. > > Document: draft-ietf-nfsv4-rfc5661sesqui-msns-?? > Reviewer: Vijay K. Gurbani > Review Date: 2019-12-17 > IETF LC End Date: 2019-11-25 > IESG Telechat date: 2019-12-19 > > I have reviewed about 1/2 of the I-D, up to Section 12 (page 297). I will > review the remaining 1/2 before the telchat, but I suspect that given my very > high level overview of the draft, my disposition will not change. > > Summary: This draft is ready for publication as a Proposed Standard. In the > portion of the draft I reviewed, there are some minor nits that can easily be > fixed. > > Major issues: 0 > > Minor issues: 0 > > Nits/editorial comments: 4 ("Sn" means Section n): > 1/ Appendix A: s/No correesponding explanation/No corresponding explanation/ > 2/ S1: s/authoritative complete/authoritatively complete/ > 3/ S1.7 (page 12): "associable" or "associated to" > 4/ There are many long lines that go beyond 80 characters, see S1.9, the bullet > that starts with “o Open files can be …”, Table 1, S4.2.1, etc. > > Thanks, > > - vijay > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Sun Dec 22 22:12:55 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078EC120072; Sun, 22 Dec 2019 22:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6_08MsNpCod; Sun, 22 Dec 2019 22:12:48 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 EDA1D120025; Sun, 22 Dec 2019 22:12:47 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DC5CA2F584BF82B4E3B2; Mon, 23 Dec 2019 06:12:43 +0000 (GMT) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 23 Dec 2019 06:12:43 +0000 Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 23 Dec 2019 06:12:43 +0000 Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Mon, 23 Dec 2019 06:12:43 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Mon, 23 Dec 2019 14:12:32 +0800 From: Tianran Zhou To: "MORTON, ALFRED C (AL)" , "secdir@ietf.org" , IETF IPPM WG CC: Caoli Thread-Topic: security considerations on the TWAMP Thread-Index: AdW2IE+K7R6ZTjm3QMWstOtse9zzeAAULTEgALmpQHA= Date: Mon, 23 Dec 2019 06:12:31 +0000 Message-ID: References: <4D7F4AD313D3FC43A053B309F97543CFA6F0F0C2@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CFA6F0F0C2@njmtexg5.research.att.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.162] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BF1634A1NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] security considerations on the TWAMP X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 06:12:50 -0000 --_000_BBA82579FD347748BEADC4C445EA0F21BF1634A1NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Al! Good to know your opinion on this. Merry Christmas! Tianran From: MORTON, ALFRED C (AL) [mailto:acm@research.att.com] Sent: Thursday, December 19, 2019 9:38 PM To: Tianran Zhou ; secdir@ietf.org; IETF IPPM WG Cc: Caoli Subject: RE: security considerations on the TWAMP Allow only known addresses, or block entire address blocks where most attacks are coming from. Use ACLs, IPtables, firewalls, etc. IOW, there are plenty of mechanisms beyond TWAMP to meet this need. Al From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Wednesday, December 18, 2019 11:15 PM To: secdir@ietf.org; IETF IPPM WG > Cc: Caoli > Subject: [ippm] security considerations on the TWAMP Hi IPPM and SecDir, When firstly set up the control session between the client and the server, = TWAMP(RFC5357) server will listen on a specific TCP port. By default, the w= ell-known port is 862. However, RFC 5357 does not provide mechanism to restrict the source IP addr= ess of the request. How do you think about the potential DDOS attack risk from the unknown IP s= ource addresses? Thanks, Tianran --_000_BBA82579FD347748BEADC4C445EA0F21BF1634A1NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Al!<= /span>

Good to know your opin= ion on this.

 

Merry Christmas!<= /o:p>

Tianran

 

From: MORTON, ALFRED C (AL) [mailto:acm@resea= rch.att.com]
Sent: Thursday, December 19, 2019 9:38 PM
To: Tianran Zhou <zhoutianran@huawei.com>; secdir@ietf.org; IE= TF IPPM WG <ippm@ietf.org>
Cc: Caoli <caoli@huawei.com>
Subject: RE: security considerations on the TWAMP

 

Allow only known addresses, or block entire address blocks

where most attacks are coming from. Use ACLs, IPtables, firewal= ls,

etc.  IOW, there are plenty of mechanisms beyond TWAMP to<= o:p>

meet this need.

 

Al

 

--_000_BBA82579FD347748BEADC4C445EA0F21BF1634A1NKGEML515MBXchi_-- From nobody Mon Dec 23 14:05:30 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D8312022A; Mon, 23 Dec 2019 14:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 OEtr67NwFg2U; Mon, 23 Dec 2019 14:05:18 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 79BD41201DB; Mon, 23 Dec 2019 14:05:18 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBNM59oC001666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Dec 2019 17:05:12 -0500 Date: Mon, 23 Dec 2019 14:05:09 -0800 From: Benjamin Kaduk To: Sara Dickinson Cc: last-call@ietf.org, dns-privacy@ietf.org, draft-ietf-dprive-rfc7626-bis.all@ietf.org, secdir@ietf.org, Stephen Farrell Message-ID: <20191223220509.GK35479@kduck.mit.edu> References: <157504194893.4871.5551746255324168227@ietfa.amsl.com> <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] [dns-privacy] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 22:05:20 -0000 On Wed, Dec 18, 2019 at 02:00:45PM +0000, Stephen Farrell wrote: > > Hiya, > > On 18/12/2019 13:45, Sara Dickinson wrote: > > > > > >> On 29 Nov 2019, at 15:39, Stephen Farrell via Datatracker wrote: > >> > >> Reviewer: Stephen Farrell > >> Review result: Ready > > > > Hi Stephen, > > > > Thanks for reviewing (again)! > > > >> > >> I might not be the best reviewer for this one as I've read it a few times > >> before. But anyway, I scanned the diff [1] with RFC7626 and figure it > >> seems fine. > >> > >> The only thing that occurred to me that seemed missing was to note > >> that while the new privacy analysis in 3.5.1.1 is already complex, many > >> systems are mobile and hence an analysis that ignores that won't be > >> sufficient. For a mobile device one really needs to analyse all of the > >> possible setups, and hence it's even harder to get to a good answer. > >> (It could be that that's elsewhere in the document but since I only > >> read the diff, I didn't see it:-) > > > > There was a bit of discussion about this and the following text in 3.4.1 was added: > > > > “ It is also noted that typically a device connected _only_ to a modern > > cellular network is > > > > o directly configured with only the recursive resolvers of the IAP > > and > > > > o all traffic (including DNS) between the device and the cellular > > network is encrypted following an encryption profile edited by the > > Third Generation Partnership Project (3GPP [2]). > > > > The attack surface for this specific scenario is not considered here." > > > > Which hopefully covers this? > > Not really, no. My point is that the analysis in 3.5.1.1 > doesn't encompass the fact that hosts are often (or even > mostly) mobile and hence connect to many networks, and that > the results of a privacy analysis related to DoT/DoH will > likely differ for each of those networks, from the POV > of the user or device owner, and even those two may not > agree in some cases. > > I don't believe that point is made in the document. But > I'm ok that you and the ADs figure out if its needed or > not. I think some kind of treatment is needed, even if the extent of the treatment might still be up for debate. Sara: note that "mobile" here is used in the generic sense of "moving around", not specific to a mobile or "cellular" pocket computer (aka "phone"). (I also agree with Ekr that the considerations around 3GPP encryption remain not great and would prefer to not rely on them.) Thanks for raising these issues, Stephen and Ekr. -Ben From nobody Mon Dec 23 14:12:48 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3253712081D; Mon, 23 Dec 2019 14:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 YtuwzZEJg0nv; Mon, 23 Dec 2019 14:12:40 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 D418112081C; Mon, 23 Dec 2019 14:12:40 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id x1so17497340iop.7; Mon, 23 Dec 2019 14:12:40 -0800 (PST) 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=qmdYbo2cQ3i06WX9dcxrJRULnGxoczl0PWyz+GjPxcY=; b=QoMZMjGAckTHahFcCMRugsEZ4B1vSm5+fBuY3KkqJpkDEJgI3oLlAuWNH0cU4RmSd7 JNN+WUIn5CrMJ+QxqgO/sjdGMkItd5nOdZPovdt+rw2OOx4HbYBwVtfHqK/Kxa3o2gau jC/JPdW0UlWx0G0IZWW4FOkZ7e/Vxb/ur2p9LsKdN1M6QJzel6w095tHDDY7oJ+nzjji Q9P4tIlo4dPdc+sxcnQjJVBNoyn3LJ8vbInMt8AhlluqC7oqgKYIsHxIEjqQq54GPhzQ Xg74M19CE4h3fPyAs39WFc5uS3ptWFfg5yzxwgIbitzZTJn7OXpjzw2EaAZmXkI+vcoo J6fg== 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=qmdYbo2cQ3i06WX9dcxrJRULnGxoczl0PWyz+GjPxcY=; b=o9Iu3X6/RFB4RMNHZFqXw48VSgcUSAFheULD7mBYwpLdqaJo6i5NrE7vLgzzv6B/bd MUw51j6yDnegvW4B2EW+dNP1IV1rQYBc+4xolDqUxpNnc4ollv3pzPavfR7ZQ/eEMtOS XvKr/vsgyita8quEzVaeBNz7qCGjv0jGtD3Q3BjQEh3jbQ6ehpRLq8NqsM9MIao2sV7N qDUjlJVNauyUNG3XIZHr2MI3CvlH9Ezm396MfxpBZEYMjwxZhSAVOg5gFqmh+C3z2yRw LX0IzS6dn4Y1hSUyqEitzsz5uAabwY2AstJ2ykn7ZRIxkKcoDWN40MfWFo5rWBrM6nh8 h3UQ== X-Gm-Message-State: APjAAAUsq/G44I38qF0pPjyquITg0gV/gLA6Ie8X3wKO8N26sTMII0bY G9mBkjmRyECBOTxFhvOFFIRUtoLMXvecH18AVrQ= X-Google-Smtp-Source: APXvYqzqZVO7r+pO1EMHCBjZ/ENnIYFE7eKNKAeTtaVXNYxy7AJR9nQR0dw/iPCDwd0iaRONVpJ/gmlX7xHO9+4P5so= X-Received: by 2002:a6b:d219:: with SMTP id q25mr8265567iob.49.1577139160052; Mon, 23 Dec 2019 14:12:40 -0800 (PST) MIME-Version: 1.0 References: <157504194893.4871.5551746255324168227@ietfa.amsl.com> <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> <20191223220509.GK35479@kduck.mit.edu> In-Reply-To: <20191223220509.GK35479@kduck.mit.edu> From: Rob Sayre Date: Mon, 23 Dec 2019 14:12:27 -0800 Message-ID: To: Benjamin Kaduk Cc: Sara Dickinson , last-call@ietf.org, DNS Privacy Working Group , Stephen Farrell , draft-ietf-dprive-rfc7626-bis.all@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000657907059a665376" Archived-At: Subject: Re: [secdir] [Last-Call] [dns-privacy] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 22:12:42 -0000 --000000000000657907059a665376 Content-Type: text/plain; charset="UTF-8" Hi, here are comments I mistakenly sent to a thread about another dprive last call. Summary: the section about "DoH Specific Considerations" is highly questionable, and seems like advocacy rather than a representation of IETF consensus. ---- Hi, I found two issues with [this draft]. The document mentions unattributed "concerns" in a few places. That doesn't seem like helpful content, but I can't say that such "concerns" and rampant use of the passive voice are uncommon in today's IETF. Secondly, I found the entire section "3.5.1.5.2. DoH Specific Considerations" to be objectionable, and recommend removing it. It mentions many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and contrasts DoH with DoT in ways that are specious. Both TLS and HTTP allow extension fields and metadata, so there's nothing unique to DoH here (source: I've implemented DoH and ESNI clients). The entire section amounts to a description of fields that privacy conscious DoH clients /might/ send if they were poorly implemented. But it seems strange to stop there. Implementation quality ratholes can go on for a while: for example, the document doesn't mention the numerous problems with today's TLS, PKI, and BGP infrastructure that apply to both DoT and DoH. thanks, Rob --000000000000657907059a665376 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, here are comments I mistakenly sent t= o a thread about another dprive last call. Summary: the section about "= ;DoH Specific Considerations" is highly questionable, and seems like a= dvocacy rather than a representation of IETF consensus.

= ----

Hi,

I found two issues with [this draf= t]. The document mentions unattributed "concerns" in a few places= . That doesn't seem like helpful content, but I can't say that such= "concerns" and rampant use of the passive voice are uncommon in = today's IETF.

Secondly, I found the entire section "3.5.1.= 5.2.=C2=A0 DoH Specific Considerations" to be objectionable, and recom= mend removing it. It mentions many concerns that are better covered in RFC = 8484 and/or HTTP RFCs, and contrasts DoH with DoT in ways that are specious= . Both TLS and HTTP allow extension fields and metadata, so there's not= hing unique to DoH here (source: I've implemented DoH and ESNI clients)= . The entire section amounts to a description of fields that privacy consci= ous DoH clients /might/ send if they were poorly implemented. But it seems = strange to stop there. Implementation quality ratholes can go on for a whil= e: for example, the document doesn't mention the numerous problems with= today's TLS, PKI, and BGP infrastructure that apply to both DoT and Do= H.

thanks,
Rob
--000000000000657907059a665376-- From nobody Tue Dec 24 07:51:24 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BD71200B8; Tue, 24 Dec 2019 07:51:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: Cc: last-call@ietf.org, draft-foudil-securitytxt.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Tero Kivinen Message-ID: <157720267698.19361.11750709876624228448@ietfa.amsl.com> Date: Tue, 24 Dec 2019 07:51:17 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2019 15:51:17 -0000 Reviewer: Tero Kivinen Review result: Has Issues This document describes text file located in the web server which can be used to find the information where to contact in case there is security vulnerabilities that needs to be disclosed. I think this whole idea is BAD, and I do not think we should be publishing this document at all in this format. First of all, the description here says we are providing "machine-parseable and extensible way for organizations to communicate information about their security disclosure policies". This file is supposed to be used WHEN there is security vulnerability found in the site, and in that case the attacker might have already had a way to modify this file too. Because of this I think providing machine-parseable format is bad, as this can open new security vulnerabilities, when some security problem reporting software parses this file generated by the attacker. Another problem is that even if the parser which parses this properly verifies the contents, the attacker might have changed the reporting locations to devnull@example.com or similar address, and if this report is semi-automatically sent the security reporter might not realize that he is just sending reports to the attacker. If this kind of file is needed, I think it should be human readable, and only shown to the user making the report, and user should then read it and find out the information where to send the reports. This way there is human in the process verifying that the information provided by the security.txt file is sane. More detailed comments follows. In section 3 it says that "security.txt" SHOULD be placed in the /.well-known/ path for web properties. Why is this not MUST? For this to be usable standard, there must be one location which is the authorative for this file. I think this document needs to say that it MUST the in /.well-known/security.txt. Documenting the legacy location in /security.txt is ok, and applications might try to read that also in case the standard "/.well-known/security.txt" is not found. Also it should tell which file is used if multiple copies of security.txt is found and their content is different. Also it seems even this document is not clear whether this is machine-parseable or not. It says it must be text/plain, and has .txt in file name, which would indicate it is just text file, not machine-parseable file. If the real reason is to provide machine-parseable file then .json / .xml or some other really machine-parseable file would be more suitable. On the other hand it also says in several places that security researcher SHOULD check this file and verify that everything looks good and so on. So if human is always needed in the loop, why even try to make this file machine-parseable. We can use the same format even if we do not try to make this file machine-parseable as humans also benefit from having standardized format containing information they need. Section 3 also says that "A security.txt file can have an unlimited number of fields." is bit dangerous when there is good probability that this file is generated by attacker. Perhaps provide some suitable limits for the size of this file. As most of the directives only provide pointers to another places, it might be suitable to limit this file in some sane size, for example saying that it SHOULD be less than 64kB, and receiver do not need to parse files larger than 1MB in size. These limits could also be added to section 6.3 if not here. Section 3.2 says that "Only the line most immediately preceding a field SHOULD be associated with that field." meaning that if you have file saying: # Our security policy is provided in the separate domain because the external # company was used to generate it Policy: https://example.com/security-policy.html and this would only associate the 2nd comment line to the Policy field. This can cause unexpected results for people generating this file, as usually they assume that you can add multiple lines of comment and all of them relate to the next field. In section 4.1, why is the redirect processing forbidden only when security.txt is in top directory, i.e., in that case the redirect will not be followed if it is not in the same server? Why do we allow redirects from the /.well-known/security.txt to external domains or servers? I would remove the 2nd paragraph of 4.1 completely, or rewrite it so it covers all cases where security.txt is fetched. The security section 6.1 claims that "/" is more likely to be compromised than "/.well-known/" and thats why redirects are limited for those, but redirects can also be done in the httpd server configuration file, and in that case it does not matter whether it redirects /.well-known/security.txt or /security.txt. Also I do not think there is real difference which directory is compromised more easily. If attackers can file files to the filesystem served by the web-server they quite often can do that for all paths. How is section 4.3 and 4.2 different. The root directory of the internal host is usually also considered as filesystem, so the rules of 4.2 also cover 4.3. Also why it is important that security.txt is put to the root directory of the filesystem only on internal hosts, but not in external hosts? This document contains lots of SHOULD etc to the actual users of the files (security researchers, organizations etc), which is bit funny. It is quite hard to verify that security researchers really checks the file before using it. It is good thing to give useful instructions for the users, but making them SHOULD or SHOULD NOT is not really helpful. In section 6.6 it says we MUST validated the X.509 certificates of the TLS, but one of the most common security reports I have been doing is a report of the expired certificates, in which case the certificate of the site serving security.txt is also expired, thus to be able to find this I need to allow reading this even when certificate validation failed. I wonder do we really need Hiring and Acknowledgements directives? I do not think they are really needed by the security researcher sending reports... From nobody Tue Dec 24 07:51:51 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE4B1201DE for ; Tue, 24 Dec 2019 07:51:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157720270476.19381.991410996437455800.idtracker@ietfa.amsl.com> Date: Tue, 24 Dec 2019 07:51:44 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2019 15:51:49 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Last calls: Reviewer LC end Draft John Bradley 2019-11-22 draft-schaad-cbor-content-02 Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-07 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-17 Alan DeKok 2019-11-27 draft-ietf-6man-ra-pref64-09 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Donald Eastlake 2019-11-14 draft-ietf-hip-dex-11 Tobias Gondrom 2019-12-02 draft-ietf-tls-tls13-cert-with-extern-psk-07 Dan Harkins R2019-10-03 draft-ietf-dtn-bpsec-13 Leif Johansson 2019-12-19 draft-ietf-jmap-websocket-04 Scott Kelly 2019-12-13 draft-ietf-bess-nsh-bgp-control-plane-13 Watson Ladd 2019-12-25 draft-ietf-ipsecme-qr-ikev2-09 Aanchal Malhotra 2019-12-23 draft-ietf-pce-stateful-flags-00 Daniel Migault 2020-01-17 draft-kucherawy-rfc8478bis-03 Adam Montville 2020-01-09 draft-ietf-6lo-ap-nd-12 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-07 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-05 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tirumaleswar Reddy.K Vincent Roca Kyle Rose Joseph Salowey From nobody Tue Dec 24 20:01:57 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBB21200E9; Tue, 24 Dec 2019 20:01:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: ipsec@ietf.org, last-call@ietf.org, draft-ietf-ipsecme-qr-ikev2.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Watson Ladd Message-ID: <157724651034.19353.11323639071881214460@ietfa.amsl.com> Date: Tue, 24 Dec 2019 20:01:50 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 04:01:50 -0000 Reviewer: Watson Ladd Review result: Not Ready Twas the night before Christmas when all through the house someone was desperately trying to get a review done on time. I didn't see anything wrong per se in the draft itself, but I found the capitalization of quantum computer an odd choice. IKEv2 is a complicated protocol, and I am not 100% sure that this draft does what we want it to: It would be great if someone could check very carefully in some symbolic model, ala what has been done in TLS. The guidance on sizes seems to rule out NIST level 1, but not any higher levels: might be worth calling out this explicitly. From nobody Tue Dec 24 20:34:24 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDD7120125; Tue, 24 Dec 2019 20:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 VU2ylmbU-CAf; Tue, 24 Dec 2019 20:34:11 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 0F227120071; Tue, 24 Dec 2019 20:34:11 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id y6so14118493lji.0; Tue, 24 Dec 2019 20:34:10 -0800 (PST) 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=NOg1hF3tnOUIuEohl2L03ZSDXE5LJF7ZP5SWDQ21eCY=; b=mpN7+x+ShVdYxyQquk2ww7WO5KoXiSI6hKwUN455vlZIRlwpo4NWdVac3k40UDfSug /8e9H+BkHu3X5Lf0CpK0NkirFwfoLZo9iJyYLgBASJ7zR+icHoBEY8gMh220hbr0yZsh SzI8c7Cj6w2uL1GT9Fz7JZKCJccDRv2o9kuITLzdT7zEfqkQrGfVXaeu6D2ZJ9MW1Amz PlcaFp4k3RlhO5xCLqSwvLVDP/+b2yjKazvl1K93AVS5mAkIQkTCtgfehwo52tsvCvEc WJBJQ2L4SvCJtZFESkMiFY3IwlKE4egq4Di4xsqkd1M0wRlLeOWwSPsHTa3T60uLMOhB 24fw== 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=NOg1hF3tnOUIuEohl2L03ZSDXE5LJF7ZP5SWDQ21eCY=; b=DT9nr80rSu2ajYGfESgiv/v4xk7vNnfu6lntd8596vMcV6ofvCuv5MROkjPVZcZY0x 6DYbKNtS1s9hhDga4l7GzB3FFGB6ep2AQLzLmj/BNR91FQeimdmnjMB/mC8GCmwcD5zf WpFGooL+YdR8pQ5KJVmPDSR+V4bzdmbGB91OsJbjK2P9qvOmBLT4rczLjQLT7Vh0o9va n8mMy3uMEqEpV4iBaWOiJ95JMeeshX7t1yYjBmAXDIhK7P+eO57khTD3fUCZuts7fx1K Al0Y0POkxcVCQIWevVVKyl27iaZFkEnpdQoafB5+jMYhj7bQrkcgGzRQU2ndhR/PrNUY eNZA== X-Gm-Message-State: APjAAAXnLGaUHtZ2EiyFTTdkmKUWvg9qkcL479eOI0qIIwHMRh0GmTri GXQEwWlPPz40r3JTWCpehVHr06fbIhD5wHn5VHw= X-Google-Smtp-Source: APXvYqz8rSq5gJ27w+iMRxhGfyMWJRIStD6OWFpFyCJsmNqPeHbaZnTjD6RvVKl7+nD8S83FNzY7IQ2bPKKMPKu0vGM= X-Received: by 2002:a2e:8551:: with SMTP id u17mr16949442ljj.165.1577248449086; Tue, 24 Dec 2019 20:34:09 -0800 (PST) MIME-Version: 1.0 References: <157724651034.19353.11323639071881214460@ietfa.amsl.com> In-Reply-To: <157724651034.19353.11323639071881214460@ietfa.amsl.com> From: Watson Ladd Date: Tue, 24 Dec 2019 20:33:57 -0800 Message-ID: To: Watson Ladd Cc: secdir , "ipsec@ietf.org WG" , last-call@ietf.org, draft-ietf-ipsecme-qr-ikev2.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000087cc6f059a7fc5b3" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 04:34:14 -0000 --00000000000087cc6f059a7fc5b3 Content-Type: text/plain; charset="UTF-8" Damn misclick. I meant With Nits. On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker < noreply@ietf.org> wrote: > Reviewer: Watson Ladd > Review result: Not Ready > > Twas the night before Christmas > when all through the house > someone was desperately trying to get a review done on time. > > I didn't see anything wrong per se in the draft itself, but I found the > capitalization of quantum computer an odd choice. IKEv2 is a complicated > protocol, and I am not 100% sure that this draft does what we want it to: > It > would be great if someone could check very carefully in some symbolic > model, > ala what has been done in TLS. The guidance on sizes seems to rule out NIST > level 1, but not any higher levels: might be worth calling out this > explicitly. > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > -- "Man is born free, but everywhere he is in chains". --Rousseau. --00000000000087cc6f059a7fc5b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Damn misclick. I meant With Nits.

On Tue, Dec 24, 2019= at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org> wrote:
Reviewer: Watson Ladd
Review result: Not Ready

Twas the night before Christmas
when all through the house
someone was desperately trying to get a review done on time.

I didn't see anything wrong per se in the draft itself, but I found the=
capitalization of quantum computer an odd choice. IKEv2 is a complicated protocol, and I am not 100% sure that this draft does what we want it to: I= t
would be great if someone could check very carefully in some symbolic model= ,
ala what has been done in TLS. The guidance on sizes seems to rule out NIST=
level 1, but not any higher levels: might be worth calling out this explici= tly.

_______________________________________________
secdir mailing list
secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/= SecDirReview


--
"Man is born free, but everywhere he is in chains"= ;.
--Rousseau.
--00000000000087cc6f059a7fc5b3-- From nobody Tue Dec 24 22:52:39 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C56012011F; Tue, 24 Dec 2019 22:52:30 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 Y31XMX6KaiWO; Tue, 24 Dec 2019 22:52:27 -0800 (PST) Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (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 85DDC120045; Tue, 24 Dec 2019 22:52:27 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ik0Wu-0001cR-53; Wed, 25 Dec 2019 09:52:24 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ik0Wt-0002m8-FI; Wed, 25 Dec 2019 09:52:24 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 25 Dec 2019 09:52:23 +0300 Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 25 Dec 2019 09:52:23 +0300 From: Valery Smyslov To: 'Watson Ladd' CC: 'secdir' , , , References: <157724651034.19353.11323639071881214460@ietfa.amsl.com> In-Reply-To: Date: Wed, 25 Dec 2019 09:52:26 +0300 Message-ID: <02c101d5baef$de2cdd90$9a8698b0$@elvis.ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C2_01D5BB09.037B2700" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHAI3dxdU4nCxDkFGYNjlyUdbESogLEWRy+p99zWWA= Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2019/12/25 05:40:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/12/25 05:12:00 #14885698 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 06:52:31 -0000 ------=_NextPart_000_02C2_01D5BB09.037B2700 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Watson, =20 thank you for spending your time on this review in Christmas Eve. =20 The capitalization issue has been already noticed and fixed. =20 I=E2=80=99m not sure the draft should mention NIST levels, because=20 they are relevant mostly for US customers. I think that=20 generic recommendations on key sizes are more appropriate for this document. =20 Regards, Valery. =20 Damn misclick. I meant With Nits. =20 On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker = wrote: Reviewer: Watson Ladd Review result: Not Ready Twas the night before Christmas when all through the house someone was desperately trying to get a review done on time. I didn't see anything wrong per se in the draft itself, but I found the capitalization of quantum computer an odd choice. IKEv2 is a complicated protocol, and I am not 100% sure that this draft does what we want it = to: It would be great if someone could check very carefully in some symbolic = model, ala what has been done in TLS. The guidance on sizes seems to rule out = NIST level 1, but not any higher levels: might be worth calling out this = explicitly. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau. ------=_NextPart_000_02C2_01D5BB09.037B2700 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Watson,

 

thank you for spending your time on this review in Christmas = Eve.

 

The capitalization issue has been already noticed and = fixed.

 

I=E2=80=99m not sure the draft should mention NIST levels, because =

they are relevant mostly for US customers. I think that =

generic recommendations on key sizes are more = appropriate

for this document.

 

Regards,

Valery.

 

Damn misclick. I meant With = Nits.

 

On = Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org> = wrote:

Reviewer: = Watson Ladd
Review result: Not Ready

Twas the night before = Christmas
when all through the house
someone was desperately = trying to get a review done on time.

I didn't see anything wrong = per se in the draft itself, but I found the
capitalization of quantum = computer an odd choice. IKEv2 is a complicated
protocol, and I am not = 100% sure that this draft does what we want it to: It
would be great = if someone could check very carefully in some symbolic model,
ala = what has been done in TLS. The guidance on sizes seems to rule out = NIST
level 1, but not any higher levels: might be worth calling out = this = explicitly.

_______________________________________________
sec= dir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--

------=_NextPart_000_02C2_01D5BB09.037B2700-- From nobody Wed Dec 25 03:57:58 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC3112082E; Wed, 25 Dec 2019 03:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEFU3pPeOt1L; Wed, 25 Dec 2019 03:57:41 -0800 (PST) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 BC58A12004A; Wed, 25 Dec 2019 03:57:40 -0800 (PST) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id xBPBxhLp019915; Wed, 25 Dec 2019 06:59:44 -0500 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 25 Dec 2019 06:56:01 -0500 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by oc11expo31.exchange.mit.edu (18.9.4.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 25 Dec 2019 06:57:32 -0500 Received: from oc11expo31.exchange.mit.edu ([18.9.4.104]) by oc11expo31.exchange.mit.edu ([18.9.4.104]) with mapi id 15.00.1365.000; Wed, 25 Dec 2019 06:57:32 -0500 From: Uri Blumenthal To: Valery Smyslov CC: Watson Ladd , "ipsec@ietf.org" , "last-call@ietf.org" , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" , secdir Thread-Topic: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 Thread-Index: AQHVutgQJ9+wavcRBECx2knvNxQEcqfKlyyAgAAmsQCAAFU9gA== Date: Wed, 25 Dec 2019 11:57:32 +0000 Message-ID: <70FA58C0-97E1-4F76-B88B-A28101A46069@mit.edu> References: <02c101d5baef$de2cdd90$9a8698b0$@elvis.ru> In-Reply-To: <02c101d5baef$de2cdd90$9a8698b0$@elvis.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/signed; boundary="Apple-Mail-D2EEC21A-E3BF-4669-B023-977D9FB8468C"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 11:57:43 -0000 --Apple-Mail-D2EEC21A-E3BF-4669-B023-977D9FB8468C Content-Type: multipart/alternative; boundary=Apple-Mail-877A88EF-9CA1-4975-BC02-1B11CA7980C3 Content-Transfer-Encoding: 7bit --Apple-Mail-877A88EF-9CA1-4975-BC02-1B11CA7980C3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 TklTVCBzdGFuZGFyZHMgYXJlIG1hbmRhdG9yeSBmb3IgYSBzdWJzZXQgb2YgVVMgY2l0aXplbnMu IEJ1dCBlbm91Z2ggb2YgYnVzaW5lc3NlcyBvdXRzaWRlIHRoZSBVUyBwYXkgYXR0ZW50aW9uIHRv IHdoYXQgTklTVCBzYXlzIHRvIG1ha2UgYWRkaW5nIHRoZSByZWZlcmVuY2UgcmVsZXZhbnQgYW5k IHVzZWZ1bC4NCg0KPiBPbiBEZWMgMjUsIDIwMTksIGF0IDAxOjUyLCBWYWxlcnkgU215c2xvdiA8 c3ZhbkBlbHZpcy5ydT4gd3JvdGU6DQo+IA0KPiDvu78NCj4gSGkgV2F0c29uLA0KPiAgDQo+IHRo YW5rIHlvdSBmb3Igc3BlbmRpbmcgeW91ciB0aW1lIG9uIHRoaXMgcmV2aWV3IGluIENocmlzdG1h cyBFdmUuDQo+ICANCj4gVGhlIGNhcGl0YWxpemF0aW9uIGlzc3VlIGhhcyBiZWVuIGFscmVhZHkg bm90aWNlZCBhbmQgZml4ZWQuDQo+ICANCj4gSeKAmW0gbm90IHN1cmUgdGhlIGRyYWZ0IHNob3Vs ZCBtZW50aW9uIE5JU1QgbGV2ZWxzLCBiZWNhdXNlDQo+IHRoZXkgYXJlIHJlbGV2YW50IG1vc3Rs eSBmb3IgVVMgY3VzdG9tZXJzLiBJIHRoaW5rIHRoYXQNCj4gZ2VuZXJpYyByZWNvbW1lbmRhdGlv bnMgb24ga2V5IHNpemVzIGFyZSBtb3JlIGFwcHJvcHJpYXRlDQo+IGZvciB0aGlzIGRvY3VtZW50 Lg0KPiAgDQo+IFJlZ2FyZHMsDQo+IFZhbGVyeS4NCj4gIA0KPiBEYW1uIG1pc2NsaWNrLiBJIG1l YW50IFdpdGggTml0cy4NCj4gIA0KPiBPbiBUdWUsIERlYyAyNCwgMjAxOSBhdCA4OjAyIFBNIFdh dHNvbiBMYWRkIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQo+IFJl dmlld2VyOiBXYXRzb24gTGFkZA0KPiBSZXZpZXcgcmVzdWx0OiBOb3QgUmVhZHkNCj4gDQo+IFR3 YXMgdGhlIG5pZ2h0IGJlZm9yZSBDaHJpc3RtYXMNCj4gd2hlbiBhbGwgdGhyb3VnaCB0aGUgaG91 c2UNCj4gc29tZW9uZSB3YXMgZGVzcGVyYXRlbHkgdHJ5aW5nIHRvIGdldCBhIHJldmlldyBkb25l IG9uIHRpbWUuDQo+IA0KPiBJIGRpZG4ndCBzZWUgYW55dGhpbmcgd3JvbmcgcGVyIHNlIGluIHRo ZSBkcmFmdCBpdHNlbGYsIGJ1dCBJIGZvdW5kIHRoZQ0KPiBjYXBpdGFsaXphdGlvbiBvZiBxdWFu dHVtIGNvbXB1dGVyIGFuIG9kZCBjaG9pY2UuIElLRXYyIGlzIGEgY29tcGxpY2F0ZWQNCj4gcHJv dG9jb2wsIGFuZCBJIGFtIG5vdCAxMDAlIHN1cmUgdGhhdCB0aGlzIGRyYWZ0IGRvZXMgd2hhdCB3 ZSB3YW50IGl0IHRvOiBJdA0KPiB3b3VsZCBiZSBncmVhdCBpZiBzb21lb25lIGNvdWxkIGNoZWNr IHZlcnkgY2FyZWZ1bGx5IGluIHNvbWUgc3ltYm9saWMgbW9kZWwsDQo+IGFsYSB3aGF0IGhhcyBi ZWVuIGRvbmUgaW4gVExTLiBUaGUgZ3VpZGFuY2Ugb24gc2l6ZXMgc2VlbXMgdG8gcnVsZSBvdXQg TklTVA0KPiBsZXZlbCAxLCBidXQgbm90IGFueSBoaWdoZXIgbGV2ZWxzOiBtaWdodCBiZSB3b3J0 aCBjYWxsaW5nIG91dCB0aGlzIGV4cGxpY2l0bHkuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZWNkaXIgbWFpbGluZyBsaXN0DQo+IHNl Y2RpckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nl Y2Rpcg0KPiB3aWtpOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYXJlYS9zZWMvdHJhYy93aWtpL1Nl Y0RpclJldmlldw0KPiANCj4gDQo+IC0tDQo+ICJNYW4gaXMgYm9ybiBmcmVlLCBidXQgZXZlcnl3 aGVyZSBoZSBpcyBpbiBjaGFpbnMiLg0KPiAtLVJvdXNzZWF1Lg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZWNkaXIgbWFpbGluZyBsaXN0DQo+ IHNlY2RpckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NlY2Rpcg0KPiB3aWtpOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYXJlYS9zZWMvdHJhYy93aWtp L1NlY0RpclJldmlldw0K --Apple-Mail-877A88EF-9CA1-4975-BC02-1B11CA7980C3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPk5JU1Qgc3RhbmRh cmRzIGFyZSBtYW5kYXRvcnkgZm9yIGEgc3Vic2V0IG9mIFVTIGNpdGl6ZW5zLiBCdXQgZW5vdWdo IG9mIGJ1c2luZXNzZXMgb3V0c2lkZSB0aGUgVVMgcGF5IGF0dGVudGlvbiB0byB3aGF0IE5JU1Qg c2F5cyB0byBtYWtlIGFkZGluZyB0aGUgcmVmZXJlbmNlIHJlbGV2YW50IGFuZCB1c2VmdWwuPGRp dj48ZGl2IGRpcj0ibHRyIj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+T24gRGVjIDI1LCAy MDE5LCBhdCAwMTo1MiwgVmFsZXJ5IFNteXNsb3YgJmx0O3N2YW5AZWx2aXMucnUmZ3Q7IHdyb3Rl Ojxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXYg ZGlyPSJsdHIiPu+7vw0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0 ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPjxzdHlsZT48IS0tDQovKiBGb250 IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzQ0NTQ2QTt9 DQouLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjIuMGNtIDQyLjVwdCAyLjBjbSAzLjBjbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT48ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2 QSI+SGkgV2F0c29uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPnRoYW5rIHlvdSBm b3Igc3BlbmRpbmcgeW91ciB0aW1lIG9uIHRoaXMgcmV2aWV3IGluIENocmlzdG1hcyBFdmUuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+VGhlIGNhcGl0YWxpemF0aW9uIGlzc3VlIGhh cyBiZWVuIGFscmVhZHkgbm90aWNlZCBhbmQgZml4ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0 LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzQ0NTQ2QSI+SeKAmW0gbm90IHN1cmUgdGhlIGRyYWZ0IHNob3VsZCBtZW50aW9uIE5JU1QgbGV2 ZWxzLCBiZWNhdXNlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPnRo ZXkgYXJlIHJlbGV2YW50IG1vc3RseSBmb3IgVVMgY3VzdG9tZXJzLiBJIHRoaW5rIHRoYXQgPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+Z2VuZXJpYyByZWNvbW1lbmRh dGlvbnMgb24ga2V5IHNpemVzIGFyZSBtb3JlIGFwcHJvcHJpYXRlPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+Zm9yIHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0 LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzQ0NTQ2QSI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojNDQ1NDZBIj5WYWxlcnkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2 QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+PGRp dj48cCBjbGFzcz0iTXNvTm9ybWFsIj5EYW1uIG1pc2NsaWNrLiBJIG1lYW50IFdpdGggTml0cy48 bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgMjQsIDIwMTkg YXQgODowMiBQTSBXYXRzb24gTGFkZCB2aWEgRGF0YXRyYWNrZXIgJmx0OzxhIGhyZWY9Im1haWx0 bzpub3JlcGx5QGlldGYub3JnIj5ub3JlcGx5QGlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj48cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXZpZXdlcjog V2F0c29uIExhZGQ8YnI+UmV2aWV3IHJlc3VsdDogTm90IFJlYWR5PGJyPjxicj5Ud2FzIHRoZSBu aWdodCBiZWZvcmUgQ2hyaXN0bWFzPGJyPndoZW4gYWxsIHRocm91Z2ggdGhlIGhvdXNlPGJyPnNv bWVvbmUgd2FzIGRlc3BlcmF0ZWx5IHRyeWluZyB0byBnZXQgYSByZXZpZXcgZG9uZSBvbiB0aW1l Ljxicj48YnI+SSBkaWRuJ3Qgc2VlIGFueXRoaW5nIHdyb25nIHBlciBzZSBpbiB0aGUgZHJhZnQg aXRzZWxmLCBidXQgSSBmb3VuZCB0aGU8YnI+Y2FwaXRhbGl6YXRpb24gb2YgcXVhbnR1bSBjb21w dXRlciBhbiBvZGQgY2hvaWNlLiBJS0V2MiBpcyBhIGNvbXBsaWNhdGVkPGJyPnByb3RvY29sLCBh bmQgSSBhbSBub3QgMTAwJSBzdXJlIHRoYXQgdGhpcyBkcmFmdCBkb2VzIHdoYXQgd2Ugd2FudCBp dCB0bzogSXQ8YnI+d291bGQgYmUgZ3JlYXQgaWYgc29tZW9uZSBjb3VsZCBjaGVjayB2ZXJ5IGNh cmVmdWxseSBpbiBzb21lIHN5bWJvbGljIG1vZGVsLDxicj5hbGEgd2hhdCBoYXMgYmVlbiBkb25l IGluIFRMUy4gVGhlIGd1aWRhbmNlIG9uIHNpemVzIHNlZW1zIHRvIHJ1bGUgb3V0IE5JU1Q8YnI+ bGV2ZWwgMSwgYnV0IG5vdCBhbnkgaGlnaGVyIGxldmVsczogbWlnaHQgYmUgd29ydGggY2FsbGlu ZyBvdXQgdGhpcyBleHBsaWNpdGx5Ljxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+c2VjZGlyIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJt YWlsdG86c2VjZGlyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2VjZGlyQGlldGYub3JnPC9h Pjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rp ciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2VjZGlyPC9hPjxicj53aWtpOiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYXJlYS9z ZWMvdHJhYy93aWtpL1NlY0RpclJldmlldyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5p ZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2VjRGlyUmV2aWV3PC9hPjxvOnA+PC9vOnA+PC9w PjwvYmxvY2txdW90ZT48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+ PGJyPi0tIDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+Ik1hbiBpcyBi b3JuIGZyZWUsIGJ1dCBldmVyeXdoZXJlIGhlIGlzIGluIGNoYWlucyIuPGJyPi0tUm91c3NlYXUu PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PHNwYW4+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPnNlY2RpciBtYWls aW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPnNlY2RpckBpZXRmLm9yZzwvc3Bhbj48YnI+PHNwYW4+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXI8L3NwYW4+PGJyPjxz cGFuPndpa2k6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2VjRGly UmV2aWV3PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-877A88EF-9CA1-4975-BC02-1B11CA7980C3-- --Apple-Mail-D2EEC21A-E3BF-4669-B023-977D9FB8468C Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMjI1MTE1NzMxWjAvBgkq hkiG9w0BCQQxIgQgiBdm9AIUa2EAE17v20HFGHuqMfsNenJEn1uHHayt5fgwMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYCQxBmJ vAav3FY+Z8soa2MpkgL3NGuQUqGIkxacx8LEbzFBnjF3uCDrOYKVhazzRTA13JJIIZnvyMa/T7AT 1eXSJhMiu+QormQ70xOdCEAwisahI4B18oEnDTrj73EsSvoCakZQjGddEa5lswNA3xd+uO8d67WF FL58A0PYD3dzlstA7l5TcHMlXGVGQTNr2mVzxq7L3BujW9/ID/JZTbM8VWQ68G7JItsgFoH1oRTv p4SYHBGikg/GmbnHQEWvs2QEXSnT3quQUmqcamJlnvJIQUEccqCENHdZ+8Bq1M586yqknWdWwAOa 6fT/I+T3Mu7nzalu0I5AXqej1sx62dm6UTbuYp6sz3eYZSKFumEy7aZ6hGVzWw+wDCnUoKbyDvQI gF2YpmBdICTpFpTKW/3Lx5xNj16muYDwROysvXIoOYzh2vDG38KZtlDOz1mzsrFgYQQQtMKUv8zu F90/p3yQs+wkm79xvrsRarIiz3hD1mV4PzfdQzzDl9nB/UO0jogAAAAAAAA= --Apple-Mail-D2EEC21A-E3BF-4669-B023-977D9FB8468C-- From nobody Wed Dec 25 09:19:10 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D53D1200A4; Wed, 25 Dec 2019 09:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 lrj_8Q_ULnfF; Wed, 25 Dec 2019 09:18:58 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 321B112008A; Wed, 25 Dec 2019 09:18:58 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id u1so23120355ljk.7; Wed, 25 Dec 2019 09:18:58 -0800 (PST) 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=BgPttg34novKpTJ1ZNpQfjOKpwM5DsFq3mUyHPE4N5M=; b=KzneKkeSh0i01MRTQzYJwwjQVLojTHioqmOAGytBc+RHb1gfQY8CkJhfp6QQ5toxCU I0RJReoo6rekO+0eIeOa44ZxbKW26gtzy8V6djIU2FZSd4tJ0SdxxHsh8jV5e9D3lkvA bDRKC1c/6tbe0vnliPI8l0fRhsrJjbTFobNJDPDdKvkngKWIfVdqxqfHRKe4qkFs1daf Ilh67JBnR8+eM9vobIYYV6VjxbvCD1TCbMDzoqhut1y97JHwNh6SbjZgf+AHT0Z5njDe 8tJ7s9G+hvpzYdMTCgp9mnkyRJq+wYOnllJFGXzWegMGGMro/ABLax4XGF0w1Eol4oTD juow== 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=BgPttg34novKpTJ1ZNpQfjOKpwM5DsFq3mUyHPE4N5M=; b=WXTyQ52cKpGz7apgEMxthUpW+PzZWVzCAOp58qhtLgrFyElDfxvfE8Xg4TZ07/vGr/ M3RKvRVla20fa+RSCNfHZckuRPiE9jrAkcgxYeoo8FGvqhvr65cGI2LqvyAqoEJ7fN/z yW7HKOuVPZgYUurxdzJdrunDX9bX0jXZ310zehNBp9H4LXEvEdHzTdJEV0zr9zPbntEd 4YnH9AC2IVnXBAGpQzyie/UKnG0HK0cC29q50Z+NxJA9yxRreEZAnJsVM/KeK00TKJ33 CZFIXfwqk7ts9WvkD+FffUcgZ3UjoWySYT+hsACqyWcTyKsFSyw8lxqmb4gz6hSZHely joTQ== X-Gm-Message-State: APjAAAVALoDJW3RAByyFxySR+bKvgBezVEcGfBo9g0CHKhlmN0Up6SIl ZuDRYEbl33uKvaXmIIJeLdf6iAHzPNz6hlWNfC0= X-Google-Smtp-Source: APXvYqxIRqAT0V6S61uavwcul4OBWcUhimZqMgU2lRYoefdDnh7VLq/kHAuIUaU4QCdLehux+R31LgwORyXhGvjB9xI= X-Received: by 2002:a2e:80cc:: with SMTP id r12mr23811861ljg.154.1577294336203; Wed, 25 Dec 2019 09:18:56 -0800 (PST) MIME-Version: 1.0 References: <02c101d5baef$de2cdd90$9a8698b0$@elvis.ru> <70FA58C0-97E1-4F76-B88B-A28101A46069@mit.edu> In-Reply-To: <70FA58C0-97E1-4F76-B88B-A28101A46069@mit.edu> From: Watson Ladd Date: Wed, 25 Dec 2019 09:18:44 -0800 Message-ID: To: Uri Blumenthal Cc: Valery Smyslov , "ipsec@ietf.org" , "last-call@ietf.org" , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" , secdir Content-Type: multipart/alternative; boundary="0000000000009da28a059a8a74a0" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 17:19:01 -0000 --0000000000009da28a059a8a74a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal wrote: > NIST standards are mandatory for a subset of US citizens. But enough of > businesses outside the US pay attention to what NIST says to make adding > the reference relevant and useful. > It's not about standards, it's about the competition and the relevant security level definitions. Not that I feel strongly about it, just a suggestion. > On Dec 25, 2019, at 01:52, Valery Smyslov wrote: > > =EF=BB=BF > > Hi Watson, > > > > thank you for spending your time on this review in Christmas Eve. > > > > The capitalization issue has been already noticed and fixed. > > > > I=E2=80=99m not sure the draft should mention NIST levels, because > > they are relevant mostly for US customers. I think that > > generic recommendations on key sizes are more appropriate > > for this document. > > > > Regards, > > Valery. > > > > Damn misclick. I meant With Nits. > > > > On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Watson Ladd > Review result: Not Ready > > Twas the night before Christmas > when all through the house > someone was desperately trying to get a review done on time. > > I didn't see anything wrong per se in the draft itself, but I found the > capitalization of quantum computer an odd choice. IKEv2 is a complicated > protocol, and I am not 100% sure that this draft does what we want it to: > It > would be great if someone could check very carefully in some symbolic > model, > ala what has been done in TLS. The guidance on sizes seems to rule out NI= ST > level 1, but not any higher levels: might be worth calling out this > explicitly. > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > > > -- > > "Man is born free, but everywhere he is in chains". > --Rousseau. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. --0000000000009da28a059a8a74a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 25, 2019 at 3:57 AM Uri B= lumenthal <uri@mit.edu> wrote:
=
N= IST standards are mandatory for a subset of US citizens. But enough of busi= nesses outside the US pay attention to what NIST says to make adding the re= ference relevant and useful.

It's= not about standards, it's about the competition and the relevant secur= ity level definitions. Not that I feel strongly about it, just a suggestion= .


On Dec 2= 5, 2019, at 01:52, Valery Smyslov <svan@elvis.ru> wrote:

=EF=BB=BF

= Hi Watson,

=C2=A0

thank you for spend= ing your time on this review in Christmas Eve.

= =C2=A0

The capitalization issue has been already noticed and fi= xed.

=C2=A0

I=E2=80=99m not sure the = draft should mention NIST levels, because

they are rele= vant mostly for US customers. I think that

generic reco= mmendations on key sizes are more appropriate

for this d= ocument.

=C2=A0

Regards,

Valery.

=C2=A0

Damn misclick. I meant With Nits.

=C2=A0

<= div>

On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via = Datatracker <norep= ly@ietf.org> wrote:

Revie= wer: Watson Ladd
Review result: Not Ready

Twas the night before C= hristmas
when all through the house
someone was desperately trying to= get a review done on time.

I didn't see anything wrong per se i= n the draft itself, but I found the
capitalization of quantum computer a= n odd choice. IKEv2 is a complicated
protocol, and I am not 100% sure th= at this draft does what we want it to: It
would be great if someone coul= d check very carefully in some symbolic model,
ala what has been done in= TLS. The guidance on sizes seems to rule out NIST
level 1, but not any = higher levels: might be worth calling out this explicitly.

_________= ______________________________________
secdir mailing list
secdir@ietf.org
https:/= /www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ie= tf.org/area/sec/trac/wiki/SecDirReview



--

=

"Man is born free, but everywhere he is in chai= ns".
--Rousseau.

_________= ______________________________________
secdir mailing list<= /span>
secdir= @ietf.org
https://www.ietf.org/mailman/listinfo/secdir<= /a>
wiki: http://tools.ietf.org/area/sec/trac/wiki= /SecDirReview


--
= "Man is born free, but everywhere he is in chains".
--Rousseau= .
--0000000000009da28a059a8a74a0-- From nobody Wed Dec 25 09:29:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE1D1200DF; Wed, 25 Dec 2019 09:29:15 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net 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 44Ni8lmLNJLz; Wed, 25 Dec 2019 09:29:13 -0800 (PST) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 110461200DB; Wed, 25 Dec 2019 09:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=rneZ+KmZPXE4LNeYoWlRDPfmgdao61WBWS1cvip/e7g=; b=sXPMNhDcsH8kXXduLuJ5ZuF/y6 N3u4q52nwAdad7OKHfQ9HaFkhn6IDpvltKtB9jLIInHBriMHCuenH6Sp0DO5j3wJ13GBP2NShfYi3 zJGPLYVEjHmQBjxYSuoTpXLNvgwaJnY3cCysrdNp0uhdyp3ZskNBGl4pW1owStzdDAIfyY0dUuRn7 4hLmphp81XiQxH409bhhg0iDc5lbiXBpnKh/3PrOV85zl8laxAeVUFjIGzUUia/X8GO/+JZaBlUZ9 0fJ++wYIxWnsAHTH2BCMnQnjOzZOhwxQYfgIX1mKhjbKpXwpzvquwfxKmKkvWhUkA1vea/WkGdXZO LnkVBc7A==; Received: from 95-27-147-103.broadband.corbina.ru ([95.27.147.103]:49183 helo=chichi) by direct.host-care.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.92) (envelope-from ) id 1ikAT7-0003Pr-PW; Wed, 25 Dec 2019 12:29:10 -0500 From: "Valery Smyslov" To: "'Watson Ladd'" , "'Uri Blumenthal'" Cc: , , "'secdir'" , , "'Valery Smyslov'" References: <02c101d5baef$de2cdd90$9a8698b0$@elvis.ru> <70FA58C0-97E1-4F76-B88B-A28101A46069@mit.edu> In-Reply-To: Date: Wed, 25 Dec 2019 20:29:04 +0300 Message-ID: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01D5BB61.F511BD60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD4j+CcA1FUw/w7bryPcykwDxxYVgHNoREJAqKWLLmpYe92IA== Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 17:29:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003A_01D5BB61.F511BD60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal < = uri@mit.edu> wrote: NIST standards are mandatory for a subset of US citizens. But enough of = businesses outside the US pay attention to what NIST says to make adding = the reference relevant and useful. =20 It's not about standards, it's about the competition and the relevant = security level definitions. Not that I feel strongly about it, just a = suggestion.. =20 Then I'm a bit confused. What competition do you mean?=20 =20 Regards, Valery. =20 =20 On Dec 25, 2019, at 01:52, Valery Smyslov wrote: =EF=BB=BF=20 Hi Watson, =20 thank you for spending your time on this review in Christmas Eve. =20 The capitalization issue has been already noticed and fixed. =20 I=E2=80=99m not sure the draft should mention NIST levels, because=20 they are relevant mostly for US customers. I think that=20 generic recommendations on key sizes are more appropriate for this document. =20 Regards, Valery. =20 Damn misclick. I meant With Nits. =20 On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker = wrote: Reviewer: Watson Ladd Review result: Not Ready Twas the night before Christmas when all through the house someone was desperately trying to get a review done on time. I didn't see anything wrong per se in the draft itself, but I found the capitalization of quantum computer an odd choice. IKEv2 is a complicated protocol, and I am not 100% sure that this draft does what we want it = to: It would be great if someone could check very carefully in some symbolic = model, ala what has been done in TLS. The guidance on sizes seems to rule out = NIST level 1, but not any higher levels: might be worth calling out this = explicitly. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau.. ------=_NextPart_000_003A_01D5BB61.F511BD60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, = Dec 25, 2019 at 3:57 AM Uri Blumenthal <uri@mit.edu> = wrote:

NIST = standards are mandatory for a subset of US citizens. But enough of = businesses outside the US pay attention to what NIST says to make adding = the reference relevant and = useful.

 

It's not about standards, it's about the competition = and the relevant security level definitions. Not that I feel strongly = about it, just a suggestion..

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Then I'm a bit = confused. What competition do you mean?

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Valery.

 

 



On Dec 25, 2019, at = 01:52, Valery Smyslov <svan@elvis.ru> = wrote:

=EF=BB=BF

Hi Watson,

 

thank you for spending your time on this review in Christmas = Eve.

 

The capitalization issue has been already noticed and = fixed.

 

I=E2=80=99m not sure the draft should mention NIST levels, because =

they are relevant mostly for US customers. I think that =

generic recommendations on key sizes are more = appropriate

for this document.

 

Regards,

Valery.

 

Damn = misclick. I meant With Nits.

 <= /o:p>

On Tue, Dec = 24, 2019 at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org> = wrote:

Reviewer: = Watson Ladd
Review result: Not Ready

Twas the night before = Christmas
when all through the house
someone was desperately = trying to get a review done on time.

I didn't see anything wrong = per se in the draft itself, but I found the
capitalization of quantum = computer an odd choice. IKEv2 is a complicated
protocol, and I am not = 100% sure that this draft does what we want it to: It
would be great = if someone could check very carefully in some symbolic model,
ala = what has been done in TLS. The guidance on sizes seems to rule out = NIST
level 1, but not any higher levels: might be worth calling out = this = explicitly.

_______________________________________________
sec= dir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--

_______________________________________________
secd= ir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--

------=_NextPart_000_003A_01D5BB61.F511BD60-- From nobody Wed Dec 25 10:25:02 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977021200E0; Wed, 25 Dec 2019 10:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIB5s54-D65C; Wed, 25 Dec 2019 10:24:48 -0800 (PST) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 6DDF11200E7; Wed, 25 Dec 2019 10:24:48 -0800 (PST) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id xBPIOS7s021422; Wed, 25 Dec 2019 13:24:38 -0500 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 25 Dec 2019 13:23:07 -0500 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by oc11expo31.exchange.mit.edu (18.9.4.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 25 Dec 2019 13:24:38 -0500 Received: from oc11expo31.exchange.mit.edu ([18.9.4.104]) by oc11expo31.exchange.mit.edu ([18.9.4.104]) with mapi id 15.00.1365.000; Wed, 25 Dec 2019 13:24:38 -0500 From: Uri Blumenthal To: Valery Smyslov CC: Watson Ladd , "ipsec@ietf.org" , "last-call@ietf.org" , secdir , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" , Valery Smyslov Thread-Topic: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 Thread-Index: AQHVutgQJ9+wavcRBECx2knvNxQEcqfKlyyAgAAmsQCAAFU9gIAAWb8AgAAC4wCAAA+GgA== Date: Wed, 25 Dec 2019 18:24:38 +0000 Message-ID: <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> In-Reply-To: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/signed; boundary="Apple-Mail-8082967C-EE3A-4682-8429-A70DBA3D925D"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 18:24:51 -0000 --Apple-Mail-8082967C-EE3A-4682-8429-A70DBA3D925D Content-Type: multipart/alternative; boundary=Apple-Mail-431E8F48-78D4-4243-AAAF-1F35F0B11EAB Content-Transfer-Encoding: 7bit --Apple-Mail-431E8F48-78D4-4243-AAAF-1F35F0B11EAB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 TklTVCBwcm9kdWNlcyBzdGFuZGFyZHMgYW5kIHJlY29tbWVuZGF0aW9ucy4gVVMgZ292ZXJubWVu dCBvcmdhbml6YXRpb25zIGFuZCBjb21wYW5pZXMgZG9pbmcgYnVzaW5lc3Mgd2l0aCB0aGVtIGFy ZSB1c3VhbGx5IHJlcXVpcmVkIHRvIGNvbXBseS4gT3JnYW5pemF0aW9ucyBhbmQgYnVzaW5lc3Nl cyAoYm90aCBVUyBhbmQgbm9uLVVTKSB0aGF0IGFyZSBub3QgYm91bmQgYnkgVVMgcmVndWxhdGlv bnMsIG9mdGVuIHBheSBhdHRlbnRpb24gdG8gd2hhdCBOSVNUIHJlY29tbWVuZHMuIA0KDQpUbyBy ZXBlYXQgbXlzZWxmLCBpdCBtYWdlcyBzZW5zZSB0byBhZGQgcmVmZXJlbmNlIHRvIHRoZSBOSVNU IGxldmVscywgZXZlbiBpZiBXYXRzb24gZG9lc24ndCBpbnNpc3QuIDstKQ0KDQo+IE9uIERlYyAy NSwgMjAxOSwgYXQgMTI6MjksIFZhbGVyeSBTbXlzbG92IDx2YWxlcnlAc215c2xvdi5uZXQ+IHdy b3RlOg0KPiANCj4g77u/DQo+IE9uIFdlZCwgRGVjIDI1LCAyMDE5IGF0IDM6NTcgQU0gVXJpIEJs dW1lbnRoYWwgPHVyaUBtaXQuZWR1PiB3cm90ZToNCj4gTklTVCBzdGFuZGFyZHMgYXJlIG1hbmRh dG9yeSBmb3IgYSBzdWJzZXQgb2YgVVMgY2l0aXplbnMuIEJ1dCBlbm91Z2ggb2YgYnVzaW5lc3Nl cyBvdXRzaWRlIHRoZSBVUyBwYXkgYXR0ZW50aW9uIHRvIHdoYXQgTklTVCBzYXlzIHRvIG1ha2Ug YWRkaW5nIHRoZSByZWZlcmVuY2UgcmVsZXZhbnQgYW5kIHVzZWZ1bC4NCj4gIA0KPiBJdCdzIG5v dCBhYm91dCBzdGFuZGFyZHMsIGl0J3MgYWJvdXQgdGhlIGNvbXBldGl0aW9uIGFuZCB0aGUgcmVs ZXZhbnQgc2VjdXJpdHkgbGV2ZWwgZGVmaW5pdGlvbnMuIE5vdCB0aGF0IEkgZmVlbCBzdHJvbmds eSBhYm91dCBpdCwganVzdCBhIHN1Z2dlc3Rpb24uLg0KPiAgDQo+ICAgICAgICAgICBUaGVuIEkn bSBhIGJpdCBjb25mdXNlZC4gV2hhdCBjb21wZXRpdGlvbiBkbyB5b3UgbWVhbj8NCj4gIA0KPiAg ICAgICAgICAgUmVnYXJkcywNCj4gICAgICAgICAgIFZhbGVyeS4NCj4gIA0KPiAgDQo+IA0KPiAN Cj4gT24gRGVjIDI1LCAyMDE5LCBhdCAwMTo1MiwgVmFsZXJ5IFNteXNsb3YgPHN2YW5AZWx2aXMu cnU+IHdyb3RlOg0KPiANCj4g77u/DQo+IEhpIFdhdHNvbiwNCj4gIA0KPiB0aGFuayB5b3UgZm9y IHNwZW5kaW5nIHlvdXIgdGltZSBvbiB0aGlzIHJldmlldyBpbiBDaHJpc3RtYXMgRXZlLg0KPiAg DQo+IFRoZSBjYXBpdGFsaXphdGlvbiBpc3N1ZSBoYXMgYmVlbiBhbHJlYWR5IG5vdGljZWQgYW5k IGZpeGVkLg0KPiAgDQo+IEnigJltIG5vdCBzdXJlIHRoZSBkcmFmdCBzaG91bGQgbWVudGlvbiBO SVNUIGxldmVscywgYmVjYXVzZQ0KPiB0aGV5IGFyZSByZWxldmFudCBtb3N0bHkgZm9yIFVTIGN1 c3RvbWVycy4gSSB0aGluayB0aGF0DQo+IGdlbmVyaWMgcmVjb21tZW5kYXRpb25zIG9uIGtleSBz aXplcyBhcmUgbW9yZSBhcHByb3ByaWF0ZQ0KPiBmb3IgdGhpcyBkb2N1bWVudC4NCj4gIA0KPiBS ZWdhcmRzLA0KPiBWYWxlcnkuDQo+ICANCj4gRGFtbiBtaXNjbGljay4gSSBtZWFudCBXaXRoIE5p dHMuDQo+ICANCj4gT24gVHVlLCBEZWMgMjQsIDIwMTkgYXQgODowMiBQTSBXYXRzb24gTGFkZCB2 aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KPiBSZXZpZXdlcjogV2F0 c29uIExhZGQNCj4gUmV2aWV3IHJlc3VsdDogTm90IFJlYWR5DQo+IA0KPiBUd2FzIHRoZSBuaWdo dCBiZWZvcmUgQ2hyaXN0bWFzDQo+IHdoZW4gYWxsIHRocm91Z2ggdGhlIGhvdXNlDQo+IHNvbWVv bmUgd2FzIGRlc3BlcmF0ZWx5IHRyeWluZyB0byBnZXQgYSByZXZpZXcgZG9uZSBvbiB0aW1lLg0K PiANCj4gSSBkaWRuJ3Qgc2VlIGFueXRoaW5nIHdyb25nIHBlciBzZSBpbiB0aGUgZHJhZnQgaXRz ZWxmLCBidXQgSSBmb3VuZCB0aGUNCj4gY2FwaXRhbGl6YXRpb24gb2YgcXVhbnR1bSBjb21wdXRl ciBhbiBvZGQgY2hvaWNlLiBJS0V2MiBpcyBhIGNvbXBsaWNhdGVkDQo+IHByb3RvY29sLCBhbmQg SSBhbSBub3QgMTAwJSBzdXJlIHRoYXQgdGhpcyBkcmFmdCBkb2VzIHdoYXQgd2Ugd2FudCBpdCB0 bzogSXQNCj4gd291bGQgYmUgZ3JlYXQgaWYgc29tZW9uZSBjb3VsZCBjaGVjayB2ZXJ5IGNhcmVm dWxseSBpbiBzb21lIHN5bWJvbGljIG1vZGVsLA0KPiBhbGEgd2hhdCBoYXMgYmVlbiBkb25lIGlu IFRMUy4gVGhlIGd1aWRhbmNlIG9uIHNpemVzIHNlZW1zIHRvIHJ1bGUgb3V0IE5JU1QNCj4gbGV2 ZWwgMSwgYnV0IG5vdCBhbnkgaGlnaGVyIGxldmVsczogbWlnaHQgYmUgd29ydGggY2FsbGluZyBv dXQgdGhpcyBleHBsaWNpdGx5Lg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gc2VjZGlyIG1haWxpbmcgbGlzdA0KPiBzZWNkaXJAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXINCj4gd2lr aTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZpZXcN Cj4gDQo+IA0KPiAtLQ0KPiAiTWFuIGlzIGJvcm4gZnJlZSwgYnV0IGV2ZXJ5d2hlcmUgaGUgaXMg aW4gY2hhaW5zIi4NCj4gLS1Sb3Vzc2VhdS4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2VjZGlyIG1haWxpbmcgbGlzdA0KPiBzZWNkaXJAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXINCj4g d2lraTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZp ZXcNCj4gDQo+IA0KPiAtLQ0KPiAiTWFuIGlzIGJvcm4gZnJlZSwgYnV0IGV2ZXJ5d2hlcmUgaGUg aXMgaW4gY2hhaW5zIi4NCj4gLS1Sb3Vzc2VhdS4uDQo= --Apple-Mail-431E8F48-78D4-4243-AAAF-1F35F0B11EAB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPk5JU1QgcHJvZHVj ZXMgc3RhbmRhcmRzIGFuZCByZWNvbW1lbmRhdGlvbnMuIFVTIGdvdmVybm1lbnQgb3JnYW5pemF0 aW9ucyBhbmQgY29tcGFuaWVzIGRvaW5nIGJ1c2luZXNzIHdpdGggdGhlbSBhcmUgdXN1YWxseSBy ZXF1aXJlZCB0byBjb21wbHkuIE9yZ2FuaXphdGlvbnMgYW5kIGJ1c2luZXNzZXMgKGJvdGggVVMg YW5kIG5vbi1VUykgdGhhdCBhcmUgbm90IGJvdW5kIGJ5IFVTIHJlZ3VsYXRpb25zLCBvZnRlbiBw YXkgYXR0ZW50aW9uIHRvIHdoYXQgTklTVCByZWNvbW1lbmRzLiZuYnNwOzxkaXY+PGJyPjxkaXYg ZGlyPSJsdHIiPlRvIHJlcGVhdCBteXNlbGYsIGl0IG1hZ2VzIHNlbnNlIHRvIGFkZCByZWZlcmVu Y2UgdG8gdGhlIE5JU1QgbGV2ZWxzLCBldmVuIGlmIFdhdHNvbiBkb2Vzbid0IGluc2lzdC4gOy0p PC9kaXY+PGRpdiBkaXI9Imx0ciI+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9uIERlYyAy NSwgMjAxOSwgYXQgMTI6MjksIFZhbGVyeSBTbXlzbG92ICZsdDt2YWxlcnlAc215c2xvdi5uZXQm Z3Q7IHdyb3RlOjxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPjxkaXYgZGlyPSJsdHIiPu+7vw0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPjxzdHlsZT48IS0t DQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBN aW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQEFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjIuMGNtIDQyLjVwdCAyLjBjbSAzLjBjbTt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFdlZCwgRGVjIDI1LCAyMDE5IGF0IDM6NTcgQU0g VXJpIEJsdW1lbnRoYWwgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86dXJpQG1pdC5lZHUiPjxz cGFuIGxhbmc9IkVOLVVTIj51cmlAbWl0LmVkdTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+PGRpdj48 cCBjbGFzcz0iTXNvTm9ybWFsIj5OSVNUIHN0YW5kYXJkcyBhcmUgbWFuZGF0b3J5IGZvciBhIHN1 YnNldCBvZiBVUyBjaXRpemVucy4gQnV0IGVub3VnaCBvZiBidXNpbmVzc2VzIG91dHNpZGUgdGhl IFVTIHBheSBhdHRlbnRpb24gdG8gd2hhdCBOSVNUIHNheXMgdG8gbWFrZSBhZGRpbmcgdGhlIHJl ZmVyZW5jZSByZWxldmFudCBhbmQgdXNlZnVsLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2tx dW90ZT48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQncyBub3QgYWJvdXQgc3RhbmRhcmRzLCBpdCdz IGFib3V0IHRoZSBjb21wZXRpdGlvbiBhbmQgdGhlIHJlbGV2YW50IHNlY3VyaXR5IGxldmVsIGRl ZmluaXRpb25zLiBOb3QgdGhhdCBJIGZlZWwgc3Ryb25nbHkgYWJvdXQgaXQsIGp1c3QgYSBzdWdn ZXN0aW9uLi48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoZW4gSSdtIGEgYml0IGNvbmZ1c2VkLiBXaGF0IGNvbXBldGl0aW9uIGRvIHlvdSBtZWFuPyA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTMuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVmFsZXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiBEZWMgMjUsIDIw MTksIGF0IDAxOjUyLCBWYWxlcnkgU215c2xvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN2YW5AZWx2 aXMucnUiIHRhcmdldD0iX2JsYW5rIj5zdmFuQGVsdmlzLnJ1PC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj7vu78gPG86cD48L286cD48 L3A+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+SGkgV2F0c29uLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNDQ1NDZBIj50aGFuayB5b3UgZm9yIHNwZW5kaW5nIHlvdXIgdGltZSBvbiB0 aGlzIHJldmlldyBpbiBDaHJpc3RtYXMgRXZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzQ0NTQ2QSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj NDQ1NDZBIj5UaGUgY2FwaXRhbGl6YXRpb24gaXNzdWUgaGFzIGJlZW4gYWxyZWFkeSBub3RpY2Vk IGFuZCBmaXhlZC48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+SeKAmW0gbm90 IHN1cmUgdGhlIGRyYWZ0IHNob3VsZCBtZW50aW9uIE5JU1QgbGV2ZWxzLCBiZWNhdXNlIDwvc3Bh bj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+dGhleSBhcmUgcmVsZXZhbnQg bW9zdGx5IGZvciBVUyBjdXN0b21lcnMuIEkgdGhpbmsgdGhhdCA8L3NwYW4+PG86cD48L286cD48 L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPmdlbmVyaWMgcmVjb21tZW5kYXRpb25zIG9uIGtleSBz aXplcyBhcmUgbW9yZSBhcHByb3ByaWF0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzQ0NTQ2QSI+Zm9yIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojNDQ1NDZBIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiM0NDU0NkEiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1 NDZBIj5WYWxlcnkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O2Jv cmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBibHVlIj48 ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RGFtbiBtaXNjbGljay4gSSBtZWFudCBXaXRoIE5p dHMuPG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIERlYyAy NCwgMjAxOSBhdCA4OjAyIFBNIFdhdHNvbiBMYWRkIHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ub3JlcGx5QGlldGYu b3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9y IGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5SZXZpZXdlcjogV2F0c29uIExhZGQ8YnI+UmV2aWV3IHJlc3VsdDogTm90IFJl YWR5PGJyPjxicj5Ud2FzIHRoZSBuaWdodCBiZWZvcmUgQ2hyaXN0bWFzPGJyPndoZW4gYWxsIHRo cm91Z2ggdGhlIGhvdXNlPGJyPnNvbWVvbmUgd2FzIGRlc3BlcmF0ZWx5IHRyeWluZyB0byBnZXQg YSByZXZpZXcgZG9uZSBvbiB0aW1lLjxicj48YnI+SSBkaWRuJ3Qgc2VlIGFueXRoaW5nIHdyb25n IHBlciBzZSBpbiB0aGUgZHJhZnQgaXRzZWxmLCBidXQgSSBmb3VuZCB0aGU8YnI+Y2FwaXRhbGl6 YXRpb24gb2YgcXVhbnR1bSBjb21wdXRlciBhbiBvZGQgY2hvaWNlLiBJS0V2MiBpcyBhIGNvbXBs aWNhdGVkPGJyPnByb3RvY29sLCBhbmQgSSBhbSBub3QgMTAwJSBzdXJlIHRoYXQgdGhpcyBkcmFm dCBkb2VzIHdoYXQgd2Ugd2FudCBpdCB0bzogSXQ8YnI+d291bGQgYmUgZ3JlYXQgaWYgc29tZW9u ZSBjb3VsZCBjaGVjayB2ZXJ5IGNhcmVmdWxseSBpbiBzb21lIHN5bWJvbGljIG1vZGVsLDxicj5h bGEgd2hhdCBoYXMgYmVlbiBkb25lIGluIFRMUy4gVGhlIGd1aWRhbmNlIG9uIHNpemVzIHNlZW1z IHRvIHJ1bGUgb3V0IE5JU1Q8YnI+bGV2ZWwgMSwgYnV0IG5vdCBhbnkgaGlnaGVyIGxldmVsczog bWlnaHQgYmUgd29ydGggY2FsbGluZyBvdXQgdGhpcyBleHBsaWNpdGx5Ljxicj48YnI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+c2VjZGlyIG1haWxp bmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+c2VjZGlyQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NlY2RpciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlyPC9hPjxicj53aWtpOiA8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvYXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2VjRGlyUmV2 aWV3PC9hPjxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48L2Rpdj48cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPG86cD48L286cD48L3A+PGRpdj48cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiJNYW4gaXMgYm9ybiBmcmVlLCBidXQgZXZlcnl3aGVyZSBoZSBpcyBp biBjaGFpbnMiLjxicj4tLVJvdXNzZWF1LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPnNlY2RpciBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnNl Y2RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNlY2RpckBpZXRmLm9yZzwvYT48YnI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXIiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpcjwv YT48YnI+d2lraTogPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMv d2lraS9TZWNEaXJSZXZpZXciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv YXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldzwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPG86cD48L286cD48L3A+PGRpdj48cCBjbGFz cz0iTXNvTm9ybWFsIj4iTWFuIGlzIGJvcm4gZnJlZSwgYnV0IGV2ZXJ5d2hlcmUgaGUgaXMgaW4g Y2hhaW5zIi48YnI+LS1Sb3Vzc2VhdS4uPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvYm9keT48L2h0bWw+ --Apple-Mail-431E8F48-78D4-4243-AAAF-1F35F0B11EAB-- --Apple-Mail-8082967C-EE3A-4682-8429-A70DBA3D925D Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMjI1MTgyNDM3WjAvBgkq hkiG9w0BCQQxIgQg8R4guve9bByBQIhrZIQZ3cwEwVZs9lzBN8nL6mpUWIswMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYAuUkGB 1dQ+ox7OXUzXJXdonLpP8Z2aPRIbx3rr/uuj8khZ13cYTs91v+ZiKebxqWOBILSA2NdCvXRcpXpk pbVotNgNguDexkkxUvZO6MatKqHCQyvwncBp8+Uf0wTG/JrZhSJnjPaGzy+dYJcjFlWTiB9XdOPc nak4m8zqug7ZJ/cPLGQg7nsfgrkk1Z18ZOSqmEWveOmDDZp4WAQ1FBswBdwQilQoJcw4Kzb3+8Va qoei3q4tmeKDFsQ5FscnQ88qtrNMv/Yv4LEnFnxI9eoSNLysR/JFDzsdzkpmbYmibX+G5Wc2N+AL nAGiCtvRuai10IdhPhds1hi9+A1FwhCgis9Jya1DryXdWVn5Yx2Ioz0FYKp510tfkFObIs3X247Y avcvBfvYfbajemwXT8/mbtKgVQgSqvod3rZOIIji2Xpk0bgGxv4YC/aOWXxcs9Wpz5mzpGyVt0uB l8VjhBWDli0g7Jyp9AWvV2wbl59nfqwvuDEWmNptcLH7KpH5eCwAAAAAAAA= --Apple-Mail-8082967C-EE3A-4682-8429-A70DBA3D925D-- From nobody Wed Dec 25 10:27:55 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A15D1200DB; Wed, 25 Dec 2019 10:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 r32pKvhNhLW1; Wed, 25 Dec 2019 10:27:42 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 1D8A412002E; Wed, 25 Dec 2019 10:27:42 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id n25so17204838lfl.0; Wed, 25 Dec 2019 10:27:42 -0800 (PST) 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=lkQ7Vm1PUpSLKKHrqsAdIkrON01hExJHJXQzZS/zYrI=; b=EOjxngl7r/opo66b0GMqSGLf1aa+IR3oKnCg6CgxYRV0hBfL8AODF9GGaGgsuePw5F WlEnK08+BD1+MjWssCrBVPhYQDXuLDGa+mRqgHEep7bwS06B2YdqCtj3lzpCFkMOw4pb X5rynxLfitGjM+2rQjF1p0mIdkIBVvRoz+x381HO1LsQSv69O9VxGNc/CKYcoH2/9O/A qoxT6DAmen+Hh1mjaSslmq0aouAJclsTmE/DFtNdaosGqfhmjdLciPRFnO92p1lJYkuv HImy7pLFT46ZzI/fqfiCQTE0zMOlUHJ5TQQUaepeoiqvtS7wuJJ2fhq9YZJlpd5CvQw/ 5ALQ== 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=lkQ7Vm1PUpSLKKHrqsAdIkrON01hExJHJXQzZS/zYrI=; b=SP0/fAQZv5j8x5oGXQ9UO+uzyzcur/ijrtWHbNBUSL2VUSzPGuwsBz5aSdXKpqNn3U ixdjRG82d8J+LHEVXHJTSZMSjY8t7fCyzHHbNltp6fHikB7cwUAXo0hZiiNpVvwKUdfe OZeU1LaoK+D07HnY5RV+9Oz9BBJ49hT6iGcY9SJePwACpf11wQtODWQqtqmsQHsF5jLT bA/okOEq6Y2ERmUrPX2li3eAxybtKIe6kYdRdpROn2OlkC6C9q7MeOsh2vzNFLCPfBlu q74N78OLJduwrIRXbzuJAjMtuIRt1D+32CtXlhr6rk4zrd2YF48fF72pM/u1ta4D0EBX 9HsQ== X-Gm-Message-State: APjAAAVZpVCzTUTmH4/3NwseCVcnsU30H+v3IX+r5qprn+xbQNkUeU9X B8xwJfhgh5A+bqmACffMibZJeRq37HaGtXCxeaw= X-Google-Smtp-Source: APXvYqzHDdxGCRbgrFwCHDfjlOgRMd8+ZW5pqk9eN4tCp54/A56EgO4H1YENjkC9if0teJzNrvg4n+/f96JONebXWuI= X-Received: by 2002:a19:6509:: with SMTP id z9mr23369445lfb.97.1577298460360; Wed, 25 Dec 2019 10:27:40 -0800 (PST) MIME-Version: 1.0 References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> In-Reply-To: <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> From: Watson Ladd Date: Wed, 25 Dec 2019 10:27:29 -0800 Message-ID: To: Uri Blumenthal Cc: Valery Smyslov , "ipsec@ietf.org" , "last-call@ietf.org" , secdir , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" , Valery Smyslov Content-Type: multipart/alternative; boundary="0000000000006f441f059a8b6add" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 18:27:45 -0000 --0000000000006f441f059a8b6add Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm talking about the ongoing NIST quantum cryptography competition, which targets at the lowest level security equivalent to AES-128. On Wed, Dec 25, 2019 at 10:24 AM Uri Blumenthal wrote: > NIST produces standards and recommendations. US government organizations > and companies doing business with them are usually required to comply. > Organizations and businesses (both US and non-US) that are not bound by U= S > regulations, often pay attention to what NIST recommends. > > To repeat myself, it mages sense to add reference to the NIST levels, eve= n > if Watson doesn't insist. ;-) > > On Dec 25, 2019, at 12:29, Valery Smyslov wrote: > > =EF=BB=BF > > On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal wrote: > > NIST standards are mandatory for a subset of US citizens. But enough of > businesses outside the US pay attention to what NIST says to make adding > the reference relevant and useful. > > > > It's not about standards, it's about the competition and the relevant > security level definitions. Not that I feel strongly about it, just a > suggestion.. > > > > Then I'm a bit confused. What competition do you mean? > > > > Regards, > > Valery. > > > > > > > > On Dec 25, 2019, at 01:52, Valery Smyslov wrote: > > =EF=BB=BF > > Hi Watson, > > > > thank you for spending your time on this review in Christmas Eve. > > > > The capitalization issue has been already noticed and fixed. > > > > I=E2=80=99m not sure the draft should mention NIST levels, because > > they are relevant mostly for US customers. I think that > > generic recommendations on key sizes are more appropriate > > for this document. > > > > Regards, > > Valery. > > > > Damn misclick. I meant With Nits. > > > > On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Watson Ladd > Review result: Not Ready > > Twas the night before Christmas > when all through the house > someone was desperately trying to get a review done on time. > > I didn't see anything wrong per se in the draft itself, but I found the > capitalization of quantum computer an odd choice. IKEv2 is a complicated > protocol, and I am not 100% sure that this draft does what we want it to: > It > would be great if someone could check very carefully in some symbolic > model, > ala what has been done in TLS. The guidance on sizes seems to rule out NI= ST > level 1, but not any higher levels: might be worth calling out this > explicitly. > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > > > -- > > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > > > -- > > "Man is born free, but everywhere he is in chains". > --Rousseau.. > > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. --0000000000006f441f059a8b6add Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm talking about the ongoing NIST qu= antum cryptography competition, which targets at the lowest level security = equivalent to AES-128.

On Wed, Dec 25, 2019 at 10:24 AM Uri Blumenthal &= lt;uri@mit.edu> wrote:
NIST produce= s standards and recommendations. US government organizations and companies = doing business with them are usually required to comply. Organizations and = businesses (both US and non-US) that are not bound by US regulations, often= pay attention to what NIST recommends.=C2=A0

To r= epeat myself, it mages sense to add reference to the NIST levels, even if W= atson doesn't insist. ;-)

On Dec 25, 2019, at 12:29, Valery Smyslov <valery@smyslov.net> wrote:

=
=EF=BB=BF

On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal <uri@mit.edu= > wrote:

<= blockquote style=3D"border-color:currentcolor currentcolor currentcolor rgb= (204,204,204);border-style:none none none solid;border-width:medium medium = medium 1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">

NIST standards are mandatory for a subset of US cit= izens. But enough of businesses outside the US pay attention to what NIST s= ays to make adding the reference relevant and useful.

=C2=A0

It's not about standards, it's about the = competition and the relevant security level definitions. Not that I feel st= rongly about it, just a suggestion..

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Then I'm a bit confused. What competition do you mean?

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Regards,

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Valery.

=C2=A0<= /u>

=C2=A0



On Dec 25, 2019, at 01:52, Valery Smyslov <svan@elvis.ru> wrote:<= u>

=EF=BB=BF

Hi Watson,

=C2=A0

thank you for spending your time on= this review in Christmas Eve.

=C2=A0

The capitalization issue has been already noticed and fixed.=

=C2=A0

I=E2=80=99m not sure the draft should menti= on NIST levels, because

they are relevant mostly for US= customers. I think that

generic recommendations on key= sizes are more appropriate

= for this document.=

=C2=A0

Regards,

Valery.

=C2=A0

Damn misclick. I meant With Nits.

=C2=A0

On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org>= wrote:

Reviewer: Watson Ladd
Review re= sult: Not Ready

Twas the night before Christmas
when all through = the house
someone was desperately trying to get a review done on time.
I didn't see anything wrong per se in the draft itself, but I fou= nd the
capitalization of quantum computer an odd choice. IKEv2 is a comp= licated
protocol, and I am not 100% sure that this draft does what we wa= nt it to: It
would be great if someone could check very carefully in som= e symbolic model,
ala what has been done in TLS. The guidance on sizes s= eems to rule out NIST
level 1, but not any higher levels: might be worth= calling out this explicitly.

______________________________________= _________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/= secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDi= rReview



--

"Ma= n is born free, but everywhere he is in chains".
--Rousseau.=

_______________________= ________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/= trac/wiki/SecDirReview

=



-- <= u>

"Man is born free, but everywher= e he is in chains".
--Rousseau..


=
--
"Man is born fre= e, but everywhere he is in chains".
--Rousseau.
--0000000000006f441f059a8b6add-- From nobody Wed Dec 25 10:44:21 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4EF1200A1; Wed, 25 Dec 2019 10:44:20 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 AZGoerrZBrVP; Wed, 25 Dec 2019 10:44:17 -0800 (PST) Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (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 2D42812002E; Wed, 25 Dec 2019 10:44:17 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ikBdm-0007y3-9P; Wed, 25 Dec 2019 21:44:14 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ikBdl-0001H0-BP; Wed, 25 Dec 2019 21:44:14 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 25 Dec 2019 21:44:10 +0300 Received: from chichi (10.100.100.5) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 25 Dec 2019 21:44:07 +0300 From: Valery Smyslov To: 'Watson Ladd' , 'Uri Blumenthal' CC: 'Valery Smyslov' , , , 'secdir' , References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> In-Reply-To: Date: Wed, 25 Dec 2019 21:44:05 +0300 Message-ID: <007b01d5bb53$48c557f0$da5007d0$@elvis.ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01D5BB6C.6E143DA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHdvvqKSyXWSys4i9wLZip4/JKSjgI7xNqsAbHYPj2nm7dRkA== Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2019/12/25 18:17:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/12/25 14:37:00 #14886745 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 18:44:20 -0000 ------=_NextPart_000_007C_01D5BB6C.6E143DA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Do you mean the post-quantum cryptography competition = (https://csrc.nist.gov/Projects/post-quantum-cryptography)?=20 =20 That's why I felt confused. The draft isn't concerned with any = post-quantum cryptography stuff, it uses only well-studied methods of classical cryptography. I don't = think this particular=20 competition is relevant here. =20 However, taking into consideration Grover's algorithm, it seems that 128 = bit level is the maximum available for the current off-the-shelf crypto algorithms (I'm not aware = of any widely used cipher with key=20 length more than 256 bit). =20 Regards, Valery. =20 =20 I'm talking about the ongoing NIST quantum cryptography competition, = which targets at the lowest level security equivalent to AES-128. =20 On Wed, Dec 25, 2019 at 10:24 AM Uri Blumenthal wrote: NIST produces standards and recommendations. US government organizations = and companies doing business with them are usually required to comply. = Organizations and businesses (both US and non-US) that are not bound by = US regulations, often pay attention to what NIST recommends.=20 =20 To repeat myself, it mages sense to add reference to the NIST levels, = even if Watson doesn't insist. ;-) On Dec 25, 2019, at 12:29, Valery Smyslov wrote: =EF=BB=BF=20 On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal < = uri@mit.edu> wrote: NIST standards are mandatory for a subset of US citizens. But enough of = businesses outside the US pay attention to what NIST says to make adding = the reference relevant and useful. =20 It's not about standards, it's about the competition and the relevant = security level definitions. Not that I feel strongly about it, just a = suggestion.. =20 Then I'm a bit confused. What competition do you mean?=20 =20 Regards, Valery. =20 =20 =20 On Dec 25, 2019, at 01:52, Valery Smyslov wrote: =EF=BB=BF=20 Hi Watson, =20 thank you for spending your time on this review in Christmas Eve. =20 The capitalization issue has been already noticed and fixed. =20 I=E2=80=99m not sure the draft should mention NIST levels, because=20 they are relevant mostly for US customers. I think that=20 generic recommendations on key sizes are more appropriate for this document. =20 Regards, Valery. =20 Damn misclick. I meant With Nits. =20 On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker = wrote: Reviewer: Watson Ladd Review result: Not Ready Twas the night before Christmas when all through the house someone was desperately trying to get a review done on time. I didn't see anything wrong per se in the draft itself, but I found the capitalization of quantum computer an odd choice. IKEv2 is a complicated protocol, and I am not 100% sure that this draft does what we want it = to: It would be great if someone could check very carefully in some symbolic = model, ala what has been done in TLS. The guidance on sizes seems to rule out = NIST level 1, but not any higher levels: might be worth calling out this = explicitly. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau.. --=20 "Man is born free, but everywhere he is in chains". --Rousseau. ------=_NextPart_000_007C_01D5BB6C.6E143DA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Do you mean the post-quantum cryptography competition = (https://csrc.nist.gov/Projects/post-quantum-cryptography)?

 

That's why I felt confused. The draft isn't concerned with any = post-quantum cryptography stuff,

it uses only well-studied methods of classical cryptography. I don't = think this particular

competition is relevant here.

 

However, taking into consideration Grover's algorithm, it seems that = 128 bit level is the maximum

available for the current off-the-shelf crypto algorithms (I'm not = aware of any widely used cipher with key

length more than 256 bit).

 

Regards,

Valery.

 

 

I'm talking = about the ongoing NIST quantum cryptography competition, which targets = at the lowest level security equivalent to = AES-128.

 

On Wed, Dec 25, 2019 at 10:24 AM Uri Blumenthal <uri@mit.edu> = wrote:

NIST = produces standards and recommendations. US government organizations and = companies doing business with them are usually required to comply. = Organizations and businesses (both US and non-US) that are not bound by = US regulations, often pay attention to what NIST = recommends. 

 

To = repeat myself, it mages sense to add reference to the NIST levels, even = if Watson doesn't insist. ;-)



On Dec 25, 2019, at 12:29, Valery Smyslov = <valery@smyslov.net> = wrote:

=EF=BB=BF

On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal = <uri@mit.edu> = wrote:

NIST = standards are mandatory for a subset of US citizens. But enough of = businesses outside the US pay attention to what NIST says to make adding = the reference relevant and = useful.

 <= /o:p>

It's not = about standards, it's about the competition and the relevant security = level definitions. Not that I feel strongly about it, just a = suggestion..

 

          Then I'm a bit = confused. What competition do you mean?

 

          = Regards,

          = Valery.

 

 

 <= /p>

On Dec 25, 2019, = at 01:52, Valery Smyslov <svan@elvis.ru> = wrote:

=EF=BB=BF =

Hi Watson,

 

thank you for spending your time on this review in Christmas = Eve.

 

The capitalization issue has been already noticed and = fixed.

 

I=E2=80=99m not sure the draft should mention NIST levels, because =

they are relevant mostly for US customers. I think that =

generic recommendations on key sizes are more = appropriate

for this document.

 

Regards,

Valery.

 

Damn = misclick. I meant With Nits.

 <= /o:p>

On Tue, Dec = 24, 2019 at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org> = wrote:

Reviewer: = Watson Ladd
Review result: Not Ready

Twas the night before = Christmas
when all through the house
someone was desperately = trying to get a review done on time.

I didn't see anything wrong = per se in the draft itself, but I found the
capitalization of quantum = computer an odd choice. IKEv2 is a complicated
protocol, and I am not = 100% sure that this draft does what we want it to: It
would be great = if someone could check very carefully in some symbolic model,
ala = what has been done in TLS. The guidance on sizes seems to rule out = NIST
level 1, but not any higher levels: might be worth calling out = this = explicitly.

_______________________________________________
sec= dir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--

____________= ___________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--



--

------=_NextPart_000_007C_01D5BB6C.6E143DA0-- From nobody Wed Dec 25 10:45:34 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F5512002E; Wed, 25 Dec 2019 10:45:31 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 FvJuo-nDUb9m; Wed, 25 Dec 2019 10:45:29 -0800 (PST) Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (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 F315D1200DB; Wed, 25 Dec 2019 10:45:28 -0800 (PST) Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ikBew-0007yp-LF; Wed, 25 Dec 2019 21:45:27 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1ikBev-0001I8-TO; Wed, 25 Dec 2019 21:45:26 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 25 Dec 2019 21:45:24 +0300 Received: from chichi (10.100.100.5) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 25 Dec 2019 21:45:22 +0300 From: Valery Smyslov To: 'Uri Blumenthal' , 'Valery Smyslov' CC: 'Watson Ladd' , , , 'secdir' , References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> In-Reply-To: <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> Date: Wed, 25 Dec 2019 21:45:19 +0300 Message-ID: <008601d5bb53$75269480$5f73bd80$@elvis.ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01D5BB6C.9A750500" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHdvvqKSyXWSys4i9wLZip4/JKSjgI7xNqsp6lKkCA= Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2019/12/25 18:17:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/12/25 14:37:00 #14886745 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 18:45:32 -0000 ------=_NextPart_000_0087_01D5BB6C.9A750500 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Uri, I don't mind referencing NIST levels, but I'd like to first hear = from my co-authors, who are definitely more experienced in cryptography and in NIST levels = than I am :-) =20 =20 NIST produces standards and recommendations. US government organizations = and companies doing business with them are usually required to comply. = Organizations and businesses (both US and non-US) that are not bound by = US regulations, often pay attention to what NIST recommends.=20 =20 To repeat myself, it mages sense to add reference to the NIST levels, = even if Watson doesn't insist. ;-) On Dec 25, 2019, at 12:29, Valery Smyslov wrote: =EF=BB=BF=20 On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal < = uri@mit.edu> wrote: NIST standards are mandatory for a subset of US citizens. But enough of = businesses outside the US pay attention to what NIST says to make adding = the reference relevant and useful. =20 It's not about standards, it's about the competition and the relevant = security level definitions. Not that I feel strongly about it, just a = suggestion.. =20 Then I'm a bit confused. What competition do you mean?=20 =20 Regards, Valery. =20 =20 On Dec 25, 2019, at 01:52, Valery Smyslov wrote: =EF=BB=BF=20 Hi Watson, =20 thank you for spending your time on this review in Christmas Eve. =20 The capitalization issue has been already noticed and fixed. =20 I=E2=80=99m not sure the draft should mention NIST levels, because=20 they are relevant mostly for US customers. I think that=20 generic recommendations on key sizes are more appropriate for this document. =20 Regards, Valery. =20 Damn misclick. I meant With Nits. =20 On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker = wrote: Reviewer: Watson Ladd Review result: Not Ready Twas the night before Christmas when all through the house someone was desperately trying to get a review done on time. I didn't see anything wrong per se in the draft itself, but I found the capitalization of quantum computer an odd choice. IKEv2 is a complicated protocol, and I am not 100% sure that this draft does what we want it = to: It would be great if someone could check very carefully in some symbolic = model, ala what has been done in TLS. The guidance on sizes seems to rule out = NIST level 1, but not any higher levels: might be worth calling out this = explicitly. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 "Man is born free, but everywhere he is in chains". --Rousseau.. ------=_NextPart_000_0087_01D5BB6C.9A750500 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Uri, I don't mind referencing NIST levels, but I'd like to first hear = from my co-authors,

who are definitely more experienced in cryptography and in NIST = levels than I am :-)

 

 

NIST produces standards = and recommendations. US government organizations and companies = doing business with them are usually required to comply. Organizations = and businesses (both US and non-US) that are not bound by US = regulations, often pay attention to what NIST = recommends. 

 

To = repeat myself, it mages sense to add reference to the NIST levels, even = if Watson doesn't insist. ;-)



On Dec 25, 2019, at 12:29, Valery Smyslov = <valery@smyslov.net> wrote:

=EF=BB=BF

On Wed, = Dec 25, 2019 at 3:57 AM Uri Blumenthal <uri@mit.edu> = wrote:

NIST standards are mandatory for a = subset of US citizens. But enough of businesses outside the US pay = attention to what NIST says to make adding the reference relevant and = useful.

 

It's not about standards, it's about the competition = and the relevant security level definitions. Not that I feel strongly = about it, just a suggestion..

 

          Then I'm a bit = confused. What competition do you mean?

 

          = Regards,

          = Valery.

 

 

=EF=BB=BF

Hi Watson,

 

thank you for spending your time on this review in Christmas = Eve.

 

The capitalization issue has been already noticed and = fixed.

 

I=E2=80=99m not sure the draft should mention NIST levels, because =

they are relevant mostly for US customers. I think that =

generic recommendations on key sizes are more = appropriate

for this document.

 

Regards,

Valery.

 

Damn = misclick. I meant With Nits.

 <= /o:p>

On Tue, Dec = 24, 2019 at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org> = wrote:

Reviewer: = Watson Ladd
Review result: Not Ready

Twas the night before = Christmas
when all through the house
someone was desperately = trying to get a review done on time.

I didn't see anything wrong = per se in the draft itself, but I found the
capitalization of quantum = computer an odd choice. IKEv2 is a complicated
protocol, and I am not = 100% sure that this draft does what we want it to: It
would be great = if someone could check very carefully in some symbolic model,
ala = what has been done in TLS. The guidance on sizes seems to rule out = NIST
level 1, but not any higher levels: might be worth calling out = this = explicitly.

_______________________________________________
sec= dir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--

_______________________________________________
secd= ir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wik= i: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



--

------=_NextPart_000_0087_01D5BB6C.9A750500-- From nobody Wed Dec 25 19:00:31 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE641207FB for ; Wed, 25 Dec 2019 19:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsPGfi9xNJ9X for ; Wed, 25 Dec 2019 19:00:25 -0800 (PST) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D0512029C for ; Wed, 25 Dec 2019 19:00:25 -0800 (PST) Received: by mail-pl1-x644.google.com with SMTP id c13so9948647pls.0 for ; Wed, 25 Dec 2019 19:00:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UT7qihSqP28yAPYyfcTc5JMxyS/7Rp0SY0WjFsfuvDw=; b=PNgW6+2F8m1g60izCT+u29Fawh+vsHCOFYWfvU9uXhJSV4BjNJ59qQsmz4zBEP6MfR WjwlcsKDbPGIXXHkktW5VsTcjbF6nz8Ujp5uwKbhOuLtl7MCQt58zd21lda0PtL9HR5b XO1ND+aPk8wk9DoIiSnHrea2uD/DhNgQBOcdyUg6u0jU/hSaBHDRXayGCzL8TWmHYYhI MGnN6N9zv0NzNvbKZE4TilSsbgs/hTsfKT/91K2YKLs2raUfX1mciiB+uvav1op4SLJu Gzq8a6rvhfnC4VHkoEByYbzPhvtOxyJIAcZM5OU5eVFHnHBY7Q7NrEJ1pgxSMWbnz6tb YGVw== 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=UT7qihSqP28yAPYyfcTc5JMxyS/7Rp0SY0WjFsfuvDw=; b=k+h4KcrjZNzpNt4BAYvfEK+5Vo+KSLdgLrlTrBMvB5i/lHW+79k9WuBdfc4LZ+idqc WLaJXwe/RLiPDnzo128eDoRzr1cmVllQc0f+z03mp6ltr6SrbYFKL7yIrFfSzxZ1p9Q1 gQjh2d0WW5vSYZd5qw4dSU4CJJ59Lz5gtLOh7Lh5QF/Kegz/T/fGdF9tMOHdcBKpYQnO wDzLLlwi1NQ41hCfItMDP7wflQPTsuEHZnXdnU2zT3p8TeCX13r35GUJqA/G768Iil/C 6/YEp9FknJC01/aFSaMTqcse85gvP4ES6uKlk3aSgGOrIOKxvtHolrPYlfjCwFxIjnkH PB3w== X-Gm-Message-State: APjAAAV69GskFNnFippvhZ/vDCIh2/8RIuD1/BuTZrUyK0GWJ/HGAoCv ZUQvakmvlAU0Yl9jALNgwmVA8zJj9HLjTKWiKwFC8g== X-Google-Smtp-Source: APXvYqy/dxhUVLANT9z/fs9ln2G4Vhrb4swWfm8yNhEYuPST/xX8jyBAyTRgSm6T7RbGD+yJdONnQVfnRKkha8mc1KU= X-Received: by 2002:a17:90a:660d:: with SMTP id l13mr16234525pjj.23.1577329225000; Wed, 25 Dec 2019 19:00:25 -0800 (PST) MIME-Version: 1.0 References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> In-Reply-To: <157720267698.19361.11750709876624228448@ietfa.amsl.com> From: Yakov Shafranovich Date: Wed, 25 Dec 2019 21:59:49 -0500 Message-ID: To: Tero Kivinen Cc: secdir@ietf.org, last-call@ietf.org, draft-foudil-securitytxt.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2019 03:00:29 -0000 On Tue, Dec 24, 2019 at 10:51 AM Tero Kivinen via Datatracker wrote: > Reviewer: Tero Kivinen > Review result: Has Issues > > This document describes text file located in the web server which can be used > to find the information where to contact in case there is security > vulnerabilities that needs to be disclosed. > > I think this whole idea is BAD, and I do not think we should be publishing this > document at all in this format. > > First of all, the description here says we are providing "machine-parseable and > extensible way for organizations to communicate information about their > security disclosure policies". This file is supposed to be used WHEN there is > security vulnerability found in the site, and in that case the attacker might > have already had a way to modify this file too. The draft is not intended to be used for reporting issues related to an active incident as described in previous discussions. There is a subtle but important difference between incident response vs. vulnerability response. See: https://mailarchive.ietf.org/arch/msg/last-call/ZIftviNdfGbdzruvvffG3KuCcQs https://mailarchive.ietf.org/arch/msg/last-call/YDa3P3SnnXaEPG7Vm8noDUlS38U https://mailarchive.ietf.org/arch/msg/saag/zl7ZFk4esY-O-q6qHLgErVThvbE This is also why section 1 of the draft calls out other guidance such as ISO 29147 and CERT CVD. We can certainly make this more explicit. > Because of this I think > providing machine-parseable format is bad, as this can open new security > vulnerabilities, when some security problem reporting software parses this file > generated by the attacker. Another problem is that even if the parser which > parses this properly verifies the contents, the attacker might have changed the > reporting locations to devnull@example.com or similar address, and if this > report is semi-automatically sent the security reporter might not realize that > he is just sending reports to the attacker. > Regarding the parsing issue, this is true for any machine readable format on the Internet. This is there is extensive discussion in section 6 around these issues. > If this kind of file is needed, I think it should be human readable, and only > shown to the user making the report, and user should then read it and find out > the information where to send the reports. This way there is human in the > process verifying that the information provided by the security.txt file is > sane. > Human triage is recommended as described in section 6.7. We can make this recommendation stronger. As an aside - this has been intended as a lightweight solution which is both parsable and human readable. We didn't want to make a complete arbitrary file format since it wouldn't really have any meaning, and by restricting what can appear in it, it leads implementers towards a reasonable list of things that should and should not be done. On the other hand, we didn't want to put too many things in it since it would make the file to hard to create and use. People are also designing tooling around this. > More detailed comments follows. > > In section 3 it says that "security.txt" SHOULD be placed in the /.well-known/ > path for web properties. Why is this not MUST? For this to be usable standard, > there must be one location which is the authorative for this file. I think this > document needs to say that it MUST the in /.well-known/security.txt. > Documenting the legacy location in /security.txt is ok, and applications might > try to read that also in case the standard "/.well-known/security.txt" is not > found. Also it should tell which file is used if multiple copies of > security.txt is found and their content is different. > The only reason why it says SHOULD now was due the legacy mechanism and my understanding is that using MUST would prohibit the legacy mechanism all together. For multiple copies, the one in .well-known path will take precedence but we can make this more explicit. > Also it seems even this document is not clear whether this is machine-parseable > or not. It says it must be text/plain, and has .txt in file name, which would > indicate it is just text file, not machine-parseable file. If the real reason > is to provide machine-parseable file then .json / .xml or some other really > machine-parseable file would be more suitable. On the other hand it also says > in several places that security researcher SHOULD check this file and verify > that everything looks good and so on. So if human is always needed in the loop, > why even try to make this file machine-parseable. We can use the same format > even if we do not try to make this file machine-parseable as humans also > benefit from having standardized format containing information they need. > Not clear on the concern here - it is intended to be machine readable since humans will build tools around it. The human triage will take place before report submission but there are a lot of other things tools can do prior to that. Additionally, we didn't want people to dump anything they wanted into it. The reason why ".txt" and headers were used since it was meant to be an easy to read format and based off "robots.txt", so anyone can easily create such file without resorting to XML or JSON. > Section 3 also says that "A security.txt file can have an unlimited number of > fields." is bit dangerous when there is good probability that this file is > generated by attacker. Perhaps provide some suitable limits for the size of > this file. As most of the directives only provide pointers to another places, > it might be suitable to limit this file in some sane size, for example saying > that it SHOULD be less than 64kB, and receiver do not need to parse files > larger than 1MB in size. These limits could also be added to section 6.3 if not > here. > Section 6.3 says "extraordinarily large" but we can certainly add a specific size as an example. > Section 3.2 says that "Only the line most immediately preceding a field SHOULD > be associated with that field." meaning that if you have file saying: > > # Our security policy is provided in the separate domain because the external > # company was used to generate it > Policy: https://example.com/security-policy.html > > and this would only associate the 2nd comment line to the Policy field. This > can cause unexpected results for people generating this file, as usually they > assume that you can add multiple lines of comment and all of them relate to the > next field. > This is why it's only a SHOULD and not a MUST. Some context here: https://github.com/securitytxt/security-txt/issues/158 > In section 4.1, why is the redirect processing forbidden only when security.txt > is in top directory, i.e., in that case the redirect will not be followed if it > is not in the same server? Why do we allow redirects from the > /.well-known/security.txt to external domains or servers? I would remove the > 2nd paragraph of 4.1 completely, or rewrite it so it covers all cases where > security.txt is fetched. The security section 6.1 claims that "/" is more > likely to be compromised than "/.well-known/" and thats why redirects are > limited for those, but redirects can also be done in the httpd server > configuration file, and in that case it does not matter whether it redirects > /.well-known/security.txt or /security.txt. Also I do not think there is real > difference which directory is compromised more easily. If attackers can file > files to the filesystem served by the web-server they quite often can do that > for all paths. > The feedback we received on the draft so far has been that people feel that the root directory is more likely to be compromised. On the other hand, the following of redirects has been an important operational requirement at organizations where multiple domains may all be pointing to the same master "security.txt" file located on a primary corporate domain. One solution to address this is to allow redirects in all cases but to add a stronger warning in section 6 regarding where they may lead and that the parsers should be more careful with redirects across domains vs. a redirect on the same domain. We had discussions around this and there was no clear consensus, which is why this compromise is listed. > How is section 4.3 and 4.2 different. The root directory of the internal host > is usually also considered as filesystem, so the rules of 4.2 also cover 4.3. > Also why it is important that security.txt is put to the root directory of the > filesystem only on internal hosts, but not in external hosts? > The filesystem and internal hosts sections are intended for use cases where a researcher has gained access to systems which which might not be web servers. So for example, if an SSH host is compromised, the "well-known" path would make no sense. > This document contains lots of SHOULD etc to the actual users of the files > (security researchers, organizations etc), which is bit funny. It is quite hard > to verify that security researchers really checks the file before using it. It > is good thing to give useful instructions for the users, but making them SHOULD > or SHOULD NOT is not really helpful. > We were basing this on the guidance in RFC 2119, section 6: "In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm" Specifically, "to limit behavior which has potential for causing harm". > In section 6.6 it says we MUST validated the X.509 certificates of the TLS, but > one of the most common security reports I have been doing is a report of the > expired certificates, in which case the certificate of the site serving > security.txt is also expired, thus to be able to find this I need to allow > reading this even when certificate validation failed. > Based on previous discussion on the SAAG list, many members felt very strongly that in today's Internet SSL is a MUST. The feedback we received so far doesn't seem to indicate that reporting expired certificates is all that common. However, we can spell out this use case with additional guidance that if the issue being reported is for SSL itself, researchers should rely on other mechanisms such as the digital signature. > I wonder do we really need Hiring and Acknowledgements directives? I do not > think they are really needed by the security researcher sending reports... >https://mailarchive.ietf.org/arch/msg/last-call/ZIftviNdfGbdzruvvffG3KuCcQs Both are documenting existing usage - they are in active use. Thanks From nobody Thu Dec 26 09:58:07 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECC5120875; Thu, 26 Dec 2019 09:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 wvZmMefd9vAC; Thu, 26 Dec 2019 09:58:03 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 AE890120874; Thu, 26 Dec 2019 09:58:03 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47kHjx5bJLzDJZ; Thu, 26 Dec 2019 18:57:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1577383077; bh=OxVekRl0JUVL+q4ZngfPRFsvm9HIBcbt7IkuCIKpels=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=taUljMVQbIH/7AD1aNNlfD1v9v+9NzaF6x05ABQKT85c1bXy747f3RYMCDOdgV8h9 PEp5xZQH3DXNE16JpuHiCh1fhInIWGLJgwINuS38YTV659slPzYCSpWBShNWWRKU1l MLHkJrM8INgj9OV+jt0aK+VTC1GdFzN6JK9bmmqA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 8ve1096K8jqt; Thu, 26 Dec 2019 18:57:56 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 26 Dec 2019 18:57:56 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 97B576007AD8; Thu, 26 Dec 2019 12:57:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 93B0D65E47; Thu, 26 Dec 2019 12:57:55 -0500 (EST) Date: Thu, 26 Dec 2019 12:57:55 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: "ipsec@ietf.org WG" , 'secdir' , draft-ietf-ipsecme-qr-ikev2.all@ietf.org, last-call@ietf.org In-Reply-To: <008601d5bb53$75269480$5f73bd80$@elvis.ru> Message-ID: References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> <008601d5bb53$75269480$5f73bd80$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2019 17:58:06 -0000 On Wed, 25 Dec 2019, Valery Smyslov wrote: > Uri, I don't mind referencing NIST levels, but I'd like to first hear from my co-authors, > > who are definitely more experienced in cryptography and in NIST levels than I am :-) I don't think mentioning the NIST competition is useful. Per definition, that is incomplete preliminary data. Paul From nobody Thu Dec 26 11:17:00 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C7A1208DF; Thu, 26 Dec 2019 11:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF17GmXSLQq9; Thu, 26 Dec 2019 11:16:50 -0800 (PST) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 F12501208D0; Thu, 26 Dec 2019 11:16:49 -0800 (PST) Received: by mail-qk1-x741.google.com with SMTP id c16so20031873qko.6; Thu, 26 Dec 2019 11:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qXGtJnNdi60A/dOHJaXPws+Azza3mLlKDeaf+JYlNF4=; b=frU/I/YYlEieMaf9gSmKJW+Cwl3bFrosDqe0HBxIYaavLNTt8DuNXDgRf1w7A/n+QF wl7x34zDLL5L4qdSzukQLc4iL1LmcW0ZAM71k6ir6rsk6TosWDZ/BXT7hX9kaBA9Eqya CUqYC7apg049CZpqLZjYHnZt8pyqqDR2j4r/4MldtDZ3wGCIb6T/rWbYVC/4Un5t6MGV b7b8nlZeAfMAQBRVFVx+KY4F+iCsJSZuMvZuOyMSQnsSlOtt0LUSaajY4ALnA3mlm7KN wndCoYT0ySJotVq327G40lPkUhy34oJfDxK3kB8DdLhkk3G6UWPx+czqURUCqwJeYWNW 5P0g== 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=qXGtJnNdi60A/dOHJaXPws+Azza3mLlKDeaf+JYlNF4=; b=FdC9gUxO7hO4sUaSq/G7ZkjSyYNogQXr83yvJvXyO08P/BK9jigIiwjvpwBYssWJxV kJJOl+ubO/9eCvASly4HDHhDc5kbKkpfiI+xOTOneRX+KN0HxSvAEA0M81mIZrs1dOm8 i5RKeSMsoFZY0hBY7b2U41yAG2PKTbiL8r21Wst7LCtw7GbHOHFhKx5HUsbOeL5yk1a4 mVdUPvXCOsWNYc5MoEWlPxGOiVCNJ/29kuQS6Vl3LYIkFaMMjnhvIJalKksGWgj4xKmb xtAD/mKuzq+YFfS76yVasYIkDmbQUtgSA51a3Kh/Ty/P9bmPQP3qkx5zvkoDNrtYIM8L E/7A== X-Gm-Message-State: APjAAAUgFuh0KDvFCxbgccyFH3u9GVJPsGerE1tNfI5pQ1s+W3mOjhBb t1wcrsG/rWUeCbRUl0KY+8H1+yRB X-Google-Smtp-Source: APXvYqw+IiQyfv2eGU4DD/b4+xlpCpk5nXQU/tZoORSDR71WrgQwkp4Kg2YTSSO7oFIeQF5i9YxcRw== X-Received: by 2002:a05:620a:1403:: with SMTP id d3mr30781056qkj.243.1577387808865; Thu, 26 Dec 2019 11:16:48 -0800 (PST) Received: from [10.30.20.14] (pool-108-48-81-61.washdc.fios.verizon.net. [108.48.81.61]) by smtp.gmail.com with ESMTPSA id t2sm9663534qtn.22.2019.12.26.11.16.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Dec 2019 11:16:48 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "R. Atkinson" In-Reply-To: <70FA58C0-97E1-4F76-B88B-A28101A46069@mit.edu> Date: Thu, 26 Dec 2019 14:16:47 -0500 Cc: secdir , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <02c101d5baef$de2cdd90$9a8698b0$@elvis.ru> <70FA58C0-97E1-4F76-B88B-A28101A46069@mit.edu> To: last-call@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2019 19:16:52 -0000 In my experience, many countries other than the US also reference and = use/follow many NIST specifications and many NIST = recommendations/guidance. Also, there is some non-governmental commercial pressure to follow NIST = specifications, recommendations, & guidance. For example, insurers of = financial sector firms often write a requirement for the insured firm to = at least be compliant with listed NIST specifications, recommendations, = & guidance as part of the insurance (or re-insurance) policy for a bank, = stock brokerage, or such like. I am not certain, but I think the legal requirement in the US is limited = to US Federal Government offices/agencies/departments other than the US = Department of Defense. For example, I do not think there are legal = requirements for commercial firms or individual states to follow NIST = specifications, recommendations, & guidance. My understanding, possibly = confused, is that US DoD writes its own guidance, at least on = cryptographic matters. Yours, Ran > On Dec 25, 2019, at 06:57, Uri Blumenthal wrote: >=20 > NIST standards are mandatory for a subset of US citizens. But enough = of businesses outside the US pay attention to what NIST says to make = adding the reference relevant and useful. >=20 >> On Dec 25, 2019, at 01:52, Valery Smyslov wrote: >>=20 >> =EF=BB=BF >> Hi Watson, >> =20 >> thank you for spending your time on this review in Christmas Eve. >> =20 >> The capitalization issue has been already noticed and fixed. >> =20 >> I=E2=80=99m not sure the draft should mention NIST levels, because=20 >> they are relevant mostly for US customers. I think that=20 >> generic recommendations on key sizes are more appropriate >> for this document. >> =20 >> Regards, >> Valery. >> =20 >> Damn misclick. I meant With Nits. >> =20 >> On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker = wrote: >> Reviewer: Watson Ladd >> Review result: Not Ready >>=20 >> Twas the night before Christmas >> when all through the house >> someone was desperately trying to get a review done on time. >>=20 >> I didn't see anything wrong per se in the draft itself, but I found = the >> capitalization of quantum computer an odd choice. IKEv2 is a = complicated >> protocol, and I am not 100% sure that this draft does what we want it = to: It >> would be great if someone could check very carefully in some symbolic = model, >> ala what has been done in TLS. The guidance on sizes seems to rule = out NIST >> level 1, but not any higher levels: might be worth calling out this = explicitly. >>=20 >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>=20 >>=20 >> --=20 >> "Man is born free, but everywhere he is in chains". >> --Rousseau. >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Thu Dec 26 20:13:41 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502B712004E; Thu, 26 Dec 2019 20:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fmICZQ7a; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=rz8iZvX4 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 lgT5BsYRB7kO; Thu, 26 Dec 2019 20:13:28 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D7812001E; Thu, 26 Dec 2019 20:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7297; q=dns/txt; s=iport; t=1577420008; x=1578629608; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6FX2rp36r9enI/zdOktm4/aGXrKhGM9lZnYiobw8OQo=; b=fmICZQ7aWA1ftwZDRntCWbZgvw9kOugYI6J+T21ZEaHgZVqeLBdHenSt Ff9nYK8hQyINromh4zljMWtxip2WA0cOG53VeEXX838rhi2dYIgSb4mlf Qv2U3ex87fk9dq70aDUuHpQm29mINAbbzrGoo/Kl7SAZba02z4o+9mTIJ 4=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AvnUnOhHt9Ou/EocxSBDg0Z1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eebpZikiFcJLfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAACqgwVe/4MNJK1kHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoFAQELAYFTUAVsKy0gBAsqh04DiniCX5gJgS6BJANUAgcBAQE?= =?us-ascii?q?JAwEBGAsKAgEBhEACgh8kNgcOAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECAQE?= =?us-ascii?q?BEAsjAQEsCwEEBwQCAQgRBAEBHhECJQsdCAIEAQ0FCAYUgwGBeU0DDhEPAQI?= =?us-ascii?q?Mn1wCgTiIYYIngn4BAQWEfxiCBQcDBoE2AYFSikYagUE/gRFHgh4uPoJkAQG?= =?us-ascii?q?BZRWDK4IslxmXfgqCNINhgjeGVolGmleOUppWAgQCBAUCDgEBBYFZAjCBWHA?= =?us-ascii?q?VO4JsUBgNjRI4gzuFFIU/dIEokiYBAQ?= X-IronPort-AV: E=Sophos;i="5.69,361,1571702400"; d="p7s'?scan'208";a="391285807" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Dec 2019 04:13:25 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xBR4DPb8012752 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Dec 2019 04:13:25 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 26 Dec 2019 22:13:24 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 26 Dec 2019 22:13:23 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 26 Dec 2019 23:13:23 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iPLfbFYCFMY80Dfh7KTX/xbDpnOhQ+sAVPRQEYjjbUNv7SijSVmAeOFtEFSB4mZoSnTZDXtdwdVyNlcjkHclb10yq2bNOm5aHxcsJCthC5yVK9TcGblPACJqNH6azht3DLJ2t7O6Fdp5Wr9MWS6LFRCKKB50EUtsjilr94jGfq9ctKrUJVYf2lYGMPuFBLfsao5jT5KcyOyvdH4lQU5jU3tzTc0VFGx/KlERnmZcpQhRXIKiU0OhpFzhiwrXbMZScF20xbmnqjVcXk8B6CwQi4GbGVDu5oTlL335F3SAqwWiVIm1RICJN3bQLMgBKvoXJoW+pob+HVHIpex+8HsnSw== 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=lWR6Lfx8rnN3P01Q11KHEuu4VxOm+krUPqUioIlaFKc=; b=iKIoClP3bmiJijYsZGzokhC+m0EXbgfdoh9ief0kTK5u0MTY9G71q/QAVeA6r4JTvUotouCcCXpdyUN0VVF+VtNZ5y8oDQZcAgrLPrj7IAXwo65FacYToXmtFUxWneZLR4guLlaxFelkxliyGWOBlVclVIPg2p9hel+uFtryWVjVwfsyd07sGgjn3FqxDM0WEwYerDHd2H5yyXnQBFc0SGIk9+LGEBVmVnU3gTsx5VlRqw4Dr4i+bqLnDJBlO78bM/KBcSNBhxeaAKbda5DE8N9pfvOImh0Ht9BopK4kJwkSoWl34Nec62VsgPKOZcI99JrWkZ63m4rypxHi0CUz1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lWR6Lfx8rnN3P01Q11KHEuu4VxOm+krUPqUioIlaFKc=; b=rz8iZvX4j2YJ3mUFNDr6qgNlPJdKS15TqdKlhbwffPgW/WsrBEJM+qVfh5uyfLuaQt7D3/zOW4N27JlgcNh3lsqtPc59Zp3i/TVVtZzy9ZHM3ujj6vYxMYcooaS16nCjDuv5PGAqOZKH3PAkkdtgulxJV/0rXBC+LyPHG101Y3g= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2563.namprd11.prod.outlook.com (52.135.244.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Fri, 27 Dec 2019 04:13:23 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2581.007; Fri, 27 Dec 2019 04:13:23 +0000 From: "Panos Kampanakis (pkampana)" To: Paul Wouters , Valery Smyslov CC: "ipsec@ietf.org WG" , "last-call@ietf.org" , "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" , "'secdir'" Thread-Topic: [IPsec] [Last-Call] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 Thread-Index: AQHVvBYgaemvAijUV0anuRMjqrab/afNX7Lw Date: Fri, 27 Dec 2019 04:13:22 +0000 Message-ID: References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> <008601d5bb53$75269480$5f73bd80$@elvis.ru> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1003::61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54f4d2da-3812-489a-09c7-08d78a831d32 x-ms-traffictypediagnostic: BN7PR11MB2563: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(346002)(366004)(376002)(13464003)(189003)(199004)(86362001)(52536014)(4326008)(66616009)(66946007)(66476007)(66556008)(66446008)(64756008)(186003)(76116006)(2906002)(5660300002)(71200400001)(33656002)(316002)(81156014)(9686003)(81166006)(55016002)(54906003)(8676002)(8936002)(7696005)(478600001)(110136005)(53546011)(6506007)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2563; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oRtAfOzVSJjzMxKXMNvvaBekBzUupkLCwkXNNJ3UYJ3OaZ08pWYTbvKOfTmP6xRUnePBDy6JIEWjZWw/SXkNXqxnuuhS6q6/BGyJd1JCs5jiRsQb4MrfWJPhGQ9YGfxooS5fvAClJLV5m3v0UTAIYYv828BXvCRPjWzWBWwB6xOvGMEHo11zwK6bg1K5hKPdhpPcRnGqn5Sz06Cxn3aX6HURhko0Jgh8forXufvT19MNMLQnmGL27bsd02/juz3GK6AZh5LXBNxQp9EA0xEb3oXVKVH2EH81QmdAINBPisETBkJGMyAwodyKbX7L0W5rkfOOo/whTE+A8RUjuTeY+S+tyOMTikmrcenou+xYGJiDuZXf0U+FdKODlH8i7E3cTEcM1eiiyj/SeQ9T0K87xj01qw4IvVOloSuJbJArO3rxczbkuKV9+4P//ec3Y+yBtZp7gra7sj+3haHx9gMbjt3l0okgY92AMlZFjVcUQGoSpYwz69xdjvO4CblEj9BjhI4hewAEO9p76Zotdv2puyNzSeIcUJfwVo3Ni+TxSyk= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0026_01D5BC42.103C7A40" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 54f4d2da-3812-489a-09c7-08d78a831d32 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2019 04:13:22.7873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qfTBsDZer67e0xoS0Rp1eu04xcpM1m239WscX4H99KAwbdA4nUT+PmFG+C+sTwq3ItXYBjXnGkiydjAwifcdCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2563 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [secdir] [IPsec] [Last-Call] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 04:13:30 -0000 ------=_NextPart_000_0026_01D5BC42.103C7A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To make sure we mention the NIST PQ Level categorization (that will not change as the NIST PQ Project progresses), I was thinking we could add something in the Sec Considerations section like [...] Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. -----Original Message----- From: IPsec On Behalf Of Paul Wouters Sent: Thursday, December 26, 2019 12:58 PM To: Valery Smyslov Cc: ipsec@ietf.org WG ; last-call@ietf.org; draft-ietf-ipsecme-qr-ikev2.all@ietf.org; 'secdir' Subject: Re: [IPsec] [Last-Call] [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09 On Wed, 25 Dec 2019, Valery Smyslov wrote: > Uri, I don't mind referencing NIST levels, but I'd like to first hear > from my co-authors, > > who are definitely more experienced in cryptography and in NIST levels > than I am :-) I don't think mentioning the NIST competition is useful. Per definition, that is incomplete preliminary data. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0026_01D5BC42.103C7A40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTkxMjI3MDQxMzIwWjAvBgkqhkiG9w0BCQQxIgQgJ9TmeFBRkrJayuKajW8iJaw0h5gA1Vf/ mmrVOEZNMn0wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA SQM4uTpJn2c6HtBKopq47Zxs6pfvfHRELdoRjYcb75FcfA6Pq2QZbbJGatOAWrDE8BXBJjhCdLxZ 8MGdazYATcvDPpTZKjs1xIsTqGGLipYCj6f0hErHarNsJ8bmYIMI/SgtAhDckWMm9TPSoyClBREp AYr+b1eA7IL3NL/Ug7FNGPnEycYv6Cky8igI9QnQySbIFqlvOTmg3RnDr7wVrhfoYqxVdcynR25z CBREa3ICuEhXWHpSx5+Pp9K13+S27kDBUrkLuIaErDB20F4aahSthYO7QBa2Uf4RoJu1WP6m9EJc 6UD1TM/U0guGe66PPARrUrQoEeN/6TWg8cL7zQAAAAAAAA== ------=_NextPart_000_0026_01D5BC42.103C7A40-- From nobody Fri Dec 27 15:34:54 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4E31200CE; Fri, 27 Dec 2019 15:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_FILL_THIS_FORM_SHORT=0.01] 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 jwrop5BGKKrC; Fri, 27 Dec 2019 15:34:42 -0800 (PST) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1491200B6; Fri, 27 Dec 2019 15:34:40 -0800 (PST) Received: by fireball.acr.fi (Postfix, from userid 15204) id DBA9F25C1D05; Sat, 28 Dec 2019 01:34:36 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24070.38156.658126.30539@fireball.acr.fi> Date: Sat, 28 Dec 2019 01:34:36 +0200 From: Tero Kivinen To: Yakov Shafranovich Cc: secdir@ietf.org, last-call@ietf.org, draft-foudil-securitytxt.all@ietf.org In-Reply-To: References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 43 min X-Total-Time: 51 min Archived-At: Subject: Re: [secdir] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 23:34:47 -0000 Yakov Shafranovich writes: > On Tue, Dec 24, 2019 at 10:51 AM Tero Kivinen via Datatracker > wrote: > > Reviewer: Tero Kivinen > > Review result: Has Issues > > > > This document describes text file located in the web server which can be used > > to find the information where to contact in case there is security > > vulnerabilities that needs to be disclosed. > > > > I think this whole idea is BAD, and I do not think we should be publishing this > > document at all in this format. > > > > First of all, the description here says we are providing "machine-parseable and > > extensible way for organizations to communicate information about their > > security disclosure policies". This file is supposed to be used WHEN there is > > security vulnerability found in the site, and in that case the attacker might > > have already had a way to modify this file too. > > The draft is not intended to be used for reporting issues related to > an active incident as described in previous discussions. There is a > subtle but important difference between incident response vs. > vulnerability response. See: > https://mailarchive.ietf.org/arch/msg/last-call/ZIftviNdfGbdzruvvffG3KuCcQs > https://mailarchive.ietf.org/arch/msg/last-call/YDa3P3SnnXaEPG7Vm8noDUlS38U > https://mailarchive.ietf.org/arch/msg/saag/zl7ZFk4esY-O-q6qHLgErVThvbE > > This is also why section 1 of the draft calls out other guidance such > as ISO 29147 and CERT CVD. We can certainly make this more explicit. > > > Because of this I think > > providing machine-parseable format is bad, as this can open new security > > vulnerabilities, when some security problem reporting software parses this file > > generated by the attacker. Another problem is that even if the parser which > > parses this properly verifies the contents, the attacker might have changed the > > reporting locations to devnull@example.com or similar address, and if this > > report is semi-automatically sent the security reporter might not realize that > > he is just sending reports to the attacker. > > > > Regarding the parsing issue, this is true for any machine readable > format on the Internet. This is there is extensive discussion in > section 6 around these issues. Yes, but this is data that I would always assume has been modified by attacker. The difference is not large, but it is similar than what is required by firewall code versus networking stack of the normal operating system. > > If this kind of file is needed, I think it should be human readable, and only > > shown to the user making the report, and user should then read it and find out > > the information where to send the reports. This way there is human in the > > process verifying that the information provided by the security.txt file is > > sane. > > > > Human triage is recommended as described in section 6.7. We can make > this recommendation stronger. If human is always recommended when do you think this would be used automatically and where would the machine-parseable aspect of this document be required? I mean we can keep the exactly same format, but just remove all text relating to the machine-parseable from the draft. The document will still stay as machine-parseable as it was before, but it would give much more emphasis that this do require human interaction. > As an aside - this has been intended as a lightweight solution which > is both parsable and human readable. We didn't want to make a complete > arbitrary file format since it wouldn't really have any meaning, and > by restricting what can appear in it, it leads implementers towards a > reasonable list of things that should and should not be done. On the > other hand, we didn't want to put too many things in it since it would > make the file to hard to create and use. People are also designing > tooling around this. I am bit concerned about the need for tooling for this file. Why do you think we need tooling. Is there really going to be so many vulnerabilities found in general that such tooling is required. My take would be that security researcher would simply cut & paste the contact information from this file and use that, and that is the tooling required. Or directly click the link in policy keyword to read that ect. > > More detailed comments follows. > > > > In section 3 it says that "security.txt" SHOULD be placed in the /.well-known/ > > path for web properties. Why is this not MUST? For this to be usable standard, > > there must be one location which is the authorative for this file. I think this > > document needs to say that it MUST the in /.well-known/security.txt. > > Documenting the legacy location in /security.txt is ok, and applications might > > try to read that also in case the standard "/.well-known/security.txt" is not > > found. Also it should tell which file is used if multiple copies of > > security.txt is found and their content is different. > > > > The only reason why it says SHOULD now was due the legacy mechanism > and my understanding is that using MUST would prohibit the legacy > mechanism all together. No. Those legacy mechanisms could not then claim to be following this RFC to be until move the file location to correct place. Saying that the file MUST be at /.well-known/security.txt does not forbid having that file in other locations too, and does not have any effect on the legacy systems. > For multiple copies, the one in .well-known path will take precedence > but we can make this more explicit. I did not find that text at all, so yes, make it more explicit. > > Also it seems even this document is not clear whether this is machine-parseable > > or not. It says it must be text/plain, and has .txt in file name, which would > > indicate it is just text file, not machine-parseable file. If the real reason > > is to provide machine-parseable file then .json / .xml or some other really > > machine-parseable file would be more suitable. On the other hand it also says > > in several places that security researcher SHOULD check this file and verify > > that everything looks good and so on. So if human is always needed in the loop, > > why even try to make this file machine-parseable. We can use the same format > > even if we do not try to make this file machine-parseable as humans also > > benefit from having standardized format containing information they need. > > > > Not clear on the concern here - it is intended to be machine readable > since humans will build tools around it. The human triage will take > place before report submission but there are a lot of other things > tools can do prior to that. Additionally, we didn't want people to > dump anything they wanted into it. What kind of other things tools can do prior to that? What is expected to happen with those tools. Why do we even need the tools. What kind of software you assume will be reading this file and act based on it? > The reason why ".txt" and headers were used since it was meant to be > an easy to read format and based off "robots.txt", so anyone can > easily create such file without resorting to XML or JSON. Yes, I can understand it being .txt file if it human readable. If it is supposed to be machine readable, then it will most likely be machine generated also, meaning any proper machine parseable format would be better than this one. Robots.txt is very bad example, as that file is always machine readable, there is no reason for humans to read that ever. That file should be in some more sane format than .txt file. To summarize, I think this document should only be meant for humans to read, and because of that I think we should keep the format and the .txt format, but we should remove the mentions in the draft that suggest that this is read by tools or to be machine-parseable. Of course it will still stay machine-parseable as same format and same ABNF will be used, but as this is not intended to be machine readable, we do not need to emphasize that. > > Section 3 also says that "A security.txt file can have an unlimited number of > > fields." is bit dangerous when there is good probability that this file is > > generated by attacker. Perhaps provide some suitable limits for the size of > > this file. As most of the directives only provide pointers to another places, > > it might be suitable to limit this file in some sane size, for example saying > > that it SHOULD be less than 64kB, and receiver do not need to parse files > > larger than 1MB in size. These limits could also be added to section 6.3 if not > > here. > > > > Section 6.3 says "extraordinarily large" but we can certainly add a > specific size as an example. Different people do have different meaning of extraordinary large. Some people would consider my examples of 64kB/1MB way too big, and some would consider them still tiny (when normal web page to download is several tens of magabytes then 64kB seems like very small). Yes, I think it would be good idea to provide some specific limits. > > Section 3.2 says that "Only the line most immediately preceding a field SHOULD > > be associated with that field." meaning that if you have file saying: > > > > # Our security policy is provided in the separate domain because the external > > # company was used to generate it > > Policy: https://example.com/security-policy.html > > > > and this would only associate the 2nd comment line to the Policy field. This > > can cause unexpected results for people generating this file, as usually they > > assume that you can add multiple lines of comment and all of them relate to the > > next field. > > > > This is why it's only a SHOULD and not a MUST. Some context here: > https://github.com/securitytxt/security-txt/issues/158 This whole issue goes away if we do not assume this is machine-readable but assume it is read by human. Human can very easily associate comments to suitable keywords. I would simply remove the whole text talking about comment and associated fields. > > In section 4.1, why is the redirect processing forbidden only when security.txt > > is in top directory, i.e., in that case the redirect will not be followed if it > > is not in the same server? Why do we allow redirects from the > > /.well-known/security.txt to external domains or servers? I would remove the > > 2nd paragraph of 4.1 completely, or rewrite it so it covers all cases where > > security.txt is fetched. The security section 6.1 claims that "/" is more > > likely to be compromised than "/.well-known/" and thats why redirects are > > limited for those, but redirects can also be done in the httpd server > > configuration file, and in that case it does not matter whether it redirects > > /.well-known/security.txt or /security.txt. Also I do not think there is real > > difference which directory is compromised more easily. If attackers can file > > files to the filesystem served by the web-server they quite often can do that > > for all paths. > > The feedback we received on the draft so far has been that people feel > that the root directory is more likely to be compromised. On the other > hand, the following of redirects has been an important operational > requirement at organizations where multiple domains may all be > pointing to the same master "security.txt" file located on a primary > corporate domain. I can see the reason for redirects, I do not really see that big difference of root or /.well-known directories. In both cases to make redirect you usually need to make .htaccess file in that directory or to change the configuration of the web server. > One solution to address this is to allow redirects in all cases but to > add a stronger warning in section 6 regarding where they may lead and > that the parsers should be more careful with redirects across domains > vs. a redirect on the same domain. We had discussions around this and > there was no clear consensus, which is why this compromise is listed. If this is human readable file format then the tool to fetch this will be web browser or wget or similar. Those will follow readirects automatically and what we say here does not really matter. One of the problem with redirects is that Canonical is field that can only appear once, thus there is no way to verify that this https://example.com/security.txt file should really be something that should be used when you go there with redirect from https://signin.example.com/security.txt. If there could be multiple Canonical fields then you could list all the possible locations where this same file could be found, while all of them redirect them to this location. > > How is section 4.3 and 4.2 different. The root directory of the internal host > > is usually also considered as filesystem, so the rules of 4.2 also cover 4.3. > > Also why it is important that security.txt is put to the root directory of the > > filesystem only on internal hosts, but not in external hosts? > > > > The filesystem and internal hosts sections are intended for use cases > where a researcher has gained access to systems which which might not > be web servers. So for example, if an SSH host is compromised, the > "well-known" path would make no sense. Yes, but then I would assume that the security.txt would be in the root directory of that machine, i.e., the section 4.2 would be the one that applies. So I would simply just remove section 4.3, as I think 4.2 already covers that. > > This document contains lots of SHOULD etc to the actual users of the files > > (security researchers, organizations etc), which is bit funny. It is quite hard > > to verify that security researchers really checks the file before using it. It > > is good thing to give useful instructions for the users, but making them SHOULD > > or SHOULD NOT is not really helpful. > > > > We were basing this on the guidance in RFC 2119, section 6: > "In particular, they MUST only be used where it is actually required > for interoperation or to limit behavior which has potential for > causing harm" > > Specifically, "to limit behavior which has potential for causing harm". How are you going to verify that security researches and organzations are going to follow your SHOULDs? I have received question from the customer (from Japan) where they listed all SHOULDs, MUSTs, and MUST NOTs in the RFC and required to know which line numbers of our code implement those requirements. For SHOULDs and MUSTs it sometimes is easy, but for "Implementation MUST NOT do XXX" is bit harder to pinpoint the exact line numbers NOT doing XXX... If you have SHOULD or MUSTs which cannot be verified at all, or which depend on the humans, they are always something that is problematic. For example in IPsec we tried to be very clear that we do not for example say that users MUST NOT configure their IPsec to use DES, we said implementations MUST not implement DES. There is no point of saying for example this: Organizations SHOULD ensure that information in this file and any referenced resources such as web pages, email addresses and telephone numbers are kept current, are accessible, controlled by the organization, and are kept secure. Using SHOULD there does not help at all. Changing that to say "Organizations needs to ensure that ..." would meant that person who is implementing this will not try to implement that SHOULD... > > In section 6.6 it says we MUST validated the X.509 certificates of the TLS, but > > one of the most common security reports I have been doing is a report of the > > expired certificates, in which case the certificate of the site serving > > security.txt is also expired, thus to be able to find this I need to allow > > reading this even when certificate validation failed. > > > > Based on previous discussion on the SAAG list, many members felt very > strongly that in today's Internet SSL is a MUST. The feedback we > received so far doesn't seem to indicate that reporting expired > certificates is all that common. However, we can spell out this use > case with additional guidance that if the issue being reported is for > SSL itself, researchers should rely on other mechanisms such as the > digital signature. I have reported expired certificates twice this year already, and both of them did got fixed in few days after my email... With Lets Encrypt this is going to be more and more common in the future. > > I wonder do we really need Hiring and Acknowledgements directives? I do not > > think they are really needed by the security researcher sending reports... > >https://mailarchive.ietf.org/arch/msg/last-call/ZIftviNdfGbdzruvvffG3KuCcQs > > Both are documenting existing usage - they are in active use. As this is extensible format and humans known how to skip over unknown fields anyways it does not matter whether they are in use or not. Do we really need those fields in the format. What benefits they have? What use they are for the security researcher using this file? Yes, he could use the Acknowledgements directive to verify that his report is properly acknowledged in that file, but hiring should most like use some other channels than security.txt. Especially the hiring directive information will most likely be out of date very quickly so it does not go very well with the requirement that organations SHOULD keep it up to date.... -- kivinen@iki.fi From nobody Fri Dec 27 16:22:36 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4441F1200E5; Fri, 27 Dec 2019 16:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 tfCUOoXVo7GB; Fri, 27 Dec 2019 16:22:28 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 D8B4B1200CE; Fri, 27 Dec 2019 16:22:27 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47l4C42XKCzFn6; Sat, 28 Dec 2019 01:22:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1577492544; bh=2fgxjAgU2GmwSJpzgrHsXUFAZ9OYWWKPiUYP07I/+HE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=blgTUmDU992my92fTbgWiWE70od+Ktc1F4tuhJEL5k6rtX/xzVkfqj0XBiu3Mn5xT SQ1hYZcx2yUvVWPeXivte71rLAOzwyP+YQyGNjG6SMpK3YTHOGNyH7oxeKweIXOxQy NbOebR9BoKUG8tarSqQcj44e1QjifwW4twC6r9TU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Ho75YIHVGoAj; Sat, 28 Dec 2019 01:22:22 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 28 Dec 2019 01:22:22 +0100 (CET) Received: from [193.111.228.74] (unknown [193.111.228.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id A871960015B8; Fri, 27 Dec 2019 19:22:20 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16G102) In-Reply-To: <24070.38156.658126.30539@fireball.acr.fi> Date: Fri, 27 Dec 2019 19:22:20 -0500 Cc: Yakov Shafranovich , last-call@ietf.org, draft-foudil-securitytxt.all@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <427E1372-59C7-4304-9562-2C93DDDD05AD@nohats.ca> References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <24070.38156.658126.30539@fireball.acr.fi> To: Tero Kivinen Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 00:22:29 -0000 > On Dec 27, 2019, at 18:34, Tero Kivinen wrote: >=20 >=20 > Especially the hiring directive information will most likely be out of > date very quickly so it does not go very well with the requirement > that organations SHOULD keep it up to date.... It is worse. A company MUST always be seen as growing, so even if they are n= ot hiring, some bogus information will be provided here, similar to the =E2=80= =9Cmandatory=E2=80=9D statement on their website regarding hiring. Paul >=20 From contact@edoverflow.com Sat Dec 28 05:02:13 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFF9120026; Sat, 28 Dec 2019 05:02:13 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsYKKAkTOa1D; Sat, 28 Dec 2019 05:02:11 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 95438120020; Sat, 28 Dec 2019 05:02:11 -0800 (PST) Received: from umb ([146.90.55.225]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MLyaj-1j2Rb239sX-00HtVD; Sat, 28 Dec 2019 14:01:58 +0100 Date: Sat, 28 Dec 2019 14:01:52 +0100 From: Edwin Foudil To: Tero Kivinen Cc: Yakov Shafranovich , "=?utf-8?Q?secdir=40ietf.org?=" , "=?utf-8?Q?last-call=40ietf.org?=" , "=?utf-8?Q?draft-foudil-securitytxt.all=40ietf.org?=" Message-ID: <02D86F64-0AC0-43DB-8EDB-0B1938713A81@getmailspring.com> In-Reply-To: <24070.38156.658126.30539@fireball.acr.fi> References: <24070.38156.658126.30539@fireball.acr.fi> X-Mailer: Mailspring MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5e075240_1f65af52_b6c" X-Provags-ID: V03:K1:DUIQhOkaUv8IweLUmFx3aWuGgjrUTil+5/Dwxp6qlRvIsWHi7h6 b7QeXtDFV3e4+8ywgWbJnenHdgcMPvjRQ6fvANIOCTFcyIK4hDUsZ3muKyAS6r5yT2mkpAD Y9iXUpjhmPTZqT7AOycvfKV2yM9o+GwS6e2xwWrZiaEy02ix4vmZXu1mGg1zcxUAESXNoNf EDatR6eOjauVQYdR3p5Gw== X-UI-Out-Filterresults: notjunk:1;V03:K0:b9blBROAWes=:Dw/a4J6eLEGoIluKIsyFRi bQ12pu1hR317J9D0vXTUkijfIz98f9utYrrSq+By0WzX9dpthokGF+f1PTVBbfZLy24QuJcl8 sZBVTh/kbG5+220wxBAeSkE4v2IlhD8eKjVs/xo2fuKPTnGFh8PMVmGd2odlHk56Pjx8AzuSn OoAny7zcL41hSlwNTTnDvVJawZvBzYRMcpV0TfDn9u0B0BQp8DtUcxICpy/JU6DsJW74dWXXU Bt8Pn41i2E/rIRDJJYMhG3mNYGaoOCwYTDtFpi1xh6pFPZ2MaPV+nPFt9ud9JvuGbLyNDuykU wbA3IY0Uy7vIIn2jjjp7Nj57IqdiSIbXOuvusdau1c/7HqTuiPfSfSy5CPVt5p1pkkR2hsdft goINlj8d52zPuZNIXraQWkoMK1znShN74AoiY0xECJk8ITvPPA8TSiInM1E4YJ3182Wl9Xwz9 KTIa/YANEAcibGBZ44yhCkJbl/KRYqvVrH5JqQ73j6UkrF21ns83oneTjkhMwaDjeO/zAOC63 bylipknX8HnAre4J0UjUQrKjNAzMY7ze8V7qDQZS0Q2jTtG7k8B3JqJUQgxnC3hsYApKEeBsX zn/N1bsF7sEOq01W4gnCdt1ibKXrdhZklpk/4Qb24banuQOd18SIabFRAWhE63aDbGU5hQKPz cpYFXcVHXZMXHXVniK35RBe4102ECwTixNR1sKEBCqphBKWnSLJNTQWgvaWozEYFo2MDtQrpi lHeicR4EOa38v/FGM5Kw596+AuIaKXjsHg7X6uDF1Jqj0d4UgOt6rH21WQwHSFL7PbjFFHwA4 urhfBHjhM8sXKrWsX1K9me+ZkU0S6zloj1ZVDle4XqxJu/s7jrHtVlzzQxzs6SjfMo9XOLN4O F1D1vrQDHmdTXDp4p0zuWNLftRz6U++rWdDfQKvgc= Archived-At: Subject: Re: [secdir] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 13:35:51 -0000 --5e075240_1f65af52_b6c Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat Dec 28, 2019 at 1:34 AM Tero Kivinen wrote: > I am bit concerned about the need for tooling for this file. Why do > you think we need tooling. Is there really going to be so many > vulnerabilities found in general that such tooling is required. My > take would be that security researcher would simply cut & paste the > contact information from this file and use that, and that is the > tooling required. Or directly click the link in policy keyword to read > that ect. There is already a demand for tooling by the public; this was not necessarily something we (the authors) came up with. Some of the published tooling developed by members of the public can be found here: https://securitytxt.org/projects. Also, as others have already pointed out in this mailing list, Shodan (https://www.shodan.io/) and disclose.io (https://disclose.io/) index contact information from security.txt files. Since there is already tooling out there, I think it is safe to say that people do not necessarily want to extract information from a security.txt file manually. > I can see the reason for redirects, I do not really see that big > difference of root or /.well-known directories. > > In both cases to make redirect you usually need to make .htaccess file > in that directory or to change the configuration of the web server. I can back our statements up with real-world cases. I am a bug bounty hunter and actively go after namespace attacks. This attack vector abuses the fact that most applications with users reserve the top-level directory for usernames. Some of my findings include redirects to external pages from /. In addition, all of the cases I have found did not require access to the web server itself. Please refer to https://edoverflow.com/2018/logic-flaws-in-wot-services/ for a case demonstrating this attack vector in practice. Applications that use the top-level directory for usernames can be vulnerable to namespace attacks. But I have yet to come across a compromised /.well-known/ directory: websites usually do not allow dot-prefix or directory-like usernames. - Ed --5e075240_1f65af52_b6c Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On Sat Dec 28, 2019 at 1:34 AM Tero Kivinen wrote:
> I = am bit concerned about the need for tooling for this file. Why do
> you think we need tooling. Is there really going to be so many
> vulnerabilities found in general that such tooling is requir= ed. My
> take would be that security researcher would simply= cut & paste the
> contact information from this file an= d use that, and that is the
> tooling required. Or directly = click the link in policy keyword to read
> that ect.
There is already a demand for tooling by the public; this was not = necessarily something we (the authors) came up with. Some of the publishe= d tooling developed by members of the public can be found here: https://s= ecuritytxt.org/projects.


Since there is already tooling out there, I think i= t is safe to say that people do not necessarily want to extract informati= on from a security.txt file manually.

> I can see the re= ason for redirects, I do not really see that big
> differenc= e of root or /.well-known directories.
>
> In = both cases to make redirect you usually need to make .htaccess file
=
> in that directory or to change the configuration of the web ser= ver.

I can back our statements up with real-world cases. I= am a bug bounty hunter and actively go after namespace attacks. This att= ack vector abuses the fact that most applications with users reserve the = top-level directory for usernames. Some of my findings include redirects = to external pages from /<username>. In addition, all of the cases I= have found did not require access to the web server itself.

Please refer to https://edoverflow.com/2018/logic-flaws-in-wot-services= / for a case demonstrating this attack vector in practice.
= Applications that use the top-level directory for usernames can be vulner= able to namespace attacks. But I have yet to come across a compromised /.= well-known/ directory: websites usually do not allow dot-prefix or direct= ory-like usernames.

- Ed

--5e075240_1f65af52_b6c-- From nobody Sat Dec 28 07:33:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA06120111; Sat, 28 Dec 2019 07:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWgP-tueDrzb; Sat, 28 Dec 2019 07:33:25 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C40912010F; Sat, 28 Dec 2019 07:33:25 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xBSFVtTh027356; Sat, 28 Dec 2019 15:33:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Osn/c9kuqy3+8Mw6HCSFojDLSwswMIB3I7AH9I9J8Pg=; b=VzvyN0rd96kc0FEqk/nPwBDFDqP6FqaXTK2ol7nw7UYJufDQSz8ALogVrQhnVQ/zJ0NT u20vE+Gh4xfOwnDketPTG4hpkV9q3mW0EPobgqIWvMxiIvB/Q4dPMAHAaH01KfAyprH2 BUnY5qvQA37YdSCffwxiwnkqPrsbQCFZyIOmQH06yoPTYyBJSGpwsi8dOx87oIkwhmvE F6u6OeF2zcp9aVEbejDj3Fc+BPZvxQtOy6B08z3SBNbti6IHHl8yw8ZYUSgGiQ5hF9Kc xvcd1fog23QC7E0YiQRMNJDbxK62iTYe8tiycXm16G3lpr6eDNXjZmUb3L4mnf26oU6h BQ== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2x5yf91gps-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 28 Dec 2019 15:33:23 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xBSFIadD018372; Sat, 28 Dec 2019 07:33:22 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint5.akamai.com with ESMTP id 2x65war6b2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 28 Dec 2019 07:33:22 -0800 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 28 Dec 2019 10:33:21 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Sat, 28 Dec 2019 10:33:21 -0500 From: "Salz, Rich" To: Tero Kivinen , Yakov Shafranovich CC: "last-call@ietf.org" , "draft-foudil-securitytxt.all@ietf.org" , "secdir@ietf.org" Thread-Topic: [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 Thread-Index: AQHVvQ5F5NhPo4WnF02kWL0VZuiUIKfPricA Date: Sat, 28 Dec 2019 15:33:20 +0000 Message-ID: <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <24070.38156.658126.30539@fireball.acr.fi> In-Reply-To: <24070.38156.658126.30539@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.9] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-28_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=885 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912280142 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-28_04:2019-12-27,2019-12-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 lowpriorityscore=0 spamscore=0 phishscore=0 clxscore=1011 adultscore=0 impostorscore=0 mlxscore=0 bulkscore=0 malwarescore=0 mlxlogscore=856 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912280143 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 15:33:26 -0000 SSBkb24ndCB1bmRlcnN0YW5kIHRoZSBzZWN1cml0eSBjb25jZXJucyBhYm91dCAiZG8gbm90IHB1 Ymxpc2ggdGhpcy4iDQoNCkl0J3MgcHJvdGVjdGVkIGJ5IHRyYW5zcG9ydCBsZXZlbCBzZWN1cml0 eSwgYW5kIGl0J3MgZW5jb3VyYWdlZCB0byB1c2UgYXBwbGljYXRpb24tbGV2ZWwgc2lnbmluZy4g IEl0J3MgbWFjaGluZSByZWFkYWJsZSwgb3IgZWFzaWx5IHBhcnNlYWJsZSwgYW5kIGl0IG1ha2Vz IGl0IGVhc2llciBmb3IgcGVvcGxlIHRvIHJlcG9ydCBwcm9ibGVtcy4gIERvIHdlIGhhdmUgYSBw cm9ibGVtIHdpdGggb3Zlci1yZXBvcnRhZ2U/DQoNCkRvbid0IGxldCB0aGUgcGVyZmVjdCBiZSB0 aGUgZW5lbXkgb2YgdGhlIGJldHRlci4NCiANCg0K From nobody Sat Dec 28 08:56:47 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77DA120125; Sat, 28 Dec 2019 08:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (1024-bit key) header.d=nohats.ca 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 iPcC0VdyFQt6; Sat, 28 Dec 2019 08:56:44 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 7D50E12011E; Sat, 28 Dec 2019 08:56:44 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47lVGH4fKMzF6V; Sat, 28 Dec 2019 17:56:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1577552199; bh=4Dq3s4tNF01JIQu+YCJHQwoPuv9GrXytjdNNgPnsDZo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=d+/opNiM1Eos9VttPcElzuzEJyw+7WnuroRZdGFoUfeGg3zIGt2IYDgEgve52IKo6 m1ose9f2LwJ+WXXsd9uxJOK9oojHEhjNE6O4vJWYdtNonvG4x9pQmiIq+xHjeGj4m/ ryBC+qLEmsid54OWyduUwyDxDCGi+LMl2uMWTmoI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cVVGCIiGz8NU; Sat, 28 Dec 2019 17:56:37 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 28 Dec 2019 17:56:37 +0100 (CET) Received: from [193.111.228.74] (unknown [193.111.228.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id CF3A06001413; Sat, 28 Dec 2019 11:56:36 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16G102) In-Reply-To: <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> Date: Sat, 28 Dec 2019 11:56:36 -0500 Cc: Tero Kivinen , Yakov Shafranovich , "last-call@ietf.org" , "draft-foudil-securitytxt.all@ietf.org" , "secdir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <24070.38156.658126.30539@fireball.acr.fi> <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> To: "Salz, Rich" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 16:56:47 -0000 > On Dec 28, 2019, at 10:33, Salz, Rich wrote: >=20 > I don't understand the security concerns about "do not publish this." >=20 > It's protected by transport level security, and it's encouraged to use app= lication-level signing. It's machine readable, or easily parseable, and it m= akes it easier for people to report problems. Do we have a problem with ove= r-reportage? >=20 > Don't let the perfect be the enemy of the better. We did that already with Whois/RDAP ? It=E2=80=99s the non-perfect solution w= e have that is more secure than this alternative. It=E2=80=99s not perfect, and rdap is better than Whois for human plus machi= ne readable. Putting this information in the same realm you have a security issue with is= just not a good idea for many reasons mentioned during the entire discussio= n of the document and the various last call comments. We have more less-perfect solutions too. There is the web server error messa= ge contact info too. The DNS SOA record has a contact. The main web page usu= ally has a =E2=80=9Ccontact=E2=80=9D place listing an email or web form. And= we have postmaster@ and info@ and security@ email address that usually work= . If anything, we already have too many non-perfect solutions out there and t= his proposal is really a perfect example of xkcd 927. Paul= From nobody Sat Dec 28 09:13:39 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155D5120121; Sat, 28 Dec 2019 09:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chkas4yzb42L; Sat, 28 Dec 2019 09:13:31 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A791F12011E; Sat, 28 Dec 2019 09:13:30 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id y4so15247266ljj.9; Sat, 28 Dec 2019 09:13:30 -0800 (PST) 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=TEGI8o6aS1VnvF4ZuZg3ZaIpmf7uQXfEu/oyKSL7mcY=; b=BgO19r1EtfzATzRfC1pMlCg00BOMSIH9ijwr9VPS6CwtTa1XqQ27ucK/vFy55B5ptg a1fbbkKnf90LLmKbyqzblYBn8Kcpy5d+cgMxN66Dz4WQ+nS9ng05dhk+p2PnJaThpVIF FYlF6LHczR7vm+RJLYSBZa+NJGnfUW2kt/AR/IC2QMN6T/6qaFwW1xmNKJEeoLMLBOZ+ cIBXUcnShQZRqacRKHsN3bBGaTww2olAwZS3X92lE3dzkd2EE4sM4tQsBB6ScSNf2RKs cwrE08DNnWdazYZqctWPnT3Vmb47VSvGBPmp2EG4sGI42uiHW+uVVAOMXS3a6Pgpn2/3 OtXA== 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=TEGI8o6aS1VnvF4ZuZg3ZaIpmf7uQXfEu/oyKSL7mcY=; b=S8LpdlCT+5pEszYzts+YAyMkTP6k2ws3ETovindwE3gMiiAyoCcIF4bfW5XNlnNr9w HvjZfoRuY+LhxcObZqWuEOAjRr6gplVoUdPbS2hvKsNDnnZ+pTHVOT+DHmJx2IiwXgaq a7LM15rjdLkpbmIZ/iCIfPD4bwLY0jEMi2f1vKHsjOAn+ZGpteS14m0ewO63gq3rCqpG I1gfwJFNP1dCrXi3kNf4RrR16UASJjCRpsfuB8/fcSZgdOOpbkz2ckv6qwdsvXF2QTb5 DCCy7YT+TZdhrCrD2n82M+T2gjabf5KsJvR/nEBhUBllIHP9MMK7Ztp/M6U1XjgF8mee JLXw== X-Gm-Message-State: APjAAAU8HFvEIAbaMidWiHz7LlwQRQ6OXyV2aTXynG70DJ3KkMFbmkRe OYKnivIvo3ZfEGb0hjYAp0xe9xsqytJgwQZQXMNVfXHq X-Google-Smtp-Source: APXvYqxsVoUPCMgLTWwG/uDjJ7JPgJDttzHOn+/D04RUQHwn9J10hbBi19gxU01iC0DjTY0JAW8sawMYiPsFUX/8V2k= X-Received: by 2002:a2e:9f47:: with SMTP id v7mr10969469ljk.124.1577553208933; Sat, 28 Dec 2019 09:13:28 -0800 (PST) MIME-Version: 1.0 References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <24070.38156.658126.30539@fireball.acr.fi> <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> In-Reply-To: From: Watson Ladd Date: Sat, 28 Dec 2019 09:13:17 -0800 Message-ID: To: Paul Wouters Cc: "Salz, Rich" , "last-call@ietf.org" , "secdir@ietf.org" , Yakov Shafranovich , "draft-foudil-securitytxt.all@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a203da059ac6ba3f" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 17:13:33 -0000 --000000000000a203da059ac6ba3f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 28, 2019 at 8:56 AM Paul Wouters wrote: > > > > On Dec 28, 2019, at 10:33, Salz, Rich wrote: > > > > I don't understand the security concerns about "do not publish this." > > > > It's protected by transport level security, and it's encouraged to use > application-level signing. It's machine readable, or easily parseable, a= nd > it makes it easier for people to report problems. Do we have a problem > with over-reportage? > > > > Don't let the perfect be the enemy of the better. > > We did that already with Whois/RDAP ? It=E2=80=99s the non-perfect soluti= on we > have that is more secure than this alternative. > > It=E2=80=99s not perfect, and rdap is better than Whois for human plus ma= chine > readable. > > Putting this information in the same realm you have a security issue with > is just not a good idea for many reasons mentioned during the entire > discussion of the document and the various last call comments. > Most vulnerabilities will not get access to this file. Stuff like SQL injection, CSRF, XSS, etc. > > We have more less-perfect solutions too. There is the web server error > message contact info too. The DNS SOA record has a contact. The main web > page usually has a =E2=80=9Ccontact=E2=80=9D place listing an email or we= b form. And we > have postmaster@ and info@ and security@ email address that usually work. > If anything, we already have too many non-perfect solutions out there and > this proposal is really a perfect example of xkcd 927. > The reason this draft was made is those methods don't work. DNS SOA and website contact can go the wrong places in an organization. info@ and security@ aren't universal, and after that you're left being psychic. We are seeing new solutions to serious problems, and the response is "No, it isn't a problem" when the proposed solutions offer far less information. You're also assuming that another place to put information is a bad thing, and a possible heads up to a hypothetical attacker is worse then no notification. Right now the standard is begging on twitter for a chain of introductions. We should be able to do better. > Paul > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. --000000000000a203da059ac6ba3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Dec 28, 2019 at 8:56 AM Paul = Wouters <paul@nohats.ca> wrote:=


> On Dec 28, 2019, at 10:33, Salz, Rich <rsalz@akamai.com> wrote:
>
> I don't understand the security concerns about "do not publis= h this."
>
> It's protected by transport level security, and it's encourage= d to use application-level signing.=C2=A0 It's machine readable, or eas= ily parseable, and it makes it easier for people to report problems.=C2=A0 = Do we have a problem with over-reportage?
>
> Don't let the perfect be the enemy of the better.

We did that already with Whois/RDAP ? It=E2=80=99s the non-perfect solution= we have that is more secure than this alternative.

It=E2=80=99s not perfect, and rdap is better than Whois for human plus mach= ine readable.

Putting this information in the same realm you have a security issue with i= s just not a good idea for many reasons mentioned during the entire discuss= ion of the document and the various last call comments.

Most vulnerabilities will not get access to this file. Stu= ff like SQL injection, CSRF, XSS, etc.

We have more less-perfect solutions too. There is the web server error mess= age contact info too. The DNS SOA record has a contact. The main web page u= sually has a =E2=80=9Ccontact=E2=80=9D place listing an email or web form. = And we have postmaster@ and info@ and security@ email address that usually = work. If anything, we already have too many non-perfect solutions out there= and this proposal is really a perfect example of xkcd 927.

The reason this draft was made is those methods don= 9;t work. DNS SOA and website contact can go the wrong places in an organiz= ation. info@ and security@ aren't universal, and after that you're = left being psychic. We are seeing new solutions to serious problems, and th= e response is "No, it isn't a problem" when the proposed solu= tions offer far less information. You're also assuming that another pla= ce to put information is a bad thing, and a possible heads up to a hypothet= ical attacker is worse then no notification.

Right= now the standard is begging on twitter for a chain of introductions. We sh= ould be able to do better.


Paul
_______________________________________________
secdir mailing list
secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/= SecDirReview


--
"Man is born free, but everywhere he is in chains"= ;.
--Rousseau.
--000000000000a203da059ac6ba3f-- From nobody Sat Dec 28 10:44:41 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACA412011E; Sat, 28 Dec 2019 10:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWSRJ2LpTYrs; Sat, 28 Dec 2019 10:44:33 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 924E112010C; Sat, 28 Dec 2019 10:44:33 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1ilH4h-0000PD-Qo; Sat, 28 Dec 2019 18:44:32 +0000 Date: Sat, 28 Dec 2019 10:44:31 -0800 Message-ID: From: Randy Bush To: Watson Ladd Cc: secdir@ietf.org, Rubber Stamp In-Reply-To: References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <24070.38156.658126.30539@fireball.acr.fi> <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 18:44:35 -0000 > Right now the standard is begging on twitter for a chain of > introductions. and it works, i am embarrassed to say. and one hears about outages on the ops lists before one sees the automatic outage detector reports. sitting across the hudson, i heard of the wtc attack on nanog almost two minutes before it came on television. these half-assed "the market demands something" panaceas provide false solutions we have to clean up later; emphasis on that last clause. rwhois anyone? the highway is littered with whitepages roadkill. today there is a massive problem with authority in the IRR (which some RIRs throw in with whois); and retrofitting a solution is now years in blah blah blah. no one is asking for the perfect over the good. but it is our obligation, before putting the ietf stamp on it, for it to be as good as we can reasonably get for the time. this proposal is not, as has been enumerated time and again as it has been shoved through the process over objections. imiho, tero's review stands. randy From nobody Sat Dec 28 12:38:25 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319751201DC; Sat, 28 Dec 2019 12:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoFcvLQ2gjvN; Sat, 28 Dec 2019 12:38:15 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915061200F9; Sat, 28 Dec 2019 12:38:15 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xBSKYKYW012730; Sat, 28 Dec 2019 20:38:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=gv+A/t4/v7+/LKzT1nUa9/jWeiCSk6TyFdiJe3ylH0M=; b=NyOWXauCycjH6nAeUlZ68VH5oH43D0XTkq9xkcxWH7lqsQ1QZtjHjbwxIXCcgAHgHdf9 vkFD78zJVLnxMVstoB5a/cJAp7Dwt7iNCggAIXuq1im+043LOHNuKt+M0FlQ9AFl5zrW REHYjWDpZAcmJmAb9sS0cFB/HGomeio8fBhHdppm7puvazWuWY1c5ULzcVmmNCit0qaU cck6+J5qEgatQ/SfcIgciM3TUWPu3hVG9+6T42stMyUY1ruj+RJ+s5z1ZT7HQ92YDhod uOMVJiBsKAVjfT3RCcsZf/Qup46ve9qxV4pwj9JskU4Zc1mSv1C7oLRvWhNZkpEXMUsG Iw== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2x60be1vja-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 28 Dec 2019 20:38:13 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xBSKWBsZ022721; Sat, 28 Dec 2019 15:38:12 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint8.akamai.com with ESMTP id 2x638yjmtf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 28 Dec 2019 15:38:11 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb3.msg.corp.akamai.com (172.27.123.58) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 28 Dec 2019 15:38:08 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 28 Dec 2019 15:38:08 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Sat, 28 Dec 2019 15:38:08 -0500 From: "Salz, Rich" To: Paul Wouters CC: Tero Kivinen , Yakov Shafranovich , "last-call@ietf.org" , "draft-foudil-securitytxt.all@ietf.org" , "secdir@ietf.org" Thread-Topic: [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 Thread-Index: AQHVvQ5F5NhPo4WnF02kWL0VZuiUIKfPricAgABrFQD//+oUAA== Date: Sat, 28 Dec 2019 20:38:08 +0000 Message-ID: <9C5DEC2D-03CB-424B-B1F5-B98BAD84ADD9@akamai.com> References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <24070.38156.658126.30539@fireball.acr.fi> <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.9] Content-Type: text/plain; charset="utf-8" Content-ID: <282C231E245A074D916E9625A0C2BAC0@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-28_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=658 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912280192 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-28_07:2019-12-27,2019-12-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 suspectscore=0 spamscore=0 clxscore=1015 adultscore=0 mlxlogscore=622 mlxscore=0 phishscore=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912280192 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 20:38:17 -0000 ICAgIA0KPiAgICBQdXR0aW5nIHRoaXMgaW5mb3JtYXRpb24gaW4gdGhlIHNhbWUgcmVhbG0geW91 IGhhdmUgYSBzZWN1cml0eSBpc3N1ZSB3aXRoIGlzIGp1c3Qgbm90IGEgZ29vZCBpZGVhIC4uLg0K DQpJdCBkZXBlbmRzLiAgSWYgc29tZW9uZSB1c2VzIHRoZSBvbmUgYXQgb3BlbnNzbC5vcmcsIHdp bGwgdGhleSBiZSByZXBvcnRpbmcgYW4gaXNzdWUgaW4gdGhlIGxpYnJhcmllcywgdGhlIHNvZnR3 YXJlLCB0aGUgd2Vic2l0ZT8gIE15IG1vbmV5J3Mgb24gdGhlIGZpcnN0LiAgU2ltaWxhcmx5LCBp ZiB0aGVyZSB3ZXJlIG9uZSBhdCB3d3cuYWthbWFpLmNvbSwgaG93IHdvdWxkIHRoYXQgYmUgdXNl ZD8NCg0KPnBlcmZlY3QgZXhhbXBsZSBvZiA5MjcNCg0KTm8sIHNlZW1zIHByZXR0eSBjbGVhciB0 aGF0IHRoZSBvdGhlcnMgYXJlbid0IGFzIHN1Y2Nlc3NmdWwgYXMgd2Ugd2FudC9uZWVkLiAgV2hv aXMvcmRhcD8gIFdobyB1c2VzIHRoYXQ/DQoNCg== From nobody Sat Dec 28 19:31:16 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1EE12022A; Sat, 28 Dec 2019 19:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 g-QPX3Aub56V; Sat, 28 Dec 2019 19:31:07 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B3213120227; Sat, 28 Dec 2019 19:31:07 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBT3V264021081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 28 Dec 2019 22:31:04 -0500 Date: Sat, 28 Dec 2019 19:31:01 -0800 From: Benjamin Kaduk To: Randy Bush Cc: last-call@ietf.org, secdir@ietf.org Message-ID: <20191229033101.GE35479@kduck.mit.edu> References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <24070.38156.658126.30539@fireball.acr.fi> <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2019 03:31:10 -0000 Hi Randy, On Sat, Dec 28, 2019 at 10:44:31AM -0800, Randy Bush wrote: > > Right now the standard is begging on twitter for a chain of > > introductions. > > and it works, i am embarrassed to say. and one hears about outages on > the ops lists before one sees the automatic outage detector reports. > sitting across the hudson, i heard of the wtc attack on nanog almost two > minutes before it came on television. I do hear many stories about twitter letting people get in touch with the right organizational contact; a lot of them even "make the news" for some definition of "news". I wonder if they remain newsworthy because achieving success is far from guaranteed, whether by "traditional" methods or by twitter. > these half-assed "the market demands something" panaceas provide false > solutions we have to clean up later; emphasis on that last clause. > rwhois anyone? the highway is littered with whitepages roadkill. today > there is a massive problem with authority in the IRR (which some RIRs > throw in with whois); and retrofitting a solution is now years in blah > blah blah. > > no one is asking for the perfect over the good. but it is our > obligation, before putting the ietf stamp on it, for it to be as good as > we can reasonably get for the time. this proposal is not, as has been > enumerated time and again as it has been shoved through the process over > objections. > > imiho, tero's review stands. I do note the second 'i', but I have to say that to me, "shoved through the process over objections" sounds like a pretty serious process violation that ought to be remedied. I'd like to better understand what you see as the process violation (if any) here, so that I can try to remedy it. I note that the IETF LC period is still open, and I am closely reading all the feedback (e.g., including Paul Hoffman's note that arrived a bit after yours) and will make an assessment of whether there is IETF consensus to publish the document based on the feedback received during the last call. (Which is to say, I do not consider consensus to be a foregone conclusion.) Thanks, Ben From nobody Sat Dec 28 21:38:52 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4D412018D; Sat, 28 Dec 2019 21:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDlIcvxRiPXV; Sat, 28 Dec 2019 21:38:42 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 62C6D120018; Sat, 28 Dec 2019 21:38:42 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1ilRHk-0001ic-Bp; Sun, 29 Dec 2019 05:38:40 +0000 Date: Sat, 28 Dec 2019 21:38:36 -0800 Message-ID: From: Randy Bush To: Benjamin Kaduk Cc: last-call@ietf.org, secdir@ietf.org In-Reply-To: <20191229033101.GE35479@kduck.mit.edu> References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <24070.38156.658126.30539@fireball.acr.fi> <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> <20191229033101.GE35479@kduck.mit.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2019 05:38:46 -0000 >>> Right now the standard is begging on twitter for a chain of >>> introductions. >> >> and it works, i am embarrassed to say. and one hears about outages >> on the ops lists before one sees the automatic outage detector >> reports. sitting across the hudson, i heard of the wtc attack on >> nanog almost two minutes before it came on television. > > I do hear many stories about twitter letting people get in touch with > the right organizational contact; a lot of them even "make the news" > for some definition of "news". I wonder if they remain newsworthy > because achieving success is far from guaranteed, whether by > "traditional" methods or by twitter. probably because, as with 47.2% of what the press publishes, it sells papers. but no, i am not pleased that the most used sources of security and net failure notifications are twitter and a few mailing lists. and don't get me started about the certs as information hoarders. >> these half-assed "the market demands something" panaceas provide >> false solutions we have to clean up later; emphasis on that last >> clause. rwhois anyone? the highway is littered with whitepages >> roadkill. today there is a massive problem with authority in the IRR >> (which some RIRs throw in with whois); and retrofitting a solution is >> now years in blah blah blah. >> >> no one is asking for the perfect over the good. but it is our >> obligation, before putting the ietf stamp on it, for it to be as good >> as we can reasonably get for the time. this proposal is not, as has >> been enumerated time and again as it has been shoved through the >> process over objections. >> >> imiho, tero's review stands. > > I do note the second 'i', but I have to say that to me, "shoved > through the process over objections" sounds like a pretty serious > process violation that ought to be remedied. that may be what you heard, but that is not what i said, or at least meant to say. > I'd like to better understand what you see as the process violation > (if any) here, so that I can try to remedy it. if i had a process objection, i would say it quite clearly. i have a reputation to maintain :) technical objections have been raised all along the path of this document. many of them ignored and repeated, many covered in tero's most excellent secdir review. but the draft marched on. today sm raised new issues. but you're a security guy, have the badge and all, even if your name is not steve. read the darn thing and tell us what you think of it as reasonable and prudent secops practice. randy From nobody Sun Dec 29 11:49:05 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09C4120098; Sun, 29 Dec 2019 11:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=kteve7iy; dkim=pass (1024-bit key) header.d=juniper.net header.b=D4Ky7fMp 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 BYEkG8EJXVm3; Sun, 29 Dec 2019 11:48:57 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 AEA3E120091; Sun, 29 Dec 2019 11:48:57 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBTJmuSc027873; Sun, 29 Dec 2019 11:48:56 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=i6Wz1EyaM52hokNTmvw4jZZzoWJ3VQ1NdQP5Iyxu8d4=; b=kteve7iySQHsmlHy9AcnoQNfAlZZiRzgdNT1vh+h4LK3Eks614KHId7gJvzHRdqTXBKd EajoP6H6i7ea5F/oRcS3YyjTPH2hQDwVJ7e89OYAb8FS79hk6UG3tDEG/Mg1ShTaiWEt ZbM4ZZ1B13XnmJ558axNSAMyi6fviTx3NROM0VR5OjcCbghtIinFLiNPmUCGtXXqAuC9 jnQvTBbkPDBG9w1WODulkoFlri1M+hZ9XWIVkJTnEtDHnqUp804IyYcSLCKqj8KcqUAf hTQDrZgBqvVzTYs8KxpxCyzKlnnAFP6Pvf0eoah8WfyQONWnrfElQ3nAcmRF/ulrQWdZ nA== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2056.outbound.protection.outlook.com [104.47.45.56]) by mx0a-00273201.pphosted.com with ESMTP id 2x66xv1a3d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 29 Dec 2019 11:48:56 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MH3TJu3tSUB7HdU9hKxcyQt5OJ+e4qE9t4YsG/r7iveQ+mFdPitj+FLcgQOemf6j/XtCFN+xK8CmrV2gxKuI68jdcPYWwdW1k6/imrC2BLw1AY/kea1gMC0t28hdAQo99L/LC+n+X2VJwqXZZTUn/eVXOD6aBNSFiVu/iAS++fDp0iglO3YVk16v23Afm8cC6NBsp59gmzu7M5KrKnoZVURgn9UTbBFVHKWpGOtKX88gMG8zyBxKuADFhUtXPXKNUSWFC8DR5iODXsV/nzYpQ/ut6fuKJsl1MbKsavY+qAHFlIta+tmtpgU5CRlJHJXuTQW5w/jwFDZ/E3P6HGHrmQ== 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=i6Wz1EyaM52hokNTmvw4jZZzoWJ3VQ1NdQP5Iyxu8d4=; b=YgQFP3Ep0r9+xwQlJlge9Hzu3sYsRLbwEOJbulRBcI03e52kY8l8XPO4TRo3TpVimGgKPwhvtsH8Nhf5ugGvVo1ZrBia9DH/FgK3oO92VgM4Pj3ekGOb3zNx4wk8skAaYKcqKx9o0TpdfwX2inVQEuHnkIY8wWwDH8qz5jwP8Yx5nRPjxZ//rDg+Zjc3kuTUovF+K3qrmWtYfEsSurco0OOJ8CJ3gWrH8xGDRLn7xBXtilaaBTq3jNopHr6ZY31ByZEEzkMmsxSLf8V6qpz+vK6usCBzEEazuCkho7/3bTwVg8+vka1dc6wPNG2PLDnNR2ZoMiAnOAdADzjuFn6aHg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i6Wz1EyaM52hokNTmvw4jZZzoWJ3VQ1NdQP5Iyxu8d4=; b=D4Ky7fMpczqCOjnUt67uiw3UEt12ScRiZSPAJ1kf4ldzZRGD12QBvj3MkaX3KyHoNd6UDoUJavtU+7+U90Pa3QbU1QEab3T2TnRjIvy2fVIFJ+yxdkXKkS2xM7AnvO1IPPtMnJhPAM8fXNIxraUFYdsgHQdURpkSUALUNe+m0y0= Received: from BYAPR05MB4341.namprd05.prod.outlook.com (20.176.252.21) by BYASPR01MB0035.namprd05.prod.outlook.com (20.178.1.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.6; Sun, 29 Dec 2019 19:48:53 +0000 Received: from BYAPR05MB4341.namprd05.prod.outlook.com ([fe80::d14c:cc1b:8d10:19d3]) by BYAPR05MB4341.namprd05.prod.outlook.com ([fe80::d14c:cc1b:8d10:19d3%7]) with mapi id 15.20.2602.009; Sun, 29 Dec 2019 19:48:53 +0000 From: Tarek Saad To: Chris Lonvick , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-mpls-summary-frr-rsvpte.all@ietf.org" Thread-Topic: SECDIR review of draft-ietf-mpls-summary-frr-rsvpte Thread-Index: AQHVtH2natu5WnXpBkevt9n9DIHJQqfRRTAA Date: Sun, 29 Dec 2019 19:48:52 +0000 Message-ID: <40C4EBF7-1229-4A06-B9A3-38EB4AFB0B22@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Name=Juniper Business Use Only; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ContentBits=0; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Method=Standard; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ActionId=e224ce62-6a9a-426b-bbb4-0000b28093d8; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SetDate=2019-12-29T19:47:41Z; user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6349b704-016b-471a-bc6a-08d78c982221 x-ms-traffictypediagnostic: BYASPR01MB0035: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(346002)(136003)(366004)(37854004)(189003)(199004)(91956017)(76116006)(2906002)(316002)(6512007)(110136005)(5660300002)(8936002)(6486002)(186003)(478600001)(81156014)(81166006)(8676002)(36756003)(66446008)(33656002)(4744005)(64756008)(71200400001)(6506007)(86362001)(26005)(2616005)(66556008)(66946007)(66476007); DIR:OUT; SFP:1102; SCL:1; SRVR:BYASPR01MB0035; H:BYAPR05MB4341.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ORBlb3PaYXYUBKGAQsnr2FBLxa0D47Peevub0SOe+SZeZfvJ9gspqoQhbXhRMkBnJGoVb04f8Q1jbdxBiXl11YY4jZa56ICsYfk0v+iUVN4lOaWoW7WCgJr2830kRntnImnU9qMFxAsi2jkXfOxq9rFPk/3UdcUgo8/ZWYdJkNejROj2dE31gsId+FpWyasbKbiO/rPHJn0u3nJNVDB4b+GJlCAnk24LIJtXgYBEi3NgU5nfYnGsRATchNZ4RcchoLGa00YltipUemdvSU4c4piRx5pnMO/xfDu63yYY/wqiTvwnwScuaeuw6+TpKubhER+TfzoBLOF9MiJIMQqf3eni/K96sbaLvEU6xTOS8wggPK5IkMFBoYW+ilh5V+cYKIPlbVzUHOl8Y2A/Sx/yexScsCfKDDCCXH/FPWKvNhrrfGbBr8Zwj8NTUQ1HTS5DBj4eFW9zYhESun0bENdCdoMx6MtE7ql49DxKw7duyQWAM9km6wxy0WNxXarFsUaD x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <59051CE797781140A91D93A30871430E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 6349b704-016b-471a-bc6a-08d78c982221 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2019 19:48:52.9599 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6pMSHRnfKwvWNbrg4nM2quBt5ioCRz9jwhYXlslF0xiVCKcTMY2b8Xw0NvqakTVVqrsU0H8KiZ8DipdgYTabZg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYASPR01MB0035 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-29_03:2019-12-27,2019-12-29 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 bulkscore=0 adultscore=0 mlxlogscore=999 priorityscore=1501 lowpriorityscore=0 clxscore=1011 phishscore=0 mlxscore=0 malwarescore=0 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912290187 Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-summary-frr-rsvpte X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2019 19:48:59 -0000 SGkgQ2hyaXMsDQoNCkhhcHB5IG5ldyB5ZWFyISBUaGFua3MgYSBsb3QgZm9yIHlvdXIgdGltZSBy ZXZpZXdpbmcgdGhlIGRvY3VtZW50Lg0KDQpSZWdhcmRzLA0KVGFyZWsNCg0K77u/T24gMTIvMTYv MTksIDg6NTkgUE0sICJDaHJpcyBMb252aWNrIiA8bG9udmljay5pZXRmQGdtYWlsLmNvbT4gd3Jv dGU6DQoNCiAgICBIaSwNCiAgICANCiAgICBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBh cyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIA0KICAgIG9uZ29pbmcgZWZmb3J0 IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNH LiANCiAgICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVu ZWZpdCBvZiB0aGUgc2VjdXJpdHkgDQogICAgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVkaXRv cnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgDQogICAgY29tbWVudHMganVzdCBs aWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQogICAgDQogICAgVGhlIHN1bW1hcnkg b2YgdGhlIHJldmlldyBpcyBSRUFEWS4NCiAgICANCiAgICBUaGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbiBpcyBhIGJpdCB0aGluLCBidXQgaXQgYXBwcm9wcmlhdGVseSANCiAgICBh ZGRyZXNzZXMgdGhlIGlzc3VlIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gd2lsbCBpbmNyZWFzZSB0 aGUgYXR0YWNrIA0KICAgIHN1cmZhY2Ugb2YgYW4gUlNWUCBvYmplY3QuIFNpbmNlIHRoaXMgaXMg YW4gZXh0ZW5zaW9uIHRvIHRoZSBwcm90b2NvbCwgDQogICAgdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNlY3Rpb25zIG9mIHRoZSBjb250cm9sbGluZyBSRkNzIGFyZSBpZGVudGlmaWVkLg0K ICAgIA0KICAgIEkgc2tpbW1lZCB0aGUgZHJhZnQgYSBmZXcgdGltZXMgYnV0IGRpZCBub3Qgc2Vl IGFueSBuaXRzIG9yIG90aGVyIA0KICAgIGlzc3Vlcy4gT3ZlcmFsbCwgdGhlIGRyYWZ0IGFwcGVh cnMgdG8gYmUgd2VsbCB3cml0dGVuIGFuZCB3ZWxsIHRob3VnaHQgb3V0Lg0KICAgIA0KICAgIFJl Z2FyZHMsDQogICAgDQogICAgQ2hyaXMNCiAgICANCiAgICANCg0K From nobody Mon Dec 30 18:37:21 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F3112002E; Mon, 30 Dec 2019 18:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 GwUCuJIrzpHB; Mon, 30 Dec 2019 18:37:13 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 E168312008F; Mon, 30 Dec 2019 18:37:12 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBV2b8lA025151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Dec 2019 21:37:10 -0500 Date: Mon, 30 Dec 2019 18:37:07 -0800 From: Benjamin Kaduk To: Randy Bush Cc: last-call@ietf.org, secdir@ietf.org Message-ID: <20191231023707.GR35479@kduck.mit.edu> References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <24070.38156.658126.30539@fireball.acr.fi> <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> <20191229033101.GE35479@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 02:37:15 -0000 On Sat, Dec 28, 2019 at 09:38:36PM -0800, Randy Bush wrote: > > >> these half-assed "the market demands something" panaceas provide > >> false solutions we have to clean up later; emphasis on that last > >> clause. rwhois anyone? the highway is littered with whitepages > >> roadkill. today there is a massive problem with authority in the IRR > >> (which some RIRs throw in with whois); and retrofitting a solution is > >> now years in blah blah blah. > >> > >> no one is asking for the perfect over the good. but it is our > >> obligation, before putting the ietf stamp on it, for it to be as good > >> as we can reasonably get for the time. this proposal is not, as has > >> been enumerated time and again as it has been shoved through the > >> process over objections. > >> > >> imiho, tero's review stands. > > > > I do note the second 'i', but I have to say that to me, "shoved > > through the process over objections" sounds like a pretty serious > > process violation that ought to be remedied. > > that may be what you heard, but that is not what i said, or at least > meant to say. > > > I'd like to better understand what you see as the process violation > > (if any) here, so that I can try to remedy it. > > if i had a process objection, i would say it quite clearly. i have a > reputation to maintain :) Okay, thanks for clarifying. > technical objections have been raised all along the path of this > document. many of them ignored and repeated, many covered in tero's > most excellent secdir review. but the draft marched on. today sm > raised new issues. Well, I do remember some objections raised when this draft was still at SAAG/SECDISPATCH, but I also assigned it a document shepherd and refused to touch it myself until the shepherd had worked with the authors to address those comments to the extent that we understood them. (That was mostly comments from Paul Wouters, if I remember correctly; there may have been others.) So I'm not sure which objections you think have been ignored while "the draft marched on" -- my intent was to get the initial objections addressed (and yes, sometimes that was by attempting to make them "out of scope", which does not always work well), and the next step in the process is AD review followed by IETF LC. Having more issues raised during a single IETF LC isn't surprising (though it is perhaps unusual, with many drafts getting no LC comments other than directorate reviews, which is probably a different thread), so "ignored and repeated" and "but the draft marched on" feel a bit like hyperbole to me. But maybe I messed up and we missed something; I'm sure you won't be shy about telling me if that's the case. > but you're a security guy, have the badge and all, even if your name is > not steve. read the darn thing and tell us what you think of it as > reasonable and prudent secops practice. I mean, I read it when I did the AD evaluation, and what I recall thinking is that it proposes a mechanism that's useful in some cases but potentially harmful in other cases, so the trick would be to get the writing to be clear about the risks. Having it already being in use tends to tilt the scales towards "document the thing so that the semantics are well-defined", though that does not absolve us of the duty to accurately document the drawbacks and risks. It's a mixed bag, and you'll need to think before relying on the information in the file, but that's hardly unique to this mechanism. -Ben From nobody Mon Dec 30 18:51:38 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B1D12002E; Mon, 30 Dec 2019 18:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 qcgZ0dXPCjyc; Mon, 30 Dec 2019 18:51:30 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 BE5EE12008F; Mon, 30 Dec 2019 18:51:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1im7d2-0006RR-SJ; Tue, 31 Dec 2019 02:51:29 +0000 Date: Mon, 30 Dec 2019 18:51:28 -0800 Message-ID: From: Randy Bush To: Benjamin Kaduk Cc: last-call@ietf.org, secdir@ietf.org In-Reply-To: <20191231023707.GR35479@kduck.mit.edu> References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <24070.38156.658126.30539@fireball.acr.fi> <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> <20191229033101.GE35479@kduck.mit.edu> <20191231023707.GR35479@kduck.mit.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 02:51:32 -0000 > Well, I do remember some objections raised when this draft was still at > SAAG/SECDISPATCH, but I also assigned it a document shepherd and refused to > touch it myself until the shepherd had worked with the authors to address > those comments to the extent that we understood them. (That was mostly > comments from Paul Wouters, if I remember correctly; there may have been > others.) So I'm not sure which objections you think have been ignored > while "the draft marched on" e.g. mine. qed. randy From nobody Mon Dec 30 19:24:10 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA9A1200CD for ; Mon, 30 Dec 2019 19:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kD71kiF2M6kh for ; Mon, 30 Dec 2019 19:24:07 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 3076F12002E for ; Mon, 30 Dec 2019 19:24:07 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id y8so15393649pll.13 for ; Mon, 30 Dec 2019 19:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UTTgGp3GYJx4nAIp97b76ajMqFlxme59XGKCJY+7NJs=; b=Lar9AhFFmq2cnpeHpTic6yYWkC2rLeoKS9GM0ZinU4FhTosvnIWFkaNcSYQ1qoiIXZ i9fBl+N4+SQ+e3P+iluD5r8N76q5x5gd7zfFSZ9efypYi5OHK79W74x24umP1R89F+7J 2aBF118ehCVeEfRU+qFVvJk36DI8Ep9EyqqbFj3XGdAlhrdsm8B0HB67+KssYjHcouvg BiEO3s0gdVg+UbFtTHo5eyx2fSp4IXraEjI43Kt12Sr3UimprLK+/PEzAX9wgC/z3CWN IHn8U4IIqWi11JOyiem92yhzuDyXaQ/IvBj0mp5VRopA5Jh1QZg/+ZEHi05J14f/Z/KM ntrQ== 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=UTTgGp3GYJx4nAIp97b76ajMqFlxme59XGKCJY+7NJs=; b=MPxmbqdRsvN0TNVK74wmnIDMgqVTOi5pfC2wai4rYLbDZT5Z7+emacw1Yn5PTmdbAF uKx2QA5BUs2Y48HVOUOy2DI4rTLjqW8s1cQ58VoMvFVBYJAVuybjR+5St3NXhFyp/4Rp mGxXNRJjRGknEqi5bDATyl+GylkGXoJIRck8v3dv7CglXbk5d2Pry1+4TpYTDx4vWKb0 dSbd4NqzACRTUtcjtfYgoWcn7U8So5NTMKqcY1jdsmeIeSqdoXRL6YguIBs+CwEmyCcb Hx02gE1z1zBxmpc4ZIiINPtFV3vYmvIe7I/7Dt7mbC1ju8KbnSQ/eWYCwbRG0E3q+q9n iVOg== X-Gm-Message-State: APjAAAUp2xQ8Lde8JiiAQxj/7slDx4z5RgwnDJi7RsUCALpSaH6Z7iol uygOLjrCo8wp6F2o4MBuXoF+NdKd3ZeEupC8+mMXWfVFeFE= X-Google-Smtp-Source: APXvYqxtefDjsiXG1rfEm0LnO0jjd+kiWu8EbnQhMpemaRjZWNnieDF1Mr8tYTbVnH1Gmy9huGPCTAkbUJai3dV4wuw= X-Received: by 2002:a17:902:7208:: with SMTP id ba8mr18765220plb.220.1577762646612; Mon, 30 Dec 2019 19:24:06 -0800 (PST) MIME-Version: 1.0 References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <24070.38156.658126.30539@fireball.acr.fi> <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> In-Reply-To: From: Yakov Shafranovich Date: Mon, 30 Dec 2019 22:23:30 -0500 Message-ID: To: Watson Ladd Cc: "last-call@ietf.org" , "secdir@ietf.org" , "draft-foudil-securitytxt.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 03:24:08 -0000 On Sat, Dec 28, 2019 at 12:13 PM Watson Ladd wrote: > > Right now the standard is begging on twitter for a chain of introductions. We should be able to do better. > As a side point, some organizations publishing a security.txt file, use Twitter as a preferred contact method. Here is an example: https://scotthelme.co.uk/.well-known/security.txt Contact: security@scotthelme.co.uk Contact: https://twitter.com/Scott_Helme Encryption: https://scotthelme.co.uk/contact/ Thanks From nobody Mon Dec 30 19:55:10 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C3A1200C3; Mon, 30 Dec 2019 19:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZXTDeGFSjqz; Mon, 30 Dec 2019 19:55:01 -0800 (PST) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 C6AB412002E; Mon, 30 Dec 2019 19:55:01 -0800 (PST) Received: by mail-il1-x143.google.com with SMTP id x5so29348895ila.6; Mon, 30 Dec 2019 19:55:01 -0800 (PST) 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=KSYrgdJqqRRoFUDi5IDdLpDzoBq2IDKsdGFiYWtUQLY=; b=FlvJnUruxShwIZ7d2Rj1oy4rOlYi6R8xhp+0W/vhlDmtxiRM3Df7buUYhmb21Ywh3b pmtOA4ohGaXbFw4j4U4eY27n9yFO2eUh0u1XKKIGI/UfRFBSMFpnheTRLvKGhnKruZY+ REE2aPIbf7Gtj/nF6tn/yN969aoU/JFPFyZM0ypw/v7K6KO89mZjOPP5ML500pJSoiWI CXs/e/cTeFdoi5REsEwabZnklXVIjobw9yVr2YtJxKYDgjU06lXBTRVxed5yf7lM6rkO slsFS5yvHSNHnSIkxrqgkDPUMtoOkG1zqUMIT+K1gZBYXVnaqyAdvkd5ieMQIYsuMaD/ yPRw== 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=KSYrgdJqqRRoFUDi5IDdLpDzoBq2IDKsdGFiYWtUQLY=; b=VOP9e6MMhvTD3MWPDTD9eqVAhF6NA6mj4wbtsd0RDnVIcKIzFofunvNw6SGLzGnHZh Dh3ZzPLPzEYugzZoT518Sv/PY9tp4Tf8+KgtUoBZZFGiKXA7RyW5u2RZvrBsmUm3ekbh qVGYU/+64nwYw3bJcECRzbW2sAfe6wpO1kwiXf8QHmkYJmEFgravUXP3THVCAcoxz/3Q 4ScvbAtxnuNiJlrz4P1Nlu5Ch/dA6cgQHd6PJEJG133pqaTrk5oxl0hwxx4dIkwzWIMM E879pjikTDeUC/hK3LqJw508qPiEdUQ6NDvD4JZhHbC52ehZCrZWmBIskqHv3AON+Pzq 1AAQ== X-Gm-Message-State: APjAAAWzH97ZJ5gkdeBvSxfz5HG6c2DnD8XC0zQwhwPhWUccZJINgGJL 0pRs7I9VGPBjXBrX0+QbbxlxTf2eRAmsDjiE58Y= X-Google-Smtp-Source: APXvYqwj9g/+6DLHNvNS5HYqwam4K8Poh8TCMdEwIXYEDe842yeZBOyYW0ujSvp0t7pscMb2KXha9wg1MElxK4PQdj8= X-Received: by 2002:a92:8307:: with SMTP id f7mr62046450ild.73.1577764501079; Mon, 30 Dec 2019 19:55:01 -0800 (PST) MIME-Version: 1.0 References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> In-Reply-To: <157720267698.19361.11750709876624228448@ietfa.amsl.com> From: Rob Sayre Date: Mon, 30 Dec 2019 19:54:48 -0800 Message-ID: To: Tero Kivinen Cc: secdir@ietf.org, last-call@ietf.org, draft-foudil-securitytxt.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000a04db0059af7ece9" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 03:55:03 -0000 --000000000000a04db0059af7ece9 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 24, 2019 at 7:51 AM Tero Kivinen via Datatracker < noreply@ietf.org> wrote: > Reviewer: Tero Kivinen > Review result: Has Issues > > This document describes text file located in the web server which can be > used > to find the information where to contact in case there is security > vulnerabilities that needs to be disclosed. > > I think this whole idea is BAD, and I do not think we should be publishing > this > document at all in this format. > Yeah... I looked at: https://tools.ietf.org/html/draft-foudil-securitytxt-08#section-6.7 "Organizations SHOULD weigh the advantages of publishing this file versus the possible disadvantages and increased resources required to triage security reports." While the draft does spend some time describing the "Scope of the File", it doesn't address attacks against other parties using phone numbers or emails contained within the file. For example, it seems possible to register free domain names under TLDs like .xyz and .tk and then point phone numbers at unsuspecting parties. thanks, Rob --000000000000a04db0059af7ece9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 24, 2019 at 7:51 AM Tero Kivi= nen via Datatracker <noreply@ietf.or= g> wrote:
Reviewer: Tero Kivinen
Review result: Has Issues

This document describes text file located in the web server which can be us= ed
to find the information where to contact in case there is security
vulnerabilities that needs to be disclosed.

I think this whole idea is BAD, and I do not think we should be publishing = this
document at all in this format.

Yeah...= I looked at:


"= ;Organizations SHOULD weigh the advantages of publishing this file versus t= he possible disadvantages and increased resources required to triage securi= ty reports."

While the draft does spend some = time describing the "Scope of the File", it doesn't address a= ttacks against other parties using phone numbers or emails contained within= the file.

For=C2=A0example, it seems possible to = register free domain names under TLDs like .xyz and .tk and then point phon= e numbers at unsuspecting parties.

thanks,
Rob

--000000000000a04db0059af7ece9-- From nobody Mon Dec 30 20:00:46 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4FF1200CE for ; Mon, 30 Dec 2019 20:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=nightwatchcybersecurity-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTbF1BrTKqhr for ; Mon, 30 Dec 2019 20:00:42 -0800 (PST) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 7CF501200C3 for ; Mon, 30 Dec 2019 20:00:42 -0800 (PST) Received: by mail-pj1-x1035.google.com with SMTP id s7so706998pjc.0 for ; Mon, 30 Dec 2019 20:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Hrz3F5xPHzJQkVoyNYe6KiyCdh84boU1kk/2MdjJc4=; b=bjdwiIYbAy7W+QE/dUeQak9QcQFd0T77G64i0TPEpnss1d/4gneod1G9yV0WUXe3LZ qRqP1o7FCSiREUeZ8agb/AW08Wl7gGmWxZDi/DwMDqE8+bknaw+q5JsCLskapN02ZQwi obmcDPMsC26ZqQ+kEmIvlRQrCqMu+yZfZpVJ3D54JQkRN5VgHg+J2YlSFjewdTNT6i+L tfNqyKAcUvJ3Nb+wnQsN63HIG6PWE9ujUb/CLlAYeZQu71xwY93fqp3x5l0pIqg9Utwk 8PQuIpNvsEi4ZoAiqoFV3J4lTiXMH3i/HPSUwxe17wgH1B3OqmmJqM3Qw2NEhQ9Spxcv 1a/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0Hrz3F5xPHzJQkVoyNYe6KiyCdh84boU1kk/2MdjJc4=; b=m8nhTAXYp8NEeq2vS38RLzWj3HhJFXKmcS4HfZwGYzvCOnQvq+K9ei6m+w+9caVwcA 7PblJALZQjncBydMd9ghxYTCX99kQfgA10MWYptil/gBr+EC7hhAgWs6620PDmZmoZXX U7jQxO+mMHEtkD8qimD+Ce0AtSIEFkUsZJzD7dGkdfA3MXU6ZZgd917VgvX/imq50X+i nDMirOyaoLubXuavzEyysplbZ5UyA1SGnvuRxsRej8UIRzX76n3FygwzvyfuWUHanJUu vn8bM7CjQNXuqmUdCEAu3FwCmS5k6YAMmcY0GXRsBdEJdPCyQlDoq8CwVf0B/VcjZod/ hotA== X-Gm-Message-State: APjAAAUVkyWpYMB7m2lEtoSONxcvIHl6hgfQc+QCKJIIrdithaBlKRwu O5NG9Vow7z7zYIwr4CguYQQtBZW+xCMfXJW/0guhOw== X-Google-Smtp-Source: APXvYqwjPfTqtCiX7WYgEzm/qyLyGv+oPwhDm4tsaX3NfxMhldDj1XPwUp3srxbXr3zNwqk3xmgt9djkyTftRfY17yw= X-Received: by 2002:a17:902:8bc4:: with SMTP id r4mr71754325plo.291.1577764841883; Mon, 30 Dec 2019 20:00:41 -0800 (PST) MIME-Version: 1.0 References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> In-Reply-To: From: Yakov Shafranovich Date: Mon, 30 Dec 2019 23:00:05 -0500 Message-ID: To: Rob Sayre Cc: Tero Kivinen , secdir@ietf.org, last-call@ietf.org, draft-foudil-securitytxt.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 04:00:44 -0000 On Mon, Dec 30, 2019 at 10:55 PM Rob Sayre wrote: > > On Tue, Dec 24, 2019 at 7:51 AM Tero Kivinen via Datatracker wrote: >> >> Reviewer: Tero Kivinen >> Review result: Has Issues >> >> This document describes text file located in the web server which can be used >> to find the information where to contact in case there is security >> vulnerabilities that needs to be disclosed. >> >> I think this whole idea is BAD, and I do not think we should be publishing this >> document at all in this format. > > > Yeah... I looked at: > > https://tools.ietf.org/html/draft-foudil-securitytxt-08#section-6.7 > > "Organizations SHOULD weigh the advantages of publishing this file versus the possible disadvantages and increased resources required to triage security reports." > > While the draft does spend some time describing the "Scope of the File", it doesn't address attacks against other parties using phone numbers or emails contained within the file. > > For example, it seems possible to register free domain names under TLDs like .xyz and .tk and then point phone numbers at unsuspecting parties. > I am adding language to address that: "Attackers can also use this file as a way to spam unrelated third parties by listing their resources and/or contact information." And: "Security researchers SHOULD consult the organization's policy, if available, and review the contact information and/or resources referenced within the "security.txt" file before submitting reports in an automated fashion or as resulting from automated scans." From nobody Mon Dec 30 20:05:07 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2107B1200C3; Mon, 30 Dec 2019 20:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtEDkUQ19Ejm; Mon, 30 Dec 2019 20:04:58 -0800 (PST) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 C116812002E; Mon, 30 Dec 2019 20:04:58 -0800 (PST) Received: by mail-io1-xd42.google.com with SMTP id c16so3238348ioh.6; Mon, 30 Dec 2019 20:04:58 -0800 (PST) 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=LQjGFef4IkCmZfzGZyhFajcw390pScca5Z8lDbckpl4=; b=HG8faETcUoaLM5qkqcsedlQV/moP9mGrHao0Z4YUxiE7vFuD/qIyrUEI8DsB9rVdMD IBPxDlDmhmrCNHU1MmYHbO+5PdcmgUZJrd3tP5E6t2QXDRn5l6ym/c1oJ9dtflXhvH7L Bo6JvDYsegBJXO35fCl/ba5nWFua473tZS298VRGQurXLbendhEUDpOl/CKmu8dz5SY7 6Hi6SpxvVjGlTRzOyqz/OGOoLf3SEI3l60aVSkCboEEQBBOMLxR80/mBli1lTwA5zC46 7Qo6gSJqeJhWAf6TGf5mv+d/AvYPPPbIowLzwpVxUt+7mFrIBeI2KXmYpuZC2ASOUGlP ln3A== 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=LQjGFef4IkCmZfzGZyhFajcw390pScca5Z8lDbckpl4=; b=FX1MghqpJokPSh46AWhg2oF8dYMQEoxMSxJHEC1NGIbFBAYZ+PdPoirSEFqOK8uqEW 1gTbT5AIVPBwy6Zc4VC0P2NFhibAQtiVlcoTcMjkGvgKPtPPF75Atx0vEWWtrOGNkPib nBt+IE+PK+7grlY4pscZEm2dcBz2r+dq3tFlc2jwqhwxSoLNEATRAk8d68rh2qWaWzGy 4NhdbN+bCcNy+nzSELh67D4QTVBwAnKA40dNxyidzkIRGiaYEVSkOGRYfeaWpkSNtgWw 52iFOYLavj87/Vxn4UNHF2tF3dk4CoYaj6v0Y02PglT+QgXAoLDxSvImtOq3PwYU3Mcg 3c0w== X-Gm-Message-State: APjAAAXVJNrOlBLT0cJPfy3KdTwj9JU7890onAH4XEuT2kPwzgUBVFJw d11b7L38EfIotAOfYySM27tpwR0xWt3uuH7xBYE= X-Google-Smtp-Source: APXvYqx02E7OSLsbhzXdvUujxVjbgFcS/smxXZpA58QD1LMx3uyur3D9zxhnYGocIw10fgY+7SP1r8j5lsJVTC9rGLE= X-Received: by 2002:a02:ba91:: with SMTP id g17mr56858720jao.106.1577765098095; Mon, 30 Dec 2019 20:04:58 -0800 (PST) MIME-Version: 1.0 References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> In-Reply-To: From: Rob Sayre Date: Mon, 30 Dec 2019 20:04:45 -0800 Message-ID: To: Yakov Shafranovich Cc: Tero Kivinen , secdir@ietf.org, last-call@ietf.org, draft-foudil-securitytxt.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000036080d059af81072" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 04:05:01 -0000 --00000000000036080d059af81072 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 30, 2019 at 8:00 PM Yakov Shafranovich < yakov@nightwatchcybersecurity.com> wrote: > On Mon, Dec 30, 2019 at 10:55 PM Rob Sayre wrote: > > > > On Tue, Dec 24, 2019 at 7:51 AM Tero Kivinen via Datatracker < > noreply@ietf.org> wrote: > >> > >> Reviewer: Tero Kivinen > >> Review result: Has Issues > >> > >> This document describes text file located in the web server which can > be used > >> to find the information where to contact in case there is security > >> vulnerabilities that needs to be disclosed. > >> > >> I think this whole idea is BAD, and I do not think we should be > publishing this > >> document at all in this format. > > > > > > Yeah... I looked at: > > > > https://tools.ietf.org/html/draft-foudil-securitytxt-08#section-6.7 > > > > "Organizations SHOULD weigh the advantages of publishing this file > versus the possible disadvantages and increased resources required to > triage security reports." > > > > While the draft does spend some time describing the "Scope of the File", > it doesn't address attacks against other parties using phone numbers or > emails contained within the file. > > > > For example, it seems possible to register free domain names under TLDs > like .xyz and .tk and then point phone numbers at unsuspecting parties. > > > > I am adding language to address that: > "Attackers can also use this file as a way to spam unrelated third > parties by listing their resources and/or contact information." > > And: > "Security researchers SHOULD consult the organization's policy, if > available, and review the contact information and/or resources > referenced within the "security.txt" file before submitting reports in > an automated fashion or as resulting from automated scans." > OK. Then what level of automation is required? The semantics of the fields seems hopelessly fuzzy, and so I'm not sure a well-known URI is required. thanks, Rob --00000000000036080d059af81072 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 30, 2019 at 8:00 PM Yakov= Shafranovich <yako= v@nightwatchcybersecurity.com> wrote:
On Mon, Dec 30, 2019 at 10:55 PM Rob Sayre <= ;sayrer@gmail.com= > wrote:
>
> On Tue, Dec 24, 2019 at 7:51 AM Tero Kivinen via Datatracker <noreply@ietf.org> w= rote:
>>
>> Reviewer: Tero Kivinen
>> Review result: Has Issues
>>
>> This document describes text file located in the web server which = can be used
>> to find the information where to contact in case there is security=
>> vulnerabilities that needs to be disclosed.
>>
>> I think this whole idea is BAD, and I do not think we should be pu= blishing this
>> document at all in this format.
>
>
> Yeah... I looked at:
>
> https://tools.ietf.org/html/= draft-foudil-securitytxt-08#section-6.7
>
> "Organizations SHOULD weigh the advantages of publishing this fil= e versus the possible disadvantages and increased resources required to tri= age security reports."
>
> While the draft does spend some time describing the "Scope of the= File", it doesn't address attacks against other parties using pho= ne numbers or emails contained within the file.
>
> For example, it seems possible to register free domain names under TLD= s like .xyz and .tk and then point phone numbers at unsuspecting parties. >

I am adding language to address that:
"Attackers can also use this file as a way to spam unrelated third
parties by listing their resources and/or contact information."

And:
"Security researchers SHOULD consult the organization's policy, if=
available, and review the contact information and/or resources
referenced within the "security.txt" file before submitting repor= ts in
an automated fashion or as resulting from automated scans."

OK. Then what level of automation is required?

The semantics of the fields seems hopelessly fuzzy, = and so I'm not sure a well-known URI is required.

<= div>thanks,
Rob


=C2=A0
--00000000000036080d059af81072-- From nobody Mon Dec 30 20:17:20 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BF612002E for ; Mon, 30 Dec 2019 20:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4a846eqVhFv for ; Mon, 30 Dec 2019 20:17:12 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 EDB021200C7 for ; Mon, 30 Dec 2019 20:17:11 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id b137so19011457pga.6 for ; Mon, 30 Dec 2019 20:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5waYc1slde26c56ZrfAJpRMyzhIyB74Uh6yodjO5XDI=; b=xGMkynkVn5xfujS16oRO5uOv4C0UkrHN+4nfJ8iM000Ls/op4jRtEwNdSVygbkLdt4 WH2BUEjSxAh6CE5qQcLM63wYQ0HE8KrWz1NtlZFo/1gOrheT3JHwcSOSpK4/X2ETZruc aS7idZKpp42zEVsLnAs1ujls4UxP7fGGeHEOm8pD0FcBV5Aqgy2qp7R1dWZqPSwe3X+b sJr3IFEFQxx7g2HNTYn3622eFiVgZkU5sxblsJnXayFIoF+Z8q3Gu2U4ED5ANNZd7ajr m0ImSzyw4nkRL+omQkfjzwKOn7mkMgxo5T+I4kqZaAXtSyT+4Z9L+FSrEywj3c8M6uRY a4hw== 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=5waYc1slde26c56ZrfAJpRMyzhIyB74Uh6yodjO5XDI=; b=l0WOdWYIZot5yOsG8cQcQXJ/cmYM+qcpZfoYwNxWiQkYLi0clNJ4Yz4kdakduUKlt3 uiul9OChRcRbAeBct3fi8cUKqqkMpicMcypVp681D5lDjVGuJ3k4nPIJtCMSUyfJzEVy 5EHNPMbVrT5cYL5PVJXLSZAOMkQF5GfWFA8+P/N0M940RYMym4hf4y+oOFEzwsRiz5K5 LXq8D3o3zbicl+WvnJkGfotY5+2jzzT5Cp7AYfhDHX7qymDfH2gQGZbwcyZdBwtFy7MK HWZa/bkKhjqxh9rmVs3oflRFVjUp3PYZxm1/I/gV2yfR2Razypmr27jK0MJKcBhoWW6Y bfUA== X-Gm-Message-State: APjAAAVFrWz4taqE8UuiBGGAzlC1tnGapoJ1DHF/U6CE9HKjkne8S0JE AjNPjF0soCGU6/d9Z0Wt5mldoofX29pRm00U+8u5qg== X-Google-Smtp-Source: APXvYqw/1OiTV2euAqxtrjpl+an5mqDqhICM3tN+zeWlwQiq5jmcoSgWA31d89HrIhLBJ/nOLR6ubLFz3dwYlsoJ0SM= X-Received: by 2002:a63:e954:: with SMTP id q20mr78800450pgj.204.1577765831044; Mon, 30 Dec 2019 20:17:11 -0800 (PST) MIME-Version: 1.0 References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <24070.38156.658126.30539@fireball.acr.fi> In-Reply-To: <24070.38156.658126.30539@fireball.acr.fi> From: Yakov Shafranovich Date: Mon, 30 Dec 2019 23:16:35 -0500 Message-ID: To: Tero Kivinen Cc: secdir@ietf.org, last-call@ietf.org, draft-foudil-securitytxt.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 04:17:15 -0000 On Fri, Dec 27, 2019 at 6:34 PM Tero Kivinen wrote: > > Yakov Shafranovich writes: > > On Tue, Dec 24, 2019 at 10:51 AM Tero Kivinen via Datatracker > > > Because of this I think > > > providing machine-parseable format is bad, as this can open new security > > > vulnerabilities, when some security problem reporting software parses this file > > > generated by the attacker. Another problem is that even if the parser which > > > parses this properly verifies the contents, the attacker might have changed the > > > reporting locations to devnull@example.com or similar address, and if this > > > report is semi-automatically sent the security reporter might not realize that > > > he is just sending reports to the attacker. > > > > > > > Regarding the parsing issue, this is true for any machine readable > > format on the Internet. This is there is extensive discussion in > > section 6 around these issues. > > Yes, but this is data that I would always assume has been modified by > attacker. The difference is not large, but it is similar than what is > required by firewall code versus networking stack of the normal > operating system. > Would making the language in the security section stronger help with this? Right now we say the following: "Implementers should make sure that any such code is robust against large or malformed files and fields and may choose not to parse files larger than 32 KBs, having fields longer than 2,048 characters or containing more than 1,000 lines." > > > If this kind of file is needed, I think it should be human readable, and only > > > shown to the user making the report, and user should then read it and find out > > > the information where to send the reports. This way there is human in the > > > process verifying that the information provided by the security.txt file is > > > sane. > > > > > > > Human triage is recommended as described in section 6.7. We can make > > this recommendation stronger. > > If human is always recommended when do you think this would be used > automatically and where would the machine-parseable aspect of this > document be required? > > I mean we can keep the exactly same format, but just remove all text > relating to the machine-parseable from the draft. The document will > still stay as machine-parseable as it was before, but it would give > much more emphasis that this do require human interaction. > I will remove the machine-parseable references > > > > More detailed comments follows. > > > > > > In section 3 it says that "security.txt" SHOULD be placed in the /.well-known/ > > > path for web properties. Why is this not MUST? For this to be usable standard, > > > there must be one location which is the authorative for this file. I think this > > > document needs to say that it MUST the in /.well-known/security.txt. > > > Documenting the legacy location in /security.txt is ok, and applications might > > > try to read that also in case the standard "/.well-known/security.txt" is not > > > found. Also it should tell which file is used if multiple copies of > > > security.txt is found and their content is different. > > > > > > > The only reason why it says SHOULD now was due the legacy mechanism > > and my understanding is that using MUST would prohibit the legacy > > mechanism all together. > > No. Those legacy mechanisms could not then claim to be following this > RFC to be until move the file location to correct place. Saying that > the file MUST be at /.well-known/security.txt does not forbid having > that file in other locations too, and does not have any effect on the > legacy systems. > I will change this to MUST > > For multiple copies, the one in .well-known path will take precedence > > but we can make this more explicit. > > I did not find that text at all, so yes, make it more explicit. > Will do > > > Also it seems even this document is not clear whether this is machine-parseable > > > or not. It says it must be text/plain, and has .txt in file name, which would > > > indicate it is just text file, not machine-parseable file. If the real reason > > > is to provide machine-parseable file then .json / .xml or some other really > > > machine-parseable file would be more suitable. On the other hand it also says > > > in several places that security researcher SHOULD check this file and verify > > > that everything looks good and so on. So if human is always needed in the loop, > > > why even try to make this file machine-parseable. We can use the same format > > > even if we do not try to make this file machine-parseable as humans also > > > benefit from having standardized format containing information they need. > > > > > > > Not clear on the concern here - it is intended to be machine readable > > since humans will build tools around it. The human triage will take > > place before report submission but there are a lot of other things > > tools can do prior to that. Additionally, we didn't want people to > > dump anything they wanted into it. > > What kind of other things tools can do prior to that? What is expected > to happen with those tools. Why do we even need the tools. What kind > of software you assume will be reading this file and act based on it? > > > The reason why ".txt" and headers were used since it was meant to be > > an easy to read format and based off "robots.txt", so anyone can > > easily create such file without resorting to XML or JSON. > > Yes, I can understand it being .txt file if it human readable. If it > is supposed to be machine readable, then it will most likely be > machine generated also, meaning any proper machine parseable format > would be better than this one. > > Robots.txt is very bad example, as that file is always machine > readable, there is no reason for humans to read that ever. That file > should be in some more sane format than .txt file. > > To summarize, I think this document should only be meant for humans to > read, and because of that I think we should keep the format and the > .txt format, but we should remove the mentions in the draft that > suggest that this is read by tools or to be machine-parseable. > > Of course it will still stay machine-parseable as same format and same > ABNF will be used, but as this is not intended to be machine readable, > we do not need to emphasize that. > I will remove the machine-parseable language > > > Section 3 also says that "A security.txt file can have an unlimited number of > > > fields." is bit dangerous when there is good probability that this file is > > > generated by attacker. Perhaps provide some suitable limits for the size of > > > this file. As most of the directives only provide pointers to another places, > > > it might be suitable to limit this file in some sane size, for example saying > > > that it SHOULD be less than 64kB, and receiver do not need to parse files > > > larger than 1MB in size. These limits could also be added to section 6.3 if not > > > here. > > > > > > > Section 6.3 says "extraordinarily large" but we can certainly add a > > specific size as an example. > > Different people do have different meaning of extraordinary large. > Some people would consider my examples of 64kB/1MB way too big, and > some would consider them still tiny (when normal web page to download > is several tens of magabytes then 64kB seems like very small). > > Yes, I think it would be good idea to provide some specific limits. > Added this: Implementors SHOULD make sure that any such code is robust against large or malformed files and fields and may choose not to parse files larger than 32 KBs, having fields longer than 2,048 characters or containing more than 1,000 lines. > > > Section 3.2 says that "Only the line most immediately preceding a field SHOULD > > > be associated with that field." meaning that if you have file saying: > > > > > > # Our security policy is provided in the separate domain because the external > > > # company was used to generate it > > > Policy: https://example.com/security-policy.html > > > > > > and this would only associate the 2nd comment line to the Policy field. This > > > can cause unexpected results for people generating this file, as usually they > > > assume that you can add multiple lines of comment and all of them relate to the > > > next field. > > > > > > > This is why it's only a SHOULD and not a MUST. Some context here: > > https://github.com/securitytxt/security-txt/issues/158 > > This whole issue goes away if we do not assume this is > machine-readable but assume it is read by human. Human can very easily > associate comments to suitable keywords. > > I would simply remove the whole text talking about comment and > associated fields. > Will do > > One solution to address this is to allow redirects in all cases but to > > add a stronger warning in section 6 regarding where they may lead and > > that the parsers should be more careful with redirects across domains > > vs. a redirect on the same domain. We had discussions around this and > > there was no clear consensus, which is why this compromise is listed. > > If this is human readable file format then the tool to fetch this will > be web browser or wget or similar. Those will follow readirects > automatically and what we say here does not really matter. > Will address this > One of the problem with redirects is that Canonical is field that can > only appear once, thus there is no way to verify that this > https://example.com/security.txt file should really be something that > should be used when you go there with redirect from > https://signin.example.com/security.txt. > > If there could be multiple Canonical fields then you could list all > the possible locations where this same file could be found, while all > of them redirect them to this location. > That is an excellent idea, I will adjust the language to indicate that multiple "Canonical" fields can appear. > > > How is section 4.3 and 4.2 different. The root directory of the internal host > > > is usually also considered as filesystem, so the rules of 4.2 also cover 4.3. > > > Also why it is important that security.txt is put to the root directory of the > > > filesystem only on internal hosts, but not in external hosts? > > > > > > > The filesystem and internal hosts sections are intended for use cases > > where a researcher has gained access to systems which which might not > > be web servers. So for example, if an SSH host is compromised, the > > "well-known" path would make no sense. > > Yes, but then I would assume that the security.txt would be in the > root directory of that machine, i.e., the section 4.2 would be the one > that applies. So I would simply just remove section 4.3, as I think > 4.2 already covers that. > Will do > > > This document contains lots of SHOULD etc to the actual users of the files > > > (security researchers, organizations etc), which is bit funny. It is quite hard > > > to verify that security researchers really checks the file before using it. It > > > is good thing to give useful instructions for the users, but making them SHOULD > > > or SHOULD NOT is not really helpful. > > > > > > > We were basing this on the guidance in RFC 2119, section 6: > > "In particular, they MUST only be used where it is actually required > > for interoperation or to limit behavior which has potential for > > causing harm" > > > > Specifically, "to limit behavior which has potential for causing harm". > > How are you going to verify that security researches and organzations > are going to follow your SHOULDs? > > I have received question from the customer (from Japan) where they > listed all SHOULDs, MUSTs, and MUST NOTs in the RFC and required to > know which line numbers of our code implement those requirements. For > SHOULDs and MUSTs it sometimes is easy, but for "Implementation MUST > NOT do XXX" is bit harder to pinpoint the exact line numbers NOT doing > XXX... > > If you have SHOULD or MUSTs which cannot be verified at all, or which > depend on the humans, they are always something that is problematic. > For example in IPsec we tried to be very clear that we do not for > example say that users MUST NOT configure their IPsec to use DES, we > said implementations MUST not implement DES. > > There is no point of saying for example this: > > Organizations SHOULD ensure that information in this file and any > referenced resources such as web pages, email addresses and > telephone numbers are kept current, are accessible, controlled by the > organization, and are kept secure. > > Using SHOULD there does not help at all. Changing that to say > "Organizations needs to ensure that ..." would meant that person who > is implementing this will not try to implement that SHOULD... > We are going to remove the RFC 2119 keywords where it makes sense > > > In section 6.6 it says we MUST validated the X.509 certificates of the TLS, but > > > one of the most common security reports I have been doing is a report of the > > > expired certificates, in which case the certificate of the site serving > > > security.txt is also expired, thus to be able to find this I need to allow > > > reading this even when certificate validation failed. > > > > > > > Based on previous discussion on the SAAG list, many members felt very > > strongly that in today's Internet SSL is a MUST. The feedback we > > received so far doesn't seem to indicate that reporting expired > > certificates is all that common. However, we can spell out this use > > case with additional guidance that if the issue being reported is for > > SSL itself, researchers should rely on other mechanisms such as the > > digital signature. > > I have reported expired certificates twice this year already, and both > of them did got fixed in few days after my email... With Lets Encrypt > this is going to be more and more common in the future. > How about adding this language: "In cases where the "security.txt" file cannot be served via HTTPS or is being served with an invalid certificate, additional human triage is recommended since the contents may have been modified while in transit." > > > I wonder do we really need Hiring and Acknowledgements directives? I do not > > > think they are really needed by the security researcher sending reports... > > >https://mailarchive.ietf.org/arch/msg/last-call/ZIftviNdfGbdzruvvffG3KuCcQs > > > > Both are documenting existing usage - they are in active use. > > As this is extensible format and humans known how to skip over unknown > fields anyways it does not matter whether they are in use or not. Do > we really need those fields in the format. What benefits they have? > What use they are for the security researcher using this file? > > Yes, he could use the Acknowledgements directive to verify that his > report is properly acknowledged in that file, but hiring should most > like use some other channels than security.txt. > Acknowledgements directive is used by researchers when deciding whether to report something or not. Some researchers would not report a low severity vulnerability unless there is such page. > Especially the hiring directive information will most likely be out of > date very quickly so it does not go very well with the requirement > that organations SHOULD keep it up to date.... > -- Organizations find it useful which is why we included it. Even if it is not included now, it will probably get submitted to the IANA registry anyway. Thanks From nobody Tue Dec 31 06:38:43 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DCE12001E; Tue, 31 Dec 2019 06:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE2RHk34sRWf; Tue, 31 Dec 2019 06:38:34 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04556120013; Tue, 31 Dec 2019 06:38:33 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xBVEYgo7026314; Tue, 31 Dec 2019 14:38:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=Jn+Ltg4rYWmzXfg0EaC6XpI72e1FZelG9/tZPtmu/ac=; b=hjutoSBSCef/Mvi4mln8/TJPd6OnzFH9U6j8AeJg3ppIWJZBw+Of7TdzLR36lBycnmPv F/Vh9NRKS/g0QMSfXuNrTRC/IiV3Y3oXweTS80i7QBp7TNKhgCi60y9n+uaTKwx141WV 5oWvGb4Gwefgp7u7IYk0p637NAZV1h8sibWSCIOQ6MdroihOO/SSeV9d8jDM8dFBuJNh wTXlzWu9KLK+38naGlV/OlDlAzpaJ7XyWnTEywT0PxICMOa5RPkG/B1Uwi7d7LxxRctn UG0FMKME5D8tyLJcEaVWGxW7N6saoJMQ4nUON/BuiUU23pLDKxR0twJWyqdxSHynWsgH 9Q== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2x60beb2sh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Dec 2019 14:38:32 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xBVEW15H025746; Tue, 31 Dec 2019 09:38:31 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2x638yuxe9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 31 Dec 2019 09:38:31 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 31 Dec 2019 09:38:30 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 31 Dec 2019 09:38:24 -0500 From: "Salz, Rich" To: Rob Sayre , Tero Kivinen CC: "last-call@ietf.org" , "draft-foudil-securitytxt.all@ietf.org" , "secdir@ietf.org" Thread-Topic: [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 Thread-Index: AQHVunIEOmwHJiw0sU6Xr4k62saPi6fT+wUAgABf84A= Date: Tue, 31 Dec 2019 14:38:23 +0000 Message-ID: <31A49EAD-1399-4E1F-AFB2-D1743B8DC718@akamai.com> References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.117.201] Content-Type: multipart/alternative; boundary="_000_31A49EAD13994E1FAFB2D1743B8DC718akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-31_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=620 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912310128 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-31_04:2019-12-30,2019-12-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 suspectscore=0 spamscore=0 clxscore=1011 adultscore=0 mlxlogscore=593 mlxscore=0 phishscore=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912310128 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 14:38:36 -0000 --_000_31A49EAD13994E1FAFB2D1743B8DC718akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgV2hpbGUgdGhlIGRyYWZ0IGRvZXMgc3BlbmQgc29tZSB0aW1lIGRlc2NyaWJpbmcgdGhl ICJTY29wZSBvZiB0aGUgRmlsZSIsIGl0IGRvZXNuJ3QgYWRkcmVzcyBhdHRhY2tzIGFnYWluc3Qg b3RoZXIgcGFydGllcyB1c2luZyBwaG9uZSBudW1iZXJzIG9yIGVtYWlscyBjb250YWluZWQgd2l0 aGluIHRoZSBmaWxlLg0KDQpXaHkgaXMgdGhpcyBmaWxlIHdvcnNlIHRoYW4gYW55IG90aGVyIGZp bGUgb24gYW55IG90aGVyIHdlYiBzZXJ2ZXIgb24gdGhlIEludGVybmV0Pw0K --_000_31A49EAD13994E1FAFB2D1743B8DC718akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <7687EEEC40CF134C9559C8C6656CDB15@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzAw MzgyOTY3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot MTI5ODEyNDcyMCA0ODY1OTkyMDIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+V2hpbGUgdGhlIGRyYWZ0IGRvZXMgc3BlbmQgc29tZSB0aW1lIGRlc2NyaWJpbmcgdGhl ICZxdW90O1Njb3BlIG9mIHRoZSBGaWxlJnF1b3Q7LCBpdCBkb2Vzbid0IGFkZHJlc3MgYXR0YWNr cyBhZ2FpbnN0IG90aGVyIHBhcnRpZXMgdXNpbmcgcGhvbmUgbnVtYmVycyBvciBlbWFpbHMgY29u dGFpbmVkIHdpdGhpbiB0aGUgZmlsZS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldoeSBpcyB0aGlzIGZpbGUgd29yc2UgdGhhbiBhbnkgb3RoZXIgZmlsZSBvbiBhbnkgb3Ro ZXIgd2ViIHNlcnZlciBvbiB0aGUgSW50ZXJuZXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_31A49EAD13994E1FAFB2D1743B8DC718akamaicom_-- From nobody Tue Dec 31 08:24:21 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124E01201E3; Tue, 31 Dec 2019 08:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 RHm4anAwWLJB; Tue, 31 Dec 2019 08:24:16 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 CB63A12022E; Tue, 31 Dec 2019 08:24:09 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47nKPL5mQ4zDmr; Tue, 31 Dec 2019 17:24:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1577809446; bh=VYkA9lhmGcOcob4jLQcj40xT3IKojt/FznMDS5vM6kk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=sVSqUVcgpXBsMXnBSeKA5zmDdbR2n76GVSXzgymSc6hu8jJkgjk9/lu8JJ9Pjv7lV ylUcx6mnRLcz72zbrrgSGgCeqpOzlHQbko5rxrNem3YLGQOmv6oVtrpLOgT6hrJw3h kBN1zRAeKoT7ymadOTgyxKA/ND4rXspBfu07dBQs= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id j8txqI6MRWIv; Tue, 31 Dec 2019 17:24:05 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 31 Dec 2019 17:24:04 +0100 (CET) Received: from [10.168.12.4] (unknown [199.119.233.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id DA85460011A1; Tue, 31 Dec 2019 11:24:03 -0500 (EST) Content-Type: multipart/alternative; boundary=Apple-Mail-8CCD600C-7638-48D7-BC5D-65B775AA0C1C Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16G102) In-Reply-To: <31A49EAD-1399-4E1F-AFB2-D1743B8DC718@akamai.com> Date: Tue, 31 Dec 2019 11:23:54 -0500 Cc: Rob Sayre , Tero Kivinen , "last-call@ietf.org" , "draft-foudil-securitytxt.all@ietf.org" , "secdir@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <3BD71349-2298-4B5C-B422-EB7D563F833D@nohats.ca> References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <31A49EAD-1399-4E1F-AFB2-D1743B8DC718@akamai.com> To: "Salz, Rich" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 16:24:20 -0000 --Apple-Mail-8CCD600C-7638-48D7-BC5D-65B775AA0C1C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Dec 31, 2019, at 09:38, Salz, Rich wrote: >=20 > While the draft does spend some time describing the "Scope of the File", i= t doesn't address attacks against other parties using phone numbers or email= s contained within the file. > =20 > Why is this file worse than any other file on any other web server on the I= nternet? Because those files are not claiming to be authoritative about a security co= ntact or report method, and can mislead. If I am a hacker and I gain access, I will want to change this file so the r= eal administrator isn=E2=80=99t notified. How does a security researcher kno= w they aren=E2=80=99t the first to find a vulnerability with write access in= the web root? They can=E2=80=99t trust the content, and machine parsing the= content seems incredibly dangerous. Removing or adding some text meant to hint to security researchers that they= should not blindly trust this file basically defeats the whole purpose of t= he file. It just created +1 location for finding possible contact informatio= n. And actually more than one due to the whole =E2=80=9Cdiscovery=E2=80=9D p= rocess described in the draft. The idea is cute and I wish it would work. But it is just adding more danger= ous work to the security researcher. Which is fine if that group wants this.= But it also adds a new risk to administrators. I now need to check all thes= e possible file locations for maliciously uploaded content that I never want= ed to maintain in the first place. That is why I took the rare step of recom= mending this document is not published. It is unfortunately, potentially har= mful to every administrator that is not aware of this document, and might le= ad to not being properly contacted when there is a security issue. (And if s= omeone claims this is not a concern, than they also say this document isn=E2= =80=99t needed at all) Paul= --Apple-Mail-8CCD600C-7638-48D7-BC5D-65B775AA0C1C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Dec 31, 2019, a= t 09:38, Salz, Rich <rsalz@akamai.com= > wrote:

  • While the draft does spend some time describing the "Scope of the File"= , it doesn't address attacks against other parties using phone numbers or em= ails contained within the file.

 

Why is this file worse than any other file on any oth= er web server on the Internet?


Because those files are not claiming to be= authoritative about a security contact or report method, and can mislead.
If I am a hacker and I gain access, I will want to change t= his file so the real administrator isn=E2=80=99t notified. How does a securi= ty researcher know they aren=E2=80=99t the first to find a vulnerability wit= h write access in the web root? They can=E2=80=99t trust the content, and ma= chine parsing the content seems incredibly dangerous.

Removing or adding some text meant to hint to security researchers that t= hey should not blindly trust this file basically defeats the whole purpose o= f the file. It just created +1 location for finding possible contact informa= tion. And actually more than one due to the whole =E2=80=9Cdiscovery=E2=80=9D= process described in the draft.

The idea is cute a= nd I wish it would work. But it is just adding more dangerous work to the se= curity researcher. Which is fine if that group wants this. But it also adds a= new risk to administrators. I now need to check all these possible file loc= ations for maliciously uploaded content that I never wanted to maintain in t= he first place. That is why I took the rare step of recommending this docume= nt is not published. It is unfortunately, potentially harmful to every admin= istrator that is not aware of this document, and might lead to not being pro= perly contacted when there is a security issue. (And if someone claims this i= s not a concern, than they also say this document isn=E2=80=99t needed at al= l)

Paul
= --Apple-Mail-8CCD600C-7638-48D7-BC5D-65B775AA0C1C-- From nobody Tue Dec 31 15:06:10 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37D4120052; Tue, 31 Dec 2019 15:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2PxGHMvIckZ; Tue, 31 Dec 2019 15:06:01 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 4D627120019; Tue, 31 Dec 2019 15:06:01 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id f5so31256220ilq.5; Tue, 31 Dec 2019 15:06:01 -0800 (PST) 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=xYcsNqd+DqqS3+7n839qrlMWm1IJuNGwoRlOIsDj5Ak=; b=psF+Jjpe/SDTPv/gpd9MTOmVEr81NBx7C3JdMmwJZWtCkwsA75EbSrx50eNYAEapP4 zsLqsxcO5XoGxUVcKcSfVhgw/EnNGNsUc9VU7kHwlI6D6PyiQdlsGkIJXIDWLuqGSYyZ qXDQGI/QwWeKSJqZYpieLrIdgB/h2koMnsQtlIVh/NPkEVShgoa/k8K17ZNamFIk12YL m52qWVVQ6JaSd+xEd8FQiSJqybvXnffU0enxkag2P2nnulZSLD/7vovPdR5LB0o9oyWd pslHdIxxNd24bmGAmSc8NIdRksxisMOXGjxl5EzrsqX5ZLF+RsbhWp2IfHd+bfZeRwFg zdvQ== 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=xYcsNqd+DqqS3+7n839qrlMWm1IJuNGwoRlOIsDj5Ak=; b=RQTH37xZLor9GqYObGruj5Ybs4RdRkIVnEsef0UyRmpMLnp0c3NWYXTmgsvW+r2P22 is6uQwQQl7qprVCjlqBvBm0i9khM+mfLZk9yWLnNqHryxtWeu929797NLrR8DryVPGkU /ABK93mjKohOHN/aTTAG9m9wlUvbQOrlRXjTAmsgBnfgbMmp2r1RxcrnVa+HVHP7YlLw 0kjH9iZUfColad3MA77B533s/3ezlB6PTDG+Uwsi3D3SdUXHY0tK9l4LJT0bSjuHSWy5 Yc9lxlQ7B4MVhA/EI4TnIzxOPYaajS4KlsY/QQC8thXOjhhi5MuwGJNfozTQsFn41jkf SPUA== X-Gm-Message-State: APjAAAXDaEyaCaR6kqqFCMY144CoJwgIYHsDPNVVONj7C7F4cq5FDkIV 31fWKIZdLr04vPnDbjffzZcP627KU92jgNoSppCxNQA2 X-Google-Smtp-Source: APXvYqwFRL3FwsSfF6Zsa5Sr8FB2+1d+9zURFZqrccDjDkukwgZm2auHwItznmxPZ2zgP+WR31xJdDR4sJFjIQh1Q88= X-Received: by 2002:a92:4514:: with SMTP id s20mr47995897ila.254.1577833560521; Tue, 31 Dec 2019 15:06:00 -0800 (PST) MIME-Version: 1.0 References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <31A49EAD-1399-4E1F-AFB2-D1743B8DC718@akamai.com> In-Reply-To: <31A49EAD-1399-4E1F-AFB2-D1743B8DC718@akamai.com> From: Rob Sayre Date: Tue, 31 Dec 2019 15:05:48 -0800 Message-ID: To: "Salz, Rich" Cc: Tero Kivinen , "last-call@ietf.org" , "draft-foudil-securitytxt.all@ietf.org" , "secdir@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e3bf76059b080051" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 23:06:05 -0000 --000000000000e3bf76059b080051 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 31, 2019 at 6:38 AM Salz, Rich wrote: > > - While the draft does spend some time describing the "Scope of the > File", it doesn't address attacks against other parties using phone numbers > or emails contained within the file. > > > > Why is this file worse than any other file on any other web server on the > Internet? > It's not, but it isn't better either. :) thanks, Rob --000000000000e3bf76059b080051 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 31, 2019 at 6:38 AM Salz, Ric= h <rsalz@akamai.com> wrote:
  • While the draft does spend some time describing the "Scope o= f the File", it doesn't address attacks against other parties usin= g phone numbers or emails contained within the file.

    • =C2=A0

    Why is this file worse than any other file on any ot= her web server on the Internet?


=
It's not, but it isn't better either. :)

<= /div>
thanks,
Rob=C2=A0

--000000000000e3bf76059b080051--