From nobody Tue Nov 1 09:16:20 2016 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 4659A1294B1; Tue, 1 Nov 2016 09:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_PASS=-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=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taich8SNmDwB; Tue, 1 Nov 2016 09:16:14 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0114.outbound.protection.outlook.com [23.103.200.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6781512945F; Tue, 1 Nov 2016 09:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NXA0W8njJ6Qv9xv18KSwRYIeeaQvSOkg1fz2H6P6Qbo=; b=GH1LUAJj6m1p/XfE7veFNk0kMPoreRU4+97byojgS7cZXPzn+Z3uRY7NmX1XvtcyZf+Sop/Un0aFVeZ9w4x94z5627LdaQJJOdjOpVEcSa5gNgHQWIMgScrHKlXlYh4+ZIYwrBuq4hPNRzkqS5Pz3/VS/2jWUDZbfC2Tvtno+j8= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1438.namprd09.prod.outlook.com (10.173.50.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Tue, 1 Nov 2016 16:16:13 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0679.020; Tue, 1 Nov 2016 16:16:13 +0000 From: "Waltermire, David A. (Fed)" To: "'iesg@ietf.org'" , "secdir@ietf.org" , "draft-ietf-l2tpext-keyed-ipv6-tunnel.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-l2tpext-keyed-ipv6-tunnel-07 Thread-Index: AdIzhqYgrbRnXbHOTYSnuKHT3a2shw== Date: Tue, 1 Nov 2016 16:16:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 9e892844-b353-4ff8-d7bd-08d40272664f x-microsoft-exchange-diagnostics: 1; MWHPR09MB1438; 7:pUh9vz0GHaT9c+Ai7QutLQDlHhj80Ckkjyl33u4bX4N445G1NH1hGhP+Sxrvwt7b1t7lHlUMHHd1GfiwvYsoVfmkwfCjS+wtvfHy7sDGs4eYXWqNcb46dYyTyezS4g5WmpdKNVcXoxr9Y9vtN/Ty1sH/7cvQ/uwpO4mQl9NYiieKcCwSUGPkITgUGcuEky+Li3r8/HKo9xCEmpFBOfUIoIUdUhr4Imb7PkGlTGBzHfVAydNcFv5FzNZ7unCyOAFL7o+j1QgasPVLMWYJQzt+Pba9t6zwCMEriLrcUCQS+ByPCMZs/JZXb9W0QpYi5J9xrgpC6C14J0sRheORfmYz1xtFYPXRQxctGBEa4zYXS0s= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1438; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:MWHPR09MB1438; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1438; x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(7846002)(74316002)(7736002)(66066001)(305945005)(5660300001)(50986999)(11100500001)(450100001)(3846002)(8936002)(2900100001)(81156014)(8676002)(77096005)(81166006)(189998001)(54356999)(7696004)(586003)(101416001)(122556002)(6116002)(102836003)(87936001)(229853001)(3280700002)(106356001)(99286002)(105586002)(107886002)(2906002)(33656002)(10400500002)(97736004)(68736007)(86362001)(76576001)(92566002)(5002640100001)(3660700001)(9686002)(2501003)(5001770100001)(2201001)(230783001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1438; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2016 16:16:12.9356 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1438 Archived-At: Subject: [secdir] Secdir review of draft-ietf-l2tpext-keyed-ipv6-tunnel-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 16:16:16 -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 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. Summary: Ready This standards track draft describes a mechanism for establishing an Ethern= et tunnel over IPv6 using L2TPv3 encapsulation. IPv6 is ideal since unique = IP addresses can be used to when establishing a L2TPv3 session. This can al= low for an optimization, over current multiplexing approaches, where consul= ting the L2TPv3 session ID is not needed if each tunnel is assigned a uniqu= e IPv6 address.=20 I found that the draft clearly articulates the problem that is solved. The = security considerations seem to be appropriate for the draft. This draft ap= pears to be ready for publication. Regards, Dave Waltermire From nobody Thu Nov 3 04:16:43 2016 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 1A0A71299A7 for ; Thu, 3 Nov 2016 04:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 byu08aXQmbCQ for ; Thu, 3 Nov 2016 04:16:39 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 688B41298C6 for ; Thu, 3 Nov 2016 04:16:37 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uA3BGWZL000710 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 3 Nov 2016 13:16:32 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uA3BGVq1004420; Thu, 3 Nov 2016 13:16:31 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22555.7311.916527.166699@fireball.acr.fi> Date: Thu, 3 Nov 2016 13:16:31 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 11:16:41 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Paul Hoffman is next in the rotation. For telechat 2016-11-03 Reviewer LC end Draft Simon Josefsson TR2016-09-22 draft-harkins-salted-eap-pwd-07 Matthew Miller T 2016-10-06 draft-ietf-stox-7248bis-13 Melinda Shore T 2016-10-25 draft-ietf-httpauth-mutual-10 Takeshi Takahashi T 2016-10-25 draft-ietf-httpauth-mutual-algo-06 Paul Wouters T 2016-11-01 draft-ietf-stir-passport-10 Dacheng Zhang T 2016-11-03 draft-ietf-netmod-routing-cfg-24 For telechat 2016-12-01 Derek Atkins T 2016-11-27 draft-ietf-siprec-callflows-07 Ben Laurie TR2016-10-10 draft-levine-herkula-oneclick-08 Tina TSOU T 2016-11-14 draft-ieee-urn-02 For telechat 2016-12-15 Dan Harkins T 2016-11-16 draft-ietf-dprive-dnsodtls-12 Last calls and special requests: Shaun Cooley 2016-11-03 draft-ietf-kitten-pkinit-freshness-07 Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Donald Eastlake 2016-11-03 draft-ietf-appsawg-mdn-3798bis-15 Shawn Emery 2016-11-03 draft-ietf-payload-rtp-ancillary-06 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Olafur Gudmundsson 2016-11-09 draft-ietf-justfont-toplevel-03 Phillip Hallam-Baker 2016-11-23 draft-holmberg-dispatch-received-realm-08 Steve Hanna 2016-11-10 draft-ietf-dnsop-resolver-priming-09 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-11 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-15 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-07 Carl Wallace 2016-11-02 draft-ietf-kitten-rfc6112bis-02 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-10 Tom Yu 2016-11-15 draft-leiba-3967upd-downref-00 -- kivinen@iki.fi From nobody Fri Nov 4 15:01:45 2016 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 0ECE7129601; Fri, 4 Nov 2016 10:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1478281801; bh=sj1vuTOsCAZxia7XDXsE/IG5s+X/lxNC/qKTmB4uGuA=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=MZLw5pkVg1wSgPdgQHoVjKUI4/vchqf3QKgL6dXT8IvFMXYKsemmewTIN6a8xnObU Rqxq1k74tGL2twbHvY6rf1sup9Q93PJ9Ll3zI6c762JuRxlHpyWjP0ADH+iAjMPPFj D2Mv8YP0QuvqSUiXHycvWjSwN1QLBWbUOMHAIf8Q= 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 E5C201295FE for ; Fri, 4 Nov 2016 10:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 Ia48os2ZsfXz for ; Fri, 4 Nov 2016 10:49:58 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA14512961E for ; Fri, 4 Nov 2016 10:49:11 -0700 (PDT) Received: from boc06-4-78-216-15-101.fbx.proxad.net ([78.216.15.101] helo=[192.168.0.10]) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1c2ic2-0008Ri-M1; Fri, 04 Nov 2016 17:49:10 +0000 From: Coralie Mercier Date: Fri, 4 Nov 2016 18:49:08 +0100 To: new-work@ietf.org Message-Id: <0C87BDE2-4988-4F21-9B2E-6EB618C4068E@w3.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 04 Nov 2016 15:01:43 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Accessibility Guidelines Working Group (until 2016-12-02) 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, 04 Nov 2016 17:50:01 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBBY2Nlc3Np YmlsaXR5IEd1aWRlbGluZXMgV29ya2luZyBHcm91cDoKICBodHRwczovL3d3dy53My5vcmcvMjAx Ni8xMS9wcm9wb3NlZC1hZy1jaGFydGVyCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRoYXQgdGhlIGNv bW11bml0eSBpcyBhd2FyZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBkcmFmdCBjaGFy dGVyIGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZpZXcgcGVyaW9k LgoKVzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2ggMjAxNi0xMi0wMiBvbiB0aGUK cHJvcG9zZWQgY2hhcnRlci4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8KcHVibGljLW5ldy13b3Jr QHczLm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiAgaHR0cDovL2xpc3RzLnczLm9y Zy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBjb21tZW50cyBz ZW50IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRlZSBSZXByZXNl bnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29tbWVudHMuIElm IHlvdSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0ZQp5b3VyIGNv bW1lbnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUuIEZvcgpl eGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlhIHRoaXMgbGlz dCBhbmQKaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZSByZWZlciB0 byBpdCBmcm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KCklmIHlvdSBzaG91 bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNl CmNvbnRhY3QgTWljaGFlbCBDb29wZXIgPGNvb3BlckB3My5vcmc+IGFuZCBTaGFkaSBBYm91LVph aHJhIDxzaGFkaUB3My5vcmc+LCBUZWFtIENvbnRhY3RzLgoKVGhhbmsgeW91LAoKQ29yYWxpZSBN ZXJjaWVyLCBIZWFkIG9mIFczQyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6 Ly93d3cudzMub3JnL0NvbnNvcnRpdW0vTWVtYmVyL0xpc3QKCuKAlApDb3JhbGllIE1lcmNpZXIg IC0gIFczQyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucyAtICBodHRwOi8vd3d3LnczLm9yZwpt YWlsdG86Y29yYWxpZUB3My5vcmcgKzMzNiA0MzIyIDAwMDEgaHR0cDovL3d3dy53My5vcmcvUGVv cGxlL0NNZXJjaWVyLwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Mon Nov 7 15:16:54 2016 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 D686C129BEE for ; Mon, 7 Nov 2016 15:16:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 FJikHVYTrspB for ; Mon, 7 Nov 2016 15:16:44 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 2CD33129BC2 for ; Mon, 7 Nov 2016 15:16:44 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id w194so134764165vkw.2 for ; Mon, 07 Nov 2016 15:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=sEyWmh7f91qHlComdUZ/h+CSyjk1cebFXCN3uNUs9lQ=; b=eXfExXC5twgc4QZ+E7jOj5FAbAzS7H4pF/Zs6wXpeBOKPFoxUc/6a8XOhu+FjrWVHr rLWjluQTm5aNg7MtprndwkNAKPNxdLRdGxYEsGqtTNfBP0k/KHkeCAABuaNU52GLVjP3 EtM6Mkk7w3vKVkfS3dTeyF6c1dpX5864Eh45U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-transfer-encoding; bh=sEyWmh7f91qHlComdUZ/h+CSyjk1cebFXCN3uNUs9lQ=; b=ah0yOfd0+CNO+/0vbB0KcFbKRbDBi2VZE7Jq4xAzZQ6/6T3Y62j5zHtB/axfJW4vRf tXwL9/ddFKmEHshwqEYaCYix/++XM9nsYhp717e4I/gpef33tCvIw60bic+BUWfs8swe thTa9LerrU2FBWv5QwxMPe6Q4YkiNGTS8CEDXyjIQRzDui98ZSYS+kyF8oNFlwMmij5Q buw4z3cfXaF1rG+Y8vmpFwWqy/re0aYauspv3SDzVIL2bHKwQryomBKQgArnbsUmkWgE x+EzxcI1CFH1epC4vwc93IR89FwQUipTaiQ7EJ8wtnptcCeXueV+/I1x2cmgnIsBUgPv e44g== X-Gm-Message-State: ABUngve2MQFT5vZJIKx26PS7Yl6Mh/9aDXExCJZWIgNtRKG9wIYSc/NgA1io5kEbM7hHKw== X-Received: by 10.31.125.136 with SMTP id y130mr6215553vkc.1.1478560603040; Mon, 07 Nov 2016 15:16:43 -0800 (PST) Received: from [10.83.104.17] ([64.94.31.206]) by smtp.googlemail.com with ESMTPSA id f195sm1209245vke.24.2016.11.07.15.16.38 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 07 Nov 2016 15:16:41 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.5.8.151023 Date: Mon, 07 Nov 2016 18:16:46 -0500 From: Carl Wallace To: Message-ID: Thread-Topic: secdir review of draft-ietf-kitten-rfc6112bis-02 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: The IESG , secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-kitten-rfc6112bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 23:16:47 -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. draft-ietf-kitten-rfc6112bis-02 is an update that obsoletes RFC 6112. It's a copy of 6112 with a few corrections, some word-smithing and a small amount of new text. A few minor comments are below: - RFC6112 should appear in the bibliography. - I'd add a few more items to section 1.1 (changes since 6112) to call out the corrections to type names from RFC4556 and highlight the KeyExchange->KEYEXCHANGE change. Rationale for the MUST->SHOULD change might be nice here too. - The IANA considerations section was right in 6112, but probably doesn't belong here (at not least as defining a 'new' well-known name). From nobody Tue Nov 8 00:08:35 2016 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 AE2BE1294F3 for ; Tue, 8 Nov 2016 00:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, 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 1Z3gJ47SDg12 for ; Tue, 8 Nov 2016 00:08:31 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 B30E4129468 for ; Tue, 8 Nov 2016 00:08:31 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uA888T3k016167 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Nov 2016 08:08:30 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id uA888TDn008224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Nov 2016 08:08:29 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uA888T18013687; Tue, 8 Nov 2016 08:08:29 GMT Received: from [10.154.129.130] (/10.154.129.130) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Nov 2016 00:08:28 -0800 References: <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com> To: "secdir@ietf.org" From: Shawn M Emery X-Forwarded-Message-Id: <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com> Message-ID: <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com> Date: Tue, 8 Nov 2016 01:10:50 -0700 User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: draft-ietf-payload-rtp-ancillary.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-payload-rtp-ancillary-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 08:08:33 -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. This draft specifies a Real-time Transport Protocol (RTP) payload format for ancillary data; including time code, Closed Captioning, and Active Format Description (AFD). The security considerations section does exist and refers to the base protocol specification of RTP and any profile utilized for consideration. The section continues that RTP does not require a single media solution, referencing RFC 7202, and references RFC 7201 for various mechanisms to secure RTP. I agree with this assertion. The section goes on to discuss the specific payload data and how to mitigate against attack by first sanity checking said data. I'm OK with this assertion, except for the integrity check using Checksum_Word. The nine bit checksum based on summing the nine least significant bits of four out of dozens of possible data fields doesn't seem to provide sufficient coverage for this check. General comments: None. Editorial comments: Abstract: Does RTP and SMPTE need to be expanded first? Abstract: Is SMPTE ST 291-1 a normative reference? s/an SDI/a SDI/ Shawn. -- From nobody Tue Nov 8 17:35:46 2016 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 5882E129447; Tue, 8 Nov 2016 17:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, 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 ZXhumPwIUDA0; Tue, 8 Nov 2016 17:35:38 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 EAC1A129459; Tue, 8 Nov 2016 17:35:37 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uA91Za0l013488 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Nov 2016 01:35:36 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id uA91ZZ0T017318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Nov 2016 01:35:35 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id uA91ZVt1026483; Wed, 9 Nov 2016 01:35:32 GMT Received: from [10.154.110.154] (/10.154.110.154) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Nov 2016 17:35:31 -0800 To: Carl Wallace , draft-ietf-kitten-rfc6112bis.all@ietf.org References: From: Shawn M Emery Message-ID: <98bb9070-051e-a63e-2c1d-8285ce4afc9c@oracle.com> Date: Tue, 8 Nov 2016 18:37:53 -0700 User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: Greg Hudson , The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-kitten-rfc6112bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 01:35:39 -0000 On 11/ 7/16 04:16 PM, 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. > > draft-ietf-kitten-rfc6112bis-02 is an update that obsoletes RFC 6112. It's > a copy of 6112 with a few corrections, some word-smithing and a small > amount of new text. A few minor comments are below: > > - RFC6112 should appear in the bibliography. Done. > - I'd add a few more items to section 1.1 (changes since 6112) to call out > the corrections to type names from RFC4556 and highlight the > KeyExchange->KEYEXCHANGE change. Rationale for the MUST->SHOULD change > might be nice here too. I've updated the section according to your suggestions: -- In Section 7, the pepper2 string, "KeyExchange", is corrected to comply with the string actually used by implementations. The requirement for the anonymous option to be used when an anonymous ticket is used in a TGS request is reduced from a MUST to a SHOULD. At least one implementation does not require this and is not necessary that both be used as an indicator of request type. Corrected the authorization data type name, AD-INITIAL-VERIFIED-CAS, referenced in this document. -- Does this clarify the changes? > - The IANA considerations section was right in 6112, but probably doesn't > belong here (at not least as defining a 'new' well-known name). I've taken out the words 'new' from this section. Thanks for your review and I've made the recommended updates in the next version of the draft. Shawn. -- From nobody Wed Nov 9 07:29:51 2016 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 97CE21295B2 for ; Wed, 9 Nov 2016 07:29:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 aFyZa330afY8 for ; Wed, 9 Nov 2016 07:29:44 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 7F46E1295C0 for ; Wed, 9 Nov 2016 07:29:43 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id x190so258030340qkb.0 for ; Wed, 09 Nov 2016 07:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=yucO373wZ9kH34EyF64oEhMkeOynQevWbdHzSwf6uLA=; b=BnY54Wu6GgiXHlXvNYXE3MASVslhBB7ymozNhpclw8YrB/xtgnQ0jDU+FXpTF2ebEE vOrY22a/ODizp8fH3MgA1nwL5MAUH2HaCSrcODJw6f/TpCq5ezdeio4IKr27o0ycDD7p NBn/FC6SHpAVYEKjccRjrPS3VPnSPcj12sRdE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=yucO373wZ9kH34EyF64oEhMkeOynQevWbdHzSwf6uLA=; b=lYwLCvQJwXdrPSO3LzJdEfVXeoPXyHtc8ee009/+uRILInIEP4++DhVXBXyFlUYxtu f9AsZCPZXZ89k6W5dcsE844krcROPaUYfANH+M2apYVP1bowg5ow3xvbb1tFAiuAQoEY lN3xOF9+xgQJvQQztoYIKnHAVchrhLZu7hbNxgQP0jr95zTE2PHJGoNYUC0uczYBWpeq aYxT+0RQxTtI6jt3PlBltb2q6ZbxGIWdwomoD3zBbK+fIZw5lnR64uDp8eIKydQwht45 eXWLA4NFyNfebQ2s6Qe/tFHIEPbf6wWgCKBBIS8NsMv7NfTuecRjV9q1uiakTAVH8yfn HTEw== X-Gm-Message-State: ABUngvcbh0uIPnjy0VcCvGcEFVAXdLL13mvTN16cWgmlw5vhcohjWUkoI/GxeG1U3/0THg== X-Received: by 10.55.17.143 with SMTP id 15mr140256qkr.297.1478705382555; Wed, 09 Nov 2016 07:29:42 -0800 (PST) Received: from [172.31.98.60] (23-24-118-27-static.hfc.comcastbusiness.net. [23.24.118.27]) by smtp.googlemail.com with ESMTPSA id 29sm60854qtu.21.2016.11.09.07.29.39 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 09 Nov 2016 07:29:41 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.5.8.151023 Date: Wed, 09 Nov 2016 10:29:50 -0500 From: Carl Wallace To: Shawn M Emery , Message-ID: Thread-Topic: secdir review of draft-ietf-kitten-rfc6112bis-02 References: <98bb9070-051e-a63e-2c1d-8285ce4afc9c@oracle.com> In-Reply-To: <98bb9070-051e-a63e-2c1d-8285ce4afc9c@oracle.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: Greg Hudson , The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-kitten-rfc6112bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 15:29:45 -0000 > > > >Does this clarify the changes? Yep. Thanks. > >> - The IANA considerations section was right in 6112, but probably >>doesn't >> belong here (at not least as defining a 'new' well-known name). > >I've taken out the words 'new' from this section. > >Thanks for your review and I've made the recommended updates in the next >version of the draft. > >Shawn. >-- From nobody Thu Nov 10 03:18:11 2016 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 0640012969F for ; Thu, 10 Nov 2016 03:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 WGjrF95RcM7V for ; Thu, 10 Nov 2016 03:17:52 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 CA474129684 for ; Thu, 10 Nov 2016 03:17:51 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uAABHknw012727 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Nov 2016 13:17:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uAABHjZ4004075; Thu, 10 Nov 2016 13:17:45 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22564.22361.733525.708466@fireball.acr.fi> Date: Thu, 10 Nov 2016 13:17:45 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 11:17:54 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Leif Johansson is next in the rotation. For telechat 2016-12-01 Reviewer LC end Draft Derek Atkins T 2016-11-27 draft-ietf-siprec-callflows-07 Shaun Cooley T 2016-11-03 draft-ietf-kitten-pkinit-freshness-07 Donald Eastlake T 2016-11-03 draft-ietf-appsawg-mdn-3798bis-15 Ben Laurie TR2016-10-10 draft-levine-herkula-oneclick-08 Tina TSOU T 2016-11-14 draft-ieee-urn-02 For telechat 2016-12-15 Olafur Gudmundsson T 2016-11-09 draft-ietf-justfont-toplevel-03 Dan Harkins T 2016-11-16 draft-ietf-dprive-dnsodtls-12 Paul Hoffman T 2016-11-28 draft-ietf-manet-dlep-25 Christian Huitema T 2016-11-28 draft-ietf-manet-credit-window-06 Chris Inacio T 2016-11-28 draft-ietf-sidr-bgpsec-algs-15 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Phillip Hallam-Baker 2016-11-23 draft-holmberg-dispatch-received-realm-08 Steve Hanna 2016-11-10 draft-ietf-dnsop-resolver-priming-09 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-11 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-15 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-07 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-10 Tom Yu 2016-11-15 draft-leiba-3967upd-downref-00 -- kivinen@iki.fi From nobody Sat Nov 12 00:26:21 2016 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 DEE53129614 for ; Sat, 12 Nov 2016 00:26:19 -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, 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 kiDVCaKYT6cC for ; Sat, 12 Nov 2016 00:26:18 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 5D4CE1295C6 for ; Sat, 12 Nov 2016 00:26:18 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id p66so23916753pga.2 for ; Sat, 12 Nov 2016 00:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=9gIYW6YQ+1HM4c0EpUg4SD8hmzCM/3I+scd34XyPPpQ=; b=i0gABIwL/uywU4rGo4/i0JnDuPmoJVxptJRxtpbW9u+kqqmxIhsNRbDmUAMXOn/mca DfZEDkrn+5vBGJdJ53aAcEcmp2ZR25IOmND4lsAa2mnJzJtKqkJEAmGZiDlKWtLHZGg0 mTZlqw3m1X2WvdPWizx0Rz61A9TDz1fH71k9RXjMYj9lf3nacV3VKcTWmaAgNC7VxUCJ 6Jc6QnYt3cH41TrHEFTnM1zezTyi65B1UVRm3SrYew2PvZHOAIej+5zHTS59d9LARd3a UIeYFX5+0UoiINQyC5ON0OCdEH9hVK7Yn/MXJOovLSd0XW9OCElRmOpjJP8eiJ/yUZKp Awwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=9gIYW6YQ+1HM4c0EpUg4SD8hmzCM/3I+scd34XyPPpQ=; b=eWA3whkPb/yt3gh4z7QvehuB8JcoiAwR+HPIVqR+q8mZtI7c5t9wvALSGtXEwX2EJN uaIfqAPVIAgKJr6Ydz9bmToalRKGwIgs0qL5LLKK3WEdXYlxj/+oqoJCXbdOlzLDqTlD z0M3evxeyoHAEakC8wScFz39lwaO315UN85leN/+f8Y77p1NmMiYvcPD/nbcJ6+SNEKp WGfHBCLFeHkSdFNbx0fS7xSHa8kTPytjqPHUh2Yt6jLfaMA6quCjU/EcDefneeY+9qSu Nm9IyW4Kp/lULVHvwd7wZfLXfuJlPwe0qse0nuBrF/TPaGQQN5wIuRFj5YAfUqVIaLjP 85zA== X-Gm-Message-State: ABUngvfyQQZT7dFemlJS6dehmI/a+c9Gx6PsSPVxS5NYRFIwf1bxl0pZ7X97dZnxSvGFlg== X-Received: by 10.98.68.84 with SMTP id r81mr15209699pfa.174.1478939177816; Sat, 12 Nov 2016 00:26:17 -0800 (PST) Received: from ?IPv6:2001:67c:370:144:4999:e0db:6edf:ce12? ([2001:67c:370:144:4999:e0db:6edf:ce12]) by smtp.gmail.com with ESMTPSA id d29sm3945743pfk.78.2016.11.12.00.26.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Nov 2016 00:26:17 -0800 (PST) From: kathleen.moriarty.ietf@gmail.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Sat, 12 Nov 2016 17:26:15 +0900 Message-Id: <4ED8CEEC-CB94-42BB-9DE3-1FF71B27F112@gmail.com> To: secdir@ietf.org X-Mailer: iPhone Mail (14B100) Archived-At: Subject: [secdir] Tuesday lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 08:26:20 -0000 Hi, Please do plan on SecDir lunch in Park Ballroom 3. Sorry for the late notic= e on room location. Thanks, Kathleen=20 Please excuse typos, sent from handheld device=20= From nobody Tue Nov 15 21:26:31 2016 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 16C8D129670 for ; Tue, 15 Nov 2016 21:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxgroupinc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcNA8Cx6jw3w for ; Tue, 15 Nov 2016 21:26:27 -0800 (PST) Received: from mx0a-00195501.pphosted.com (mx0b-00195501.pphosted.com [67.231.157.160]) (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 9A251129669 for ; Tue, 15 Nov 2016 21:26:27 -0800 (PST) Received: from pps.filterd (m0082293.ppops.net [127.0.0.1]) by mx0b-00195501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uAG5Metk030837; Tue, 15 Nov 2016 21:26:26 -0800 Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0019.outbound.protection.outlook.com [216.32.180.19]) by mx0b-00195501.pphosted.com with ESMTP id 26rfv90994-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 15 Nov 2016 21:26:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=FoxGroupInc.onmicrosoft.com; s=selector1-fox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SZllpV2ScqyblfR/vUaw+w6QuOY8EAkrS1i4fD8WOkE=; b=BhBHnxZ9569Oyb14I2MkcWAFyY4rLJMUm1r30OPZwGaOl2J3hgyUVrTlT0UiaqAtQ/1fT93drqI/uiYIdfEfWzKxgaX+aoPd+aM3llknJ4gb8qfpzVj8120/iFt8pvFLxPsIpV1W/bohI8Jmv+PVR6+x9BPT8aFD1tiYWkhMQ4g= Received: from CY4PR05MB3109.namprd05.prod.outlook.com (10.172.157.7) by CY4PR05MB3112.namprd05.prod.outlook.com (10.172.160.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Wed, 16 Nov 2016 05:26:25 +0000 Received: from CY4PR05MB3109.namprd05.prod.outlook.com ([10.172.157.7]) by CY4PR05MB3109.namprd05.prod.outlook.com ([10.172.157.7]) with mapi id 15.01.0734.001; Wed, 16 Nov 2016 05:26:25 +0000 From: Thomas Edwards To: Shawn M Emery , "secdir@ietf.org" Thread-Topic: Review of draft-ietf-payload-rtp-ancillary-06 Thread-Index: AQHSOZdWFP/ySUox50iUhVd97kVo0qDamr4A Date: Wed, 16 Nov 2016 05:26:25 +0000 Message-ID: <547619FA-F754-4ACD-B2FB-4593838B487A@fox.com> References: <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com> <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com> In-Reply-To: <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [76.171.122.204] x-microsoft-exchange-diagnostics: 1; CY4PR05MB3112; 7:LRedyvwhQJI5FGaKJltgPNT7W1gsLw7sc1lWJ8MaaoLtjTuac05ITAn2HyrWqbLEBGTBF+KUQAVNSDmUUNLS745vmi0ITF1q3ZVlQW4M4/sFsD+WFwT3hQ1KlOadM5XPoZYjwTbXo0K6SuIcYQrIiXphhuozlVqrf5MDBYjmYqkP9aQAiD6LdXHk9NMzMVtvPDi1HlQP9zT7XFfLUkxnBVjO8cuGiPcBqTNUNpV5KXWs+SvRBhPiQNy72nGIPRshbt8B4q7qE9HzEGGhyXTfP0KCyQ8jWz56w//imagKk9gKhrx5zRtku5bDwS+elsN8/mch8w5bdPmvpfKa4+MtCRvEYRl+M22nZCQqVmHXWzk= x-ms-office365-filtering-correlation-id: 3901b6c3-fb56-41fd-bd7a-08d40de11c00 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR05MB3112; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(177823376758907)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6061324)(6072148); SRVR:CY4PR05MB3112; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3112; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(43784003)(189002)(199003)(377454003)(3660700001)(77096005)(6512003)(2900100001)(189998001)(3280700002)(122556002)(2950100002)(99286002)(36756003)(4326007)(2501003)(66066001)(83716003)(82746002)(83506001)(2906002)(8676002)(68736007)(87936001)(230783001)(86362001)(229853002)(7846002)(33656002)(7736002)(105586002)(81166006)(6116002)(102836003)(92566002)(106356001)(8936002)(3846002)(305945005)(106116001)(97736004)(5001770100001)(50986999)(101416001)(5660300001)(54356999)(76176999)(4001350100001)(6506003)(81156014)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3112; H:CY4PR05MB3109.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2016 05:26:25.3194 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3112 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-15_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611160093 Archived-At: Cc: "draft-ietf-payload-rtp-ancillary.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-payload-rtp-ancillary-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 05:26:29 -0000 U2hhd24sDQoNClRoYW5rcyBhZ2FpbiBmb3IgdGhlIFNlY3VyaXR5IERpcmVjdG9yYXRlIHJldmll dyBvZiBvZiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWFuY2lsbGFyeS0wNiENCg0KUGxlYXNlIHNl ZSBiZWxvdyBmb3IgYSBsaXN0IG9mIHlvdXIgY29tbWVudHMsIG15IHJlc3BvbnNlcywgYW5kIG15 IHN1Z2dlc3RlZCBkcmFmdCBjaGFuZ2VzLg0KDQpDb21tZW50OiDigJxUaGUgW3NlY3VyaXR5IGNv bnNpZGVyYXRpb25zXSBzZWN0aW9uIGdvZXMgb24gdG8gZGlzY3VzcyB0aGUgc3BlY2lmaWMgcGF5 bG9hZCBkYXRhIGFuZCBob3cgdG8gbWl0aWdhdGUgYWdhaW5zdCBhdHRhY2sgYnkgZmlyc3Qgc2Fu aXR5IGNoZWNraW5nIHNhaWQgZGF0YS4gIEknbSBPSyB3aXRoIHRoaXMgYXNzZXJ0aW9uLCBleGNl cHQgZm9yIHRoZSBpbnRlZ3JpdHkgY2hlY2sgdXNpbmcgQ2hlY2tzdW1fV29yZC4gIFRoZSBuaW5l IGJpdCBjaGVja3N1bSBiYXNlZCBvbiBzdW1taW5nIHRoZSBuaW5lIGxlYXN0IHNpZ25pZmljYW50 IGJpdHMgb2YgZm91ciBvdXQgb2YgZG96ZW5zIG9mIHBvc3NpYmxlIGRhdGEgZmllbGRzIGRvZXNu J3Qgc2VlbSB0byBwcm92aWRlIHN1ZmZpY2llbnQgY292ZXJhZ2UgZm9yIHRoaXMgY2hlY2su4oCd DQpSZXNwb25zZTogSW5kZWVkLCB0aGUgbmluZSBiaXQgY2hlY2tzdW0gd29yZCBkb2VzIG5vdCBw cm92aWRlIHN1ZmZpY2llbnQgY292ZXJhZ2UgZm9yIGEgY2hlY2sgYWdhaW5zdCBhdHRhY2suDQpE cmFmdCBjaGFuZ2U6IFRvICJBbHNvIHRoZSBDaGVja3N1bV9Xb3JkIHNob3VsZCBiZSBjaGVja2Vk IGFnYWluc3QgdGhlIEFOQyBkYXRhIHBhY2tldCB0byBlbnN1cmUgdGhhdCBpdHMgZGF0YSBoYXMg bm90IGJlZW4gZGFtYWdlZCBpbiB0cmFuc2l0IiBhZGQgIiwgImJ1dCB0aGUgQ2hlY2tzdW1fV29y ZCBpcyB1bmxpa2VseSB0byBwcm92aWRlIGEgcGF5bG9hZCBpbnRlZ3JpdHkgY2hlY2sgaW4gY2Fz ZSBvZiBhIGRpcmVjdGVkIGF0dGFjay4iDQoNCkNvbW1lbnQ6IEFic3RyYWN0OiBEb2VzIFJUUCBh bmQgU01QVEUgbmVlZCB0byBiZSBleHBhbmRlZCBmaXJzdD8NClJlc3BvbnNlOiBBZ3JlZWQuDQpE cmFmdCBjaGFuZ2U6IEV4cGFuZCBSVFAgYW5kIFNNUFRFIGluIEFic3RyYWN0DQoNCkNvbW1lbnQ6 IElzIFNNUFRFIFNUIDI5MS0xIGEgbm9ybWF0aXZlIHJlZmVyZW5jZT8NClJlc3BvbnNlOiBJIGJl bGlldmUgeWVzLCBkdWUgdG8gc3BlY2lmaWMgZGVmaW5pdGlvbnMgb2YgU1QgMjkxLTEgZGF0YSBm aWVsZHMgc3BlY2lmaWVkIGluIHRoZSBwYXlsb2FkLCBhbmQgRElEL1NESUQgaW5mbyBpbiB0aGUg TWVkaWEgVHlwZSBwYXJhbWV0ZXIuDQpEcmFmdCBjaGFuZ2U6IE5vIGNoYW5nZQ0KDQpDb21tZW50 OiBzL2FuIFNESS9hIFNESS8NClJlc3BvbnNlOiBTREkgaXMgYW4gaW5pdGlhbGlzbS4gIFRoZSBD aGljYWdvIE1hbnVhbCBvZiBTdHlsZSBzdGF0ZXMgIldoZW4gYW4gYWJicmV2aWF0aW9uIGZvbGxv d3MgYW4gaW5kZWZpbml0ZSBhcnRpY2xlLCB0aGUgY2hvaWNlIG9mIGEgb3IgYW4gaXMgZGV0ZXJt aW5lZCBieSB0aGUgd2F5IHRoZSBhYmJyZXZpYXRpb24gd291bGQgYmUgcmVhZCBhbG91ZC4iDQpE cmFmdCBjaGFuZ2U6IE5vIGNoYW5nZQ0KDQotVGhvbWFzDQoNCi0tIA0KVGhvbWFzIEVkd2FyZHMg DQpWUCBFbmdpbmVlcmluZyAmIERldmVsb3BtZW50DQpGT1ggTmV0d29ya3MgRW5naW5lZXJpbmcg YW5kIE9wZXJhdGlvbnMNCnRob21hcy5lZHdhcmRzQGZveC5jb20NClBob25lOiArMS4zMTAuMzY5 LjY2OTYNCjEwMjAxIFdlc3QgUGljbyBCbHZkLg0KTG9zIEFuZ2VsZXMsIENBIDkwMDM1DQoNCiAN Cg0KT24gMTEvOC8xNiwgMTI6MTAgQU0sICJTaGF3biBNIEVtZXJ5IiA8c2hhd24uZW1lcnlAb3Jh Y2xlLmNvbT4gd3JvdGU6DQoNCiAgICBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBw YXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzDQogICAgb25nb2luZyBlZmZvcnQgdG8g cmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuDQog ICAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQg b2YgdGhlIHNlY3VyaXR5DQogICAgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5k IFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UNCiAgICBjb21tZW50cyBqdXN0IGxpa2UgYW55 IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCiAgICANCiAgICBUaGlzIGRyYWZ0IHNwZWNpZmll cyBhIFJlYWwtdGltZSBUcmFuc3BvcnQgUHJvdG9jb2wgKFJUUCkgcGF5bG9hZCBmb3JtYXQNCiAg ICBmb3IgYW5jaWxsYXJ5IGRhdGE7IGluY2x1ZGluZyB0aW1lIGNvZGUsIENsb3NlZCBDYXB0aW9u aW5nLCBhbmQgQWN0aXZlDQogICAgRm9ybWF0IERlc2NyaXB0aW9uIChBRkQpLg0KICAgIA0KICAg IFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGRvZXMgZXhpc3QgYW5kIHJlZmVy cyB0byB0aGUgYmFzZQ0KICAgIHByb3RvY29sIHNwZWNpZmljYXRpb24gb2YgUlRQIGFuZCBhbnkg cHJvZmlsZSB1dGlsaXplZCBmb3IgY29uc2lkZXJhdGlvbi4NCiAgICBUaGUgc2VjdGlvbiBjb250 aW51ZXMgdGhhdCBSVFAgZG9lcyBub3QgcmVxdWlyZSBhIHNpbmdsZSBtZWRpYSBzb2x1dGlvbiwN CiAgICByZWZlcmVuY2luZyBSRkMgNzIwMiwgYW5kIHJlZmVyZW5jZXMgUkZDIDcyMDEgZm9yIHZh cmlvdXMgbWVjaGFuaXNtcyB0bw0KICAgIHNlY3VyZSBSVFAuICBJIGFncmVlIHdpdGggdGhpcyBh c3NlcnRpb24uICBUaGUgc2VjdGlvbiBnb2VzIG9uIHRvIGRpc2N1c3MNCiAgICB0aGUgc3BlY2lm aWMgcGF5bG9hZCBkYXRhIGFuZCBob3cgdG8gbWl0aWdhdGUgYWdhaW5zdCBhdHRhY2sgYnkgZmly c3QNCiAgICBzYW5pdHkgY2hlY2tpbmcgc2FpZCBkYXRhLiAgSSdtIE9LIHdpdGggdGhpcyBhc3Nl cnRpb24sIGV4Y2VwdCBmb3IgdGhlDQogICAgaW50ZWdyaXR5IGNoZWNrIHVzaW5nIENoZWNrc3Vt X1dvcmQuICBUaGUgbmluZSBiaXQgY2hlY2tzdW0gYmFzZWQgb24NCiAgICBzdW1taW5nIHRoZSBu aW5lIGxlYXN0IHNpZ25pZmljYW50IGJpdHMgb2YgZm91ciBvdXQgb2YgZG96ZW5zIG9mIHBvc3Np YmxlDQogICAgZGF0YSBmaWVsZHMgZG9lc24ndCBzZWVtIHRvIHByb3ZpZGUgc3VmZmljaWVudCBj b3ZlcmFnZSBmb3IgdGhpcyBjaGVjay4NCiAgICANCiAgICBHZW5lcmFsIGNvbW1lbnRzOg0KICAg IA0KICAgIE5vbmUuDQogICAgDQogICAgRWRpdG9yaWFsIGNvbW1lbnRzOg0KICAgIA0KICAgIEFi c3RyYWN0OiBEb2VzIFJUUCBhbmQgU01QVEUgbmVlZCB0byBiZSBleHBhbmRlZCBmaXJzdD8NCiAg ICBBYnN0cmFjdDogSXMgU01QVEUgU1QgMjkxLTEgYSBub3JtYXRpdmUgcmVmZXJlbmNlPw0KICAg IHMvYW4gU0RJL2EgU0RJLw0KICAgIA0KICAgIFNoYXduLg0KICAgIC0tDQogICAgDQogICAgDQoN Cg== From nobody Tue Nov 15 23:02:28 2016 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 896C312968A; Tue, 15 Nov 2016 23:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 AtVJ29pa4fFI; Tue, 15 Nov 2016 23:02:25 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 35E94129695; Tue, 15 Nov 2016 23:02:22 -0800 (PST) Received: from [10.32.60.66] (dhcp-8990.meeting.ietf.org [31.133.139.144] (may be forged)) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id uAG728Gv039091 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Nov 2016 00:02:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host dhcp-8990.meeting.ietf.org [31.133.139.144] (may be forged) claimed to be [10.32.60.66] From: "Paul Hoffman" To: draft-ietf-manet-dlep.all@ietf.org, secdir Date: Wed, 16 Nov 2016 16:02:18 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Subject: [secdir] SecDir review of draft-ietf-manet-dlep X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 07:02:26 -0000 Greetings. This is a review of draft-ietf-manet-dlep-15 for the Security Directorate. Please treat these comments as you would any IETF Last Call comments you get. As I understand it, Dynamic Link Exchange Protocol (DLEP) is a protocol for a router and wireless modem to inform each other about characteristics of the link in order to make better routing decisions. It runs over UDP and TCP, and is explicitly meant to be only valid on a single L2 hop directly between the modem and router. (Please let me know if I have this wrong!) There is no security in DLEP. At the end of Section 3, it says: DLEP further requires that security of the implementations (e.g., authentication of stations, encryption of traffic, or both) is dealt with by utilizing Layer 2 security techniques. This reliance on Layer 2 mechanisms secures all DLEP Messages - both the UDP discovery Signals and the TCP control Messages. Further, there is no mandatory-to-implement L2 security protocol; 802.1X and 802.1AE are mentioned as possibly being used, but neither is required to be implemented. This, the specified security is pretty weak. It is not clear what advantage an attacker would get by snooping on the DLEP traffic: the values exchanged are pretty easy to determine just by watching the link. It is also not clear what advantage an attacker would get by impersonating either party or mounting an MITM attack other than degrading the link, which an MITM could do anyways. This feels like a classic IETF "we don't deal with security and leave it to the layer below us" protocol, which might be acceptable in this case because of the nature of the data being exchanged. --Paul Hoffman From nobody Wed Nov 16 21:09:33 2016 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 29D33129538 for ; Wed, 16 Nov 2016 21:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 0m5PlJqevWvf for ; Wed, 16 Nov 2016 21:09:30 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 E6026129628 for ; Wed, 16 Nov 2016 21:09:29 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uAH59PNV016295 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Nov 2016 07:09:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uAH59Ph3007282; Thu, 17 Nov 2016 07:09:25 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22573.15237.778322.822503@fireball.acr.fi> Date: Thu, 17 Nov 2016 07:09:25 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 05:09:32 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Watson Ladd is next in the rotation. For telechat 2016-12-01 Reviewer LC end Draft Derek Atkins T 2016-11-27 draft-ietf-siprec-callflows-07 Shaun Cooley T 2016-11-03 draft-ietf-kitten-pkinit-freshness-07 Donald Eastlake T 2016-11-03 draft-ietf-appsawg-mdn-3798bis-15 Steve Hanna T 2016-11-10 draft-ietf-dnsop-resolver-priming-09 Leif Johansson T 2016-11-30 draft-ietf-6lo-6lobac-06 Benjamin Kaduk T 2016-11-30 draft-ietf-6lo-privacy-considerations-04 Scott Kelly T 2016-11-30 draft-ietf-savi-mix-12 Ben Laurie TR2016-10-10 draft-levine-herkula-oneclick-08 Tina TSOU T 2016-11-14 draft-ieee-urn-03 Tom Yu T 2016-11-15 draft-leiba-3967upd-downref-01 For telechat 2016-12-15 Olafur Gudmundsson T 2016-11-09 draft-ietf-justfont-toplevel-04 Dan Harkins T 2016-11-16 draft-ietf-dprive-dnsodtls-12 Christian Huitema T 2016-11-28 draft-ietf-manet-credit-window-07 Chris Inacio T 2016-11-28 draft-ietf-sidr-bgpsec-algs-16 Simon Josefsson T 2016-12-02 draft-ietf-6lo-dect-ule-07 Charlie Kaufman T 2016-12-02 draft-ietf-6man-default-iids-16 Tero Kivinen T 2016-12-07 draft-ietf-sidr-origin-validation-signaling-09 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Phillip Hallam-Baker 2016-11-23 draft-holmberg-dispatch-received-realm-08 Stephen Kent E None draft-ietf-dnssd-pairing-00 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-11 Warren Kumari 2016-12-08 draft-wilde-json-seq-suffix-00 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-15 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-07 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-10 -- kivinen@iki.fi From nobody Fri Nov 18 20:03:02 2016 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 85102128E18; Fri, 18 Nov 2016 20:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 OsmtMzN0uokR; Fri, 18 Nov 2016 20:02:58 -0800 (PST) Received: from SNT004-OMC3S17.hotmail.com (snt004-omc3s17.hotmail.com [65.55.90.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029D61293F9; Fri, 18 Nov 2016 20:02:57 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.55.90.137]) by SNT004-OMC3S17.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 18 Nov 2016 20:02:57 -0800 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; bh=7fb9NC9MyIioUWFYHnHgWDrcdIJAg5NoNXa0c0zlmX4=; b=S8GtG1QI2sMBELPQt6ojDQayZm6UKFNvpfCJngUOuFA6bW534z94miHnxH/v/vWxRU7bzowjkHQCY6ujCmNubn7lGyGeVPc4U3xGle5lAYDA22lcao9XEoeS3eHlhXHEhrX+u+LfR7zzKZb8t18TLJ4+IU8dCDrIxzfDnFDlNLy3VWb/yLoV/ZLerkZ0gSBMz21+V/jaN/XEVZLikLIcsVNRFULpgbB0fhqX8lh/ILTvNJ/+jPfjN2oAEPrbhZJ46gvnxu7/TB+naXzoyGe9+1KvoQa/03t86Y26LcfN5cZpP7yBYjnasyZirlo6WTyYCvMY25hwfSNQpbQyavQtHg== Received: from CY1NAM02FT034.eop-nam02.prod.protection.outlook.com (10.152.74.53) by CY1NAM02HT157.eop-nam02.prod.protection.outlook.com (10.152.75.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.5; Sat, 19 Nov 2016 04:02:56 +0000 Received: from CY4PR17MB0997.namprd17.prod.outlook.com (10.152.74.51) by CY1NAM02FT034.mail.protection.outlook.com (10.152.75.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.4 via Frontend Transport; Sat, 19 Nov 2016 04:02:56 +0000 Received: from CY4PR17MB0997.namprd17.prod.outlook.com ([10.173.181.7]) by CY4PR17MB0997.namprd17.prod.outlook.com ([10.173.181.7]) with mapi id 15.01.0721.017; Sat, 19 Nov 2016 04:02:56 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , 'The IESG' , "draft-ietf-6man-default-iids.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-6man-default-iids-16 Thread-Index: AQHSQhe/hqED3+8kAUeTD8JTC7NMKQ== Date: Sat, 19 Nov 2016 04:02:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:7421; Count:37 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [iMgBa61nNauVPoY7DNTfm9FDNSxjrV6w] x-incomingheadercount: 37 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; CY1NAM02HT157; 5:IPb8/moFDZcvauy+T+bqo/KRoaDFv3Nxj7rTPRfFG6ZC7km/UuXSe9xG3Y3S1jhNpNtiwScHtSOlVhJaxZg9UNyUaid9e9HgtCHUE4sXUDWLwElmPghXkvBgn9akBW0d1JXFjvDUfio+h8vLT09uKQ==; 24:HiA6+8KAwyb9HPl46HRw7wbagEOv1s66UaPUa/aSYsq0akpPpdPYXrI82p7c/aj1QHA31SP96lVNe26qizViaTeleR8yEHUu9/lG+/Zo70w=; 7:+TWRNSWijCB6mcVRtZf/Fx6WbQMN4KwJUME2VY5lb7aidCuw0BejeZoXpzn+twVQEgx/8SvaUGZGbc9gUDzn5C6/Q+Fmtx/j8CddAMRQ1gyvYAi66GAkZikeNwkeSbMiwjcZO/qakeOOZ2pA3ZFJqsDOuKqsQqhEvpiQ8cJYg0wKLy2EXL+tTsAQTWs0KhtfNti7VvlbZ5kSxNBLzxzRJfljpjmxkPRfSLZab3Kj9qFT6bF8rrnFR5RMGUf5zDrQvZnAhfXeiv0lvo6+yu1Nv+Mmq4HW8SVgosc712gv4vLzK/tmzHDWl0GkAGyb8uRj5T7mGmE4YUJdC32nxg1bnk/W0ZAyRnd+9LBhYDDvmS4= x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1NAM02HT157; H:CY4PR17MB0997.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 20b4ead4-c21c-4025-4a44-08d41030f16d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(1603103113)(1603101340)(1601125047); SRVR:CY1NAM02HT157; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:CY1NAM02HT157; BCL:0; PCL:0; RULEID:; SRVR:CY1NAM02HT157; x-forefront-prvs: 0131D22242 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR17MB09978ED339434C8F19ED4A5FDFB30CY4PR17MB0997namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2016 04:02:55.9477 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT157 X-OriginalArrivalTime: 19 Nov 2016 04:02:57.0528 (UTC) FILETIME=[CFCFBF80:01D24219] Archived-At: Subject: [secdir] Secdir review of draft-ietf-6man-default-iids-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 04:03:00 -0000 --_000_CY4PR17MB09978ED339434C8F19ED4A5FDFB30CY4PR17MB0997namp_ 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 com= ments 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: Ready This is a bookkeeping document with no technical content. At issue is how t= o pick the low order eight bytes of IPv6 addresses. The original vision was= to use the six bytes MAC address or the eight bytes from some other MAC ad= dress assignment mechanism so that addresses could be unique without any sp= ecial configuration. That approach has been problematic. In an increasingly= virtualized world, more and more entities need IPv6 addresses that don't h= ave physical adaptors from which to get MAC addresses. Worse, privacy enthu= siasts believe it will leak too much information about who you are if you u= se the same low order bits in an IPv6 address when connecting to different = network connection points. RFC7217 specified an alternate means for choosing the low order 8 bytes of = IPv6 addresses that will generate consistent addresses when connecting to t= he same network connection point but different addresses when connecting di= fferent ones. There is a growing consensus that this is a better default be= havior. Unfortunately, there are lots of existing RFCs that include contrary advice= ... that still recommend the older mechanism. So this document formally upd= ates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146= , RFC3572, RFC4291, RFC4338, RFC4391, RFC5072, and RFC5121 to reflect the new advice. = If we can do this instead of going back and updating all of those documents= , then there is an administrative savings. If we're also going to go back a= nd amend each of those documents, then I'm not sure what this document is f= or. In any case, there should be no security objections to this document. Any s= uch objections should have been lodged against RFC7217. --Charlie Sent from Outlook --_000_CY4PR17MB09978ED339434C8F19ED4A5FDFB30CY4PR17MB0997namp_ 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. Thes= e comments were written primarily for the benefit of the security area dire= ctors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document is: Ready

This is a bookkeeping document with no technical content. At issue is ho= w to pick the low order eight bytes of IPv6 addresses. The original vision = was to use the six bytes MAC address or the eight bytes from some other MAC= address assignment mechanism so that addresses could be unique without any special configuration. That app= roach has been problematic. In an increasingly virtualized world, more and = more entities need IPv6 addresses that don't have physical adaptors fr= om which to get MAC addresses. Worse, privacy enthusiasts believe it will leak too much information about who yo= u are if you use the same low order bits in an IPv6 address when conne= cting to different network connection points.


RFC7217 specified an alternate means for choosing the low order 8 bytes = of IPv6 addresses that will generate consistent addresses when connecting t= o the same network connection point but different addresses when connecting= different ones. There is a growing consensus that this is a better default behavior.


Unfortunately, there are lots of existing RFCs that include contrary adv= ice... that still recommend the older mechanism. So this document = formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572,

RFC4291, RFC4338, RFC4391, RFC5072, and RFC5121 to reflect the new advice. If w= e can do this instead of going back and updating all of those documents, th= en there is an administrative savings. If we're also going to go back and a= mend each of those documents, then I'm not sure what this document is for.=


In any case, there should be no security objections to this document. Any suc= h objections should have been lodged against RFC7217.<= /font>


--Charlie





Sent from Outlook=

--_000_CY4PR17MB09978ED339434C8F19ED4A5FDFB30CY4PR17MB0997namp_-- From nobody Mon Nov 21 09:26:00 2016 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 6907312957A; Mon, 21 Nov 2016 09:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 TADprHu9bkmz; Mon, 21 Nov 2016 09:25:53 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 604BB12956D; Mon, 21 Nov 2016 09:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1479749152; d=isode.com; s=june2016; i=@isode.com; bh=TawXVUsyf0kmlwxoSV7qhkIvErvFZHAh8E55+nNup+A=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Rp8PJ2+6Axi+eGS+4aWAFXVzWIBmrN0mVbKFkfDsmeiO+FUtjSoRQZEgQKSmwz5vaXI42o 3ADCJH36BruJ3Hj3wWOr+As5Q2Qe0uEmuepvbzp8gbfu9lfoI7jMiS3EVFiobhJczvArhX yHvrcP75k+yKfMjjRR8y76DXnDxF2gU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 21 Nov 2016 17:25:52 +0000 To: =?UTF-8?Q?Julien_=c3=89LIE?= , Barry Leiba References: <20981db3190142193043f1445abadaa3@trigofacile.com> <1b5edd03-675c-01b7-6d06-c2e155987929@trigofacile.com> From: Alexey Melnikov Message-ID: Date: Mon, 21 Nov 2016 17:25:48 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <1b5edd03-675c-01b7-6d06-c2e155987929@trigofacile.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Archived-At: Cc: draft-murchison-nntp-compress.all@ietf.org, IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 17:25:54 -0000 Hi Julien, Sorry for the late followup on this. On 03/10/2016 21:47, Julien =C3=89LIE wrote: > Hi Barry, > > I'm currently reviewing the comments I need to take into account for=20 > the document. > Do you believe I should add a note about a possible security issue as=20 > far as the use of DEFLATE is concerned? (see below) > (An "out of memory" attack?) I think this would be a good idea. Best Regards, Alexey From nobody Mon Nov 21 23:39:37 2016 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 ADB7B129635 for ; Mon, 21 Nov 2016 23:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, 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 DMJEIjL8cq_C for ; Mon, 21 Nov 2016 23:39:34 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 97FB7129462 for ; Mon, 21 Nov 2016 23:39:34 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uAM7dU3J026256 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Nov 2016 07:39:31 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id uAM7dTqE014369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Nov 2016 07:39:30 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uAM7dStE031064; Tue, 22 Nov 2016 07:39:28 GMT Received: from [10.154.108.111] (/10.154.108.111) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Nov 2016 23:39:28 -0800 To: Thomas Edwards , "secdir@ietf.org" References: <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com> <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com> <547619FA-F754-4ACD-B2FB-4593838B487A@fox.com> From: Shawn M Emery Message-ID: <4e0bb21a-50fe-f527-ff70-76daaa747083@oracle.com> Date: Tue, 22 Nov 2016 00:41:52 -0700 User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <547619FA-F754-4ACD-B2FB-4593838B487A@fox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "draft-ietf-payload-rtp-ancillary.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-payload-rtp-ancillary-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 07:39:35 -0000 Hi Thomas, Sorry for the late reply, was out of the office last week. Comments in-line... On 11/15/16 10:26 PM, Thomas Edwards wrote: > Shawn, > > Thanks again for the Security Directorate review of of draft-ietf-payload-rtp-ancillary-06! > > Please see below for a list of your comments, my responses, and my suggested draft changes. > > Comment: “The [security considerations] section goes on to discuss the specific payload data and how to mitigate against attack by first sanity checking said data. I'm OK with this assertion, except for the integrity check using Checksum_Word. The nine bit checksum based on summing the nine least significant bits of four out of dozens of possible data fields doesn't seem to provide sufficient coverage for this check.” > Response: Indeed, the nine bit checksum word does not provide sufficient coverage for a check against attack. > Draft change: To "Also the Checksum_Word should be checked against the ANC data packet to ensure that its data has not been damaged in transit" add ", "but the Checksum_Word is unlikely to provide a payload integrity check in case of a directed attack." I think that this addition more clearly states the limitations of Checksum_Word. > Comment: Abstract: Does RTP and SMPTE need to be expanded first? > Response: Agreed. > Draft change: Expand RTP and SMPTE in Abstract Thanks. > Comment: Is SMPTE ST 291-1 a normative reference? > Response: I believe yes, due to specific definitions of ST 291-1 data fields specified in the payload, and DID/SDID info in the Media Type parameter. > Draft change: No change Other standards track RFCs have referenced SMPTE standards as informative. If you want this to be a normative reference then you will need to call this out in the IETF LC. This allows the community to determine if the standard being referenced meets the criteria of a stable and vetted point of reference. Please see RFC 4897. > Comment: s/an SDI/a SDI/ > Response: SDI is an initialism. The Chicago Manual of Style states "When an abbreviation follows an indefinite article, the choice of a or an is determined by the way the abbreviation would be read aloud." > Draft change: No change OK. Regards, Shawn. -- From nobody Tue Nov 22 03:35:57 2016 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 4EF911295AA; Tue, 22 Nov 2016 03:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 8x_iiiriBGwB; Tue, 22 Nov 2016 03:34:50 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE94C129AEE; Tue, 22 Nov 2016 03:34:46 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 22 Nov 2016 12:34:44 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 22 Nov 2016 12:34:21 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Nov 2016 12:34:20 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Nov 2016 12:34:20 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.03.0279.002; Tue, 22 Nov 2016 11:34:20 +0000 From: "Taylor, Rick (External)" To: Paul Hoffman , "draft-ietf-manet-dlep.all@ietf.org" , secdir Thread-Topic: SecDir review of draft-ietf-manet-dlep Thread-Index: AQHSP9dxooq1deGLb0CN9D0fTSXK8KDk5l2g Date: Tue, 22 Nov 2016 11:34:19 +0000 Message-ID: References: <30706_1479279750_582C0485_30706_8297_7_C7F1D029-C067-4AF6-9F40-436F7BA54311@vpnc.org> In-Reply-To: <30706_1479279750_582C0485_30706_8297_7_C7F1D029-C067-4AF6-9F40-436F7BA54311@vpnc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.22.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Nov 2016 11:34:20.0356 (UTC) FILETIME=[5DAC9840:01D244B4] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-22714.006 X-TM-AS-Result: No--17.696500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Archived-At: X-Mailman-Approved-At: Tue, 22 Nov 2016 03:35:55 -0800 Subject: Re: [secdir] SecDir review of draft-ietf-manet-dlep X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 11:34:53 -0000 Hi Paul, Thank you for the review. A couple of quick comments: Did you review draft-ietf-manet-dlep-15 or draft-ietf-manet-dlep-25 (the la= test)? As we have attempted to address the security comments raised by the= WG and AD review. One area we have worked hard on addressing is mandating use of RFC5082 (Gen= eralized TTL Security) on the link between router and modem (See Section 3.= 1). As you correctly state, DLEP does not have any inherent security mecha= nisms, and recommends link-layer security, such as 802.1X/AE, but we do man= date mechanisms to restrict the protocol to run over a single hop. As you = point out, DLEP is a control-plane protocol and does not carry any user dat= a. We have updated the security considerations (section 12) since draft-15, pl= ease can you see if the new verbiage addresses your valid comments? Many thanks, Rick Taylor -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: 16 November 2016 07:02 To: draft-ietf-manet-dlep.all@ietf.org; secdir Subject: SecDir review of draft-ietf-manet-dlep Greetings. This is a review of draft-ietf-manet-dlep-15 for the Security Di= rectorate. Please treat these comments as you would any IETF Last Call comm= ents you get. As I understand it, Dynamic Link Exchange Protocol (DLEP) is a protocol for= a router and wireless modem to inform each other about characteristics of = the link in order to make better routing decisions. It runs over UDP and TCP, and is explicitly meant to be only valid on a sin= gle L2 hop directly between the modem and router. (Please let me know if I = have this wrong!) There is no security in DLEP. At the end of Section 3, it says: DLEP further requires that security of the implementations (e.g., authentication of stations, encryption of traffic, or both) is dealt with by utilizing Layer 2 security techniques. This reliance on Layer 2 mechanisms secures all DLEP Messages - both the UDP discovery Signals and the TCP control Messages. Further, there is no mandatory-to-implement L2 security protocol; 802.1X an= d 802.1AE are mentioned as possibly being used, but neither is required to = be implemented. This, the specified security is pretty weak. It is not clear what advantage= an attacker would get by snooping on the DLEP traffic: the values exchange= d are pretty easy to determine just by watching the link. It is also not clear what advantage an attacker would get by impersonating = either party or mounting an MITM attack other than degrading the link, whic= h an MITM could do anyways. This feels like a classic IETF "we don't deal with security and leave it to= the layer below us" protocol, which might be acceptable in this case becau= se of the nature of the data being exchanged. --Paul Hoffman This mail has originated outside your organization, either from an external= partner or the Global Internet. Keep this in mind if you answer this message. -- Airbus Defence and Space has taken all possible efforts to ensure this emai= l is free from malicious code; however, never open suspicious emails or att= achments or follow unknown hyperlinks. The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or distribut= ion is prohibited. Please also contact the sender and inform them of the er= ror and delete the e-mail, including any attached files from your system. Emails to Airbus Defence and Space Limited may be processed, recorded and m= onitored anywhere in the European Community. Airbus Defence and Space Limited Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS. Registered in England and Wales under company number 02449259. From paul.hoffman@vpnc.org Tue Nov 22 07:46:14 2016 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 1D2241294F5; Tue, 22 Nov 2016 07:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 WbtUU7SqlT-y; Tue, 22 Nov 2016 07:46:13 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 156D412956A; Tue, 22 Nov 2016 07:46:13 -0800 (PST) Received: from [10.32.60.73] (50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id uAMFjq3X077810 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Nov 2016 08:45:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163] claimed to be [10.32.60.73] From: "Paul Hoffman" To: "Taylor, Rick" Date: Tue, 22 Nov 2016 07:46:05 -0800 Message-ID: <0AE7C2DE-B316-4675-B7BE-EB9AC50ED955@vpnc.org> In-Reply-To: References: <30706_1479279750_582C0485_30706_8297_7_C7F1D029-C067-4AF6-9F40-436F7BA54311@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Cc: secdir , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-manet-dlep X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 15:46:14 -0000 On 22 Nov 2016, at 3:34, Taylor, Rick (External) wrote: > Thank you for the review. A couple of quick comments: > > Did you review draft-ietf-manet-dlep-15 or draft-ietf-manet-dlep-25 > (the latest)? As we have attempted to address the security comments > raised by the WG and AD review. I reviewed -25; sorry for the typo in my report. > One area we have worked hard on addressing is mandating use of RFC5082 > (Generalized TTL Security) on the link between router and modem (See > Section 3.1). As you correctly state, DLEP does not have any inherent > security mechanisms, and recommends link-layer security, such as > 802.1X/AE, but we do mandate mechanisms to restrict the protocol to > run over a single hop. As you point out, DLEP is a control-plane > protocol and does not carry any user data. Noted. However, requiring TTL security doesn't prevent snooping or MITM attacks. --Paul Hoffman From nobody Tue Nov 22 08:35:50 2016 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 224AC129606; Tue, 22 Nov 2016 08:35:49 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 QbLqhz4TR0OR; Tue, 22 Nov 2016 08:35:46 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976F21296CB; Tue, 22 Nov 2016 08:35:46 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id uAMGZjTA014003; Tue, 22 Nov 2016 11:35:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1479832545; bh=ZcAGq0fK4V5GkMgmzMO3TVh/fIlKDWDN8LJhpkOX5Hw=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:In-Reply-To: References; b=EriEsbYuQQf+1eTs1mJalOg2tgLWMIJdpUH3TewOzNHm5Jl4iceimXAgIYQwbFMgD ii+cNi6ZlTCEUR1aZqfNjBr4loyYjXwmBvD8No49S1bFnGKgNX+1afymR5keM+l6ld IRW5mT6fn4c0kmWygUuXRLsWKcJ83VUUJBH/FCdA= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id uAMGZe6D012831; Tue, 22 Nov 2016 11:35:40 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0319.002; Tue, 22 Nov 2016 11:35:39 -0500 From: Chris Inacio To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-sidr-bgpsec-algs-16.all@tools.ietf.org" Thread-Topic: SECDIR review of draft-ietf-sidr-bgpsec-algs-16 Thread-Index: AQHSRN51t+tWjKyq8EGqOIAmo07R6A== Date: Tue, 22 Nov 2016 16:35:39 +0000 Message-ID: <2C424863-2993-4E7C-9B32-F35A5404422D@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.51.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <7044C60E2993B645B8FB0897AA9A6C19@sei.cmu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [secdir] SECDIR review of draft-ietf-sidr-bgpsec-algs-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 16:35:49 -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 com= ments 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: Ready with nits NIT: Section 3.1 Public Key Format "Section 2.1.1" links to the current document and not to RFC5480 in the= initial reference. -- Chris Inacio inacio@cert.org From nobody Tue Nov 22 10:57:04 2016 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 114751296A3 for ; Tue, 22 Nov 2016 10:57:03 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 sQn25jXPrHoH for ; Tue, 22 Nov 2016 10:57:01 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDFE12956B for ; Tue, 22 Nov 2016 10:57:00 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id w33so18333734qtc.3 for ; Tue, 22 Nov 2016 10:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AEsIcaqiQXW7rnW4G8UnI+PqtVU3atM2WdTfWSJ8tGc=; b=ZOYWrOIbp3jv+7bqeEwORdS22UuMFn8D9sgVFwHTSZK3fMASJc4uXEb0uJm2q3wh5b noCy3Gb7UuOO+Wi3ACnkF2i9eHt/lnYxvZT1LsHS4ur8eP6WICC3RPLbSXXYIaQLG0pr eewNT8g5KEbFynWLeroTdxdsmI/UvXvTU+i4E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AEsIcaqiQXW7rnW4G8UnI+PqtVU3atM2WdTfWSJ8tGc=; b=KPkPqdCPiPx3paOCy/9ehKD054HopOeukHALX5HxU9VvrIegvAI9gM4/opdcQdOtwd orfBpiDN2NnDFOOkLxu4S+ynenk1b5DHWPu4wkF8f3hkg/XxfgTn2T+NAIB/MCnqB1KZ ytfpRU7w1RMPkjI7bPlExcQNTdSNpaifLGR7UjVTgoWQHdq0eQa0Kt0LNNiX2/Qgj0JH smaJzI8G2EL1/RW7Vp97U5Wh79mdiqi2bzjXSsPN26G1rnKnWyQO2lfEBc9JRIpj9kE2 2y/UssdC65EU21fUMGr+y40Cc3M10ebejZNkNxiz7vLgJaIYUog7UV/T4vvwQNIMmn3w pu9A== X-Gm-Message-State: AKaTC00P2nWyeR5CSbxL4tNlomm5YyVpThT+6vuhTUteveGtBT0E2iB8uIN2LOQBc9Iskw== X-Received: by 10.200.50.35 with SMTP id x32mr14805942qta.78.1479841019176; Tue, 22 Nov 2016 10:56:59 -0800 (PST) Received: from [172.16.0.92] ([96.231.230.70]) by smtp.gmail.com with ESMTPSA id 14sm14398368qtp.19.2016.11.22.10.56.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Nov 2016 10:56:58 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <2C424863-2993-4E7C-9B32-F35A5404422D@cert.org> Date: Tue, 22 Nov 2016 13:56:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9141B17E-BB54-47EB-B6B2-D6D2BDFA8744@sn3rd.com> References: <2C424863-2993-4E7C-9B32-F35A5404422D@cert.org> To: Chris Inacio X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-sidr-bgpsec-algs-16.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-sidr-bgpsec-algs-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 18:57:03 -0000 > On Nov 22, 2016, at 11:35, Chris Inacio wrote: >=20 > 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. >=20 > This document is: Ready with nits >=20 > NIT: Section 3.1 Public Key Format > "Section 2.1.1" links to the current document and not to RFC5480 in = the initial reference. Took me a bit to figure this out: You=E2=80=99re talking about the hmtl = version right? I haven=E2=80=99t a clue why it=E2=80=99s doing that but = I=E2=80=99ll make sure the final HTML version doesn=E2=80=99t do this = (by asking the RFC editor to make sure it doesn=E2=80=99t happen ;). spt= From nobody Tue Nov 22 12:46:43 2016 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 3EF4F129B72 for ; Tue, 22 Nov 2016 12:46:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 mMTwGsp4l7Du for ; Tue, 22 Nov 2016 12:46:40 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr [80.12.242.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CC712944B for ; Tue, 22 Nov 2016 12:46:39 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d88 with ME id B8mX1u00B17Lgi4038mX2x; Tue, 22 Nov 2016 21:46:37 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Tue, 22 Nov 2016 21:46:37 +0100 X-ME-IP: 92.170.5.52 To: Alexey Melnikov References: <20981db3190142193043f1445abadaa3@trigofacile.com> <1b5edd03-675c-01b7-6d06-c2e155987929@trigofacile.com> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: Date: Tue, 22 Nov 2016 21:46:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-murchison-nntp-compress.all@ietf.org, Barry Leiba , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 20:46:42 -0000 Hi Alexey, >> I'm currently reviewing the comments I need to take into account for >> the document. >> Do you believe I should add a note about a possible security issue as >> far as the use of DEFLATE is concerned? (see below) >> (An "out of memory" attack?) > > I think this would be a good idea. I took it into account in the -06 version. Paragraph added at the end of Section 7 (Security Considerations): Last but not least, careful consideration should be given to protections against implementation errors that introduce security risks with regards to compression algorithms. See for instance the part of Section 6 of [RFC3749] about compression algorithms that can occasionally expand, rather than compress, input data. It covers security issues related to compression. Section 6 of RFC3749 is as follows: Compression algorithms tend to be mathematically complex and prone to implementation errors. An implementation error that can produce a buffer overrun introduces a potential security risk for programming languages and operating systems that do not provide buffer overrun protections. Careful consideration should thus be given to protections against implementation errors that introduce security risks. As described in Section 2, compression algorithms can occasionally expand, rather than compress, input data. This feature introduces the ability to construct rogue data that expands to some enormous size when compressed or decompressed. RFC 2246 describes several methods to ameliorate this kind of attack. First, compression has to be lossless. Second, a limit (1,024 bytes) is placed on the amount of allowable compression content length increase. Finally, a limit (2^14 bytes) is placed on the total content length. See section 6.2.2 of RFC 2246 [2] for complete details. -- Julien ÉLIE « Ce que j'aime chez vous, c'est que vous savez jusqu'où on va trop loin. » (Cocteau) From nobody Tue Nov 22 17:58:07 2016 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 D6B5B1294C2; Tue, 22 Nov 2016 17:58:05 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 9TWkjwYOFr7L; Tue, 22 Nov 2016 17:58:04 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57454129496; Tue, 22 Nov 2016 17:58:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 35074E2040; Tue, 22 Nov 2016 20:58:03 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 10493-06; Tue, 22 Nov 2016 20:58:01 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:2001:470:e448:2:ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 54AFCE2038; Tue, 22 Nov 2016 20:58:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1479866281; bh=Lo6xyjhUvSjnKM0sOVy/sT0rh5kBzjrtxsPII7b3aNQ=; h=From:To:Cc:Subject:Date; b=hZlzv/tfRMd7IgwHLb+dyWispVUs1khbkNwoh1x9COjh8NFsG1NkP4uDubehAekix qjUj97gDNRjmpgZzLCNWq2dWW3BlXHq3Qr9gQokx9Fg1jdH/MrqiciwI/jcPslmX3T FFYvgimVmROTExZXgt9qI3p6/1XWM6YiklSZQIH8= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id uAN1w0Yi023416; Tue, 22 Nov 2016 20:58:00 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Tue, 22 Nov 2016 20:58:00 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: rmohanr@cisco.com, siprec-chairs@ietf.org, pkyzivat@alum.mit.edu, partha@parthasarathi.co.in Subject: [secdir] sec-dir review of draft-ietf-siprec-callflows-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 01:58:06 -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 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. Summary: Almost ready to publish. Are there any implementation issues that should be added to the Security Considerations? What about privacy and/or data protection (media encryption) issues/recommendations? Details: * I did not audit the SDP or XML for correctness. * There is a typo in section 3.2.2: One of the participants Bob puts Alice hold and then resumes as part of the same CS. The I believe this should be "Bob puts Alice *on* hold"? * In section 3.3, the first paragraph starts with "The section describes...", should that be "This section"? * In section 3.3.3, "Below is a snapshot sent from SRC to SRC in this case". Is this a typo? Or did you really mean to use SRC twice or should the second be SRS? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Nov 23 07:01:02 2016 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 EE9DA1296C6; Wed, 23 Nov 2016 07:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 Tf8O99npjXiy; Wed, 23 Nov 2016 07:00:56 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 84EF3129A40; Wed, 23 Nov 2016 07:00:41 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uANF0dom005631 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Nov 2016 17:00:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uANF0dSM005637; Wed, 23 Nov 2016 17:00:39 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22581.44823.269032.294446@fireball.acr.fi> Date: Wed, 23 Nov 2016 17:00:39 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sidr-origin-validation-signaling.all@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 5 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-sidr-origin-validation-signaling-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 15:00:57 -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. This is quite short draft explaining how to transmit prefix origin validation state over BGP. Its security considerations section say: This document introduces no new security concerns beyond what is described in [RFC6811]. I think this is mostly correct, but I also think that there might be also new security considerations when you are not doing prefixi origin validation yourself, but you are trusting someone else to send you that information. I.e. you need to know whether the sender should be trusted to send that information and how the BGP information is protected from tampering (on the other hand if you trust BGP information from untrusted sources, or allow attackers to modify BGP messages, you most likely have more serious issues :-) Adding that kind of text to the security considerations section would be needed. -- kivinen@iki.fi From nobody Wed Nov 23 23:20:22 2016 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 D8FF9129530; Wed, 23 Nov 2016 23:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.398 X-Spam-Level: X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 JCKi1zRE2VTi; Wed, 23 Nov 2016 23:20:10 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 F173212950B; Wed, 23 Nov 2016 23:20:09 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1c9oKE-0000Ti-V1; Thu, 24 Nov 2016 07:20:07 +0000 Date: Thu, 24 Nov 2016 02:20:06 -0500 Message-ID: From: Randy Bush To: Tero Kivinen In-Reply-To: <22581.44823.269032.294446@fireball.acr.fi> References: <22581.44823.269032.294446@fireball.acr.fi> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 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: Cc: draft-ietf-sidr-origin-validation-signaling.all@ietf.org, Pradosh Mohapatra , Keyur Patel , IESG , secdir Subject: Re: [secdir] Secdir review of draft-ietf-sidr-origin-validation-signaling-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 07:20:14 -0000 > This is quite short draft explaining how to transmit prefix origin > validation state over BGP. Its security considerations section say: > > This document introduces no new security concerns beyond what is > described in [RFC6811]. > > I think this is mostly correct, but I also think that there might be > also new security considerations when you are not doing prefixi origin > validation yourself, but you are trusting someone else to send you > that information. I.e. you need to know whether the sender should be > trusted to send that information and how the BGP information is > protected from tampering (on the other hand if you trust BGP > information from untrusted sources, or allow attackers to modify BGP > messages, you most likely have more serious issues :-) > > Adding that kind of text to the security considerations section would > be needed. well said. outsourcing security is a tenuous method and needs to be flagged. i do not hold the pen, otherwise i would fix. randy From nobody Thu Nov 24 02:09:53 2016 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 AFE321296A5 for ; Thu, 24 Nov 2016 02:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 xwdylaoHTWpx for ; Thu, 24 Nov 2016 02:09:49 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 62C2D129FBD for ; Thu, 24 Nov 2016 02:09:46 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uAOA9gcc003961 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 24 Nov 2016 12:09:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uAOA9gNA013384; Thu, 24 Nov 2016 12:09:42 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22582.48230.118391.985108@fireball.acr.fi> Date: Thu, 24 Nov 2016 12:09:42 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 2 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 10:09:52 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview David Mandelberg is next in the rotation. For telechat 2016-12-01 Reviewer LC end Draft Shaun Cooley T 2016-11-03 draft-ietf-kitten-pkinit-freshness-07 Donald Eastlake T 2016-11-03 draft-ietf-appsawg-mdn-3798bis-15 Phillip Hallam-Baker T 2016-11-23 draft-holmberg-dispatch-received-realm-10 Steve Hanna T 2016-11-10 draft-ietf-dnsop-resolver-priming-09 Leif Johansson T 2016-11-30 draft-ietf-6lo-6lobac-06 Benjamin Kaduk T 2016-11-30 draft-ietf-6lo-privacy-considerations-04 Scott Kelly T 2016-11-30 draft-ietf-savi-mix-12 Ben Laurie TR2016-10-10 draft-levine-herkula-oneclick-08 Tina TSOU T 2016-11-14 draft-ieee-urn-03 Tom Yu T 2016-11-15 draft-leiba-3967upd-downref-01 For telechat 2016-12-15 Olafur Gudmundsson T 2016-11-09 draft-ietf-justfont-toplevel-04 Dan Harkins T 2016-11-16 draft-ietf-dprive-dnsodtls-12 Christian Huitema T 2016-11-28 draft-ietf-manet-credit-window-07 Simon Josefsson T 2016-12-02 draft-ietf-6lo-dect-ule-08 Warren Kumari T 2016-12-08 draft-wilde-json-seq-suffix-00 Chris Lonvick T 2016-12-06 draft-ietf-pals-endpoint-fast-protection-04 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Stephen Kent E None draft-ietf-dnssd-pairing-00 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-11 Watson Ladd 2016-12-19 draft-adid-urn-01 Ben Laurie 2016-12-08 draft-ietf-6lo-dispatch-iana-registry-06 Barry Leiba 2016-12-06 draft-ietf-appsawg-file-scheme-13 Matt Lepinski 2016-12-14 draft-ietf-avtext-avpf-ccm-layered-03 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-15 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-07 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-10 -- kivinen@iki.fi From nobody Thu Nov 24 03:34:42 2016 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 2BCD912996B for ; Thu, 24 Nov 2016 03:34:40 -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, 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 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 8sbKhsCTZZzz for ; Thu, 24 Nov 2016 03:34:38 -0800 (PST) Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com [173.203.187.122]) (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 BA32C129958 for ; Thu, 24 Nov 2016 03:34:38 -0800 (PST) Received: from smtp24.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 60B9424F5C; Thu, 24 Nov 2016 06:34:33 -0500 (EST) X-Auth-ID: ogud@ogud.com Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 4CBB124E4E; Thu, 24 Nov 2016 06:34:33 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-71-191-33-181.washdc.fios.verizon.net [71.191.33.181]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 24 Nov 2016 06:34:33 -0500 From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_699736F2-73AD-41C3-A0FC-14C86C51283A" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: <4AF5D708-4B58-4692-ADCC-389967F9C550@ogud.com> Date: Thu, 24 Nov 2016 06:34:45 -0500 To: draft-ietf-justfont-toplevel@ietf.org, The IESG X-Mailer: Apple Mail (2.3251) Archived-At: Cc: secdir@ietf.org Subject: [secdir] Secdir review of draft-ietf-justfont-toplevel-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 11:34:40 -0000 --Apple-Mail=_699736F2-73AD-41C3-A0FC-14C86C51283A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. Summary: Ready This document is well written and clear on purpose. The security consideration section highlights well the issues with = rendering fonts based on downloaded media type. This document simply is an attempt to simplify how the font media types = are expressed, thus this document does not create any new security = issues.=20 Olafur --Apple-Mail=_699736F2-73AD-41C3-A0FC-14C86C51283A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


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.

Summary: Ready

This = document is well written and clear on purpose.
The security = consideration section highlights well the issues with rendering = fonts based on downloaded media type.
This document simply is an attempt to simplify how = the font media types are expressed, thus this document does not = create any new security issues. 

Olafur

= --Apple-Mail=_699736F2-73AD-41C3-A0FC-14C86C51283A-- From nobody Fri Nov 25 03:00:22 2016 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 3435A1296CF; Fri, 25 Nov 2016 02:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1480068376; bh=UruGPkTakDx+9FSjeYCXvcJZWwNdQmw8wvMtdaiXuac=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=ANXq7jjas/jdc5C5cN8MVYpp9wvx2iMUBwYVcy0Mt9zaU/QLdk8DimJp70l1DP7IO MI4b6aYlOtrfb6ECAC4So1Iv9Aq7z+T/mnS3tKoPNXM8vPn+IrYtINMQpMGH7HURCE QAfNsT8qEnFSmIAWCaHUXBamjrzgxm/TI5xIgqNs= 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 04C001296CF for ; Fri, 25 Nov 2016 02:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 SlXk32qErU2n for ; Fri, 25 Nov 2016 02:06:10 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793E5129629 for ; Fri, 25 Nov 2016 02:06:09 -0800 (PST) Received: from [2001:da8:203:80:4492:ff91:24b1:6752] by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1cADOR-0001MS-Ey for new-work@ietf.org; Fri, 25 Nov 2016 10:06:08 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: Date: Fri, 25 Nov 2016 18:07:11 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 25 Nov 2016 03:00:21 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Tracking Protection Working Group (until 2016-12-23) 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, 25 Nov 2016 10:06:16 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Tracking Protection Working Group: https://www.w3.org/2016/11/tracking-protection-wg.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2016-12-23 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Wendy Seltzer or Philippe Le Hegaret . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Nov 25 03:00:25 2016 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 7AB0B1296BA; Fri, 25 Nov 2016 02:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1480068465; bh=sIemQBAv3r2J/oV2XJwqt3FMJb/oV3uznruVo1Wx5TU=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=uVXnSzVeKRbZfOMgEtxdo+JwvHA7WeEiBcj93oReT0FEhV+mxO9V4ya1ik8DJY7uC t/4jxAdLqStaf8hBCdwW7+TOywDXCbfp2DylPyiGoplULqD1h0KTv6kaZsoJ53NIku u9f88UFGkseYre4oePCR7ZOjJLYitbc4Zr/VOAhk= 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 EF4301296BA for ; Fri, 25 Nov 2016 02:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 mOSxNQ6pCYGd for ; Fri, 25 Nov 2016 02:07:42 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3A0129578 for ; Fri, 25 Nov 2016 02:07:24 -0800 (PST) Received: from [2001:da8:203:80:4492:ff91:24b1:6752] by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1cADPf-00025L-4r for new-work@ietf.org; Fri, 25 Nov 2016 10:07:23 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: Date: Fri, 25 Nov 2016 18:08:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 25 Nov 2016 03:00:21 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Scalable Vector Graphics (SVG) Working Group (until 2016-12-23) 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, 25 Nov 2016 10:07:45 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Scalable Vector Graphics (SVG) Working Group: https://www.w3.org/2016/11/svg-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2016-12-23 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Philippe Le Hegaret . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Nov 25 08:37:59 2016 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 8C0CB1294E1 for ; Fri, 25 Nov 2016 08:37:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 yDx0JsvtzlH9 for ; Fri, 25 Nov 2016 08:37:56 -0800 (PST) Received: from smtp74.iad3a.emailsrvr.com (smtp74.iad3a.emailsrvr.com [173.203.187.74]) (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 425711293F9 for ; Fri, 25 Nov 2016 08:37:56 -0800 (PST) Received: from smtp10.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5B9335DB6; Fri, 25 Nov 2016 11:37:55 -0500 (EST) Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 4DA8B5DB4; Fri, 25 Nov 2016 11:37:55 -0500 (EST) X-Sender-Id: scott@hyperthought.com Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 25 Nov 2016 11:37:55 -0500 Received: from hyperthought.com (localhost [127.0.0.1]) by app15.wa-webapps.iad3a (Postfix) with ESMTP id 3ED7BE0064; Fri, 25 Nov 2016 11:37:55 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 25 Nov 2016 08:37:55 -0800 (PST) Date: Fri, 25 Nov 2016 08:37:55 -0800 (PST) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-savi-mix.all@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain X-Auth-ID: scott@hyperthought.com Message-ID: <1480091875.2556323@apps.rackspace.com> X-Mailer: webmail/12.6.2-RC1 Archived-At: Subject: [secdir] secdir review of draft-ietf-savi-mix-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 16:37:57 -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 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.=0A=0Asummary: Ready with issues=0A=0AThis docum= ent describes how multiple Source Address Validation Improvement (SAVI) met= hods can coexist in a single SAVI device and how collisions are resolved wh= en the same binding entry is discovered by two or more methods.=0A=0AThis i= s my first exposure to SAVI. In reviewing this document, I skimmed RFCs 721= 9, 7513, 6620, 7039, and 4862.=0A=0AI have a few comments on the Security C= onsiderations text. The first paragraph says, =0A=0A SAVI MIX does not el= iminate the security problems of each SAVI=0A method. Thus, the potentia= l attacks, e.g., the DoS attack against=0A the SAVI device resource, can = still happen. In deployment, the=0A security threats from each enabled S= AVI methods should be prevented=0A by the corresponding proposed solution= s in each document.=0A=0ATwo comments on this: first, not only does SAVI MI= X not improve on or reduce the security concerns for each implemented SAVI = method, but in fact, combining methods (as in SAVI MIX) may increase suscep= tibility to DoS attacks. This is hinted at in the next paragraph, but it wo= uld be better to call this out directly. For the 3rd sentence, you might tr= y, =E2=80=9CIn deployment, security considerations for each enabled SAVI me= thod should be addressed as described in the associated RFC.=E2=80=9D=0A=0A= The second paragraph says,=0A=0A SAVI MIX is only a binding setup/removal= arbitration mechanism. It=0A does not introduce additional security thr= eats if the arbitration is=0A reasonable. However, there is a slight pro= blem. SAVI MIX is more=0A tolerant about binding establishment than each= SAVI method alone. As=0A long as one of the enabled SAVI methods genera= tes a binding, the=0A binding will be applied. As a result, the allowed = number of SAVI=0A bindings or allowed SAVI binding setup rate will be the= sum of that=0A of all the enabled SAVI methods. In deployment, whether = a SAVI=0A device is capable of supporting the resulting resource requirem= ents=0A should be evaluated.=0A=0AWhat constitutes =E2=80=9Creasonable=E2= =80=9D arbitration? Shouldn=E2=80=99t this document spell that out? The doc= ument comments that SAVI is more =E2=80=9Ctolerant=E2=80=9D, but shouldn=E2= =80=99t this point out that mixing methods potentially reduces the security= level to that of the weakest supported method (because of the FCFS suggest= ion below) unless additional steps (e.g. requiring non-overlapping address = spaces for different methods) are taken?=0A=0A From nobody Fri Nov 25 23:15:43 2016 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 AF30A129453; Fri, 25 Nov 2016 23:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.265 X-Spam-Level: **** X-Spam-Status: No, score=4.265 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, FSL_HELO_BARE_IP_2=1.499, HTML_MESSAGE=0.001, RCVD_NUMERIC_HELO=1.164, SPF_FAIL=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 t5Mn6QvyfQOI; Fri, 25 Nov 2016 23:15:41 -0800 (PST) Received: from s16055305.onlinehome-server.info (s16055305.onlinehome-server.info [82.165.40.108]) (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 EB85F129492; Fri, 25 Nov 2016 23:15:40 -0800 (PST) X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from 179.191.131.42 (unknown [179.191.131.42]) by s16055305.onlinehome-server.info (Postfix) with ESMTPSA id 27EBC2AD03; Sat, 26 Nov 2016 06:32:12 +0100 (CET) From: iof-members To: "Hanna Perden" , "mclange" , "Inip-discuss" , "secdir" , "uta" Date: Sat, 26 Nov 2016 08:36:51 +0300 Message-ID: <0000c36c2f39$3a444849$65114c06$@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_011A806E.39CF2C57" Thread-Index: AdI/5Z0nzSO892SKG9UW+DeyLEYOXw== Content-Language: en-gb Archived-At: Subject: [secdir] enjoy) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 07:15:42 -0000 ------=_NextPart_000_0050_011A806E.39CF2C57 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I just wanted to show you something really beautiful, enjoy) Check it out Sent from a prehistoric stone tablet, iof-members ------=_NextPart_000_0050_011A806E.39CF2C57 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= span lang=3DEN-US>Hi,

I just wanted to show you something really beautiful, en= joy) Check it out htt= p://office.veravanich.net/e4cf/14

 

Sent from a prehistoric stone tablet, iof-m= embers

------=_NextPart_000_0050_011A806E.39CF2C57-- From nobody Sun Nov 27 11:14:20 2016 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 68925129500; Sun, 27 Nov 2016 11:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1WXekdfdBjW; Sun, 27 Nov 2016 11:14:12 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0112.outbound.protection.outlook.com [104.47.37.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3321294F3; Sun, 27 Nov 2016 11:14:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9gBbwft2iF3pwIG/4w7yKlwf32LvWdynPRU4d3+sovA=; b=XoZyhqJ8MnzFZpgEdzX6J3eFhlCkT+1zs/OeYgr/kEpH4h49hfBUqeNW5Is38b7vSItODIz69JBahMqPAtc0Z+8A1wC4UnkrVNNdYRuUBhiWNLwtmsa8nTfFosMj6RBFWwiFpOwEBYm9kdenaVnPtUlZeEUnINvvUyIIFrIlLjA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.33.83] (66.129.241.12) by CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Sun, 27 Nov 2016 19:14:10 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Sun, 27 Nov 2016 14:14:02 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <528F862E-BBA4-44C5-9454-25A2AD1E103D@juniper.net> References: <22581.44823.269032.294446@fireball.acr.fi> To: Randy Bush X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR0601CA0018.namprd06.prod.outlook.com (10.163.210.28) To CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) X-MS-Office365-Filtering-Correlation-Id: 37f845e4-3646-45e2-8ba1-08d416f991ee X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2508; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 3:zNTGaNom8v8aQmxji/kmGRyLogtiTbxVCQYS6058wul9rs+okgqISgRnHrTeL9jyioNAZ9K5RPGd4VR6VzF3BwZ1jtdZ7fDIbILfk4lAawSBu/RJXNMgUUr0TRvsMJ5gv3QOPPnXPFVx5Z548C96bEciiZWPqd/PsOJ7h7efuDgzU1LnIwcBG3LeTKPdb7a2YQGMM+PJlLnIK+WV88fuKiWfLGLvnyHTUH57mvfYutVzCeu9S8FkSM7Nb4butGbiAKrmYeKhJ8eOXEZxYzcwaw== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 25:yOsU71qKVhkmsdpTTs6t+pceYmqTo1/0CEvZxO+ksaLcWRmQ+KJETQRV7eG3Maouj9v7bQGH91Rzk4+fLNSHAXz943ZtO/BEVcwsyQya9MgTbHghdRtWZ3KSCBii+lp6xbGcQB8njfENyt8QDlMRY6yK/jhq3EMEJocQQ8ZwGmLOH3ttTt8lN77YffC6F5GEjNOPa66znAd0jQrg5O/CnfaBNR5Aohfj+WWWvL7HfdInaH8XCEzhPgpMYweZZjozHlBqhikfVe25/902ETQjmUxe2pDsYKN7nTklc7CoUEVbbYOgJY6tzaS+FaNF/Y7bSn7xU3kEJAuMgtfCZBPIaFUwBdLMIVTNeGzrVmYa7JaIpIuPsiaSUGmpeb4SKuTzDBxuxrPOPY4jKCCHVJS1qz92XoPM/wcKHBOjfrOioKQLRqh3QaKPIZ84koBo4hahP0txZEanip3CKPKmZQzPoOkwgLc22w3xZs4Cmuj+pN+EAgpHx1ojk8WiEiDZHXszJ/98vVkGdwPrIUYtdKbV3Qr6Cg6wAe/BM0/O7mb+Zdb74CqKvH81DE8xpIJgqEoTvBpl142FjMo2ThWhFeh9PdvZWL1V9JB9+3m6iLfWt2NcjqU6QuDlvc/bHSQTnYA6Jzc3uDfnbotxaWvX1oUytDmCF2nhaGgjKXBtxmWkdwfkuBVCfGWzm+tlQxpU1uQ0JP5pzGvCx+zcKsj3x6a0ITIe/rfuWwXlxXlXtEzbA+bXJHNHgr+VxX35IFcWvu+2SwG3DxwTydvWoUYWUTffeA== X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 31:VyL6IcdCbsfC14HmKj8GONDTUG1N5s1utq6Sf5neCZAXvAdWsNHUI0LEHA/OQcruNat48RZDfEZ2CRa/MY+UlBlS6lCA6uLcyCKhCctBmfnIsxaPOePbhK/Tl0G48Tl9T9VjbOwOXvirg14KgLLrZjoB0f3aqcJXHrX2Q+S7Ny6dMd/Uyv17CcCHHiG6yb74TnwRnzWOe847iXQErGOjCRly8WVwxLcemoD0/XXsbgH7Fw5UV8JTK0TL09uHXpDLc+vD+eyb0CeF/lb77O6INQ==; 20:AI1OMxxW07H0QDd0M4AuLtBc3e5weuYpjUm6SsuQ+lYAhTgUGMxoctzaLndnsQ6IueG/CdCnWdJ7FddzmOuTdYxrT7KDcj8KJmjwZCkgl4anQSXo8KSlZcBs9hgn5dZBlS0z2V03AzaDotg18vE4eC11FKrfpr3is+BCfiGuXaSfE7qt3HhY/+OCjNd/5XzboOklFb2GcAbNNjkvlXGGXUvD8SHIBztET2F0XFiyKPQnl3tmNWyzER2tAyJTB0CmOL9CA7shYy1h+yoTHvWUo3bXxfJsmq9X3KoPSprKRWt+qgoVRcxzkEssZQTqyHFiiuZowCBLamw2HG1mpEAu3P5Ul3DIoeKe2V3sTOxn4Z8FUTLGHFoCrN4uYZ1jcdi0j4wC8MiNjTcubtGAJh9LfVpLSTNFvicdWx//vm0gQpXGndPX6Os6M6WfFM6euQ3Abhcimjn38OVWbj6yqTE94tVeQWFAXpSJPwe2XgPH+q17NvoX4vANKZmRgwVlYddtza2TDI35ERN9+8nYwnFU6uAtilucBLPGFaSNLImigUSbXw8Jkk9f8+4cAuqJ7fi1AUglrqb8AdI2CyKW9ZymZ/Y8m/Co6HRoP1raaKXT23E= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(6045199)(6040361)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6061324)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY1PR05MB2508; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2508; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 4:DEpmLvrAIHqpDSQrohGK5tM/ZjahGqWSJZLavjymKaTsIvymxT0T8KWqy9AvV7l+E6JJvI4dHj8FvZlpHswSBQ1+bCJx5me90UHod1V6INa9sqOmC8dUZtQMCvTAW51eg6Nq2V+qd4HYR98yjT1JaYo4vx7JQfdq45Q7NZG+QpvwikRaYuyLXf+gD7I5I2K8No/vPHQxogwldfkg2fnp73gS9a11Kq3/X53LZGCyYYgH3bbWS/bSLPPziLtuJsfmlwF+JT0+ioe0YWhE8VOYdfH9PgO1VGTj3C1vRLwtutwtJvXhiGHLbcZpqiUhN6c7hYkYv5ZkOCP/L/oMuX5IItE1vZefTPYLkjXsP0lGQhxkd1dm+eP7GKzMIlf2PREZwHW9E+/odAF7LanY5Jeu2kOyFZkmlpireiSXZDHuBbJh0Qlsd6UGNOUDiNLdmz//SfW9UlBVvATZexw+1BDsI4rhlMEstTU0L+h58UlZTiUA2hbx9zOXFqFttQUuxNYpo/X6TLbY7dlO6Huaa/JtVZkoOuMcz3DzPcrNgnhBkGOSRQikGmfxm3FaAn0IQ1ut1QbaCTHLncJYXZlyFB97UwMWaDggJ5eIhHmWjeS+OXARdkgqMmBlh05F4UWuDFXqWcYcEuoW4q0EfKrKYHxZEA== X-Forefront-PRVS: 0139052FDB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(24454002)(199003)(377454003)(97756001)(42186005)(46406003)(105586002)(2906002)(106356001)(5660300001)(4326007)(101416001)(66066001)(83716003)(189998001)(47776003)(6116002)(86362001)(82746002)(50986999)(76176999)(230783001)(57306001)(33656002)(229853002)(92566002)(38730400001)(50466002)(39410400001)(81166006)(81156014)(97736004)(39380400001)(8746002)(39400400001)(39060400001)(6666003)(7736002)(6916009)(8676002)(7846002)(2950100002)(68736007)(36756003)(50226002)(733004)(110136003)(77096006)(23726003)(39450400002)(3846002)(305945005)(6486002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2508; H:[172.29.33.83]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2508; 23:OoWNRwugStsr+fXsxQbfXUFyOUwkJc1xujAR5SQDv?= =?us-ascii?Q?dqsPLYDaPtGIAXlJzQIk/+hLuuj7TzrlZkfvlM9QdsHAgnZFYCeY15pOrmKB?= =?us-ascii?Q?Q9mzSsa6DT45bNChqIbMRuvditWvn0niFL7V+DZij5tDDpUCUElp+sZWW5Wu?= =?us-ascii?Q?haRz2QnFFqRlWrF8s8drP8IlmzdLDKG2dxMlV9GSg5ReennsoEPhJWNCr/MO?= =?us-ascii?Q?m8g3r2fdf5Zq3WGkI8J9UB/RnKkB821xPKsYAJOx6rjYMfwJVUDeTsXskrtj?= =?us-ascii?Q?DmQdKZV4SOsb7nWjD9OJ5SQ8F8hU71e/sKi/xE2NALcGfp7rl6j4INN4yBaB?= =?us-ascii?Q?YPhgTTicvxQzeVQpf/NOKdY7WZ3uGNcjQkmPrD0Zph7tSzR0nsAuaG8M9Ybe?= =?us-ascii?Q?xfzgYGXBDWKy5VHDzzTgdfSMO6nidBVvVqVvMS8WSkGSNNutj1GnUjUH0Lzo?= =?us-ascii?Q?nML9hBi/SpR8FEgaH0ra+PZp1d8BZk7mWeOf8ZU0vKb5RPxsBfHXOUtuAdcq?= =?us-ascii?Q?1zo5DBfU+HixqZWpyg5Xfei8aJqjHexFm+dimu9oXzArpKvBjVeqzk8eP9Jv?= =?us-ascii?Q?YvxO7wOzDMSKxWI1UUd4EDSG2wkgUnL8wI8fRJCeNfNe6ZbsjGv8SLLEy8Ff?= =?us-ascii?Q?s7FTQJG6bqftQ+Huo5RDqnuZkw3qZ4x0f/vRphVMlaB9rA/n12ALPzPVWT6q?= =?us-ascii?Q?cxtiiha00oOY72U/6K2lWwaronA2cfgupI+Js3iT7C3Jsy7mWAOB2JAxmr0V?= =?us-ascii?Q?fBcDBYEBxm50Vq1aJ1SpOyEVNTPDxmFMziKLnGnc9wUIO4o2DNpJpA8+Y3gH?= =?us-ascii?Q?BP0x+PPPnq08QvSUK97WQV3Y+JeJbvE8Y2n6+ol6eyLAE3BZZsDZ5PpPsJTe?= =?us-ascii?Q?8/THEZn949FuqKvQuFn9TL05BzC4Jp3KUhFWBxTf98oJzcnAADy1B0zG+lsf?= =?us-ascii?Q?eo067jQWcSuh2/UPiGj30fx5Yn2uJ1SFUhFaiuf+tmopGOkCRoI75O9FZdn1?= =?us-ascii?Q?O4guTzW1jRACWifvss0IEL+qK7yjyIzyu4ZIqQXZVmtKvcTa03jwdcq6thGK?= =?us-ascii?Q?1o9wsQnef3AZSSWtqNKTA0mWR5350IHTbF23KWf63CZHqFH8Al6n8zHZlpYq?= =?us-ascii?Q?kwVY2zUjbjR9p1q13aW5Sgp/tcmkUa8zx8ffpPQINRGUjVoFrDQ/QEaB7UBR?= =?us-ascii?Q?7HMUAgC1h9I39VfcvOoW16QNYsxyBEM+v6psCTl7bIXp3X9j6+xKE/N8PPXg?= =?us-ascii?Q?esyJFgFg6DMUCSyN0mvau5fLBZbGXDmRQhcANAXhJ+GOXuOot/dSAPUzw+E4?= =?us-ascii?Q?4EUM9t+7WKCUE5o69iMdTOTUSZ+JVeC0DqnWPwVQH9FJ/2S4yeFWeoR+3Ygt?= =?us-ascii?Q?7kcluy7cmp5jv4EFNtRhotqvqVVMXUx5XT1UgtOsKCWf8S6kUbRaDc6nBhfe?= =?us-ascii?Q?L56/ziBjA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 6:16dq+y55nYyghLAunCiAUJ/R+kXXwp1CnWEoEnhBZvXWgGAn52wgR65RTd9wZknWKEBwd+mWz1vb9lXJ/qvmtGvcTE/B/IFJq2lNQ4JyngB+5uuZphS4BlXqKy5o+ZE4AVXEgmYNZ7Yx08rLrnBRxr9rBYHbUPqtqg56a7O8VV7pmalBVdn0BCyBx2cmSaBqmYrNaNr9buDqEuPalv+q3Nu8kDouqs39swDd64nEgsD+4/wj0KAIG4lKwgYPF8I8jqeDv7nQDLWUYcaCK1EGaMwEvkT6nBZKydKj1H/IWV5320dCqnT2TGDHnwdAwFd+oxqe+Wj1Pn9GlYpvcy6EOa/Gr8LZJ0jEn/SIOmWzJPMVhNsqm11E9QHWx6NA5SigiFdZg6UaagAMfAURKHwRQWyvgKWgsdVm2lbEq7P/AL7O1zTT3g6e+tLzIYW3KtPoIIWmZCazHUBm96+PgutfHYyjghr25ZQ/8a5clKuU4OPh2oW0aw3/1/Lj+leRxUq6; 5:lK2G/m8n+IzEy7kP4VT3OLbWa2OZiSN4p1X+iecK/Wt9NG5Rps1ieMa6tG+Rubmpm1yQ6wf4W2Y/faUpEvb+24QM0C9uqVpDnjIkjAHovWBxiSCFlTfAiO+cdyR6OuqRq3uOs+R4Mp7RDt8vMcw8wHSJgK8l6SSIAwnBv0OOXC8=; 24:pwHRDf1jRIp2CB1rbLd8ocKULOc+FTPqDEbtZVD5cYbIX6mvKpdVkuyUD6WJ+PGlG9a+A9xeNQsCsrMXsP87uoHQijKWxruZsLJJK+/PGYM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 7:cXI1ezFVOAMTTfqBSmwbVzhiNWrj+Hcp9psK2fpsnvyyOKwxeWnoelp//bgnDQcXUg0EAP9OfNgXL16Azi49XTYcRecj6p1/Ql644Scev32IaKNqAPSn09Na/ftdfNIsvg/z9Akg9912BxSYY6CDr5durKe7Rgir5psM+FNTKXYU/IKLFuksn/d/0EgdxoJ9gG5eN4R7fE+V62uwZGH2To5vl80Mchl1hgCJqdYaT7Dyb0J7Negkih2lg0BsT9TByqolLGjciIeswdnSbqVOxrAKw2bvHnc5EmgoykeuxDGjzlTII4I7UcRTghuyeih6jElvMc1DGEeGbrVkkKMi9hFN7mww4GpYgc9ODsAynD5KYJrd6rfN4vFIM25wQU2XBv7CvmxLf4SLEP/uiGo5Bo+QkxPfktDR1goQRdOhs1p6flqiWXE7/AdKshB81wFrv2FoLDquhdfWgn/sFoQWXg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Nov 2016 19:14:10.7551 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2508 Archived-At: Cc: secdir , Pradosh Mohapatra , Keyur Patel , IESG , draft-ietf-sidr-origin-validation-signaling.all@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-origin-validation-signaling-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 19:14:14 -0000 On Nov 24, 2016, at 2:20 AM, Randy Bush wrote: > i do not hold the pen, otherwise i would fix. I believe I have the current source. If someone sends me text, I'll = paste it, or otherwise I'll send out the XML when I get a chance on = Monday. If we have to wait for me to write the proposed text, it will = not be very soon. --John= From nobody Mon Nov 28 05:17:10 2016 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 595631295BD for ; Mon, 28 Nov 2016 05:17:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rc9rd0wgKHRP for ; Mon, 28 Nov 2016 05:17:04 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 8930312943A for ; Mon, 28 Nov 2016 05:17:04 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id n204so138872201qke.2 for ; Mon, 28 Nov 2016 05:17:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=vVZwygOkWvLCAGoJbYm/hu4i1hs7gNykpJdWyvoKoHQ=; b=C3/teyMNXG/tCTvTZVFfJ18bFEzqwppSPvhleVRlcP997efdwRsVmSa0CJIheOBKf2 a0ZqTHhgK/h39dXUWi9ZS6fIc2Kly+oOLNrq908ofoYoX99POrH7NXOd+JuVbs2O75OU /9WaPZOyT+lIOShvvWi717Cb+eR0bXFay6DcYA8r1ZW3ygNDjI1a6mKVpEK3BOjfCArs m3/ya8Wyyp6Vxe8QaUlSEbstXTTeZuBT3E1PfpPlukmURzgmT5Hvf9paqFXqFB8HRuR+ 0LLeHSrQhv9bgs0BRp04RcCMsRf+ChQ99ayZ2T6nIVeaCzH8RZ/TVLoVdtOnDJp7O5hA 6EJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vVZwygOkWvLCAGoJbYm/hu4i1hs7gNykpJdWyvoKoHQ=; b=QKjxFM5qqdyWHbx9AlrSC9UBiYlp2QHX1RS3g3MVy340WFJClkGkK8P9g8W164o8/2 /bfcTJk8YBXEQxUvXNf/qwiT+4DO5PRzFN37XBMd/9uhPtSKY630s8SeUbOcKOVDImVV T7g/4ipgtRokvaahd7L8tRkdvMlaRW16+0d1B/UiFjtUEMaoZlv8pudRxDHszrovkOWg yjWdTeAAZFoMcKHVnaGhsjwH91K2CICeyVLtaxLkFKq3b5uJIIy8yOY3qZblye/W1NRK R1ryCDNaNvtG/HJMpbj2zn9A0kNt0HR5GuCAfMgk5q94ck2fP33NgcJ4/VXIM/C7VYIr X1Ig== X-Gm-Message-State: AKaTC0159lK7zSJyx5yv+DJP5OSMY3GT7Pa3qF3IYYzXKQgHuGGm0dxWhW7P7F42kiM1LeKKK5K9UzA0+hBUPz6I X-Received: by 10.55.118.65 with SMTP id r62mr20492275qkc.21.1480339023353; Mon, 28 Nov 2016 05:17:03 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Mon, 28 Nov 2016 13:16:52 +0000 Message-ID: To: The IESG , IETF Security Directorate , draft-wilde-json-seq-suffix.all@ietf.org Content-Type: multipart/alternative; boundary=94eb2c062206a2857e05425c499d Archived-At: Subject: [secdir] Secdir review of: draft-wilde-json-seq-suffix X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 13:17:07 -0000 --94eb2c062206a2857e05425c499d 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. 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. Summary: I do not think that it is ready (see below), but presumably there is some backstory that I'm not aware of, or it wouldn't be here. I don't see any *security* issues, but the document is very unclear. It *looks* like it just tries to add "+json-seq" to the IANA Structured Syntax Suffix Registry, but I don't see why it is Standards Track, or why it need to be an RFC at all; the registry is Expert Review, and RFC 6838 Section 6 seems clear. Other issues: It does not contain a Security Considerations section, and there are a number of broken references (e.g: it says: "Online access to all versions and files is available on github [2]." - but [2] is a link to: http://www.rfc-editor.org/info/rfc6838) It is a -00, submitted Sept 23rd 2016, and the document on which it was based (draft-json-seq-suffix-00) was also a -00, submitted Sept 19th 2016. The only changes between the 2 are the metadata (name, date). There has been basically no discussion (at least, that I can find), closest is: https://mailarchive.ietf.org/arch/search/?email_list=art&index=AxC0J7zxKU_wH1jOrkZ0ZZUUcs4 ? I *think* that it is simply trying to add "+json-seq" to the IANA Structured Syntax Suffix Registry ( http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml) -- unfortunately it does this very poorly. It starts off by saying (note tense): "IANA has added the following "+json-seq" structured syntax suffix to its registry of structured syntax suffixes established by [2]". [2] references to RFC 6838 - "Media Type Registration", which creates a number of registries - while looking I found " http://www.iana.org/assignments/media-types/media-types.xhtml", which does indeed have "json-seq". Because of the "IANA has added" I assumed that this was what was being referenced. The IANA considerations section needs work... Nits: Section 1: how a media type can signal that it is based on another media type as [O] way of how a media type can signal [P] way for a media type to signal [R] readability; original was a bit awkward Section 3: Applications encountering such a media type then can either simply [O] then can either [P] can then either [R] readability W --94eb2c062206a2857e05425c499d Content-Type: text/html; charset=UTF-8 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.=C2=A0 These comments were written primarily for the benefit = of the
security area dir= ectors.=C2=A0 Document editors and WG chairs should treat
these comments just like any other last= call comments.
Summa= ry: I do not think that it is ready (see below), but presumably there is so= me backstory that I'm not aware of, or it wouldn't be here.<= /div>

I don't see = any *security* issues, but the document is very unclear.
<= span style=3D"font-size:13px;color:rgb(33,33,33)">It *looks* like it just t= ries to add "+json-seq" to the=C2=A0IANA Structured Syntax Suffix Registry, = but I don't see why it is Standards Track, or why it need to be an RFC = at all; =C2=A0the registry is Expert Review, and RFC 6838 Section 6 seems c= lear.

Other issues:=C2=A0
It does not contain a Security Considerations section= , and there are a number of broken references (e.g: it says: "Online a= ccess to all versions and files is available on github [2]." - but [2]= is a link to:=C2=A0http= ://www.rfc-editor.org/info/rfc6838)

It is a -00, submitted Sept 23rd 2016,= and the document on which it was based (dra= ft-json-seq-suffix-00) was also a -00, submitted Sept 19th 2016. The only c= hanges between the 2 are the metadata (name, date).=C2=A0There has been basically no discuss= ion (at least, that I can find), closest is:=C2=A0https://mailarchive.ietf.org/arch= /search/?email_list=3Dart&index=3DAxC0J7zxKU_wH1jOrkZ0ZZUUcs4=C2=A0= ?

I *thi= nk* that it is simply trying to add "+json-seq" to the IANA Struc= tured Syntax Suffix Registry (http://www.i= ana.org/assignments/media-type-structured-suffix/media-type-structured-suff= ix.xhtml) -- unfortunately it does this very poorly.=C2=A0
It starts off by saying (note tense): "IANA has added the= following "+json-seq" structured syntax suffix to its registry o= f structured syntax suffixes established by [2]".=C2=A0
[2] = references to=C2=A0RFC 6838 - "Me= dia Type Registration", which creates a number of registries - while l= ooking I found "http://www.iana.o= rg/assignments/media-types/media-types.xhtml", which does indeed have "json-seq". Because of t= he "IANA has added" I assumed that this was what was being refere= nced.
The IANA consi= derations section needs work...

Nits:
Section 1:
how a media type can signal that it is based on another media type as [O] way of how a media type can signal [P] way for a media type to signal [R] readability; original was a bit awkward

Section 3:
Applications encountering such a media type the= n can either simply
[O] then can either
[P] can then ei= ther
[R] readability

W
<= br>


=

--94eb2c062206a2857e05425c499d-- From nobody Mon Nov 28 05:35:01 2016 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 C4B0912943A; Mon, 28 Nov 2016 05:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 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, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 ruCpDQe1t7zy; Mon, 28 Nov 2016 05:34:58 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A3DAD12988C; Mon, 28 Nov 2016 05:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1480340097; d=isode.com; s=june2016; i=@isode.com; bh=Ge/YVrmDI/FVRm7sLLK7vIf7atmZKtVsJdb2XDZumQs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=aqpdzEeRuc3rKHuEvMiJZEkE3PKiRrQenx4KB2Sqcn5ooZ2L9XJHLgdztTgJugFaRziKu0 mjl38xTpjlhgGrIOsCzg6M87mdIUhsmRkK6Aqf01qGh4BDrgjwEo40s00S5xKkEsqNr8Vt RiqP4uLyy10Y5hQS4VE4cp3EtUJHcFU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 28 Nov 2016 13:34:57 +0000 To: Warren Kumari , The IESG , IETF Security Directorate , draft-wilde-json-seq-suffix.all@ietf.org References: From: Alexey Melnikov Message-ID: Date: Mon, 28 Nov 2016 13:34:56 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------AD19928D260EC5B11B6AB9A4" Archived-At: Subject: Re: [secdir] Secdir review of: draft-wilde-json-seq-suffix X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 13:35:00 -0000 --------------AD19928D260EC5B11B6AB9A4 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Warren, Thank you for your review. On 28/11/2016 13:16, Warren Kumari 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. > > Summary: I do not think that it is ready (see below), but presumably > there is some backstory that I'm not aware of, or it wouldn't be here. > > I don't see any *security* issues, but the document is very unclear. > It *looks* like it just tries to add "+json-seq" to theIANA Structured > Syntax Suffix Registry, but I don't see why it is Standards Track, or > why it need to be an RFC at all; the registry is Expert Review, and > RFC 6838 Section 6 seems clear. While this indeed can be just sent in an email, IMHO, it is better to register Media Type suffixes in RFCs. All existing Media Type suffixes were registered in RFCs. It probably doesn't need to be Standards Track. I would be happy to follow IESG's advice on how to handle this document. This suffix was incorrectly being used in a media type registration, so this document is now trying to register the suffix to fix the brokenness. > Other issues: > It does not contain a Security Considerations section, and there are a > number of broken references (e.g: it says: "Online access to all > versions and files is available on github [2]." - but [2] is a link > to: http://www.rfc-editor.org/info/rfc6838) Yes, this needs to be fixed. > It is a -00, submitted Sept 23rd 2016, and the document on which it > was based (draft-json-seq-suffix-00) was also a -00, submitted Sept > 19th 2016. The only changes between the 2 are the metadata (name, > date). There has been basically no discussion (at least, that I can > find), closest is: > https://mailarchive.ietf.org/arch/search/?email_list=art&index=AxC0J7zxKU_wH1jOrkZ0ZZUUcs4 ? The document is rather trivial (and yes, it does contain annoying omissions). Chairs of GeoJSON WG reached out to me for AD sponsoring of this document, because one of their documents used the prefix incorrectly. > I *think* that it is simply trying to add "+json-seq" to the IANA > Structured Syntax Suffix Registry > (http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml) > Yes. > -- unfortunately it does this very poorly. > > It starts off by saying (note tense): "IANA has added the following > "+json-seq" structured syntax suffix to its registry of structured > syntax suffixes established by [2]". > [2] references to RFC 6838 - "Media Type Registration", which creates > a number of registries - while looking I found > "http://www.iana.org/assignments/media-types/media-types.xhtml", which > does indeed have "json-seq". Because of the "IANA has added" I assumed > that this was what was being referenced. > The IANA considerations section needs work... > > Nits: > Section 1: > how a media type can signal that it is based on another media type as > [O] way of how a media type can signal [P] way for a media type to > signal [R] readability; original was a bit awkward > Section 3: > Applications encountering such a media type then can either simply > [O] then can either > [P] can then either > [R] readability > > W --------------AD19928D260EC5B11B6AB9A4 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

Hi Warren,

Thank you for your review.

On 28/11/2016 13:16, Warren Kumari 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.=A0 These comments were written primarily for the benefit of the
security area directors.=A0 Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: I do not think that it is ready (see below), but presumably there is some backstory that I'm not aware of, or it wouldn't be here.

I don't see any *security* issues, but the document is very unclear.
It *looks* like it just tries to add "+json-seq" to the=A0IANA Structured Syntax Suffix Registry, but I don't see why it is Standards Track, or why it need to be an RFC at all; =A0the registry is Expert Review, and RFC 6838 Section 6 seems clear.
While this indeed can be just sent in an email, IMHO, it is better to register Media Type suffixes in RFCs. All existing Media Type suffixes were registered in RFCs.
It probably doesn't need to be Standards Track.

I would be happy to follow IESG's advice on how to handle this document.

This suffix was incorrectly being used in a media type registration, so this document is now trying to register the suffix to fix the brokenness.
Other issues:=A0
It does not contain a Security Considerations section, and there are a number of broken references (e.g: it says: "Online access to all versions and files is available on github [2]." - but [2] is a link to:=A0http://www.rfc= -editor.org/info/rfc6838)
Yes, this needs to be fixed.

It is a -00, submitted Sept 23rd 2016, and the document on which it was based (<= font color=3D"#212121">draft-json-seq-suffix-00) was also a -00, submitted Sept 19th 2016. The only changes between the 2 are the metadata (name, date).=A0There has been basically no discussion (at least, that I can find), closest is:=A0https://mailarchive.ietf.org/arch/search/?em= ail_list=3Dart&index=3DAxC0J7zxKU_wH1jOrkZ0ZZUUcs4=A0?

The document is rather trivial (and yes, it does contain annoying omissions). Chairs of GeoJSON WG reached out to me for AD sponsoring of this document, because one of their documents used the prefix incorrectly.

I *think* that it is simply trying to add "+json-seq" to the IANA Structured Syntax Suffix Registry (http://www.iana.org/assignments/media-type-stru= ctured-suffix/media-type-structured-suffix.xhtml)
Yes.

-- unfortunately it does this very poorly.=A0

It starts off by saying (note tense): "IANA has added the following "+json-seq" structured syntax suffix to its registry of structured syntax suffixes established by [2]".=A0
[2] references to=A0RFC 6838 - "Media Type Registration", which creates a number of registries - while= looking I found "http://www.iana.org/assignments/media-types/media-types.xhtml", which does indeed have "json-seq". Because o= f the "IANA has added" I assumed that this was what was being referenced.
The IANA considerations se= ction needs work...

Nits:
Section 1:
how a media type can signa= l that it is based on another media type as [O] way of how a media type can signal [P] way for a media type to signal [R] readability; original was a bit awkward
Section 3:
Applications encountering such a media type then can either simply
[O] then can either
[P] can then either
[R] readability

W

--------------AD19928D260EC5B11B6AB9A4-- From nobody Mon Nov 28 09:47:59 2016 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 F26DA1294A1; Mon, 28 Nov 2016 09:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.398 X-Spam-Level: X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 Z6qrRt-OJQXY; Mon, 28 Nov 2016 09:47:50 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 99A9E129F75; Mon, 28 Nov 2016 09:47:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cBQ1p-0000qr-1t; Mon, 28 Nov 2016 17:47:45 +0000 Date: Mon, 28 Nov 2016 09:47:43 -0800 Message-ID: From: Randy Bush To: "John G. Scudder" In-Reply-To: <528F862E-BBA4-44C5-9454-25A2AD1E103D@juniper.net> References: <22581.44823.269032.294446@fireball.acr.fi> <528F862E-BBA4-44C5-9454-25A2AD1E103D@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 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: Cc: Pradosh Mohapatra , Keyur Patel , IESG , secdir Subject: Re: [secdir] Secdir review of draft-ietf-sidr-origin-validation-signaling-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 17:47:52 -0000 This document describes a scheme where router A out-sources validation to some router B. Out-sourcing security is generally dangerous. It is strongly recommend that, if this scheme is to be used, that the participating routers be under the same administrative control; i.e. router B has truest in router A, and that there be some assurance of the propagation path (TCP/MD5 authentication etc.). randy From nobody Mon Nov 28 10:00:36 2016 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 64616129445; Mon, 28 Nov 2016 10:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.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 k-gXGELpVF6B; Mon, 28 Nov 2016 10:00:34 -0800 (PST) Received: from postoffice.gristmillmedia.com (postoffice.gristmillmedia.com [96.30.18.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 E7B13129F83; Mon, 28 Nov 2016 10:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:Cc:From:References:To:Subject:Sender:Reply-To: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=ESthidEo0ysnv5jpugyOxfs3zYBnVvmwuQN7RUcOQ/4=; b=A/QBjXGlVKlznkZNrasCb7QEiw FuEvw5AsU+6kgrp35zHsrvUPzThWs10X93RFZplU7GwmLx4Sp9fgBMUKok2hZKqAvJT8mWJFz9WJQ sZd4b9j66kko1Wdmlj3FJeX6pJ27Ji5xRLkP8TrYhzPAhk3GNMKADHeIv7TCm3NPvOdBCy4kVnu/R jZ/kpvkrI3z5ABfUxLXgLgFNTz4hwZQaOnXqURn1d9hhVdQ2c2BRDwzKXHu5sn69ry4VJCf8O5M6L i6PG7YDbfc4RvYXifyxlaCvN4PLDIGQI5B5F7gjsUg90Ez7J0ZHIhgGY307K4fJoOkcIqPwGxUWJg qYteKvEQ==; Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:62701 helo=[192.168.1.67]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cBQEC-0000uN-3b; Mon, 28 Nov 2016 13:00:32 -0500 To: Alexey Melnikov , Warren Kumari , The IESG , IETF Security Directorate , draft-wilde-json-seq-suffix.all@ietf.org References: From: Erik Wilde Message-ID: <91f59711-84e0-853c-8dd0-8157c7807a93@dret.net> Date: Mon, 28 Nov 2016 10:00:26 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: Martin Thomson , Sean Gillies Subject: Re: [secdir] Secdir review of: draft-wilde-json-seq-suffix X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 18:00:35 -0000 hello. thanks a lot for the review! On 2016-11-28 05:34, Alexey Melnikov wrote: > On 28/11/2016 13:16, Warren Kumari wrote: >> I don't see any *security* issues, but the document is very unclear. >> It *looks* like it just tries to add "+json-seq" to the IANA >> Structured Syntax Suffix Registry, but I don't see why it is Standards >> Track, or why it need to be an RFC at all; the registry is Expert >> Review, and RFC 6838 Section 6 seems clear. > While this indeed can be just sent in an email, IMHO, it is better to > register Media Type suffixes in RFCs. All existing Media Type suffixes > were registered in RFCs. > It probably doesn't need to be Standards Track. > I would be happy to follow IESG's advice on how to handle this document. https://github.com/dret/I-D/commit/8694a1efce71dcb96410be3bd6be8d0373383703 switches the draft to experimental. to be honest, i do get conflicting info on this, and depending on the people dealing with a draft, some seem to prefer one status over the other. i have no strong opinion about this and thus i am happy to switch to the status people think is most appropriate. > This suffix was incorrectly being used in a media type registration, so > this document is now trying to register the suffix to fix the brokenness. that is the only reason this draft exists: register the suffix in a way that it is properly defined and registered and that the registration can be referenced. so yes, this is a simple draft, and intentionally so. >> Other issues: >> It does not contain a Security Considerations section, and there are a >> number of broken references (e.g: it says: "Online access to all >> versions and files is available on github [2]." - but [2] is a link >> to: http://www.rfc-editor.org/info/rfc6838) > Yes, this needs to be fixed. that's the good old xml2rfc bug that still is around. sorry for this, https://github.com/dret/I-D/commit/ee5838e5ddf53cf7084022abb7a275ac4a30a028 is the best workaround there is for this bug, afaict. https://github.com/dret/I-D/commit/1efd188ff60f2dbe7f414082d730091e803faa77 fixes another broken reference. >> It is a -00, submitted Sept 23rd 2016, and the document on which it >> was based (draft-json-seq-suffix-00) was also a -00, submitted Sept >> 19th 2016. The only changes between the 2 are the metadata (name, >> date). There has been basically no discussion (at least, that I can >> find), closest >> is: https://mailarchive.ietf.org/arch/search/?email_list=art&index=AxC0J7zxKU_wH1jOrkZ0ZZUUcs4 ? > The document is rather trivial (and yes, it does contain annoying > omissions). Chairs of GeoJSON WG reached out to me for AD sponsoring of > this document, because one of their documents used the prefix incorrectly. all correct, and apologies for missing these things so far. - the two versions exist because i accidentally named the initial submission incorrectly. the current version simply was a re-submission with the fixed submission name. - i will submit a -01 version with the changes discussed in this message today. - apart from the missing security considerations section (added via https://github.com/dret/I-D/commit/f57746b52ffc9d9b89b3af392be41c80ba530743), is there anything else that seems to be missing? >> I *think* that it is simply trying to add "+json-seq" to the IANA >> Structured Syntax Suffix Registry >> (http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml) > Yes. >> -- unfortunately it does this very poorly. that indeed is the only intent of this document. >> It starts off by saying (note tense): "IANA has added the following >> "+json-seq" structured syntax suffix to its registry of structured >> syntax suffixes established by [2]". that's how it's supposed to read once approved (at which point the addition will have been done), and that's how i have written this in previous documents. >> [2] references to RFC 6838 - "Media Type Registration", which creates >> a number of registries - while looking I found >> "http://www.iana.org/assignments/media-types/media-types.xhtml", which >> does indeed have "json-seq". Because of the "IANA has added" I assumed >> that this was what was being referenced. RFC 6838 established more than one registry. one is that of media types. another one is that of structured syntax suffixes. it is that latter one that is targeted by this document: http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml#structured-syntax-suffix this one does not have the "+json-seq" structured syntax suffix in there and the goal of the document is to add it. this registry is specifically called out in the IANA considerations section. >> The IANA considerations section needs work... in which particular way? the section says that it updates the structured syntax suffixes registry and contains all the necessary fields to do that. what are you missing? >> Nits: >> Section 1: >> how a media type can signal that it is based on another media type as >> [O] way of how a media type can signal [P] way for a media type to >> signal [R] readability; original was a bit awkward thanks! https://github.com/dret/I-D/commit/672780ac2aafd2732e696ae85dec72e9c315ddc7 >> Section 3: >> Applications encountering such a media type then can either simply >> [O] then can either >> [P] can then either >> [R] readability thanks! https://github.com/dret/I-D/commit/f4d915490f1b05551b9b424f3b9e69b617de3645 https://tools.ietf.org/html/draft-wilde-json-seq-suffix-01 is the updated version of the draft. once again, thanks a lot for the review and feedback, this is greatly appreciated! cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Mon Nov 28 13:50:08 2016 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 52587129FC5; Mon, 28 Nov 2016 13:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mF7aOeK7gt0L; Mon, 28 Nov 2016 13:50:01 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0115.outbound.protection.outlook.com [104.47.41.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36EC512943D; Mon, 28 Nov 2016 13:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QTxWyKFRBYxPFpP+6+g7b38rSqDekvrNvYriry3oC+E=; b=VFUInfYNlIi8NXDn8mMAEw7TRFDGcO+zAq8v2N24DqpyZTxaaDDFtbIO9LZakNjFrUyCUBe/tMzcMmYtDCOPXrunVhraloQjGF391FOGYGe+nij6u2fQ6jisEufMV9e/4fAHjK0xhPOA3n6R/uuSx+SfKpbI3fLbZZ0LgJgUsj8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.33.83] (66.129.241.12) by SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.5; Mon, 28 Nov 2016 21:49:58 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Mon, 28 Nov 2016 16:49:53 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <55828489-887F-4488-BF39-941D9ACD677F@juniper.net> References: <22581.44823.269032.294446@fireball.acr.fi> <528F862E-BBA4-44C5-9454-25A2AD1E103D@juniper.net> To: Randy Bush X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN1PR08CA0028.namprd08.prod.outlook.com (10.242.217.156) To SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) X-MS-Office365-Filtering-Correlation-Id: ef83831c-8f83-4c83-7b8e-08d417d88010 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 3:FGPsj14KvYTnTp8yZGlyxxv9h5aJ9RARTyChxF/+1kP9Jn87CQ96l3xMdXVBIY4zh1b4TjpjtOPF+CjYRkdJ0QHUXrkY2c+n8wA9IK+/RCNSAerX0ILKXWWvX36pgJaMaS1fmDu/L0uDufVwowxL3CB/4rrmH5kam9Qu6v8tVtQO3jRPA75bTVmvPPUpy7G/JW6oOLfZSrJV0vJyLDanOFzilaFTs5daUgSBXNaugDth2xL9+HuUsya8GN5fdDw2D5AcFUtce+6gFKTE8xU4ww==; 25:5ulmnTg/5bjWIL7Dz2elbh0tdvn/G/GvCey9mYs5MC9Q7hCG5tuh5EQeZ+z6uwP43qBsiz9ivuplkKtlVbk8Raq3djrgzRVxdx5MYQAU6sG/CXgDiNKFhdPgwCDMcz8/RQyoLzKS9DRoVyATondWFdskcMyIynCF2FzUkfMEhcQ6R9ezOsfRNRMxjeCofZS8oO7Vb2DxzzHHXse0ZG1+vaMtQXqmin7ZHmuuehc9IgDnRrL/YIAtMv4/v+cIQa5InqMkmHmLCLXlSN5B+H5e03guHL0ACy6mTPVEUluogcbJSfM/gDzMeiJOfUZmTF9DWIstdCvE6lau//6GNC2btJIzrmTPoKNUbW92hqyKKLVh1JyZnuQ+7CDYwNgVzQT9YkvIw/u6xlHm1o3u83wf0htqnso+fmRpZczKGhCDjTipt7J8rkeGENe5XMkCMzqRcrfNC5N6sOzt7BUg9FyYSA== X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 31:1c20cWveIIQ0RACdTVpq14+yWlBAeWbECt1dqY+azIHQSgo/hsXBeWp2+XKCmMsXeCI4V+wRrMdicT5AY6UcBzGw+/3/unhXv94b7IssyY6LXBFu3F33Hkj/ivQvJMjmbtAEjCOBeGfu3mGp19mmglqEz1ZVvSOC6YM2TnpfkjlzHVjEVmQIIb6LKDbf5MEHFopGEXSnNUDLNghaEwm+c9wcjXu18KqmVwpAQbjDSMEAUDq6T0D6XaK5cHyl7IVnVdfc3hsvwNuQRUW6KpTVExj18FEnX7OZMgVFingWr0Q=; 20:/yFah0/G/93szdtk/BcBgNlzq50lvbjLLT2ABqnRHL3GVX4sDtCetio3xNghL99aQtkLRjAjAuFxGkyThVunrYeM7yAWK/XPVVL/bhHf+JwB6zZctBFjb5/sVACxX9nw5goeeeWczFtC3o8bSegZ4AYgQSu2rHyiMXx2lemmKlNKXu27kNG/wS/p98WGKVyMSMB+EL1asvLWL3EfTlV9MyBCF0S8tw536Sl5LtC/dMrZhe+C1rZykbP+3Y2p9+jBrq8jQ1Uo1A5sKx1pPi190pJ3FB7DmS0bq9vId+dm/rUpCdIAfqR9mU3RUJ/PFtxSByXrDoBVu5NFvrF2HVGniYCR5ztIV+bAEadHI1FTVKc9WsJwYD/GnIZBxcGw13Zp/ehe2Dog2oesqVO2RzLZvi5igdHHpVypqSujBSQ1141Vbs8pkdc36rkQjRQzL/WWrp51XYV1qxlkNna93tUKP8UBNzB75u0F/sB5+2JygRzq1LC1/6vuc+dgwEmc38+4WBoKwf9iNa1cPBgELeQsyHewiYZR8V/g/AKx5p0OJC+P4nxr2hVAU65TyIIEkmpa2O9MS/tUzzWfbtUm1bS7murZPNlRqBF/mmdTwUe7ghw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(6040361)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6061324)(6041248)(20161123555025)(20161123562025)(20161123558021)(20161123564025)(20161123560025); SRVR:SN2PR05MB2510; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 4:MiToqN58BcdbnUfOjJQf1dQv9ehTqleKedtSUT99Y7k4M/4i/+XpUBoN5cmpOLA5WwDsrsCnd9t/hQrfWwo2hL/EaIZgnyrVaH4uTBfc4LHzvrdD7cVsRfRXs+UwUZLP3i/GYSIMls7wWY2GEHHdX/5lCjQ4+lUZqWlE2GdsorUFoI1Ij9OyXB3OOykQoecaZhpog7u2qzU3M7E8Hoil8+aiyvim4dt5T5tD+uAEzLoUDZTwB3LbmovIuGJxpJv/ZKTkxJuejAzCaxnkMMpz06i17WcBUzxaTDiojvWUAZBUw4AkgZwetKlPJ6G5C8kzRmMjfqJ+MIkUN6gXgtg6jC63kLuckx5yP26i/CDbYE2fCs9hYfRVAQNhhHpIv7Eg4GiWnecuslrrt5BGTPJFwBVnJoHGruHeuin8vbmknFOeTN6lyyqng35IcOKgX21pS9c9gaWMmetz3aluZFZgve9bKNovL30/5umn4UCYQa6x/86/ZKSjHc+3j0c6mjDbHsSh3TkHkLltu4x+di1RDweCaJWt5Nj6Up2O8D+ea1l4hF64VcBWARwj9/tF4/sU9o2CI6dC/Sjn+h3gsAJBWG8aX+ok7NvYpFtPUJxrtuKhgwqKdokJ+IS5x0QY9bCoZ9cdiwily/bGFfJFWLwPTb1QHohYjiZ8CWFD5ciu1W6K0tlVwnz4TEb7V8funCaKWUU8BailjAHevIzrE373zQ== X-Forefront-PRVS: 01401330D1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(24454002)(51914003)(189002)(377454003)(199003)(4326007)(2950100002)(6486002)(42186005)(6916009)(33656002)(305945005)(38730400001)(7846002)(7736002)(110136003)(39380400001)(50986999)(229853002)(106356001)(189998001)(733004)(97736004)(39410400001)(77096006)(76176999)(39450400002)(39400400001)(92566002)(39060400001)(5660300001)(105586002)(36756003)(101416001)(81156014)(50226002)(97756001)(82746002)(46406003)(81166006)(8746002)(83716003)(230783001)(47776003)(93886004)(68736007)(3846002)(2906002)(66066001)(6116002)(50466002)(23726003)(6666003)(8676002)(57306001)(86362001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2510; H:[172.29.33.83]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2510; 23:pPQy9k0ZuIrEPVGUq14hKKXtEY+FglDzwStQlZ139?= =?us-ascii?Q?YVzRFyUmb8O4QJxHSyLL1p+qXAOqMvgjqRikVEjJ3KvW6BsnH+j6pF5CsZcb?= =?us-ascii?Q?pJxuNU/+vuJrztQz5rnfkz8fGQPdtmbKVnQkCHSNxSZNOO3sdUuG7BvDmacd?= =?us-ascii?Q?n8+8sm30MVYmxZ5clGwW4HGkTda/6qs6kKCATLjvjslrtkew5riEQBzfGltW?= =?us-ascii?Q?YIGHgkJETfTArF23Ast/GoFamGuY/Ji8OILX84cCUtp8k4u7a++mOTwwVhnY?= =?us-ascii?Q?CoW6woiVhjGgq/JEMUxY+a2WUfzR0xlQeV6fh+hih6IU48PhIfvvtsPJdXBk?= =?us-ascii?Q?ofOG1WT85z8VW1BNJL07WLF7hJ10JvDvwIZjZvH7LQ42nF0D6iKsE5s9f9gF?= =?us-ascii?Q?0EiwqGgcJjOLh9nALuqSzcQFuI9/6ayZ4HvV7cCBkwaBvV3ovT2RsoE+60Oh?= =?us-ascii?Q?kJLPcK/CdocHaBi8MERdVQaXRADiFNoVVXEEHbGdIjcVjN77kbvPX63mQACf?= =?us-ascii?Q?1csgkZqKlWrHDJCbqkJ76Cw0ZdEwW0gjqHjfgcZ3ygui5eG3ASlTEsOMW1Bq?= =?us-ascii?Q?L2RnpOXAKTYtjVZfnq9jIPDuiCQAGzB1v74bxelBo9cgzn/kKXmuVCdnRS1s?= =?us-ascii?Q?gVHxi1KhScRxxaj7e4VSBKYB4VXA+wKq+n3K+e9qKpyAf0ohw1Y7dO8SeU2l?= =?us-ascii?Q?1RlQTLg6iDSHtCiyZK/dEfdq1/N0+295FjxGk1uG0CHsclKLrdjLk9kI2BSW?= =?us-ascii?Q?AQFPU0OCxplA3WKzLoD8MyjBrtYbNH+VDt1d4yCwofxD9LPmCc+aBXt0TvBl?= =?us-ascii?Q?bACS1t5VaCONerfNEFvk2bVug6QwMa2POVL/A6nVPJp4qedYSybjNGhKk/41?= =?us-ascii?Q?Tx62+/Y6ijjx5OEu8blejp++AwPaUMkHPBzBDvDqDQ93oCP1w0IsaD5hDB6l?= =?us-ascii?Q?hfizgSLUtobtRxDgnjYMyo7NtNrt9vWXJrghdV6J2yOxrY3ZfvsBrC2aW8sw?= =?us-ascii?Q?VEr2xk8Xg4mUjl/KXsC9Kb3RACfB2/DFy/K47uIQkiCEIfKjCsBSfmZ3UWyf?= =?us-ascii?Q?Q47vy/GXRQHvK445491ChYN4flYYNsXOb7Z3VmFpojs3RF9C+9bsffJ9UdcK?= =?us-ascii?Q?GcoJPv8LyIImha0/ZA77ZEZycSi9zPW3oR//rENITRGltYQNwGiA+OiesrQb?= =?us-ascii?Q?MnLYO5OdPrhRbvpXxDH0bKixg3h9u7P6mMnVk7RKKHb7BKsvWVIheHde6k43?= =?us-ascii?Q?w97IjyjXHX3Jwkw5MpwvSXpD5UT2MbCzdhK/XhCHY/aVDXWjzNo+KihRDVwP?= =?us-ascii?Q?ddUoEObDeNpELSmLtUAkpTDc3iPijCLdx+l8HVJF9ZUS9bv8jDISPu3vkRxe?= =?us-ascii?Q?3lICPgQAJPKDOwqXdHZHlPcV/tqlROqQl/H09AGMviaWN4tk3Fjo43P4ML1E?= =?us-ascii?Q?nrvpXQ5cUdPXiBFI47cQ504ruvzuAvpBDDU1dYkYDvgGBoowLmF?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 6:KmaRqt6Xbi345fvCRkpdiKRSWx523XQsD2BXmFb4jOQAxJ/en/mxpjFNcbWHA6XQgx+Om++SctIsEag1XdTlAi1zAJqpcD9DxHYNszQKJyY5O9bCJavUmHS2YfP+uzscP5cMkYBcwXzKLTree6ViUA0uwYKQIgc8YsJMMEkvulSKZWIiDClRFLLooQ55+VxU+b/3RUcwBgcTEsRCK11DhBri5Y2HoGARDv1FRKvwTgMbmVoILUCsWgi2mBbJpiZvv3fEzrJSVm+vNBPgF/IwitBhlI07SUgiCbac1F3XvgS+DXdC5z5aW716C4VkqVcewqpwthx1kTl/PPyv8SdRLntp9iGIis6P6FMRZ9O2zdgiPCh7OdZNbku8gSAlk5pxlPEnSBRQwMFfvUZZVCAFerhnYQ6HIPIHq4l9zjzHx1q57ViMF4Lem5oO2mhh3P8UnkP6iSHxVdMhstpivRZzxkjJzQ9JIA8mCooHtEoUxcdtTTv6e2+lPD+fhM2nk6bm; 5:g5m+p/LcUw5lRZcE3amtzxnWv27ZRUGDfl0u4A7BskmUfyfs592UWI5lbYsy0Q8hNu8EUE+BwpmUxuC79jnzy+3rh+J3jIdGHo47kmB9pt40FP1AH/at6S0Iv415T8gMQSWhnxw3zmNYyW0p0sA/4g==; 24:s0VLz/ZtDfAQeXA0oNaIO5Hz9GTt8xtbUjJDdRqvyQ+0Kfqh13lCAFapbPdYZ3VzXyTNbNOF/IlTGGDxHTBRdHY2Mlz3kGDH5hMUWZSX83E= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 7:4FE3YuCp/HLF4oeQJupavlcXBX8ZfLFrNjaG/R+G4Yc1mLqb9JP4H4zqMzWbYXgozdHtWDAnl3sSWHeX0Jkw9A1NIZFxmhSaPSJe1r48vLRRhkNB8o6UGZcW0WT1CDXPQzOVX3KULAwHWrHXKKEqQcqH2poy22Db0gTtLmYltfQVC7LL3/cgwTWS8JML0T3uxAB2hHUPONnaRMjScWjq7b18ymbJ96lEILFTlOTIW3/kwbziCmTI3y9EB+1HzBVbip1cipwkt1IaqzRnnnij2KRAB3h+WNZ2bnFlD803Dz8TKX88GlzKD7NsuNQagzqHpE+5PhkhKttVHTUsdzt5Iufk0lgYY0Pkpfyt+nhnxPAxgtJDmZLvqPt58PK9BDpdS3blcb4gIj6Qri2uJv6JL3N8bw42WOGd2LcbK/MRmOJuAIQhVpbXx8MaiDWhMwlMhCUWMnSg6bEp5hR3F9QZZg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2016 21:49:58.6293 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2510 Archived-At: Cc: secdir , Keyur Patel , David Ward , IESG , Pradosh Mohapatra Subject: Re: [secdir] Secdir review of draft-ietf-sidr-origin-validation-signaling-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 21:50:03 -0000 [Fixed up some addresses] > On Nov 28, 2016, at 12:47 PM, Randy Bush wrote: >=20 > This document describes a scheme where router A out-sources validation > to some router B. Out-sourcing security is generally dangerous. It = is > strongly recommend that, if this scheme is to be used, that the > participating routers be under the same administrative control; > i.e. router B has truest in router A, and that there be some assurance > of the propagation path (TCP/MD5 authentication etc.). >=20 > randy How about this? This document describes a scheme where router A outsources validation to some router B. If this scheme is to be used, the participating routers should have the appropriate trust relationship -- B should trust A either because they are under the same administrative control or for some other reason (for example, consider [draft-ietf-sidr-route-server-rpki-light]). The security properties of the propagation path between the two routers should also be considered. See [RFC 7454] Section 5.1 for advice regarding protection of the propagation path. (both refs informative) I'll wait a day or two for comments and if none, I'll publish. Thanks = for the text. --John= From nobody Mon Nov 28 17:48:05 2016 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 B6231129504; Mon, 28 Nov 2016 17:47:58 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 aPrWGAE9zRaj; Mon, 28 Nov 2016 17:47:57 -0800 (PST) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 226AD129F6B; Mon, 28 Nov 2016 17:47:57 -0800 (PST) Received: by mail-qk0-x243.google.com with SMTP id y205so15760990qkb.1; Mon, 28 Nov 2016 17:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ORzN1fAPSPAiZy12Qhnnlg5hePIJfe08kqmta4uCOSM=; b=GnojDvyaoNvhz8KRzEZHi1hVxW3euj/FGiPgRoBr+JbiZ+VflxHyuCP5aJwFOfJ3H1 lQ932CHo2oXxgGTJnq4UmaI1jlf/Fqs57R5GznIOMV3SzkPI3L8ePeOrW7DGZnD5CNy1 gPtAxII+0niY8KP6PgwIal0JZ3Qolxwv8KLvyT/Kp+/aCSq2vKcL6KBYmBK4yN3dqtJO 6MT1EkjUNmZtf73xq09YOQe5xGmXUeMR9TQD0x0VGx7fpDhvXB5I41sKkoqs/jRytAGd KY4ysqcCfm5XSf8dWK/dDJ4WQG6kyFBSGbyjpb/0yvo2wiKGOM2PzDRivV10zr2CYwPm Q0og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ORzN1fAPSPAiZy12Qhnnlg5hePIJfe08kqmta4uCOSM=; b=X3CkWfUewTFMIYudVqUuv+O2mhB+RsxIYPGOuM/0RlSMtMmB9qWdgllxcjS2aUWo// Uyw/84Ig37bbd4gS9uVtUjP4Edi1fs4PkvJs/5zfmoV1zjELLtOBoABkJFU9kU5DkD9R +4iobwOX/EjT9KzU8T1/LKJ/P2IpCXO5xH5cptqWiXOsp8BSnZy+XDUHXBa3tlyecECp 4JNVKni05yVV3p3xGVtoA6torFgvtwD4e872ML9T5BFuL9VqZOP+d4aRIajXwPDL9YS8 zNslQQjhokvpCqYapcXnZ6urburBLrfBrMj3ASuacctLKT1Tbglxi8ocJ2luzHMZz/KQ YfFA== X-Gm-Message-State: AKaTC02q50rx8/KMt3gf7giX1SarWRdPxfnwVbi67F9CuZr8iM8MIdNHW4Vv7/mjTaQrmP/M+1DaxWpGt1q3OA== X-Received: by 10.55.150.131 with SMTP id y125mr21826993qkd.115.1480384076290; Mon, 28 Nov 2016 17:47:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Mon, 28 Nov 2016 17:47:55 -0800 (PST) In-Reply-To: <91f59711-84e0-853c-8dd0-8157c7807a93@dret.net> References: <91f59711-84e0-853c-8dd0-8157c7807a93@dret.net> From: Martin Thomson Date: Tue, 29 Nov 2016 12:47:55 +1100 Message-ID: To: Erik Wilde Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF Security Directorate , draft-wilde-json-seq-suffix.all@ietf.org, The IESG , Sean Gillies Subject: Re: [secdir] Secdir review of: draft-wilde-json-seq-suffix X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 01:47:59 -0000 On 29 November 2016 at 05:00, Erik Wilde wrote: > https://github.com/dret/I-D/commit/8694a1efce71dcb96410be3bd6be8d0373383703 > switches the draft to experimental. to be honest, i do get conflicting info > on this, and depending on the people dealing with a draft, some seem to > prefer one status over the other. i have no strong opinion about this and > thus i am happy to switch to the status people think is most appropriate. Informational is probably a better choice. From nobody Mon Nov 28 18:12:24 2016 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 92AB112A24F; Mon, 28 Nov 2016 18:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.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 okbY3yB18K7x; Mon, 28 Nov 2016 18:12:16 -0800 (PST) Received: from postoffice.gristmillmedia.com (postoffice.gristmillmedia.com [96.30.18.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 5ECD8128B44; Mon, 28 Nov 2016 18:12:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To: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=f3OiY4Evti4qKLTJD6XGALMgL0i/xb4bw10A7T5wpko=; b=spBE0Ic+IFYBjhU9QsoeziIuK9 Iajp+lB5PifU8JtRAzk3fBM1Teg5xZQJN78ZIfDNDQuoq6+4gZ8cy5qFp14oi8nrLXkQf2uQhnlRA iAd1i+84pEEPokmj8SFSzt+5WW2oJNEKq3/wirzsVjEwywWMCLhQn6SDmaKij1nEocIVLfGEWx+sP WLUaSQVwN4RoenJsl786hgbNnXrrj7pWvkyBDcT4Jw/c+ewX5BTyCUDy9TVQlq6bguQANv/QDbSxd 3Vl6ii4J+np6osgmD6A5ZsPWunhu6K61V7rGYW9MBwEGW65bjPosW8TD2h7SsJioDZwGgYH33Ni9F RuPVLHmA==; Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:58011 helo=[192.168.1.67]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cBXu2-0001e7-Va; Mon, 28 Nov 2016 21:12:15 -0500 To: Martin Thomson References: <91f59711-84e0-853c-8dd0-8157c7807a93@dret.net> From: Erik Wilde Message-ID: <2882de2b-2af8-1e55-0fee-6297648ea438@dret.net> Date: Mon, 28 Nov 2016 18:12:13 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: IETF Security Directorate , draft-wilde-json-seq-suffix.all@ietf.org, The IESG , Sean Gillies Subject: Re: [secdir] Secdir review of: draft-wilde-json-seq-suffix X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 02:12:17 -0000 hello martin. On 2016-11-28 17:47, Martin Thomson wrote: > Informational is probably a better choice. alexey pointed that out as well. https://github.com/dret/I-D/commit/d0cf3ee1bf53288e8a86e9e62e9be6a2b95bfbda switches the draft to informational, but i haven't published a new version. i will do that after the next round of feedback. thanks and cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Mon Nov 28 19:04:46 2016 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 115AF12A259 for ; Mon, 28 Nov 2016 19:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 vQ1SiAGNl13E for ; Mon, 28 Nov 2016 19:04:44 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 104A51293DC for ; Mon, 28 Nov 2016 19:04:44 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cBYio-0002lx-75 for secdir@ietf.org; Tue, 29 Nov 2016 04:04:43 +0100 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cBYiI-0008L9-G7 for secdir@ietf.org; Mon, 28 Nov 2016 22:04:41 -0500 Received: (qmail 2593 invoked from network); 29 Nov 2016 03:04:07 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Nov 2016 03:04:06 -0000 From: "Christian Huitema" To: "'Paul Hoffman'" , "'Taylor, Rick'" References: <30706_1479279750_582C0485_30706_8297_7_C7F1D029-C067-4AF6-9F40-436F7BA54311@vpnc.org> <0AE7C2DE-B316-4675-B7BE-EB9AC50ED955@vpnc.org> In-Reply-To: <0AE7C2DE-B316-4675-B7BE-EB9AC50ED955@vpnc.org> Date: Mon, 28 Nov 2016 17:04:03 -1000 Message-ID: <003b01d249ed$3f003260$bd009720$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJO58gflm7yviVf6/Cfvo0tY/H6ngJp8YIyAbfck2mf1Pcy0A== Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dHEJL963yvZzofOAehTafloeD9ey9972JZ1Xcr1RWHu8UvfgoE7Tx8PYIcekOty5V3kY Ddr3TKXRcZQ4mEJmoSfmEQNc4kwsLgs13IMp2rYbUV8ShebT8U8Xw9HTDfreWQUhw0NOE6GJ4h1S yx3SVxxTMqX0PJmjOEykuntPB0mTf015vFX3Mr/p2bub/7pcobsBNjjE5Aa2bYPF/Ljub7D1nvJs XtU2nZ7nPOLF/Wn1ZymEi4ZQojpeZ03k33R0rsoAtgTaADGmLikT3swaYT40dKFOE3BfZETw255u BppYPVOv5BtNTjcagkYTbQLRBa8CWlWJ/Z52Y2lK4wxs0NlmM8dmYMoX9zl4nXWYGnFn3yzO1sNI xVAhudRU4os+nEeuHaHQ+7nQfs3MfDo0rdXACQIHPYrCd4PY+G/nx7QL+MTObVKxHy/dols381l9 ryOIyTwXkV5v9rYnjJeS/R+I6BZ65nwq5J5jOi1sCFUVVgW9/bktU41htiJ8fk7NkHtzJzDXtW19 p+oSJq/sPNS7pOEbN+JMueFd2wBL5ko+03rd0MueqeqFzadSbJ8EWv48M3dEN/L6l2KS1xSjSzJ8 mVtlmHTW6t+XF13aDiVUE2hrO9QGiyz48bSlEFaPeA== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.230 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.24) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: Cc: draft-ietf-manet-dlep.all@ietf.org, 'secdir' Subject: Re: [secdir] SecDir review of draft-ietf-manet-dlep X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 03:04:45 -0000 On Tuesday, November 22, 2016 5:46 AM, Paul Hoffman wrote: > On 22 Nov 2016, at 3:34, Taylor, Rick (External) wrote: > >> Thank you for the review. A couple of quick comments: >> >> Did you review draft-ietf-manet-dlep-15 or draft-ietf-manet-dlep-25=20 >> (the latest)? As we have attempted to address the security comments=20 >> raised by the WG and AD review. > > I reviewed -25; sorry for the typo in my report. I was asked to review draft-ietf-manet-credit-window-07, whose security properties are inherited from draft-ietf-manet-dlep-25, so I also = reviewed draft-ietf-manet-dlep-25. Like Paul, I find the security of DLEP pretty weak. DLEP =93requires that security of the implementations (e.g., authentication of stations, encryption of traffic, or both) is dealt = with by utilizing Layer 2 security techniques.=94 This layer 2 security model is effectively an implementation of = =93perimeter security=94, and has all the known issues with perimeter security. Two = classic attacks are =93finding a way to send packets through the perimeter=94 = and =93subvert a node already installed inside the perimeter=94. The draft = attempts to mitigate the first class of attacks by using the mechanism of RFC = 5082, although it does not actually use it correctly. There is no mitigation = for the =93subverted node=94 attack. >> One area we have worked hard on addressing is mandating use of = RFC5082=20 >> (Generalized TTL Security) on the link between router and modem (See=20 >> Section 3.1). =20 Not quite. RFC5082 suggests setting the TTL to 255 and checking the = value on the received message. Your draft suggests setting the TTL value to 1, = and checking the received value in the message. You need to fix that. >>... As you correctly state, DLEP does not have any inherent=20 >> security mechanisms, and recommends link-layer security, such as=20 >> 802.1X/AE, but we do mandate mechanisms to restrict the protocol to=20 >> run over a single hop. As you point out, DLEP is a control-plane=20 >> protocol and does not carry any user data. > > Noted. However, requiring TTL security doesn't prevent snooping or = MITM=20 > attacks. TTL security also does not provide any defense in depth. If the = attackers manage to gain access inside the perimeter, all bets are off. And there = is a history of such attacks, e.g., what if some test node on the secure link = is infected by a virus. Your architecture has zero protection there. Any = node can issue a discovery request, establish a DLEP session, and control the radio modem. That was OK in the 90's, but I do not believe that's = acceptable now. -- Christian Huitema =20 From nobody Tue Nov 29 04:14:41 2016 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 7E2D21299EF; Tue, 29 Nov 2016 04:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 mI6Rs9Ui8v-h; Tue, 29 Nov 2016 04:14:37 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB6E1296DB; Tue, 29 Nov 2016 04:08:44 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 29 Nov 2016 13:08:42 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 29 Nov 2016 13:08:41 +0100 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Nov 2016 13:08:41 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Nov 2016 13:08:41 +0100 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.03.0279.002; Tue, 29 Nov 2016 12:08:40 +0000 From: "Taylor, Rick (External)" To: Christian Huitema , 'Paul Hoffman' Thread-Topic: [secdir] SecDir review of draft-ietf-manet-dlep Thread-Index: AQHSP9dxooq1deGLb0CN9D0fTSXK8AJp8YIyAbfck2mf1Pcy0ID54YMA Date: Tue, 29 Nov 2016 12:08:40 +0000 Message-ID: References: <30706_1479279750_582C0485_30706_8297_7_C7F1D029-C067-4AF6-9F40-436F7BA54311@vpnc.org> <0AE7C2DE-B316-4675-B7BE-EB9AC50ED955@vpnc.org> <4035_1480388659_583CF032_4035_1030_1_003b01d249ed$3f003260$bd009720$@huitema.net> In-Reply-To: <4035_1480388659_583CF032_4035_1030_1_003b01d249ed$3f003260$bd009720$@huitema.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.22.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Nov 2016 12:08:41.0303 (UTC) FILETIME=[52FC6670:01D24A39] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-7.500.1017-22728.006 X-TM-AS-Result: No--28.847800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Archived-At: Cc: "draft-ietf-manet-dlep.all@ietf.org" , 'secdir' Subject: Re: [secdir] SecDir review of draft-ietf-manet-dlep X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 12:14:39 -0000 Hi All, Thank you both for your reviews and further comments. I'm not the author of= draft-ietf-manet-credit-window-07, but am one of the authors of draft-ietf= -manet-dlep-25. However, as the security of the credit windowing extension= relies on the underlying security considerations of DLEP, I feel I can res= pond. A few comments inline... > -----Original Message----- > From: Christian Huitema [mailto:huitema@huitema.net] > Sent: 29 November 2016 03:04 > To: 'Paul Hoffman'; Taylor, Rick (External) > Cc: 'secdir'; draft-ietf-manet-dlep.all@ietf.org > Subject: RE: [secdir] SecDir review of draft-ietf-manet-dlep > > On Tuesday, November 22, 2016 5:46 AM, Paul Hoffman wrote: > > On 22 Nov 2016, at 3:34, Taylor, Rick (External) wrote: > > > >> Thank you for the review. A couple of quick comments: > >> > >> Did you review draft-ietf-manet-dlep-15 or draft-ietf-manet-dlep-25 > >> (the latest)? As we have attempted to address the security comments > >> raised by the WG and AD review. > > > > I reviewed -25; sorry for the typo in my report. > > I was asked to review draft-ietf-manet-credit-window-07, whose security > properties are inherited from draft-ietf-manet-dlep-25, so I also reviewe= d > draft-ietf-manet-dlep-25. Like Paul, I find the security of DLEP pretty w= eak. > DLEP "requires that security of the implementations (e.g., authentication= of > stations, encryption of traffic, or both) is dealt with by utilizing Laye= r 2 > security techniques." > > This layer 2 security model is effectively an implementation of "perimete= r > security", and has all the known issues with perimeter security. Two clas= sic > attacks are "finding a way to send packets through the perimeter" and > "subvert a node already installed inside the perimeter". The draft attemp= ts > to mitigate the first class of attacks by using the mechanism of RFC 5082= , > although it does not actually use it correctly. There is no mitigation fo= r the > "subverted node" attack. There has been extensive discussion within the WG on this topic, and we do = fully understand the concerns. The security of DLEP has always been a majo= r worry for the authors/WG as we are being pulled in two directions: The s= ticking point is the situation where an implementer has the modem and route= r as two separate modules in a single chassis (or secured perimeter), and w= ants to avoid the perceived complexity/annoyance of implementing TLS. The= authors have received off-the-record comment from major radio vendors stat= ing that they will not adopt DLEP if it requires TLS. However, I agree tha= t both your comments are absolutely valid. The question is how to reconcil= e the difference? We are searching for some mechanism that would allow the protocol to: a) Specify how to secure the session correctly. b) Secure the session by default. c) Allow either peer to waive the requirement for security in a way that ca= nnot be maliciously downgraded. Is a STARTTLS style approach acceptable? Or is an http/https style two port= approach preferred? I'm not asking for the solution, but trying to avoid = wasting your and our time. > > >> One area we have worked hard on addressing is mandating use of > >> RFC5082 (Generalized TTL Security) on the link between router and > >> modem (See Section 3.1). > > Not quite. RFC5082 suggests setting the TTL to 255 and checking the value= on > the received message. Your draft suggests setting the TTL value to 1, and > checking the received value in the message. You need to fix that. TTL 1 is required for the discovery mechanism (UDP mcast) in an attempt to = restrict packets to a single hop (particularly for IPv4), but the TCP conne= ction for the session must use TTL 255 as per RFC5082 (The paragraph above)= . We might consider re-ordering the paragraphs if you think it is unclear. * snip * Many thanks, Rick Taylor The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or distribut= ion is prohibited. Please also contact the sender and inform them of the er= ror and delete the e-mail, including any attached files from your system. Emails to Airbus Defence and Space Limited may be processed, recorded and m= onitored anywhere in the European Community. Airbus Defence and Space Limited Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS. Registered in England and Wales under company number 02449259. From nobody Tue Nov 29 06:11:49 2016 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 42321129AE0; Tue, 29 Nov 2016 06:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 NpgYPz7haPif; Tue, 29 Nov 2016 06:11:46 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA05129670; Tue, 29 Nov 2016 06:11:45 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id uATEBi7i024454; Tue, 29 Nov 2016 09:11:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1480428704; bh=hx+j0t1jbRUCBHMvyRPScbPGKJf8LxXHl5bSDyzQzfY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To; b=Dwgbtdp6AvfCI2mV2kBtuUiXJsPhzyilu9BVjUVWojoSNwoBp5EXznzV0XARi+b/K V0wkAHPatqidiwUk8C++a/EcO++h5w7LlDzhk5iIpIvSDpaIyPrM3LPbQ2yw3vGmN/ 2FRTzKuONEXDvN2rpmEyWcsSPtt6BCSQnPw2Bs+g= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id uATEBfrw004144; Tue, 29 Nov 2016 09:11:42 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0319.002; Tue, 29 Nov 2016 09:11:41 -0500 From: Chris Inacio To: Sean Turner Thread-Topic: [secdir] SECDIR review of draft-ietf-sidr-bgpsec-algs-16 Thread-Index: AQHSRN51t+tWjKyq8EGqOIAmo07R6KDlrngAgAqwnAA= Date: Tue, 29 Nov 2016 14:11:39 +0000 Message-ID: References: <2C424863-2993-4E7C-9B32-F35A5404422D@cert.org> <9141B17E-BB54-47EB-B6B2-D6D2BDFA8744@sn3rd.com> In-Reply-To: <9141B17E-BB54-47EB-B6B2-D6D2BDFA8744@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.51.97] Content-Type: multipart/alternative; boundary="_000_etPan583d8c9b26b686ea2afcertorg_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-side-bgpsec-algs.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-sidr-bgpsec-algs-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 14:11:48 -0000 --_000_etPan583d8c9b26b686ea2afcertorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT48bWFpbHRvOnNlYW5Ac24zcmQu Y29tPg0KRGF0ZTogTm92ZW1iZXIgMjIsIDIwMTYgYXQgMTo1NzowMyBQTQ0KVG86IENocmlzIElu YWNpbyA8aW5hY2lvQGNlcnQub3JnPjxtYWlsdG86aW5hY2lvQGNlcnQub3JnPg0KQ2M6IHNlY2Rp ckBpZXRmLm9yZyA8c2VjZGlyQGlldGYub3JnPjxtYWlsdG86c2VjZGlyQGlldGYub3JnPiwgaWVz Z0BpZXRmLm9yZyA8aWVzZ0BpZXRmLm9yZz48bWFpbHRvOmllc2dAaWV0Zi5vcmc+LCBkcmFmdC1p ZXRmLXNpZHItYmdwc2VjLWFsZ3MtMTYuYWxsQHRvb2xzLmlldGYub3JnIDxkcmFmdC1pZXRmLXNp ZHItYmdwc2VjLWFsZ3MtMTYuYWxsQHRvb2xzLmlldGYub3JnPjxtYWlsdG86ZHJhZnQtaWV0Zi1z aWRyLWJncHNlYy1hbGdzLTE2LmFsbEB0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6ICBSZTogW3Nl Y2Rpcl0gU0VDRElSIHJldmlldyBvZiBkcmFmdC1pZXRmLXNpZHItYmdwc2VjLWFsZ3MtMTYNCg0K DQo+IE9uIE5vdiAyMiwgMjAxNiwgYXQgMTE6MzUsIENocmlzIEluYWNpbyA8aW5hY2lvQGNlcnQu b3JnPiB3cm90ZToNCj4NCj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBv ZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxs IElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVu dHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5 IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRy ZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRz Lg0KPg0KPiBUaGlzIGRvY3VtZW50IGlzOiBSZWFkeSB3aXRoIG5pdHMNCj4NCj4gTklUOiBTZWN0 aW9uIDMuMSBQdWJsaWMgS2V5IEZvcm1hdA0KPiAiU2VjdGlvbiAyLjEuMSIgbGlua3MgdG8gdGhl IGN1cnJlbnQgZG9jdW1lbnQgYW5kIG5vdCB0byBSRkM1NDgwIGluIHRoZSBpbml0aWFsIHJlZmVy ZW5jZS4NCg0KVG9vayBtZSBhIGJpdCB0byBmaWd1cmUgdGhpcyBvdXQ6IFlvdeKAmXJlIHRhbGtp bmcgYWJvdXQgdGhlIGhtdGwgdmVyc2lvbiByaWdodD8gSSBoYXZlbuKAmXQgYSBjbHVlIHdoeSBp dOKAmXMgZG9pbmcgdGhhdCBidXQgSeKAmWxsIG1ha2Ugc3VyZSB0aGUgZmluYWwgSFRNTCB2ZXJz aW9uIGRvZXNu4oCZdCBkbyB0aGlzIChieSBhc2tpbmcgdGhlIFJGQyBlZGl0b3IgdG8gbWFrZSBz dXJlIGl0IGRvZXNu4oCZdCBoYXBwZW4gOykuDQoNCnNwdA0KDQoNClRoZSBkcmFmdCB3YXMgc2hv cnQgZW5vdWdoIHRoYXQgSSByZXZpZXdlZCBpdCB2aWEganVzdCByZWFkaW5nIHRoZSB0b29scy5p ZXRmLm9yZyBzaXRlLCBzbyB5ZXMuICBBbmQsIGZyYW5rbHksIEkgb25seSBmb3VuZCBpdCBiZWNh dXNlIEkgdXNlZCBvbmUgb2YgdGhlIG90aGVyIGxpbmtzIGluIHRoZSBkb2N1bWVudCB0byBnZXQg dG8gYW5vdGhlciBSRkMgZm9yIGJhY2tncm91bmQuICBBbmQgSSBsaWtlIHlvdXIgc29sdXRpb24u ICA6KQ0KDQoNCi0tDQpDaHJpcyBJbmFjaW8NCmluYWNpb0BjZXJ0Lm9yZzxtYWlsdG86aW5hY2lv QGNlcnQub3JnPg0K --_000_etPan583d8c9b26b686ea2afcertorg_ Content-Type: text/html; charset="utf-8" Content-ID: <2393CD59B7ECBF4EBA9FF01E0F61501B@sei.cmu.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5e2ZvbnQtZmFtaWx5OlNvdXJj ZSBTYW5zIFBybyxBcmlhbDtmb250LXNpemU6MTNweH08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkg c3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGlkPSJibG9vcF9j dXN0b21mb250IiBzdHlsZT0iZm9udC1mYW1pbHk6U291cmNlIFNhbnMgUHJvLEFyaWFsO2ZvbnQt c2l6ZToxM3B4OyBjb2xvcjogcmdiYSgwLDAsMCwxLjApOyBtYXJnaW46IDBweDsgbGluZS1oZWln aHQ6IGF1dG87Ij4NCjxicj4NCjwvZGl2Pg0KPGJyPg0KPGRpdiBpZD0iYmxvb3Bfc2lnbl8xNDgw NDI4NDMzNjI3NTE1MTM2IiBjbGFzcz0iYmxvb3Bfc2lnbiI+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpoZWx2ZXRpY2EsYXJpYWw7Zm9udC1zaXplOjEzcHgiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogJ1NvdXJjZSBTYW5zIFBybycsIEFyaWFsOyI+RnJvbTombmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiAnU291cmNlIFNhbnMgUHJvJywgQXJpYWw7Ij5TZWFuIFR1cm5l cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdTb3VyY2UgU2FucyBQcm8nLCBBcmlh bDsiPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZWFuQHNuM3JkLmNvbSIgc3R5bGU9ImZvbnQt ZmFtaWx5OiAnU291cmNlIFNhbnMgUHJvJywgQXJpYWw7Ij4mbHQ7c2VhbkBzbjNyZC5jb20mZ3Q7 PC9hPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJhaXJtYWlsX2V4dF9vbiIgc3R5bGU9ImNv bG9yOmJsYWNrIj5EYXRlOiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Tm92ZW1iZXIg MjIsIDIwMTYgYXQgMTo1NzowMyBQTTwvc3Bhbj48YnI+DQpUbzombmJzcDs8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkNocmlzIEluYWNpbzwvc3Bhbj4gPGEgaHJlZj0ibWFpbHRvOmluYWNpb0Bj ZXJ0Lm9yZyI+DQombHQ7aW5hY2lvQGNlcnQub3JnJmd0OzwvYT48YnI+DQpDYzombmJzcDs8c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPnNlY2RpckBpZXRmLm9yZzwvc3Bhbj4gPGEgaHJlZj0ibWFp bHRvOnNlY2RpckBpZXRmLm9yZyI+DQombHQ7c2VjZGlyQGlldGYub3JnJmd0OzwvYT4sIDxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+aWVzZ0BpZXRmLm9yZzwvc3Bhbj4gPGEgaHJlZj0ibWFpbHRv Omllc2dAaWV0Zi5vcmciPg0KJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7PC9hPiwgPHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5kcmFmdC1pZXRmLXNpZHItYmdwc2VjLWFsZ3MtMTYuYWxsQHRvb2xzLmll dGYub3JnPC9zcGFuPg0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc2lkci1iZ3BzZWMtYWxn cy0xNi5hbGxAdG9vbHMuaWV0Zi5vcmciPiZsdDtkcmFmdC1pZXRmLXNpZHItYmdwc2VjLWFsZ3Mt MTYuYWxsQHRvb2xzLmlldGYub3JnJmd0OzwvYT48YnI+DQpTdWJqZWN0OiZuYnNwOzxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+IFJlOiBbc2VjZGlyXSBTRUNESVIgcmV2aWV3IG9mIGRyYWZ0LWll dGYtc2lkci1iZ3BzZWMtYWxncy0xNg0KPGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGJyPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSJjbGVhbl9icSIgc3R5bGU9ImZvbnQtZmFt aWx5OiAnU291cmNlIFNhbnMgUHJvJywgQXJpYWw7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8c3Bhbj4N CjxkaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQomZ3Q7IE9uIE5vdiAyMiwgMjAxNiwgYXQg MTE6MzUsIENocmlzIEluYWNpbyAmbHQ7aW5hY2lvQGNlcnQub3JnJmd0OyB3cm90ZTo8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OzxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7IEkg aGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVj dG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWlu ZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmlt YXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9j dW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzDQogc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7PHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsgVGhpcyBkb2N1bWVu dCBpczogUmVhZHkgd2l0aCBuaXRzPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCiZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyBOSVQ6IFNlY3Rpb24gMy4xIFB1YmxpYyBLZXkgRm9y bWF0PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CiZndDsgJnF1b3Q7U2VjdGlvbiAyLjEuMSZxdW90OyBsaW5rcyB0byB0aGUgY3VycmVudCBkb2N1 bWVudCBhbmQgbm90IHRvIFJGQzU0ODAgaW4gdGhlIGluaXRpYWwgcmVmZXJlbmNlLjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpUb29r IG1lIGEgYml0IHRvIGZpZ3VyZSB0aGlzIG91dDogWW914oCZcmUgdGFsa2luZyBhYm91dCB0aGUg aG10bCB2ZXJzaW9uIHJpZ2h0PyBJIGhhdmVu4oCZdCBhIGNsdWUgd2h5IGl04oCZcyBkb2luZyB0 aGF0IGJ1dCBJ4oCZbGwgbWFrZSBzdXJlIHRoZSBmaW5hbCBIVE1MIHZlcnNpb24gZG9lc27igJl0 IGRvIHRoaXMgKGJ5IGFza2luZyB0aGUgUkZDIGVkaXRvciB0byBtYWtlIHN1cmUgaXQgZG9lc27i gJl0IGhhcHBlbiA7KS48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGJyPg0KPGJyPg0Kc3B0PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cD48YnI+DQo8L3A+DQo8cD5UaGUgZHJhZnQgd2FzIHNob3J0IGVub3VnaCB0aGF0IEkgcmV2 aWV3ZWQgaXQgdmlhIGp1c3QgcmVhZGluZyB0aGUgdG9vbHMuaWV0Zi5vcmcgc2l0ZSwgc28geWVz LiAmbmJzcDtBbmQsIGZyYW5rbHksIEkgb25seSBmb3VuZCBpdCBiZWNhdXNlIEkgdXNlZCBvbmUg b2YgdGhlIG90aGVyIGxpbmtzIGluIHRoZSBkb2N1bWVudCB0byBnZXQgdG8gYW5vdGhlciBSRkMg Zm9yIGJhY2tncm91bmQuICZuYnNwO0FuZCBJIGxpa2UgeW91ciBzb2x1dGlvbi4gJm5ic3A7Oik8 L3A+DQo8cD48YnI+DQo8L3A+DQo8ZGl2IGlkPSJibG9vcF9zaWduXzE0ODA0Mjg0MzM2Mjc1MTUx MzYiIGNsYXNzPSJibG9vcF9zaWduIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBoZWx2ZXRp Y2EsIGFyaWFsOyI+LS0mbmJzcDs8YnI+DQpDaHJpcyBJbmFjaW88YnI+DQo8YSBocmVmPSJtYWls dG86aW5hY2lvQGNlcnQub3JnIj5pbmFjaW9AY2VydC5vcmc8L2E+PC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_etPan583d8c9b26b686ea2afcertorg_-- From nobody Tue Nov 29 06:59:17 2016 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 7AF311293FD; Tue, 29 Nov 2016 06:59:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Qt_SPvPAf6If; Tue, 29 Nov 2016 06:59:13 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 AF27F12969E; Tue, 29 Nov 2016 06:59:13 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 20so180614880uak.0; Tue, 29 Nov 2016 06:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=5DsCNSW9e7Jt5gHQ6nxunSsr5N65jbYWHxcCrb29voE=; b=f2QiHvGHb9fDRrE6G6J9ETGJJtYKay0jeNzzUih74yuN/p8d85J9RAhXXvDh6U5U7n ERo15fQqq4A/atW6LpZkir+X03a45zRIA3EvMWvKTiXNFMqgGZcgrR2oQ/qjveF1gOt6 oQgkiLq+OlfWlv5MM8Ifv1W+yFtysDdH8S1/JutYUhOt2cN/TFbZNr6Fmsd858rK8w0D ksccORYiKcufHzpIDZ3j9rP7gNwCtI6IaMIZ3FJ86mcdnupz51zMx9oLIHxkMHn+C5XS ijbdTa5MqhR3MC/zlRk9lwCdT8dKVvSiPzyotU/FcdACuASbttKW7qdYbPucN0+nWWwj UsmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5DsCNSW9e7Jt5gHQ6nxunSsr5N65jbYWHxcCrb29voE=; b=QzuqkIiah+NxDgJXiw/ygEGOZBb+hLnayDstiJ7oDad2tSxFW0oxUk0+lQwk9Sfsty S9RKvPH6T1Cm/sWrQpiDFg5fYIp2+FxIy55Pel4HdIP55adG+BYer7Odk+g76PYBPa6z RTsWN2sLPxZ7XpfButEwI9AqDGbvsVmFOsBDKJsc8+8vLeGaf1NqMukfWW8E0Bn+nMHO LHkjGzA2dsw6py0q3y6W9BIRxd6Ips8hF98OWFkAXR3XwCaWmWAdhqAKLc5MlFMda7JP wyib8rmx+ArDlOKhzNwOXc9bQ97apybaz+A06Nxaw9ILfSRQNunzyVDNwzLeeHSG+z82 Pukw== X-Gm-Message-State: AKaTC00BwatU72d5WlAEFlu3m99DfQcTg3k5/ZEiIbbPj4BoR7qjsn+dzW198byXA8pfsS7qka5LqAAjjC/eWw== X-Received: by 10.159.33.193 with SMTP id 59mr20189485uac.28.1480431552583; Tue, 29 Nov 2016 06:59:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.37.66 with HTTP; Tue, 29 Nov 2016 06:59:12 -0800 (PST) From: Watson Ladd Date: Tue, 29 Nov 2016 06:59:12 -0800 Message-ID: To: "" , secdir@ietf.org, draft-adid-urn-01.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] secdir review of draft-adid-urn-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 14:59:16 -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. I believe this draft is ready. It's nice to see someone note that properly checking for equivalence matters. Sincerely, Watson From nobody Tue Nov 29 10:49:28 2016 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 C3505129649; Tue, 29 Nov 2016 10:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 UvcAzOXa4q8N; Tue, 29 Nov 2016 10:49:17 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 7B26A1294A2; Tue, 29 Nov 2016 10:49:14 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id n6so164909653qtd.1; Tue, 29 Nov 2016 10:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=H0UrE3vTj5vBbw2LNTHWDQD2tutCxtRL6SUZ7rfHudE=; b=oD2dW2R/MbUfjYzRoRDgKKXSuCIeAhVmx7LQ4D9PM1cdNg8iN84Nv22N3cVZpf0bdR E2sPmsC3azx6A8zfmRhiw3cOwxYBmYSkCmxSbdMkOumr238QaNInWZOQR7VRMgxLUfB9 fw1+i44k4WN+G4zd9TXyYTfgt+xNkM4EsPy97XU6nRPemmxs1VC8JJOd61OOzPIVaZVw fcfR3gq8Mo3vfXFY8KJ+YnDvXYTQXlsIctzjKmM0Iu6iABzYqB3O3IQn9epfpJT2Rkm7 U8JW6cu+/amJ66WayvN9hVXZg0wO/79t+W578Gt8MR00eKw/4pdLU+g2PBBEfitvbbCB 4mGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc:content-transfer-encoding; bh=H0UrE3vTj5vBbw2LNTHWDQD2tutCxtRL6SUZ7rfHudE=; b=mlgnSmMMfs91j3uWiB5PnZLtWX9qCFDs0CdDJKFVGvHaFdIT2GHc2S7zUSkgGm29Lr YLygzFNfFSkSbvPbcjjwTZqZtsfsqekH6xYxP9UKT5KY9i5KYLOKl+Rizi1H8mrdvXY+ AKHRdRifAXLNzQOEQQYr8u6zW2gf0HLemL6gCad5Fo9Y17GDie92tfnGWmKk8rBqF8Uw 36+DwzuKJ9L4owGazVHagJczwXMkw+FpRuw2AEULBX1W6mAbqJauQTq03TYb6rWK2JYr NKn44ir+Z7KVzyHPf4utxfkwzgMVpDwpSwe1ZtF4uAczhjFAb30hkJWe/6wGtQMQpPwM +0nw== X-Gm-Message-State: AKaTC01oy4mFqkDzpDgMcGCtb197m4GuHGnWxABHUtdqHB67QSIzuVrzD+mTN4a4NEOqKNKICbwcOTQrIiNpVg== X-Received: by 10.200.38.239 with SMTP id 44mr26470724qtp.91.1480445353329; Tue, 29 Nov 2016 10:49:13 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.140.41.177 with HTTP; Tue, 29 Nov 2016 10:49:12 -0800 (PST) From: Barry Leiba Date: Tue, 29 Nov 2016 13:49:12 -0500 X-Google-Sender-Auth: Y_oH2YhpFtKbsQknNx-7fFQEDCE Message-ID: To: draft-ietf-appsawg-file-scheme.all@ietf.org, "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: art@ietf.org, IETF discussion list Subject: [secdir] SecDir review of draft-ietf-appsawg-file-scheme-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 18:49:24 -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. Thanks for finally getting this through. I think the document is ready with nits; my detailed comments are below. It=E2=80=99s a tiny thing, but where the abstract says =E2=80=9Creplacing t= he definition in RFC 1738,=E2=80=9D one may be led to think (I was) that 1738 = has a more robust definition than it does. D=E2=80=99you mind changing that to something like this: =E2=80=98This document provides a full specification o= f the "file" Uniform Resource Identifier (URI) scheme, replacing the very brief definition in Section 3.10 of RFC 1738.=E2=80=99 The Security Considerations section is well thought out; thanks. The only thing I can think of that might be added is a few words about non-local file URIs. Section 3 says two significant things that should be highlighted in a security consideration: 1. A file URI can be dependably dereferenced or translated to a local file path only if it is local. 2. This specification neither defines nor forbids any set of operations that might be performed on a file identified by a non-local file URI. Given those two things, I think it would be worth explicitly saying that treating a non-local URI as local or otherwise attempting to perform local operations on a non-local URI can result in security problems. Matthew=E2=80=99s name and address will be on the RFC, of course, but is th= at really the best choice for contact information for the scheme in the registry? Or would it be better to point people to =E2=80=9CApplications a= nd Real-Time Area =E2=80=9D ? In general, we seem to have mixed feelings about listing individuals as contact points for things registered by working group documents (and I fall on the =E2=80=9Cavoid usi= ng specific individuals=E2=80=9D side, because individuals often come and go o= ver relatively short time). The =E2=80=9CReferences=E2=80=9D in the registry template should just be = =E2=80=9Cthis RFC=E2=80=9D, and this RFC number will appear in the registry. A bit of process geekery: In the Acknowledgments, you say=E2=80=A6 This specification is derived from [RFC1738], [RFC3986], and [I-D.hoffman-file-uri] (expired); the acknowledgements in those documents still apply. I don=E2=80=99t imagine there=E2=80=99s actually text from 1738 in here (is= there?). How much text is here from 3986? I=E2=80=99m not talking about concepts, b= ut actual text that was brought over. If there is, have you made sure that all authors of the documents you got text from agree to the terms of BCPs 78 & 79 ? If not, there might need to be a pre-5378 disclaimer in the boilerplate. I suspect we=E2=80=99re OK, because we=E2= =80=99re mostly talking about Larry, Roy, and TimBL, but I just wanted to check. (I personally think the acknowledgments text above is a bit much, unless you=E2=80=99ve really copied a lot of text from those RFCs. But tha= t=E2=80=99s your section to do with as you think best.) References: I don=E2=80=99t think BCP35 is normative, and I=E2=80=99d move it to inform= ative. I don=E2=80=99t think UAX15 is normative, and I=E2=80=99d move it to inform= ative. I think UTF-8 is normative (as you have it), but UNICODE is not. Others might disagree with that. I think I would make RFC 6454 normative, only because it=E2=80=99s listed a= s a reference for =E2=80=9Cthe most secure option=E2=80=9D in the Security Cons= iderations. Barry From nobody Tue Nov 29 11:04:30 2016 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 479D4129C31; Tue, 29 Nov 2016 11:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 cc6Tz4Kvsk04; Tue, 29 Nov 2016 11:04:28 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 64471129C29; Tue, 29 Nov 2016 11:04:28 -0800 (PST) Received: from [10.32.60.81] (50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id uATJ44VU008806 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Nov 2016 12:04:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163] claimed to be [10.32.60.81] From: "Paul Hoffman" To: "Barry Leiba" Date: Tue, 29 Nov 2016 11:04:25 -0800 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: art@ietf.org, draft-ietf-appsawg-file-scheme.all@ietf.org, IETF discussion list , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-appsawg-file-scheme-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 19:04:30 -0000 On 29 Nov 2016, at 10:49, Barry Leiba 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. > > Thanks for finally getting this through. I think the document is > ready with nits; my detailed comments are below. > > It’s a tiny thing, but where the abstract says “replacing the > definition in RFC 1738,” one may be led to think (I was) that 1738 > has > a more robust definition than it does. D’you mind changing that to > something like this: ‘This document provides a full specification of > the "file" Uniform Resource Identifier (URI) scheme, replacing the > very brief definition in Section 3.10 of RFC 1738.’ Agree. (Humorously, I have some standing here; see below.) > > The Security Considerations section is well thought out; thanks. The > only thing I can think of that might be added is a few words about > non-local file URIs. Section 3 says two significant things that > should be highlighted in a security consideration: > 1. A file URI can be dependably dereferenced or translated to a local > file path only if it is local. > 2. This specification neither defines nor forbids any set of > operations that might be performed on a file identified by a non-local > file URI. > > Given those two things, I think it would be worth explicitly saying > that treating a non-local URI as local or otherwise attempting to > perform local operations on a non-local URI can result in security > problems. Agree. > Matthew’s name and address will be on the RFC, of course, but is > that > really the best choice for contact information for the scheme in the > registry? Or would it be better to point people to “Applications > and > Real-Time Area ” ? In general, we seem to have mixed > feelings about listing individuals as contact points for things > registered by working group documents (and I fall on the “avoid > using > specific individuals” side, because individuals often come and go > over > relatively short time). Agree. > The “References” in the registry template should just be “this > RFC”, > and this RFC number will appear in the registry. > > A bit of process geekery: > In the Acknowledgments, you say… > This specification is derived from [RFC1738], [RFC3986], and > [I-D.hoffman-file-uri] (expired); the acknowledgements in those > documents still apply. > > I don’t imagine there’s actually text from 1738 in here (is > there?). > How much text is here from 3986? I’m not talking about concepts, > but > actual text that was brought over. If there is, have you made sure > that all authors of the documents you got text from agree to the terms > of BCPs 78 & 79 ? If not, there might need to be a pre-5378 > disclaimer in the boilerplate. I suspect we’re OK, because we’re > mostly talking about Larry, Roy, and TimBL, but I just wanted to > check. > > (I personally think the acknowledgments text above is a bit much, > unless you’ve really copied a lot of text from those RFCs. But > that’s > your section to do with as you think best.) I remember that draft-hoffman-file-uri copied from 1739 and 3986. I also remember running away sobbing from the draft, so I appreciate that someone with more fortitude took it up again. > References: > I don’t think BCP35 is normative, and I’d move it to informative. > I don’t think UAX15 is normative, and I’d move it to informative. > I think UTF-8 is normative (as you have it), but UNICODE is not. > Others might disagree with that. I agree with all those. > I think I would make RFC 6454 normative, only because it’s listed as > a > reference for “the most secure option” in the Security > Considerations. Sure. --Paul Hoffman From nobody Tue Nov 29 15:11:29 2016 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 30308129CBB; Tue, 29 Nov 2016 15:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 4eesJrsjLXuY; Tue, 29 Nov 2016 15:11:23 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 B2C561294A8; Tue, 29 Nov 2016 15:11:00 -0800 (PST) X-AuditID: 12074425-77fff70000002ca0-b8-583e0b030be5 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 03.B0.11424.30B0E385; Tue, 29 Nov 2016 18:10:59 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id uATNAw79018804; Tue, 29 Nov 2016 18:10:59 -0500 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uATNAvbn005510; Tue, 29 Nov 2016 18:10:58 -0500 From: Tom Yu To: iesg@ietf.org, secdir@ietf.org, draft-leiba-3967upd-downref.all@ietf.org Date: Tue, 29 Nov 2016 18:10:57 -0500 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUixG6nrsvMbRdhsHu2ocX3K/sYLWb8mchs 8WHhQxYHZo8lS34yBTBGcdmkpOZklqUW6dslcGWseMtV0MVW0bzqN1MD4z+WLkZODgkBE4l5 X34wdjFycQgJtDFJzPh1kBnC2cgo8XDdWSYI5w2jxMvGT2AtbALSEscv7wJKcHCICPhIXL6m BhIWFrCQmDFtJytImEVAVeLrGR8Qk1dAV6KjKw2kgkeAU+LkzK1sIDavgCCQ/QRsILOAlsSN fy+ZJjDyzEKSmoUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGuhV5uZoleakrpJkZwqLio 7mCc89frEKMAB6MSD++EPtsIIdbEsuLK3EOMkhxMSqK8/44AhfiS8lMqMxKLM+KLSnNSiw8x SnAwK4nwSnHYRQjxpiRWVqUW5cOkpDlYlMR5/7t9DRcSSE8sSc1OTS1ILYLJynBwKEnwHuQE ahQsSk1PrUjLzClBSDNxcIIM5wEaHgFSw1tckJhbnJkOkT/FqMvxbvO7B0xCLHn5ealS4ryz QIoEQIoySvPg5oBjXIhx3ytGcaC3hHlXgFTxANMD3KRXQEuYgJa8fW0NsqQkESEl1cC4msts 9Udj94VrYw3t9zec2BOdf8raWPuf06LXLC9DFnBpqNwW/CGUryTxKbbCeaOu8hvGVqnfd/6e bv/3QPn3+VMK9VYcyluag7Y6yt28FLHyxU0TRm1zy1seZ+85GMtOyAlb8Z716abkZQ17Fz0/ uGPJJi3hxxOfLXvmVJmW1aCTMFEva+pzJZbijERDLeai4kQAcz8sjswCAAA= Archived-At: Subject: [secdir] secdir review of draft-leiba-3967upd-downref-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 23:11:24 -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. Summary: ready with nits The Security Considerations changes added in -01 seem good. Comment: Could the responsible AD annotate each "safe" normative downref (doesn't require community review), along with the rationale? (e.g., foundational or architecture document having Informational status) Or is that putting too much burden on the AD? I know this is a substantive comment late in the process, so feel free to disregard. -Tom From nobody Tue Nov 29 15:34:45 2016 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 6FC1E129527; Tue, 29 Nov 2016 15:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 C871tcMijv8h; Tue, 29 Nov 2016 15:34:37 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 B9DDA127A91; Tue, 29 Nov 2016 15:34:17 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id p16so171666790qta.0; Tue, 29 Nov 2016 15:34:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=M3VbUpr55j8PxAxDSAEORxnrrVX4JD8/r6j4sCQXcLQ=; b=0BHurrezTqvwSFNTuOg4ivqQTSlPyrk8UgJ16fzlgLDuFuuxblbpFTJ4KUdpkUwQ6V hMHt9T+qYQ7wAUPu5wjSPDxgZCX/LOKT/17VX2sr1cjyvyucM78TUj88cqTziyujL0cR 0nYzEa8gI4xT2p1WQt5hn1VfR9Zc8gpP/ltAiC5cTZa6smm/qg7KZcl2pEwG93zH/8TP +Gc5Nh47laZr1jeHdpB+qPRpyIbhb88kvMDMNGiojnOVvpbDzD+NJ3NRwTN3SBtM2LdP E4Tcz+/8LGtBfvX4F3fv52TP1G7oMftr6CDyXMFIAxEbRyHaRJ6fzjjIMIBPjsHHvPgj e5bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=M3VbUpr55j8PxAxDSAEORxnrrVX4JD8/r6j4sCQXcLQ=; b=Tbbxg7fqQGgQUBQh5YMZJx3gek1+ZqzE2ddV+VyA0q+m6KuhWbC1pwcw1uwGhixolQ yiOUQLg0zJYegb+2gObX6hPZ6uMa2TDCp3GwIlIMepG5jEcttuXTn4ld1XZ3SWC8uKKE D+AeLhCwJ0WHo18ixz5T9zXWfBMu3fme1V9ZkddOel1EbXr2d+h2H1EHBDOaoErLGXXp eKXAM8b9MeWDReW4HtVLb3Uz1iC7swTjGGd4Jggf4NPq2QvDUW9R/p8R62ktqICgMBlV 9St/1cat5ig2+t4I8IX9crJZXW+ogYshxMepKaQE7xuF/PxRWTHExzxExPAGpNDy5WZV n9cA== X-Gm-Message-State: AKaTC00BXG/wtTkHXk1vqnD0mzJWsVfxE9va1mvorMQPHE28XHkMCRS/CvweQhcm6u6Zn433Xl45A78vSO3m5A== X-Received: by 10.237.62.169 with SMTP id n38mr26556149qtf.177.1480462456926; Tue, 29 Nov 2016 15:34:16 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.140.41.177 with HTTP; Tue, 29 Nov 2016 15:34:16 -0800 (PST) In-Reply-To: References: From: Barry Leiba Date: Tue, 29 Nov 2016 18:34:16 -0500 X-Google-Sender-Auth: xXZr09bPYzb-2qIvlzlDGjZ5MZQ Message-ID: To: Tom Yu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-leiba-3967upd-downref.all@ietf.org, IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-leiba-3967upd-downref-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 23:34:38 -0000 Hi, Tom, and thanks for the review. > The Security Considerations changes added in -01 seem good. Great; thanks for the check. > Comment: Could the responsible AD annotate each "safe" normative downref > (doesn't require community review), along with the rationale? (e.g., > foundational or architecture document having Informational status) Or is > that putting too much burden on the AD? I know this is a substantive > comment late in the process, so feel free to disregard. I'm happy to put text in for that, if the IESG thinks it's a good idea. I'll let them discuss it and Ben can let me know. Barry From nobody Tue Nov 29 15:41:50 2016 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 8D503129CA8; Tue, 29 Nov 2016 15:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 Or4EmQDwHZax; Tue, 29 Nov 2016 15:41:40 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CE877129BBE; Tue, 29 Nov 2016 15:41:40 -0800 (PST) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uATNfcLe083833 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 29 Nov 2016 17:41:39 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Barry Leiba" Date: Tue, 29 Nov 2016 17:41:38 -0600 Message-ID: <35EBCEB4-AE98-4CAE-A4B2-B772267C0EC1@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: draft-leiba-3967upd-downref.all@ietf.org, IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-leiba-3967upd-downref-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 23:41:43 -0000 Thanks for the review and response. Please see below: On 29 Nov 2016, at 17:34, Barry Leiba wrote: > Hi, Tom, and thanks for the review. > >> The Security Considerations changes added in -01 seem good. > > Great; thanks for the check. > >> Comment: Could the responsible AD annotate each "safe" normative >> downref >> (doesn't require community review), along with the rationale? (e.g., >> foundational or architecture document having Informational status) Or >> is >> that putting too much burden on the AD? I know this is a substantive >> comment late in the process, so feel free to disregard. > > I'm happy to put text in for that, if the IESG thinks it's a good > idea. I'll let them discuss it and Ben can let me know. My kneejerk response is that the relaxation of process in this draft is not about saying a downref is "safe" in general, just that the specific circumstances do not justify repeating the LC. I would expect the responsible AD to mention that (and the reasoning) to the IESG and give them a chance to object, If that's not clear for the draft we should add some words about it. OTOH, if we are talking about whether the downref might be safe for subsequent drafts, we have the downref registry for that purpose. I think the registry solves different problem and somewhat orthogonal problem. Thanks! Ben. From nobody Tue Nov 29 16:29:14 2016 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 0E56C129509 for ; Tue, 29 Nov 2016 16:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2S-3ussgUWUA for ; Tue, 29 Nov 2016 16:29:13 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 8AF97129D03 for ; Tue, 29 Nov 2016 16:28:53 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cBslX-0004AI-K8 for secdir@ietf.org; Wed, 30 Nov 2016 01:28:52 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cBslV-0000Vl-1R for secdir@ietf.org; Tue, 29 Nov 2016 19:28:50 -0500 Received: (qmail 24781 invoked from network); 30 Nov 2016 00:28:43 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Nov 2016 00:28:43 -0000 From: "Christian Huitema" To: "'Taylor, Rick \(External\)'" , "'Paul Hoffman'" References: <30706_1479279750_582C0485_30706_8297_7_C7F1D029-C067-4AF6-9F40-436F7BA54311@vpnc.org> <0AE7C2DE-B316-4675-B7BE-EB9AC50ED955@vpnc.org> <4035_1480388659_583CF032_4035_1030_1_003b01d249ed$3f003260$bd009720$@huitema.net> In-Reply-To: Date: Tue, 29 Nov 2016 14:28:38 -1000 Message-ID: <033801d24aa0$b34f09d0$19ed1d70$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJO58gflm7yviVf6/Cfvo0tY/H6ngJp8YIyAbfck2kBjD7axAMpmdv2n7CtZdA= Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dHEJL963yvZzofOAehTafloeD9ey9972JZ1Xcr1RWHu8UvfgoE7Tx8PYIcekOty5V3Vn Qqb7YZk4tcfqG9LHSqQVYkZQj3sVWNPd6Zqvf7YgUV8ShebT8U8Xw9HTDfreWQUhw0NOE6GJ4h1S yx3SVxxTMqX0PJmjOEykuntPB0mTf015vFX3Mr/p2bub/7pcobsBNjjE5Aa2bYPF/Ljub7D1nvJs XtU2nZ7nPOLF/Wn1ZymEi4ZQojpeZ03k33R0rsoAtgTaADGmLikT3swaYT40dKFOE3BfZETw255u BppYPVOv5BtNTjcagkYTbQLRBa8CWlWJ/Z52Y2lK4wxs0NlmM8dmYMoX9zl4nXWYGnFn3yzO1sNI xVAhudRU4os+nEeuHaHQ+7nQfs3MfDo0rdXACQIHPYrCd4PY+G/nx7QL+MTObVKxHy/dols381l9 ryOIyTwXkV5v9rYnjJeS/R+I6BZ65nwq5J5jOi1sCFUVVgW9/bktU41htiJ8fk7NkHtzJzDXtW19 p+oSJq/sPNS7pOEbN+JMueFd2wBL5ko+03rd0MueqeqFzadSbJ8EWv48M3dEN/L6l2KS1xSjSzJ8 mVtlmHTW6t+XF13aDiVUE2hrO9QGiyz48bSlEFaPeA== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.230 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.07) X-Classification: not-spam/combined X-Recommended-Action: accept Archived-At: Cc: draft-ietf-manet-dlep.all@ietf.org, 'secdir' Subject: Re: [secdir] SecDir review of draft-ietf-manet-dlep X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 00:29:14 -0000 On Tuesday, November 29, 2016 2:09 AM, Rick Taylor wrote: >> This layer 2 security model is effectively an implementation of "perimeter >> security", and has all the known issues with perimeter security. Two classic >> attacks are "finding a way to send packets through the perimeter" and >> "subvert a node already installed inside the perimeter". The draft attempts >> to mitigate the first class of attacks by using the mechanism of RFC 5082, >> although it does not actually use it correctly. There is no mitigation for the >> "subverted node" attack. > > There has been extensive discussion within the WG on this topic, and we do > fully understand the concerns. The security of DLEP has always been a major > worry for the authors/WG as we are being pulled in two directions: The sticking > point is the situation where an implementer has the modem and router as two > separate modules in a single chassis (or secured perimeter), and wants to avoid > the perceived complexity/annoyance of implementing TLS. The authors have > received off-the-record comment from major radio vendors stating that they will > not adopt DLEP if it requires TLS. However, I agree that both your comments are > absolutely valid. The question is how to reconcile the difference? There may be different deployment scenarios. As is, I would not recommend deploying DLEP if the Lan provides access to anything else than the router and the modem. For the other scenarios, you really want to use something like TLS with appropriate credentials. > We are searching for some mechanism that would allow the protocol to: > > a) Specify how to secure the session correctly. > b) Secure the session by default. > c) Allow either peer to waive the requirement for security in a way that cannot be maliciously > downgraded. > > Is a STARTTLS style approach acceptable? Or is an http/https style two port approach > preferred? I'm not asking for the solution, but trying to avoid wasting your and our time. Of course, I have no idea of the operational constraints, but at a high level you seem to have the same problem as various small appliances and devices. My gut feeling is that the same solutions apply, e.g., a one time "pairing" to establish trust between router and modem, and then using TLS and verifying the appropriate credentials, e.g., some shared secret. You could make that optional when the perimeter is really tightly controlled. >> >> One area we have worked hard on addressing is mandating use of >> >> RFC5082 (Generalized TTL Security) on the link between router and >> >> modem (See Section 3.1). >> >> Not quite. RFC5082 suggests setting the TTL to 255 and checking the value on >> the received message. Your draft suggests setting the TTL value to 1, and >> checking the received value in the message. You need to fix that. > > TTL 1 is required for the discovery mechanism (UDP mcast) in an attempt to restrict > packets to a single hop (particularly for IPv4), but the TCP connection for the session > must use TTL 255 as per RFC5082 (The paragraph above). We might consider re-ordering > the paragraphs if you think it is unclear. TTL 255 prevents nodes from receiving packets from outside the LAN, TTL 1 prevents nodes from leaking packets outside the LAN. An attacker can format an UDP packet with a TTL just right, so that it arrives on the LAN with TTL=1. At a minimum, this allows the attacker to trigger multicast UDP replies, i.e., a form of DOS attack. Lucky attackers might be able to send a complex packet and trigger a code fault. That's why "prevent packets from the outside in" is generally better than "prevent packets from the inside out" -- multicast routing normally stops transmission outside the LAN anyhow. If you decide to stick to TTL=1 for UDP, then you should definitely make the text explicit, explain the difference of treatment between TCP and UDP. -- Christian Huitema From nobody Tue Nov 29 17:03:39 2016 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 EAD5F12941A for ; Tue, 29 Nov 2016 17:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 zZOwdlbEi339 for ; Tue, 29 Nov 2016 17:03:35 -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 13F21129D0C for ; Tue, 29 Nov 2016 17:03:22 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cBtIt-0003bT-TJ for secdir@ietf.org; Wed, 30 Nov 2016 02:03:20 +0100 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cBtIr-0006DC-C7 for secdir@ietf.org; Tue, 29 Nov 2016 20:03:17 -0500 Received: (qmail 662 invoked from network); 30 Nov 2016 01:03:17 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Nov 2016 01:03:16 -0000 From: "Christian Huitema" To: , "'secdir'" , Date: Tue, 29 Nov 2016 15:03:12 -1000 Message-ID: <035101d24aa5$87287300$95795900$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJKpBiZ2i1wodttR3CdZxRYQEPXKw== Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dHEJL963yvZzofOAehTafloeD9ey9972JZ1Xcr1RWHu8UvfgoE7Tx8PYIcekOty5V5Yy GF7ppvWPs4IUxZvGtOKnYxvXMUpDbClWGLuWnsW5UV8ShebT8U8Xw9HTDfreWQUhw0NOE6GJ4h1S yx3SVxxES/UXWeXchaxUcVp6EfPff015vFX3Mr/p2bub/7pcobsBNjjE5Aa2bYPF/Ljub7D1nvJs XtU2nZ7nPOLF/Wn1ZymEi4ZQojpeZ03k33R0rrlRgbSdQ7Ctt1HC2HYSOeg0dKFOE3BfZETw255u BppYPVOv5BtNTjcagkYTbQLRBfR+A3nLS2qp+5C5LWaPZatmM8dmYMoX9zl4nXWYGnFn3yzO1sNI xVAhudRU4os+nEeuHaHQ+7nQfs3MfDo0rdXACQIHPYrCd4PY+G/nx7QL+MTObVKxHy/dols381l9 ryOIyTwXkV5v9rYnjJeS/R+CQ4YEstQl1QGd8iYxHIFeVgW9/bktU41htiJ8fk7NkHtzJzDXtW19 p+oSJq/sPNR92sVsNv4/n68zqLHQfaIpy1XdlBp3PLPSE+dwQJstApGq6yQd+esc4yzV58Z0KZK+ mEgE0Sm9Tddig0b84xPm9jihx+Za/cV70jOJzN2r4A== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.232 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.34) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: Subject: [secdir] SecDir review of draft-ietf-manet-credit-window-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 01:03:37 -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. I think the document is ready, but its security considerations depend on those of draft-ietf-manet-dlep-25, which are discussed in another thread. Draft-ietf-manet-credit-window-07 defines "Credit Windowing extension for DLEP". The Dynamic Link Exchange Protocol (DLEP) is defined in draft-ietf-manet-dlep-25. DLEP is meant to operate over a single link. It consists of an ad hoc discovery protocol over multicast UDP in which a router discovers a modem, followed by a TCP connection over which router and modem exchange control messages. DLEP operates in the control plane, independent of the data plane used for actual data transmission. The current draft, draft-ietf-manet-credit-window-07, defines a set of messages exchanged over DLEP to manage a credit window, so as to control the flow of packets in the data plane between the router and destinations accessible through the wireless modem. The goal is to track the variable capacity of the wireless link to different destinations without requiring complex queue management at the modem itself -- I assume that the queues will be managed by the router instead. The security section states that "The extension does not introduce any additional threats above those documented in [DLEP]." That's true. There is an ongoing debate about the security of DLEP itself, but there is noting that this extension could do about it. -- Christian Huitema From nobody Wed Nov 30 06:27:21 2016 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 D01D712958C; Wed, 30 Nov 2016 06:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1480515008; bh=pvN0guFOodoAe4XyrWyi2hhSfzHywPbzweN+c0PClXQ=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=rhaOSevlolaeUCR9cNyLt9Zij2qpFyyOqJzeRgfIGbV38gYFR+BOSoh+XhGteY2kM AIkJ4BRNJshVAXRX+gi2Rw4lWOb5Vc+rNk8QQwRczThevJ+2yFcUG+on0YAnwCNQeh O0C8rhhW5AP27uBjYF2xaqQ6QaepwipDuzkAMJ8w= 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 AF24E12953C for ; Wed, 30 Nov 2016 06:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 SRjPkodyv9eC for ; Wed, 30 Nov 2016 06:10:05 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210B912958C for ; Wed, 30 Nov 2016 06:10:05 -0800 (PST) Received: from [61.148.242.21] (helo=[172.20.10.2]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1cC5aE-0002RO-W4 for new-work@ietf.org; Wed, 30 Nov 2016 14:10:03 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: <4db0fc37-d417-dfca-e83f-557d9cd20e05@w3.org> Date: Wed, 30 Nov 2016 22:11:08 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 30 Nov 2016 06:27:20 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Security Interest Group (until 2017-01-06) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 14:10:09 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Web Security Interest Group: https://w3c.github.io/charter-drafts/websec-ig.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2017-01-06 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Wendy Seltzer and Samuel Weiler . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Nov 30 16:25:08 2016 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 B3CD5129519; Wed, 30 Nov 2016 16:25:06 -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, HTML_MESSAGE=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 WYftDfMoEQ0O; Wed, 30 Nov 2016 16:25:05 -0800 (PST) Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (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 2339C1295E3; Wed, 30 Nov 2016 16:25:01 -0800 (PST) Received: by mail-yw0-x243.google.com with SMTP id r204so16309761ywb.3; Wed, 30 Nov 2016 16:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version; bh=EXS+cqN1Ty6/5JB/1qXrcYt1qDbEcSTpt27rb45aWXM=; b=Occ+9gIAJ2GzHiaPy6aWcRHlcWLD4SOOngSfdD6orLzh2JU0Oso3drfHSZV7q/oU12 WcnIPw+9uhIV7XkIrEfcDzmuhVykPOewCmCtcpamKisUFYGC/4mdWc0LTm0d9T1Cln85 suKcY8nU/TnILd2lpLVAWd0cEJr2N5AbXXBdAB2VrSES6aSWb7jdYIyopyf99+vu2PRP gNMmefzdBv2KoaSPMaJxY4La6kKcKnsysWy680Gyy4ud/OEasyiv/4l706EQORpmHdH8 Snpp3nD53Q5hKPk6kYz59T2/Z4xbY1KD2onzndZ2PuFR3mJgSbuwk63wv7LFew/MD16m e2oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=EXS+cqN1Ty6/5JB/1qXrcYt1qDbEcSTpt27rb45aWXM=; b=LeF0amTVJBuoqZcPeK3D98k8biod+oPvWHEtOuTWnkbE1qZleIrV55ICV+KL7AcWa3 LW7ZEtz8UT+kgQYPHEfqdm2EUSn9Z+f88DJHLRN37dNY9TqNCIknOGtBEmYa2VsJAydl CaiBV8r6QKywuMIB+OH+6uVuq+0sUA3pP+iSjQ01eHUsuh6aPPBGWKBPHrUVxdT82G9o Ra/+CVnfkaFnu/NZZLzQ8HZEPsEOw+QG7xu+mL8/jJC8QFSMTowresXkcdTx2T11JrnX PMlT8ORxlGrQ5Mve6G/eYifYVhpmKiXwHkSWM2TyjB/N/mrL+c/MIVXdwPAEIoUNLRJO +yUw== X-Gm-Message-State: AKaTC00zw6HCPDWNMtQ62f6zFWh1HreuJKthS8/fiqynPMHYaz3l5yV/oxbdr5NH9r1J6Q== X-Received: by 10.157.46.135 with SMTP id w7mr19076454ota.64.1480551900219; Wed, 30 Nov 2016 16:25:00 -0800 (PST) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:6963:9af5:8af2:1777]) by smtp.googlemail.com with ESMTPSA id l6sm10841707oia.22.2016.11.30.16.24.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Nov 2016 16:24:59 -0800 (PST) To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-pals-endpoint-fast-protection.all@ietf.org From: Chris Lonvick Message-ID: <583F6DDB.1070300@gmail.com> Date: Wed, 30 Nov 2016 18:24:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000804070406030709050807" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-pals-endpoint-fast-protection-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 00:25:06 -0000 This is a multi-part message in MIME format. --------------000804070406030709050807 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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. I'm not familiar with this technology but the specification appears to address the security concerns. I like that the relevant RFCs for the base and associated protocols are each listed in the Security Considerations section. The document appears well written and I found no nits in my albeit brief review. Best regards, Chris --------------000804070406030709050807 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 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.

I'm not familiar with this technology but the specification appears to address the security concerns. I like that the relevant RFCs for the base and associated protocols are each listed in the Security Considerations section.

The document appears well written and I found no nits in my albeit brief review.

Best regards,
Chris
--------------000804070406030709050807-- From nobody Wed Nov 30 18:03:19 2016 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 B7DEF129BAC; Wed, 30 Nov 2016 18:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_LOW=-0.7, 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 5sW0oIwKsQ9N; Wed, 30 Nov 2016 18:03:11 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 AD38D129B10; Wed, 30 Nov 2016 18:03:11 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id m5so250748093ioe.3; Wed, 30 Nov 2016 18:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=GbCbKFRhnMOEDZgYRFD2ngF/tMlpdSx15gHwpRVHPRg=; b=QlVKltcMvwxjJ85eWB/lEagKa+fXVF0RoSnBNMecE3jSTI7tYrgeG4DHtvyCJIxGxK hAK0mAKKILJpD9E+VK7YwHvou0xEjSCkgaPMb47vHUr77Mv9C8BAWQ2KdsT52b+qXKuW X/vGYgwAIKcpcsKuiaO2DCmIRxNSSqdqJq6ddvaV+VMsLOcU8k7qXQtPetrbMeZ0ZOeC id7iy/2QSz3CKddKyILrjTfw6p9Xar5GyVNlN30wqynTDoPaKUIGsA93h/V1pm9GjgwS 17/joOvPd+GoRalufBOXL60CYtPRDIYF0L1oLeUdQ6p+Fy0PKJ49YzuXKX5onJ4LrwOT aNWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=GbCbKFRhnMOEDZgYRFD2ngF/tMlpdSx15gHwpRVHPRg=; b=BVjNWsjHle1P3yp+oP8JhaNei9r6CEbSJnhNIBOat2mbUmGDvMR+WLRKA2tFdoK18i sIrkxnkK7lmxCsJY4D2cRXsxP1lwQhz85FEzm6Fq3WtORnHkdiGJML/DM4JWP0kYQpbL vHzg67wKANQJrFd3+HXlVMsAOgmFMJ6dt9YKO7o4NZ2TYc8wbYouxKa7zQSLUiBt8SuY NnlHAFmvW9tcbOeuuoVG91+iGASccaRbuyMGoQc/e8QCyoDcJSIYHOoc5IU02K20sTd9 8qeN0yi94sRqC/KiWlZDLFMkCnAKJNN6Q78QV2XpBha7pEhbTKLzm3JT+TVQ1Mbd7YUX PYdQ== X-Gm-Message-State: AKaTC02uCP4G2iUnMM/MfBGMyOKP5+S+P7qZ2aG3W/CdEYs6f94hg+fr2V7OcpCq6oWqomvT/YW2RGZZ9c0gvQ== X-Received: by 10.107.34.207 with SMTP id i198mr28527224ioi.16.1480557791014; Wed, 30 Nov 2016 18:03:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.33.6 with HTTP; Wed, 30 Nov 2016 18:02:55 -0800 (PST) From: Donald Eastlake Date: Wed, 30 Nov 2016 21:02:55 -0500 Message-ID: To: "iesg@ietf.org" , draft-ietf-appsawg-mdn-3798bis.all@ietf.org Content-Type: multipart/alternative; boundary=001a11403e24340c5205428f3989 Archived-At: Cc: "secdir@ietf.org" Subject: [secdir] draft-ietf-appsawg-mdn-3798bis-15 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 02:03:14 -0000 --001a11403e24340c5205428f3989 Content-Type: text/plain; charset=UTF-8 My apologies for getting this in late. 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. This draft appears to be ready for publication with some nits.. This draft polishes and advances to Internet Standard level RFC 3798 on Message Disposition Notifications. *Security Considerations:* The Security Considerations seem good except for one minor point: in my opinion the option to return all or a portion of the original message significantly increases the possible risk of use MDNs as a traffic multiplier. I believe this should be mentioned in Section 6.4. *Miscellaneous:* The style of this draft is to say that you MUST do this and MUST NOT do that without indicating what action should be taken if this is violated. This is like saying a protocol field "MUST be zero" without adding the usual "and is ignored on receipt". For example, in Section 3 it says that a message disposition notification MUST NOT itself request an MDN. I believe it should go on and add the few words to say: "If one does, this is ignored." (unless that's wrong...) I'm not saying this must always be done but there may be 1 or 2 other cases like this in the draft where such wording should be added. *Wording:* In Section 3, the wording of the last sentence of point d seems just a bit obscure. It says However, in the case of encrypted messages requesting MDNs, encrypted message text MUST be returned, if it is returned at all, only in its original encrypted form. I think it would be a just bit clearer as However, in the case of encrypted messages requesting MDNs, if the original message or a portion thereof is returned, it MUST be in its original encrypted form. *Trivia:* I do wonder if the references to X.400 mail are necessary. They seem archaic. Does anyone run X.400 email any more? It is just used as an example, along with proprietary mail systems. I think such proprietary systems still exist, but X.400 mail? I'm not so sure. If it is going to be retained, maybe there should be an Informational reference for it. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --001a11403e24340c5205428f3989 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My apologies for getting this in late. I have reviewe= d this document as part of the security directorate's ongoing effort to= review all IETF documents being processed by the IESG. Document editors an= d WG chairs should treat these comments just like any other last call comme= nts.

This draft appears to be ready for publicatio= n with some nits..

This draft polishes and advance= s to Internet Standard level RFC 3798 on Message Disposition Notifications.=

Security Considerations:

The Security Considerations seem good except for one minor point: i= n my opinion the option to return all or a portion of the original message = significantly increases the possible risk of use MDNs as a traffic multipli= er. I believe this should be mentioned in Section 6.4.

=
Miscellaneous:

The style of this draft= is to say that you MUST do this and MUST NOT do that without indicating wh= at action should be taken if this is violated. This is like saying a protoc= ol field "MUST be zero" without adding the usual "and is ign= ored on receipt". For example, in Section 3 it says that a message dis= position notification MUST NOT itself request an MDN. I believe it should g= o on and add the few words to say: "If one does, this is ignored."= ; (unless that's wrong...) I'm not saying this must always be done = but there may be 1 or 2 other cases like this in the draft where such wordi= ng should be added.

Wording:

=
In Section 3, the wording of the last sentence of point d seems = just a bit obscure. It says
   =
    However, in the case of encrypted messages requesting MDNs,
       encrypted message text MUST be returned, if it is returned at
       all, only in its original encrypted form.
I think it= would be a just bit clearer as
       However, in the case of encrypted messages requesting MDNs, if
       the original message or a portion=
 thereof is returned, it MUST
      =
 be in its original encrypted form.

Trivi= a:

I do wonder if the references to X.400 mail= are necessary. They seem archaic. Does anyone run X.400 email any more? It= is just used as an example, along with proprietary mail systems. I think s= uch proprietary systems still exist, but X.400 mail? I'm not so sure. I= f it is going to be retained, maybe there should be an Informational refere= nce for 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= -508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
= =C2=A0d3e3e3@gmail.co= m
--001a11403e24340c5205428f3989-- From nobody Wed Nov 30 18:49:43 2016 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 AC62E129693; Wed, 30 Nov 2016 18:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, 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 fddBEjfb_asJ; Wed, 30 Nov 2016 18:49:41 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.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 A94681294B2; Wed, 30 Nov 2016 18:49:40 -0800 (PST) X-AuditID: 12074423-18fff7000000365f-de-583f8fc2ee34 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 51.1F.13919.2CF8F385; Wed, 30 Nov 2016 21:49:39 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id uB12nc4J005406; Wed, 30 Nov 2016 21:49:38 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uB12nYDM025649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Nov 2016 21:49:37 -0500 Date: Wed, 30 Nov 2016 20:49:34 -0600 From: Benjamin Kaduk To: draft-ietf-6lo-privacy-considerations.all@ietf.org, iesg@ietf.org, secdir@ietf.org Message-ID: <20161201024934.GP8460@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsUixCmqrHu43z7C4MZObYt503uYLGb8mchs 8WHhQxYHZo8lS34yBTBGcdmkpOZklqUW6dslcGX0Tp7IXnBAvGLBrjcsDYyThbsYOTgkBEwk 9q/y7mLk4hASaGOSODl9HzuEs5FR4tmD+SwQzlUmiW19y4EynBwsAqoSU3acZgSx2QRUJBq6 LzOD2CIC8RJzz19kA5kqLOAk8W0/E4jJK2AsMbchAaSCV0BQ4uTMJywgNrOAlsSNfy/BSpgF pCWW/+MACYsKKEs0zHjAPIGRdxaSjllIOmYhdCxgZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qk a6aXm1mil5pSuokRFFjsLso7GF/2eR9iFOBgVOLh3XHXLkKINbGsuDL3EKMkB5OSKG9ZiX2E EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFeM2A4C/GmJFZWpRblw6SkOViUxHn/u30NFxJITyxJ zU5NLUgtgsnKcHAoSfCu6gNqFCxKTU+tSMvMKUFIM3FwggznARpeAlLDW1yQmFucmQ6RP8Wo KCXOu7YXKCEAksgozYPrBUW+RPb+mleM4kCvCPOmgLTzAJMGXPcroMFMQIPfvrYGGVySiJCS amCMuuayuNJYe037WWdP/c3H14RWcqxoFtverBkmumN3BMffC+vZkn5579h9UkV2rdyBpkCO mbvs0tzf5fyxrA+fKVPCOLFG9vrE2rfWy3KurxRQONyiVd74fcop3bOHNr4X2PpUcOU8mSPH XRbdLfsBNCfPcr648u7CzEOiMj3lVbqlX8XaBZRYijMSDbWYi4oTAbx6a4fXAgAA Archived-At: Subject: [secdir] secdir review of draft-ietf-6lo-privacy-considerations-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 02:49:43 -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. This document is ready with nits. This document is something of a meta-document, accumulating pointers to other documents that cover privacy considerations regarding IPv6 addresses, and using them to give guidance for future documents that specify how to run IPv6 over [insert protocol here]. It's worth having that advice consolidated in one place with math giving guidance on actual amounts of entropy to have in addresses; thank you! The security considerations section (correctly) notes that the whole document is about security/privacy. I just had a few questions after reading the document: In section 1, second paragraph, the claim is made that "when interface identifiers are generated without sufficient entropy compared to the link lifetime, devices and users can become vulnerable to various threats". Is it always the *link* lifetime that is most relevant in this context, or are there other lifetimes that can come into play as well? It seems that there are other lifetimes, at least for certain IID-generation schemes, which is covered later in the document, but may give cause for reconsidering word choice here. In section 2 (bottom of page 3), the claim is made that ICMP unreachable errors are typically rate limited to 2/second. Is there hardware that has no limit, or a much higher limit? (That is, what is the shape of the distribution?) If there is a risk of a device being on a network where the rate limit is much higher, that device may need to adjust its scheme for generating addresses. Similarly, near the end of section 2, there is discussion of 46-bit threshold and cases where it may not apply; it's not clear to me when spoofing is possible (or if a device might in general even know whether spoofing is possible), so perhaps the 46-bit claim should be de-emphasized. Unfortunately, the last paragraph of the section just says "more bits of entropy would be needed" for the case when 46 bits are not enough, which is not exactly clear guidance. (I have no better alternative suggestion, though.) In section 4, there is a claim that when a short address is "allocated by the network (rather than being constant in the node)", a short address is (unequivocally?) safe. Is this supposed to be because a new address is generated each time a device connects to the network, so it is supposed to not be linkable? (I am not sure I believe the claim from just the given discussion in the document.) Editorial quibbles: Top of page 4, is "actual" really needed in "actual math"? End of section 2, maybe "more entropy would be needed" rather than "more bits of entropy would be needed"? Thanks, Ben From nobody Wed Nov 30 19:31:16 2016 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 136AA12950F; Wed, 30 Nov 2016 19:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 Q8G10iSYElFr; Wed, 30 Nov 2016 19:31:08 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 C63B81295EF; Wed, 30 Nov 2016 19:30:54 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id j65so393412009iof.0; Wed, 30 Nov 2016 19:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sFC+yJZQfOqn4LSXKjSFL2ciNhephrwv5/ig02Eyr+E=; b=tFz/AgaSmEcpSPzxz0hDaK0a7WL8wW8Sz4N3A7xZvltFxzyyFFxgGHdjgicCWhQX6b WV+25u4cX3sgKtMYLYgKfHkF44ii3jSyBZjPvdkugIWPLQ8OHQzF0hcjG+Lo24lWDEbu cKHKqSTawifDQ3xEpHlrMjkxh3VJAiipL3iDn9VZSVK48thH0LLGWnrPS23H2IIkkASv xL+5FAXtRDvwuP/J4uPa1n+MZqoSNKGtGd3J/GwNaELPJ7rPR4hvUDwQLQK10v2gmHoI 17qPmhOo1fU4OK8mP9O6Jol0JPqf0aZwsSjt9uOuSc0Yl29RqgkziHXY7WNX+d4C9U5Z vCGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sFC+yJZQfOqn4LSXKjSFL2ciNhephrwv5/ig02Eyr+E=; b=VrHXQaYc5hX/LkL0Q3ub9/Lo22jfQO/VAzDwf0sdyuRmpf4l0rooxWfEeozWcNdwqR BSgQe/yb92+NUd3JjHo873bsZ3EjONEEvHAd3UkusoEj2mfv8yoT3V2kbvUmvg9NW1QM evoonVaAiJYfdCE7zp12GMvIhkJsG/TLuysicQ6JPptMW/Ohk+irgW69hkjKj/H85yT5 ur9Z6xI7K5b62n/ImXQtWgehmcyAddxlG0oJwXTEJIBfiwtrAQ/4aCDcBl9Qjmi5rAWH IjgUS5P5+8R0m1g+fOCmiVF20H2T4VDCfTH0r8XRYKBLWUTTxt71gMXQ6t5aD6CfAhsL Y7jw== X-Gm-Message-State: AKaTC01cjAumKTImq8sHho5q2rVnXUpI40ZXdnox+V1sVnFvvnx0t7QzqMxPBhU9LNvz0sDi3gp6HBWT5sR+9g== X-Received: by 10.202.196.150 with SMTP id u144mr19672114oif.190.1480563054103; Wed, 30 Nov 2016 19:30:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.236.37 with HTTP; Wed, 30 Nov 2016 19:30:33 -0800 (PST) In-Reply-To: <583F6DDB.1070300@gmail.com> References: <583F6DDB.1070300@gmail.com> From: "Andrew G. Malis" Date: Wed, 30 Nov 2016 22:30:33 -0500 Message-ID: To: Chris Lonvick Content-Type: multipart/alternative; boundary=001a113e4ad2e8565b0542907265 Archived-At: Cc: draft-ietf-pals-endpoint-fast-protection.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-endpoint-fast-protection-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 03:31:10 -0000 --001a113e4ad2e8565b0542907265 Content-Type: text/plain; charset=UTF-8 Chris, Thanks for your review! Cheers, Andy (PALS co-chair) On Wed, Nov 30, 2016 at 7:24 PM, Chris Lonvick wrote: > 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. > > I'm not familiar with this technology but the specification appears to > address the security concerns. I like that the relevant RFCs for the base > and associated protocols are each listed in the Security Considerations > section. > > The document appears well written and I found no nits in my albeit brief > review. > > Best regards, > Chris > --001a113e4ad2e8565b0542907265 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Chris,

Thanks for your review!

Cheers,
Andy
(PALS co-chair)


= On Wed, Nov 30, 2016 at 7:24 PM, Chris Lonvick <lonvick.ietf@gmail.co= m> wrote:
=20 =20 =20
Hi,

=20 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.

I'm not familiar with this technology but the specification appears to address the security concerns. I like that the relevant RFCs for the base and associated protocols are each listed in the Security Considerations section.

The document appears well written and I found no nits in my albeit brief review.

Best regards,
Chris

--001a113e4ad2e8565b0542907265--