From nobody Mon Feb 1 18:03:44 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C481A1DE1; Mon, 1 Feb 2016 18:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 eGTLFQTEqQeD; Mon, 1 Feb 2016 18:03:40 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 510B11A1DBE; Mon, 1 Feb 2016 18:03:39 -0800 (PST) X-AuditID: 12074422-ee7ff70000000a47-06-56b00e7afc32 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 90.8C.02631.A7E00B65; Mon, 1 Feb 2016 21:03:38 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u1223bvi006942; Mon, 1 Feb 2016 21:03:38 -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 u1223aEN025646; Mon, 1 Feb 2016 21:03:37 -0500 From: Tom Yu To: iesg@ietf.org, secdir@ietf.org, draft-ietf-netconf-yang-library.all@tools.ietf.org Date: Mon, 01 Feb 2016 21:03:35 -0500 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUixCmqrVvFtyHMoLVZ3uLB4RY2ixl/JjJb fFj4kMWB2WPJkp9MHl8uf2YLYIrisklJzcksSy3St0vgymi8+I+x4C1rxck5X5gbGF+ydDFy cEgImEhsn1DWxcjFISTQxiSx8/kKZghnA6PExrmb2CGc14wSt6ctZOti5ORgE5CWOH55FxOI LSIQL3Hi9F1GEFtYwEbi0K2/LCA2i4CqxK1OiHpeAV2JZfNusYPYPAKcErsnbWWHiAtKnJz5 BKyeWUBL4sa/l0wTGHlmIUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdULzezRC81 pXQTIyh02F2UdjD+PKh0iFGAg1GJh7dj7fowIdbEsuLK3EOMkhxMSqK8m/8DhfiS8lMqMxKL M+KLSnNSiw8xSnAwK4nwrnwPlONNSaysSi3Kh0lJc7AoifPu6pgbJiSQnliSmp2aWpBaBJOV 4eBQkuCdzbshTEiwKDU9tSItM6cEIc3EwQkynAdo+FKQGt7igsTc4sx0iPwpRl2OBT9ur2US YsnLz0uVEuddAlIkAFKUUZoHNwcc80KM+14xigO9JcxrA1LFA0wXcJNeAS1hAloymw/kg+KS RISUVANjpKvIdtfc9PjmqKXM6qtSPmhXRdgn3LQ/uJ5vz8xY+SNWBrq11zeaNzpufiP+fN0b +X37SufMPHcmbv8En/nsWlNmKKt5z4q28tZn+M86qf5SiuPlgjlHjNxOFyTN7Zcurl0jL8os v+jfh47tYs3JakXFytbnzRbPVwhWCu5L19W/4rW3jl+JpTgj0VCLuag4EQAQVhgj1AIAAA== Archived-At: Subject: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 02:03:42 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The Security Considerations of this document seem reasonable. It might be useful to add a comparison of the risks posed by sensitive information exposed by this YANG module with information exposed by other aspects of NETCONF, or available through methods such as fingerprinting. Admittedly, a meaningful comparison might be highly context-specific, so a general comparison might have limited utility. From nobody Tue Feb 2 08:58:09 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82DA1B2D09; Tue, 2 Feb 2016 08:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 DL6yfxLqfHDW; Tue, 2 Feb 2016 08:58:04 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D991B2D31; Tue, 2 Feb 2016 08:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=825; q=dns/txt; s=iport; t=1454432283; x=1455641883; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ngXJ9apCOyb77k2pgdnYoCm7/iE6XT81RcxMlQtoDhk=; b=G02kx5BuV8BEdFNKeR0L0SYmHQY58blohI3xpnr7HMZRkUDdpJnkVYgR EayooR86s+dCw1otynBYBxrehDGKS4jI9xiRplK/GQ7KyzLD/clObvGz1 FMcEIm9ilJHVSSanhNqzTGMqamNr0iZ4mpexgEGcnmP6RoU00qetZ94W5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgAl37BW/4YNJK1egzqBRYhTsWwBD?= =?us-ascii?q?YFkhg2BSDgUAQEBAQEBAYEKhEQEOj8SAT5CJwQBDYggvwYBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBARmHfIongQ8BBJZxAYERjDkHjmqOPgEeAQFCg2SJWXwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,385,1449532800"; d="scan'208";a="73106003" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2016 16:58:02 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u12Gw2KC017319 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 16:58:02 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 2 Feb 2016 11:58:01 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 2 Feb 2016 11:58:01 -0500 From: "Brian Weis (bew)" To: "secdir@ietf.org" , The IESG Thread-Topic: Secdir review of draft-ietf-isis-te-metric-extensions-09 Thread-Index: AQHRXdrgUblF4CPrDUSazDkgZah1mA== Date: Tue, 2 Feb 2016 16:58:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.165] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-isis-te-metric-extensions.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-ietf-isis-te-metric-extensions-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 16:58:05 -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 is a re-review of the draft. The previous review was version -07, wher= e I suggested adding some text to the Security Considerations noting that t= he sub-TLVs added in this document were especially at risk for tampering, s= o it would be valuable to explicitly point out the IS-IS authentication met= hod that would mitigate the risk. The current version of the draft includes= this text, and it looks good to me. I consider this draft Ready to publish. Brian = From nobody Tue Feb 2 16:43:29 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E043D1ACE8B for ; Tue, 2 Feb 2016 16:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 DyTq28KwoMPx for ; Tue, 2 Feb 2016 16:43:27 -0800 (PST) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECA51ACE88 for ; Tue, 2 Feb 2016 16:43:26 -0800 (PST) Received: from smtp9.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C31B4380537; Tue, 2 Feb 2016 19:43:25 -0500 (EST) Received: from app2.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B38F738050D; Tue, 2 Feb 2016 19:43:25 -0500 (EST) X-Sender-Id: scott@hyperthought.com Received: from app2.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.5.4); Tue, 02 Feb 2016 19:43:25 -0500 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app2.wa-webapps.iad3a (Postfix) with ESMTP id A1166280D91; Tue, 2 Feb 2016 19:43:25 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Tue, 2 Feb 2016 16:43:25 -0800 (PST) Date: Tue, 2 Feb 2016 16:43:25 -0800 (PST) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-netext-logical-interface-support.all@tools.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: <1454460205.658219841@apps.rackspace.com> X-Mailer: webmail/12.0.0-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-netext-logical-interface-support-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 00:43:28 -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=0AFrom the abstract, this Informational docu= ment explains the operational details of [sic] Logical-interface construct = and the specifics on how the link-layer implementations hide the physical i= nterfaces from the IP stack and from the network nodes on the attached acce= ss networks.=0A=0AThe brief security considerations section says the implem= entation on the host is not visible to the network and does not require any= special security considerations. One thing that occurred to me when I read= this is that if someone is depending on link layer security (e.g. 802.11i)= for any reason, then there may be security implications to switching the e= xit interface. Not sure if this is important - I'll leave it to the ADs to = decide.=0A=0A From nobody Thu Feb 4 03:14:01 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 1B08A1A1B15; Thu, 4 Feb 2016 00:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1454573192; bh=TPWfDIWj3RNbXS0WDB+XR+5Yi4h3QrNNoV7hNVuTm8s=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=AsPc7y22M2DcCChcYvzk3V4HFpfrK8nah6Oy3owPM9PPxv75M1zUg63l7XibEKmdz FaoeOtpJ+PM6OxAIVWjpU8/xsbewYcZvGzW7kjvQYY4SXUvpdUyWe8crxx+/oFZFVI 9yoqHNrN1paR5XlmouqWZxQQMHr9PyfykICXUYqs= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074461A1B07 for ; Thu, 4 Feb 2016 00:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 JpLdE0x9-icH for ; Thu, 4 Feb 2016 00:06:29 -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 552291A1B15 for ; Thu, 4 Feb 2016 00:06:14 -0800 (PST) Received: from [2a01:e35:8ad2:1c30:718b:57c5:4fb0:43c7] (helo=gillie.local) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aREvc-000ERf-O1 for new-work@ietf.org; Thu, 04 Feb 2016 08:06:12 +0000 To: new-work@ietf.org Date: Thu, 04 Feb 2016 09:06:11 +0100 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 04 Feb 2016 03:13:59 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Pointer Events Working Group (until 2016-03-04) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 08:06:32 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Pointer Events Working Group: https://www.w3.org/2016/02/pointer-events-2015.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-03-04 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 Doug Schepers, Team Contact . Thank you, Coralie Mercier, Head of W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Marketing & Communications - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Feb 4 03:14:02 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 EC68C1A1B27; Thu, 4 Feb 2016 00:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1454573600; bh=WsA11hChrhEIZbA6d4USvm3bkEr5goCdl6oIB6/BbL4=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=GkwYHvixrDDGsvfgrbkNDhjpDlwDc23nKRUZgi/7QDDYdc0P0kJwpPZFHttmWFXgk PHfX4SD204zhyY8fnvnzQ+1fw24DH73hdBUmOIcail4W13YiUeM+4gHi/kZk7EGN5f ozjVlT6Q07uSDoHug4IV1igozcSYJAjZbfrklkKI= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8387D1A1B29 for ; Thu, 4 Feb 2016 00:13:18 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 QdtmjhG1OUeV for ; Thu, 4 Feb 2016 00:13:17 -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 19CFD1A1B24 for ; Thu, 4 Feb 2016 00:13:17 -0800 (PST) Received: from [2a01:e35:8ad2:1c30:718b:57c5:4fb0:43c7] (helo=gillie.local) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aRF2R-000EXk-5k for new-work@ietf.org; Thu, 04 Feb 2016 08:13:15 +0000 To: new-work@ietf.org Date: Thu, 04 Feb 2016 09:13:14 +0100 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 04 Feb 2016 03:13:59 -0800 Subject: [secdir] [new-work] Proposed W3C Charters: Internationalization Working Group, Internationalization Interest Group, Internationalization Tag Set Interest Group (until 2016-03-04) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 08:13:20 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review draft charters for the Internationalization Working Group, the Internationalization Interest Group, and the Internationalization Tag Set Interest Group: https://www.w3.org/International/core/charter-2016.html https://www.w3.org/International/ig/charter-2016.html https://www.w3.org/International/its/ig/charter-2016.html As part of ensuring that the community is aware of proposed work at W3C, the draft charters are public during the Advisory Committee review period. W3C invites public comments through 2016-03-04 on the proposed charters. 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 Richard Ishida, Team Contact . Thank you, Coralie Mercier, Head of W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Marketing & Communications - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Feb 4 03:21:45 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D261ACEBA for ; Thu, 4 Feb 2016 03:21:44 -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 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 ZJllPq5u0Vnh for ; Thu, 4 Feb 2016 03:21:41 -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 CA82F1ACEBD for ; Thu, 4 Feb 2016 03:21:40 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u14BLac1020123 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 4 Feb 2016 13:21:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u14BLaxI019617; Thu, 4 Feb 2016 13:21:36 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22195.13375.945718.682221@fireball.acr.fi> Date: Thu, 4 Feb 2016 13:21:35 +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.15 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, 04 Feb 2016 11:21:44 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Matt Lepinski is next in the rotation. For telechat 2016-02-04 Reviewer LC end Draft Daniel Kahn Gillmor T 2016-02-04 draft-mahesh-mef-urn-02 For telechat 2016-02-18 Derek Atkins T 2016-01-18 draft-ietf-dnsop-edns-chain-query-06 Simon Josefsson TR2015-12-04 draft-ietf-eppext-tmch-smd-04 For telechat 2016-03-03 Charlie Kaufman T 2016-02-18 draft-sparks-genarea-mailarch-improvements-02 Last calls and special requests: Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Tobias Gondrom 2016-01-27 draft-ietf-codec-oggopus-12 Olafur Gudmundsson 2016-02-11 draft-holmberg-dispatch-pani-abnf-02 Phillip Hallam-Baker 2016-02-12 draft-ietf-behave-ipfix-nat-logging-06 Sam Hartman 2016-02-04 draft-ietf-dhc-dhcpv6-privacy-03 Jeffrey Hutzelman 2015-12-04 draft-ietf-core-block-18 Chris Inacio 2016-02-02 draft-ietf-v6ops-ipv6-ehs-in-real-world-02 Leif Johansson 2016-02-10 draft-ietf-dprive-edns0-padding-02 Benjamin Kaduk 2016-02-09 draft-ietf-tsvwg-circuit-breaker-11 Tero Kivinen 2016-02-16 draft-ietf-netmod-opstate-reqs-04 Warren Kumari 2016-02-15 draft-ietf-dhc-anonymity-profile-06 Watson Ladd 2016-02-11 draft-ietf-tram-stun-path-data-03 Ben Laurie 2016-02-16 draft-ietf-tsvwg-behave-requirements-update-06 Eric Osterweil 2016-01-05 draft-campbell-art-rfc5727-update-02 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-06 -- kivinen@iki.fi From nobody Thu Feb 4 11:28:49 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5361ACE10; Thu, 4 Feb 2016 11:28:48 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 j3JcL8GWoR9N; Thu, 4 Feb 2016 11:28:46 -0800 (PST) Received: from SNT004-OMC2S44.hotmail.com (snt004-omc2s44.hotmail.com [65.54.61.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10AC1ACE0F; Thu, 4 Feb 2016 11:28:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com ([65.55.90.71]) by SNT004-OMC2S44.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 4 Feb 2016 11:28:45 -0800 Received: from CY1PR17MB0425.namprd17.prod.outlook.com (10.163.253.19) by CY1PR17MB0426.namprd17.prod.outlook.com (10.163.253.20) with Microsoft SMTP Server (TLS) id 15.1.403.16; Thu, 4 Feb 2016 19:28:44 +0000 Received: from CY1PR17MB0425.namprd17.prod.outlook.com ([10.163.253.19]) by CY1PR17MB0425.namprd17.prod.outlook.com ([10.163.253.19]) with mapi id 15.01.0403.016; Thu, 4 Feb 2016 19:28:44 +0000 From: Charlie Kaufman To: 'secdir' Thread-Topic: Secdir review of draft-sparks-genarea-mailarch-improvements-02 Thread-Index: AdFff96UBzjShINKQ2CQr5eZwcbQYQ== Date: Thu, 4 Feb 2016 19:28:43 +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-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [AVAUxX9bnlpbMKdxu99J12BtLn80oF6B] x-microsoft-exchange-diagnostics: 1; CY1PR17MB0426; 5:0O/xwS4K6sG7NmHFXUm8/hCv/l0Clt8yCzIVyeSV+Kx6yUh1ANNgdQ9FuqD8DWqMT7iuACEPl5v1pcsoaAliCfmj0IeMu7zT4WT6ypnxDyci0BVq0drxPgoAMJ7SXoEUP2Sz3XUHlwgtWxQuVUPycg==; 24:ioH33W5PYaPhEMrfJBKpqvP5G1DcdTOsLjWrOWi7YQ/r2p9NwegaW3WAM/UcHJxdISsxgAN5cPqQg3ZPpKRylzCs2Tvj+qyFdFz1KN/G+bw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR17MB0426; x-ms-office365-filtering-correlation-id: fc44313e-2d9a-4aed-bbc1-08d32d99653b x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:CY1PR17MB0426; BCL:0; PCL:0; RULEID:; SRVR:CY1PR17MB0426; x-forefront-prvs: 084285FC5C x-forefront-antispam-report: SFV:NSPM; SFS:(7070004)(6009001)(33656002)(87572001)(54356999)(229853001)(15975445007)(77096005)(76576001)(50986999)(11100500001)(2900100001)(99286002)(5003600100002)(230783001)(110136002)(3660700001)(189998001)(5008740100001)(3280700002)(19300405004)(10400500002)(586003)(87936001)(92566002)(16236675004)(19580395003)(102836003)(19625215002)(40100003)(74316001)(86362001)(5002640100001)(790700001)(122556002)(4326007)(1220700001); DIR:OUT; SFP:1901; SCL:1; SRVR:CY1PR17MB0426; H:CY1PR17MB0425.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR17MB04250B4DC67358D55E341DABDFD10CY1PR17MB0425namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2016 19:28:43.9312 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR17MB0426 X-OriginalArrivalTime: 04 Feb 2016 19:28:45.0537 (UTC) FILETIME=[439F8510:01D15F82] Archived-At: Cc: 'The IESG' , "draft-sparks-genarea-mailarch-improvements.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-sparks-genarea-mailarch-improvements-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 19:28:48 -0000 --_000_CY1PR17MB04250B4DC67358D55E341DABDFD10CY1PR17MB0425namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This is an unusual RFC candidate - even as informational - in that it is ef= fectively a wish list for improvements to the IETF's "mailarch" tool for se= arching email archives. It's not quite a requirements document, but rather = seems to describe a well developed design, as indicated by stating that the= new version should work without requiring JavaScript on the client, but th= at in that mode would give up certain enumerated features. Since all of the archives are public, and the search engine should only hav= e the right to read them, the only significant security considerations are = with respect to denial of service. That issue is briefly raised in RFC 6778= , which this document references. --Charlie --_000_CY1PR17MB04250B4DC67358D55E341DABDFD10CY1PR17MB0425namp_ Content-Type: text/html; charset="us-ascii" Content-ID: <0F6F50A658D83A4FA90D0E31E696E167@sct-15-1-318-15-msonline-outlook-9143d.templateTenant> Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.  These comments were written primarily for the benefi= t of the security area directors.  Document editors and WG chairs should treat these comments just like any other last= call comments.

 

This is an unusual RFC candidate – even as inf= ormational – in that it is effectively a wish list for improvements t= o the IETF’s “mailarch” tool for searching email archives= . It’s not quite a requirements document, but rather seems to describ= e a well developed design, as indicated by stating that the new version shou= ld work without requiring JavaScript on the client, but that in that mode w= ould give up certain enumerated features.

 

Since all of the archives are public, and the search= engine should only have the right to read them, the only significant secur= ity considerations are with respect to denial of service. That issue is bri= efly raised in RFC 6778, which this document references.

 

        &nbs= p;       --Charlie

 

 

--_000_CY1PR17MB04250B4DC67358D55E341DABDFD10CY1PR17MB0425namp_-- From nobody Thu Feb 4 15:31:27 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B281B3407 for ; Thu, 4 Feb 2016 15:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_EXTRA_CLOSE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 iKwFb1GetORF for ; Thu, 4 Feb 2016 15:31:25 -0800 (PST) Received: from smtp82.iad3a.emailsrvr.com (smtp82.iad3a.emailsrvr.com [173.203.187.82]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062CA1B3404 for ; Thu, 4 Feb 2016 15:31:23 -0800 (PST) Received: from smtp3.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp3.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 309FB3005D5; Thu, 4 Feb 2016 18:31:23 -0500 (EST) Received: from app41.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp3.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 24B1F300223; Thu, 4 Feb 2016 18:31:23 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from app41.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.5.4); Thu, 04 Feb 2016 18:31:23 -0500 Received: from ogud.com (localhost.localdomain [127.0.0.1]) by app41.wa-webapps.iad3a (Postfix) with ESMTP id 129A0280041; Thu, 4 Feb 2016 18:31:23 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: ogud@ogud.com, from: ogud@ogud.com) with HTTP; Thu, 4 Feb 2016 18:31:23 -0500 (EST) Date: Thu, 4 Feb 2016 18:31:23 -0500 (EST) From: "Olafur Gudmundsson" To: secdir@ietf.org, "IETF DNSOP WG" , dispatch@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20160204183123000000_67968" Importance: Normal X-Priority: 3 (Normal) X-Type: html X-Auth-ID: ogud@ogud.com Message-ID: <1454628683.073614898@apps.rackspace.com> X-Mailer: webmail/12.0.0-RC Archived-At: Subject: [secdir] SecDIr review: draft-holmberg-dispatch-pani-abnf-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 23:31:26 -0000 ------=_20160204183123000000_67968 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI have reviewed this document as part of the security directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the security area direc= tors. Document editors and WG chairs should treat these comments just like= any other last call comments.=0A=0AThe document is short and to the point,= it has no security issues and is ready for publication. =0A=0AOlafur=0A=0A ------=_20160204183123000000_67968 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security directorate's =0Aong= oing effort to review all IETF documents being processed by the =0AIESG. T= hese comments were written primarily for the benefit of the =0Asecurity are= a directors. Document editors and WG chairs should treat =0Athese comments= just like any other last call comments.

The document is short a= nd to the point, it has no security issues and is ready for publication.
Olafur

 ------=_20160204183123000000_67968-- From nobody Mon Feb 8 20:25:48 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9781A036C; Mon, 8 Feb 2016 20:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 wRZyFYFjJXAM; Mon, 8 Feb 2016 20:25:44 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::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 6A8D21A036A; Mon, 8 Feb 2016 20:25:44 -0800 (PST) Received: by mail-lb0-x22c.google.com with SMTP id x4so95454776lbm.0; Mon, 08 Feb 2016 20:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=5DVuvx55MY3f3jriTx52fRqQYd3LzkSQbLTlguY3NPk=; b=yjvxok7dRz7XnnOAqBafhvhO65cc+zjFUh3LqrgzEpQ14ouZIg2DBzaEjh374xwjwG rB7bMZfHtoOhG3LbxyT6eRC5bF+3o7vOUHs4CM5WCykkcxiTCXUr+h574Mjnj+XEJ6g2 5K4E51SNsRh29fCAX96Lgz5Q/LUTtxEQVOYFo3cgUpTpnEklNBrq0yymX7VPEpQQkpzv zpVGxlF0lWK0kh9YSQuKthk+qM6nzPyEgOBan8yCmKQmKJJimIQAZs5bySIY6NStzns5 I3sdbg89L7S/hB8hevnqfos0nHAJJHNW3n4VrpPbbO0kA3Fj7c/aX5NLioJ60dUab6qO G7sQ== 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:date:message-id:subject:from :to:content-type; bh=5DVuvx55MY3f3jriTx52fRqQYd3LzkSQbLTlguY3NPk=; b=eFNmEenA4a9dGH6iQfWeVkAge67GoKWOKO1X4pow9HVwW0P34zf+Mfih1/fHa7e82E KUWEQKij9Vvhgft4AEpMxbhrM28I26sFpkfhSpUMPeSfja1Rwv+DjSN92S5WsN2W3IIO iUOmZXWuX/VFSxD83G9oX4NzpNSpEpB+nLAyecWsTtzLo6gCpBrwwB8cGIqxOZp1ZgfP W/r5nUG3p5ck8qRsnfdT525by2hQrKvsFDRPtK/apb4EjefOR28bggR9SJcpHD7HCZCX 3P6JkQlDcxWOf2YZAlgaQwVg3U9m6eA4wX3LAXS4IsNj/fsi/cyUfxtNHkeLbHMLxamb i/nw== X-Gm-Message-State: AG10YOR7ue7HstiqBv2TCJao1pjHf1BxS1CFXgtlcTjYLEllEhAyP4gJ7BsibT8GPJsNB5Aofmw8zTDNWFYGyg== MIME-Version: 1.0 X-Received: by 10.112.166.100 with SMTP id zf4mr12847145lbb.58.1454991942512; Mon, 08 Feb 2016 20:25:42 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Mon, 8 Feb 2016 20:25:42 -0800 (PST) Date: Mon, 8 Feb 2016 23:25:42 -0500 X-Google-Sender-Auth: muB42dIGHlSSFGouldAZTvywUBc Message-ID: From: Phillip Hallam-Baker To: draft-ietf-behave-ipfix-nat-logging.all@tools.ietf.org, "secdir@ietf.org" , "iesg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] SECDIR Review of draft-ietf-behave-ipfix-nat-logging-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 04:25:45 -0000 draft-ietf-behave-ipfix-nat-logging.all@tools.ietf.org 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. It is a logging format, you keep data, it might be disclosed. This document does not seem to add to the issues set out in RFC7011 which is cited in the references section. The cited reference is comprehensive, relevant and recent. Nothing further to add from a security point of view. From nobody Thu Feb 11 02:18:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2EE1ACE7A; Thu, 11 Feb 2016 02:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 SR-Uml58vHO8; Thu, 11 Feb 2016 02:18:00 -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 880701ACE73; Thu, 11 Feb 2016 02:17:58 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1BAHrvc029693 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Feb 2016 12:17:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1BAHqF3020097; Thu, 11 Feb 2016 12:17:52 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22204.24528.791620.642938@fireball.acr.fi> Date: Thu, 11 Feb 2016 12:17:52 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-netmod-opstate-reqs.all@tools.ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 16 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-netmod-opstate-reqs-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 10:18:03 -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 terminology and requirements document for handling operational state. As such the security considerations section cannot have very detailed problems, but it does properly point out that while configuration is being applied the device might be in inconsistent state, and that might cause security issues. It does not say anything about how the configuration requests needs to be secured, but I assume that is more in to the actual protocol RFC issue, than this document. It does not also comment anything about whether the different states (intended configuration, applied configuration and derivative state) should have different security policies to applied to them, i.e. it does say that it should be possible to retrieve only applied configuration or only derived state, but does not mention should there also be different security policies to do those operations. In some cases the derivative state might contain things like traffic keys negotiated during the protocol runs, or traffic information aabout flows passing the devices (privacy issues), so derivative state might be more sensitive than the actual applied configuration. Outside the security considerations section the requirement which says: A. A server MUST support only synchronous configuration operations, or only asynchronous configuration operations, or both synchronous and asynchronous configuration operations on a client-specified per-operation basis. is bit funny, as it effectively says that either syncronous or asyncronous MUST be supported and both may be supported, but I do not understand what the "client-specified per-operation basis" is meaning for the requirement for server. Client cannot really require server to change its IMPLEMENTATION on per-operation basis (i.e., client 1 requesting that server MUST support only asyncronous operations, and client 2 requesting that server MUST support only syncronous operations). Client can use either syncronous or asyncronous if both are supported by the server, and I assume this is trying to say that client can select syncronous/asyncronous operation per-operation basis, but when you are talking about that "A server MUST support ..." I do not think it is ok to requiring that on a client-specified way. I.e. proper way would be to say that if server supports both, it MUST allow client to select which method is used on per-operation basis. -- kivinen@iki.fi From nobody Thu Feb 11 03:17:07 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDA61AD248 for ; Thu, 11 Feb 2016 03:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 MgUCK2iTXNZR for ; Thu, 11 Feb 2016 03:17:04 -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 B42D91AD21C for ; Thu, 11 Feb 2016 03:17:03 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1BBGxUj015685 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Feb 2016 13:16:59 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1BBGxhI021338; Thu, 11 Feb 2016 13:16:59 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22204.28075.567916.348133@fireball.acr.fi> Date: Thu, 11 Feb 2016 13:16:59 +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.15 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, 11 Feb 2016 11:17:06 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Matthew Miller is next in the rotation. For telechat 2016-02-18 Reviewer LC end Draft Derek Atkins T 2016-01-18 draft-ietf-dnsop-edns-chain-query-06 Sam Hartman T 2016-02-04 draft-ietf-dhc-dhcpv6-privacy-03 Simon Josefsson TR2015-12-04 draft-ietf-eppext-tmch-smd-04 Warren Kumari T 2016-02-15 draft-ietf-dhc-anonymity-profile-06 For telechat 2016-03-03 Chris Lonvick T 2016-02-24 draft-ietf-httpbis-alt-svc-12 David Mandelberg T 2016-02-22 draft-ietf-siprec-metadata-20 For telechat 2016-03-17 Catherine Meadows T 2016-03-09 draft-martin-urn-globus-02 Last calls and special requests: Donald Eastlake R2016-02-22 draft-ietf-dane-openpgpkey-07 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Tobias Gondrom 2016-01-27 draft-ietf-codec-oggopus-12 Jeffrey Hutzelman 2015-12-04 draft-ietf-core-block-18 Chris Inacio 2016-02-02 draft-ietf-v6ops-ipv6-ehs-in-real-world-02 Leif Johansson 2016-02-10 draft-ietf-dprive-edns0-padding-02 Benjamin Kaduk 2016-02-09 draft-ietf-tsvwg-circuit-breaker-11 Watson Ladd 2016-02-11 draft-ietf-tram-stun-path-data-03 Ben Laurie 2016-02-16 draft-ietf-tsvwg-behave-requirements-update-06 Matt Lepinski 2016-03-09 draft-bao-v6ops-rfc6145bis-05 Alexey Melnikov 2016-03-07 draft-wallace-est-alt-challenge-04 Eric Osterweil 2016-01-05 draft-campbell-art-rfc5727-update-02 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-06 -- kivinen@iki.fi From nobody Thu Feb 11 07:57:10 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E231B33CB for ; Thu, 11 Feb 2016 07:57:09 -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 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 ps3B68apWqDm for ; Thu, 11 Feb 2016 07:57:08 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 028961B2B7B for ; Thu, 11 Feb 2016 07:57:08 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id u200so42341585ywf.0; Thu, 11 Feb 2016 07:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zRG5ieSd0JNe+MXUvFHXX7spE9h7um+EP3rbT258w7Y=; b=xUATdjf6qdkdFaVKbymC+T1VtoumMUFRevJmUSwLOmuI8Aw83uw5dw302EqTPJGtGG 7+gvGSvQwzabbLTRaSbI14ZacQTettBejfht83/3G6GmPqQw74mw5U5oACX+CAZWAI0l TGJs6nOV19flC7pxMkyJYld2qrLTFTgSuapOXoyF4+eT8qjnVa/TWfyIn+1dzNTUEJ3L m0cn5Vn4hIXUOMcsKipBOm9hKrI2vim+lleBCoL1rJAxKLGkRjKngY8ySUyEj0bSK4nS JCgv5CXbntrQM3tvr3Et7I0Ll0DTmc+EKK5PUNKz7TibgpSQkip4zCd+nyjUvdvdI9Hm 4RBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=zRG5ieSd0JNe+MXUvFHXX7spE9h7um+EP3rbT258w7Y=; b=FTOzz/d82ySS2FrVyGTigC0svEfGyL3EzTWeOGczufD5hr/yIEJ5cmUfQF/Qn942Ju iD/v5h53ifiQ29VT2Y+tSQbr0syQg66FamSG1CVQy0i0EdlvWECi8U8abPSE9DedHlWd HMkxUg3xII6Vbi5Akb+qzKiiBy7Q89oIiZfYV17LRixZ8gf+SlOBWqM6wS2E87kjELcM NYFQWXaOBBlKf1MeBLBfDjl6kaEHJ0upeZGw2y6kv0uQkmq+5PUKZr3yxTi5IJwXNhHl 8RZGteubcojJpYhR386IzSwwpZVQI3PBKoVojvqtNF9QzkfsoleJIz2M7mV6yrtSztfm X5ig== X-Gm-Message-State: AG10YOQXXoWZO9NIEH8QPvlmM2PUOlb556Rfhw3aVSb/B5V7LJL1kMN3pd9WoR6rbz7QAdxefPiUv8tJ1eiqjw== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr23478309ywa.244.1455206227275; Thu, 11 Feb 2016 07:57:07 -0800 (PST) Received: by 10.13.216.138 with HTTP; Thu, 11 Feb 2016 07:57:07 -0800 (PST) Date: Thu, 11 Feb 2016 07:57:07 -0800 Message-ID: From: Watson Ladd To: iseg@ietf.org, secdir@ietf.org, draft-ietf-tram-stun-path-data-03.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Secdir Review of draft-ietf-tram-stun-path-data-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 15:57:09 -0000 Dear all, 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 describes an extension to STUN for determining the characteristics of connections, useful in situations where hosts have multiple interfaces. It does this by enabling clients to send multiple requests and receive counts of how many responses were transmitted. This document was Ready with Nits. Some values need to be assigned by IANA. It reuses existing security mechanisms from STUN, which do in fact protect the integrity of messages properly. I am worried about interoperability questions, but these come from those earlier RFCs, and so are outside the scope of this review. Sincerely, Watson From nobody Thu Feb 11 20:21:17 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B171B3F4A; Thu, 11 Feb 2016 20:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 G8KxmIW4enet; Thu, 11 Feb 2016 20:21:11 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 479DB1B3F53; Thu, 11 Feb 2016 20:21:09 -0800 (PST) X-AuditID: 12074424-713ff70000000fca-42-56bd5db337a7 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 BC.F6.04042.3BD5DB65; Thu, 11 Feb 2016 23:21:07 -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 u1C4L6jR015362; Thu, 11 Feb 2016 23:21:07 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1C4L34W004136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Feb 2016 23:21:06 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u1C4L2il028240; Thu, 11 Feb 2016 23:21:02 -0500 (EST) Date: Thu, 11 Feb 2016 23:21:02 -0500 (EST) From: Benjamin Kaduk To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tsvwg-circuit-breaker.all@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUixCmqrLs5dm+Ywc6pRhafnq9ktpjxZyKz xYeFD1kcmD2WLPnJFMAYxWWTkpqTWZZapG+XwJXR/n0Ka8GblIrj2wobGBcEdTFyckgImEgc ftHC2MXIxSEk0MYk0fWigQnC2cgo0f3kG5RziEli5vWjLBBOA6PEzdOXmEH6WQS0JQ686mQF sdkEVCRmvtnIBmKLCERJfD96CMwWFrCVeLXiJZjNK+AoMfvDHUYQW1RAR2L1/iksEHFBiZMz n4DZzAJaEsunb2OZwMg7C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbrmermZJXqp KaWbGEGhxO6isoOx+ZDSIUYBDkYlHt4b1/eECbEmlhVX5h5ilORgUhLlZVTdGybEl5SfUpmR WJwRX1Sak1p8iFGCg1lJhFeCCyjHm5JYWZValA+TkuZgURLnffRrZ5iQQHpiSWp2ampBahFM VoaDQ0mC90AMUKNgUWp6akVaZk4JQpqJgxNkOA/Q8CKQGt7igsTc4sx0iPwpRkUpcd73IAkB kERGaR5cLzjWdzOpvmIUB3pFmDcYpIoHmCbgul8BDWYCGrzj+y6QwSWJCCmpBkaDo787lQu8 LI4EMUiwXSmOvZLApv9oRmSvT8D/ww/r3ua9DWz5fpeNLXpBlv6lJdeKZqlc3Fbc8vfGWrsU BkfdBcXRLisXzrE/45i+1MRS7UmxRNTG7LqvKWXdqzzmazOwvukTXSlcYDGBX9mhUbbyiUr5 rpWf9KfabZqikTqLUyO4ML7nnRJLcUaioRZzUXEiAJTvFLrQAgAA Archived-At: Subject: [secdir] secdir review of draft-ietf-tsvwg-circuit-breaker-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 04:21:15 -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 (the rest of this paragraph), modulo one question I have (the following paragraph). Since it's more of a requirements doc than a full protocol specification, there are not too many requirements for security considerations. This document correctly notes the risk of an attacker using the circuit breaker mechanism for denial of service and the need for integrity and authenticity of control messages. It states that there is a trade-off between the cost of crypto and the need to authenticate control messages when there is a risk of on-path attack; I am a little uncomfortable with this statement (it is perhaps "too weak"), especially since it does not give guidance on determining the level of risk, but neither do I have a concrete objection to it. (Given the availability of physical network taps to at least nation-state-level actors, there seems to always be a risk of on-path attack.) Likewise, I am somewhat uneasy with the claim that just randomization of source port (or similar randomization in the packet header) suffices to deter an off-path attacker -- for example, in crypto, we usually talk of reducing the attacker's success probability to below 2^-32 or 2^-64 or something like that, but there are only ~2^16 ports numbers to randomize in, so the success probability from just port number randomization would not meet the usual criteria. So, perhaps that's not a good example to use on its own in the requirements document; other fields in the packet header could have a larger search space and be more reasonable for this purpose. The rest of the security considerations are good, covering the issues related to capacity and robustness, and mentioning the need for per-mechanism analysis. The one question I have relates to the possibility of circuit breakers becoming ubiquitous. It seems pretty clear that going from a network with no circuit breakers to a network with one circuit breaker is worthwhile, offering a local improvement for the flows in question. But if all, or nearly all routes through the network traversed one or more circuit breakers -- is there a risk of cascading failure, either accidental or purposefully triggered by an attacker? In a network where circuit breakers occupy what a topologist would call a dense or fully-connected subset of the network, would one circuit breaker tripping cause subsequent breaker trips and near-complete network shutdown? There seems to even be something of an analogue (though not a perfect one) in electrical circuit breakers, where an extreme failure in a device can cause the breaker in a power strip to fuse open, causing the breaker for the particular circuit in the building that it's on to fuse open, tripping the main breaker for the whole panel. It is uncommon for the cascade to continue to the mains for the building or the local substation, but is a known risk. So, has anyone thought about the behavior of circuit breakers if/when they are ubiquitous in the network? (Also, it's amusing to see "CB" used for "circuit breaker" in this context, as I'm so used to seeing it expand to "channel binding". It seems that the RFC Editor's abbreviation list https://www.rfc-editor.org/materials/abbrev.expansion.txt includes neither form...) Section 7.3 as written does not seem terribly connected to circuit breakers or the rest of the document. Should it be removed? This secdir review also comes with a bonus copyediting pass; iesg@ and secdir@ feel free to stop reading now. The last sentence of the first paragraph of section 1 ("Just ... appliance.") does not have an independent clause, and leaves the reader hanging. In Section 1, second paragraph, "countered by the requirement to use congestion control by the transmission control protocol" would probably flow better as "in the [TCP]" or "with the [TCP]", since although the TCP specification is what requires the use of congestion control, the TCP protocol itself is just using congestion control. In Section 1, second paragraph, penultimate sentence, "applications of the Unix Datagram Protocol" suffers from the dual meaning of "applications" as "software programs" and "instances where it is used". The first time I read it, I flagged it to be changed to "applications using [UDP]", but of course it is the latter meaning that was intended. Not a big deal, but perhaps this could be rearranged to avoid the potential confusion. (I don't think there's a good word to just replace the single word with, though.) Section 1, third paragraph, penultimate sentence has a comma splice. Section 1, fourth paragraph, second sentence: a timescale is inherently an order-of-magnitude thing, and different paths have a different RTT, so there is not a single timescale on which congestion control operates. I suggest just saying "operates on the timescale of a packet RTT", but "operates on a timescale on the order of a packet RTT" is probably fine, too. In the following sentence, the concept of "packet loss/marking" is calmly used with no introduction. I'm not personally familiar with packet marking in this sense, and though the usage later in the document gave me some rough sense of what it means, maybe a bit more introduction (e.g., an informational reference) would be useful. Or maybe it's a term of art in transport and I'm just not a practitioner; that's possible, too. In a similar vein, "5-tuple" at the end of that same paragraph may want an informational reference to RFC 6146, or may be considered common knowledge for the target audience. In the next paragraph, there's a comma splice in the penultimate sentence. The long paragraph in the middle of page 4 seems to introduce a new term "control function" without much explanation; this phrase does not seem to be used anyplace else in the document (thought "control plane function" has one occurrence), so it seems likely that a slight rewording here would improve the document. (I'm not actually entirely sure what it's trying to say, so I don't have any concrete suggestions.) In this and the following sentence, it would be good to make more clear that the text is talking about circuit breakers and not other forms of congestion control The second bullet point for examples of situations that could trigger circuit breakers ("traffic generated by an application...utilised for other purposes") confused me the first time I read it. Perhaps shuffle things around a bit to clarify that it is that "the network capacity provisioned for that application is being utilised for other purposes", though upon re-reading the existing text may suffice as-is. The second sentence of the first (full, i.e., non-bullet-point) paragraph on page 5 seems to suffer from a bit of pronoun/antecedent confusion. In particular, "will generate elastic traffic that may be expected to regulate the load" reads as if it is the generated traffic itself that will regulate the load, whereas a common way of thinking about it would be that it is the application that is regulating the load produced by the traffic that the application generates. Also, in "the load it introduces" there is ambiguity as to whether "it" refers to the application or the traffic. (Perhaps this ambiguity is irrelevant, but in general ambiguity in a spec is to be avoided.) In the following paragraph, the second sentence is a bit long, and heavily broken up by qualifiers that are not really needed ("all but impossible", "may further be the case", "may have some difficulty", "has in fact been tripped"). As copyeditor, I would suggest splitting this into two sentences and removing some of the unneeded words. Should "Circuit Breaker" be uniformly capitalized throughout the document? It is not capitalized in the first sentence of Section 1.1. (Perhaps the plural "Breakers" is also appropriate?) On pages 8/9, it would be good to maintain parallel structure across the enumerated items, most notably by including "that" in the first sentences ("An ingress meter that records the number of packets", "A measurement function that combines", ...). Item 3 does not currently fit into that structure, and it may not be worth the drastic changes that would be needed to stuff it into place, since it is describing an action as opposed to the functions that are described in the other items. But it's probably worth making the easy changes. In item 3 of that list, the capital "An" is not needed after a semicolon, and there is another list within the second sentence that could gain a more parallel structure if "be sending another in-band" were replaced with "sending an in-band". In Section 4, fourth bullet point, "adjust the traffic to experienced congetsion" might be better as "adjust the traffic when congestion is experienced". The fifth (i.e., next) bullet point seems to lack a subject for the first sentence. Presumably it refers to the circuit breaker in question, but it's best to be explicit about it. The eighth bullet point (top of page 11), I'd put "it is" before the "triggered" in the parenthetical. In the sixteenth bullet point (second one on page 12), you refer to the "source" of control messages, which I think would more conventionally be written as the "authenticity" of those messages. ("Source" is used in this fashion in at least one other place in the document, so please change all occurrences if changing any.) I am a bit hazy on what exactly is going on in the example in Section 5.1 (the last three paragraphs), but I will chalk that up to my lack of knowledge about multicast routing. It's probably worth expanding and/or putting an informational reference for PIM-SM, though, and offsetting the "however" in the last sentence with commas. In the first paragraph of Section 5.2, please us the plural "paths" in "paths provisioned using the Resource reservation protocol". Given the success of UDP-based protocols like QUIC, mosh, BitTorrent, etc., it seems a little strong to have this claim in Section 6.1 that "all applications ought to use a full-featured transport" when the meaning seems to really just be that all applications ought to have congestion control functionality for their traffic, whether obtained via a full-featured transport or built directly into the application [protocol]. I would also consider removing the comma in the penultimate sentence of the first paragraph of Section 6.1, though I do not think I can claim that it is actually incorrect. In the next paragraph, "tailored *to* the type of traffic", and probably "when multiple congestion-controlled flows *combined* lead to short-term overload", since otherwise one could read it as saying that (multiple) (congestion-controlled flows lead to short-term overload), in which case the "multiple" is seemingly irrelevant. In the next paragraph (last one on page 15), there's a singular/plural mismatch in "a RTP-aware network devices"; I'd go with the plural, but it's your call. In Section 6.1.1, item 3 doesn't seem quite right -- I don't think that the breaker ought to trigger just by the act of using a TFRC-style check with a hard upper limit; I'd expect that the observed traffic would need to exceed that limit, too. (Also, expand "TFRC".) >From a document structure perspective, it's slightly jarring to not have a subsection 6.2.1 with a dedicated example, but I can understand why the document is currently the way it is. The last sentence of Section 6.3.1 seems to come without much lead-in; it would be nice to get a better transition into it, and maybe a mention of "circuit breaker" and its releation thereto. In Section 7.1, third paragraph, I don't think I understand what "other sharing network traffic" is supposed to mean, or really, what the example is saying in general. In Section 7.2, second paragraph, "For sure" seems a rather informal way of starting a sentence. The third sentence in that paragraph contains a comma splice. The last sentence of Section 7.2 could benefit from avoiding the pronoun in "this protects other network traffic" to clarify what exactly is providing the protection ("the network configuration", perhaps?). In Section 8, first paragraph, it's probably worth covering the failure mode when the interval is too short, just for completeness (even though it's ~obvious and covered elsewhere in the document). -Ben From nobody Thu Feb 11 21:01:50 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB901B3F62; Thu, 11 Feb 2016 21:01:48 -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 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 beqRpOopYhpC; Thu, 11 Feb 2016 21:01:44 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93AC61B3F8C; Thu, 11 Feb 2016 21:01:42 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id z13so30187277ykd.0; Thu, 11 Feb 2016 21:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iDyU5JLQshYddTNXipzAXfTAWZ+vhVxLn5mEx6/NRD0=; b=jMSDhFLCJ7s1+NaLXc22yAXxC1aDE2I/wFEcNbDrf8Jg/dGsoGa7FEL7p2IIApynBi 2v06BqYac0xzGa4ih/I2Yw6JPl4WsRSE4PmU6rpcsuiMV+uh93+qfc+OjtkyxNCAlWtb kTvaUxlplwh1zWDX94MGdqYqcH52KvYNb3YBydjCP3GXR490GYEnFkhmEdF9QgraHbvN YvwEMJrZklieiePaxBc5EigZCcdPCrFCMq8RILIiDYJX/VRK8axrgpM+mFgduqpOD4dC DKV15SAArP9RvkX3KfzH+fLMO6KPSTJHbmwxso7aUW8euKlaUcKyZLiv986tCP0mvB0v khCw== 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:date :message-id:subject:from:to:cc:content-type; bh=iDyU5JLQshYddTNXipzAXfTAWZ+vhVxLn5mEx6/NRD0=; b=W5Gb4+9RP7fiDBhe268s6tItESgsnpvOIhPPt7XWiumcl6ojQmKxOrSE6vqCbUEAJc MwzSkmY8LTck0+st49aKES22SpVml0Lgb05aOW5ddoA86C3e2td/N0kC8vkHuuuC/TxM Nl/YdHVi82q4W/yjtQgWVAXAbLAGKmZZJM+/NVYMBYHX3nj4thk5zpWBPu31RDFbdfNA QgUkbkCNq/D4BP6rkWCKzw3CSKGyvpgvoSIKys9lZp5xsNRZO4r9bQec2SV35pboSrUC 0DZ7yc/iDBHS/RF827LKRmTwLCCVmTuv1m8Ad6izs1W1ouiFgTmLZ65xGV9m/VzF9242 nO8w== X-Gm-Message-State: AG10YOSvQT3R71objo6GpQie6nWFJ3ynaxJM8XJvgUpaTL/4TeMgfY9AdSyDlkcGBU3QEu9DBnBl+c8I7igrgw== MIME-Version: 1.0 X-Received: by 10.37.78.5 with SMTP id c5mr27098846ybb.53.1455253301798; Thu, 11 Feb 2016 21:01:41 -0800 (PST) Received: by 10.13.216.138 with HTTP; Thu, 11 Feb 2016 21:01:41 -0800 (PST) In-Reply-To: References: Date: Thu, 11 Feb 2016 21:01:41 -0800 Message-ID: From: Watson Ladd To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-tsvwg-circuit-breaker.all@ietf.org, "" , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-circuit-breaker-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 05:01:48 -0000 On Thu, Feb 11, 2016 at 8:21 PM, Benjamin Kaduk wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document is ready with nits (the rest of this paragraph), modulo one > question I have (the following paragraph). Since it's more of a > requirements doc than a full protocol specification, there are not too > many requirements for security considerations. This document correctly > notes the risk of an attacker using the circuit breaker mechanism for > denial of service and the need for integrity and authenticity of control > messages. It states that there is a trade-off between the cost of crypto > and the need to authenticate control messages when there is a risk of > on-path attack; I am a little uncomfortable with this statement (it is > perhaps "too weak"), especially since it does not give guidance on > determining the level of risk, but neither do I have a concrete objection > to it. (Given the availability of physical network taps to at least > nation-state-level actors, there seems to always be a risk of on-path > attack.) Likewise, I am somewhat uneasy with the claim that just > randomization of source port (or similar randomization in the packet > header) suffices to deter an off-path attacker -- for example, in crypto, > we usually talk of reducing the attacker's success probability to below > 2^-32 or 2^-64 or something like that, but there are only ~2^16 ports > numbers to randomize in, so the success probability from just port number > randomization would not meet the usual criteria. So, perhaps that's not a > good example to use on its own in the requirements document; other fields > in the packet header could have a larger search space and be more > reasonable for this purpose. The rest of the security considerations are > good, covering the issues related to capacity and robustness, and > mentioning the need for per-mechanism analysis. Sending 2^32 packets is pretty easy, especially if I only need to get lucky once. All control signals need to be authenticated, or they will be spoofed. Secondly, this "on path" notion matters very little: routing is easily forged, you don't know what's actually on your network, routers have holes, etc. > > The one question I have relates to the possibility of circuit breakers > becoming ubiquitous. It seems pretty clear that going from a network with > no circuit breakers to a network with one circuit breaker is worthwhile, > offering a local improvement for the flows in question. But if all, or > nearly all routes through the network traversed one or more circuit > breakers -- is there a risk of cascading failure, either accidental or > purposefully triggered by an attacker? In a network where circuit > breakers occupy what a topologist would call a dense or fully-connected > subset of the network, would one circuit breaker tripping cause subsequent > breaker trips and near-complete network shutdown? There seems to even be > something of an analogue (though not a perfect one) in electrical circuit > breakers, where an extreme failure in a device can cause the breaker in a > power strip to fuse open, causing the breaker for the particular circuit > in the building that it's on to fuse open, tripping the main breaker for > the whole panel. It is uncommon for the cascade to continue to the mains > for the building or the local substation, but is a known risk. So, has > anyone thought about the behavior of circuit breakers if/when they are > ubiquitous in the network? Yes, this a serious concern. Let's consider how IPsec or MPLS network tunnels carrying TCP traffic currently function (at least to me). Each IP packet the endpoint sends gets encrypted/labeled, goes out over the other end, and at the far side of the tunnel gets decrypted and sent. Crucially a loss event in the tunnel (and hopefully ECN, but I'm not holding my breath) becomes a loss event for the TCP implementation, which then backs off, the same as if the tunnel wasn't there. One concern is if there are multiple possible tunnels to use, say connecting three sites via IPsec, with each pair exposed as a transport route for the OSPF routing happening over the VPN. Unusual: sure, but I'm sure someone out there has done it. I go and SCP a big file from site #1 to site #2, and the machines get up to full speed because there is no congestion. Unfortunately it exceeds a badly set-limit/a temporary congestion event happens. The circuit breaker on the link between them triggers, causing a loss of the tunnel event. My packets now go the long way around, triggering the second circuit breaker. Congratulations, you've just knocked out the entire office network temporarily. Even better is if the first tunnel goes down for unrelated reasons, triggering a rerouting, and so properly sized breakers become too small. The argument here is that TDM wires don't fit into a congestion controlled world as they are not congestion controlled, and dropping packets makes them not work so we should drop 100% of the packets to make things work better. I think this is really an argument against deploying TDM PWs: the Internet is packet-switched, not circuit-switched, and so circuits don't fit nicely into it. It's not clear that officially blessing a dangerous, footgunny idea is a good solution to this problem. > > (Also, it's amusing to see "CB" used for "circuit breaker" in this > context, as I'm so used to seeing it expand to "channel binding". It > seems that the RFC Editor's abbreviation list > https://www.rfc-editor.org/materials/abbrev.expansion.txt includes neither > form...) > > > Section 7.3 as written does not seem terribly connected to circuit > breakers or the rest of the document. Should it be removed? > > > This secdir review also comes with a bonus copyediting pass; iesg@ and > secdir@ feel free to stop reading now. > > The last sentence of the first paragraph of section 1 ("Just ... > appliance.") does not have an independent clause, and leaves the reader > hanging. > > In Section 1, second paragraph, "countered by the requirement to use > congestion control by the transmission control protocol" would probably > flow better as "in the [TCP]" or "with the [TCP]", since although the TCP > specification is what requires the use of congestion control, the TCP > protocol itself is just using congestion control. > > In Section 1, second paragraph, penultimate sentence, "applications of the > Unix Datagram Protocol" suffers from the dual meaning of "applications" as > "software programs" and "instances where it is used". The first time I > read it, I flagged it to be changed to "applications using [UDP]", but of > course it is the latter meaning that was intended. Not a big deal, but > perhaps this could be rearranged to avoid the potential confusion. (I > don't think there's a good word to just replace the single word with, > though.) > > Section 1, third paragraph, penultimate sentence has a comma splice. > > Section 1, fourth paragraph, second sentence: a timescale is inherently an > order-of-magnitude thing, and different paths have a different RTT, so > there is not a single timescale on which congestion control operates. I > suggest just saying "operates on the timescale of a packet RTT", but > "operates on a timescale on the order of a packet RTT" is probably fine, > too. > > In the following sentence, the concept of "packet loss/marking" is calmly > used with no introduction. I'm not personally familiar with packet > marking in this sense, and though the usage later in the document gave me > some rough sense of what it means, maybe a bit more introduction (e.g., an > informational reference) would be useful. Or maybe it's a term of art in > transport and I'm just not a practitioner; that's possible, too. > > In a similar vein, "5-tuple" at the end of that same paragraph may want an > informational reference to RFC 6146, or may be considered common knowledge > for the target audience. > > In the next paragraph, there's a comma splice in the penultimate sentence. > > The long paragraph in the middle of page 4 seems to introduce a new term > "control function" without much explanation; this phrase does not seem to > be used anyplace else in the document (thought "control plane function" > has one occurrence), so it seems likely that a slight rewording here would > improve the document. (I'm not actually entirely sure what it's trying to > say, so I don't have any concrete suggestions.) In this and the following > sentence, it would be good to make more clear that the text is talking > about circuit breakers and not other forms of congestion control > > The second bullet point for examples of situations that could trigger > circuit breakers ("traffic generated by an application...utilised for > other purposes") confused me the first time I read it. Perhaps shuffle > things around a bit to clarify that it is that "the network capacity > provisioned for that application is being utilised for other purposes", > though upon re-reading the existing text may suffice as-is. > > The second sentence of the first (full, i.e., non-bullet-point) paragraph > on page 5 seems to suffer from a bit of pronoun/antecedent confusion. In > particular, "will generate elastic traffic that may be expected to > regulate the load" reads as if it is the generated traffic itself that > will regulate the load, whereas a common way of thinking about it would be > that it is the application that is regulating the load produced by the > traffic that the application generates. Also, in "the load it introduces" > there is ambiguity as to whether "it" refers to the application or the > traffic. (Perhaps this ambiguity is irrelevant, but in general ambiguity > in a spec is to be avoided.) > > In the following paragraph, the second sentence is a bit long, and heavily > broken up by qualifiers that are not really needed ("all but impossible", > "may further be the case", "may have some difficulty", "has in fact been > tripped"). As copyeditor, I would suggest splitting this into two > sentences and removing some of the unneeded words. > > Should "Circuit Breaker" be uniformly capitalized throughout the document? > It is not capitalized in the first sentence of Section 1.1. (Perhaps the > plural "Breakers" is also appropriate?) > > On pages 8/9, it would be good to maintain parallel structure across the > enumerated items, most notably by including "that" in the first sentences > ("An ingress meter that records the number of packets", "A measurement > function that combines", ...). Item 3 does not currently fit into that > structure, and it may not be worth the drastic changes that would be > needed to stuff it into place, since it is describing an action as opposed > to the functions that are described in the other items. But it's probably > worth making the easy changes. > > In item 3 of that list, the capital "An" is not needed after a semicolon, > and there is another list within the second sentence that could gain a > more parallel structure if "be sending another in-band" were replaced with > "sending an in-band". > > In Section 4, fourth bullet point, "adjust the traffic to experienced > congetsion" might be better as "adjust the traffic when congestion is > experienced". > > The fifth (i.e., next) bullet point seems to lack a subject for the first > sentence. Presumably it refers to the circuit breaker in question, but > it's best to be explicit about it. > > The eighth bullet point (top of page 11), I'd put "it is" before the > "triggered" in the parenthetical. > > In the sixteenth bullet point (second one on page 12), you refer to the > "source" of control messages, which I think would more conventionally be > written as the "authenticity" of those messages. ("Source" is used in > this fashion in at least one other place in the document, so please change > all occurrences if changing any.) > > I am a bit hazy on what exactly is going on in the example in Section 5.1 > (the last three paragraphs), but I will chalk that up to my lack of > knowledge about multicast routing. It's probably worth expanding and/or > putting an informational reference for PIM-SM, though, and offsetting the > "however" in the last sentence with commas. > > In the first paragraph of Section 5.2, please us the plural "paths" in > "paths provisioned using the Resource reservation protocol". > > Given the success of UDP-based protocols like QUIC, mosh, BitTorrent, > etc., it seems a little strong to have this claim in Section 6.1 that "all > applications ought to use a full-featured transport" when the meaning > seems to really just be that all applications ought to have congestion > control functionality for their traffic, whether obtained via a > full-featured transport or built directly into the application [protocol]. > > I would also consider removing the comma in the penultimate sentence of > the first paragraph of Section 6.1, though I do not think I can claim that > it is actually incorrect. > > In the next paragraph, "tailored *to* the type of traffic", and probably > "when multiple congestion-controlled flows *combined* lead to short-term > overload", since otherwise one could read it as saying that (multiple) > (congestion-controlled flows lead to short-term overload), in which case > the "multiple" is seemingly irrelevant. > > In the next paragraph (last one on page 15), there's a singular/plural > mismatch in "a RTP-aware network devices"; I'd go with the plural, but > it's your call. > > In Section 6.1.1, item 3 doesn't seem quite right -- I don't think that > the breaker ought to trigger just by the act of using a TFRC-style check > with a hard upper limit; I'd expect that the observed traffic would need > to exceed that limit, too. (Also, expand "TFRC".) > > >From a document structure perspective, it's slightly jarring to not have a > subsection 6.2.1 with a dedicated example, but I can understand why the > document is currently the way it is. > > The last sentence of Section 6.3.1 seems to come without much lead-in; it > would be nice to get a better transition into it, and maybe a mention of > "circuit breaker" and its releation thereto. > > In Section 7.1, third paragraph, I don't think I understand what "other > sharing network traffic" is supposed to mean, or really, what the example > is saying in general. > > In Section 7.2, second paragraph, "For sure" seems a rather informal way > of starting a sentence. > > The third sentence in that paragraph contains a comma splice. > > The last sentence of Section 7.2 could benefit from avoiding the pronoun > in "this protects other network traffic" to clarify what exactly is > providing the protection ("the network configuration", perhaps?). > > In Section 8, first paragraph, it's probably worth covering the failure > mode when the interval is too short, just for completeness (even though > it's ~obvious and covered elsewhere in the document). > > -Ben > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Feb 12 03:37:35 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A4C1B43DC; Fri, 12 Feb 2016 03:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.972 X-Spam-Level: X-Spam-Status: No, score=0.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RP_MATCHES_RCVD=-0.001] autolearn=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 7NkIlXyosYIW; Fri, 12 Feb 2016 03:37:33 -0800 (PST) Received: from h-62.96.220.36.host.de.colt.net (a.mx.secunet.com [62.96.220.36]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C229F1B43C9; Fri, 12 Feb 2016 03:37:32 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by h-62.96.220.36.host.de.colt.net (Postfix) with ESMTP id 4426D1A03E3; Fri, 12 Feb 2016 12:37:30 +0100 (CET) X-Virus-Scanned: by secunet Received: from h-62.96.220.36.host.de.colt.net ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4qDMx3CJO7VQ; Fri, 12 Feb 2016 12:37:28 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by h-62.96.220.36.host.de.colt.net (Postfix) with ESMTP id 8C83F1A03DD; Fri, 12 Feb 2016 12:37:28 +0100 (CET) Received: from [10.208.1.99] (10.208.1.99) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.266.1; Fri, 12 Feb 2016 12:37:28 +0100 To: Donald Eastlake References: <56AB3DAF.6010409@secunet.com> From: Johannes Merkle Message-ID: <56BDC40F.5020101@secunet.com> Date: Fri, 12 Feb 2016 12:37:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.99] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Cc: draft-ietf-opsawg-hmac-sha-2-usm-snmp-new.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-03 SECDIR review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 11:37:35 -0000 the agreed improvements have been implemented in the new draft Name: draft-ietf-opsawg-hmac-sha-2-usm-snmp-new Revision: 04 Title: HMAC-SHA-2 Authentication Protocols in USM for SNMPv3 Document date: 2016-02-12 Group: opsawg Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp-new/ Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-04 Johannes Donald Eastlake schrieb am 31.01.2016 um 22:50: > Hi Johannes, > > On Fri, Jan 29, 2016 at 5:23 AM, Johannes Merkle > wrote: >> >>> The Abstract does not mention that this document obsoletes RFC 7630. I >>> think it is a good practice to include that in the Abstract. >> >> That's a good hint. I will do that. >> >>> >>> The first paragraph of the Introduction seems odd to me It says >>> "This memo defines a portion of the Management Information Base (MIB) >>> for use with network management protocols. In particular, it defines >>> additional authentication protocols ..." >>> While I can't actually say this is actually wrong, the portion of the >>> MIB it defines is trivial and it seems to me that the meat is in the >>> specification of the additional authentication protocols. Certainly, >>> those authentication protocol specifications don't appear in the MIB >>> portion specified, only identifiers for them. Yet the wording of the >>> Introduction (... defines a portion of the ... MIB.. In particular, >>> ...) seems to imply that the definition of the additional >>> authentication protocols is a subpart of the portion of the MIB. So I >>> would say the Introduction should begin with something like: >>> "This document specified additional authentication protocols ... In >>> addition, it defines a portion of the Management Information Base >>> (MIB) containing identifiers for these authentication protocols for >>> use with network management protocols." >>> >> >> Alternatively, the introduction could be rephrased in the line of that of RFC 3826, e.g., >> >> Within the Architecture for describing Simple Network Management >> Protocol (SNMP) Management Frameworks [RFC3411], the User-based >> Security Model (USM) [RFC3414] for SNMPv3 is defined as a Security >> Subsystem within an SNMP engine. In RFC 3414, two different >> authentication protocols, HMAC-MD5-96 and HMAC-SHA-96, are defined >> based on the hash functions MD5 and SHA-1, respectively. >> >> This memo specifies new HMAC-SHA-2 authentication protocols for USM... >> >> >> IMHO that would be a better start. > > That alternative text looks fine to me. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > >> -- >> Johannes > From nobody Fri Feb 12 03:41:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB17A1B43E0 for ; Fri, 12 Feb 2016 03:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779] autolearn=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 97OL7zJni8Yd for ; Fri, 12 Feb 2016 03:41:40 -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 929271B43DC for ; Fri, 12 Feb 2016 03:41:40 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1CBfcSw018795 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 12 Feb 2016 13:41:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1CBfcHB007972; Fri, 12 Feb 2016 13:41:38 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22205.50418.460889.975121@fireball.acr.fi> Date: Fri, 12 Feb 2016 13:41:38 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 6 min Archived-At: Subject: [secdir] The NTP working group and updated security protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 11:41:41 -0000 The NTP working group is getting close to a WGLC for an updated security protocol, and they would like to get early secdir review for it during the WGLC. This is 3 documents 75 pages in total. Anybody volunteering to do the early review? This will of course give 3 documents done, which will put you very high on the "most documents reviewed" list in the next IETF, and of course skips your next 3 normal round robin assignments. If you are interested send me email. Documents will be https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time-security/ https://datatracker.ietf.org/doc/draft-ietf-ntp-cms-for-nts-message/ https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ -- kivinen@iki.fi From nobody Fri Feb 12 04:15:33 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957711B43FB; Fri, 12 Feb 2016 03:47:15 -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 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 KWkqawAvLDBJ; Fri, 12 Feb 2016 03:47:13 -0800 (PST) Received: from argo.otaverkko.fi (argo.ipv6.otaverkko.fi [IPv6:2a02:4880:10:1000::2:25]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767171B43F9; Fri, 12 Feb 2016 03:47:13 -0800 (PST) Received: from webmail.otaverkko.fi (hydra.otaverkko.fi [212.68.0.4]) by argo.otaverkko.fi (Postfix) with ESMTP id 73F89202BB; Fri, 12 Feb 2016 13:47:11 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 12 Feb 2016 13:47:11 +0200 From: Samu Varjonen To: Sean Turner In-Reply-To: References: Message-ID: X-Sender: Samu.Varjonen@hiit.fi User-Agent: Roundcube Webmail/1.0.1 Archived-At: X-Mailman-Approved-At: Fri, 12 Feb 2016 04:15:32 -0800 Cc: draft-ietf-hip-rfc6253-bis.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-hip-rfc6253-bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 11:47:15 -0000 Hi, answers inline (and a question). -Samu Varjonen On 22.12.2015 19:22, Sean Turner wrote: > Fear not as this is just the secdir review! > > 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. > > draft summary: This is a bis document that specifies the certificate > parameter and the error signaling in case of a failed verification for > the Host Identity Protocol (HIP) v2; the previous version was > experimental now it's moving to the standards track. The big change > is that the SPKI cert type got dropped. > > secdir summary: pretty darn close to being ready, but I’ve got a > couple of questions and some nits: > > Questions: > > Q1. What’s the rationale for the renumbering of the certificate types? > Were there no HIPv1 implementations that used the SPKI option so it’s > safe to just renumber? If you’re not 100% sure whether there were any > you could mark values 2, 4, 6, and 8 as reserved/obsoleted and keep on > using the existing values for 3, 5, 7. nit-wise: In s2 values 5-8 are > still referenced in the last three paragraphs. The type number table in the document has been reverted and 2,4,6, and 8 has been obsoleted. > > Q2. I see that you pointed from s4 to s5 of 5280 for revocation. The > only error signaling in your s5 seems to be “invalid", but 5280 > defines a number of CRL reason codes, e.g., key compromise, but also > “holdâ€. If you’re not planning on supporting “hold†then it might be > worth adding some more text to say that any HIP certificate serial > number that appears on the CRL is treated as “invalid†regardless of > the reason code. BTW - I’m in no way suggesting that you support > hold. > We do not support hold and clarification is added > Q3. On the errors, does the credential_required error cover the case > where the sender's cert is sent but not the intermediary? I’m > assuming short paths, i.e., root, intermediary, and end-entity, so > you’d just send the end-entity and the recipient says “hey send me > you’re intermediary†or does it just fail with the > credentials_required error? > It will fail with credentials_required error. Clarification added. > Nits: > > nit 0: Often a bis draft will include a section that says what’s > changed since the original draft, but since it’s basically just “we > dropped the SPKI certificate type†maybe just put something like that > at the end of the introduction? > > nit 1: I read this a couple of times: > > CERT parameters with the same Cert group number > in the group field indicate a logical grouping. > > Isn’t it that the same group # is in the Cert group field:? > > CERT parameters with the same number > in the Cert group field indicate a logical grouping. > Is this about missing CERT word in the group field? Or did I misunderstand this question? > nit 2: There’s some error signaling, but what happens if I set Cert ID > to 0, the CERT parameters are not sent in ascending order, etc. do you > throw an error? > The numbers in the Cert ID field MUST start from 1 up to Cert count. Cert ID = 0 would result in INVALID_CERTIFICATE. About the order the document says "The CERT parameters MUST be placed in ascending order, within a HIP control packet, according to their Cert group field." Different order would result in INVALID_CERTIFICATE. Clarification added to the text. > nit 3: Do you need to specify how you do the padding, e.g., all 1s, all > 0s? > All 0s clarified in the text. > nit 4: About the example cert in Appendix A: > > 0. It’s not really a certificate in Appendix A it’s a pretty print of > some certificate fields. Maybe you could include the HEX > representation of DER cert in section A.1 and the pretty print in > section A.2? > Updated version is added as above. > 1. The example shows sha1WithRSAEncryption and that’s not one of the > algs in RFC 7401; switch it to ecdsa-with-SHA384 or whatever is being > used most now. > > 2. The serial # can’t be 0 it’s got to be a positive # (see s4.1.2.2 of > 5280) > Fixed > 3. Might be good to update the validity period :) > Fixed > 4. Are 1024-bit keys normal maybe it should be changed to 2048-bit? > Fixed > 5. I get that there will be profiles for the HIP certificates, but > there’s a couple of extensions not shown that are in pretty much every > certificate compliant with RFC 5280; AKI and KU come to mind. > This example's idea is just to show how to include HITs into the certificate so I do not see the reason to add all the possible extensions to it. Unless they could contain HITs. > A question that I’m curious about but that has absolutely nothing to > do with whether this draft progressing or not (i.e., IESG these are > not the droids you’re looking for): Is anybody implementing the DSA > suite in RFC 7401? > > spt From nobody Fri Feb 12 06:49:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E881A040C; Fri, 12 Feb 2016 06:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 MVRDb2NgTp-C; Fri, 12 Feb 2016 06:43:08 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 05E3D1A0397; Fri, 12 Feb 2016 06:43:07 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 3F5FD1B001A1; Fri, 12 Feb 2016 14:50:37 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Fri, 12 Feb 2016 14:43:06 -0000 Message-ID: <123b6fdd10b8f735e3a5e0f9e5e57228.squirrel@erg.abdn.ac.uk> In-Reply-To: References: Date: Fri, 12 Feb 2016 14:43:06 -0000 From: gorry@erg.abdn.ac.uk To: "Benjamin Kaduk" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: X-Mailman-Approved-At: Fri, 12 Feb 2016 06:49:46 -0800 Cc: draft-ietf-tsvwg-circuit-breaker.all@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-circuit-breaker-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:43:12 -0000 GF: Thanks for the great review. I've noted my response below (prefixed by GF:) - nearly all of these will be directly addressed in rev -12. Gorry ---- 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 (the rest of this paragraph), modulo one question I have (the following paragraph). Since it's more of a requirements doc than a full protocol specification, there are not too many requirements for security considerations. This document correctly notes the risk of an attacker using the circuit breaker mechanism for denial of service and the need for integrity and authenticity of control messages. It states that there is a trade-off between the cost of crypto and the need to authenticate control messages when there is a risk of on-path attack; I am a little uncomfortable with this statement (it is perhaps "too weak"), especially since it does not give guidance on determining the level of risk, but neither do I have a concrete objection to it. (Given the availability of physical network taps to at least nation-state-level actors, there seems to always be a risk of on-path attack.) Likewise, I am somewhat uneasy with the claim that just randomization of source port (or similar randomization in the packet header) suffices to deter an off-path attacker -- for example, in crypto, we usually talk of reducing the attacker's success probability to below 2^-32 or 2^-64 or something like that, but there are only ~2^16 ports numbers to randomize in, so the success probability from just port number randomization would not meet the usual criteria. So, perhaps that's not a good example to use on its own in the requirements document; other fields in the packet header could have a larger search space and be more reasonable for this purpose. The rest of the security considerations are good, covering the issues related to capacity and robustness, and mentioning the need for per-mechanism analysis. GF: Further advice is needed.I note the off-path “protection” of the source port is typically used per transport flow (could be appropriate to Fast-Trip CBs). For large flow aggregates the impact of an attack can be greater, and so perhaps also the recommendation should be stronger? The one question I have relates to the possibility of circuit breakers becoming ubiquitous. It seems pretty clear that going from a network with no circuit breakers to a network with one circuit breaker is worthwhile, offering a local improvement for the flows in question. But if all, or nearly all routes through the network traversed one or more circuit breakers -- is there a risk of cascading failure, either accidental or purposefully triggered by an attacker? In a network where circuit breakers occupy what a topologist would call a dense or fully-connected subset of the network, would one circuit breaker tripping cause subsequent breaker trips and near-complete network shutdown? GF: Not expected. The result of a circuit breaker tripping is to shed traffic (load), not to reduce capacity. This should mean that once a CB is triggered this results in less load to another cascaded circuit breaker. There seems to even be something of an analogue (though not a perfect one) in electrical circuit breakers, where an extreme failure in a device can cause the breaker in a power strip to fuse open, causing the breaker for the particular circuit in the building that it's on to fuse open, tripping the main breaker for the whole panel. It is uncommon for the cascade to continue to the mains for the building or the local substation, but is a known risk. So, has anyone thought about the behavior of circuit breakers if/when they are ubiquitous in the network? GF: For electricity supply, the circuit breaker stops the supply. So you’re correct in that selectivity between circuit breakers connected in series requires that the operating or tripping time of the lower rated downstream circuit breaker is less than the operating or tripping time of the upstream circuit breaker. For short circuits where current limitation occurs and the energy let-through as the device clears the fault is significant, and you can indeed trip all the electrical circuit breakers. GF: However, I think in the networking context, things are different because the circuit breaker acts by turning off the source of traffic, not by turning off the ”capacity” (other traffic can use the network after a source is disabled). In the network, the problem then becomes one of selecting a sufficiently long reaction time/robust measure to allow other functions to react before the source is turned off. --------------------------------------------------------------------------------- (Also, it's amusing to see "CB" used for "circuit breaker" in this context, as I'm so used to seeing it expand to "channel binding". It seems that the RFC Editor's abbreviation list https://www.rfc-editor.org/materials/abbrev.expansion.txt includes neither form...) Section 7.3 as written does not seem terribly connected to circuit breakers or the rest of the document. Should it be removed? -GF: Reworked This secdir review also comes with a bonus copyediting pass; iesg@ and secdir@ feel free to stop reading now. -GF: Sorry for making you proof-read, comments appreciated. The last sentence of the first paragraph of section 1 ("Just ... appliance.") does not have an independent clause, and leaves the reader hanging. -GF: Resolved. In Section 1, second paragraph, "countered by the requirement to use congestion control by the transmission control protocol" would probably flow better as "in the [TCP]" or "with the [TCP]", since although the TCP specification is what requires the use of congestion control, the TCP protocol itself is just using congestion control. -GF: Done. In Section 1, second paragraph, penultimate sentence, "applications of the Unix Datagram Protocol" suffers from the dual meaning of "applications" as "software programs" and "instances where it is used". The first time I read it, I flagged it to be changed to "applications using [UDP]", but of course it is the latter meaning that was intended. Not a big deal, but perhaps this could be rearranged to avoid the potential confusion. (I don't think there's a good word to just replace the single word with, though.) -GF: Done. Section 1, third paragraph, penultimate sentence has a comma splice. -GF: Done. Section 1, fourth paragraph, second sentence: a timescale is inherently an order-of-magnitude thing, and different paths have a different RTT, so there is not a single timescale on which congestion control operates. I suggest just saying "operates on the timescale of a packet RTT", but "operates on a timescale on the order of a packet RTT" is probably fine, too. -GF: Done. In the following sentence, the concept of "packet loss/marking" is calmly used with no introduction. I'm not personally familiar with packet marking in this sense, and though the usage later in the document gave me some rough sense of what it means, maybe a bit more introduction (e.g., an informational reference) would be useful. Or maybe it's a term of art in transport and I'm just not a practitioner; that's possible, too. -GF: Added ref to ECN spec. In a similar vein, "5-tuple" at the end of that same paragraph may want an informational reference to RFC 6146, or may be considered common knowledge for the target audience. -GF: Added: (e.g., a 5-tuple that includes the IP addresses, protocol, and ports). In the next paragraph, there's a comma splice in the penultimate sentence. -GF: Done. The long paragraph in the middle of page 4 seems to introduce a new term "control function" without much explanation; this phrase does not seem to be used anyplace else in the document (thought "control plane function" has one occurrence), so it seems likely that a slight rewording here would improve the document. (I'm not actually entirely sure what it's trying to say, so I don't have any concrete suggestions.) In this and the following sentence, it would be good to make more clear that the text is talking about circuit breakers and not other forms of congestion control -GF: This seems to have collected inputs from various people into a less read-able para. Rewritten. The second bullet point for examples of situations that could trigger circuit breakers ("traffic generated by an application...utilised for other purposes") confused me the first time I read it. Perhaps shuffle things around a bit to clarify that it is that "the network capacity provisioned for that application is being utilised for other purposes", though upon re-reading the existing text may suffice as-is. -GF: Did not change - couldn’t work out how to do it better. The second sentence of the first (full, i.e., non-bullet-point) paragraph on page 5 seems to suffer from a bit of pronoun/antecedent confusion. In particular, "will generate elastic traffic that may be expected to regulate the load" reads as if it is the generated traffic itself that will regulate the load, whereas a common way of thinking about it would be that it is the application that is regulating the load produced by the traffic that the application generates. Also, in "the load it introduces" there is ambiguity as to whether "it" refers to the application or the traffic. (Perhaps this ambiguity is irrelevant, but in general ambiguity in a spec is to be avoided.) -GF: Reworked. In the following paragraph, the second sentence is a bit long, and heavily broken up by qualifiers that are not really needed ("all but impossible", "may further be the case", "may have some difficulty", "has in fact been tripped"). As copyeditor, I would suggest splitting this into two sentences and removing some of the unneeded words. -GF: Done Should "Circuit Breaker" be uniformly capitalized throughout the document? It is not capitalized in the first sentence of Section 1.1. (Perhaps the plural "Breakers" is also appropriate? -GF: Done On pages 8/9, it would be good to maintain parallel structure across the enumerated items, most notably by including "that" in the first sentences ("An ingress meter that records the number of packets", "A measurement function that combines", ...). Item 3 does not currently fit into that structure, and it may not be worth the drastic changes that would be needed to stuff it into place, since it is describing an action as opposed to the functions that are described in the other items. But it's probably worth making the easy changes. -GF: Done In item 3 of that list, the capital "An" is not needed after a semicolon, -GF: Done and there is another list within the second sentence that could gain a more parallel structure if "be sending another in-band" were replaced with "sending an in-band". -GF: Done In Section 4, fourth bullet point, "adjust the traffic to experienced congetsion" might be better as "adjust the traffic when congestion is experienced". -GF: Done The fifth (i.e., next) bullet point seems to lack a subject for the first sentence. Presumably it refers to the circuit breaker in question, but it's best to be explicit about it. -GF: Done The eighth bullet point (top of page 11), I'd put "it is" before the "triggered" in the parenthetical. -GF: Done In the sixteenth bullet point (second one on page 12), you refer to the "source" of control messages, which I think would more conventionally be written as the "authenticity" of those messages. ("Source" is used in this fashion in at least one other place in the document, so please change all occurrences if changing any.) -GF: Done I am a bit hazy on what exactly is going on in the example in Section 5.1 (the last three paragraphs), but I will chalk that up to my lack of knowledge about multicast routing. It's probably worth expanding and/or putting an informational reference for PIM-SM, though, and offsetting the "however" in the last sentence with commas. -GF: Done In the first paragraph of Section 5.2, please us the plural "paths" in "paths provisioned using the Resource reservation protocol". -GF: Done Given the success of UDP-based protocols like QUIC, mosh, BitTorrent, etc., it seems a little strong to have this claim in Section 6.1 that "all applications ought to use a full-featured transport" when the meaning seems to really just be that all applications ought to have congestion control functionality for their traffic, whether obtained via a full-featured transport or built directly into the application [protocol]. -GF: Yes. Of course, fixed. I would also consider removing the comma in the penultimate sentence of the first paragraph of Section 6.1, though I do not think I can claim that it is actually incorrect. -GF: Done In the next paragraph, "tailored *to* the type of traffic", and probably "when multiple congestion-controlled flows *combined* lead to short-term overload", since otherwise one could read it as saying that (multiple) (congestion-controlled flows lead to short-term overload), in which case the "multiple" is seemingly irrelevant. -GF: Done In the next paragraph (last one on page 15), there's a singular/plural mismatch in "a RTP-aware network devices"; I'd go with the plural, but it's your call. -GF: Done In Section 6.1.1, item 3 doesn't seem quite right -- I don't think that the breaker ought to trigger just by the act of using a TFRC-style check with a hard upper limit; I'd expect that the observed traffic would need to exceed that limit, too. (Also, expand "TFRC".) -GF: Done >From a document structure perspective, it's slightly jarring to not have a subsection 6.2.1 with a dedicated example, but I can understand why the document is currently the way it is. -GF: No action. The last sentence of Section 6.3.1 seems to come without much lead-in; it would be nice to get a better transition into it, and maybe a mention of "circuit breaker" and its releation thereto. -GF: Done In Section 7.1, third paragraph, I don't think I understand what "other sharing network traffic" is supposed to mean, or really, what the example is saying in general. -GF: Done In Section 7.2, second paragraph, "For sure" seems a rather informal way of starting a sentence. -GF: Already fixed! The third sentence in that paragraph contains a comma splice. -GF: Done The last sentence of Section 7.2 could benefit from avoiding the pronoun in "this protects other network traffic" to clarify what exactly is providing the protection ("the network configuration", perhaps?). -GF: Done In Section 8, first paragraph, it's probably worth covering the failure mode when the interval is too short, just for completeness (even though it's ~obvious and covered elsewhere in the document). -GF: Done. -Ben From nobody Fri Feb 12 06:50:32 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C351A0545 for ; Fri, 12 Feb 2016 06:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 6FL2Vnn2b2Ai for ; Fri, 12 Feb 2016 06:50:29 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3346A1A047A for ; Fri, 12 Feb 2016 06:50:29 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 6C7CF9A4005; Fri, 12 Feb 2016 09:50:28 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id S2vA0S9LdrQa; Fri, 12 Feb 2016 09:49:20 -0500 (EST) Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 1889A9A4001; Fri, 12 Feb 2016 09:50:28 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <22205.50418.460889.975121@fireball.acr.fi> Date: Fri, 12 Feb 2016 09:50:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22205.50418.460889.975121@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1085) Archived-At: Cc: secdir@ietf.org Subject: Re: [secdir] The NTP working group and updated security protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:50:31 -0000 I have helped with theses documents, and I would greatly appreciate = another set of eyes on them. It will be much easier for someone that is = familiar with CMS. Russ On Feb 12, 2016, at 6:41 AM, Tero Kivinen wrote: > The NTP working group is getting close to a WGLC for an updated > security protocol, and they would like to get early secdir review for > it during the WGLC. >=20 > This is 3 documents 75 pages in total. >=20 > Anybody volunteering to do the early review? >=20 > This will of course give 3 documents done, which will put you very > high on the "most documents reviewed" list in the next IETF, and of > course skips your next 3 normal round robin assignments. >=20 > If you are interested send me email. >=20 > Documents will be >=20 > https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time-security/ > https://datatracker.ietf.org/doc/draft-ietf-ntp-cms-for-nts-message/ > https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ >=20 > --=20 > kivinen@iki.fi From nobody Fri Feb 12 14:12:12 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 CEC481A90F1; Fri, 12 Feb 2016 14:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1455315035; bh=5jQPCCDiBaPEZ0azOen0CW4HfSXTH6Lh1+O35aNKVe8=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=T6tFKUgmAAPDrwCVVYEj5btTqBAj3sJKIxRhu6LMCNAmmzlPlmaLQU8SXDduwLGML 0ALljz6s24b+SCx6DJa/Sv6Okce9g0BooYb5zclYoGzcL2Z5dhgPgoVG+7e6eyXsqH 0NOjFaCr5djKixXoG8WVN7CTuwdYDm6AfEJEnUNQ= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 676431A90DD for ; Fri, 12 Feb 2016 14:10:30 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <20160212221030.18260.85490.idtracker@ietfa.amsl.com> Date: Fri, 12 Feb 2016 14:10:30 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 12 Feb 2016 14:12:09 -0800 Subject: [secdir] [new-work] WG Review: Dispatch (dispatch) 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, 12 Feb 2016 22:10:36 -0000 The Dispatch (dispatch) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-02-22. Dispatch (dispatch) ----------------------------------------------------------------------- Current status: Active WG Chairs: Mary Barnes Cullen Jennings Murray Kucherawy Assigned Area Director: Ben Campbell Applications and Real-Time Area Directors: Barry Leiba Ben Campbell Alissa Cooper Mailing list: Address: dispatch@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/dispatch Archive: https://mailarchive.ietf.org/arch/browse/dispatch/ Charter: https://datatracker.ietf.org/doc/charter-ietf-dispatch/ The Dispatch working group is chartered to consider proposals for new work in the ART area and identify, or help create, an appropriate venue for the work. Guiding principles for the proposed new work include: 1. Providing a clear problem statement, motivation and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, individuals have expressed a willingness to contribute and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing protocol work. Such commonalities may indicate the possibility of reusing existing protocols or elements thereof published by other WGs, or expanding and/or refactoring the scope of deliverables in an active WG. 4. Protecting the architectural integrity of IETF protocols and ensuring that new work has general applicability. 5. Ensuring that the new work considers and seeks to improve security and privacy. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - By agreement with ART ADs, processing simple administrative documents. - Deferring the decision for the new work. - Rejecting the new work. If the group decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. The DISPATCH WG will not do any protocol work. Specifically, DISPATCH will always opt to find a location for technical work; the only work that DISPATCH is not required to delegate (or defer, or reject) is administrative work such as IANA actions. Documents progressed as AD-sponsored would typically include those that do not have general applicability to IETF protocols, but rather are only applicable to specific use cases and network deployments, for which the scope must be clearly specified. Proposed new work may be deferred in cases where the WG does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient WG interest or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, the WG will strive to quickly find a home for it. While most new work in the ART area is expected to be considered in the DISPATCH working group, there may be times where that is not appropriate. At the discretion of the area directors, new efforts may follow other paths. For example work may go directly to BoFs, may be initiated in other working groups when it clearly belongs in that group, or may be directly AD sponsored. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sun Feb 14 13:03:20 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA0E1A1B79 for ; Sun, 14 Feb 2016 13:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 XwxHbg-T7CFR for ; Sun, 14 Feb 2016 13:03:07 -0800 (PST) Received: from nm23-vm4.access.bullet.mail.gq1.yahoo.com (nm23-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.111]) (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 ADCCF1A1B72 for ; Sun, 14 Feb 2016 13:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1455483787; bh=OEcvMJQFNOG9WG00hBWVO7DuWyQ7sYIykvRSXl4K3KM=; h=From:Subject:To:Date:From:Subject; b=rwY+IoXBxcrJnpo04L7WjVpQvnbdbSt9FVyE8fC2OP2f6OV/8J1ahogC11PygrrKGgZXK/eJtDd+HW0Rh6wBcuEGvZf1/kjX4FzUs8icHT+USl9QGIdQAd01nHxPKQkZvUHNEJHNaw8YWGDZB7LxWWwpvPZEaXfEFxLCSLVo0NefUe8An7CNxiwOnlte7xCol5pbadzAewbJJbXAUYGMD44JhLET7fTlFkUePtsrMInRkbhPjc9WhtEMJ2RqMqsWXeHPwSv08Ohe9A4fYFyjTNw1ukyHAMVFG8+S2bo9qKWwhUKOElWECUTmGpMCC33bbp72inFbMBVPpVO7oXYLtw== Received: from [216.39.60.166] by nm23.access.bullet.mail.gq1.yahoo.com with NNFMP; 14 Feb 2016 21:03:06 -0000 Received: from [98.138.226.244] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 14 Feb 2016 21:03:06 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 14 Feb 2016 21:03:06 -0000 X-Yahoo-Newman-Id: 840235.14966.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WPfchOIVM1m3g511rNqIqj.aXJjyBWcC3vZA6SDIVdqOQNm XgyPlzSlyddtEPFfwJQb64IBsZKklpCBOwTggZPv5aO6w7NgHhe8E89GGBaw bBVXIjcFnqPiT7d60UMY4zwUvYXD3Q_wxn6SOAY6chTiIn7q50zuV_aQfRHr ckkf6akl26Bjvy.lh5K7nvUa3xazS3CKIWpGO1dfCMgVACoL53D1NtkCeUXB Y0FsoeRXLnkrCtC9VDqJZfkLGaEbYqC2GN2pMBuF9Kj8gMGkFVPmcsP.Y8DU O0oLdq7qZ0hTVpTkwArg14tT.CohUuGLa7vfJCspTQdyTS1Gzwyy3XvIO.Cn 4FIy9zxvdOZsD4uDd_qwbc13V1UskAf68BXxWM.2f6RgyG7zQSUMRH2m7ljE 05ljghqBj9r9kDbM1j52sgFHwXam5uXQnKkBf3Kwd9FKx5LGM53bWd_Zouip BZxxbmqZswYwRba_Q2nBU1KBfc9lVkdOSWarg4jtyQPCFlimjfzUvzCA8o8V eq1xSlp9HkkRnWkAa0.veTcH7pftt.bN.aSwp1A-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.16] (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id ADDED1C6006; Sun, 14 Feb 2016 16:03:05 -0500 (EST) From: David Mandelberg To: iesg@ietf.org, secdir@ietf.org, draft-ietf-siprec-metadata.all@tools.ietf.org X-Enigmail-Draft-Status: N1110 Message-ID: <56C0EB89.4050409@mandelberg.org> Date: Sun, 14 Feb 2016 16:03:05 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeJ3dG6H2i0DV6HQaacpuBp5PDhrTgrjO" Archived-At: Subject: [secdir] secdir review of draft-ietf-siprec-metadata-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 21:03:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EeJ3dG6H2i0DV6HQaacpuBp5PDhrTgrjO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. This document specifies a metadata format for information about recorded SIP sessions. The Security Considerations section has good text about the protection of metadata in this format, but I found one potential security issue with the way an SRS (server) is supposed to handle the metadata. I think this draft is ready with issues. Section 6.10 says that "multiple SRC's [clients] can refer to the same element/UUID (how each SRC learns the UUID here is out of scope of SIPREC)". But what happens if two clients try to define different objects with the same UUID? Does one of the objects take precedence for all clients? If all of the benign clients are relying on referencing an object A with UUID 1, and a malicious client is able to send an object B also with UUID 1, that might compromise the integrity of the metadata sent by the benign clients. This could be mitigated by requiring that UUIDs are generated (pseudo-)randomly and are kept confidential from potential adversaries, but I don't think the draft says either of these things. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --EeJ3dG6H2i0DV6HQaacpuBp5PDhrTgrjO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlbA64kACgkQRKlmUHCg4sBvBgCfQv7Z1ao1izjQxoGc2N587Poi 6P4An2wEi/zAw5/JyhIMzLscjWP8kYou =Ph/Y -----END PGP SIGNATURE----- --EeJ3dG6H2i0DV6HQaacpuBp5PDhrTgrjO-- From nobody Sun Feb 14 21:19:01 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115611B2DC7 for ; Sun, 14 Feb 2016 21:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 giM_AHJeKngc for ; Sun, 14 Feb 2016 21:18:52 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51CB1B2DAC for ; Sun, 14 Feb 2016 21:18:52 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-03v.sys.comcast.net with comcast id JVJr1s00258ss0Y01VJsBc; Mon, 15 Feb 2016 05:18:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-14v.sys.comcast.net with comcast id JVJq1s00D3KdFy101VJqFM; Mon, 15 Feb 2016 05:18:51 +0000 To: David Mandelberg , iesg@ietf.org, secdir@ietf.org, draft-ietf-siprec-metadata.all@tools.ietf.org References: <56C0EB89.4050409@mandelberg.org> From: Paul Kyzivat Message-ID: <56C15FB9.8030600@alum.mit.edu> Date: Mon, 15 Feb 2016 00:18:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C0EB89.4050409@mandelberg.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455513532; bh=hZiscENGrjqkc2TSxe4fZhXoDWo36Au1d0UMcwsswu0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=r/caXObbwPF/72Cx+XtgG7XphvirhJIgvOi46Ag15GLyOPHV4+4nRtjCSTvWGwcDc KlGexklVsW+FeMrViG2YHkd2tgoZtGpBrowd5zey9IjBN1gidQ3OvFlsZLYstODyHB 2qNAvePlmmDtQIfGYMX/psUImFc23TV0cbrUsyIkozLkOGd8i4E51dJGsBojeNbtYk dd12PtiYxImImNDF0SmhA6Q0i8xCYgvIck7D7bDxQZGxZVlSdr5XuKj0BnVK7k8dVe solyGgzzp14NbFRbyyc5zRNPDbgsJ+6G917YA1iccwDQWPeGJd8wqcMVmWHB7VDoAY 37YYHDxhStotA== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-siprec-metadata-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 05:18:54 -0000 David, Thank you for the review. I will try to respond. (Note that I haven't consulted with the other authors on this response, so they may have something else to say.) Please see inline below. On 2/14/16 4:03 PM, David Mandelberg 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. > > This document specifies a metadata format for information about recorded > SIP sessions. The Security Considerations section has good text about > the protection of metadata in this format, but I found one potential > security issue with the way an SRS (server) is supposed to handle the > metadata. I think this draft is ready with issues. > > Section 6.10 says that "multiple SRC's [clients] can refer to the same > element/UUID (how each SRC learns the UUID here is out of scope of > SIPREC)". But what happens if two clients try to define different > objects with the same UUID? Does one of the objects take precedence for > all clients? If all of the benign clients are relying on referencing an > object A with UUID 1, and a malicious client is able to send an object B > also with UUID 1, that might compromise the integrity of the metadata > sent by the benign clients. This could be mitigated by requiring that > UUIDs are generated (pseudo-)randomly and are kept confidential from > potential adversaries, but I don't think the draft says either of these > things. The UUIDs used in the metadata are intended to be *unique*. Distinct SRCs that construct new UUIDs are expected to follow the rules for constructing them so that they are indeed unique. If two SRCs use the same UUID it will be because they intentionally choose to do so. Typically this will be by some back channel to communicate among themselves. (I suppose there could potentially be some algorithmic way for them to construct UUIDs in a coordinated way, but I won't speculate on that.) By design there should be no accidental reuse of UUIDs. Thanks, Paul From nobody Mon Feb 15 04:37:55 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC6C1B3232 for ; Mon, 15 Feb 2016 04:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 RI4FrRWiCUun for ; Mon, 15 Feb 2016 04:37:53 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::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 7996D1B321C for ; Mon, 15 Feb 2016 04:37:53 -0800 (PST) Received: by mail-ig0-x235.google.com with SMTP id 5so54788196igt.0 for ; Mon, 15 Feb 2016 04:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=b0MSE2LHsNatFvnw8D6cnaemztD3+5V6JDz0pPSZhoQ=; b=HDRwlJcaf0hMfLf91MOMcBR2u3w/vxA+T5161UyfnHB1OribAWx/47uVrZ2d3R28O+ j4lU/8x/+EOKX0QliOvKGlGHg6IISOpHFVIR1/k2XRWP7rq6Mz+wXTKqMZKWiaDRHd8I W2hFrOYA5CCuWeoOKGyj8dmw6Fzl9AWUDvTygRGkTVPkZbpwm+wYzGZ2nhM2x2zLccER BLzLc8vvZL6VtWfKD8E6G4FcASvwKf26DUI2at46dTrXeTSrcVtkywOB5kP4HFnC+rqW cdFGmpqVemroy/3wrIFXbP0Sd0+gXoIg9hNPA0ssb+nCCXMWzKtGJaVZg2Y6gnsCBij3 2alg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=b0MSE2LHsNatFvnw8D6cnaemztD3+5V6JDz0pPSZhoQ=; b=AduD/seC9vbKRSfK6dO+jyHUBnh1AizOsggBIuI+IUaXOpFo1Azc/TrIDjw+exicgL JBN1HFsJ2yVDyej/9dVDWdk0XOsAJZwmvmyCVmQxSk7klCcekw76/TGiQnRoLiUvLQAK 4XqsgzxG6bhEfpMNbKRknWUYttjhNyg8W9wSCRDVUnUxRdA4YRYxA0lhB5VFWUJ6J2aZ nxUMOL9XEDp1jNbDQ+Sx5KVxwHeq6RLjUZ2svZLsBdnB1AHAeP4MPrzXTgBE9ONr5wc3 XJfTo5XpcJB1bZWFL978OIgIZej2PAt4R0C/NSJu5K2q9tvIHPdE5RK/6sJqV4wX+OMS z9JQ== X-Gm-Message-State: AG10YOR3IskRog84yv0nCvPlhQoq0mEf0MeQz0nfsDNPH4wq4/5d3XMXPnLuE94pfV7joOLXj68zB8hInCiAMxET MIME-Version: 1.0 X-Received: by 10.50.171.162 with SMTP id av2mr12689499igc.32.1455539872774; Mon, 15 Feb 2016 04:37:52 -0800 (PST) Received: by 10.64.26.98 with HTTP; Mon, 15 Feb 2016 04:37:52 -0800 (PST) Date: Mon, 15 Feb 2016 12:37:52 +0000 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-tsvwg-behave-requirements-update-all@tools.ietf.org Content-Type: multipart/alternative; boundary=089e0118429e1328d7052bce49e3 Archived-At: Subject: [secdir] Security review of draft-ietf-tsvwg-behave-requirements-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 12:37:55 -0000 --089e0118429e1328d7052bce49e3 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: ready with issues This document updates the behavioural requirements for NAT, and as noted in the very comprehensive (thankyou!) security considerations section, introduces at least two requirements that might have security consequences. The ADs should probably consider whether these new requirements are worth the additional risk. Also, "Hosts which require a restricted filtering behavior should enable security-dedicated features (e.g., access control list (ACL)) either locally or by soliciting a dedicated security device (e.g., firewall)." is concerning - how will hosts know that they need to update their policies? "security-dedicate features" is not very informative - it would be helpful to explain what new behaviour may need to be counteracted. Looking at sections 5 and 6, to which this text refers, they appear to make NAT more restrictive, not less, so its unclear why there might be security impact. BTW, small typo: "only if packets are to be sen to distinct destination addresses." sen -> sent --089e0118429e1328d7052bce49e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security dire= ctorate's ongoing effort to review all IETF documents being processed b= y the IESG. These comments were written primarily for the benefit of the se= curity area directors. Document editors and WG chairs should treat these co= mments just like any other last call comments.

Summary: = ready with issues

This document updates the behavi= oural requirements for NAT, and as noted in the very comprehensive (thankyo= u!) security considerations section, =C2=A0introduces at least two requirem= ents that might have security consequences.

The AD= s should probably consider whether these new requirements are worth the add= itional risk.

Also, "Hosts which require a=C2=A0restricted filt= ering behavior should enable security-dedicated=C2=A0features (e.g., access= control list (ACL)) either locally or by=C2=A0soliciting a dedicated secur= ity device (e.g., firewall)." is concerning - how will hosts know that= they need to update their policies?

"securit= y-dedicate features" is not very informative - it would be helpful to = explain what new behaviour may need to be counteracted. Looking at sections= 5 and 6, to which this text refers, they appear to make NAT more restricti= ve, not less, so its unclear why there might be security impact.

B= TW, small typo: "only if packets are to be sen to distinct destination= =C2=A0addresses."
sen -> sent

--089e0118429e1328d7052bce49e3-- From nobody Mon Feb 15 04:44:10 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4897E1B32CC for ; Mon, 15 Feb 2016 04:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 993NgHUW0EUj for ; Mon, 15 Feb 2016 04:44:07 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 1894A1B32C9 for ; Mon, 15 Feb 2016 04:44:07 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id z135so87691728iof.0 for ; Mon, 15 Feb 2016 04:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RZZLQgPKPlBP1GZKNLT9OZNalGD5QHnEfoNJtK1uNmE=; b=j9akhTQ83UhptvmZci5mf6/WUJ9OVmT4/t+Dd1HjHAag1vxFzYl+Z/i0s1OUoROXie MAHNH2EF42RkZd3HTRbCBtSb0bc4hFEXXkMYjU8dO9XUrfW8J8N5C3864R0PVIVGdl2C 6DPy4Fyi5bd0wn8OkJW4QHzHfMc94ZGcxfys9Qq10BV5g6IZDGv6r5b8wxTnQ6PorAoZ ZzipOr/5AHRluRaEKUU5pOnfWNMqghkoF36KtetSdkWVLnh/2FiajO5PBh/HIk2qkvFE wS7vhqdYeYJpppz4OQVM9lC7rrYc/4yzYVQjFOCkOLV9QMIJUWM9/0zr8VYHD0BmJPgs mnmg== 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:date :message-id:subject:from:to:content-type; bh=RZZLQgPKPlBP1GZKNLT9OZNalGD5QHnEfoNJtK1uNmE=; b=AiKA+OGzmXI1j38RxEWhWXT5VryyqPbx1Nvh7isrMDK7mwSr9zyXCHTP7bMDBQCtPc UuGQ4tiNSZ+WzI6xQtrt3vKYC6UvBCyJSi4/7uVP1Nq43ZLohX8seiHKI49pJFH3r7o5 94tTIQJIrF865Oh+EX2LSb7GP0azvrWv7ZvFLIwka6AHIYgf/J2+XCFjGCypPcPhUdC4 wD3DtoPskDtlxbAcKS6iYlcRGIeyDPGW4MVAkUOzeT4ntCwKpsxwgRwJI0CB1+nxjYke nWSwz7Pf40LBLew5hN66APc5C4lxiCF7LK/vRTV45XXQdFpCDDGH5NW/1nZ0lfhLVaq/ FtZw== X-Gm-Message-State: AG10YOSI/oHVYujXziXZuNNcVZp3swskEb8UOk8W8HDIW9q4NQbYzkNhsK/dYWHZW4uA7bfsfa47I0aZLMPRfNKU MIME-Version: 1.0 X-Received: by 10.107.16.17 with SMTP id y17mr20017165ioi.119.1455540246177; Mon, 15 Feb 2016 04:44:06 -0800 (PST) Received: by 10.64.26.98 with HTTP; Mon, 15 Feb 2016 04:44:06 -0800 (PST) In-Reply-To: References: Date: Mon, 15 Feb 2016 12:44:06 +0000 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-tsvwg-behave-requirements-update.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a113ff32854b9ec052bce5f96 Archived-At: Subject: Re: [secdir] Security review of draft-ietf-tsvwg-behave-requirements-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 12:44:08 -0000 --001a113ff32854b9ec052bce5f96 Content-Type: text/plain; charset=UTF-8 Resending to correct address: 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 issues This document updates the behavioural requirements for NAT, and as noted in the very comprehensive (thankyou!) security considerations section, introduces at least two requirements that might have security consequences. The ADs should probably consider whether these new requirements are worth the additional risk. Also, "Hosts which require a restricted filtering behavior should enable security-dedicated features (e.g., access control list (ACL)) either locally or by soliciting a dedicated security device (e.g., firewall)." is concerning - how will hosts know that they need to update their policies? "security-dedicate features" is not very informative - it would be helpful to explain what new behaviour may need to be counteracted. Looking at sections 5 and 6, to which this text refers, they appear to make NAT more restrictive, not less, so its unclear why there might be security impact. BTW, small typo: "only if packets are to be sen to distinct destination addresses." sen -> sent --001a113ff32854b9ec052bce5f96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Resending to correct address:

I have reviewed this document as part of the securi= ty directorate's ongoing effort to review all IETF documents being proc= essed by the IESG. These comments were written primarily for the benefit of= the security area directors. Document editors and WG chairs should treat t= hese comments just like any other last call comments.

Summary: ready w= ith issues

This document updates the behavioural requirements for NAT, = and as noted in the very comprehensive (thankyou!) security considerations = section, =C2=A0introduces at least two requirements that might have securit= y consequences.

The ADs should probably consider whether these new re= quirements are worth the additional risk.

Also, "Hosts which re= quire a=C2=A0restricted filtering behavior should enable security-dedicated= =C2=A0features (e.g., access control list (ACL)) either locally or by=C2=A0= soliciting a dedicated security device (e.g., firewall)." is concernin= g - how will hosts know that they need to update their policies?

"= security-dedicate features" is not very informative - it would be help= ful to explain what new behaviour may need to be counteracted. Looking at s= ections 5 and 6, to which this text refers, they appear to make NAT more re= strictive, not less, so its unclear why there might be security impact.
BTW, smal= l typo: "only if packets are to be sen to distinct destination=C2=A0ad= dresses."
sen -> sent

--001a113ff32854b9ec052bce5f96-- From nobody Mon Feb 15 05:28:55 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19FE1B2EC9; Mon, 15 Feb 2016 05:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.102 X-Spam-Level: X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 ZBqoiJQUr-jA; Mon, 15 Feb 2016 05:28:48 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137961B325E; Mon, 15 Feb 2016 05:28:48 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 38ABE3242EF; Mon, 15 Feb 2016 14:28:46 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 110D827C058; Mon, 15 Feb 2016 14:28:46 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0279.002; Mon, 15 Feb 2016 14:28:45 +0100 From: To: Ben Laurie , The IESG , "secdir@ietf.org" , "draft-ietf-tsvwg-behave-requirements-update.all@tools.ietf.org" Thread-Topic: Security review of draft-ietf-tsvwg-behave-requirements-update-06 Thread-Index: AQHRZ+6YVmjLE+hYIUaR5uBFpHiQ7p8tD9Ng Date: Mon, 15 Feb 2016 13:28:45 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008CE2A9E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008CE2A9EOPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.8.153315 Archived-At: Subject: Re: [secdir] Security review of draft-ietf-tsvwg-behave-requirements-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 13:28:50 -0000 --_000_787AE7BB302AE849A7480A190F8B933008CE2A9EOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBCZW4sDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4NCg0KUGxlYXNlIHNlZSBpbmxp bmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IEJlbiBMYXVyaWUgW21haWx0bzpiZW5sQGdvb2ds ZS5jb21dDQpFbnZvecOpIDogbHVuZGkgMTUgZsOpdnJpZXIgMjAxNiAxMzo0NA0Kw4AgOiBUaGUg SUVTRzsgc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLXRzdndnLWJlaGF2ZS1yZXF1aXJlbWVu dHMtdXBkYXRlLmFsbEB0b29scy5pZXRmLm9yZw0KT2JqZXQgOiBSZTogU2VjdXJpdHkgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtdHN2d2ctYmVoYXZlLXJlcXVpcmVtZW50cy11cGRhdGUtMDYNCg0KUmVz ZW5kaW5nIHRvIGNvcnJlY3QgYWRkcmVzczoNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1l bnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0 byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4g VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2Yg dGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFp cnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBj YWxsIGNvbW1lbnRzLg0KDQpTdW1tYXJ5OiByZWFkeSB3aXRoIGlzc3Vlcw0KDQpUaGlzIGRvY3Vt ZW50IHVwZGF0ZXMgdGhlIGJlaGF2aW91cmFsIHJlcXVpcmVtZW50cyBmb3IgTkFULCBhbmQgYXMg bm90ZWQgaW4gdGhlIHZlcnkgY29tcHJlaGVuc2l2ZSAodGhhbmt5b3UhKSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBzZWN0aW9uLCAgaW50cm9kdWNlcyBhdCBsZWFzdCB0d28gcmVxdWlyZW1lbnRz IHRoYXQgbWlnaHQgaGF2ZSBzZWN1cml0eSBjb25zZXF1ZW5jZXMuDQoNClRoZSBBRHMgc2hvdWxk IHByb2JhYmx5IGNvbnNpZGVyIHdoZXRoZXIgdGhlc2UgbmV3IHJlcXVpcmVtZW50cyBhcmUgd29y dGggdGhlIGFkZGl0aW9uYWwgcmlzay4NCg0KQWxzbywgIkhvc3RzIHdoaWNoIHJlcXVpcmUgYSBy ZXN0cmljdGVkIGZpbHRlcmluZyBiZWhhdmlvciBzaG91bGQgZW5hYmxlIHNlY3VyaXR5LWRlZGlj YXRlZCBmZWF0dXJlcyAoZS5nLiwgYWNjZXNzIGNvbnRyb2wgbGlzdCAoQUNMKSkgZWl0aGVyIGxv Y2FsbHkgb3IgYnkgc29saWNpdGluZyBhIGRlZGljYXRlZCBzZWN1cml0eSBkZXZpY2UgKGUuZy4s IGZpcmV3YWxsKS4iIGlzIGNvbmNlcm5pbmcgLSBob3cgd2lsbCBob3N0cyBrbm93IHRoYXQgdGhl eSBuZWVkIHRvIHVwZGF0ZSB0aGVpciBwb2xpY2llcz8NCg0KW01lZF0gVGhlIHRleHQgZG9lcyBu b3QgZGlzY3VzcyB0aGlzIHBvaW50IGJlY2F1c2UgaXQgaXMgaW1wbGVtZW50YXRpb24gYW5kIGRl cGxveW1lbnQtc3BlY2lmaWMuIFRoaXMgY2FuIGJlLCBmb3IgZXhhbXBsZSwgc2V0IGJ5IGFuIGFw cGxpY2F0aW9uLCBhIHVzZXIsIGEgZ2xvYmFsIHN5c3RlbSBwYXJhbWV0ZXIsIGV0Yy4gV2UgY2Fu IGFkZCB0aGlzIE5FVyBzZW50ZW5jZSBpZiB5b3UgdGhpbmsgaXQgaXMgaGVscGZ1bDoNCg0KTkVX Og0KSG93IGEgaG9zdCB1cGRhdGVzIGl0cyBmaWx0ZXJpbmcgaXMgaW1wbGVtZW50YXRpb24tc3Bl Y2lmaWMuDQoNCiJzZWN1cml0eS1kZWRpY2F0ZSBmZWF0dXJlcyIgaXMgbm90IHZlcnkgaW5mb3Jt YXRpdmUgLSBpdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGV4cGxhaW4gd2hhdCBuZXcgYmVoYXZpb3Vy IG1heSBuZWVkIHRvIGJlIGNvdW50ZXJhY3RlZC4gTG9va2luZyBhdCBzZWN0aW9ucyA1IGFuZCA2 LCB0byB3aGljaCB0aGlzIHRleHQgcmVmZXJzLCB0aGV5IGFwcGVhciB0byBtYWtlIE5BVCBtb3Jl IHJlc3RyaWN0aXZlLCBub3QgbGVzcywgc28gaXRzIHVuY2xlYXIgd2h5IHRoZXJlIG1pZ2h0IGJl IHNlY3VyaXR5IGltcGFjdC4NCg0KW01lZF0gSXQgaXMgdHJ1ZSB0aGF0IHRoZSB1cGRhdGUgaW4g dGhpcyBkcmFmdCBpcyBtb3JlIHJlc3RyaWN0aXZlIGNvbXBhcmVkIHRvIFJGQzQ3ODcgYnV0IHN0 aWxsIHRoaXMgaXMgRUlGLiBCZWNhdXNlIHNvbWUgbWF5IGFyZ3VlIGZpbHRlcmluZyBpcyBkZXNp cmVkLCBob3N0cyB0aGF0IG5lZWQgbW9yZSByZXN0cmljdGVkIGZpbHRlcmluZyBzaG91bGQgZW5m b3JjZSBzb21lIHBvbGljaWVzIGVpdGhlciBsb2NhbGx5IG9yIGJ5IGludGVyYWN0aW5nIHdpdGgg YW4gaW4tcGF0aCBkZXZpY2UuIFdoYXQgYWJvdXQgY2hhbmdpbmcg4oCcc2VjdXJpdHktZGVkaWNh dGVkIGZlYXR1cmVz4oCdIHRvIOKAnGRlZGljYXRlZCBwb2xpY2llc+KAnT8NCg0KQlRXLCBzbWFs bCB0eXBvOiAib25seSBpZiBwYWNrZXRzIGFyZSB0byBiZSBzZW4gdG8gZGlzdGluY3QgZGVzdGlu YXRpb24gYWRkcmVzc2VzLiINCnNlbiAtPiBzZW50DQpbTWVkXSBUaGFuayB5b3UgZm9yIGNhdGNo aW5nIGl0LiBGaXhlZCBpbiBteSBsb2NhbCBjb3B5Lg0KDQo= --_000_787AE7BB302AE849A7480A190F8B933008CE2A9EOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5EZWFy IEJlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UgZm9y IHRoZSByZXZpZXcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+UGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJlbiBMYXVyaWUgW21haWx0 bzpiZW5sQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbHVuZGkgMTUg ZsOpdnJpZXIgMjAxNiAxMzo0NDxicj4NCjxiPsOAJm5ic3A7OjwvYj4gVGhlIElFU0c7IHNlY2Rp ckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi10c3Z3Zy1iZWhhdmUtcmVxdWlyZW1lbnRzLXVwZGF0ZS5h bGxAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBTZWN1cml0eSBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi10c3Z3Zy1iZWhhdmUtcmVxdWlyZW1lbnRzLXVwZGF0ZS0wNjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXNl bmRpbmcgdG8gY29ycmVjdCBhZGRyZXNzOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+SSBoYXZlIHJldmll d2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBv bmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3Nl ZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3Ig dGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5DQogYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVk aXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtl IGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlN1bW1hcnk6IHJlYWR5IHdpdGgg aXNzdWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdCI+VGhpcyBkb2N1bWVudCB1cGRhdGVzIHRoZSBiZWhhdmlvdXJh bCByZXF1aXJlbWVudHMgZm9yIE5BVCwgYW5kIGFzIG5vdGVkIGluIHRoZSB2ZXJ5IGNvbXByZWhl bnNpdmUgKHRoYW5reW91ISkgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiwgJm5ic3A7 aW50cm9kdWNlcyBhdCBsZWFzdCB0d28gcmVxdWlyZW1lbnRzIHRoYXQgbWlnaHQgaGF2ZSBzZWN1 cml0eQ0KIGNvbnNlcXVlbmNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5UaGUgQURzIHNob3VsZCBwcm9iYWJs eSBjb25zaWRlciB3aGV0aGVyIHRoZXNlIG5ldyByZXF1aXJlbWVudHMgYXJlIHdvcnRoIHRoZSBh ZGRpdGlvbmFsIHJpc2suPGJyPg0KPGJyPg0KQWxzbywgJnF1b3Q7SG9zdHMgd2hpY2ggcmVxdWly ZSBhJm5ic3A7cmVzdHJpY3RlZCBmaWx0ZXJpbmcgYmVoYXZpb3Igc2hvdWxkIGVuYWJsZSBzZWN1 cml0eS1kZWRpY2F0ZWQmbmJzcDtmZWF0dXJlcyAoZS5nLiwgYWNjZXNzIGNvbnRyb2wgbGlzdCAo QUNMKSkgZWl0aGVyIGxvY2FsbHkgb3IgYnkmbmJzcDtzb2xpY2l0aW5nIGEgZGVkaWNhdGVkIHNl Y3VyaXR5IGRldmljZSAoZS5nLiwgZmlyZXdhbGwpLiZxdW90OyBpcyBjb25jZXJuaW5nIC0gaG93 IHdpbGwgaG9zdHMga25vdyB0aGF0IHRoZXkNCiBuZWVkIHRvIHVwZGF0ZSB0aGVpciBwb2xpY2ll cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01l ZF0gVGhlIHRleHQgZG9lcyBub3QgZGlzY3VzcyB0aGlzIHBvaW50IGJlY2F1c2UgaXQgaXMgaW1w bGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQtc3BlY2lmaWMuIFRoaXMgY2FuIGJlLCBmb3IgZXhh bXBsZSwgc2V0IGJ5IGFuIGFwcGxpY2F0aW9uLCBhIHVzZXIsDQogYSBnbG9iYWwgc3lzdGVtIHBh cmFtZXRlciwgZXRjLiBXZSBjYW4gYWRkIHRoaXMgTkVXIHNlbnRlbmNlIGlmIHlvdSB0aGluayBp dCBpcyBoZWxwZnVsOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPk5FVzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhvdyBhIGhvc3QgdXBkYXRlcyBp dHMgZmlsdGVyaW5nIGlzIGltcGxlbWVudGF0aW9uLXNwZWNpZmljLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij4mcXVvdDtzZWN1cml0eS1kZWRpY2F0ZSBmZWF0dXJl cyZxdW90OyBpcyBub3QgdmVyeSBpbmZvcm1hdGl2ZSAtIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8g ZXhwbGFpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPm4gd2hhdCBuZXcgYmVo YXZpb3VyIG1heSBuZWVkIHRvIGJlIGNvdW50ZXJhY3RlZC4gTG9va2luZyBhdCBzZWN0aW9ucyA1 DQogYW5kIDYsIHRvIHdoaWNoIHRoaXMgdGV4dCByZWZlcnMsIHRoZXkgYXBwZWFyIHRvIG1ha2Ug TkFUIG1vcmUgcmVzdHJpY3RpdmUsIG5vdCBsZXNzLCBzbyBpdHMgdW5jbGVhciB3aHkgdGhlcmUg bWlnaHQgYmUgc2VjdXJpdHkgaW1wYWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBJdCBpcyB0cnVlIHRoYXQgdGhlIHVwZGF0ZSBpbiB0 aGlzIGRyYWZ0IGlzIG1vcmUgcmVzdHJpY3RpdmUgY29tcGFyZWQgdG8gUkZDNDc4NyBidXQgc3Rp bGwgdGhpcyBpcyBFSUYuIEJlY2F1c2Ugc29tZSBtYXkgYXJndWUgZmlsdGVyaW5nIGlzIGRlc2ly ZWQsDQogaG9zdHMgdGhhdCBuZWVkIG1vcmUgcmVzdHJpY3RlZCBmaWx0ZXJpbmcgc2hvdWxkIGVu Zm9yY2Ugc29tZSBwb2xpY2llcyBlaXRoZXIgbG9jYWxseSBvciBieSBpbnRlcmFjdGluZyB3aXRo IGFuIGluLXBhdGggZGV2aWNlLiBXaGF0IGFib3V0IGNoYW5naW5nIOKAnHNlY3VyaXR5LWRlZGlj YXRlZCBmZWF0dXJlc+KAnSB0byDigJxkZWRpY2F0ZWQgcG9saWNpZXPigJ0/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PGJyPg0KQlRXLCBzbWFsbCB0eXBvOiAmcXVvdDtv bmx5IGlmIHBhY2tldHMgYXJlIHRvIGJlIHNlbiB0byBkaXN0aW5jdCBkZXN0aW5hdGlvbiZuYnNw O2FkZHJlc3Nlcy4mcXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+c2VuIC0mZ3Q7IHNlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPltNZWRdIFRoYW5rIHlvdSBmb3IgY2F0Y2hpbmcgaXQuIEZpeGVkIGluIG15IGxvY2FsIGNv cHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933008CE2A9EOPEXCLILMA3corp_-- From nobody Mon Feb 15 07:34:10 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2851A1BC8; Mon, 15 Feb 2016 07:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 sEaAr_4rJL3C; Mon, 15 Feb 2016 07:31:34 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8703A1A886B; Mon, 15 Feb 2016 07:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3480; q=dns/txt; s=iport; t=1455550294; x=1456759894; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Fhph6fnQC9wJameTbdlIxLHgilDPfJO6LiGLqd/0jNU=; b=XxTMrg7dSyV4N/KFsYGstPByzoHeFeB1Gp/K4qAG6yERBKYwnuJKKiAE 3RG5Agvt9zch7/C9DEnob+cyGd7vc07rzXk0ZvcaOnHVzMuw4iZH21YPu djaKSY/3RDBoIHD+gkK+SwUnaw4MkAHqdHBMb4Xecf5sdmwZmORg+2aMw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQD87cFW/4UNJK1eDoMsgT8GuhcBD?= =?us-ascii?q?YFnhg0CgTI4FAEBAQEBAQGBCoRBAQEBBIEFBAIBCA4DAwECAS4yHQgCBAESiBq?= =?us-ascii?q?8ZQEBAQEBAQEBAgEBAQEBAQEBGIpGhBqEUgWNX4kaAY1UgVyEQ4hVjj0BHgEBQ?= =?us-ascii?q?oICGYENO2oBh3t8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,450,1449532800"; d="scan'208";a="237999114" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Feb 2016 15:31:33 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u1FFVXWo012758 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Feb 2016 15:31:33 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 15 Feb 2016 09:31:32 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Mon, 15 Feb 2016 09:31:32 -0600 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , David Mandelberg , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-siprec-metadata.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-siprec-metadata-20 Thread-Index: AQHRZ2skqSwwLW3R3kyyH9ELbM/sWJ8s9nKAgAEJsIA= Date: Mon, 15 Feb 2016 15:31:32 +0000 Message-ID: References: <56C0EB89.4050409@mandelberg.org> <56C15FB9.8030600@alum.mit.edu> In-Reply-To: <56C15FB9.8030600@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.58.123] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0449F8EF2714C84CB2B4F30A6A38E521@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 15 Feb 2016 07:34:03 -0800 Subject: Re: [secdir] secdir review of draft-ietf-siprec-metadata-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 15:31:36 -0000 I agree with all of Paul's responses. One more point to add to Paul=B9s response- 1) If two SRCs use the same UUID (because they intentionally choose to do so ) it MUST retain the UUID/object mapping. In other words, if UUID 1 was referring =B3participant-1" object in RS1 by SRC1, the same UUID1 can be used by other SRCs to only refer Participant-1 and not any other objects. If it was not clear from the draft we can add a line in draft to the effect of - " If multiple SRCs use the same UUID it MUST ensure a UUID is always mapped to same object across all Recording Sessions". Regards, Ram -----Original Message----- From: Paul Kyzivat Date: Monday, 15 February 2016 at 10:48 AM To: David Mandelberg , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-siprec-metadata.all@tools.ietf.org" Subject: Re: secdir review of draft-ietf-siprec-metadata-20 Resent-From: Resent-To: Resent-Date: Monday, 15 February 2016 at 10:48 AM >David, > >Thank you for the review. I will try to respond. (Note that I haven't >consulted with the other authors on this response, so they may have >something else to say.) Please see inline below. > >On 2/14/16 4:03 PM, David Mandelberg 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. >> >> This document specifies a metadata format for information about recorded >> SIP sessions. The Security Considerations section has good text about >> the protection of metadata in this format, but I found one potential >> security issue with the way an SRS (server) is supposed to handle the >> metadata. I think this draft is ready with issues. >> >> Section 6.10 says that "multiple SRC's [clients] can refer to the same >> element/UUID (how each SRC learns the UUID here is out of scope of >> SIPREC)". But what happens if two clients try to define different >> objects with the same UUID? Does one of the objects take precedence for >> all clients? If all of the benign clients are relying on referencing an >> object A with UUID 1, and a malicious client is able to send an object B >> also with UUID 1, that might compromise the integrity of the metadata >> sent by the benign clients. This could be mitigated by requiring that >> UUIDs are generated (pseudo-)randomly and are kept confidential from >> potential adversaries, but I don't think the draft says either of these >> things. > >The UUIDs used in the metadata are intended to be *unique*. Distinct >SRCs that construct new UUIDs are expected to follow the rules for >constructing them so that they are indeed unique. > >If two SRCs use the same UUID it will be because they intentionally >choose to do so. Typically this will be by some back channel to >communicate among themselves. (I suppose there could potentially be some >algorithmic way for them to construct UUIDs in a coordinated way, but I >won't speculate on that.) > >By design there should be no accidental reuse of UUIDs. > > Thanks, > Paul > From nobody Mon Feb 15 13:31:25 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137691B2B03; Mon, 15 Feb 2016 13:28:44 -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 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 mi_c9jm9uX_H; Mon, 15 Feb 2016 13:28:42 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 D36D01B2BD4; Mon, 15 Feb 2016 13:28:42 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id c10so94655135pfc.2; Mon, 15 Feb 2016 13:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LupS4zewfpF9HRjDO17A4DSSouRt/d1vMe+eAImhiMg=; b=j08Bfg3ZGj1mpdkCL02Wbz/jtNG3MC4swNmXHaR3js2i5S+DSI1/EEcV720fstAQed pmItT9+RdCIfvG8oCx4r9RLYN7F039NqC7dmlo+klHx6bR5L9+hlsadF0ZqjqtB/BUtw 5lTv9/EhPwXMfzwuMPJXOD4ZdZSlO0FZsOOogDtM7mxwh84xoTC4VyYqDl3XecQ4YFsR yZoT8nSalJLuwGjErHSaUkV6FzrE8u3EUb33h4EMg5RcjQlHm3RcpsKnB1RTXhNgfEEB DHvka7ttRr7o876GNmm65tgBh0X0uKf4wBV8Smq1mZt1BkNRVf3pLC0cUdOZ6j32uYKw uNJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=LupS4zewfpF9HRjDO17A4DSSouRt/d1vMe+eAImhiMg=; b=KpY7oNGja5B0yhgZ7wMCdFtapo97HIgYss6EAhQW03gg52yQHwImL0EgPllKLdRHzH YldnUD5ZEYhj7dOGLfF7y4krNc0pBCks4W1qzRFOehCHYUlJcVVUEsEAcpS3Jio+YmaB XIytOnyQmTKEtadXvWYQ3asZ5Gggnwq0tt7szd2HMzBEQqwMcYs/qNtSvqP1zSfzkOdc Pqd5N97ko5athCAm750D1mlM3samzQpuS/nbztvyYok8cFKjkC6PDAyA77Skllevikqj 0KgPwE57gGfYCx9v7yrdnaCSj0dMvbYGGYyrLm7ILiBZfvTVc2QztuhiotuJS4nJmI1M KL1g== X-Gm-Message-State: AG10YOSxiO2PG/v/7A1xOxcu/CLlgCTuRQkU8zydAnEZKpt/imCScqrE3A5XHIG5AKI8GQ== X-Received: by 10.98.10.86 with SMTP id s83mr26380342pfi.85.1455571722499; Mon, 15 Feb 2016 13:28:42 -0800 (PST) Received: from dhcp-171-71-145-33.cisco.com (dhcp-171-71-145-33.cisco.com. [171.71.145.33]) by smtp.gmail.com with ESMTPSA id y11sm40568509pfa.85.2016.02.15.13.28.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Feb 2016 13:28:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mahesh Jethanandani In-Reply-To: Date: Mon, 15 Feb 2016 13:28:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> References: To: Tom Yu X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Mon, 15 Feb 2016 13:31:22 -0800 Cc: draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 21:28:44 -0000 Tom, It is not entirely clear from this e-mail, what action you want the = authors to take.=20 YANG module information or more like its encodings are sent over a = secure session (SSH/TLS) and are no more specific to this draft than = they are to any NETCONF/RESTCONF session. As such it is not clear what = you want the authors to do. Could you clarify or provide text for the = Security Consideration section? Thanks. > On Feb 1, 2016, at 6:03 PM, Tom Yu wrote: >=20 > I have reviewed this document as part of the security directorate's=20 > ongoing effort to review all IETF documents being processed by the=20 > IESG. These comments were written primarily for the benefit of the=20 > security area directors. Document editors and WG chairs should treat=20= > these comments just like any other last call comments. >=20 > The Security Considerations of this document seem reasonable. It = might > be useful to add a comparison of the risks posed by sensitive > information exposed by this YANG module with information exposed by > other aspects of NETCONF, or available through methods such as > fingerprinting. Admittedly, a meaningful comparison might be highly > context-specific, so a general comparison might have limited utility. Mahesh Jethanandani mjethanandani@gmail.com From nobody Tue Feb 16 09:36:26 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 6E9C71ACEB3; Tue, 16 Feb 2016 09:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1455643935; bh=BzK4ZcffobqzJwBm6YMI0fWsPauv69CibgnAvDKnddo=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=Fmspgen8UbBaV700QWIo9OFlqo2Hk0oUQ4dqcdM1GueHsURJVwkAZwuYnMbCV/o40 1q0ydZjCGw2XXDuOzgwx+YlRYXCoBFr/lLktZUtyGsR6sUZIQjNxSrSvV+Mk0IZOWk 3ZV6Ts9yuUY1FUaYkR2YkpufCrfpxbwHzqIA6bbQ= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D43B1ACE74 for ; Tue, 16 Feb 2016 09:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.793 X-Spam-Level: X-Spam-Status: No, score=0.793 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001] autolearn=ham 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 UM7rqcif6rdY for ; Tue, 16 Feb 2016 09:32:12 -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 4BF981ACE2D for ; Tue, 16 Feb 2016 09:32:12 -0800 (PST) Received: from [2a01:e35:8ad2:1c30:752f:88e:6c27:2aff] (helo=gillie.local) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aVjTt-000G1S-Qf for new-work@ietf.org; Tue, 16 Feb 2016 17:32:10 +0000 To: new-work@ietf.org Date: Tue, 16 Feb 2016 18:32:08 +0100 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 16 Feb 2016 09:36:24 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: TV Control Working Group (until 2016-03-18) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 17:32:15 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBUViBDb250 cm9sIFdvcmtpbmcgR3JvdXA6CiAgIGh0dHBzOi8vd3d3LnczLm9yZy8yMDE2LzAyL3R2Y29udHJv bC5odG1sCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRoYXQgdGhlIGNvbW11bml0eSBpcyBhd2FyZSBv ZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBkcmFmdCBjaGFydGVyIGlzIHB1YmxpYyBkdXJp bmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZpZXcgcGVyaW9kLgoKVzNDIGludml0ZXMgcHVi bGljIGNvbW1lbnRzIHRocm91Z2ggMjAxNi0wMy0xOCBvbiB0aGUKcHJvcG9zZWQgY2hhcnRlci4g UGxlYXNlIHNlbmQgY29tbWVudHMgdG8KcHVibGljLW5ldy13b3JrQHczLm9yZywgd2hpY2ggaGFz IGEgcHVibGljIGFyY2hpdmU6CiAgIGh0dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGlj L3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4gY29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVz cG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fu bm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNvbW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBX M0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5hdGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIg QWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3 aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZpYSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBB ZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3Ig aGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpJZiB5b3Ugc2hvdWxkIGhhdmUgYW55IHF1ZXN0 aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIHBsZWFzZQpjb250YWN0IEZyYW7Dp29p cyBEYW91c3QsIFN0YWZmIENvbnRhY3QgPGZkQHczLm9yZz4uCgpUaGFuayB5b3UsCgpDb3JhbGll IE1lcmNpZXIsIEhlYWQgb2YgVzNDIE1hcmtldGluZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0 cDovL3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1iZXIvTGlzdAoKLS0gCkNvcmFsaWUgTWVyY2ll ciAgLSAgVzNDIE1hcmtldGluZyAmIENvbW11bmljYXRpb25zIC0gIGh0dHA6Ly93d3cudzMub3Jn Cm1haWx0bzpjb3JhbGllQHczLm9yZyArMzM2IDQzMjIgMDAwMSBodHRwOi8vd3d3LnczLm9yZy9Q ZW9wbGUvQ01lcmNpZXIvCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpuZXctd29yayBtYWlsaW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yawo= From nobody Wed Feb 17 09:54:40 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DB11AD376 for ; Wed, 17 Feb 2016 09:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 jUQ-im49sZeD for ; Wed, 17 Feb 2016 09:54:34 -0800 (PST) Received: from nm23-vm9.access.bullet.mail.bf1.yahoo.com (nm23-vm9.access.bullet.mail.bf1.yahoo.com [216.109.115.168]) (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 2C57D1ADBF8 for ; Wed, 17 Feb 2016 09:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1455731672; bh=fRiBFqUTeDUWrrPV5ybPvOAyhd5cg5SPYQYeUcBagA4=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=ACcxFMxljLcRPUTympNKQ0vgpfjT/H/2/dXvuHexJrRadRG5nDnfEdCm9VsR7EmyUSr3BG9SIaI8rISruuhTbIz4ASbL58HeYnJSxit8Ls2t0CBT/KJJ5foBLskB/YI37Ob11ZTFfLe2meVHI/3ZLMMDERgR+sUnujOygJgIM1T41B2K42ShLprpTJoE0igo7wObrkekYnvclzLxcv8Oi86qcaAs8ZzooEKfrIp3yVDGkIaJX4z4NMQEqJXBU0WhTmEQyfQh+NYEr0Bkd70LY9bYUd/vx71AUqe62Wd+1J3YFgqPY39r9vXI+4+uGGcZnOGpGCV9rM+o2lgkQkHrtQ== Received: from [66.196.81.166] by nm23.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2016 17:54:32 -0000 Received: from [98.138.104.99] by tm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2016 17:54:32 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 17 Feb 2016 17:54:32 -0000 X-Yahoo-Newman-Id: 637618.23535.bm@smtp119.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: IflOqHAVM1kG1eeFkmsIRe1VkDm6ZUAFPnGZKBf52BNF7VW O4.u9AqyJtnuItlv0SR5oRKnthD.t.pNWNvOnPzqfkziuGE8cGatQm9HxMsg CA7jiuGiVMB2haEDZJ5f6EqX00ZUaxMzkYp3fuUk4mdBvpDk3ZREQozLQhKX jE6vVPJ.vin2GgwkdcLd1Kuw15_s.A7Sua1ub6aRWOfUYaxmGRhcq7KdUu45 Hy_keLxZcW2B0WoCvIDXtzue4TzPBeVLBjDX4ou9uLaJ1dX.tFbRvTlq1CLR z0vjQ7d4l5CIepitGKSV_jUHgEjiR87GR44ylwdTKurfh5mY4VsaepYs9ZlB KMxx66EZYewI1bdgPTHAMi2PbWKgKxq4KchLg7iY0tsc1VDpmemonvX89UtK s8haGxzx_711yWSi8kra53w54Ke4lwy4i4Kw2mC_S3Z3ks5PMA6s6CSLhaWR 01xx5rWWcvU68RVmLrf9mK7i4w2JHeaeh5wBAKX6100hlmA9fMkmO8vuXcP1 3_J7X.VA0SWFgsJLkE4yvZsho_lQGwpTqfaraLg-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.16] (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 094A11C6031; Wed, 17 Feb 2016 12:54:31 -0500 (EST) To: Paul Kyzivat , iesg@ietf.org, secdir@ietf.org, draft-ietf-siprec-metadata.all@tools.ietf.org References: <56C0EB89.4050409@mandelberg.org> <56C15FB9.8030600@alum.mit.edu> From: David Mandelberg X-Enigmail-Draft-Status: N1110 Message-ID: <56C4B3D6.6040700@mandelberg.org> Date: Wed, 17 Feb 2016 12:54:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C15FB9.8030600@alum.mit.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CJVROEBCm6qceXRbrfDnG2mTUOjNxhlVN" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-siprec-metadata-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 17:54:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CJVROEBCm6qceXRbrfDnG2mTUOjNxhlVN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/15/2016 12:18 AM, Paul Kyzivat wrote: > On 2/14/16 4:03 PM, David Mandelberg wrote: >> Section 6.10 says that "multiple SRC's [clients] can refer to the same= >> element/UUID (how each SRC learns the UUID here is out of scope of >> SIPREC)". But what happens if two clients try to define different >> objects with the same UUID? Does one of the objects take precedence fo= r >> all clients? If all of the benign clients are relying on referencing a= n >> object A with UUID 1, and a malicious client is able to send an object= B >> also with UUID 1, that might compromise the integrity of the metadata >> sent by the benign clients. This could be mitigated by requiring that >> UUIDs are generated (pseudo-)randomly and are kept confidential from >> potential adversaries, but I don't think the draft says either of thes= e >> things. >=20 > The UUIDs used in the metadata are intended to be *unique*. Distinct > SRCs that construct new UUIDs are expected to follow the rules for > constructing them so that they are indeed unique. Yes, but a malicious SRC probably won't do what you're expecting of a benign SRC. I agree that the text in the draft is good *if* it were true that all SRCs are benign. > If two SRCs use the same UUID it will be because they intentionally > choose to do so. Or because the malicious SRC is intentionally choosing to do so, without permission or cooperation from the benign SRC. > Typically this will be by some back channel to > communicate among themselves. (I suppose there could potentially be som= e > algorithmic way for them to construct UUIDs in a coordinated way, but I= > won't speculate on that.) >=20 > By design there should be no accidental reuse of UUIDs. I agree. I'm worried only about malicious reuse of UUIDs. >=20 > Thanks, > Paul >=20 --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --CJVROEBCm6qceXRbrfDnG2mTUOjNxhlVN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlbEs9YACgkQRKlmUHCg4sCICgCfY49pgv+weUghlyZcWtikdnd0 8coAn2EwhF9koenyl70KkBrKRjik+Yrk =r2vD -----END PGP SIGNATURE----- --CJVROEBCm6qceXRbrfDnG2mTUOjNxhlVN-- From nobody Wed Feb 17 09:58:46 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743CB1B2A38 for ; Wed, 17 Feb 2016 09:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 fO0ZIOk6nYDC for ; Wed, 17 Feb 2016 09:58:41 -0800 (PST) Received: from nm13-vm5.access.bullet.mail.bf1.yahoo.com (nm13-vm5.access.bullet.mail.bf1.yahoo.com [216.109.115.5]) (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 39C721B2A3C for ; Wed, 17 Feb 2016 09:58:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1455731919; bh=PVUsLDm4LZU518xqZPuWdtI7ubLmF/RoEJrsXjp4JvI=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=ET9oTMjl6ULIaRN959OxiM3IjL75Wq69DvipGpYbHem8gxJqjamXsgNFZ8e3FMheUcNjGflYlg2GLALGPQTbzo6jfxb5+BQodznhU7kyf+3H8jvmO15I9pJH+1MjD7ot2timjdfil7ztqro1MRG2m6fIroS/Z4nlcDbgnz2ncl2MHIewvPA6OKhnJ67IaYV5LBKZgJG/Sebb/HAj/XNRimkE+QaZwZOzxEw2UKkwqkMaDk3zsbTfN1llCCrIDygDvxjZ5w33U7vq3h5MZXmTwsy0yYBqJq0gfeO28mX8BDr39V5HR9ei7ggLe1F8snni8MzinHqDe8HWLbPKzdDa+Q== Received: from [66.196.81.162] by nm13.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2016 17:58:39 -0000 Received: from [98.138.104.97] by tm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2016 17:58:39 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 17 Feb 2016 17:58:39 -0000 X-Yahoo-Newman-Id: 714591.38059.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: U6OUzr8VM1lOl3536U2Ka_4AZscbTTn0OObZQHRnxB1.GAk ZZAMjxMJdNedM4Aq0NiajTVDtQvjxlm1bnESkGCdpZlw4i8YAWkgY6BPxLZm nbrojgcbnQma8JKpcSuJTZTP9BtbAJoQP3LrykIqzrqCbTKmpgS0h66c2dG1 r1aDdeMewc1g0Ps8fxlSgAVQ7wgtrlKac5XfwBEN5c83NXl.v2MnpmHQYGdC myTqt657_OAk9Ywi9iwpZDaexOfoZWiP6XMZt9NTmKl7W.WuFCjU7s4Q_S5U j_82pKzMWtE6sLhl2Qgx_rjZU13AO3U0E7_7lXPc1sT3BXw9JlEuOotvWNzk tEIFpG0Mhv1iO85dGLsgWnKio.RabMINPslCb0VjiiHi500lnJWbPmSLpp0h RKxHJCX.K6bGykZjPNhlD.l9781b9WDic7k1idguA2BQ5lQCRsLK03CD7CLU 49As8EZ71IgsNiA5g2aqh1DPoxiO8Y.Y922DddRrfo5rrigN1.03bqW6rTmm sh8uJfSAvZCtCxPu4usB1GUfvRve2Mtjr2iH2EQ-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.16] (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id A2E111C6031; Wed, 17 Feb 2016 12:58:37 -0500 (EST) To: "Ram Mohan R (rmohanr)" , Paul Kyzivat , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-siprec-metadata.all@tools.ietf.org" References: <56C0EB89.4050409@mandelberg.org> <56C15FB9.8030600@alum.mit.edu> From: David Mandelberg Message-ID: <56C4B4CD.7080901@mandelberg.org> Date: Wed, 17 Feb 2016 12:58:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kn71wBm2rwasDjws6PlrpWc9cLV9b5drx" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-siprec-metadata-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 17:58:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kn71wBm2rwasDjws6PlrpWc9cLV9b5drx Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/15/2016 10:31 AM, Ram Mohan R (rmohanr) wrote: > I agree with all of Paul's responses. One more point to add to Paul=B9s= > response- > 1) If two SRCs use the same UUID (because they intentionally > choose to do so ) it MUST retain the UUID/object mapping. In > other words, if UUID 1 was referring =B3participant-1" object in RS1 by= > SRC1, the same UUID1 can be used by other SRCs to only refer > Participant-1 and not any other objects. >=20 > If it was not clear from the draft we can add a line in draft to the > effect of - " If multiple SRCs use > the same UUID it MUST ensure a UUID is always mapped to same object acr= oss > all Recording Sessions". It was clear to me that this was the intent. My question was about what happens when a single malicious SRC violates this by introducing a new object with an existing UUID. I don't think the draft specifies how the SRS behaves in this case, nor does it say anything to prevent a malicious SRC from being able to do this. >=20 > Regards, > Ram --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --kn71wBm2rwasDjws6PlrpWc9cLV9b5drx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlbEtM0ACgkQRKlmUHCg4sDUkwCfbcWHSKGCZoGLcYnJDRklb4nm tt4Anieb+ClhOK1dao74bzgSVLqbNUZ6 =Gpq7 -----END PGP SIGNATURE----- --kn71wBm2rwasDjws6PlrpWc9cLV9b5drx-- From nobody Wed Feb 17 10:23:29 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F791B2B19 for ; Wed, 17 Feb 2016 10:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 PYuadCfVGVh2 for ; Wed, 17 Feb 2016 10:23:23 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42CA61B2AFD for ; Wed, 17 Feb 2016 10:23:23 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-04v.sys.comcast.net with comcast id KWMH1s0032EPM3101WPNsY; Wed, 17 Feb 2016 18:23:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-07v.sys.comcast.net with comcast id KWPM1s0013KdFy101WPMiN; Wed, 17 Feb 2016 18:23:22 +0000 To: David Mandelberg , iesg@ietf.org, secdir@ietf.org, draft-ietf-siprec-metadata.all@tools.ietf.org References: <56C0EB89.4050409@mandelberg.org> <56C15FB9.8030600@alum.mit.edu> <56C4B3D6.6040700@mandelberg.org> From: Paul Kyzivat Message-ID: <56C4BA98.3080001@alum.mit.edu> Date: Wed, 17 Feb 2016 13:23:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56C4B3D6.6040700@mandelberg.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455733402; bh=9AN0NuOoaBgMVjO+rXjBUeRiVHJRBZwpfOjhSVilqjY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=IF2VZvo/AvlbfPgYwGQ9VU4piCaxCcMR++uxhiZ8gxzG1Pz1O5o76XXzsl/sOrMcJ h/s354AM7QA+fAxf0PjoiXSIEktW+m+ma8CQFOelX85IYsy7flTgzap/5V+zzo0K6f wHYzl1sbNaWJ4+5Dv18lxPudJPii5XP7u2pfNyFLprc4KxeOZAzzwqljMUZWiYq+uN vuO9ytSNPF0S7ZMfcJ24IAya8B8vxyS3kwK2K9+V2c+1DAxsxrijTDZnneGat3X6AZ cXkV48wkUrf+n1s4+zNfe9dq0I/5isjs70o6kR9CrGz7KOx33NzTzNZBubMZXWNvbX gnfWae259VC0A== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-siprec-metadata-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 18:23:24 -0000 David, Comment at end. On 2/17/16 12:54 PM, David Mandelberg wrote: > On 02/15/2016 12:18 AM, Paul Kyzivat wrote: >> On 2/14/16 4:03 PM, David Mandelberg wrote: >>> Section 6.10 says that "multiple SRC's [clients] can refer to the same >>> element/UUID (how each SRC learns the UUID here is out of scope of >>> SIPREC)". But what happens if two clients try to define different >>> objects with the same UUID? Does one of the objects take precedence for >>> all clients? If all of the benign clients are relying on referencing an >>> object A with UUID 1, and a malicious client is able to send an object B >>> also with UUID 1, that might compromise the integrity of the metadata >>> sent by the benign clients. This could be mitigated by requiring that >>> UUIDs are generated (pseudo-)randomly and are kept confidential from >>> potential adversaries, but I don't think the draft says either of these >>> things. >> >> The UUIDs used in the metadata are intended to be *unique*. Distinct >> SRCs that construct new UUIDs are expected to follow the rules for >> constructing them so that they are indeed unique. > > Yes, but a malicious SRC probably won't do what you're expecting of a > benign SRC. I agree that the text in the draft is good *if* it were true > that all SRCs are benign. > > >> If two SRCs use the same UUID it will be because they intentionally >> choose to do so. > > Or because the malicious SRC is intentionally choosing to do so, without > permission or cooperation from the benign SRC. > >> Typically this will be by some back channel to >> communicate among themselves. (I suppose there could potentially be some >> algorithmic way for them to construct UUIDs in a coordinated way, but I >> won't speculate on that.) >> >> By design there should be no accidental reuse of UUIDs. > > I agree. I'm worried only about malicious reuse of UUIDs. So your concern is the security implications when we have a malicious SRC that has been authorized by the SRS? If so, it seems like that can extend to lots of things beyond reuse of UUIDs. (Going further afield, how does this differ from a malicious SIP UA that has the credentials to register a particular AoR? It could cause all sorts of mischief by unregistering valid UAs, etc. ISTM the bottom line is that it is impossible to avoid problems from a party with access to enough "secrets".) But the problem actually seems less severe in the case of SIPREC. The SRS is performing what is essentially an append-only write process. The use of a duplicate UUID by a malicious SRC doesn't cause any valid information to be lost. And the SRS is free to track the source of each piece of information it records, so that the malicious info can be sorted out from the valid info once the bad guy has been identified. We don't put any requirements on *how* and *how much* of the the received info an SRS records, so we don't have a way to discuss this. Thanks, Paul From nobody Wed Feb 17 12:39:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2DC1B2B14 for ; Wed, 17 Feb 2016 12:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 G1ODVFYuuhX7 for ; Wed, 17 Feb 2016 12:39:04 -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 757BF1B2B05 for ; Wed, 17 Feb 2016 12:39:04 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1HKd2XY002257 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 17 Feb 2016 22:39:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1HKd20Z025158; Wed, 17 Feb 2016 22:39:02 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22212.55910.240810.701174@fireball.acr.fi> Date: Wed, 17 Feb 2016 22:39:02 +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.15 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: Wed, 17 Feb 2016 20:39:05 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yoav Nir is next in the rotation. For telechat 2016-02-18 Reviewer LC end Draft Derek Atkins T 2016-01-18 draft-ietf-dnsop-edns-chain-query-06 Tobias Gondrom T 2016-01-27 draft-ietf-codec-oggopus-13 Sam Hartman T 2016-02-04 draft-ietf-dhc-dhcpv6-privacy-04 Simon Josefsson TR2015-12-04 draft-ietf-eppext-tmch-smd-04 Warren Kumari T 2016-02-15 draft-ietf-dhc-anonymity-profile-07 For telechat 2016-03-03 Leif Johansson T 2016-02-10 draft-ietf-dprive-edns0-padding-02 Chris Lonvick T 2016-02-24 draft-ietf-httpbis-alt-svc-12 Sandy Murphy T 2016-03-01 draft-ietf-ntp-checksum-trailer-04 For telechat 2016-03-17 Catherine Meadows T 2016-03-09 draft-martin-urn-globus-02 Last calls and special requests: Donald Eastlake R2016-02-22 draft-ietf-dane-openpgpkey-07 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Jeffrey Hutzelman 2015-12-04 draft-ietf-core-block-18 Chris Inacio 2016-02-02 draft-ietf-v6ops-ipv6-ehs-in-real-world-02 Matt Lepinski 2016-03-09 draft-bao-v6ops-rfc6145bis-05 Alexey Melnikov 2016-03-07 draft-wallace-est-alt-challenge-04 Matthew Miller 2016-02-26 draft-ietf-avtext-splicing-notification-04 Adam Montville 2016-02-26 draft-ietf-mmusic-proto-iana-registration-05 Eric Osterweil 2016-01-05 draft-campbell-art-rfc5727-update-02 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-12 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-05 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-03 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-06 -- kivinen@iki.fi From nobody Wed Feb 17 13:49:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4441B2F34; Wed, 17 Feb 2016 13:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.008 X-Spam-Level: X-Spam-Status: No, score=-0.008 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 LWXmOLIvvkAa; Wed, 17 Feb 2016 13:49:12 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (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 E1FA91B2F31; Wed, 17 Feb 2016 13:49:06 -0800 (PST) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id u1HLn367017264 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 17 Feb 2016 16:49:03 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_11BF8542-4C35-4518-8182-878E912BD67E" Date: Wed, 17 Feb 2016 16:49:03 -0500 Message-Id: <76C59DBD-5B5E-4976-B574-97ED20287E12@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-martin-urn-globus.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Subject: [secdir] secdir review of draft-martin-urn-globus-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 21:49:19 -0000 --Apple-Mail=_11BF8542-4C35-4518-8182-878E912BD67E Content-Transfer-Encoding: quoted-printable 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. This draftt describes a Uniform Resource Name (URN) namespace that is = used by the Globus software-as-a-service provider for naming persistent resources. The main requirement is that these = identifiers which will persist in external systems, and which must be identifiable as references to Globus entities. The draft specifies = the syntax, and describes mechanisms for enforcing uniqueness. In = particular, URNs may not be reassigned. =20 In the Security Considerations section, the authors refer the reader to = RFC=E2=80=99s 1737 and 2141. The security considerations in RFC 1737 = refer to authentication mechanisms which are outside the scope of the document. The recommendations of RFC = 1737, however, may require more attention. Its Security Considerations = section runs as follows: =20 This document specifies the syntax for URNs. While some namespaces resolvers may assign special meaning to certain of the characters of the Namespace Specific String, any security consideration resulting from such assignment are outside the scope of this document. It is strongly recommended that the process of registering a namespace identifier include any such considerations. The draft does not propose any special meanings for characters in the = Namespace Specific String, but I think it would be good to add a sentence in the Security = Considerations Section mentioning this stipulation, and pointing out that it does not apply in your case because no such = spacial meaning is proposed. I consider this document Ready With Nits. Cathy is being proposed,=20 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil = --Apple-Mail=_11BF8542-4C35-4518-8182-878E912BD67E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; 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.

This draftt describes a Uniform = Resource Name (URN) namespace that is used by the Globus = software-as-a-service provider
for naming = persistent resources.  The main requirement is that these = identifiers which will persist in external systems, and which = must
be identifiable as references to Globus = entities.  The draft specifies the syntax, and describes mechanisms = for enforcing uniqueness.  In particular, URNs
may not be reassigned.  

In the Security Considerations section, = the authors refer the reader to RFC=E2=80=99s 1737 and 2141.  The = security considerations in RFC 1737 refer to authentication = mechanisms
which are outside the scope of the = document.  The recommendations of RFC 1737, however, may require = more attention.  Its Security Considerations section runs as = follows:

 
This document specifies the syntax for = URNs.  While some namespaces
  =  resolvers may assign special meaning to certain of the characters = of
   the Namespace Specific String, any = security consideration resulting
   from = such assignment are outside the scope of this document.  It = is
   strongly recommended that the = process of registering a namespace
  =  identifier include any such considerations.
The draft does not propose any special = meanings for characters in the Namespace Specific String,
but I think it would be good to add a sentence in the = Security Considerations Section mentioning this stipulation,
and pointing out that it does not apply in your case because = no such spacial meaning is proposed.

I consider this document Ready With = Nits.

Cathy

is being proposed, 
Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

= --Apple-Mail=_11BF8542-4C35-4518-8182-878E912BD67E-- From nobody Wed Feb 17 13:54:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CB91B2F69; Wed, 17 Feb 2016 13:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=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 E-oXJKbRUNcT; Wed, 17 Feb 2016 13:54:07 -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 288D01B2F5F; Wed, 17 Feb 2016 13:54:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D3DE0E2036; Wed, 17 Feb 2016 16:53:35 -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 08442-03; Wed, 17 Feb 2016 16:53:32 -0500 (EST) Received: from securerf.ihtfp.org (IHTFP-DHCP-159.IHTFP.ORG [192.168.248.159]) (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 22D47E2030; Wed, 17 Feb 2016 16:53:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1455746012; bh=WGU0CGGxy//+zcrSRUjJe0GZQDDab17t4CHIUQqJVLY=; h=From:To:Cc:Subject:Date; b=XF9oMEa3D7LiUAv5GzqiIlElyKGKACqnnw7O6rAQMu1ScSM5gaxtcMgC0OipOo9Zx iItlWEcaQRPrHot+1AgIrKJPnwZ+wacQhPkbJ5UQJS1XzP3BCUzbIeFJB1bnkqk90J 2yIRvEm/96N86yeN72EyvFUKx/6bvSHMsbTn+9hg= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u1HLrVhq012376; Wed, 17 Feb 2016 16:53:31 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Wed, 17 Feb 2016 16:53:31 -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: pwouters@redhat.com, dnsop-chairs@ietf.org Subject: [secdir] sec-dir review of draft-ietf-dnsop-edns-chain-query-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 21:54:13 -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: Probably ready to publish Details: I noticed that this draft has RFC2119 MUST/MUST NOT directives in the Security Considerations section. However this is not a repetition of similar language elsewhere in the draft. Is this allowed? There is also similar 2119 language in the Introduction. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Feb 18 08:20:41 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0E81B2E61; Thu, 18 Feb 2016 08:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 mN5Mqg6JO0gx; Thu, 18 Feb 2016 08:20:35 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D451B2E4F; Thu, 18 Feb 2016 08:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3061; q=dns/txt; s=iport; t=1455812434; x=1457022034; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=suvd2Yqf8UM1dJtd6c0S8DsGbRPDCcD7T/2ZWz6i9n0=; b=YN4NVPTvwV40+PzXYTaiXHPTweXqmSgFAt5ViA764u3S5hiCwhUaMAg5 OAUwprm55GyqjwtOKWabsZk3XP3TO1BqHq4OTyMU97l226pYb/mucJI+U MPc32x9+9alPhE0RvWKruMNSxOyu7Ds1iRtsN9l1nx51ViaellaM3OfSG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBACz7sVW/xbLJq1ewQ2GDQKCLQEBA?= =?us-ascii?q?QEBAWUnhEIBAQQ4QBELIRYPCQMCAQIBRQYBDAgBAYgWu14BAQEBAQEBAQIBAQE?= =?us-ascii?q?BAQEahhKEO4QdhFIBBJcFjVqBXIRDgwKFUo5HYoNkO4lNAQEB?= X-IronPort-AV: E=Sophos;i="5.22,466,1449532800"; d="scan'208";a="635584835" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Feb 2016 16:20:31 +0000 Received: from [10.61.83.28] (ams3-vpn-dhcp4893.cisco.com [10.61.83.28]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1IGKV7h018214; Thu, 18 Feb 2016 16:20:31 GMT To: Tero Kivinen , iesg@ietf.org, secdir@ietf.org, draft-ietf-netmod-opstate-reqs.all@tools.ietf.org, NETMOD Working Group References: <22204.24528.791620.642938@fireball.acr.fi> From: Benoit Claise Message-ID: <56C5EF4E.9080107@cisco.com> Date: Thu, 18 Feb 2016 17:20:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <22204.24528.791620.642938@fireball.acr.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-netmod-opstate-reqs-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:20:37 -0000 Tom, Kent, WG, Can you please engage with Tero. I would like to put this document on the telechat in 2 weeks from now. Regards, Benoit > 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 terminology and requirements document for handling operational > state. As such the security considerations section cannot have very > detailed problems, but it does properly point out that while > configuration is being applied the device might be in inconsistent > state, and that might cause security issues. > > It does not say anything about how the configuration requests needs to > be secured, but I assume that is more in to the actual protocol RFC > issue, than this document. > > It does not also comment anything about whether the different states > (intended configuration, applied configuration and derivative state) > should have different security policies to applied to them, i.e. > it does say that it should be possible to retrieve only applied > configuration or only derived state, but does not mention should there > also be different security policies to do those operations. In some > cases the derivative state might contain things like traffic keys > negotiated during the protocol runs, or traffic information aabout > flows passing the devices (privacy issues), so derivative state might > be more sensitive than the actual applied configuration. > > Outside the security considerations section the requirement which > says: > > A. A server MUST support only synchronous configuration > operations, or only asynchronous configuration operations, or > both synchronous and asynchronous configuration operations on > a client-specified per-operation basis. > > is bit funny, as it effectively says that either syncronous or > asyncronous MUST be supported and both may be supported, but I do not > understand what the "client-specified per-operation basis" is meaning > for the requirement for server. > > Client cannot really require server to change its IMPLEMENTATION on > per-operation basis (i.e., client 1 requesting that server MUST > support only asyncronous operations, and client 2 requesting that > server MUST support only syncronous operations). > > Client can use either syncronous or asyncronous if both are supported > by the server, and I assume this is trying to say that client can > select syncronous/asyncronous operation per-operation basis, but when > you are talking about that "A server MUST support ..." I do not think > it is ok to requiring that on a client-specified way. > > I.e. proper way would be to say that if server supports both, it MUST > allow client to select which method is used on per-operation basis. From nobody Fri Feb 19 10:26:06 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 361151B32F9; Fri, 19 Feb 2016 09:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1455902276; bh=P9Ps2L8QW7cqV0vXgHtx74/JZlm9FoMToFPsyVsbZrk=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=vr2eBUypTAInet7K2O3b+SDOGqivUeEH2DlFdD/f4jHeSeJNJQVe2aVFpQBE2GqGC udDexxtHoPFV47I/kZTgMA0M/HCOBNl0z5jG7aaS04o1r0Xk/PG2lQq7U7UDVO7+9M eSWqhObEHG4MQITSNq862EZrXUFAP8djAjYurX3E= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0AA1B32F1 for ; Fri, 19 Feb 2016 09:17:50 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <20160219171750.19343.8563.idtracker@ietfa.amsl.com> Date: Fri, 19 Feb 2016 09:17:50 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 19 Feb 2016 10:26:04 -0800 Subject: [secdir] [new-work] WG Review: Registration Protocols Extensions (regext) 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, 19 Feb 2016 17:17:56 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-02-29. Registration Protocols Extensions (regext) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Jim Galvin Antoin Verschuren Assigned Area Director: Barry Leiba Applications and Real-Time Area Directors: Barry Leiba Ben Campbell Alissa Cooper Mailing list: Address: regext@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/regext Archive: https://mailarchive.ietf.org/arch/browse/regext/ Charter: https://datatracker.ietf.org/doc/charter-ietf-regext/ The Extensible Provisioning Protocol (EPP, Standard 69) is the standard domain name provisioning protocol for top-level domain name registries. To avoid many separate EPP extensions that provide the same functions, it's important to coordinate and standardize EPP extensions. The EPP Extensions (EPPEXT) working group completed its first goal of creating an IANA registry of EPP extensions. The registration process of the registry is documented in RFC7451. Extensions may be registered for informational purposes as long as there is a published specification that has been reviewed by a designated expert. The Registration Data Access Protocol (RDAP, RFCs 7480-7484) is the proposed standard for retrieving registration metadata from both domain name and Regional Internet Registries. To ensure interoperable implementations it's important to coordinate and standardize extensions and profiles to be used by registries. Extensions in both cases that are targeted for the Standards Track are subject to more thorough review and open discussion within the IETF. In addition, commonality may be discovered in related extensions, especially EPP extensions listed on the EPP extension registry, for which it would makes sense to merge them into a single standard extension everybody agrees on. The REGEXT working group is the home of the coordination effort for standards track extensions. The selection of extensions for standards track shall incorporate the following guidelines. 1. Proprietary documented extensions and individual submissions of informational or experimental EPP extensions will follow the expert review process as described in RFC7451 for inclusion in the EPP extensions registry. These documents will not be part of the REGEXT working group work or milestones. The working group may discuss or advise on these documents. 2. Extensions that seek standards track status can be suggested for WG adoption. If accepted by the working group then the development of the standard may proceed. 3. When there are no more proposals for Standards-Track extensions, the working group will either close or become dormant, with the decision made in consultation with the responsible AD. The charter will be reviewed by the end of 2017 and will be refreshed by rechartering if there is still a reason the keep the working group going. In any case, the mailing list will remain open and available for the use of the expert review process as described in RFC7451. The working group will also identify the requirements for a registration protocol that allows a third-party service provider to exchange information with a registry without the need of a registrar proxy in the middle of the exchange. These requirements will be documented in an Informational RFC. The working group will focus initially on the backlog of EPP and RDAP extensions. Milestones: Mar 2016 - Submit for publication "Launch Phase Mapping for EPP" Mar 2016 - Submit for publication "TMCH functional specifications" Apr 2016 - Submit for publication "EPP and RDAP Status Mapping" Apr 2016 - Submit for publication "Registry Fee Extension for EPP" Apr 2016 - Submit for publication "Reseller Extension for EPP" Apr 2016 - Submit for publication "EPP Reseller Mapping" Jun 2016 - Submit for publication "Verification Code Extension for EPP" Jun 2016 - Submit for publication "EPP China Name Verification Mapping" Jun 2016 - Submit for publication "EPP Domain Name Mapping Extension for Bundling Registration" Oct 2016 - Submit for publication "Change Poll Extension for EPP" Oct 2016 - Submit for publication "Allocation Token Extension for EPP" Feb 2017 - Submit for publication draft-ietf-eppext-idnmap Feb 2017 - Submit for publication "EPP IDN Table Mapping" Feb 2017 - Submit for publication "CIRA IDN EPP Extension" Jun 2017 - Submit for publication an informational RFC with requirements for a registration protocol for third-party DNS providers _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Feb 19 15:07:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0701B35C3; Fri, 19 Feb 2016 15:07:18 -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 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 S--bLZa1J5i3; Fri, 19 Feb 2016 15:07:16 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 BB0011B3364; Fri, 19 Feb 2016 15:07:16 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id x65so58540660pfb.1; Fri, 19 Feb 2016 15:07:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=c5pU0VhC5rNxeLf+mMUWJbARYmJhdk1+gHGWyypgYro=; b=Lvrqbipj/4Itkv5jKwBGJ+iK/WitdERs3umkRyvMAjvU4K7ev0zVJkGSOKJcvOmTUM 3WxEZ9lTP71OtzRK6pFOWHCJDTUqwqCEi7uNyRBV423UtRwe7I4RJZXMr++GiDyYr5H+ N6OI6pk9PYNrOjATEDEhqWnIFUcNgkr1d02SqLG7em7WpKJWWTtqG3gxYR3JNHBRAhxo STbavuajFAm5kA2zfQhadd08ysqyFZrlfZ7DA/xn8E03t//ecU23eMLGAXx8FPo9p3qd I0htopPwAHkCfyNak0LlepYKi7UYYgf4LAdloIT/xPAeFrkZSpLuRJChIl1cm9gOldZB 5ahw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=c5pU0VhC5rNxeLf+mMUWJbARYmJhdk1+gHGWyypgYro=; b=QGWU57bm2VWk9iISZrqQVr8xpn2D1HbDBN1zl+Fu3Rzka4XnySmXsZPUfD1yEP+R80 CCemNtbzi9lymtiGNeZ4XU201huBfYbL6pDNiR0Mrwf3TyMTuwwsw3ruO5DzBlczWdF+ 0HPMLgfKvoawk1k+21wY3LBBipBv5ET+yvqAr3figOjn5glylWg/63MeENUkzcdV57oJ 8LfKueDg+Fodp2AV0tGIlSvs2D79GswM/QkAZeXIRTzyTG0yGB/6pZ+Bk7ndRA7+wIxg hoOdbvAQVDI5yOCh/rjaqWSrvtf6CwQ4Q9j3N0F6V35v2lwuhJxmQONjYuTILQPvt+2F a5SA== X-Gm-Message-State: AG10YORGRP+7R4hei+rkd3Xd333l1XN1mMJII2k9gKKRfkYF3R5xnAhGlbCctbpNei+L+Q== X-Received: by 10.98.69.155 with SMTP id n27mr21872249pfi.68.1455923236372; Fri, 19 Feb 2016 15:07:16 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1003::5e3? ([2001:420:c0c8:1003::5e3]) by smtp.gmail.com with ESMTPSA id q8sm20009975pfa.70.2016.02.19.15.07.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 19 Feb 2016 15:07:15 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8B2616FD-2030-4356-A9B8-349FFA3054ED" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mahesh Jethanandani In-Reply-To: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> Date: Fri, 19 Feb 2016 15:07:13 -0800 Message-Id: References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> To: Tom Yu X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-netconf-yang-library.all@tools.ietf.org, "Benoit Claise \(bclaise\)" , The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 23:07:18 -0000 --Apple-Mail=_8B2616FD-2030-4356-A9B8-349FFA3054ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, How did you want to proceed on this? > On Feb 15, 2016, at 1:28 PM, Mahesh Jethanandani = wrote: >=20 > Tom, >=20 > It is not entirely clear from this e-mail, what action you want the = authors to take.=20 >=20 > YANG module information or more like its encodings are sent over a = secure session (SSH) and are no more specific to this draft than they = are to any NETCONF/RESTCONF session. As such it is not clear what you = want the authors to do. Could you clarify or provide text for the = Security Consideration section? >=20 > Thanks. >=20 >> On Feb 1, 2016, at 6:03 PM, Tom Yu wrote: >>=20 >> I have reviewed this document as part of the security directorate's=20= >> ongoing effort to review all IETF documents being processed by the=20 >> IESG. These comments were written primarily for the benefit of the=20= >> security area directors. Document editors and WG chairs should treat=20= >> these comments just like any other last call comments. >>=20 >> The Security Considerations of this document seem reasonable. It = might >> be useful to add a comparison of the risks posed by sensitive >> information exposed by this YANG module with information exposed by >> other aspects of NETCONF, or available through methods such as >> fingerprinting. Admittedly, a meaningful comparison might be highly >> context-specific, so a general comparison might have limited utility. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_8B2616FD-2030-4356-A9B8-349FFA3054ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Tom,

How = did you want to proceed on this?

On = Feb 15, 2016, at 1:28 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Tom,
It is not entirely clear from this e-mail, what action you = want the authors to take.

YANG module = information or more like its encodings are sent over a secure session = (SSH) and are no more specific to this draft than they are to any = NETCONF/RESTCONF session. As such it is not clear what you want =  the authors to do. Could you clarify or provide text for the = Security Consideration section?

Thanks.

On Feb 1, = 2016, at 6:03 PM, Tom Yu <tlyu@mit.edu> wrote:

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

The Security Considerations of this document seem reasonable. =  It might
be useful to add a comparison of the risks = posed by sensitive
information exposed by this YANG module = with information exposed by
other aspects of NETCONF, or = available through methods such as
fingerprinting. =  Admittedly, a meaningful comparison might be highly
context-specific, so a general comparison might have limited = utility.

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_8B2616FD-2030-4356-A9B8-349FFA3054ED-- From nobody Sun Feb 21 12:13:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326F71A9172; Sun, 21 Feb 2016 12:13:45 -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 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 Ksy9RsvvnSGd; Sun, 21 Feb 2016 12:13:43 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 CDF771A909E; Sun, 21 Feb 2016 12:13:42 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id gc3so147867908obb.3; Sun, 21 Feb 2016 12:13:42 -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 :content-type; bh=D527Z9TVY5nD8BiXEft0Fe1BorOhz1iVlW1oEcAmw4U=; b=qb1iUKRC3QcGcMBMnFZyGeod+Ki/1h+Q+HJx/1BA25gU2yeEtMUuHDRdoQEw4OQ8GR 7RrOM/Kx7hVzdjGiAHyZOUpFKkU0AUBTtI7Jn7a7pDEeBJkhsutEMO8ff1FPYQEwxaxA JKb4hqgIMXDOaAzRgHrU0htOHEzdqN3+r4b4Np17zuMaNkSNNN7C2325I+rLKd8Pjh6m WnuJyQ7dtYU2f66e44TACRYMeGbuP9fIRoRvuFr3sQFDNv82RvvWxim91pgvaTEPPFwt +xF8d9Xf2f5W1wfCAN7HQsUP9RWTztydM3cFXlf4v3PLcNeea+LfmAKzjWTTMWvygoYg Yhkg== 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:content-type; bh=D527Z9TVY5nD8BiXEft0Fe1BorOhz1iVlW1oEcAmw4U=; b=kVL5EERz5Jyi4ndwnvp9BQBZrEvUIFcAx/biW2LGr38lCDcUpJ9l/JQ52AzDCH5l/t dtijy3IdGhwSBnwUFER1p43pfDnOjLbBgSdRMdW/XYMbW9H1i3DnmBYar6tMi0jHu+Im 5rgPgrQ9mic9Yof6y4tl7Xdf6oq6ohuaIKhs17q83gC/skeRy9pIQmN5sdkuyVyXfn+w 6lVpLRb+qZ3jG3AWR76+Wflx99rf5k6TIBz5UoQYdG9LYEwE6UYgGiJBH0UCIuhUobOj ajHaYlMSLhZd95daN1Ip0qbjHt/ILKbDrMTwStjZIe3wo6lPlXIkvynzb2D1tBF8D2js jxVA== X-Gm-Message-State: AG10YOQeB/ttk0D1j635RGbiIO4XpLBP63ZFjSp5MiwK6WCth4W+WkCoQ2FkK/SjiC4EVQ== X-Received: by 10.182.61.38 with SMTP id m6mr20740550obr.32.1456085622295; Sun, 21 Feb 2016 12:13:42 -0800 (PST) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:3c2a:33a6:3038:1811]) by smtp.googlemail.com with ESMTPSA id x20sm14582705oix.3.2016.02.21.12.13.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Feb 2016 12:13:41 -0800 (PST) To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-httpbis-alt-svc-12.all@tools.ietf.org From: Chris Lonvick Message-ID: <56CA1A79.4040107@gmail.com> Date: Sun, 21 Feb 2016 14:13:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000603030002070306070106" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-httpbis-alt-svc-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 20:13:45 -0000 This is a multi-part message in MIME format. --------------000603030002070306070106 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. Overall, the document looks pretty good. It clearly spells out its intent and the implementation. I believe it will be useful. I would recommend some small edits which are more on the subjective side. Please take these as mere suggestions and use them, edit them, or ignore them as you see fit. The term "safely ignore it" is used twice in the document. I would prefer a more concrete directive for each. The first time it is used is in the second paragraph of Section 4. In this case, the term should be replaced with "MAY" as that is definitive per RFC 2119 for the protocol. The second case occurs in the following paragraph: The ALTSVC frame is intended for receipt by clients; a server that receives an ALTSVC frame can safely ignore it. I'd recommend changing that to: The ALTSVC frame is intended for receipt by clients. A device acting as a server MUST ignore it. This advises what to do if a server receives the frame, but allows some leeway if the device is simultaneously being used as a client. In Section 9.2, there is a paragraph that starts as follows: Alternative services could be used to persist such an attack; for example, an... The whole thing is a bit of a run-on sentence so I'd recommend that the semicolon be replaced with a period and a second sentence started after that. Each use of 'e.g.' should be followed by a comma. There seem to be some that aren't. Section 9.3 has the following two paragraphs: For example, if an "https://" URI has a protocol advertised that does not use some form of end-to-end encryption (most likely, TLS), it violates the expectations for security that the URI scheme implies. Therefore, clients cannot blindly use alternative services, but instead evaluate the option(s) presented to assure that security requirements and expectations (of specifications, implementations and end users) are met. This should either be one unified paragraph or two paragraphs expressing different thoughts. My suggestion would be: For example, if an "https://" URI has a protocol advertised that does not use some form of end-to-end encryption (most likely TLS), it violates the expectations for security that the URI scheme denotes. Therefore, clients MUST NOT blindly use alternative services, but instead SHOULD evaluate the option(s) presented and make a selection that assures the security requirements and expectations of policy provided by specifications, implementations, and end user desires. There are a lot of parentheticals throughout. Putting an 'e.g.' or 'i.e.' in a sentence does not require that it be within parenthesis. Stick a comma in front it it and move on. ;-) Y'all almost did that within the last paragraph of Section 9.5 but didn't get it altogether right. When the protocol does not explicitly carry the scheme (e.g., as is usually the case for HTTP/1.1 over TLS, servers can mitigate this risk by either assuming that all requests have an insecure context, or by refraining from advertising alternative services for insecure schemes (such as HTTP). The first parenthetical is opened with a left parenthesis but closed with a comma. I'd suggest using commas to open and close that. The second should just be separated by a preceding comma. Best regards, Chris --------------000603030002070306070106 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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.

Overall, the document looks pretty good. It clearly spells out its intent and the implementation. I believe it will be useful.

I would recommend some small edits which are more on the subjective side. Please take these as mere suggestions and use them, edit them, or ignore them as you see fit.

The term "safely ignore it" is used twice in the document. I would prefer a more concrete directive for each. The first time it is used is in the second paragraph of Section 4. In this case, the term should be replaced with "MAY" as that is definitive per RFC 2119 for the protocol. The second case occurs in the following paragraph:
   The ALTSVC frame is intended for receipt by clients; a server that
   receives an ALTSVC frame can safely ignore it.
I'd recommend changing that to:
   The ALTSVC frame is intended for receipt by clients. A device acting
   as a server MUST ignore it.
This advises what to do if a server receives the frame, but allows some leeway if the device is simultaneously being used as a client.


In Section 9.2, there is a paragraph that starts as follows:
   Alternative services could be used to persist such an attack; for
   example, an...
The whole thing is a bit of a run-on sentence so I'd recommend that the semicolon be replaced with a period and a second sentence started after that.

Each use of 'e.g.' should be followed by a comma. There seem to be some that aren't.

Section 9.3 has the following two paragraphs:
   For example, if an "https://" URI has a protocol advertised that does
   not use some form of end-to-end encryption (most likely, TLS), it
   violates the expectations for security that the URI scheme implies.
   
   Therefore, clients cannot blindly use alternative services, but
   instead evaluate the option(s) presented to assure that security
   requirements and expectations (of specifications, implementations and
   end users) are met.
This should either be one unified paragraph or two paragraphs expressing different thoughts. My suggestion would be: 
   For example, if an "https://" URI has a protocol advertised that does
   not use some form of end-to-end encryption (most likely TLS), it
   violates the expectations for security that the URI scheme denotes.
   Therefore, clients MUST NOT blindly use alternative services, but
   instead SHOULD evaluate the option(s) presented and make a selection
   that assures the security requirements and expectations of policy 
   provided by specifications, implementations, and end user desires.
There are a lot of parentheticals throughout. Putting an 'e.g.' or 'i.e.' in a sentence does not require that it be within parenthesis. Stick a comma in front it it and move on. ;-) Y'all almost did that within the last paragraph of Section 9.5 but didn't get it altogether right. 
   When the protocol does not explicitly carry the scheme (e.g., as is
   usually the case for HTTP/1.1 over TLS, servers can mitigate this
   risk by either assuming that all requests have an insecure context,
   or by refraining from advertising alternative services for insecure
   schemes (such as HTTP).
The first parenthetical is opened with a left parenthesis but closed with a comma. I'd suggest using commas to open and close that. The second should just be separated by a preceding comma. Best regards, Chris --------------000603030002070306070106-- From nobody Sun Feb 21 12:57:19 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15A31ACD7A; Sun, 21 Feb 2016 12:57:17 -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 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 uX7KcQKQfzfP; Sun, 21 Feb 2016 12:57:15 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232571A903B; Sun, 21 Feb 2016 12:57:15 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id x65so80871651pfb.1; Sun, 21 Feb 2016 12:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=VgkxeeYWYaU66kL4OE4A6fEuPYuqadipaVuXoBUHqig=; b=tb8YsyzdXCgbinKimpZ1HF0FhEKYRdv9oaYIvIvpPCsHTSTdCq6kRWTM5KvZO6Pvzr B0hP1luiFLGi380WnKuL5hdXsTZxPhCtut5t/QPTu0CSRI//aW591FsEx2xc3ZrjSQ47 +LLw7al+5DDvWxjPAq2zK0JqD5lntauwtBEeddXpWFKWPyVPIgrKANpIcCO/iGIl9LeX +OoO/nXuzSldzWuIAWF9d3xLRwlXZJ7k7mBpHvo/f89vLfKrYw0OFc4hH910l8BRJZ10 z1/niLwW2e78qgcBFmD5N4ovucp45GWVWudNp0LQgquN79AO6/hLz1xsfIAtb9WNa0sT /73g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=VgkxeeYWYaU66kL4OE4A6fEuPYuqadipaVuXoBUHqig=; b=FCklwU6bE+m89giVA/6AtXGo7AmgM89XGe9JKet9/sVIKym/7+ergrNea5sJd/uqkg 5YEB/IOzgat++MVBABItOV8mF4Um7EYVKyzKw40LIw1o5TLKXmD5XdZYpyUBwfExw3BI sKYpJKc2QaM1ETWcuywl2/q+pCru47+iPa/gqlJuwnwS9DnyHNhvvvOrrubWKl6RomnB sjQxFwxw6Y0r1CLaNwjiSQ/maYK/+0qxv9DqSdRKZc51TzlIaVmkmiNwMHUzw4qOUTK8 b0QkYXEBxs1OcweK97bYbYdxafHgZZVM/cgtuS+o8Wj+b0iC8WF6XnOoavarWU2Q/K/A bcEQ== X-Gm-Message-State: AG10YOT6LLnF0fSJZ2RfHVhhe4zIzU+c+J9zGmbrEapzNGDe3lg/SsUS8y1edvNc2kD4uA== X-Received: by 10.98.2.197 with SMTP id 188mr33697401pfc.3.1456088234757; Sun, 21 Feb 2016 12:57:14 -0800 (PST) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:a097:f2ec:56ef:5b85]) by smtp.googlemail.com with ESMTPSA id 67sm31723694pfi.2.2016.02.21.12.57.13 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Feb 2016 12:57:14 -0800 (PST) References: <56CA1A79.4040107@gmail.com> To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-httpbis-alt-svc.all@tools.ietf.org From: Chris Lonvick X-Forwarded-Message-Id: <56CA1A79.4040107@gmail.com> Message-ID: <56CA24AD.8010102@gmail.com> Date: Sun, 21 Feb 2016 14:57:17 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CA1A79.4040107@gmail.com> Content-Type: multipart/alternative; boundary="------------000706030809060405040102" Archived-At: Subject: [secdir] Fwd: SECDIR review of draft-ietf-httpbis-alt-svc-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 20:57:18 -0000 This is a multi-part message in MIME format. --------------000706030809060405040102 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Resending to get it to all the right people. 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. Overall, the document looks pretty good. It clearly spells out its intent and the implementation. I believe it will be useful. I would recommend some small edits which are more on the subjective side. Please take these as mere suggestions and use them, edit them, or ignore them as you see fit. The term "safely ignore it" is used twice in the document. I would prefer a more concrete directive for each. The first time it is used is in the second paragraph of Section 4. In this case, the term should be replaced with "MAY" as that is definitive per RFC 2119 for the protocol. The second case occurs in the following paragraph: The ALTSVC frame is intended for receipt by clients; a server that receives an ALTSVC frame can safely ignore it. I'd recommend changing that to: The ALTSVC frame is intended for receipt by clients. A device acting as a server MUST ignore it. This advises what to do if a server receives the frame, but allows some leeway if the device is simultaneously being used as a client. In Section 9.2, there is a paragraph that starts as follows: Alternative services could be used to persist such an attack; for example, an... The whole thing is a bit of a run-on sentence so I'd recommend that the semicolon be replaced with a period and a second sentence started after that. Each use of 'e.g.' should be followed by a comma. There seem to be some that aren't. Section 9.3 has the following two paragraphs: For example, if an"https://" URI has a protocol advertised that does not use some form of end-to-end encryption (most likely, TLS), it violates the expectations for security that the URI scheme implies. Therefore, clients cannot blindly use alternative services, but instead evaluate the option(s) presented to assure that security requirements and expectations (of specifications, implementations and end users) are met. This should either be one unified paragraph or two paragraphs expressing different thoughts. My suggestion would be: For example, if an"https://" URI has a protocol advertised that does not use some form of end-to-end encryption (most likely TLS), it violates the expectations for security that the URI scheme denotes. Therefore, clients MUST NOT blindly use alternative services, but instead SHOULD evaluate the option(s) presented and make a selection that assures the security requirements and expectations of policy provided by specifications, implementations, and end user desires. There are a lot of parentheticals throughout. Putting an 'e.g.' or 'i.e.' in a sentence does not require that it be within parenthesis. Stick a comma in front it it and move on. ;-) Y'all almost did that within the last paragraph of Section 9.5 but didn't get it altogether right. When the protocol does not explicitly carry the scheme (e.g., as is usually the case for HTTP/1.1 over TLS, servers can mitigate this risk by either assuming that all requests have an insecure context, or by refraining from advertising alternative services for insecure schemes (such as HTTP). The first parenthetical is opened with a left parenthesis but closed with a comma. I'd suggest using commas to open and close that. The second should just be separated by a preceding comma. Best regards, Chris --------------000706030809060405040102 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Resending to get it to all the right people.

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.

Overall, the document looks pretty good. It clearly spells out its intent and the implementation. I believe it will be useful.

I would recommend some small edits which are more on the subjective side. Please take these as mere suggestions and use them, edit them, or ignore them as you see fit.

The term "safely ignore it" is used twice in the document. I would prefer a more concrete directive for each. The first time it is used is in the second paragraph of Section 4. In this case, the term should be replaced with "MAY" as that is definitive per RFC 2119 for the protocol. The second case occurs in the following paragraph:
   The ALTSVC frame is intended for receipt by clients; a server that
   receives an ALTSVC frame can safely ignore it.
I'd recommend changing that to:
   The ALTSVC frame is intended for receipt by clients. A device acting
   as a server MUST ignore it.
This advises what to do if a server receives the frame, but allows some leeway if the device is simultaneously being used as a client.


In Section 9.2, there is a paragraph that starts as follows:
   Alternative services could be used to persist such an attack; for
   example, an...
The whole thing is a bit of a run-on sentence so I'd recommend that the semicolon be replaced with a period and a second sentence started after that.

Each use of 'e.g.' should be followed by a comma. There seem to be some that aren't.

Section 9.3 has the following two paragraphs:
   For example, if an "https://" URI has a protocol advertised that does
   not use some form of end-to-end encryption (most likely, TLS), it
   violates the expectations for security that the URI scheme implies.
   
   Therefore, clients cannot blindly use alternative services, but
   instead evaluate the option(s) presented to assure that security
   requirements and expectations (of specifications, implementations and
   end users) are met.
This should either be one unified paragraph or two paragraphs expressing different thoughts. My suggestion would be: 
   For example, if an "https://" URI has a protocol advertised that does
   not use some form of end-to-end encryption (most likely TLS), it
   violates the expectations for security that the URI scheme denotes.
   Therefore, clients MUST NOT blindly use alternative services, but
   instead SHOULD evaluate the option(s) presented and make a selection
   that assures the security requirements and expectations of policy 
   provided by specifications, implementations, and end user desires.
There are a lot of parentheticals throughout. Putting an 'e.g.' or 'i.e.' in a sentence does not require that it be within parenthesis. Stick a comma in front it it and move on. ;-) Y'all almost did that within the last paragraph of Section 9.5 but didn't get it altogether right. 
   When the protocol does not explicitly carry the scheme (e.g., as is
   usually the case for HTTP/1.1 over TLS, servers can mitigate this
   risk by either assuming that all requests have an insecure context,
   or by refraining from advertising alternative services for insecure
   schemes (such as HTTP).
The first parenthetical is opened with a left parenthesis but closed with a comma. I'd suggest using commas to open and close that. The second should just be separated by a preceding comma. Best regards, Chris
--------------000706030809060405040102-- From nobody Sun Feb 21 13:42:51 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5CE1B2B25; Sun, 21 Feb 2016 13:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 ISdo7r1oU5V0; Sun, 21 Feb 2016 13:42:49 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001: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 443E01B2B23; Sun, 21 Feb 2016 13:42:49 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id g6so73963555igt.1; Sun, 21 Feb 2016 13:42:49 -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:date:message-id:subject :from:to:cc:content-type; bh=0RBi34EgnEJRmg+YqSfkkRvUJKWIF5Er3ZgPxliIU9U=; b=bMq8qSYj15bL7CoHnW3DJr3xgGRMpYBq6xl2xXcX5j5/4E1V7HuXNMVoJHwU4DRQg1 r5nzx1kTDKlehe30rvG0QeOcb7yBM435QwdtLcP+Nht2Uua+3AlMQEIIU4XiValnALY6 LzU2M5IBXvPddKlRw7aVvDdcBIgT3yrQyRPI3Ws6xFpzrB9zzIYlZZ2XzYcGbNclozau pqtsbZx2hiPGHCIckylAy7FnUgw+ZWTGFAtPk//bfwZ8C53zKBVKBZCGNU9qQEvDBXK2 hS5vuaZ2m/hPVAiXDXLx1Cavccb6UyYiOrC+1+1Zpfm6CGoXwYOH+h/q7Xfu3ivVLsRV ojzA== 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:date :message-id:subject:from:to:cc:content-type; bh=0RBi34EgnEJRmg+YqSfkkRvUJKWIF5Er3ZgPxliIU9U=; b=KNhl6AjAagPR85POK9k3lhPxB2uxrZppFdOdCm8D9a63QVoXb17AH6TGU1LxoAqirv B8gabSM0IEq4inVN4BC9/LO6tIEh4gnU86casyPuKGRc1hKmyGDcUEXYbkNvaeipSeoN qK/eQi2flD4FkDOGhFx+RchqEHMc5ga3j4Vrju4Q/Z7zMDDywrQct6BJkW5swjSao+WL eT/M4lEyxGmOtw1pjnQaq1uZm73R8tsVZWNxXVuPsVv75x74qAmw6A3iNEfAVHUP82RJ OuqHEgXEujqLuuUQ/7JsF2IhUG8Es+twmNLQRm+OZkRD1uU7vlsCobKXKeQp8WOIjSko EHdw== X-Gm-Message-State: AG10YOTooRhQJBEVKYz/tuBcRI8Rigievv3WfnoFxVeaH51V8N27mka02slQ2tsre1bAUEJpkzpW4aRjDbLqOA== MIME-Version: 1.0 X-Received: by 10.50.138.72 with SMTP id qo8mr7871225igb.81.1456090968756; Sun, 21 Feb 2016 13:42:48 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.156.5 with HTTP; Sun, 21 Feb 2016 13:42:48 -0800 (PST) In-Reply-To: <56CA24AD.8010102@gmail.com> References: <56CA1A79.4040107@gmail.com> <56CA24AD.8010102@gmail.com> Date: Sun, 21 Feb 2016 13:42:48 -0800 X-Google-Sender-Auth: BnBRgBxDSF89Z-DQuvQwxX1N32c Message-ID: From: Barry Leiba To: Chris Lonvick Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-httpbis-alt-svc.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-httpbis-alt-svc-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 21:42:50 -0000 Thanks for the review, Chris. A point on the Latin abbreviations: > Each use of 'e.g.' should be followed by a comma. There seem to be some that > aren't. ... > There are a lot of parentheticals throughout. Putting an 'e.g.' or 'i.e.' in > a sentence does not require that it be within parenthesis. Stick a comma in > front it it and move on. ;-) Y'all almost did that within the last paragraph > of Section 9.5 but didn't get it altogether right. As it happens, I have a strong preference for avoiding "i.e." and "e.g.", for a number of reasons. One is that they're often not used quite right, as you note in these two comments. Another is that one is often used when the other should be (that's not the case in this document). But the main one is that they're almost always unnecessary, and removing them and/or rewording makes better sentences -- "i.e." can almost always just be removed, and "e.g." can usually be replaced with a more natural "such as", "as with", or something of that sort. An example of common misuse: "...as with fruit, e.g., apples, bananas, etc." Euw! > When the protocol does not explicitly carry the scheme (e.g., as is > usually the case for HTTP/1.1 over TLS, servers can mitigate this > risk by either assuming that all requests have an insecure context, > or by refraining from advertising alternative services for insecure > schemes (such as HTTP). > > The first parenthetical is opened with a left parenthesis but closed with a > comma. I'd suggest using commas to open and close that. The second should > just be separated by a preceding comma. Best regards, Chris Actually, this is a really good example where "e.g." isn't needed at all (the "as is...the case" takes care of that), and where the sentence works better this way (also correcting the non-parallel use of "either", while we're here): NEW When the protocol does not explicitly carry the scheme, as is usually the case for HTTP/1.1 over TLS, servers can mitigate this risk either by assuming that all requests have an insecure context, or by refraining from advertising alternative services for insecure schemes such as HTTP. END I urge the authors to make a quick run-through along with handling other comments, and to get rid of as many of the "i.e."s and "e.g."s as they reasonably can. Barry From nobody Sun Feb 21 14:07:51 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF631B2EA0; Sun, 21 Feb 2016 14:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 W1-vf8dXhg1J; Sun, 21 Feb 2016 14:07:49 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id E504E1B2E85; Sun, 21 Feb 2016 14:07:48 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CE5C016C172; Sun, 21 Feb 2016 22:07:47 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id B80E316C16C; Sun, 21 Feb 2016 22:07:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1456092467; bh=7fVGv9B1xiAZf3js2dxkktysCUZ5XKmARKtr8Hnzj8g=; l=194; h=From:To:CC:Date:References:In-Reply-To:From; b=i3cD0MJH6wd5T49fs6c2/7fu2qe6yF1eBorTK9rqGSsczyhgGk7OMXzylOylRNHUb KrkF+QMOfW7Qnj4FUCrSCgJ+kQ1YnLw0rz/J0KyCG6la/qE5zgKeyW6Ev3AgQByXTM eAMSQyiQn4JdLLc0LbmYp4uBUjaCn+tbqz6LlSwM= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id B3BED1E07C; Sun, 21 Feb 2016 22:07:47 +0000 (GMT) Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 21 Feb 2016 16:07:40 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1076.000; Sun, 21 Feb 2016 16:07:40 -0600 From: "Salz, Rich" To: Barry Leiba , Chris Lonvick Thread-Topic: [secdir] SECDIR review of draft-ietf-httpbis-alt-svc-12 Thread-Index: AQHRbPDSIkvX2gLa3EG7lFLn6UgryJ83DpxQ Date: Sun, 21 Feb 2016 22:07:40 +0000 Message-ID: References: <56CA1A79.4040107@gmail.com> <56CA24AD.8010102@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.220] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-httpbis-alt-svc.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-httpbis-alt-svc-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 22:07:50 -0000 > I urge the authors to make a quick run-through along with handling other > comments, and to get rid of as many of the "i.e."s and "e.g."s as they > reasonably can. Plus-one to that! From nobody Sun Feb 21 15:38:44 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551AE1AC3B0 for ; Sun, 21 Feb 2016 15:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 efggpNekW6Jk for ; Sun, 21 Feb 2016 15:38:39 -0800 (PST) Received: from nm22-vm10.access.bullet.mail.bf1.yahoo.com (nm22-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.153]) (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 DDF751AC3B4 for ; Sun, 21 Feb 2016 15:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1456097917; bh=VXds8pAiANrW7RNG8JfodJwvZjWYnpuPadgYMfNgC3g=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=RpCnOWJOgp4gkwgsHPZ2cTXuQFhb+je5N0WyFI/90r4Gh9bUl3+y5bB/rVGjDaawd5WU7XnQLNw7DQbWGCN5RYG/DwMQQoMXoG+v5s9a18hopdYnKKrPuppSOQMOv/gynIW6NoE/f6HU/3vOXCmOSh09oCsorhpNrNZbUNHfBwpyEnBoRb2V3CyCfm9aDZ59vfhIzlxFBlxGV/EGQuTbvgAJySxGi605UBQ6XJupUIOHypdaamAnTu6bwdyqe4yNaI8LF3AXkTI2zp2nK6SbcNCI24KSsqNfqklYBCPP/32VuGw68gb7tt8YrFme/21frgbwrl/LsTt5cNEjLQvyrg== Received: from [66.196.81.159] by nm22.access.bullet.mail.bf1.yahoo.com with NNFMP; 21 Feb 2016 23:38:37 -0000 Received: from [98.138.104.97] by tm5.access.bullet.mail.bf1.yahoo.com with NNFMP; 21 Feb 2016 23:38:37 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 21 Feb 2016 23:38:37 -0000 X-Yahoo-Newman-Id: 176535.37965.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: a71bgIYVM1mSm_MnHu4B2TWHYOE.z4WM2HFIEn5_.sZj7TY qOkVbtDe5LEJ5ND4teLyxG4k7tWOT44J09kohEqqB15OWgyqneQXybGoFmSj NYndMmz300PCVn6I4vozWOw9vOW4oOkoWBVnapiL5s0n7hp83I5kANSJV4jd pMOGNiPz8EyWpWRGxruMda2_EkoqNEjXI1rtj829EI1MgaYHuqnDc_GGOyse 3n1Ho3gyFy3FuVbQRskK7_CwNxswKJ0GZM6Z8PeUNcZUJnFhgb7.2ujcCbKI HDUUFr.mbGP6OwBZPBXZjgPZU3QdmlIEH4WRej_0k5Sc_KbS2zyCUddbilDV XZj7afzyVFUVkixlzFg41.V0Ycj5AO7F3tZEFuCIKNgAmLddIrB0Zrh.5VGG uiUjL5lBgV6l1MO0P3T5ZqsJ7Z8Aqe_quGKub5ameUPCFePWiIX6JfBCQsn5 KV80WyfnRvhHRIfOFPmhGJuKkmGPZOp7iZSAP9SjslPwe3Z_VmE6jg9TmVdZ e0jBya4l3zr2tc_G7sZsA_Za_ZpCHPfnRkDhfaA-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.16] (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 58F581C6035; Sun, 21 Feb 2016 18:38:35 -0500 (EST) To: Paul Kyzivat , iesg@ietf.org, secdir@ietf.org, draft-ietf-siprec-metadata.all@tools.ietf.org References: <56C0EB89.4050409@mandelberg.org> <56C15FB9.8030600@alum.mit.edu> <56C4B3D6.6040700@mandelberg.org> <56C4BA98.3080001@alum.mit.edu> From: David Mandelberg X-Enigmail-Draft-Status: N1110 Message-ID: <56CA4A7A.1050505@mandelberg.org> Date: Sun, 21 Feb 2016 18:38:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C4BA98.3080001@alum.mit.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="psPIw9pd34RClwx55eC8Hepe9ofAiCGa8" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-siprec-metadata-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 23:38:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --psPIw9pd34RClwx55eC8Hepe9ofAiCGa8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Responses to your points are below, but I think it might also help if I'm more clear about how I think this issue could be resolved. Here's one way that seems reasonable to me, but is not the only way to prevent the issue I brought up (unless I'm wrong and it's not an issue). Add text specifying that if an SRS receives more than one object defined with the same UUID, the SRS MUST reject (or ignore?) all but the first definition of the object. (This would ensure that UUIDs are actually unique on a per-SRS basis.) Also, specify that an SRC MUST use a random or pseudo-random method of generating UUIDs, and an SRC MUST NOT share an object's UUID with anybody other than the SRS until after the SRS has acknowledged receipt of that object. (This would ensure that the UUID generated by the SRC points to the correct object.) Would that work? On 02/17/2016 01:23 PM, Paul Kyzivat wrote: > So your concern is the security implications when we have a malicious > SRC that has been authorized by the SRS? Yes, but I didn't see anything in the draft saying that an SRC needs to be authorized by the SRS, just that the SRS needs to be authorized by the SRC. Maybe I missed that? Or maybe the Security Considerations could be made more clear about exactly who needs to authenticate to whom and who needs to make what authorization decisions based on that authenticati= on? > If so, it seems like that can extend to lots of things beyond reuse of > UUIDs. The only issue I noticed was with the UUIDs. Otherwise it looks like an SRS could record metadata from any untrusted SRC without any security concerns other than the use of bandwidth, disk space, etc. (I could have missed something of course.) > (Going further afield, how does this differ from a malicious SIP UA tha= t > has the credentials to register a particular AoR? It could cause all > sorts of mischief by unregistering valid UAs, etc. ISTM the bottom line= > is that it is impossible to avoid problems from a party with access to > enough "secrets".) I'm not a SIP expert, but I think it needs to be made clear which pieces of data are secrets in order to reason about the security of a system. At present, I don't see any indication that UUIDs are meant to be secrets. If they are supposed to be secrets, then I don't think they're adequately protected from attackers who can guess the output of a (potentially non-random) UUID generator. > But the problem actually seems less severe in the case of SIPREC. The > SRS is performing what is essentially an append-only write process. The= > use of a duplicate UUID by a malicious SRC doesn't cause any valid > information to be lost. And the SRS is free to track the source of each= > piece of information it records, so that the malicious info can be > sorted out from the valid info once the bad guy has been identified. I don't see any mention of append-only writing in the draft, so I don't know how a server implementer would know to avoid overwriting of the object for a specific UUID, thus modifying the meaning of metadata that had previously been recorded from a different SRC. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --psPIw9pd34RClwx55eC8Hepe9ofAiCGa8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlbKSnsACgkQRKlmUHCg4sBVMwCdHZbbeWly4eyB74eteQXq06wm WAEAnidEk5MPCqFkT+FKY/QETRXGC5rv =Lsc8 -----END PGP SIGNATURE----- --psPIw9pd34RClwx55eC8Hepe9ofAiCGa8-- From nobody Sun Feb 21 15:42:18 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1E01A9079; Sun, 21 Feb 2016 15:42:16 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 HuhQb_m2wpug; Sun, 21 Feb 2016 15:42:14 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C041A8877; Sun, 21 Feb 2016 15:42:13 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 76C0D22E1F4; Sun, 21 Feb 2016 18:42:06 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Mark Nottingham In-Reply-To: <56CA24AD.8010102@gmail.com> Date: Mon, 22 Feb 2016 10:42:02 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <687A1C0F-067F-4487-A217-7399560FA675@mnot.net> References: <56CA1A79.4040107@gmail.com> <56CA24AD.8010102@gmail.com> To: Chris Lonvick X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-httpbis-alt-svc.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-httpbis-alt-svc-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 23:42:17 -0000 Hi Chris, Thanks for the review. See: https://github.com/httpwg/http-extensions/commit/23d3b09374c077 I eradicated the bulk of the spurious parenthesis, "e.g.," and "i.e.," = :) If folks could have a read of them I'd appreciated it, to make sure = I didn't introduce any new issues. One thing - I didn't introduce requirements in 9.3 as you suggested = below, because we generally try to avoid having normative requirements = in Security Considerations (believing that they should be in the spec = itself, so that people don't miss them). We also try to avoid untestable = requirements where possible (although we don't always reach that goal). Cheers, > On 22 Feb 2016, at 7:57 AM, Chris Lonvick = wrote: >=20 > Resending to get it to all the right people. >=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=20 > IESG. These comments were written primarily for the benefit of the=20 > security area directors. Document editors and WG chairs should treat=20= > these comments just like any other last call comments. >=20 > Overall, the document looks pretty good. It clearly spells out its = intent and the implementation. I believe it will be useful. >=20 > I would recommend some small edits which are more on the subjective = side. Please take these as mere suggestions and use them, edit them, or = ignore them as you see fit. >=20 > The term "safely ignore it" is used twice in the document. I would = prefer a more concrete directive for each. The first time it is used is = in the second paragraph of Section 4. In this case, the term should be = replaced with "MAY" as that is definitive per RFC 2119 for the protocol. = The second case occurs in the following paragraph: > The ALTSVC frame is intended for receipt by clients; a server that > receives an ALTSVC frame can safely ignore it. >=20 > I'd recommend changing that to: > The ALTSVC frame is intended for receipt by clients. A device = acting > as a server MUST ignore it. >=20 > This advises what to do if a server receives the frame, but allows = some leeway if the device is simultaneously being used as a client.=20 >=20 >=20 > In Section 9.2, there is a paragraph that starts as follows: > Alternative services could be used to persist such an attack; for > example, an... >=20 > The whole thing is a bit of a run-on sentence so I'd recommend that = the semicolon be replaced with a period and a second sentence started = after that. >=20 > Each use of 'e.g.' should be followed by a comma. There seem to be = some that aren't.=20 >=20 > Section 9.3 has the following two paragraphs: > For example, if an "https://" > URI has a protocol advertised that does > not use some form of end-to-end encryption (most likely, TLS), it > violates the expectations for security that the URI scheme implies. >=20 > =20 > Therefore, clients cannot blindly use alternative services, but > instead evaluate the option(s) presented to assure that security > requirements and expectations (of specifications, implementations = and > end users) are met. >=20 > This should either be one unified paragraph or two paragraphs = expressing different thoughts. My suggestion would be: > For example, if an "https://" > URI has a protocol advertised that does > not use some form of end-to-end encryption (most likely TLS), it > violates the expectations for security that the URI scheme denotes. > Therefore, clients MUST NOT blindly use alternative services, but > instead SHOULD evaluate the option(s) presented and make a = selection > that assures the security requirements and expectations of policy=20= > provided by specifications, implementations, and end user desires. >=20 > There are a lot of parentheticals throughout. Putting an 'e.g.' or = 'i.e.' in a sentence does not require that it be within parenthesis. = Stick a comma in front it it and move on. ;-) Y'all almost did that = within the last paragraph of Section 9.5 but didn't get it altogether = right. > When the protocol does not explicitly carry the scheme (e.g., as is > usually the case for HTTP/1.1 over TLS, servers can mitigate this > risk by either assuming that all requests have an insecure context, > or by refraining from advertising alternative services for insecure > schemes (such as HTTP). >=20 > The first parenthetical is opened with a left parenthesis but closed = with a comma. I'd suggest using commas to open and close that. The = second should just be separated by a preceding comma. Best regards, = Chris -- Mark Nottingham https://www.mnot.net/ From nobody Mon Feb 22 07:15:21 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799331B3537 for ; Mon, 22 Feb 2016 07:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 tkEU6B9c7ddV for ; Mon, 22 Feb 2016 07:15:18 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043ED1B3528 for ; Mon, 22 Feb 2016 07:15:17 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-12v.sys.comcast.net with comcast id MTEi1s0052EPM3101TFHL1; Mon, 22 Feb 2016 15:15:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-07v.sys.comcast.net with comcast id MTFG1s0043KdFy101TFGSr; Mon, 22 Feb 2016 15:15:17 +0000 To: David Mandelberg , iesg@ietf.org, secdir@ietf.org, draft-ietf-siprec-metadata.all@tools.ietf.org References: <56C0EB89.4050409@mandelberg.org> <56C15FB9.8030600@alum.mit.edu> <56C4B3D6.6040700@mandelberg.org> <56C4BA98.3080001@alum.mit.edu> <56CA4A7A.1050505@mandelberg.org> From: Paul Kyzivat Message-ID: <56CB2603.1020409@alum.mit.edu> Date: Mon, 22 Feb 2016 10:15:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CA4A7A.1050505@mandelberg.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456154117; bh=2h5tFB/JnlYLgy7SSaz9xibrPgIWfmHrEb86DybQCuc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=sANAVRBwDqJXPL2HrsiUwLWNJiJwKwCIy/Bx5Mw/c2sJCABvu/r/s+8PY2UJV2pKR k3VRvosdt6uqF1QYcB0AoVaouXDRclqimLHJNxx6DMO1paGFam6krnZUUlXHbZo0TW lgnCezs2XZ9BtubO82qsamFUiYc9OkbsWQsgf+MGgWfl851ordZhnboi8qdHg6cmFh PMxnC1M2tqcNKlV1Sz3O2jAcN1Df+Ollpq/RtnTfRzYfST9RNoM0vb2uZzYxK1EmZc vvvGd+biNIJAi15erEnxLlTSAzw2IPq0F38XJ0ClUZhOM6Q9q4VirCf4uNO6J6Drhc J+8dAl+jCs9aA== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-siprec-metadata-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 15:15:19 -0000 David, Thank you for being so clear. I think I now understand your perspective. I would like to have a discussion about this with the other authors and the WG before coming back with a definitive response. Thanks, Paul On 2/21/16 6:38 PM, David Mandelberg wrote: > Responses to your points are below, but I think it might also help if > I'm more clear about how I think this issue could be resolved. Here's > one way that seems reasonable to me, but is not the only way to prevent > the issue I brought up (unless I'm wrong and it's not an issue). > > Add text specifying that if an SRS receives more than one object defined > with the same UUID, the SRS MUST reject (or ignore?) all but the first > definition of the object. (This would ensure that UUIDs are actually > unique on a per-SRS basis.) Also, specify that an SRC MUST use a random > or pseudo-random method of generating UUIDs, and an SRC MUST NOT share > an object's UUID with anybody other than the SRS until after the SRS has > acknowledged receipt of that object. (This would ensure that the UUID > generated by the SRC points to the correct object.) > > Would that work? > > > On 02/17/2016 01:23 PM, Paul Kyzivat wrote: >> So your concern is the security implications when we have a malicious >> SRC that has been authorized by the SRS? > > Yes, but I didn't see anything in the draft saying that an SRC needs to > be authorized by the SRS, just that the SRS needs to be authorized by > the SRC. Maybe I missed that? Or maybe the Security Considerations could > be made more clear about exactly who needs to authenticate to whom and > who needs to make what authorization decisions based on that authentication? > > >> If so, it seems like that can extend to lots of things beyond reuse of >> UUIDs. > > The only issue I noticed was with the UUIDs. Otherwise it looks like an > SRS could record metadata from any untrusted SRC without any security > concerns other than the use of bandwidth, disk space, etc. (I could have > missed something of course.) > > >> (Going further afield, how does this differ from a malicious SIP UA that >> has the credentials to register a particular AoR? It could cause all >> sorts of mischief by unregistering valid UAs, etc. ISTM the bottom line >> is that it is impossible to avoid problems from a party with access to >> enough "secrets".) > > I'm not a SIP expert, but I think it needs to be made clear which pieces > of data are secrets in order to reason about the security of a system. > At present, I don't see any indication that UUIDs are meant to be > secrets. If they are supposed to be secrets, then I don't think they're > adequately protected from attackers who can guess the output of a > (potentially non-random) UUID generator. > > >> But the problem actually seems less severe in the case of SIPREC. The >> SRS is performing what is essentially an append-only write process. The >> use of a duplicate UUID by a malicious SRC doesn't cause any valid >> information to be lost. And the SRS is free to track the source of each >> piece of information it records, so that the malicious info can be >> sorted out from the valid info once the bad guy has been identified. > > I don't see any mention of append-only writing in the draft, so I don't > know how a server implementer would know to avoid overwriting of the > object for a specific UUID, thus modifying the meaning of metadata that > had previously been recorded from a different SRC. > > From nobody Mon Feb 22 10:24:17 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A451A8F42; Mon, 22 Feb 2016 10:24:14 -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 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 UGi7BKmbOcH6; Mon, 22 Feb 2016 10:24:13 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003: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 00FF81B2BCA; Mon, 22 Feb 2016 10:24:13 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id w5so60908566oie.3; Mon, 22 Feb 2016 10:24:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=x61mNxHgTP6nz70gYHbx0/MgcoSO+gUpGNUkvSaQ5jk=; b=uDw83xAKGOUqQLOaNWUC7poSM0BeG8VA/q0yltU+DRUA2NIxijgoYz6uDzBpOJtUAW 315GFxrSHyuTdJFwY8aTCCESRS8KkzHSuZ7+F/DIu9pG8KNqkHn8lOM7/zAxvvO6n8/6 J5i/MgRMoWx0ga7+qqSMTwFvH93E2yNn6HaqAUGS2pna3uAQkmjk4zcT5+yvf9NcRmRB E1bqr3/m7wWMrdEssDdXuMy1EwxdVbRTL32yMZ8PYPbxUvkJRQ3LPg14aBTd0pmOXaO5 UqeTtxMq4/sTgzFs0yNCu/JggTg7i+GHCcBMz2ZYEJ37Mz9RoBDAqyclDxvo9ywZQRaI /2wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=x61mNxHgTP6nz70gYHbx0/MgcoSO+gUpGNUkvSaQ5jk=; b=BpJcjkVnivkkd0nmKJuDIC3+BNvth5EyemiaIZ0LiCnFslXqzZs6oUqe6wq06lp3Jm GazaZsf+yPRD1sC/vFfWdNGsMaiOpA5+TTMzxNReeMoZ4LQoSEu/KLTQ6NTxojByEWiY QHQggxaiVOXrye/Gl3YgDYq1UYpw2cUcpYtVzXyxuiRAKQtEo1nquHZkV2T1UJLAavgx KtWHjuSzl8Emj5vNop2K8PMPbgUgX6AkinQo3LtcCmnSzcYcG0z/I1bdcC+/f7hDBbw3 tPOO+rDPlnKNU7ktapXOCIjotTCVEUNG+3f3QpuUCWIlUMSAFUPHCVj67rnCEZOJrqHy 6CkA== X-Gm-Message-State: AG10YOT+Wbbqx4kGX1PIprovson8o+NyoRjCaQ8ANAuZ0buxCJAT8EzZCVB/SSkqtNG8Lg== X-Received: by 10.202.104.169 with SMTP id o41mr23243429oik.57.1456165452428; Mon, 22 Feb 2016 10:24:12 -0800 (PST) Received: from macbook-pro-2.attlocal.net (99-64-100-131.lightspeed.austtx.sbcglobal.net. [99.64.100.131]) by smtp.gmail.com with ESMTPSA id i5sm17507701obe.14.2016.02.22.10.24.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Feb 2016 10:24:10 -0800 (PST) From: Adam Montville Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <020C51E3-4211-4C6D-9DE4-863F5004FA30@gmail.com> Date: Mon, 22 Feb 2016 12:24:09 -0600 To: The IESG , secdir@ietf.org, draft-ietf-mmusic-proto-iana-registration.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [secdir] SECDIR review of draft-ietf-mmusic-proto-iana-registration-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 18:24:14 -0000 Hi, I have reviewed this document as part of the security directorate=E2=80=99= 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 the transport realization for seven additional = Session Description Protocol identifiers and creates a corresponding = IANA registry for such, and relies on previously written security = considerations, as it does not appear to introduce any new = considerations. Overall, this document is straightforward in purpose and is ready with = nits. =20 Possibly minor nits: The first use of =E2=80=9CSDP=E2=80=9D in the first section is not = spelled out. I know that it is spelled out in the abstract, and I = cannot recall what is/is not good form here. To me, it would be more = helpful if SDP were spelled out one more time in that first section = (second paragraph of section 1). In general, I favor writing for the reader over writing for the author. = As such I do not prefer using RFC identifiers as a replacement for a = proper title, which would convey more meaning without dereferencing. = For example, in the second sentence of the second paragraph of section = 1: =E2=80=9C[RFC4145] specifies a general mechanism for=E2=80=A6=E2=80=9D = gets in the way of the primary purpose of the sentence when the reader = needs to look up that reference to gain a clue. This is especially true = for readers new to the problem domain, which also means that this nit = may not apply (it may well be expected that readers of this particular = draft are not reasonably expected to be new to the domain).=20 Kind regards, Adam From nobody Thu Feb 25 02:05:46 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5921A8A47 for ; Thu, 25 Feb 2016 02:05:45 -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 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 W_wEDFH3NW80 for ; Thu, 25 Feb 2016 02:05:44 -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 97E571A8A41 for ; Thu, 25 Feb 2016 02:05:42 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1PA5dtH012424 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 25 Feb 2016 12:05:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1PA5dXh000488; Thu, 25 Feb 2016 12:05:39 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22222.53747.246443.890352@fireball.acr.fi> Date: Thu, 25 Feb 2016 12:05:39 +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.15 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, 25 Feb 2016 10:05:46 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Rifaat Shekh-Yusef is next in the rotation. For telechat 2016-03-03 Reviewer LC end Draft Leif Johansson T 2016-02-10 draft-ietf-dprive-edns0-padding-02 Sandy Murphy T 2016-03-01 draft-ietf-ntp-checksum-trailer-04 For telechat 2016-03-17 Radia Perlman T 2016-03-04 draft-ietf-p2psip-concepts-08 Vincent Roca T 2016-03-09 draft-ietf-rtcweb-audio-10 Joe Salowey T 2016-03-09 draft-ietf-rtcweb-audio-codecs-for-interop-05 Last calls and special requests: Donald Eastlake R2016-02-22 draft-ietf-dane-openpgpkey-07 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Jeffrey Hutzelman 2015-12-04 draft-ietf-core-block-18 Chris Inacio 2016-02-02 draft-ietf-v6ops-ipv6-ehs-in-real-world-02 Alexey Melnikov 2016-03-07 draft-wallace-est-alt-challenge-04 Matthew Miller 2016-02-26 draft-ietf-avtext-splicing-notification-04 Yoav Nir 2016-03-09 draft-bao-v6ops-rfc6145bis-05 Magnus Nystrom 2016-03-09 draft-ietf-avtcore-rtp-circuit-breakers-13 Hilarie Orman 2016-03-09 draft-ietf-netmod-yang-json-08 Eric Osterweil 2016-01-05 draft-campbell-art-rfc5727-update-02 Eric Osterweil 2016-03-09 draft-ietf-netmod-yang-metadata-04 Rich Salz 2016-03-08 draft-ietf-tictoc-ptp-mib-08 Yaron Sheffer 2016-03-09 draft-ietf-v6ops-host-addr-availability-05 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-12 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-05 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-03 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-06 -- kivinen@iki.fi From nobody Thu Feb 25 14:55:24 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 7E3221B371C; Thu, 25 Feb 2016 14:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1456440468; bh=pWfVYzsuXJjIkbKFj5SC7QOewju6Lc1+LCR5uoLkoLY=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=QZLJ9rBDEnnZaVWX1XV7ogA44+j3Z7I6m5TuwcRAnSxfKcyb8wTbcfN3EZEoYO/zp nl7uPLDBEkB2yT/ditP8o+j/Pay3rlJVLxFtH2XdZuf2cz/hMhhxBVE1LvtPNZEth6 QoaElMyqJFykzl88JRSK8ErVYZWUS2//GYj2qZI0= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 784C21B36E4 for ; Thu, 25 Feb 2016 14:47:44 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <20160225224744.17401.37173.idtracker@ietfa.amsl.com> Date: Thu, 25 Feb 2016 14:47:44 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 25 Feb 2016 14:55:23 -0800 Subject: [secdir] [new-work] WG Review: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 22:47:48 -0000 The IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG in the Internet Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org by 2016-03-03. IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) ----------------------------------------------------------------------- Current status: Active WG Chairs: Pascal Thubert Thomas Watteyne Assigned Area Director: Brian Haberman Internet Area Directors: Brian Haberman Terry Manderson Mailing list: Address: 6tisch@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/6tisch Archive: https://mailarchive.ietf.org/arch/browse/6tisch/ Charter: https://datatracker.ietf.org/doc/charter-ietf-6tisch/ 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e". Background/Introduction: ------------------------ Low-power and Lossy Networks (LLNs) interconnect a possibly large number of resource-constrained nodes to form a wireless mesh network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at various layers of the protocol stack, including an IPv6 adaptation layer, a routing protocol and a web transfer protocol. This protocol stack has been used with IEEE802.15.4 low-power radios. The Timeslotted Channel Hopping (TSCH) mode was introduced in 2012 as an amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4 standard. TSCH is the emerging standard for industrial automation and process control LLNs, with a direct inheritance from WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the further adoption of IPv6 in industrial standards and the convergence of Operational Technology (OT) with Information Technology (IT). The nodes in a IEEE802.15.4 TSCH network communicate by following a Time Division Multiple Access (TDMA) schedule. A timeslot in this schedule provides a unit of bandwidth that is allocated for communication between neighbor nodes. The allocation can be programmed such that the predictable transmission pattern matches the traffic. This avoids idle listening, and extends battery lifetime for constrained nodes. Channel-hopping improves reliability in the presence of narrow- band interference and multi-path fading. These techniques enable a new range of use cases for LLNs, including: - Control loops in a wireless process control network, in which high reliability and a fully deterministic behavior are required. - Service Provider networks transporting data from different independent clients, and for which an operator needs flow isolation and traffic shaping. - Networks comprising energy harvesting nodes, which require an extremely low and predictable average power consumption. IEEE802.15.4 only defines the link-layer mechanisms. It does not define how the network communication schedule is built and matched to the traffic requirements of the network. Description of Working Group: ----------------------------- The Working Group will focus on enabling IPv6 over the TSCH mode of the IEEE802.15.4 standard. The extent of the problem space for the WG is one or more LLNs, possibly federated through a common backbone link via one or more LLN Border Routers (LBRs). The WG will rely on, and if necessary extend, existing mechanisms for authenticating LBRs. Initially, the WG has limited its scope to distributed routing over a static schedule using the Routing Protocol for LLNs (RPL) on the resulting network. This new charter allows for the dynamic allocation of cells and their exchange between adjacent peers to accommodate the available bandwidth to the variations of throughput in IP traffic. The WG will continue working on securing the join process and making that fit within the constraints of high latency, low throughput and small frame sizes that characterize IEEE802.15.4 TSCH. Additionally, IEEE802.15.4 TSCH being a deterministic MAC, it is envisioned that 6TiSCH will benefit from the work of DetNet WG to establish the so-called deterministic tracks. The group will define the objects and methods that need to be configured, and provide the associated requirements to DetNet. The WG will interface with other appropriate groups in the IETF Internet, Operations and Management, Routing and Security areas. Work Items: ----------- The group will: - Produce a specification of the 6top sublayer that describes the protocol for neighbor nodes to negotiate adding/removing cells. This work will leverage cross participation from IEEE members including the IEEE 6TiSCH Interest Group (IG 6T) to define protocol elements and associated frame formats. - Produce a specification for a default 6top Scheduling Function including the policy to enable distributed dynamic scheduling of timeslots for IP traffic. This may include the capability for nodes to appropriate chunks of the matrix without starving, or interfering with other 6TiSCH nodes. This particular work will focus on IP traffic since the work on tracks is not yet advanced enough to specify their requirements. - Produce requirements to the DetNet WG, detailing 6TiSCH chunks and tracks, and the data models to manipulate them from an external controller such as a PCE. - Produce a specification for a secure 6TiSCH network bootstrap, adapted to the constraints of 6TiSCH nodes and leveraging existing art when possible. - Keep updating the "6TiSCH architecture" that describes the design of 6TiSCH networks. This document highlights the different architectural blocks, signaling and data flows, including the operation of the network in the presence of multiple LBRs. The existing document will be augmented to cover dynamic scheduling and application of the DetNet work but will not be delivered within this round of chartering. - Producing a YANG Data Models to manage 6tisch is foreseen, but left to a later phase. Non-milestone work items: ------------------------- The Working Group regularly organizes interoperability events with support from ETSI (i.e., ETSI 6TiSCH Plugtests) to get feedback from implementers early on in the standardization process, and produce better standards. Milestones: Apr 2016 - Second submission of draft-ietf-6tisch-minimal to the IESG Apr 2016 - WG call to adopt draft-ietf-6tisch-6top-sf0 Apr 2016 - WG call to adopt draft-ietf-6tisch-6top-sublayer Jul 2016 - ETSI 6TiSCH #3 plugtests Jul 2016 - Initial submission of draft-ietf-6tisch-6top-sublayer to the IESG Oct 2016 - Initial submission of draft-ietf-6tisch-6top-sf0 to the IESG Dec 2016 - Evaluate WG progress, propose new charter to the IESG Apr 2017 - Initial submission of 6TiSCH terminology to the IESG Apr 2017 - Initial submission of 6TiSCH architecture to the IESG Dec 2017 - 6TiSCH architecture and terminology in RFC publication queue _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Feb 25 17:01:45 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75EC1A0199; Thu, 25 Feb 2016 17:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 7sICxYQpbdvh; Thu, 25 Feb 2016 17:01:38 -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 9E5DE1A0174; Thu, 25 Feb 2016 17:01:38 -0800 (PST) X-AuditID: 12074423-5c3ff70000006586-9c-56cfa3f17a86 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 EC.C9.25990.1F3AFC65; Thu, 25 Feb 2016 20:01:37 -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 u1Q11anj029879; Thu, 25 Feb 2016 20:01:36 -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 u1Q11Ym1008474; Thu, 25 Feb 2016 20:01:35 -0500 From: Tom Yu To: Mahesh Jethanandani References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> Date: Thu, 25 Feb 2016 20:01:33 -0500 In-Reply-To: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> (Mahesh Jethanandani's message of "Mon, 15 Feb 2016 13:28:40 -0800") Message-ID: Lines: 59 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixG6nrvtx8fkwg8lTuCweHG5hs5jxZyKz xek369gsPix8yOLA4rFz1l12jyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoErY+b130wFM8Uq Lk39wdLA2C3UxcjJISFgInH1w2nmLkYuDiGBNiaJWd8Xs0A4GxklHjYdYAKpEhJ4wyix7IU5 iM0mIC1x/PIusLiIgKHEqQMvwGxmgTyJsx/egdnCAg4SO8+vY4ToTZDYde0MK4jNIqAq0X96 LhPIAk6BFkaJ/uWnwRK8AroSbS1vgTZzcPAIcEosWRoPERaUODnzCQvEfC2JG/9eMk1g5J+F JDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXTO93MwSvdSU0k2M4LB0Ud7B+Oeg0iFG AQ5GJR5ehp9nw4RYE8uKK3MPMUpyMCmJ8gbOPR8mxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3 chlQjjclsbIqtSgfJiXNwaIkzhtz82iYkEB6YklqdmpqQWoRTFaGg0NJgnfFIqBGwaLU9NSK tMycEoQ0EwcnyHAeoOECi0GGFxck5hZnpkPkTzEqSonzmoM0C4AkMkrz4HrBaUOIcd8rRnGg V4R580GqeIApB677FdBgJqDBMzecAxlckoiQkmpgNGpOdxavSUuccfGGLM8FDrnNbv+dq9+c DLgjonY29d2yX5ovr13LXrjyxpFX3zsuCsn5nReR+bI06HqGq7xZUkN063nXc40nPu/NZc96 s7HCPmtd9a+ZKeLHljArdh0Prb00xdkvlkf5y8NvkgZWW4pt581bcuKL9qO6BVd2yVe7B29V nSlZqMRSnJFoqMVcVJwIAIeX6o/2AgAA Archived-At: Cc: draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 01:01:40 -0000 Hi Mahesh, Sorry about the delay. I was looking at the specific comments in the Security Considerations of this document about the sensitivity of the contents of /modules/module. How do the risks of an attacker being able to inspect /modules/module compare with other information that could be available to an attacker, such as fingerprinting through non-NETCONF means? If an attacker has limited NETCONF access on a server, what would the contents of /modules/module reveal to the attacker that might not otherwise be discovered by other kinds of probing within the NETCONF protocol? These other risks might be trivial in comparison to the one mentioned in the document, but lacking specific knowledge of the broader context of NETCONF and how it is deployed, I'm not sure how they compare. For example, is it expected that anonymous or minimally trusted users could be authorized to use NETCONF to access some public information about a server? If these other risks are similar in magnitude to the possible exposures allowed by /modules/module, you should consider mentioning them, and give the implementor or operator some guidance about how to weigh these risks. If the exposures allowed by /modules/module vastly outweigh those from other avenues of obtaining similar capability or configuration information, in most environments and forseeable deployments, maybe the current text is sufficient. -Tom Mahesh Jethanandani writes: > Tom, > > It is not entirely clear from this e-mail, what action you want the authors to take. > > YANG module information or more like its encodings are sent over a secure session (SSH/TLS) and are no more specific to this draft than they are to any NETCONF/RESTCONF session. As such it is not clear what you want the authors to do. Could you clarify or provide text for the Security Consideration section? > > Thanks. > >> On Feb 1, 2016, at 6:03 PM, Tom Yu wrote: >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> The Security Considerations of this document seem reasonable. It might >> be useful to add a comparison of the risks posed by sensitive >> information exposed by this YANG module with information exposed by >> other aspects of NETCONF, or available through methods such as >> fingerprinting. Admittedly, a meaningful comparison might be highly >> context-specific, so a general comparison might have limited utility. > > Mahesh Jethanandani > mjethanandani@gmail.com From nobody Fri Feb 26 15:12:05 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8321B32A3; Fri, 26 Feb 2016 15:12:02 -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 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 sr176HvyR3Yw; Fri, 26 Feb 2016 15:12:00 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 49EB01B32A0; Fri, 26 Feb 2016 15:11:59 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id q63so59208489pfb.0; Fri, 26 Feb 2016 15:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=2AQltzrPhSGoWkIK2nJvpYEVOmLHAcxfRpp56dFYOTE=; b=UkXxPO5mbcAOb0SCalStcRq5k+ypLhgze53w7nguY2h2a+QBXGEZXGFue13ESxFBiM 6Uu+3F2esl02RcLkv+M6LoMqs+uSrNiJ+7SYHiqMrmGbyBpEdnVKyyYJSO0kOYHyoQla Rd++0bLwvmpz1taxzTBuVdAu1wjyZRh3gQW7vFE3sgOg/KUUw1d8AEgk11lpktSaPSI7 CPlvRJiirODp+55B/i0B4zMEReHvhAhj24hrkrZdJRcdDlGXXDa5236+ZE0Lhbs5Uumm HfqbeCkosi+bUX/KI8/3lKiv2nKo8gJVrluhyr/PaWfRSA5k+kEOX0XtGU8f80zV07J/ pjuA== 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 :message-id:references:to; bh=2AQltzrPhSGoWkIK2nJvpYEVOmLHAcxfRpp56dFYOTE=; b=E3F3X4zarR2EPo83OHly/NCnHpV761LWV3TK/ON70K5tiJFUjymhNcU/GIxBG51w+W N3uYIJgkJVXlynWqLfIPDlXPXFyetH9VpVIM1zV15mrz3VkHLFmtUCouEIpbg5slv6HU /A+nZxwLKEFIBEhIWq4MJCIybbyPqY04wFJgIs0polr8q8W+FWKzPjU7xplR+B+QfpEm 9BOaARM0uZH8SJLDuc3E+cAcfhoPsNNr6GIyQOTvOUA+NFonA/2xz099fz+ei5uc5HJO Xs8mdcwmXWakGuF0qvMLtZI9VPXKiovAWcX3XXt7+hsF8lEGmuamIk4A2agWIpwZ/98E lPQw== X-Gm-Message-State: AD7BkJKw7ojc69IEj3ZelDy7GRPR6Kfily+KueFJQR/EptT5ILE23CxjrNcjhlooEwHqxQ== X-Received: by 10.98.31.21 with SMTP id f21mr5514853pff.134.1456528318955; Fri, 26 Feb 2016 15:11:58 -0800 (PST) Received: from dhcp-171-71-145-111.cisco.com (dhcp-171-71-145-111.cisco.com. [171.71.145.111]) by smtp.gmail.com with ESMTPSA id y68sm21653964pfi.6.2016.02.26.15.11.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Feb 2016 15:11:57 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6A25B0AE-112B-4625-B919-3F912773C4CE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mahesh Jethanandani In-Reply-To: Date: Fri, 26 Feb 2016 15:12:01 -0800 Message-Id: <2BC76448-BCD9-4B69-AF8E-A1D81D40A33B@gmail.com> References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> To: Tom Yu X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 23:12:02 -0000 --Apple-Mail=_6A25B0AE-112B-4625-B919-3F912773C4CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, Thanks for getting back to us.=20 At the outset let me just say that this draft is defining a new = mechanism for advertisement of capabilities within YANG modules. As = such, the security considerations for this document are not very = different from the security considerations one might have using the = NETCONF protocol today. Some of the information is already being = exchanged today through other mechanisms.=20 To your specific comments... > On Feb 25, 2016, at 5:01 PM, Tom Yu wrote: >=20 > Hi Mahesh, >=20 > Sorry about the delay. >=20 > I was looking at the specific comments in the Security Considerations = of > this document about the sensitivity of the contents of = /modules/module. > How do the risks of an attacker being able to inspect /modules/module > compare with other information that could be available to an attacker, > such as fingerprinting through non-NETCONF means? The attacker may have better success getting the information through = some other means, and even then the information would be no more = damaging than what they would be able to see if they had the right = SSH/NACM credentials. >=20 > If an attacker has limited NETCONF access on a server, what would the > contents of /modules/module reveal to the attacker that might not > otherwise be discovered by other kinds of probing within the NETCONF > protocol? With limited access most of the information about the modules/module = will not be visible. >=20 > These other risks might be trivial in comparison to the one mentioned = in > the document, but lacking specific knowledge of the broader context of > NETCONF and how it is deployed, I'm not sure how they compare. For > example, is it expected that anonymous or minimally trusted users = could > be authorized to use NETCONF to access some public information about a > server? No. There is no anonymous or minimal trusted user account (by default). = Accounts have to be setup for users to access the box over NETCONF and = then they are typically assigned to a authorized group with specific = permissions. Thanks. >=20 > If these other risks are similar in magnitude to the possible = exposures > allowed by /modules/module, you should consider mentioning them, and > give the implementor or operator some guidance about how to weigh = these > risks. If the exposures allowed by /modules/module vastly outweigh > those from other avenues of obtaining similar capability or > configuration information, in most environments and forseeable > deployments, maybe the current text is sufficient. >=20 > -Tom >=20 > Mahesh Jethanandani writes: >=20 >> Tom, >>=20 >> It is not entirely clear from this e-mail, what action you want the = authors to take.=20 >>=20 >> YANG module information or more like its encodings are sent over a = secure session (SSH/TLS) and are no more specific to this draft than = they are to any NETCONF/RESTCONF session. As such it is not clear what = you want the authors to do. Could you clarify or provide text for the = Security Consideration section? >>=20 >> Thanks. >>=20 >>> On Feb 1, 2016, at 6:03 PM, Tom Yu wrote: >>>=20 >>> I have reviewed this document as part of the security directorate's=20= >>> ongoing effort to review all IETF documents being processed by the=20= >>> IESG. These comments were written primarily for the benefit of the=20= >>> security area directors. Document editors and WG chairs should = treat=20 >>> these comments just like any other last call comments. >>>=20 >>> The Security Considerations of this document seem reasonable. It = might >>> be useful to add a comparison of the risks posed by sensitive >>> information exposed by this YANG module with information exposed by >>> other aspects of NETCONF, or available through methods such as >>> fingerprinting. Admittedly, a meaningful comparison might be highly >>> context-specific, so a general comparison might have limited = utility. >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_6A25B0AE-112B-4625-B919-3F912773C4CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Tom,

Thanks= for getting back to us. 

At the outset let me just say that this = draft is defining a new mechanism for advertisement of = capabilities within YANG modules. As such, the security considerations = for this document are not very different from the security = considerations one might have using the NETCONF protocol today. Some of = the information is already being exchanged today through other = mechanisms. 

To your specific comments...

On Feb 25, 2016, at 5:01 PM, Tom Yu <tlyu@mit.edu> = wrote:

Hi = Mahesh,

Sorry about the delay.

I was looking at the specific comments in the = Security Considerations of
this document about the = sensitivity of the contents of /modules/module.
How do the = risks of an attacker being able to inspect /modules/module
compare with other information that could be available to an = attacker,
such as fingerprinting through non-NETCONF = means?

The = attacker may have better success getting the information through some = other means, and even then the information would be no more damaging = than what they would be able to see if they had the right SSH/NACM = credentials.


If an attacker has limited = NETCONF access on a server, what would the
contents of = /modules/module reveal to the attacker that might not
otherwise be discovered by other kinds of probing within the = NETCONF
protocol?

With limited access most of the information about the = modules/module will not be visible.


These other = risks might be trivial in comparison to the one mentioned in
the document, but lacking specific knowledge of the broader = context of
NETCONF and how it is deployed, I'm not sure = how they compare.  For
example, is it expected that = anonymous or minimally trusted users could
be authorized = to use NETCONF to access some public information about a
server?

No. There is no anonymous or minimal trusted user = account (by default). Accounts have to be setup for users to access the = box over NETCONF and then they are typically assigned to a authorized = group with specific permissions.

Thanks.


If these other = risks are similar in magnitude to the possible exposures
allowed by /modules/module, you should consider mentioning = them, and
give the implementor or operator some guidance = about how to weigh these
risks.  If the exposures = allowed by /modules/module vastly outweigh
those from = other avenues of obtaining similar capability or
configuration information, in most environments and = forseeable
deployments, maybe the current text is = sufficient.

-Tom

Mahesh Jethanandani <mjethanandani@gmail.com> writes:

Tom,

It is not entirely clear from this e-mail, what action you = want the authors to take.

YANG module = information or more like its encodings are sent over a secure session = (SSH/TLS) and are no more specific to this draft than they are to any = NETCONF/RESTCONF session. As such it is not clear what you want =  the authors to do. Could you clarify or provide text for the = Security Consideration section?

Thanks.

On Feb 1, = 2016, at 6:03 PM, Tom Yu <tlyu@mit.edu> wrote:

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

The Security Considerations of this document seem reasonable. =  It might
be useful to add a comparison of the risks = posed by sensitive
information exposed by this YANG module = with information exposed by
other aspects of NETCONF, or = available through methods such as
fingerprinting. =  Admittedly, a meaningful comparison might be highly
context-specific, so a general comparison might have limited = utility.

Mahesh = Jethanandani
mjethanandani@gmail.com

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_6A25B0AE-112B-4625-B919-3F912773C4CE--