From new-work-bounces@ietf.org Wed May 1 13:40:49 2013 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 0D65921F9ABC; Wed, 1 May 2013 13:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1367440849; bh=5WGdttqCafKP2EzZlX6X86wgMXA6yrW0XWXRIuVR5Wc=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=kqfkNXeAeMkxG2fqlT8ZFIds7g9BEZMhbpZ9PoDkW5IwvGZ5p1P8g8oPmiccM7daq hUV9El/mARDjm0wSDJJnvaJKy9yF78Vsl+KVKXg1jCc9FP9zLA2pwz8xxX2d6N+DcB RxsTwjaorWZf9TdhxO3v0sXr6pP6ikbZh0ermiTE= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB27721F9ABC for ; Wed, 1 May 2013 13:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAU10ovyIbJn for ; Wed, 1 May 2013 13:40:41 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id C7B5821F9ABB for ; Wed, 1 May 2013 13:40:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UXdpQ-00029Y-Sy; Wed, 01 May 2013 16:40:41 -0400 From: Ian Jacobs Date: Wed, 1 May 2013 15:40:25 -0500 To: new-work@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 01 May 2013 14:14:48 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: HTML Working Group (until 2013-05-29) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 20:40:49 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the HTML Working Group [0] including this draft charter: http://www.w3.org/html/wg/charter/2013/ 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 2013-05-29 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 [2], 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 Mike Smith, HTML Working Group Team Contact . Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/html/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs http://www.w3.org/People/Jacobs Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From kivinen@iki.fi Thu May 2 04:36:31 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E6B21F99B7 for ; Thu, 2 May 2013 04:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhHlI7Yug0RU for ; Thu, 2 May 2013 04:36:31 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 88CAF21F99B6 for ; Thu, 2 May 2013 04:36:29 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r42BaOk2003078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 May 2013 14:36:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r42BaO6V028822; Thu, 2 May 2013 14:36:24 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20866.20407.878816.216843@fireball.kivinen.iki.fi> Date: Thu, 2 May 2013 14:36:23 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2013 11:36:31 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Paul Hoffman is next in the rotation. For telechat 2013-05-16 Reviewer LC end Draft Dave Cridland T 2013-05-06 draft-ietf-dhc-triggered-reconfigure-05 Shawn Emery T 2013-05-03 draft-ietf-netmod-interfaces-cfg-10 Tobias Gondrom T 2013-05-03 draft-ietf-netmod-ip-cfg-09 Steve Hanna T 2013-05-08 draft-ietf-trill-fine-labeling-06 Dan Harkins TR2013-04-01 draft-ietf-ipfix-flow-selection-tech-16 Eric Rescorla T 2013-04-10 draft-ietf-6renum-gap-analysis-06 Ondrej Sury T 2013-04-23 draft-ietf-manet-olsrv2-mib-07 Nico Williams T 2013-05-01 draft-ietf-netmod-rfc6021-bis-01 For telechat 2013-05-30 Rob Austein T 2013-05-06 draft-ietf-bmwg-imix-genome-04 Last calls and special requests: Derek Atkins 2013-05-10 draft-sheffer-running-code-04 Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-05-06 draft-ietf-geopriv-held-measurements-07 Donald Eastlake 2013-05-03 draft-ietf-geopriv-relative-location-04 Dan Harkins 2013-05-15 draft-ietf-6man-addr-select-opt-10 David Harrington 2013-05-09 draft-ietf-6man-impatient-nud-06 Sam Hartman 2013-05-13 draft-ietf-forces-interop-07 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Russ Mundy 2013-03-30 draft-ietf-roll-terminology-12 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 Carl Wallace 2013-05-07 draft-sparks-genarea-imaparch-06 David Waltermire 2013-05-14 draft-housley-rfc2050bis-01 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-06 Brian Weis 2013-05-01 draft-ietf-ipfix-protocol-rfc5101bis-06 Nico Williams - draft-ietf-httpbis-p5-range-22 -- kivinen@iki.fi From fgont@si6networks.com Thu May 2 11:38:14 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3D821F9199; Thu, 2 May 2013 11:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+i0ohugCcP1; Thu, 2 May 2013 11:38:13 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9262E21F9193; Thu, 2 May 2013 11:38:13 -0700 (PDT) Received: from [186.134.26.236] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UXyOI-0006xX-K1; Thu, 02 May 2013 20:38:02 +0200 Message-ID: <5182B282.4000307@si6networks.com> Date: Thu, 02 May 2013 15:37:54 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <516DD980.10806@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-opsec-ipv6-implications-on-ipv4-nets.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 18:38:14 -0000 >>> It seems the document should at least mention this risk in the >>> security considerations since hosts on these networks may be IPv6 >>> enabled. One related issue I have seen is in end host >>> configuration where a host based firewall is configured with IPv4 >>> rules and left silent on IPv6 with varying results. I don't >>> recall seeing any discussion of this in the document, but it >>> might also be worth covering in security considerations as well. >> >> Isn't this covered in the "native ipv6" section? > > [Joe] I was thinking of having some text that is a bit more host > centric. I've added this parenthetical note to Section 1: The aforementioned security controls should contemplate not only network-based solutions, but also host-based solutions (such as e.g. personal firewalls). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From d3e3e3@gmail.com Fri May 3 21:05:32 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DF621F8FAC; Fri, 3 May 2013 21:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04SdFtZv+FMh; Fri, 3 May 2013 21:05:32 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id E868E21F8FAB; Fri, 3 May 2013 21:05:24 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id tb18so1929040obb.28 for ; Fri, 03 May 2013 21:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to:cc :content-type; bh=G2T6U/bSHx+dDP3Lqx3uhbofoyHPIuQ50YD5gafQ6QU=; b=XCZIvVJl+YxBJ0mnZ8NngB4UvecBIEht28o7JOcEFhw4dKJFMmTkHf4tp+A53/q9Mo gyFCRJnaqOaOdeQoK44Kc4H5zjD8Pn3ohBLtZtYIEnUZ1PxAPjrRagUUtQ5S7ItO43DD oYXzYKVMFFcXv0ShbytyfXYyukAJyTFZIIavYZxu2Iu2/xyhwrQ46clwnlDvwRhOWReV Zw/tUhs1dsP3Wo6KVyiEI3bGRP+pjhHpMIL/74JBpjxNNecfTKGhKbl8qz0jwR2dzCTf FqQKUO2PxTvYe+/tsmkUTtczj3lgpaQOoIky4BB51uC/qXYLpIBTdh35J6XVpLacmRyB OVrg== X-Received: by 10.182.16.170 with SMTP id h10mr598843obd.17.1367640324523; Fri, 03 May 2013 21:05:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Fri, 3 May 2013 21:05:04 -0700 (PDT) From: Donald Eastlake Date: Sat, 4 May 2013 00:05:04 -0400 Message-ID: To: iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-geopriv-relative-location.all@tools.ietf.org, secdir@ietf.org Subject: [secdir] draft-ietf-geopriv-relative-location-04 SecDir Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 04:05:33 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies an extension to the Presence Information Data Format Location Object (PIDF-LO, RFC 4119) so that location information can be given relative to a base point. It is pretty general, allowing the relative location to be various shapes or specified with a map. Both XML and TLV representations are provided. The Security Considerations section seems reasonable to me for a data format specification document. It refers to the base RFC 4119 specification be also briefly touches on a covert channel that the representation would otherwise have made available in some cases. I feel comfortable with the existing Security Considerations section. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From carl@redhoundsoftware.com Sun May 5 07:00:24 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF0B21F937E for ; Sun, 5 May 2013 07:00:24 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ2vbyULWGKH for ; Sun, 5 May 2013 07:00:24 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0411B21F933B for ; Sun, 5 May 2013 07:00:23 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id bs12so1060615qab.2 for ; Sun, 05 May 2013 07:00:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=b3rT9rcm3Bo/duQP01DCVQHhzIEDzXpR3zHQq/YUV6s=; b=KgJ3EkVFes8nomFk7xUEmJtfAk09JpAePRehbhLesfpU/+8/RxkdoqIalio9nhr94l ve+vhZzFOQw4Rtw0TlDEfWofeWwR2lHQKIDAZtiAuvQcvH9+yzTF3azsMgCKk7NGWQWo ots/J8Xh9dCVUXzvufbVJ8qM33ufF4buy4lTzUwLhIN1jrCG/Z2Zl1dEVuwhvDklYgYb tX06dQaic5Y5PhI0/TOqsg5sWkMKxTPaRggxZaS8F207lIRURcAyhxmJJHGb5nYGDlcs uCjL15N3qG/o6PtlQtL3Waqn5UZXHm+omhgWBduqOcsAo0daTdAY6oLj2PfEeMTwUR4V 3zxw== X-Received: by 10.224.198.134 with SMTP id eo6mr3934734qab.74.1367762423424; Sun, 05 May 2013 07:00:23 -0700 (PDT) Received: from [192.168.2.7] (pool-173-79-106-247.washdc.fios.verizon.net. [173.79.106.247]) by mx.google.com with ESMTPSA id fq5sm31809495qab.2.2013.05.05.07.00.20 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 05 May 2013 07:00:22 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Sun, 05 May 2013 10:00:22 -0400 From: Carl Wallace To: Message-ID: Thread-Topic: secdir review of draft-sparks-genarea-imaparch Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQkjr/uzAY9woQCj+v/VOEN8pkVZb8EYJM91IqnudXtwYqLtpuuJJRlrR9jS7BfES+bNIUQT Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-sparks-genarea-imaparch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 14:00:24 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes the requirements for providing an IMAP interface for IETF mail archives. The first item in the security considerations is correct, but in general the security considerations seem too narrowly focused on searching and storage. Some discussion of the following may be worthwhile: how the server is authenticated to users, how users are authenticated to the server (unless the reference to the datatracker system is viewed as sufficient), details of the interface with the datatracker authentication system, (maybe) how archive integrity is maintained, identification of what should or should not be logged. From kivinen@iki.fi Tue May 7 04:01:10 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5943321F8B18 for ; Tue, 7 May 2013 04:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DM+tnWir09mJ for ; Tue, 7 May 2013 04:00:58 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 597AD21F872E for ; Tue, 7 May 2013 04:00:56 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r47B0pUJ027762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 May 2013 14:00:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r47B0lVi018186; Tue, 7 May 2013 14:00:47 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20872.57055.690263.450632@fireball.kivinen.iki.fi> Date: Tue, 7 May 2013 14:00:47 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 07 May 2013 11:01:10 -0000 Bit earlier this week as I will be away for next few days. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Charlie Kaufman is next in the rotation. For telechat 2013-05-16 Reviewer LC end Draft Dave Cridland T 2013-05-06 draft-ietf-dhc-triggered-reconfigure-06 Shawn Emery T 2013-05-03 draft-ietf-netmod-interfaces-cfg-10 Tobias Gondrom T 2013-05-03 draft-ietf-netmod-ip-cfg-09 Steve Hanna T 2013-05-08 draft-ietf-trill-fine-labeling-06 Dan Harkins TR2013-04-01 draft-ietf-ipfix-flow-selection-tech-16 Jeffrey Hutzelman T 2013-05-06 draft-ietf-dhc-triggered-reconfigure-06 Eric Rescorla T 2013-04-10 draft-ietf-6renum-gap-analysis-06 Joe Salowey TR2013-04-12 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-04 Ondrej Sury T 2013-04-23 draft-ietf-manet-olsrv2-mib-07 Nico Williams T 2013-05-01 draft-ietf-netmod-rfc6021-bis-01 For telechat 2013-05-30 Rob Austein T 2013-05-06 draft-ietf-bmwg-imix-genome-04 Paul Hoffman T 2013-05-06 draft-ietf-bmwg-imix-genome-04 Last calls and special requests: Derek Atkins 2013-05-10 draft-sheffer-running-code-04 Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-05-06 draft-ietf-geopriv-held-measurements-07 Dan Harkins 2013-05-15 draft-ietf-6man-addr-select-opt-10 David Harrington 2013-05-09 draft-ietf-6man-impatient-nud-06 Sam Hartman 2013-05-13 draft-ietf-forces-interop-07 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Leif Johansson 2013-05-20 draft-ietf-ipsecme-dh-checks-04 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Russ Mundy 2013-03-30 draft-ietf-roll-terminology-12 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 David Waltermire 2013-05-14 draft-housley-rfc2050bis-01 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-06 Brian Weis 2013-05-01 draft-ietf-ipfix-protocol-rfc5101bis-06 Nico Williams - draft-ietf-httpbis-p5-range-22 -- kivinen@iki.fi From gonzalo.camarillo@ericsson.com Tue May 7 04:02:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D2321F8E9A; Tue, 7 May 2013 04:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFscTgM7X3RX; Tue, 7 May 2013 04:02:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCDA21F8733; Tue, 7 May 2013 04:02:38 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-94-5188df4da9ac Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 36.67.32006.D4FD8815; Tue, 7 May 2013 13:02:37 +0200 (CEST) Received: from [131.160.126.23] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 7 May 2013 13:02:36 +0200 Message-ID: <5188DF4B.1030402@ericsson.com> Date: Tue, 7 May 2013 14:02:35 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Samuel Weiler References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvra7v/Y5Ag53nBCw2rv3MZDHjz0Rm i2cb57NYfFj4kMWi/etzNgdWjyVLfjJ5fLn8mc1jacNu9gDmKC6blNSczLLUIn27BK6MU68e MRZMEat4PWMjewPjA8EuRk4OCQETif4JLxkhbDGJC/fWs3UxcnEICZxilPh4tZ8JwlnNKLH/ 5SMWkCpeAW2JZQ9mAdkcHCwCKhJP2t1BwmwCFhJbbt0HKxEViJL493Y3I0S5oMTJmU/A4iIC qhIX/n9nBbGZBWIldkz/zwRiCwtYSjyYeA5spJCAs8SV+wkgJqeAi0TPMn2I0yQlFk3rZIHo 1JOYcrWFEcKWl9j+dg4ziC0EdNjyZy0sExiFZiFZPAtJyywkLQsYmVcxsucmZuaklxttYgSG 88Etv1V3MN45J3KIUZqDRUmcN5mrMVBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo1d8r4+r 09PI9Rf0pR43bLUpjW8otpj+O1be5sQW7Y3brabu5IxM6v9uq1DJaB2ls9cy422fji2PyLTm HxuYVnq5v745Sbdbp7pMb/bv2M+JBlON/swXcwjVkv7p+t/ud2iuNneYs9mZEM5SHuE7W9Iz Zt7LL2prmWfz/+68Kbpb/9lFykUpsRRnJBpqMRcVJwIAahmkXTUCAAA= Cc: ietf@ietf.org, iesg@ietf.org, draft-ietf-mmusic-sdp-cs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-mmusic-sdp-cs-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 11:02:44 -0000 Hi Samuel, the authors of this draft have reviewed it in order to address your comments: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-18 Could you please have a look at this revision and let them know whether you are happy with it? Thanks, Gonzalo On 04/02/2013 9:08 PM, Samuel Weiler 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 allows SIP endpoints to negotiate the use of a > circuit-switched (e.g. PSTN) channel. It presents a mechanism for > correlating an incoming circuit-switched connection with a given SDP/SIP > session by sending a nonce or a static string. > > Summary: I would like to see a stronger authentication mechanism > defined to replace the static string or "plaintext password" nonce. > > I am content with the analysis of security weaknesses: an attacker > could trick someone into initiating a potentially expensive PSTN call, > and the correlation mechanism is weak. > > I am not content with the use of a mere nonce or static string for > correlation. That is the equivalent of sending plaintext passwords, and > I suspect we have better mechanisms available that could allow for > mutual endpoint authentication, making it statistically unlikely for a > man-in-the-middle to participate successfully in the correlation > exchange. The document makes a case for using short strings/nonces > (e.g. a caller-ID string or 10 DTFM digits). I suspect both that those > lengths could be extended without great pain and that some stronger > authentication mechanisms could work with such short strings, especially > given the ability to send longer keying material in the packet-switched > SDP session. > > Non-security observation: I'm worried that the architecture of the > current correlation mechanism will have some unintended consequences. >> From section 5.2.3: > > The endpoints should be able to correlate the circuit-switched bearer > with the session negotiated with SDP in order to avoid ringing for an > incoming circuit-switched bearer that is related to the session > controlled with SDP (and SIP). > > As I understand it, some of the defined variants of the correlation > scheme require answering the call (e.g. the DTMF scheme) before > knowing whether or not the channel corresponds to a SIP session. If > it does not, then what? The call is already answered, which gives a > surprising user experience. Feel free to tell me I'm off base with > this one. > > -- Sam > > From rjsparks@nostrum.com Tue May 7 12:07:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339D721F93F9; Tue, 7 May 2013 12:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbAdpH8YoTCA; Tue, 7 May 2013 12:07:12 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A42C321F93EF; Tue, 7 May 2013 12:07:09 -0700 (PDT) Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r47J78ha015129 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Tue, 7 May 2013 14:07:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <518950DC.8080507@nostrum.com> Date: Tue, 07 May 2013 14:07:08 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Carl Wallace References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism) Cc: draft-sparks-genarea-imaparch.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-sparks-genarea-imaparch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:07:21 -0000 Thanks Carl - The details of how this authentication will be managed is probably diving a little deep for the conversations this draft is hoping to inform. Pointing to integrating with the datatracker should be enough, but if there is something _specific_ (in particular specific to IMAP) that we want to constrain the design discussions with, let me know. RjS On 5/5/13 9:00 AM, Carl Wallace wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. > > This draft describes the requirements for providing an IMAP interface for > IETF mail archives. The first item in the security considerations is > correct, but in general the security considerations seem too narrowly > focused on searching and storage. Some discussion of the following may be > worthwhile: how the server is authenticated to users, how users are > authenticated to the server (unless the reference to the datatracker > system is viewed as sufficient), details of the interface with the > datatracker authentication system, (maybe) how archive integrity is > maintained, identification of what should or should not be logged. > > From shanna@juniper.net Tue May 7 16:50:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4436C11E80D3; Tue, 7 May 2013 16:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.467 X-Spam-Level: X-Spam-Status: No, score=-101.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QzMN7kCIHe8; Tue, 7 May 2013 16:50:16 -0700 (PDT) Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id E7A3821F8E2C; Tue, 7 May 2013 16:50:14 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUYmTNr/sZujJPn/Qf2X8AsBiuVEQslnO@postini.com; Tue, 07 May 2013 16:50:15 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 May 2013 16:48:40 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 7 May 2013 16:48:40 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 May 2013 16:51:54 -0700 Received: from mail25-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 May 2013 23:48:39 +0000 Received: from mail25-ch1 (localhost [127.0.0.1]) by mail25-ch1-R.bigfish.com (Postfix) with ESMTP id 35FAD3A016A; Tue, 7 May 2013 23:48:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zz4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received: from mail25-ch1 (localhost.localdomain [127.0.0.1]) by mail25-ch1 (MessageSwitch) id 1367970517884857_19279; Tue, 7 May 2013 23:48:37 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail25-ch1.bigfish.com (Postfix) with ESMTP id D4E2D46014F; Tue, 7 May 2013 23:48:37 +0000 (UTC) Received: from SN2PRD0510HT005.namprd05.prod.outlook.com (157.56.234.117) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 May 2013 23:48:37 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.241]) by SN2PRD0510HT005.namprd05.prod.outlook.com ([10.255.116.40]) with mapi id 14.16.0305.001; Tue, 7 May 2013 23:48:36 +0000 From: Stephen Hanna To: "draft-ietf-trill-fine-labeling.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-trill-fine-labeling-06 Thread-Index: Ac5LfWL4DRrDMVUdSgWgmYwwKmmF1g== Date: Tue, 7 May 2013 23:48:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: The IESG , "secdir@ietf.org" Subject: [secdir] secdir review of draft-ietf-trill-fine-labeling-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 23:50:23 -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 describes optional extensions to the TRILL base protocol to support labeling of traffic with many more IDs than was previously supported. The Security Considerations section for this document seems to be perfectly adequate and I don't have any other security or non-security concerns related to the document. Thanks, Steve From new-work-bounces@ietf.org Wed May 8 15:43:00 2013 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 0CF3321F8C7D; Wed, 8 May 2013 15:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1368052980; bh=U/XDSz9Dh9x95hLecz5JJu21NeKqUNvXzjtejHvTrnU=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=gVYr1sT/ISRbnR8bykt4MwOd296g/sRc7n7s1pHs+kFg9jjvK6/kv3HQ0uGSSTWmo 9VLIvBsDF6OUMzVPMmb9svmXwICOhtoLg77UIkAZxRlO3NsMfkSGwzpFMz6VsvYooD +t9QB+aPyg+kst4/uF74UyNzVI5XYU/E486t6Fjs= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B153D21F8CB4 for ; Wed, 8 May 2013 15:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2vWgjlfEU7h for ; Wed, 8 May 2013 15:42:53 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 9571F21F8C23 for ; Wed, 8 May 2013 15:42:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UaD4W-00079E-9c; Wed, 08 May 2013 18:42:52 -0400 From: Ian Jacobs Date: Wed, 8 May 2013 17:42:40 -0500 To: "new-work@ietf.org" Message-Id: <2DBE05D3-671D-4B24-B1DD-033C1A464518@w3.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 08 May 2013 15:46:09 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Digital Publishing Interest Group (until 2013-06-06) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 22:43:00 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Digital Publishing Activity (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Digital Publishing Interest Group: http://www.w3.org/2013/02/digpubig.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 2013-06-06 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], 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 Ivan Herman . Thank you, Ian Jacobs, Head of W3C Communications [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs http://www.w3.org/People/Jacobs Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From derek@ihtfp.com Fri May 10 11:23:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF2E21F9017; Fri, 10 May 2013 11:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcHCE57y1DoX; Fri, 10 May 2013 11:23:19 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 23F9621F8FFC; Fri, 10 May 2013 11:23:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B2EE0260261; Fri, 10 May 2013 14:23:17 -0400 (EDT) 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 20487-01; Fri, 10 May 2013 14:23:15 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id D5A172601D8; Fri, 10 May 2013 14:23:15 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id r4AIND0G001823; Fri, 10 May 2013 14:23:13 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Fri, 10 May 2013 14:23:13 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: adrian@olddog.co.uk Subject: [secdir] sec-dir review of draft-sheffer-running-code-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 18:23:23 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, by considering the running code as evidence of valuable experimentation and feedback that has made the implemented protocols more mature. I find no issues with this document. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From leifj@mnt.se Sat May 11 16:28:04 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C357221F8A74 for ; Sat, 11 May 2013 16:28:04 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmgxTisXg4Kb for ; Sat, 11 May 2013 16:28:03 -0700 (PDT) Received: from mail-da0-x229.google.com (mail-da0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id AA7CD21F89A6 for ; Sat, 11 May 2013 16:28:03 -0700 (PDT) Received: by mail-da0-f41.google.com with SMTP id y19so2920316dan.0 for ; Sat, 11 May 2013 16:28:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=SaHf9LqKhPRtqf0d3JVOKxls8MddD2IuSjF05an9soA=; b=ZU/8nSZXHtpuDWvND9N+iiNe1R3wTyd1+SsXFSi5FLc5iEo4F55+NBarug1LvlKccC 8sUZXDhlDqdWi076fYj9i0DeeqiarKVvLNKAs+EAR45xtiyeYdju3fVXYUZQ3MALak/r ljfkrLO3O1UnpnIEEVHjHPWOuKvC0AHBy5+VUlkjxOVdrrdyFEvIssq4uVfZv4CpaT4A 0aYP7RLhWyFRBHZb8h2xV9hMs/jwsjx3N5HBNPTsv4CT6Y+dVDwraDSIk9Swrg3sVMdT Snz8tx9B3iYpKfFoggjegzJfDIEt5/AgrWsQ+Ja+2EMBMqNGG0IzLGa5dZ0STGgtsnbG b28w== X-Received: by 10.68.200.10 with SMTP id jo10mr23262764pbc.53.1368314883142; Sat, 11 May 2013 16:28:03 -0700 (PDT) Received: from [172.26.33.43] ([76.14.1.153]) by mx.google.com with ESMTPSA id cq1sm8002932pbc.13.2013.05.11.16.28.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 May 2013 16:28:02 -0700 (PDT) Message-ID: <518ED400.7050908@mnt.se> Date: Sun, 12 May 2013 01:28:00 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "iesg@ietf.org" , draft-ietf-ipsecme-dh-checks.all@tools.ietf.org, "secdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn+LhrI2rDrLdwNBGp0Kfy/011+4IIC+bhR+CicP7byHdHAbg+ADxFaoLqIaPvVRzzWX/pB X-Mailman-Approved-At: Sat, 11 May 2013 16:42:48 -0700 Subject: [secdir] secdir review of draft-ietf-ipsecme-dh-checks X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 23:28:04 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes tests required for using EC with IKEv2. I can't find anything worth fixing. Well written and clear spec. Cheers Leif From shawn.emery@oracle.com Mon May 13 00:36:10 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DE721F91D8; Mon, 13 May 2013 00:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BozhIDS+C4jv; Mon, 13 May 2013 00:36:04 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 28CE621F901B; Mon, 13 May 2013 00:36:01 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4D7Zv5a014028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 May 2013 07:35:58 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4D7Zvl1000343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 May 2013 07:35:57 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4D7ZvPq024139; Mon, 13 May 2013 07:35:57 GMT Received: from [10.159.108.175] (/10.159.108.175) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 May 2013 00:35:57 -0700 Message-ID: <519097A8.40409@oracle.com> Date: Mon, 13 May 2013 01:35:04 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: secdir@ietf.org References: <5124827A.3070407@oracle.com> In-Reply-To: <5124827A.3070407@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-netmod-interfaces-cfg-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 07:36:10 -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 internet-draft specifies a data model used for the management of network interfaces. The security considerations section does exist and discusses that the data is made available through the NETCONF protocol. NETCONF uses SSH to access and transfer said data. It goes on to discuss the implications of unattended access to list and leaf data, but does not provide guidance on how to mitigate against unauthorized access. If this is discussed in the NETCONF draft then this draft should at least provide this reference. General comments: None. Editorial comments: None. Shawn. -- From mbj@tail-f.com Mon May 13 00:44:55 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1553721F8F2C; Mon, 13 May 2013 00:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1+rfrEEiGqm; Mon, 13 May 2013 00:44:49 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1D18221F8FF8; Mon, 13 May 2013 00:44:44 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 32C6D1200174; Mon, 13 May 2013 09:44:42 +0200 (CEST) Date: Mon, 13 May 2013 09:44:41 +0200 (CEST) Message-Id: <20130513.094441.442455286.mbj@tail-f.com> To: shawn.emery@oracle.com From: Martin Bjorklund In-Reply-To: <519097A8.40409@oracle.com> References: <5124827A.3070407@oracle.com> <519097A8.40409@oracle.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 May 2013 02:22:02 -0700 Cc: draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-netmod-interfaces-cfg-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 07:44:55 -0000 Hi, Shawn Emery 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 internet-draft specifies a data model used for the management of network > interfaces. > > The security considerations section does exist and discusses that the data is > made available through the NETCONF protocol. NETCONF uses SSH to access and > transfer said data. It goes on to discuss the implications of unattended > access to list and leaf data, but does not provide guidance on how to mitigate > against unauthorized access. If this is discussed in the NETCONF draft then > this draft should at least provide this reference. This is discussed in the NETCONF Access Control Model (RFC 6536). We got the same comment also from other reviewers, and we will update the first paragraph to be: The YANG module defined in this memo is designed to be accessed via the NETCONF protocol ^RFC6241^. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH ^RFC6242^. The NETCONF access control model ^RFC6536^ provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content. This text will go into the Security Considerations template that is used for other YANG module documents as well. I hope this addresses your concern. /martin From bclaise@cisco.com Mon May 13 03:24:34 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB4821F8935; Mon, 13 May 2013 03:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.449 X-Spam-Level: X-Spam-Status: No, score=-8.449 tagged_above=-999 required=5 tests=[AWL=2.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dAqsBs4Ny-d; Mon, 13 May 2013 03:24:30 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED8821F85CE; Mon, 13 May 2013 03:24:30 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4DAOTHl028407; Mon, 13 May 2013 12:24:29 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4DANkEe024884; Mon, 13 May 2013 12:24:01 +0200 (CEST) Message-ID: <5190BF32.2040401@cisco.com> Date: Mon, 13 May 2013 12:23:46 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Bjorklund References: <5124827A.3070407@oracle.com> <519097A8.40409@oracle.com> <20130513.094441.442455286.mbj@tail-f.com> In-Reply-To: <20130513.094441.442455286.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-netmod-interfaces-cfg-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 10:24:34 -0000 Hi Shawn, > Hi, > > Shawn Emery 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 internet-draft specifies a data model used for the management of network >> interfaces. >> >> The security considerations section does exist and discusses that the data is >> made available through the NETCONF protocol. NETCONF uses SSH to access and >> transfer said data. It goes on to discuss the implications of unattended >> access to list and leaf data, but does not provide guidance on how to mitigate >> against unauthorized access. If this is discussed in the NETCONF draft then >> this draft should at least provide this reference. > This is discussed in the NETCONF Access Control Model (RFC 6536). We > got the same comment also from other reviewers, and we will update the > first paragraph to be: > > The YANG module defined in this memo is designed to be accessed via > the NETCONF protocol ^RFC6241^. The lowest NETCONF layer is the > secure transport layer and the mandatory-to-implement secure > transport is SSH ^RFC6242^. The NETCONF access control model > ^RFC6536^ provides the means to restrict access for particular > NETCONF users to a pre-configured subset of all available NETCONF > protocol operations and content. Note that this text has been recently updated at http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines Regards, Benoit > > This text will go into the Security Considerations template that is > used for other YANG module documents as well. > > I hope this addresses your concern. > > > /martin > > From hartmans@mit.edu Wed May 15 06:09:33 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFD721F899E; Wed, 15 May 2013 06:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ID6wUenriIZf; Wed, 15 May 2013 06:09:27 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9773321F85ED; Wed, 15 May 2013 06:09:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 0FBC82054D; Wed, 15 May 2013 09:06:35 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li0J9D4AtAMs; Wed, 15 May 2013 09:06:34 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 15 May 2013 09:06:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 67E1F440A; Wed, 15 May 2013 09:09:15 -0400 (EDT) From: Sam Hartman To: iesg@ietf.org,secdir@ietf.org Date: Wed, 15 May 2013 09:09:15 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [secdir] secdir review of draft-ietf-forces-interop-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 13:09:33 -0000 I've done a secdir review of the FORCES interop report. It's an interop report; publishing it has no negative impact on the security of the Internet. During the interop testing they worked on their MTI security mechanism, which was not tested in a previous interop test. No issues with the interop report. From kivinen@iki.fi Thu May 16 13:23:20 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCE021F8616 for ; Thu, 16 May 2013 13:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvgJFkbFgWyU for ; Thu, 16 May 2013 13:23:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id D203911E8111 for ; Thu, 16 May 2013 13:23:17 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r4GKNEFM010699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 16 May 2013 23:23:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r4GKNEX1017548; Thu, 16 May 2013 23:23:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20885.16434.237571.139906@fireball.kivinen.iki.fi> Date: Thu, 16 May 2013 23:23:14 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 3 min X-Total-Time: 4 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2013 20:23:20 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Julien Laganier is next in the rotation. For telechat 2013-05-30 Reviewer LC end Draft Rob Austein T 2013-05-06 draft-ietf-bmwg-imix-genome-04 Tero Kivinen T 2013-05-30 draft-ietf-dhc-dhcpv6-radius-opt-11 Ondrej Sury T 2013-04-23 draft-ietf-manet-olsrv2-mib-08 Last calls and special requests: Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-05-06 draft-ietf-geopriv-held-measurements-07 Dan Harkins 2013-05-15 draft-ietf-6man-addr-select-opt-10 David Harrington 2013-05-09 draft-ietf-6man-impatient-nud-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Charlie Kaufman 2013-06-04 draft-eastlake-rfc5342bis-02 Scott Kelly 2013-05-29 draft-ietf-cuss-sip-uui-10 Stephen Kent 2013-05-27 draft-ietf-mpls-ldp-dod-08 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Warren Kumari 2013-05-24 draft-ietf-softwire-public-4over6-09 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Russ Mundy 2013-03-30 draft-ietf-roll-terminology-12 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 David Waltermire 2013-05-14 draft-housley-rfc2050bis-01 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-06 Brian Weis 2013-05-01 draft-ietf-ipfix-protocol-rfc5101bis-06 Nico Williams - draft-ietf-httpbis-p5-range-22 -- kivinen@iki.fi From kivinen@iki.fi Thu May 16 14:30:21 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E21321F86BB; Thu, 16 May 2013 14:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAPRypA+xbMv; Thu, 16 May 2013 14:30:18 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 558EA11E80CC; Thu, 16 May 2013 14:29:57 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r4GLTtCT017505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 May 2013 00:29:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r4GLTt0J019673; Fri, 17 May 2013 00:29:55 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20885.20435.315856.407689@fireball.kivinen.iki.fi> Date: Fri, 17 May 2013 00:29:55 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 15 min X-Total-Time: 14 min Subject: [secdir] Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 21:30:22 -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 specifies a way how the NAS / DHCPv6 relay agent can take some data it received from the radius server and send it for the DHCPv6 server. The data includes things like Delegated-IPv6-Prefix, DNS-Server-IPv6-Address, Delegated-IPv6-Prefix-Pool etc. In addition to those the IANA registry specifying which options should forwarded includes Vendor-Specific. The connection between the NAS / DHCPv6 relay agent and Radius server might be protected (encrypted with IPsec), but the connection between DHCPv6 relay agent and the DHCPv6 server does not have that possibility (as far as I understand things). For most of the values forwarded that does not matter, as they are public to the network anyways, and as draft-ietf-dhc-dhcpv6-radius-opt-11 says the NAS is trusted network component. For the Vendor specific that might not be true. It might be that the vendor specific options returned from the RADIUS server contains something that might not be public, and as the NAS / DHCPv6 relay agent does not have to select which parts of that to forward (it will forward all of them), that might leak that vendor specific information to the network even when the connection between NAS and the RADIUS server was protected. I have no idea whether someone might use vendor specific radius options in such way that this might cause problems, but perhaps adding note about this to the security considerations section might be appropriate. As an (bad) example of that such practice could be that some ISP somewhere decides to add bithdate of the customer as vendor specific option to radius, so they can filter out the web sites which are allowed to be accessed from that client, and as that information has privacy concerns, they make sure that the connection between NAS and radius server is encypted. Now when this protocol is deployed those options gets relayed to the DHCPv6 server in clear, which might not be what the ISP expected... -- kivinen@iki.fi From new-work-bounces@ietf.org Fri May 17 08:52:22 2013 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 3800F21F9702; Fri, 17 May 2013 08:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1368805942; bh=DqoMPDSgjf0EkOq5e/9PDG3wufmjTMcPeiwOYoVP5bo=; 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=skizz1m10F4OFuReJlhH2ihyxYbD349byU8XNSG7B0JPGZb/CXzYWs++Cf21bjiHz OlHPI6Xx5BFpPQ7E4oBbaLlMgihxcciwTxhQ3YNPSLVaV6YN7mkWFYZp9qqIkmXOci yfCXFhr5U5Lo1vdzTkMgulxqS3N8DADHlq44+MyU= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB1321F96F2; Fri, 17 May 2013 08:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 849q20vRhQ9R; Fri, 17 May 2013 08:52:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B6821F9705; Fri, 17 May 2013 08:52:08 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130517155201.6310.75449.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2013 08:52:01 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 17 May 2013 09:20:09 -0700 Subject: [secdir] [new-work] WG Review: JavaScript Object Notation (json) 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, 17 May 2013 15:52:22 -0000 A new IETF working group has been proposed in the Applications 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 at ietf.org) by 2013-05-27. JavaScript Object Notation (json) ------------------------------------------------ Current Status: Proposed Working Group Assigned Area Director: Barry Leiba Mailing list Address: json@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/json Archive: http://www.ietf.org/mail-archive/web/json/ Charter of Working Group: Javascript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard and was published in RFC 4627, an Informational document. JSON has come into very broad use, often instead of or in addition to XML. RFC 4627 cites a 1999 version of the ECMAScript Language Specification. However, since the publication of RFC 4627, the ECMA specifications have turned the relationship around, and themselves cite RFC 4627 as the documentation for JSON. A number of Standards Track IETF specifications have also cited RFC 4627, and more are in development (for example, the work in the JOSE working group). It makes sense to move RFC 4627 onto the Standards Track. There are also a number of other JSON-related proposals for Standards Track that would benefit from review from both the IETF and the larger JSON-using communities created by a working group focused on JSON. The JSON working group will have as its only initial task the minor revision of RFC 4627 to bring it onto the Standards Track. As noted above, RFC 4627 is a mature and widely cited specification. The initial goal of this work is essentially a reclassification in place, with minimal changes. The working group will review errata and update the document as needed to incorporate those, and will correct significant errors and inconsistencies, but will keep changes at this stage to a minimum. It is acknowledged that there are differences between RFC 4627 and the ECMAScript specification in the rules for parsing JSON. Any changes that break compatibility with existing implementations of either RFC 4627 or the ECMAScript specification will need to have very strong justification and broad support. All differences between RFC 4627 or the current ECMAScript specification will be documented in the new RFC. This documentation will include both the WG consensus for the rationale of the changes and the expected impact of the changes. The resulting document will be jointly published as an RFC and by ECMA. ECMA participants will be participating in the working group editing through the normal process of working group participation. The responsible AD will coordinate the approval process with ECMA so that the versions of the document that are approved by each body are the same. There are also various proposals for JSON extensions and related standards. The working group will consider those proposals only after the initial work is done, and must recharter with specific work items for any additional work it might select. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From kivinen@iki.fi Fri May 17 11:47:12 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA20421F96E5; Fri, 17 May 2013 11:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EwVVQIbdPQq; Fri, 17 May 2013 11:47:12 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 785BC21F9705; Fri, 17 May 2013 11:47:10 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r4HIl5JV016829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 May 2013 21:47:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r4HIl3Q8024131; Fri, 17 May 2013 21:47:03 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20886.31527.670959.767940@fireball.kivinen.iki.fi> Date: Fri, 17 May 2013 21:47:03 +0300 From: Tero Kivinen To: "Leaf Yeh" In-Reply-To: <51967458.22d9440a.44f5.7843@mx.google.com> References: <20885.20435.315856.407689@fireball.kivinen.iki.fi> <51967458.22d9440a.44f5.7843@mx.google.com> X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 19 min X-Total-Time: 19 min Cc: draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org, 'Tomek Mrugalski' , 'Ted Lemon' , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 18:47:13 -0000 Leaf Yeh writes: > Tero - As an (bad) example of that such practice could be that some ISP > somewhere decides to add bithdate of the customer as vendor specific option > to radius, so they can filter out the web sites which are allowed to be > accessed from that client, and as that information has privacy concerns, > they make sure that the connection between NAS and radius server is > encypted. Now when this protocol is deployed those options gets relayed to > the DHCPv6 server in clear, which might not be what the ISP expected... > > I believe the DHCPv6 server does not really need the privacy information > (eg. birth_date) for its address/prefix (or other parameters) assignment, > and the relay in this case could just forward the possible VAS RADIUS > attribute to the server. I agree that it does not need those, but even as section 5 says that "relay agent MAY include", i.e. it is not mandated to include all vendor specific attributes (I assume VAS = vendor specific?), there is guidance what options to include. > How about to add the following text in section 8, > 'Network administrators should be aware that although RADIUS messages are > encrypted, DHCPv6 messages can not be encrypted. It is possible that some > VAS RADIUS attributes might contain the sensitive or confidential > information. Network administrators are strongly advised to prevent > including such information into DHCPv6 messages.'? That addition text seems to be just what I was looking for. Perfect, but better still spell out the VAS, as it is not currently used in draft. BTW, while reading the section 4.1. I noticed following text: New RADIUS attributes MAY be added to this list after the IETF Expert Review [RFC5226]. I do not think MAY is suitable there. The IANA allocation rules either are or are not, there is no MAY in there... Also this same text is also in the section 9, so it might be enough to remove it from here, and fix the section 9 to say: The allocation policy of this 'RADIUS attributes permitted in DHCPv6 RADIUS option' registry is Expert Review [RFC5226]. (Note, that Expert might not really be IETF Expert, it might also be just for example RADIUS Expert in this case). Also I do not think the SHOULD statement given to the Expert (again better remove the IETF and talk about Expert or Designated Expert) should just say that without capital letters. Implementors quite often check all MUST/SHOULD etc to make sure they are done, and finding this kind of text just causes extra work for them, and if you have skipped some MUST/SHOULD you need to explain why you did not implement it... :-) -- kivinen@iki.fi From Ted.Lemon@nominum.com Fri May 17 11:52:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A1C21F972B; Fri, 17 May 2013 11:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7txANDCRNc4; Fri, 17 May 2013 11:52:37 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id D1A5F21F9733; Fri, 17 May 2013 11:52:36 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUZZ8dFPY0M24wCzaBU5pDJaxBq4cZTvC@postini.com; Fri, 17 May 2013 11:52:36 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6FB2C1B80D7; Fri, 17 May 2013 11:52:36 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6949219005D; Fri, 17 May 2013 11:52:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 17 May 2013 11:52:36 -0700 From: Ted Lemon To: Tero Kivinen Thread-Topic: Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11 Thread-Index: AQHOUnyJ4Cz0UNrel0+NQBGO7xYtrZkKJgeAgAAIMICAAAGMgA== Date: Fri, 17 May 2013 18:52:36 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751A4A75@mbx-01.win.nominum.com> References: <20885.20435.315856.407689@fireball.kivinen.iki.fi> <51967458.22d9440a.44f5.7843@mx.google.com> <20886.31527.670959.767940@fireball.kivinen.iki.fi> In-Reply-To: <20886.31527.670959.767940@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Tomek Mrugalski , Leaf Yeh , "" , "" Subject: Re: [secdir] Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 18:52:45 -0000 On May 17, 2013, at 2:47 PM, Tero Kivinen wrote: > That addition text seems to be just what I was looking for. Perfect, > but better still spell out the VAS, as it is not currently used in > draft. That makes sense. > BTW, while reading the section 4.1. I noticed following text: >=20 > New RADIUS attributes > MAY be added to this list after the IETF Expert Review [RFC5226]. >=20 > I do not think MAY is suitable there. The IANA allocation rules either > are or are not, there is no MAY in there... That's correct=97this will get you a DISCUSS from Pete, so it's best to avo= id it. :) > Also this same text is also in the section 9, so it might be enough to > remove it from here, and fix the section 9 to say: >=20 > The allocation policy of this 'RADIUS attributes permitted in DHCPv6 > RADIUS option' registry is Expert Review [RFC5226]. >=20 > (Note, that Expert might not really be IETF Expert, it might also be > just for example RADIUS Expert in this case). That's a good point=97we need to decide what sort of expert we want here. = The draft should give some guidance about that. From leaf.yeh.sdo@gmail.com Fri May 17 11:18:08 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604E121F96EA; Fri, 17 May 2013 11:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRg9q+fMFf5g; Fri, 17 May 2013 11:18:02 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 40B0821F9700; Fri, 17 May 2013 11:18:02 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp6so3798829pab.21 for ; Fri, 17 May 2013 11:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=W2lZTZwTEyvkpfAoxFX3dafv82FylNRnRsuCyg7lZYM=; b=MWJydwtk5oyAs9rs+VRVivgKFXW87GIJI7TZlXpD0KLJtJCjw1UHRxHBuX7UgbVdT6 N4uXn9ujg2d3+fqL2rDmizmIX4og91o4zrDmOpB5jvoZSw6ZxyKlAtnlnLy2S9H2CHl1 kBzSPDM4Gg/o8xtDfLsUtI9tE61hRqq7k+i99h+fPGPpBlLTnfid0kekGwhsxLISRVmr tOafWE3pfRduhyTeLHzQHYFf7sAWF+DoOIoZOg/k+hBd9nPEk8qinlQ/aW2efyq4wRAv ZueASSf2SpvjSW+Z3E1aMs6XUBnQFy4TfMAcN2baLww3eXx4qbGHPLl0z8nm14mWtYQ1 8HIg== X-Received: by 10.66.248.228 with SMTP id yp4mr49855108pac.158.1368814681623; Fri, 17 May 2013 11:18:01 -0700 (PDT) Received: from PC ([221.223.164.6]) by mx.google.com with ESMTPSA id ov2sm12107303pbc.34.2013.05.17.11.17.58 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 17 May 2013 11:18:00 -0700 (PDT) From: "Leaf Yeh" To: "'Tero Kivinen'" , , , References: <20885.20435.315856.407689@fireball.kivinen.iki.fi> In-Reply-To: <20885.20435.315856.407689@fireball.kivinen.iki.fi> Date: Sat, 18 May 2013 02:17:45 +0800 Message-ID: <51967458.22d9440a.44f5.7843@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5SfIdRl5ehIv75Q0eiMu1AI5br3wAmu9pw Content-Language: zh-cn X-Mailman-Approved-At: Sat, 18 May 2013 08:09:39 -0700 Cc: 'Tomek Mrugalski' , 'Ted Lemon' Subject: Re: [secdir] Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 18:18:08 -0000 Tero - I have no idea whether someone might use vendor specific radius options in such way that this might cause problems, but perhaps adding note about this to the security considerations section might be appropriate. Any suggested text on it? Tero - As an (bad) example of that such practice could be that some ISP somewhere decides to add bithdate of the customer as vendor specific option to radius, so they can filter out the web sites which are allowed to be accessed from that client, and as that information has privacy concerns, they make sure that the connection between NAS and radius server is encypted. Now when this protocol is deployed those options gets relayed to the DHCPv6 server in clear, which might not be what the ISP expected... I believe the DHCPv6 server does not really need the privacy information (eg. birth_date) for its address/prefix (or other parameters) assignment, and the relay in this case could just forward the possible VAS RADIUS attribute to the server. How about to add the following text in section 8, 'Network administrators should be aware that although RADIUS messages are encrypted, DHCPv6 messages can not be encrypted. It is possible that some VAS RADIUS attributes might contain the sensitive or confidential information. Network administrators are strongly advised to prevent including such information into DHCPv6 messages.'? Best Regards, Leaf -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Friday, May 17, 2013 5:30 AM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org Subject: Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11 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 way how the NAS / DHCPv6 relay agent can take some data it received from the radius server and send it for the DHCPv6 server. The data includes things like Delegated-IPv6-Prefix, DNS-Server-IPv6-Address, Delegated-IPv6-Prefix-Pool etc. In addition to those the IANA registry specifying which options should forwarded includes Vendor-Specific. The connection between the NAS / DHCPv6 relay agent and Radius server might be protected (encrypted with IPsec), but the connection between DHCPv6 relay agent and the DHCPv6 server does not have that possibility (as far as I understand things). For most of the values forwarded that does not matter, as they are public to the network anyways, and as draft-ietf-dhc-dhcpv6-radius-opt-11 says the NAS is trusted network component. For the Vendor specific that might not be true. It might be that the vendor specific options returned from the RADIUS server contains something that might not be public, and as the NAS / DHCPv6 relay agent does not have to select which parts of that to forward (it will forward all of them), that might leak that vendor specific information to the network even when the connection between NAS and the RADIUS server was protected. I have no idea whether someone might use vendor specific radius options in such way that this might cause problems, but perhaps adding note about this to the security considerations section might be appropriate. As an (bad) example of that such practice could be that some ISP somewhere decides to add bithdate of the customer as vendor specific option to radius, so they can filter out the web sites which are allowed to be accessed from that client, and as that information has privacy concerns, they make sure that the connection between NAS and radius server is encypted. Now when this protocol is deployed those options gets relayed to the DHCPv6 server in clear, which might not be what the ISP expected... -- kivinen@iki.fi From new-work-bounces@ietf.org Fri May 17 12:11:55 2013 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 BA9F521F974B; Fri, 17 May 2013 12:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1368817915; bh=h3i9jRY6ixKmcxRIKnKvtWBQla4w7FuIZDFm84+ZjMk=; 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=Qhnf0CZpyWlcI81FzGnqaFuxG+NFkFStht3EW7CfUXgF/q+pxKXIDK9QYGXottWXS pEAh6KNeQc79IcLqKXVCb+Y+wLOZjsc2cCgo3RfS3kSGVPOcEP0jDLF91B9lgs4Q5F Fa0FA3hN0o/CkcDB2k6u5rGxp22Z4G9laXuRRNH8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB3721F971A for ; Fri, 17 May 2013 12:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-XdemmWOzjS for ; Fri, 17 May 2013 12:11:48 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id A8F4521F974B for ; Fri, 17 May 2013 12:11:48 -0700 (PDT) Received: from bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1UdQ4A-0005cE-N2 for new-work@ietf.org; Fri, 17 May 2013 15:11:47 -0400 To: new-work@ietf.org Date: Fri, 17 May 2013 21:11:47 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/12.15 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Sat, 18 May 2013 08:09:39 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web and Mobile Interest Group (until 2013-06-16) 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, 17 May 2013 19:11:56 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Mobile Web Initiative [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web and Mobile Interest Group: http://www.w3.org/2013/04/webmobile-ig-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2013-06-16 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 [2], 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 Dominique Hazael-Massieux, Mobile Web Initiative Activity Lead . Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/Mobile/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +33643220001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From leaf.yeh.sdo@gmail.com Sat May 18 06:25:36 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151D221F9092; Sat, 18 May 2013 06:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnkGkQBbyt4a; Sat, 18 May 2013 06:25:35 -0700 (PDT) Received: from mail-da0-x22e.google.com (mail-da0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 60E0521F9057; Sat, 18 May 2013 06:25:35 -0700 (PDT) Received: by mail-da0-f46.google.com with SMTP id e20so620659dak.5 for ; Sat, 18 May 2013 06:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=mDOJZrBcHDZ1F64rDVjMinwmX24RJ8eo4b+owCkpjEo=; b=ThdYcdKRg4KkMvf9CGP4tyxpLBkWu+lOAsdMTcnwZSc/JrdRHL7uFjlU85tDGzoCgW ErR7FrdpaXXk7ebacy8cNqRw7L+16d/3p9t5iwLyvxwW79AaB1+iCMPDV8NCJLkfiQ8H IM0JAX8T+Yj1XHgLZtkIM0B+YICUjrvatsY98XDmSkhTkyCfkLNXaunjD2wWYqfeIW5T ZB9PNhcg+UjkQoW4v9LM66Shuw/skxMXyX6RmtgVy/F+XagSz1y+KITHDAE7jYwU8pSe DAjg9xPnE35AXAimN5fQmdjJ1EkNbNtNxccMxLX/zRcIm44U4Ibf+86K/PHmckkvsO7D HjKw== X-Received: by 10.68.42.134 with SMTP id o6mr20117157pbl.149.1368883535123; Sat, 18 May 2013 06:25:35 -0700 (PDT) Received: from PC ([221.223.164.6]) by mx.google.com with ESMTPSA id zo4sm15660002pbc.21.2013.05.18.06.25.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 18 May 2013 06:25:34 -0700 (PDT) From: "Leaf Yeh" To: "'Tero Kivinen'" References: <20885.20435.315856.407689@fireball.kivinen.iki.fi> <51967458.22d9440a.44f5.7843@mx.google.com> <20886.31527.670959.767940@fireball.kivinen.iki.fi> In-Reply-To: <20886.31527.670959.767940@fireball.kivinen.iki.fi> Date: Sat, 18 May 2013 21:25:19 +0800 Message-ID: <5197814e.04fc440a.31ee.7730@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5TLu9gpPxWMznnRpKXGnZCRhevUAALMUhA Content-Language: zh-cn X-Mailman-Approved-At: Sat, 18 May 2013 08:09:39 -0700 Cc: draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org, 'Tomek Mrugalski' , 'Ted Lemon' , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 13:25:36 -0000 Tero - (I assume VAS = vendor specific?) The above 'VAS' should be VSA - Vendor-Specific Attribute. My typo, sorry about that. Tero - ...but better still spell out the VAS, as it is not currently used in draft. Ok, I will spell out it to be '..some RADIUS vendor-specific attributes...' in the sentence. Tero - the section 4.1. I noticed following text: New RADIUS attributes MAY be added to this list after the IETF Expert Review [RFC5226]. I do not think MAY is suitable there. The IANA allocation rules either are or are not, there is no MAY in there...Also this same text is also in the section 9, so it might be enough to remove it from here, I think we can use 'can' to replace 'MAY' here. Tero - and fix the section 9 to say: The allocation policy of this 'RADIUS attributes permitted in DHCPv6 RADIUS option' registry is Expert Review [RFC5226]. I will adopted it in the section 9. Tero - Also I do not think the SHOULD statement given to the Expert (again better remove the IETF and talk about Expert or Designated Expert) should just say that without capital letters. The text in section 9 will be 'The allocation policy of this 'RADIUS attributes permitted in DHCPv6 RADIUS option' registry is Expert Review . Designated expert should carefully consider the security implications of allowing the relay agent to include new RADIUS attribute for the addition to this registry.' OK? Best Regards, Leaf -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Saturday, May 18, 2013 2:47 AM To: Leaf Yeh Cc: iesg@ietf.org; secdir@ietf.org; draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org; 'Tomek Mrugalski'; 'Ted Lemon' Subject: RE: Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11 Leaf Yeh writes: > Tero - As an (bad) example of that such practice could be that some > ISP somewhere decides to add bithdate of the customer as vendor > specific option to radius, so they can filter out the web sites which > are allowed to be accessed from that client, and as that information > has privacy concerns, they make sure that the connection between NAS > and radius server is encypted. Now when this protocol is deployed > those options gets relayed to the DHCPv6 server in clear, which might not be what the ISP expected... > > I believe the DHCPv6 server does not really need the privacy > information (eg. birth_date) for its address/prefix (or other > parameters) assignment, and the relay in this case could just forward > the possible VAS RADIUS attribute to the server. I agree that it does not need those, but even as section 5 says that "relay agent MAY include", i.e. it is not mandated to include all vendor specific attributes (I assume VAS = vendor specific?), there is guidance what options to include. > How about to add the following text in section 8, 'Network > administrators should be aware that although RADIUS messages are > encrypted, DHCPv6 messages can not be encrypted. It is possible that > some VAS RADIUS attributes might contain the sensitive or confidential > information. Network administrators are strongly advised to prevent > including such information into DHCPv6 messages.'? That addition text seems to be just what I was looking for. Perfect, but better still spell out the VAS, as it is not currently used in draft. BTW, while reading the section 4.1. I noticed following text: New RADIUS attributes MAY be added to this list after the IETF Expert Review [RFC5226]. I do not think MAY is suitable there. The IANA allocation rules either are or are not, there is no MAY in there... Also this same text is also in the section 9, so it might be enough to remove it from here, and fix the section 9 to say: The allocation policy of this 'RADIUS attributes permitted in DHCPv6 RADIUS option' registry is Expert Review [RFC5226]. (Note, that Expert might not really be IETF Expert, it might also be just for example RADIUS Expert in this case). Also I do not think the SHOULD statement given to the Expert (again better remove the IETF and talk about Expert or Designated Expert) should just say that without capital letters. Implementors quite often check all MUST/SHOULD etc to make sure they are done, and finding this kind of text just causes extra work for them, and if you have skipped some MUST/SHOULD you need to explain why you did not implement it... :-) -- kivinen@iki.fi From kent@bbn.com Sun May 19 19:17:14 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE25521F8F0F for ; Sun, 19 May 2013 19:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0a8dLu6vV60 for ; Sun, 19 May 2013 19:17:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA7F21F8F0E for ; Sun, 19 May 2013 19:17:08 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:52850 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UeFen-00073S-NE; Sun, 19 May 2013 22:17:02 -0400 Message-ID: <5199879B.5010701@bbn.com> Date: Sun, 19 May 2013 22:16:59 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: secdir , Sean Turner , thomas.beckhaus@telekom.de, bruno.decraene@orange.com, kishoret@juniper.net, maciek@cisco.com, lmartini@cisco.com, Adrian Farrel , loa@pi.nu, rcallon@juniper.net, swallow@cisco.com Content-Type: multipart/alternative; boundary="------------060300020102080306090400" Subject: [secdir] SECDIR review of draft-ietf-mpls-ldp-dod-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 02:17:15 -0000 This is a multi-part message in MIME format. --------------060300020102080306090400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I 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. An overall comment: There are numerous (minor) English errors throughout the document, which I hope will be addressed through the RFC Editor process. The abstract says that the document describes LDP DoD (downstream on demand) use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. It also describes a new, optional TLV type in the LDP Label Request message. The intent of creating the new type is to enable "fast-up" convergence. Section 2 of the document is devoted to a description of reference access topologies that will make use of this new MPLS feature. These topologies are divided into two classes: ones that can be supported via static routes and ones that require use of a dedicated IGP, e.g., ISIS, OSPF (v2 or v3), andRIP (v2 or ng), by the access network. Section 3 describes use cases for LDP DoD. It too distinguishes between topologies that use static routing vs. an IGP, and examines various types of failures that may affect the LDP DoD nodes. This section includes a lot of normative text, yet almost all instances of the words "must" and "should" are lowercase. The authors should revisit this section to determine if there need to be more MUSTs and SHOULDs. Section 4 describes the label request procedure. It too contains normative text, yet almost all instances of "must" and "should" are lowercase. As with Section 3, the authors should revisit this section to determine if there need to be more MUSTs and SHOULDs. Section 5 describes the LDP extension to enable "Fast-Up" convergence. In this very brief section the authors seem to have done a better job of using uppercase terms in normative text. Section 7 addresses Security Considerations. It cites RFC 5920, the Security Framework for MPLS and GMPLS as the primary reference applicable to security concerns that arise in the MPLS DoD context. RFC 5920 devotes several pages to a discussion of service provider and inter-provider security topics, so it seems natural to cite it here. (It too suffers from a tendency to use the words "must," "should," and "may" only in lowercase, despite the apparent normative nature of the comments being made.) Sections 9.1 and 9.2 are odd parts of 5920; the former enumerates potential attacks, and the latter enumerates "deference techniques" without bothering to establish the mapping between the two! ** This I-D also cites the Security Consideration section of the MPLS LDP specification (RFC 5036), noting a need for message authenticity and integrity, and for protection against spoofing and DoS attacks. RFC 5036 contains a more conventional Security Considerations section, which seems appropriate to cite here. In addition to the references to prior RFCs, this section analyzes several security contexts:, in terms of tampering with packet flow direction, data and control plane security, and network node security. The discussion of attacks on packet flow direction seems fairly good, except for the ABR LSR network side case, for which the offered advice is vague. The data place security discussion seems to be a set of suggestions, but with a mix of normative and informative terms; Section 7.2 definitely needs work. The discussion of control plane security in Section 7.3 is shorter, but not much better. It suggests that the reader be familiar with a KARP I-D (I-D.ietf-karp-routing-tcp-analysis. This recommendation is not a precise recommendation and thus ought to be reconsidered. The text here also suggests use of TCP/MD5, recommending TCP/AO only if the former is not considered good enough. RFC 5925 (TCP-AO) obsoletes RFC 2385 (use of TCP/MD5 in BGP). This calls into question whether it is appropriate to recommend use of TCP/MD5 at all. The subsection ends with two suggestions: employ better authentication in access locations with lower physical security, and use "stricter network protection mechanism." The former advice seems good, but the latter is too amorphous to be of much use. The final subsection in Security Considerations (7.4) discusses additional precautions an operator might employ for nodes that are considered to be at risk due to degraded physical security. Addressing this concern seems reasonable, but the advice is pretty generic, and the wording here is especially poor. --------------060300020102080306090400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

I 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.

 

An overall comment: There are numerous (minor) English errors throughout the document, which I hope will be addressed through the RFC Editor process.

 

The abstract says that the document describes LDP DoD (downstream on demand) use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. It also describes a new, optional TLV type in the LDP Label Request message. The intent of creating the new type is to enable “fast-up” convergence.

 

Section 2 of the document is devoted to a description of reference access topologies that will make use of this new MPLS feature. These topologies are divided into two classes: ones that can be supported via static routes and ones that require use of a dedicated IGP, e.g., ISIS, OSPF (v2 or v3), and  RIP (v2 or ng), by the access network.

 

Section 3 describes use cases for LDP DoD. It too distinguishes between topologies that use static routing vs. an IGP, and examines various types of failures that may affect the LDP DoD nodes. This section includes a lot of normative text, yet almost all instances of the words “must” and “should” are lowercase. The authors should revisit this section to determine if there need to be more MUSTs and SHOULDs.

 

Section 4 describes the label request procedure. It too contains normative text, yet almost all instances of “must” and “should” are lowercase. As with Section 3, the authors should revisit this section to determine if there need to be more MUSTs and SHOULDs.

 

Section 5 describes the LDP extension to enable “Fast-Up” convergence. In this very brief section the authors seem to have done a better job of using uppercase terms in normative text.

 

Section 7 addresses Security Considerations. It cites RFC 5920, the Security Framework for MPLS and GMPLS as the primary reference applicable to security concerns that arise in the MPLS DoD context. RFC 5920 devotes several pages to a discussion of service provider and inter-provider security topics, so it seems natural to cite it here. (It too suffers from a tendency to use the words “must,” “should,” and “may” only in lowercase, despite the apparent normative nature of the comments being made.) Sections 9.1 and 9.2 are odd parts of 5920; the former enumerates potential attacks, and the latter enumerates “deference techniques” without bothering to establish the mapping between the two!

 

This I-D also cites the Security Consideration section of the MPLS LDP specification (RFC 5036), noting a need for message authenticity and integrity, and for protection against spoofing and DoS attacks. RFC 5036 contains a more conventional Security Considerations section, which seems appropriate to cite here.

 

In addition to the references to prior RFCs, this section analyzes several security contexts:, in terms of tampering with packet flow direction, data and control plane security, and network node security. The discussion of attacks on packet flow direction seems fairly good, except for the ABR LSR network side case, for which the offered advice is vague. The data place security discussion seems to be a set of suggestions, but with a mix of normative and informative terms; Section 7.2 definitely needs work.

 

The discussion of control plane security in Section 7.3 is shorter, but not much better. It suggests that the reader be familiar with a KARP I-D (I-D.ietf-karp-routing-tcp-analysis. This recommendation is not a precise recommendation and thus ought to be reconsidered. The text here also suggests use of TCP/MD5, recommending TCP/AO only if the former is not considered good enough. RFC 5925 (TCP-AO) obsoletes RFC 2385 (use of TCP/MD5 in BGP). This calls into question whether it is appropriate to recommend use of TCP/MD5 at all. The subsection ends with two suggestions: employ better authentication in access locations with lower physical security, and use “stricter network protection mechanism.” The former advice seems good, but the latter is too amorphous to be of much use.

 

The final subsection in Security Considerations (7.4) discusses additional precautions an operator might employ for nodes that are considered to be at risk due to degraded physical security. Addressing this concern seems reasonable, but the advice is pretty generic, and the wording here is especially poor.

--------------060300020102080306090400-- From charliek@microsoft.com Sun May 19 23:39:59 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F63021F9019; Sun, 19 May 2013 23:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.535 X-Spam-Level: ** X-Spam-Status: No, score=2.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RAND_6=2, UNPARSEABLE_RELAY=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PswSovW9ELXI; Sun, 19 May 2013 23:39:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE1C21F9021; Sun, 19 May 2013 23:39:52 -0700 (PDT) Received: from BL2FFO11FD005.protection.gbl (10.173.161.203) by BL2FFO11HUB008.protection.gbl (10.173.160.228) with Microsoft SMTP Server (TLS) id 15.0.698.0; Mon, 20 May 2013 06:39:50 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Mon, 20 May 2013 06:39:50 +0000 Received: from CO9EHSOBE024.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 20 May 2013 06:39:07 +0000 Received: from mail18-co9-R.bigfish.com (10.236.132.241) by CO9EHSOBE024.bigfish.com (10.236.130.87) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 May 2013 06:38:48 +0000 Received: from mail18-co9 (localhost [127.0.0.1]) by mail18-co9-R.bigfish.com (Postfix) with ESMTP id 015963A083D; Mon, 20 May 2013 06:38:48 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 2 X-BigFish: PS2(zzc85fhzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz17326ah18c673h8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh9a9j1155h) Received-SPF: softfail (mail18-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=charliek@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2PR03MB593; H:CH1PR03MB599.namprd03.prod.outlook.com; LANG:en; Received: from mail18-co9 (localhost.localdomain [127.0.0.1]) by mail18-co9 (MessageSwitch) id 1369031926996168_23641; Mon, 20 May 2013 06:38:46 +0000 (UTC) Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.236]) by mail18-co9.bigfish.com (Postfix) with ESMTP id F0CAD340078; Mon, 20 May 2013 06:38:46 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 May 2013 06:38:46 +0000 Received: from BL2PR03MB593.namprd03.prod.outlook.com (10.255.109.36) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.311.1; Mon, 20 May 2013 06:38:45 +0000 Received: from BL2PR03MB593.namprd03.prod.outlook.com ((10.255.109.36)) by BL2PR03MB593.namprd03.prod.outlook.com ((10.255.109.36)) with ShadowRedundancy id 15.0.680.19; Mon, 20 May 2013 06:38:45 +0000 Received: from CH1PR03MB599.namprd03.prod.outlook.com (10.255.156.164) by BL2PR03MB593.namprd03.prod.outlook.com (10.255.109.36) with Microsoft SMTP Server (TLS) id 15.0.680.19; Mon, 20 May 2013 06:38:41 +0000 Received: from CH1PR03MB599.namprd03.prod.outlook.com ([169.254.7.86]) by CH1PR03MB599.namprd03.prod.outlook.com ([169.254.7.86]) with mapi id 15.00.0698.010; Mon, 20 May 2013 06:38:41 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-eastlake-rfc5342bis.all@tools.ietf.org" Thread-Topic: Secdir review of draft-eastlake-rfc5342bis-02 Thread-Index: Ac5VItQMwrxHzODCTO+I0n35ML5kGg== Date: Mon, 20 May 2013 06:38:39 +0000 Message-ID: <88dab74d72cc4a0daa2b2050ccc7ebc0@CH1PR03MB599.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.151.49] Content-Type: multipart/alternative; boundary="_000_88dab74d72cc4a0daa2b2050ccc7ebc0CH1PR03MB599namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PR03MB593.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(69226001)(77982001)(76482001)(80022001)(33646001)(81542001)(65816001)(15202345002)(16676001)(16236675002)(81342001)(49866001)(74316001)(79102001)(71186001)(56816002)(6806003)(44976003)(56776001)(74366001)(59766001)(74706001)(31966008)(46102001)(53806001)(50986001)(47976001)(74876001)(47736001)(20776003)(63696002)(74662001)(51856001)(512954002)(54356001)(47446002)(66066001)(74502001)(4396001)(54316002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB008; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0852EB6797 Subject: [secdir] Secdir review of draft-eastlake-rfc5342bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 06:39:59 -0000 --_000_88dab74d72cc4a0daa2b2050ccc7ebc0CH1PR03MB599namprd03pro_ 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 document is a minor update to rfc5342bis, which discusses IANA conside= rations for the assignment of code points below the IANA OUI delegated to t= he IETF by IEEE 802. This document decouples the assignment of unicast and = multicast addresses, which should lead to a more efficient allocation given= that few protocols need both. It also allocates some code points for use i= n documentation as examples. There really are no security considerations associated with this document. = The author points out as a security consideration that allocation of code p= oints for use in documentation may reduce confusion and conflict if people = erroneously copy code points literally from documentation rather than subst= ituting their own assigned values, and such confusion could have resulted i= n security issues. I found no typos or other errors other than there may be a formatting glitc= h on the first page of the .pdf version, where my printer put the page 1 tr= ailer line on a page by itself. --Charlie --_000_88dab74d72cc4a0daa2b2050ccc7ebc0CH1PR03MB599namprd03pro_ Content-Type: text/html; charset="us-ascii" 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 document is a minor update to rfc5342bis, which= discusses IANA considerations for the assignment of code points below the = IANA OUI delegated to the IETF by IEEE 802. This document decouples the ass= ignment of unicast and multicast addresses, which should lead to a more efficient allocation given that few protocols = need both. It also allocates some code points for use in documentation as e= xamples.

 

There really are no security considerations associat= ed with this document. The author points out as a security consideration th= at allocation of code points for use in documentation may reduce confusion = and conflict if people erroneously copy code points literally from documentation rather than substituting the= ir own assigned values, and such confusion could have resulted in security = issues.

 

I found no typos or other errors other than there ma= y be a formatting glitch on the first page of the .pdf version, where my pr= inter put the page 1 trailer line on a page by itself.

 

        &nbs= p;       --Charlie

--_000_88dab74d72cc4a0daa2b2050ccc7ebc0CH1PR03MB599namprd03pro_-- From charliek@microsoft.com Sun May 19 23:40:01 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF1C21F9023; Sun, 19 May 2013 23:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.535 X-Spam-Level: ** X-Spam-Status: No, score=2.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RAND_6=2, UNPARSEABLE_RELAY=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFyoAYNbcSAB; Sun, 19 May 2013 23:40:01 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id A84A621F9019; Sun, 19 May 2013 23:40:00 -0700 (PDT) Received: from BN1BFFO11FD001.protection.gbl (10.58.52.201) by BN1AFFO11HUB021.protection.gbl (10.58.52.131) with Microsoft SMTP Server (TLS) id 15.0.698.0; Mon, 20 May 2013 06:39:53 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD001.mail.protection.outlook.com (10.58.53.61) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Mon, 20 May 2013 06:39:53 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 20 May 2013 06:38:45 +0000 Received: from mail140-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 May 2013 06:38:45 +0000 Received: from mail140-ch1 (localhost [127.0.0.1]) by mail140-ch1-R.bigfish.com (Postfix) with ESMTP id C7CDF36042E; Mon, 20 May 2013 06:38:44 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 2 X-BigFish: PS2(zzc85fhzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz17326ah18c673h8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh9a9j1155h) Received-SPF: softfail (mail140-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=charliek@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:CH1PR03MB599; H:CH1PR03MB599.namprd03.prod.outlook.com; LANG:en; Received: from mail140-ch1 (localhost.localdomain [127.0.0.1]) by mail140-ch1 (MessageSwitch) id 1369031922818453_32363; Mon, 20 May 2013 06:38:42 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail140-ch1.bigfish.com (Postfix) with ESMTP id C59941A004B; Mon, 20 May 2013 06:38:42 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 May 2013 06:38:42 +0000 Received: from CH1PR03MB599.namprd03.prod.outlook.com (10.255.156.164) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.311.1; Mon, 20 May 2013 06:38:42 +0000 Received: from CH1PR03MB599.namprd03.prod.outlook.com (10.255.156.164) by CH1PR03MB599.namprd03.prod.outlook.com (10.255.156.164) with Microsoft SMTP Server (TLS) id 15.0.698.13; Mon, 20 May 2013 06:38:41 +0000 Received: from CH1PR03MB599.namprd03.prod.outlook.com ([169.254.7.86]) by CH1PR03MB599.namprd03.prod.outlook.com ([169.254.7.86]) with mapi id 15.00.0698.010; Mon, 20 May 2013 06:38:41 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-eastlake-rfc5342bis.all@tools.ietf.org" Thread-Topic: Secdir review of draft-eastlake-rfc5342bis-02 Thread-Index: Ac5VItQMwrxHzODCTO+I0n35ML5kGg== Date: Mon, 20 May 2013 06:38:39 +0000 Message-ID: <88dab74d72cc4a0daa2b2050ccc7ebc0@CH1PR03MB599.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.151.49] Content-Type: multipart/alternative; boundary="_000_88dab74d72cc4a0daa2b2050ccc7ebc0CH1PR03MB599namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PR03MB599.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(46102001)(77982001)(31966008)(79102001)(76482001)(56816002)(47446002)(74662001)(47736001)(53806001)(4396001)(51856001)(50986001)(74502001)(54356001)(56776001)(54316002)(33646001)(49866001)(74366001)(59766001)(63696002)(74706001)(74876001)(69226001)(47976001)(20776003)(81542001)(512954002)(6806003)(65816001)(80022001)(71186001)(74316001)(81342001)(16236675002)(15202345002)(16676001)(66066001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB021; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0852EB6797 Subject: [secdir] Secdir review of draft-eastlake-rfc5342bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 06:40:01 -0000 --_000_88dab74d72cc4a0daa2b2050ccc7ebc0CH1PR03MB599namprd03pro_ 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 document is a minor update to rfc5342bis, which discusses IANA conside= rations for the assignment of code points below the IANA OUI delegated to t= he IETF by IEEE 802. This document decouples the assignment of unicast and = multicast addresses, which should lead to a more efficient allocation given= that few protocols need both. It also allocates some code points for use i= n documentation as examples. There really are no security considerations associated with this document. = The author points out as a security consideration that allocation of code p= oints for use in documentation may reduce confusion and conflict if people = erroneously copy code points literally from documentation rather than subst= ituting their own assigned values, and such confusion could have resulted i= n security issues. I found no typos or other errors other than there may be a formatting glitc= h on the first page of the .pdf version, where my printer put the page 1 tr= ailer line on a page by itself. --Charlie --_000_88dab74d72cc4a0daa2b2050ccc7ebc0CH1PR03MB599namprd03pro_ Content-Type: text/html; charset="us-ascii" 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 document is a minor update to rfc5342bis, which= discusses IANA considerations for the assignment of code points below the = IANA OUI delegated to the IETF by IEEE 802. This document decouples the ass= ignment of unicast and multicast addresses, which should lead to a more efficient allocation given that few protocols = need both. It also allocates some code points for use in documentation as e= xamples.

 

There really are no security considerations associat= ed with this document. The author points out as a security consideration th= at allocation of code points for use in documentation may reduce confusion = and conflict if people erroneously copy code points literally from documentation rather than substituting the= ir own assigned values, and such confusion could have resulted in security = issues.

 

I found no typos or other errors other than there ma= y be a formatting glitch on the first page of the .pdf version, where my pr= inter put the page 1 trailer line on a page by itself.

 

        &nbs= p;       --Charlie

--_000_88dab74d72cc4a0daa2b2050ccc7ebc0CH1PR03MB599namprd03pro_-- From kivinen@iki.fi Mon May 20 06:11:23 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB6621F90DF; Mon, 20 May 2013 06:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNAotlcycD0D; Mon, 20 May 2013 06:11:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id B286321F90B9; Mon, 20 May 2013 06:11:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r4KDBEGK029931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 May 2013 16:11:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r4KDBDKj028270; Mon, 20 May 2013 16:11:13 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20890.8433.87412.68437@fireball.kivinen.iki.fi> Date: Mon, 20 May 2013 16:11:13 +0300 From: Tero Kivinen To: "Leaf Yeh" In-Reply-To: <5197814e.04fc440a.31ee.7730@mx.google.com> References: <20885.20435.315856.407689@fireball.kivinen.iki.fi> <51967458.22d9440a.44f5.7843@mx.google.com> <20886.31527.670959.767940@fireball.kivinen.iki.fi> <5197814e.04fc440a.31ee.7730@mx.google.com> X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org, 'Tomek Mrugalski' , 'Ted Lemon' , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 13:11:23 -0000 Leaf Yeh writes: > The text in section 9 will be 'The allocation policy of this 'RADIUS > attributes permitted in DHCPv6 RADIUS option' registry is Expert Review > . Designated expert should carefully consider the > security implications of allowing the relay agent to include new RADIUS > attribute for the addition to this registry.' OK? Looks good. -- kivinen@iki.fi From leaf.yeh.sdo@gmail.com Mon May 20 08:47:19 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB05421F92E8; Mon, 20 May 2013 08:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsWmPlG8nHQp; Mon, 20 May 2013 08:47:14 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id C01F021F92E3; Mon, 20 May 2013 08:47:14 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id bj3so5824182pad.15 for ; Mon, 20 May 2013 08:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=xH6PuOy/gjVfLAtvalSSmCj9dVgrXtwB+hB05cfxZoU=; b=v92WJlXVhjBF0SMcaVci/602xb0yMj5OOBlpaIleY7ESBQV6vOj2gWEc5QZzfoeQLs CcPscjfLb7SyZhRMClTN0OXmAzYnetQ1eP1uzdTUvJVjfxNZzhIxkf7aHyY4BckJwhGY iFEgk43VvnEDC3sa5wbWNnN2bdMWLPMSfpaAhjEGvFQFDXbDWZqGQeIVCgVkaAq1+q3E UnZzYolZ6T1kNqEiHAj2wnJMmLAOvmXuXsH49R0nJHkuYfK5Cj3uLY8Z3050v4gDSd+T vXZ/QoX9gbBt92x+2oKWANf6GtjDfZdd3J/du2rOoow2/Drxxg8xdta5cDnmuhzpyebI LlnQ== X-Received: by 10.68.110.133 with SMTP id ia5mr60712412pbb.111.1369064834520; Mon, 20 May 2013 08:47:14 -0700 (PDT) Received: from PC ([221.223.164.6]) by mx.google.com with ESMTPSA id r6sm26308882pae.18.2013.05.20.08.47.09 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 May 2013 08:47:14 -0700 (PDT) From: "Leaf Yeh" To: "'Tero Kivinen'" References: <20885.20435.315856.407689@fireball.kivinen.iki.fi> <51967458.22d9440a.44f5.7843@mx.google.com> <20886.31527.670959.767940@fireball.kivinen.iki.fi> <5197814e.04fc440a.31ee.7730@mx.google.com> <20890.8433.87412.68437@fireball.kivinen.iki.fi> In-Reply-To: <20890.8433.87412.68437@fireball.kivinen.iki.fi> Date: Mon, 20 May 2013 23:47:06 +0800 Message-ID: <519a4582.0615420a.5710.ffffe9c5@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5VW4MWvPldzsaLRA60cIkaWTtvugAEGhmg Content-Language: zh-cn Cc: draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org, 'Tomek Mrugalski' , 'Ted Lemon' , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 15:47:19 -0000 FYI, the draft has been ver.-12, the updates can be found @ http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-radius-opt-12 . Best Regards, Leaf -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Monday, May 20, 2013 9:11 PM To: Leaf Yeh Cc: iesg@ietf.org; secdir@ietf.org; draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org; 'Tomek Mrugalski'; 'Ted Lemon' Subject: RE: Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11 Leaf Yeh writes: > The text in section 9 will be 'The allocation policy of this 'RADIUS > attributes permitted in DHCPv6 RADIUS option' registry is Expert > Review . Designated expert should carefully > consider the security implications of allowing the relay agent to > include new RADIUS attribute for the addition to this registry.' OK? Looks good. -- kivinen@iki.fi From shawn.emery@oracle.com Mon May 20 09:49:22 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1410821F9690; Mon, 20 May 2013 09:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Mf4lPy7Fuj9; Mon, 20 May 2013 09:49:15 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 96F6421F968F; Mon, 20 May 2013 09:49:15 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4KGnCej004794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 May 2013 16:49:13 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4KGnC8Y016776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 May 2013 16:49:13 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4KGnCAK023003; Mon, 20 May 2013 16:49:12 GMT Received: from [10.159.112.142] (/10.159.112.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 May 2013 09:49:11 -0700 Message-ID: <519A53CD.1060406@oracle.com> Date: Mon, 20 May 2013 10:48:13 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Bjorklund References: <5124827A.3070407@oracle.com> <519097A8.40409@oracle.com> <20130513.094441.442455286.mbj@tail-f.com> In-Reply-To: <20130513.094441.442455286.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-netmod-interfaces-cfg-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 16:49:22 -0000 On 05/13/13 01:44 AM, Martin Bjorklund wrote: > Hi, > > Shawn Emery 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 internet-draft specifies a data model used for the management of network >> interfaces. >> >> The security considerations section does exist and discusses that the data is >> made available through the NETCONF protocol. NETCONF uses SSH to access and >> transfer said data. It goes on to discuss the implications of unattended >> access to list and leaf data, but does not provide guidance on how to mitigate >> against unauthorized access. If this is discussed in the NETCONF draft then >> this draft should at least provide this reference. > This is discussed in the NETCONF Access Control Model (RFC 6536). We > got the same comment also from other reviewers, and we will update the > first paragraph to be: > > The YANG module defined in this memo is designed to be accessed via > the NETCONF protocol ^RFC6241^. The lowest NETCONF layer is the > secure transport layer and the mandatory-to-implement secure > transport is SSH ^RFC6242^. The NETCONF access control model > ^RFC6536^ provides the means to restrict access for particular > NETCONF users to a pre-configured subset of all available NETCONF > protocol operations and content. > > This text will go into the Security Considerations template that is > used for other YANG module documents as well. > > I hope this addresses your concern. Looks reasonable. Shawn. -- From bew@cisco.com Tue May 21 09:57:14 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0CE21F9588; Tue, 21 May 2013 09:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b2tjrALrOiD; Tue, 21 May 2013 09:57:09 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 60BA621F93C8; Tue, 21 May 2013 09:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3978; q=dns/txt; s=iport; t=1369155429; x=1370365029; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=C3PYm5bu1aY4yXzhZoUz4ReS82QCTzp+ApzK2jFSUuI=; b=fcnFBhPU4zMbYQJUaf8Bw9t2rQM11yamWk8k1IJh9jGs149mrKxbC8XL tn7ul3mUmpqvFLbrp50LjMM/4hISiJL6sfICIIOGJYfubujEDFHSsFo+Y hm54pwReV0Baw3RgrgHje6VW4PClLBQ2L0eoCmYk+UPE7zR1Kjr46/Yf3 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJSmm1GrRDoJ/2dsb2JhbABWA4MIwX+BCxZ0giMBAQEDATo2CQULCxguVwYKCRSHcwW7Yo1YgQ8jEAcRgmJhA4kfjhmRQIMvHIE1 X-IronPort-AV: E=Sophos;i="4.87,715,1363132800"; d="scan'208";a="79188945" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 21 May 2013 16:57:08 +0000 Received: from sjc-vpn6-693.cisco.com (sjc-vpn6-693.cisco.com [10.21.122.181]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4LGv8WV002230; Tue, 21 May 2013 16:57:08 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Weis In-Reply-To: <0A45961E-0E4B-40C1-B2DA-A4855778FF5E@tik.ee.ethz.ch> Date: Tue, 21 May 2013 09:57:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F342100-9456-4FF8-A19D-4F892AEEBB00@cisco.com> <0A45961E-0E4B-40C1-B2DA-A4855778FF5E@tik.ee.ethz.ch> To: Brian Trammell X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-ipfix-protocol-rfc5101bis.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ipfix-protocol-rfc5101bis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 16:57:14 -0000 (Adding Secdir and IETG which I accidentally omitted.) On May 21, 2013, at 9:40 AM, Brian Trammell = wrote: > Hi, Brian, >=20 > Many thanks for the review. Comments inline. >=20 > On 21 May 2013, at 18:15 , Brian Weis wrote: >=20 >> I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >>=20 >> This document specifies the IP Flow Information Export (IPFIX) = protocol used to transfer information about network flows to collecting = devices. Most of the document defines data types and record formats that = represent the flow information. The actual objects are not defined. = Implementation of TLS is mandated when IPPIX uses TCP as a transport, = and DLTS when IPFIX uses SCTP or UDP. >>=20 >> The Security Considerations section is comprehensive and well = written. The following comments are relatively minor but worth = considering. >>=20 >> 1. Section 11 describes confidentiality, integrity, and = authentication as important security requirements but omits any mention = of replay protection. Even though replay protection could possibly be = implemented at the IPPIX Collector level using timestamps (I have no = idea if it is), it is still an important service of the security = protocol to stop unwanted segments or packets before decryption. I would = suggest adding this as list item 4 in this section and mentioning in = Section 11.1 that both TLS and DTLS perform replay protection using = sequence numbers. >=20 > Replay protection wasn't considered as a requirement in RFC 3917, = possibly because "replays" occur in many measurement infrastructures = where the same packet may be measured at multiple points, and contribute = to multiple flows; therefore much post-collection analysis is focused on = de-duplication, which would catch any record replay as well.=20 >=20 > (Note as an aside that removing measurement error, including = duplication, from medium-to-large-scale flow collection infrastructures = is still enough of an area of research that a recent student from our = group devoted a chapter thereto in his thesis; at least in the research = community we're enough used to cleaning up dirty flow records that a = simple message replay would present a pleasantly simple challenge. :)=20 >=20 > But as you say, that's a _record_-level consideration, not a = message-level one, and it's still useful to have message-level replay = protection (which we get for free anyway), so we can certainly note this = as you suggest in the next revision. >=20 >> 2. In Section 11 at the very top of page 50 I would suggest = clarifying the point as s/connection/connection assumed to be = unavailable to attackers/. >=20 > Good point. Will clarify. >=20 >> 3. Section 11.3 mandates certain versions of TLS. It would be helpful = for interoperability to also specify a mandatory to implement cipher = suite. >=20 > We'd sort of presumed that this was covered by section 9 of RFC 5246 = (as I _hope_ that any IPFIX over TLS implementation will grab a tested = TLS implementation off some shelf somewhere, and pick up the MTI that = way), but we can make this explicit. You're right, the TLS mandatory to implement requirement pretty much = satisfies your need. It's possible that TLS could be updated to declare = a different cipher suite as the mandatory one, so if you thought it was = important for IPFIX interoperability to stick with one you could make it = explicit in your document. Thanks, Brian >=20 > Again, thanks, best regards, >=20 > Brian --=20 Brian Weis Security Engineering, SRG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From dharkins@lounge.org Tue May 21 12:22:54 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E1611E80D9; Tue, 21 May 2013 12:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsFG1OW0vFmb; Tue, 21 May 2013 12:22:48 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 60B3511E80D2; Tue, 21 May 2013 12:22:47 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 03AB9A888004; Tue, 21 May 2013 12:22:47 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 21 May 2013 12:22:47 -0700 (PDT) Message-ID: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> Date: Tue, 21 May 2013 12:22:47 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-addr-select-opt.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] secdir review of draft-ietf-6man-addr-select-opt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 19:22:54 -0000 Hello, I have reviewed draft-ietf-6man-addr-select-opt as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. draft-ietf-6man-addr-select-opt defines address selection options for DHCPv6 that allow a network administrator to effect some control over address selection behavior of nodes on their sites. This sounds like a reasonably straightforward problem but as I read the draft it seemed like it might be have interoperability issues. I don't believe this draft is ready for advancement until these issues are resolved. For instance, while I think I understand the policy override of RFC 6724, having the Automatic Row Additions Flag be part of the address selection options seems problematic. If it is set to zero, then what are the semantics of such a message? "Here's an address selection option but don't you dare use it!"? What is the point? Me, as a node, can have this as part of my policy state which would allow me to ignore such an update but to have the bit be part of the option to update does not seem to make much sense. The semantics of the message needs to be explained much more clearly, or the bit needs to be removed from the message. Section 3.3 says, "Even if the received policy from one source is merged with one from another source, the effect of both policy are more or less changed." I don't understand how both policies are changed. And what does "more or less" mean? 3.3 also says, "It also should be noted that absence of the distributed policy from a certain network interface should not be treated as absence of policy itself, because it may mean preference for the default address selection policy." So I use the default address selection policy then, is that it? This whole section (3.3) screams out for some normative language since it sounds like it refers to behavioral changes on the node. There is an "Implementation Consideration" mentioning that the label is passed as an unsigned integer. But it then goes on to say, "DHCPv6 clients SHOULD convert this label to a representation appropriate for the local implementation (e.g., string)." This has interoperability implications because it is not solely a local matter. The node may represent these things differently than the network administrator and the preference will not be done properly. RFC 6724 does not really define what the label is from what I can tell. It's used to just allow for policies to prefer a particular source address, S, with a particular destination address, D, if "Label(S) = Label(D)". But to pass a value over a network, and have it be used by the recipient, means that a canonical representation of "label" has to be defined. An appendix with examples would be most helpful! Spelling nit: section 3.1 "The choice a SHOULD be default, as far as the policy table is not configured by the user." There's an extra word in there somewhere, or maybe there's some words missing, it's hard to understand what is being implied. regards, Dan. From kivinen@iki.fi Thu May 23 02:22:07 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD13C21F9683 for ; Thu, 23 May 2013 02:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrCXhCcSKyZG for ; Thu, 23 May 2013 02:22:06 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 57F7B21F9676 for ; Thu, 23 May 2013 02:22:04 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r4N9M0FH017984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 23 May 2013 12:22:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r4N9M0HR017681; Thu, 23 May 2013 12:22:00 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20893.57271.793145.686423@fireball.kivinen.iki.fi> Date: Thu, 23 May 2013 12:21:59 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 5 min X-Total-Time: 5 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 09:22:08 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yoav Nir would have been next in the rotation, but because of the large NFSv4 review he did (thanks), I skipped him. Magnus Nystrom is next in the rotation. Chris Lonvick got the hardball this time, 302 pages of the draft-ietf-mmusic-rfc2326bis-34. For telechat 2013-05-30 Reviewer LC end Draft Rob Austein T 2013-05-06 draft-ietf-bmwg-imix-genome-04 Warren Kumari T 2013-05-24 draft-ietf-softwire-public-4over6-09 Ondrej Sury T 2013-04-23 draft-ietf-manet-olsrv2-mib-08 Last calls and special requests: Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-05-06 draft-ietf-geopriv-held-measurements-07 David Harrington 2013-05-09 draft-ietf-6man-impatient-nud-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Scott Kelly 2013-05-29 draft-ietf-cuss-sip-uui-10 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Julien Laganier - draft-ietf-avtcore-rtp-security-options-03 Ben Laurie 2013-06-05 draft-ietf-lwig-terminology-04 Matt Lepinski - draft-ietf-manet-nhdp-sec-threats-03 Chris Lonvick 2013-06-04 draft-ietf-mmusic-rfc2326bis-34 Catherine Meadows 2013-06-04 draft-ietf-mmusic-sdp-miscellaneous-caps-05 Alexey Melnikov - draft-ietf-payload-rtp-howto-03 Kathleen Moriarty 2013-06-03 draft-ietf-xrblock-rtcp-xr-discard-14 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Russ Mundy 2013-03-30 draft-ietf-roll-terminology-12 Russ Mundy 2013-05-31 draft-ietf-xrblock-rtcp-xr-jb-11 Sandy Murphy 2013-06-17 draft-jabley-dnsext-eui48-eui64-rrtypes-03 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 David Waltermire 2013-05-14 draft-housley-rfc2050bis-01 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-07 Brian Weis 2013-05-01 draft-ietf-ipfix-protocol-rfc5101bis-06 Nico Williams - draft-ietf-httpbis-p5-range-22 -- kivinen@iki.fi From benl@google.com Thu May 23 04:48:13 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A9521F92EB for ; Thu, 23 May 2013 04:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kqUbaecugZC for ; Thu, 23 May 2013 04:48:13 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id D7C7721F92CB for ; Thu, 23 May 2013 04:48:12 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id u16so8517837iet.0 for ; Thu, 23 May 2013 04:48:12 -0700 (PDT) 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=4a+EwRvEpWja6Ty/HEEeqW3xjHKxQrsWgpF3Qu1bUP8=; b=LI+DgJbcUtXznfiZUgDAcra1IjM6sFRAZ/EBwDr9+pO6eASzZ3ojWNT842CtHyqozs csO14GDz80eMwqorfD21ifOMsGMghpH1hmbhjzEkmiylA9++z2LJFtyTT25f64Fth2Wv itYI/wBXbc+u+lstkWw445qvmkwVmLab3WnHMsnnTKgSmDZX1krg1UpOf6/oI7VH9GXa w3472/6t7N0Y2GGcfhIrmwvU/BbeS0tgdT+ovk2GwtVzUyCN37oeidbuzf6P/iIgGpMY Cw3BSl4EwCt4qmiwmb3lgzo1dxQoDzIOrmuwrohPw4tu4PaQx39GNOVGIUq41CWQDt58 VUEA== X-Google-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 :x-gm-message-state; bh=4a+EwRvEpWja6Ty/HEEeqW3xjHKxQrsWgpF3Qu1bUP8=; b=VkNTs1nrSAzbpVgWBPPnLajAQDEnvUnssZjJ9sTco7f7Fqj4woSpJPydYwXgCPXyqL dUkSEQmKA32Eo9Wv84Y3P1fygE3lW/TmY9t8/vp6iH8ZI854PUYzMHs8VJ+z0F+YIyNb RjCCxxNm4hY/HlbR8V0fwrrAes1Mf9ufbk2n1rwA4vABDMwj9pOEW5tQjIebWb2sJ64x ly+wgulC8HFEVcz3cdbJHsYulP9ct8DRUDvO6+cK8Dt5Xg0f/n2OLLDv+T4buK9KlOPu hb1Lc4WvXWVs3NQU7WN2da0saB0BrCYaKElsJucNYLCNSxWi8VRms/SLik/+AJrbZ++c 6npw== MIME-Version: 1.0 X-Received: by 10.50.88.103 with SMTP id bf7mr11679289igb.9.1369309691908; Thu, 23 May 2013 04:48:11 -0700 (PDT) Received: by 10.64.230.232 with HTTP; Thu, 23 May 2013 04:48:11 -0700 (PDT) Date: Thu, 23 May 2013 12:48:11 +0100 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-lwig-terminology.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkJ75NOolPQ6Y3gBr9d15mb7nwk3zq7Imrv5kA17lvWpDLvHG0ZeZaCfmoAlvhDo66tViQ6Y6A1PqdqdHKuU6px1I1n18AqtkBh9Xww5/HPBId+25r5dpFOWIj/VHgPoGZNpL+WUIcBYYVcbLlfT2qgUEx6PBCs7xe1JTJYsILArJ/7SGZmJpBAxPNwOX7Qig9mfFLd Subject: [secdir] Security directorate review of draft-ietf-lwig-terminology-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 11:48:13 -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. Status: Ready with nits. This document discusses networks comprised of constrained nodes (i.e. nodes with limited power, CPU, storage, etc.). It does cover whether various classes of nodes can participate in secure networks, which is good, but the Security Considerations section is empty - I would suggest that this section could usefully contain a summary of the security implications of the various constraints discussed. From sm@elandsys.com Thu May 23 10:09:34 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0AC21F96D1; Thu, 23 May 2013 10:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eazeMl0Xvrk; Thu, 23 May 2013 10:09:24 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2304821F97AF; Thu, 23 May 2013 10:01:28 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.5]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4NH19tF023443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 10:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369328483; bh=f2P5Im/Ou+JfF1Hocd/xVp2gEMi6IPhKKMZPn6qwNkY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QR/oNg8JfemcF/p+vLlpx4TS6MW89/guk7N/S97KnG2lU4rTUk8mx7nCbJn+dJneg prEoJm8g+N8NNs0ixKku5exwxyJODNOWICfoeWFzjseLnq2wfpJgf0eQMP/NRPi9WK 1UPYUpVnQMjrE94UgomphQ5e/v2T+0OMLOyfnei0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369328483; i=@elandsys.com; bh=f2P5Im/Ou+JfF1Hocd/xVp2gEMi6IPhKKMZPn6qwNkY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=08CX6TUD0z2qwkfaYc70KJYz6AQzCkLkq+kXegVrxZuT15aS6cDuTDwnwCTaPfWzn deMJgFmh9V0fTpdCvz2pxMjFSiuDObUJPXi5ofUPZf8aQcduFOoNttQH3473V9ucUj Mp5I+uLAlfV8UIV1cpr2qI4frS/ekG7LqOk1qgCU= Message-Id: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 May 2013 10:01:02 -0700 To: Phillip Hallam-Baker From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-ietf-spfbis-4408bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 17:09:34 -0000 Hi Phillip, At 09:58 26-04-2013, Phillip Hallam-Baker wrote: >The document is clear and describes the SPF mechanism effectively. >The only quibble that I could find is that repeated mentions are >made of limiting the number of 'DNS queries' without specifying >whether these are individual queries or recursive. The count will >come out rather differently if looking up TXT/x.example.com counts >as one lookup or three. I think it is reasonably clear that this is >one but could not find an explicit statement to that effect. > >On the security side, the document addresses all the mail issues >that I can remember at this point and rather more besides. > >I think we have reached the point of diminishing returns. > >The document provides a clear enough warning to people configuring >SPF records as to the consequences of getting it wrong which is the >main concern. The filtering services will know their business well >enough to minimize false positives. > >Hopefully the email infrastructure will evolve over time towards >concentrating on the more policy friendly approaches and it will be >possible to simplify the mechanism at a future date. There are two comments about the security directorate review of draft-ietf-spfbis-4408bis-14 at http://www.ietf.org/mail-archive/web/spfbis/current/msg03723.html and http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html The SPFBIS WG does not plan to make any change to draft-ietf-spfbis-4408bis. Please let me know if you consider that the security directorate review has not been addressed. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Thu May 23 12:54:29 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5670B21F8F6D; Thu, 23 May 2013 12:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNb1mVWB4vTD; Thu, 23 May 2013 12:54:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 120D521F97EE; Thu, 23 May 2013 12:15:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.5]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4NJFTlB011947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 12:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369336543; bh=A4gR+4J5IGaopWkzi5DjRnhEq3Rjks54l68so2KH6u4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MzS0e1ZjgN2XYKChaLLkx/BCc8gfIo0T62Iq2UZlK5go0d3++TTUKFxiH528wA/bE SvX9axZyn1PX3BJ6VrzamOs7s7S+cnyaZNxHSiBs9VhTi4AAKYH0LU94cvrROSC3TS 8v3n8whQZCJMAApTBQUhpjQhRw+jFwTQUBydiV4c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369336543; i=@elandsys.com; bh=A4gR+4J5IGaopWkzi5DjRnhEq3Rjks54l68so2KH6u4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pWIoThYLaq3G+Lmepcd3BXyGwcw+lmCmpFbnsZqrhHhmwT2NVAxfUV9YzTWWypeo/ pvbh2nl8RTob1muF9O2mDbvTtCB/gIs2AUBvJCaSca7DQALvrfVjckJMTqfH1WCkVr pyHQ4GDaanSmVwQOCIJnCXFXoYRrHJZXz7iRyfvI= Message-Id: <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 May 2013 12:14:32 -0700 To: Douglas Otis From: S Moonesamy In-Reply-To: <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.com> References: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] [spfbis] draft-ietf-spfbis-4408bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 19:54:32 -0000 Hi Doug, At 11:58 23-05-2013, Douglas Otis wrote: >Greater clarity would have been achieved by separating transactions >involving the SPF checkhost process (spfch-transactions) which may >then generate some number of recursive dns server transactions >(rdns-transactions). > >A transaction made at the spfch level will result in some number of >transactions at the rdns level, which could then be described as >representing some number of separate DNS queries. > >Confusion has been caused by conflating checkhost and recursive DNS >transactions with that of non-recursive DNS which may involve dozens >of unique queries to resolve any particular resource. This is bad >and is a continuing source of confusion. What I noted among other things in the review was "the only quibble" and "it is reasonably clear". >A practical means to simplify SPF's impact on a receiver's DNS is to >first ignore SPF records containing macro expressions. This happens >and this may explain the nearly 100% lack of macro use. They then >limit the number of SPF resource records and MX mechanisms and >ignore the PTR mechanism. Appreciate what receivers consider a >reasonable demand on their resources that offers cache-able results. I don't see any relation between the security directorate review ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html ) to the above (quoted paragraph). If the security directorate reviewer is of the opinion that it is related to his review I will ask the SPFBIS to comment about the matter. Regards, S. Moonesamy (as document shepherd) From doug.mtview@gmail.com Thu May 23 12:29:11 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD0E21F90AC; Thu, 23 May 2013 12:29:11 -0700 (PDT) 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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMCSC+6uBqDz; Thu, 23 May 2013 12:28:57 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4DD21F96C7; Thu, 23 May 2013 11:58:20 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v14so2005229pde.32 for ; Thu, 23 May 2013 11:58:20 -0700 (PDT) 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:x-mailer; bh=tFHq9RbIQfrmwJ6DJiQlDKjQC99NSvu8+vlNYB1zdpg=; b=ckf1jYLsn0EcIjv/BkhPdAjeeWquay0NaGX/asA2IRZHV5cD4e7XfeFZPGmt3zPw5d iJ/GxuzmYrnTW1Djl9RnwkG2xCNeqHk7+vjJY4K+RsNK9vUBFYKz0mC9NI8r6Uk8Gg4k bl1AJair+kQapDdetVNZBJcZ5rTt4IjlB4VWpmrc4vJrKmR1tvAmT9E7xm5UOQx0pd8S 0Y/JL8ZIEsSORQYH8+XIIsFN29qSOIbk1cfe0aixEjsdhWTUCoxYMsF16yNMw1o4sRws YNmcVAykgWrw+33uLFsj2Rd1nECnVlMTw/rYXcNa91mKJZwGgO9Ayt1fbpvim1gy+JE9 oxhA== X-Received: by 10.68.164.226 with SMTP id yt2mr14310305pbb.203.1369335500037; Thu, 23 May 2013 11:58:20 -0700 (PDT) Received: from [192.168.1.194] (c-24-4-157-244.hsd1.ca.comcast.net. [24.4.157.244]) by mx.google.com with ESMTPSA id if5sm12729646pbb.31.2013.05.23.11.58.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 11:58:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> Date: Thu, 23 May 2013 11:58:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.com> References: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Fri, 24 May 2013 01:43:22 -0700 Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] [spfbis] draft-ietf-spfbis-4408bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 19:29:11 -0000 On May 23, 2013, at 10:01 AM, S Moonesamy wrote: > Hi Phillip, > At 09:58 26-04-2013, Phillip Hallam-Baker wrote: >> The document is clear and describes the SPF mechanism effectively. = The only quibble that I could find is that repeated mentions are made of = limiting the number of 'DNS queries' without specifying whether these = are individual queries or recursive. The count will come out rather = differently if looking up TXT/x.example.com counts as one lookup or = three. I think it is reasonably clear that this is one but could not = find an explicit statement to that effect. >>=20 >> On the security side, the document addresses all the mail issues that = I can remember at this point and rather more besides. >>=20 >> I think we have reached the point of diminishing returns. >>=20 >> The document provides a clear enough warning to people configuring = SPF records as to the consequences of getting it wrong which is the main = concern. The filtering services will know their business well enough to = minimize false positives. >>=20 >> Hopefully the email infrastructure will evolve over time towards = concentrating on the more policy friendly approaches and it will be = possible to simplify the mechanism at a future date. >=20 > There are two comments about the security directorate review of = draft-ietf-spfbis-4408bis-14 at = http://www.ietf.org/mail-archive/web/spfbis/current/msg03723.html and = http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html >=20 > The SPFBIS WG does not plan to make any change to = draft-ietf-spfbis-4408bis. Please let me know if you consider that the = security directorate review has not been addressed. Dear SM and Scott, Greater clarity would have been achieved by separating transactions = involving the SPF checkhost process (spfch-transactions) which may then = generate some number of recursive dns server transactions = (rdns-transactions). A transaction made at the spfch level will result in some number of = transactions at the rdns level, which could then be described as = representing some number of separate DNS queries. Confusion has been caused by conflating checkhost and recursive DNS = transactions with that of non-recursive DNS which may involve dozens of = unique queries to resolve any particular resource. This is bad and is a = continuing source of confusion. A practical means to simplify SPF's impact on a receiver's DNS is to = first ignore SPF records containing macro expressions. This happens and = this may explain the nearly 100% lack of macro use. They then limit the = number of SPF resource records and MX mechanisms and ignore the PTR = mechanism. Appreciate what receivers consider a reasonable demand on = their resources that offers cache-able results. Regards, Douglas Otis From stephen.farrell@cs.tcd.ie Fri May 24 02:12:00 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7C921F9643 for ; Fri, 24 May 2013 02:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08ZbcJazcBjg for ; Fri, 24 May 2013 02:11:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D371E21F967F for ; Fri, 24 May 2013 02:11:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 09027BE79 for ; Fri, 24 May 2013 10:11:29 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYute+XGPZLQ for ; Fri, 24 May 2013 10:11:26 +0100 (IST) Received: from [10.87.48.5] (unknown [86.41.48.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1F630BE50 for ; Fri, 24 May 2013 10:11:26 +0100 (IST) Message-ID: <519F2EBD.1030408@cs.tcd.ie> Date: Fri, 24 May 2013 10:11:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "secdir@ietf.org" References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> In-Reply-To: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Fwd: timing of reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 09:12:00 -0000 Folks, Jari's mail below says it better than I could. What do you think about this? Thanks, S. -------- Original Message -------- Subject: timing of reviews Date: Fri, 24 May 2013 01:28:48 +0300 From: Jari Arkko To: General Area Review Team CC: The IESG Thanks again for all your hard work in doing the reviews. They make it possible for me to concentrate on reviewing just those documents where there are problems or I have deeper expertise. And the quality of the protocol specifications coming out of the IETF is obviously very important, particularly for protocols that are gaining significant use. As you may have seen, the IESG and the community has been wondering if there'd be something that we could do about the IETF process, in the sense that there's quite many things happening at the very end of the document's life cycle. This results in some surprises, and often also moves some important decisions out of the working group and to author/shepherd/AD hands. A while ago we met for the IESG retreat and wanted to experiment with three specific changes: - sending work back to the WGs when significant changes are needed, and making the WG the central place of the edits - moving some directorate reviews earlier, without impact reviewer effort too much - inviting some of the shepherds onto tele chats I am writing to you in order to discuss the second item. How big of a change would it be to have Gen-ART reviews be invoked during WGLC, while the documents are still in the working groups? The goal of the reviews would still be the same, e.g., I would be checking that the reviews were positive and/or that the issues brought up have been properly addressed. There are important details to consider, however, and I would like to get your feedback on how you would seem them having an effect, and what would be the best way to organise this, if we decide to go ahead with the change for the Gen-ART. Triggering the review would have to be done by something else than IETF last call announcement. Is the best approach is to have the WG chairs manually request for this? Note that sometimes there are multiple WGLCs. I presume that it would be preferable to have a Gen-ART review be done only once at this stage, as otherwise the work load would increase. The chairs may have some idea of whether they are likely to need another WGLC before they start one. There may be possibly bigger changes and time lag between the first Gen-ART review and the one that checks that the changes are ok. Some specs may not make it through WGLC, and a review at that stage may increase the effort you guys are putting in, by reviewing those specs that will fail. Jari From kivinen@iki.fi Fri May 24 05:21:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD3421F967F for ; Fri, 24 May 2013 05:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcVOdLC9NVhm for ; Fri, 24 May 2013 05:21:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id F21FA21F9679 for ; Fri, 24 May 2013 05:21:01 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r4OCJXUx004660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 May 2013 15:19:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r4OCJWfk020301; Fri, 24 May 2013 15:19:32 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20895.23252.179339.686278@fireball.kivinen.iki.fi> Date: Fri, 24 May 2013 15:19:32 +0300 From: Tero Kivinen To: Stephen Farrell In-Reply-To: <519F2EBD.1030408@cs.tcd.ie> References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> <519F2EBD.1030408@cs.tcd.ie> X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 30 min X-Total-Time: 31 min Cc: Jari Arkko , "secdir@ietf.org" Subject: [secdir] Fwd: timing of reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 12:21:03 -0000 Stephen Farrell writes: > Jari's mail below says it better than I could. > > What do you think about this? I think one of the problems is that lately the IETF LC end time, and Telechat have been VERY close to each other. There are lots of documents coming in lately, where the IETF last call end date and the telechat date are same (for example draft-ietf-dhc-dhcpv6-radius-opt in last assignment) or there has been only one or two weeks between them (draft-ietf-ipsecme-dh-checks, draft-ietf-softwire-public-4over6 in last assignment). This makes it so that if reviewer finds some problems, there is no time to fix them before telechat. It used to be so that there was much bigger difference between the IETF LC and Telechat, and in that case there was even useful to do re-review at telechat time. Now there is no point to assign document to be re-reviewd at telechat time, as it was reviewed week or two earlier in the IETF LC time. > I am writing to you in order to discuss the second item. How big of a > change would it be to have Gen-ART reviews be invoked during WGLC, while > the documents are still in the working groups? The goal of the reviews > would still be the same, e.g., I would be checking that the reviews were > positive and/or that the issues brought up have been properly > addressed. That would make it easier to address bigger issues, especially as the WG would at that point be more wiling to change things. Sometimes it seems that suggesting some bigger changes week or two before the telechat time, is not going to be accepted well by the document authors. > Triggering the review would have to be done by something else than IETF > last call announcement. Is the best approach is to have the WG chairs > manually request for this? Note that sometimes there are multiple WGLCs. > I presume that it would be preferable to have a Gen-ART review be done > only once at this stage, as otherwise the work load would increase. The > chairs may have some idea of whether they are likely to need another > WGLC before they start one. The review tool currently takes the http://datatracker.ietf.org/feed/last-call/ rss feed and uses that to find the last calls. If there would be similar feed for WGLCs that would work fine from the tool point of view (I am not sure if there is anything like that now). We would still need to follow IETF last call status as not all documents go through WGLC. The review tool already supports quite easy way for secretary to add new documents to the list, i.e. WG can request earlier review and the document will be added to the tool for review at that point. The review tool also supports delegating the permission to add new documents to the review queue, so area-directors or selected members of the review team could add documents themselves. The next question would be how many reviews we need. Currently we officially do two, one for IETF LC, and re-review at telechat time, but quite often there is no need to do the second review: reviewer already said document is ready, or his changes were already done. In those case I will not re-assign it for re-review (I usually do check the diffs between the last reviewed version and current version). -- kivinen@iki.fi From stephen.farrell@cs.tcd.ie Fri May 24 05:30:56 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD29C21F8F6D for ; Fri, 24 May 2013 05:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iefn9CvCfsdS for ; Fri, 24 May 2013 05:30:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B7B2021F8ED8 for ; Fri, 24 May 2013 05:30:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8EF9FBE8E; Fri, 24 May 2013 13:30:29 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVJrks1oxTxH; Fri, 24 May 2013 13:30:27 +0100 (IST) Received: from [10.87.48.5] (unknown [86.41.48.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8041EBE79; Fri, 24 May 2013 13:30:27 +0100 (IST) Message-ID: <519F5D63.4000206@cs.tcd.ie> Date: Fri, 24 May 2013 13:30:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tero Kivinen References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> <519F2EBD.1030408@cs.tcd.ie> <20895.23252.179339.686278@fireball.kivinen.iki.fi> In-Reply-To: <20895.23252.179339.686278@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jari Arkko , "secdir@ietf.org" Subject: Re: [secdir] Fwd: timing of reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 12:30:56 -0000 Thanks Tero That's useful info about the mechanics. Also good to know you reckon WGLC might be a feasible time for secdir reviews. Others? Cheers, S. On 05/24/2013 01:19 PM, Tero Kivinen wrote: > Stephen Farrell writes: >> Jari's mail below says it better than I could. >> >> What do you think about this? > > I think one of the problems is that lately the IETF LC end time, and > Telechat have been VERY close to each other. There are lots of > documents coming in lately, where the IETF last call end date and the > telechat date are same (for example draft-ietf-dhc-dhcpv6-radius-opt > in last assignment) or there has been only one or two weeks between > them (draft-ietf-ipsecme-dh-checks, draft-ietf-softwire-public-4over6 > in last assignment). > > This makes it so that if reviewer finds some problems, there is no > time to fix them before telechat. It used to be so that there was much > bigger difference between the IETF LC and Telechat, and in that case > there was even useful to do re-review at telechat time. Now there is > no point to assign document to be re-reviewd at telechat time, as it > was reviewed week or two earlier in the IETF LC time. > >> I am writing to you in order to discuss the second item. How big of a >> change would it be to have Gen-ART reviews be invoked during WGLC, while >> the documents are still in the working groups? The goal of the reviews >> would still be the same, e.g., I would be checking that the reviews were >> positive and/or that the issues brought up have been properly >> addressed. > > That would make it easier to address bigger issues, especially as the > WG would at that point be more wiling to change things. Sometimes it > seems that suggesting some bigger changes week or two before the > telechat time, is not going to be accepted well by the document > authors. > >> Triggering the review would have to be done by something else than IETF >> last call announcement. Is the best approach is to have the WG chairs >> manually request for this? Note that sometimes there are multiple WGLCs. >> I presume that it would be preferable to have a Gen-ART review be done >> only once at this stage, as otherwise the work load would increase. The >> chairs may have some idea of whether they are likely to need another >> WGLC before they start one. > > The review tool currently takes the > http://datatracker.ietf.org/feed/last-call/ rss feed and uses that to > find the last calls. If there would be similar feed for WGLCs that > would work fine from the tool point of view (I am not sure if there is > anything like that now). > > We would still need to follow IETF last call status as not all > documents go through WGLC. > > The review tool already supports quite easy way for secretary to add > new documents to the list, i.e. WG can request earlier review and the > document will be added to the tool for review at that point. The > review tool also supports delegating the permission to add new > documents to the review queue, so area-directors or selected members > of the review team could add documents themselves. > > The next question would be how many reviews we need. Currently we > officially do two, one for IETF LC, and re-review at telechat time, > but quite often there is no need to do the second review: reviewer > already said document is ready, or his changes were already done. In > those case I will not re-assign it for re-review (I usually do check > the diffs between the last reviewed version and current version). > From jari.arkko@piuha.net Fri May 24 06:24:49 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F6F21F8689 for ; Fri, 24 May 2013 06:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mP-8Puarzc3h for ; Fri, 24 May 2013 06:24:37 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 57C8D21F8B98 for ; Fri, 24 May 2013 06:24:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AF7712CC53; Fri, 24 May 2013 16:24:20 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAZIfuHAYMvc; Fri, 24 May 2013 16:24:20 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 714BD2CC48; Fri, 24 May 2013 16:24:14 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jari Arkko In-Reply-To: <20895.23252.179339.686278@fireball.kivinen.iki.fi> Date: Fri, 24 May 2013 16:24:10 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> <519F2EBD.1030408@cs.tcd.ie> <20895.23252.179339.686278@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1503) Cc: secdir@ietf.org Subject: Re: [secdir] timing of reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 13:24:49 -0000 Thanks for your thoughts on this, Tero. Jari From yaronf.ietf@gmail.com Fri May 24 07:09:16 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6586621F961C for ; Fri, 24 May 2013 07:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBGJgmvrCoOb for ; Fri, 24 May 2013 07:09:15 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB1721F8FD0 for ; Fri, 24 May 2013 07:09:14 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id q16so2599256ead.23 for ; Fri, 24 May 2013 07:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uZXcsrd2gGG8IbTzNOOdQaNSWjoQB7s6enKo/avv7Bk=; b=ng6tDDq8cY4Z6BL468qDF3FUmvM4jYJ3dwkIgbLOvEScqP+hP6Nm+6oG7KTHoBDUYN jkU0yhw99aYjuIVeNwdmKwNXGFSlhRbqoo6BsSUD5FuItTYg0vysvHbCNMWi0aw3Moiv F3UmjGYRCFd/bi69TcnEsd8HJhWmkKh8L3EGfede/Oq3nIYXzL5lraagcVIlI4t/PAac F0A0PM/LED7En5p4b0RodG0KnVrlWPQ4wYyV22GKKDmvSIzBVmpnmB76YhJI5x0qgWJL 5tMyXn7I08GR4BGBTtG0cYAbp+lWFfBtgCACs+gSQIAwOTU54f2oQyzV1L4y4Rtuh/aB qxKA== X-Received: by 10.15.10.4 with SMTP id f4mr43544696eet.33.1369404554101; Fri, 24 May 2013 07:09:14 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-177-109-125.red.bezeqint.net. [79.177.109.125]) by mx.google.com with ESMTPSA id s43sm23792886eem.13.2013.05.24.07.09.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 07:09:13 -0700 (PDT) Message-ID: <519F7486.9030002@gmail.com> Date: Fri, 24 May 2013 17:09:10 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephen Farrell References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> <519F2EBD.1030408@cs.tcd.ie> <20895.23252.179339.686278@fireball.kivinen.iki.fi> <519F5D63.4000206@cs.tcd.ie> In-Reply-To: <519F5D63.4000206@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jari Arkko , "secdir@ietf.org" Subject: Re: [secdir] Fwd: timing of reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 14:09:16 -0000 I disagree with Tero. I think it would be a waste of my time to review drafts going into WGLC as a general process, since they are often not baked enough at this stage. I would definitely honor requests from WG chairs to do a secdir review at the WGLC stage, but this should be the exception. Thanks, Yaron On 2013-05-24 15:30, Stephen Farrell wrote: > > Thanks Tero > > That's useful info about the mechanics. > > Also good to know you reckon WGLC might be a feasible > time for secdir reviews. > > Others? > > Cheers, > S. > > On 05/24/2013 01:19 PM, Tero Kivinen wrote: >> Stephen Farrell writes: >>> Jari's mail below says it better than I could. >>> >>> What do you think about this? >> >> I think one of the problems is that lately the IETF LC end time, and >> Telechat have been VERY close to each other. There are lots of >> documents coming in lately, where the IETF last call end date and the >> telechat date are same (for example draft-ietf-dhc-dhcpv6-radius-opt >> in last assignment) or there has been only one or two weeks between >> them (draft-ietf-ipsecme-dh-checks, draft-ietf-softwire-public-4over6 >> in last assignment). >> >> This makes it so that if reviewer finds some problems, there is no >> time to fix them before telechat. It used to be so that there was much >> bigger difference between the IETF LC and Telechat, and in that case >> there was even useful to do re-review at telechat time. Now there is >> no point to assign document to be re-reviewd at telechat time, as it >> was reviewed week or two earlier in the IETF LC time. >> >>> I am writing to you in order to discuss the second item. How big of a >>> change would it be to have Gen-ART reviews be invoked during WGLC, while >>> the documents are still in the working groups? The goal of the reviews >>> would still be the same, e.g., I would be checking that the reviews were >>> positive and/or that the issues brought up have been properly >>> addressed. >> >> That would make it easier to address bigger issues, especially as the >> WG would at that point be more wiling to change things. Sometimes it >> seems that suggesting some bigger changes week or two before the >> telechat time, is not going to be accepted well by the document >> authors. >> >>> Triggering the review would have to be done by something else than IETF >>> last call announcement. Is the best approach is to have the WG chairs >>> manually request for this? Note that sometimes there are multiple WGLCs. >>> I presume that it would be preferable to have a Gen-ART review be done >>> only once at this stage, as otherwise the work load would increase. The >>> chairs may have some idea of whether they are likely to need another >>> WGLC before they start one. >> >> The review tool currently takes the >> http://datatracker.ietf.org/feed/last-call/ rss feed and uses that to >> find the last calls. If there would be similar feed for WGLCs that >> would work fine from the tool point of view (I am not sure if there is >> anything like that now). >> >> We would still need to follow IETF last call status as not all >> documents go through WGLC. >> >> The review tool already supports quite easy way for secretary to add >> new documents to the list, i.e. WG can request earlier review and the >> document will be added to the tool for review at that point. The >> review tool also supports delegating the permission to add new >> documents to the review queue, so area-directors or selected members >> of the review team could add documents themselves. >> >> The next question would be how many reviews we need. Currently we >> officially do two, one for IETF LC, and re-review at telechat time, >> but quite often there is no need to do the second review: reviewer >> already said document is ready, or his changes were already done. In >> those case I will not re-assign it for re-review (I usually do check >> the diffs between the last reviewed version and current version). >> > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From paul.hoffman@vpnc.org Fri May 24 08:16:14 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2288121F96C6 for ; Fri, 24 May 2013 08:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.605 X-Spam-Level: X-Spam-Status: No, score=-102.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igOozeKqQJHq for ; Fri, 24 May 2013 08:16:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 15A4921F8ECB for ; Fri, 24 May 2013 08:16:11 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4OFFeHv058698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 08:15:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <519F7486.9030002@gmail.com> Date: Fri, 24 May 2013 08:15:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <67FEC0F2-9C17-4CCA-B41C-85FCB40E59E7@vpnc.org> References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> <519F2EBD.1030408@cs.tcd.ie> <20895.23252.179339.686278@fireball.kivinen.iki.fi> <519F5D63.4000206@cs.tcd.ie> <519F7486.9030002@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1503) Cc: "secdir@ietf.org" , Jari Arkko Subject: Re: [secdir] timing of reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 15:16:14 -0000 On May 24, 2013, at 7:09 AM, Yaron Sheffer = wrote: > I disagree with Tero. I think it would be a waste of my time to review = drafts going into WGLC as a general process, since they are often not = baked enough at this stage. >=20 > I would definitely honor requests from WG chairs to do a secdir review = at the WGLC stage, but this should be the exception. And I disagree with my co-chair. :-) The primary purpose of secdir reviews is to review the security = properties of the document. The fact that many secdir reviewers feel a = need to comment on other aspects is fine, but not part of the primary = goal. The security properties of a document are generally fairly established = by WG LC. That seems like a fine time to tell if there are problems. Historically, area reviews tell the IETF if there are issues with a = document. It is more useful (if possible) to tell a WG of the problems = before the IETF-wide review. --Paul Hoffman= From ynir@checkpoint.com Fri May 24 08:34:55 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F55021F86D5 for ; Fri, 24 May 2013 08:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.462 X-Spam-Level: X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rY7OQd2YPMZh for ; Fri, 24 May 2013 08:34:49 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C0DF721F869A for ; Fri, 24 May 2013 08:34:48 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r4OFYg4A022121; Fri, 24 May 2013 18:34:46 +0300 X-CheckPoint: {519F8629-1-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Fri, 24 May 2013 18:33:41 +0300 From: Yoav Nir To: Paul Hoffman Thread-Topic: [secdir] timing of reviews Thread-Index: AQHOWJGq+6bFncfNsEmsmB53V1PYrpkURLgA Date: Fri, 24 May 2013 15:33:41 +0000 Message-ID: <5B38A51A-FD6B-4038-BB8D-D461DDF7ECDB@checkpoint.com> References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> <519F2EBD.1030408@cs.tcd.ie> <20895.23252.179339.686278@fireball.kivinen.iki.fi> <519F5D63.4000206@cs.tcd.ie> <519F7486.9030002@gmail.com> <67FEC0F2-9C17-4CCA-B41C-85FCB40E59E7@vpnc.org> In-Reply-To: <67FEC0F2-9C17-4CCA-B41C-85FCB40E59E7@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.204] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <4E25E3DE2190004DBDA69203CAD8FFC2@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jari Arkko , "secdir@ietf.org" Subject: Re: [secdir] timing of reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 15:34:55 -0000 On May 24, 2013, at 6:15 PM, Paul Hoffman wrote: > On May 24, 2013, at 7:09 AM, Yaron Sheffer wrote: >=20 >> I disagree with Tero. I think it would be a waste of my time to review d= rafts going into WGLC as a general process, since they are often not baked = enough at this stage. >>=20 >> I would definitely honor requests from WG chairs to do a secdir review a= t the WGLC stage, but this should be the exception. >=20 > And I disagree with my co-chair. :-) >=20 > The primary purpose of secdir reviews is to review the security propertie= s of the document. The fact that many secdir reviewers feel a need to comme= nt on other aspects is fine, but not part of the primary goal. >=20 > The security properties of a document are generally fairly established by= WG LC. That seems like a fine time to tell if there are problems. >=20 > Historically, area reviews tell the IETF if there are issues with a docum= ent. It is more useful (if possible) to tell a WG of the problems before th= e IETF-wide review. I guess this depends on the working group. Where WGLC is used to get the pa= rticipants to read the document for the first time, it can be half-baked. A= nd in that case the WGLC comments may include things like, "we need to add = this feature and that capability", or "let's allow a non-authenticated mode= (because PKI is too onerous)". So in that case the security properties may= change. But when WGLC are use for their intended purpose, I agree that this should = not be a problem. Yoav From jari.arkko@piuha.net Fri May 24 08:59:21 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B225221F9670 for ; Fri, 24 May 2013 08:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CvYhZMzdf7B for ; Fri, 24 May 2013 08:59:13 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 001F021F965B for ; Fri, 24 May 2013 08:59:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 45B082CC53; Fri, 24 May 2013 18:59:12 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jnnWl9_x3Sf; Fri, 24 May 2013 18:59:11 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id B32B52CC48; Fri, 24 May 2013 18:59:11 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jari Arkko In-Reply-To: <67FEC0F2-9C17-4CCA-B41C-85FCB40E59E7@vpnc.org> Date: Fri, 24 May 2013 18:59:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> <519F2EBD.1030408@cs.tcd.ie> <20895.23252.179339.686278@fireball.kivinen.iki.fi> <519F5D63.4000206@cs.tcd.ie> <519F7486.9030002@gmail.com> <67FEC0F2-9C17-4CCA-B41C-85FCB40E59E7@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: "secdir@ietf.org" , Jari Arkko Subject: Re: [secdir] timing of reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 15:59:23 -0000 I feel bad about getting you guys all disagree with each other :-) But back to substance. There are obvious situations where WGLC is done = on a document that is far from ready. It comes as a surprise, or the WG = chairs are doing it on purpose to solicit reviews that do not appear to = be forthcoming otherwise. While early help with half-finished documents = can be useful, I don't think we should waste secdir, Gen-ART, etc. = reviewer's time on it at that point. When we talked about this in the = IESG, it was brought up that the WG chairs should be involved in the = decision to call for review. I agree with that. There are details to = think about, however. Perhaps we can request review only for docs that = the chairs believe are well baked, and use the old process for others, = for instance. Jari From paul.hoffman@vpnc.org Fri May 24 09:17:50 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E8C21F8EBD for ; Fri, 24 May 2013 09:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.605 X-Spam-Level: X-Spam-Status: No, score=-102.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcajQQKCnkFg for ; Fri, 24 May 2013 09:17:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5716721F85EF for ; Fri, 24 May 2013 09:17:49 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4OGGNla061041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 09:16:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Fri, 24 May 2013 09:16:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> <519F2EBD.1030408@cs.tcd.ie> <20895.23252.179339.686278@fireball.kivinen.iki.fi> <519F5D63.4000206@cs.tcd.ie> <519F7486.9030002@gmail.com> <67FEC0F2-9C17-4CCA-B41C-85FCB40E59E7@vpnc.org> To: Jari Arkko X-Mailer: Apple Mail (2.1503) Cc: "secdir@ietf.org" Subject: Re: [secdir] timing of reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 16:17:50 -0000 On May 24, 2013, at 8:59 AM, Jari Arkko wrote: > I feel bad about getting you guys all disagree with each other :-) If WG co-chairs always agreed, you would only need one chair per WG. :-) > But back to substance. There are obvious situations where WGLC is done = on a document that is far from ready. It comes as a surprise, or the WG = chairs are doing it on purpose to solicit reviews that do not appear to = be forthcoming otherwise. While early help with half-finished documents = can be useful, I don't think we should waste secdir, Gen-ART, etc. = reviewer's time on it at that point. When we talked about this in the = IESG, it was brought up that the WG chairs should be involved in the = decision to call for review. I agree with that. There are details to = think about, however. Perhaps we can request review only for docs that = the chairs believe are well baked, and use the old process for others, = for instance. Maybe. But I also think that if the WG chair knows that the WG is going = to get all their out-of-area reviews when they press the "WG LC" button, = they might do a "pre-LC" call for more reviewers. This is a topic that = Yaron and I are actively working on in our less-than-active WG. A possibility for what you want is a new state or sub-state of "outside = reviews requested" that the WG chair can put in the tracker. I bet this = means that most chairs will forget to do this and Tero won't hear about = most documents until they are in IETF LC, so I'm hesitant to propose = this. --Paul Hoffman= From yaronf.ietf@gmail.com Fri May 24 10:35:21 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D03821F9644 for ; Fri, 24 May 2013 10:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDcGdn7KDMf9 for ; Fri, 24 May 2013 10:35:21 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D083421F9403 for ; Fri, 24 May 2013 10:35:20 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id f15so2709728eak.15 for ; Fri, 24 May 2013 10:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ThMQpySKR0CK/6wwWw0YJtDjFwzSr/uFOW4ow+1YGcA=; b=vsmjy6nte4d/GaN6HvkpNw/HgsqeM9dS5UW02iZ52aJDzMNvslrQBdYmR3KmKdBo3k Fx2q54UX+MUTBudBf6QEtUT5fdzGcU+D4+Sne7D9aTOv/LqF9vnwn3b0B4lzdq0M1U9W m4N9QQnVW0OW/+44qjHmhFPvVtEZrTTh9K+CGQKtuSYDzyRzTVATxTRy/9Q9ZbHyKEhL tISBa/3zLLcNAEsuvJ7UT21EsNXzuOD7MNM1yPLS8VHIdMZEBdrQ3GxN1/cKaZHJyrzJ 1l+gL7rI3JTRqWuJgcP4bxoU58ABwWzilXH89+ZzmuW0joYsuh/1fpzFfW5E9VYH4Lq9 kO8A== X-Received: by 10.15.32.142 with SMTP id a14mr655810eev.152.1369416919776; Fri, 24 May 2013 10:35:19 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-177-109-125.red.bezeqint.net. [79.177.109.125]) by mx.google.com with ESMTPSA id bn53sm25044207eeb.7.2013.05.24.10.35.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 10:35:19 -0700 (PDT) Message-ID: <519FA4D3.6000306@gmail.com> Date: Fri, 24 May 2013 20:35:15 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> <519F2EBD.1030408@cs.tcd.ie> <20895.23252.179339.686278@fireball.kivinen.iki.fi> <519F5D63.4000206@cs.tcd.ie> <519F7486.9030002@gmail.com> <67FEC0F2-9C17-4CCA-B41C-85FCB40E59E7@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "secdir@ietf.org" , Jari Arkko Subject: Re: [secdir] timing of reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 17:35:21 -0000 > >> But back to substance. There are obvious situations where WGLC is done on a document that is far from ready. It comes as a surprise, or the WG chairs are doing it on purpose to solicit reviews that do not appear to be forthcoming otherwise. While early help with half-finished documents can be useful, I don't think we should waste secdir, Gen-ART, etc. reviewer's time on it at that point. When we talked about this in the IESG, it was brought up that the WG chairs should be involved in the decision to call for review. I agree with that. There are details to think about, however. Perhaps we can request review only for docs that the chairs believe are well baked, and use the old process for others, for instance. > > Maybe. But I also think that if the WG chair knows that the WG is going to get all their out-of-area reviews when they press the "WG LC" button, they might do a "pre-LC" call for more reviewers. This is a topic that Yaron and I are actively working on in our less-than-active WG. > > A possibility for what you want is a new state or sub-state of "outside reviews requested" that the WG chair can put in the tracker. I bet this means that most chairs will forget to do this and Tero won't hear about most documents until they are in IETF LC, so I'm hesitant to propose this. > And where's the harm? If the WG wants to speed up a particular document, AND they feel it is ready for external review, they will "push the button". Otherwise, why not have the secdir review during IETF LC? Thanks, Yaron From doug.mtview@gmail.com Fri May 24 14:58:51 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40211E8135; Fri, 24 May 2013 14:58:51 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO31-p-VRbmZ; Fri, 24 May 2013 14:58:49 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id DF52111E8129; Fri, 24 May 2013 14:58:48 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so3444618vbb.37 for ; Fri, 24 May 2013 14:58:48 -0700 (PDT) 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:x-mailer; bh=3ZEWRgm+QVx2MsfeAOqSpzIxGr+1z0MsN3NaUd0obfA=; b=OKCvvhdjFdlhspwaybk+nabfUMjruiOLs9ZrChrE8lmZxB6F7hFD93hQPoStaYLD/P KFhNxEqvwSy8bJ9MOffTqnKud38OxWAREt/4X9Fb1NOrAChwxXsZvxIvslz1Ae+oCztt zbtavbXWQw76JGNidZSHe3pZLohO1I2fQ67AxKF67vhIIyGwKZEAPpciLlLFAuERzCnU 5uLzPz8qSItpFpOFndDy35x3C9z82ZVxX+C4p/KzN/0n3QIrFtW6ed71sWsYUWTbft8V 7q/5WQZA3BjbHf5UvJzO+z9qzcjldci57VLd3wMGWVKrNo98iQr+kZyo28UNgZy4HkG4 763g== X-Received: by 10.52.38.161 with SMTP id h1mr8396588vdk.30.1369432728283; Fri, 24 May 2013 14:58:48 -0700 (PDT) Received: from [192.168.0.99] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id s14sm10495374vdg.6.2013.05.24.14.58.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 14:58:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com> Date: Fri, 24 May 2013 14:58:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.com> <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] [spfbis] draft-ietf-spfbis-4408bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 21:58:51 -0000 On May 23, 2013, at 12:14 PM, S Moonesamy wrote: > Hi Doug, > At 11:58 23-05-2013, Douglas Otis wrote: >> Greater clarity would have been achieved by separating transactions = involving the SPF checkhost process (spfch-transactions) which may then = generate some number of recursive dns server transactions = (rdns-transactions). >>=20 >> A transaction made at the spfch level will result in some number of = transactions at the rdns level, which could then be described as = representing some number of separate DNS queries. >>=20 >> Confusion has been caused by conflating checkhost and recursive DNS = transactions with that of non-recursive DNS which may involve dozens of = unique queries to resolve any particular resource. This is bad and is a = continuing source of confusion. >=20 > What I noted among other things in the review was "the only quibble" = and "it is reasonably clear". >=20 >> A practical means to simplify SPF's impact on a receiver's DNS is to = first ignore SPF records containing macro expressions. This happens and = this may explain the nearly 100% lack of macro use. They then limit the = number of SPF resource records and MX mechanisms and ignore the PTR = mechanism. Appreciate what receivers consider a reasonable demand on = their resources that offers cache-able results. >=20 > I don't see any relation between the security directorate review ( = http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html ) to = the above (quoted paragraph). If the security directorate reviewer is = of the opinion that it is related to his review I will ask the SPFBIS to = comment about the matter. Dear SM, SPFbis terminology conflates similar terms used in both recursive DNS = and the pseudo check_host service indirectly defined in the SPFbis = document. In addition, there appears to be a significant departure in = processing of the EHLO domain in lieu of the RFC5321.MAILFROM. SPFbis = section 2.1states "If a conclusive determination about the message can = be made based on a check of HELO, then the use of DNS resources to = process the typically more complex MAIL FROM can be avoided."=20 This approach is at odds with a process proposed by = draft-kucherawy-dmarc-base, section 4.3 "For example, [DKIM] = authenticates the domain that affixed a signature to the message, while = [SPF] authenticates either the domain that appears in then = RFC5321.Mail=46rom portion of [SMTP] or the RFC5321.EHLO/HELO domain if = the RFC5321.Mail=46rom is null (in the case of Delivery Status = Notifications). Draft-kucherawy-dmarc-base already requires reprocessing message header = stacks to exclude ONLY repeated =46rom header fields. It also suggests = EHLO will be ignored and the RFC5321.Mail=46rom will still need to be = processed. This potentially doubles the load on DNS and offers poor = protocol layering. If directed toward synthetic domains used to replace = web cookies, the application of the new DNS Response Rate Limiting may = prove problematic, in addition to an attack easily occurring from a = myriad clients easily beyond prefix limits used to associate responses. = Although related to offering security, it seems highly improbable SPF = can safely make use of DNSsec.=20 It should also be noted that RFC6531 introduces character sets not = handled by SPFbis since this also includes local-part components which = may invoke handling errors since this introduces data not converted by = RFC5890. It should also be noted that use of macros still allows = left-hand labels to take the place of randomized local-parts to leverage = cached records while inducing different queries. The only way SPFbis can be made reasonably safe would be to disable = implementation of the macro functions by the receiver. Since these = macros are rarely used, this change would not impact the exchange of = email. Even now, senders making use of macros will see a greater = impact with their SPF records being ignored as things currently stand. Regards, Douglas Otis From cabo@tzi.org Mon May 27 23:58:52 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D3221F8511; Mon, 27 May 2013 23:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmfzcscmUGQu; Mon, 27 May 2013 23:58:46 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6269421F9007; Mon, 27 May 2013 23:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4S6wc9i018073; Tue, 28 May 2013 08:58:38 +0200 (CEST) Received: from [192.168.217.105] (p54894213.dip0.t-ipconnect.de [84.137.66.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5E90334A4; Tue, 28 May 2013 08:58:38 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 28 May 2013 08:58:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3CD078EF-9CBB-4C19-A5F6-DFC21C522EAA@tzi.org> References: To: Ben Laurie X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-lwig-terminology.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Security directorate review of draft-ietf-lwig-terminology-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 06:58:52 -0000 On May 23, 2013, at 13:48, Ben Laurie wrote: > I would > suggest that this section could usefully contain a summary of the > security implications of the various constraints discussed. Ben, thanks for reminding us. Interestingly, I just put in something like this as a new subsection = 11.6 in draft-ietf-core-coap-17, which I have reproduced below. That = section is focused on three specific considerations. I would expect security considerations to be more actionable when = discussed in the context of a specific protocol, as opposed to the = terminology that is used for describing the constraints. Doing a more extensive discussion of security implications of = constrainedness would be a great document on its own, which maybe we = should start looking into in the LWIG WG. There is also an activity to = work on using DTLS properly in constrained environments, which would = also benefit from such a document. So I'm not sure how much we should be putting in the terminology = document, but the WG will certainly need to discuss this. I'm opening a = ticket for now. Gr=FC=DFe, Carsten 11.6. Constrained node considerations Implementers on constrained nodes often find themselves without a good source of entropy [RFC4086]. If that is the case, the node MUST NOT be used for processes that require good entropy, such as key generation. Instead, keys should be generated externally and added to the device during manufacturing or commissioning. Due to their low processing power, constrained nodes are particularly susceptible to timing attacks. Special care must be taken in implementation of cryptographic primitives. Large numbers of constrained nodes will be installed in exposed environments and will have little resistance to tampering, including recovery of keying materials. This needs to be considered when defining the scope of credentials assigned to them. In particular, assigning a shared key to a group of nodes may make any single constrained node a target for subverting the entire group. From n@arifumi.net Mon May 27 23:25:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2551821F93EF for ; Mon, 27 May 2013 23:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSL++-nselZr for ; Mon, 27 May 2013 23:25:02 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CDBAA21F8EA4 for ; Mon, 27 May 2013 23:25:01 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr4so7500101pbb.34 for ; Mon, 27 May 2013 23:25:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=vEd8DMgsTJRP7HOdjv+Z4AG6Wpp+uCco+kpgO608wXU=; b=d/79EgBJ0nkxO0NkVc+ORouKYy7iq99wGN5ebFD2roGP/cDiNh3EKS+1iHmixDARoj bDTIt0QfmhLLU/9+oYOPaZOO358bV9Haf/7Z56/0dSJJihWixgGp6h+zTLhsKh5SM+FN 9Zj4x4CSBYxHgNM60eOLn5H/WSk03lZGDqHBH+ivirjhg1TzCSILbd1mvkuzlgFbcD7W Dv2lccbU1t4JeRNK0xMCMXLscjpD3BaKWflj1QNaX//zRGq7CBoHXqVvFmf2Ru4wcogF BRyjdq4KyiYycCTW9jBfYItLTTDJxJISS+FZuxrjH8wbsrnnTCwPa2QYHcc8rlUK5uBu rmSg== MIME-Version: 1.0 X-Received: by 10.68.239.228 with SMTP id vv4mr32318806pbc.5.1369722301493; Mon, 27 May 2013 23:25:01 -0700 (PDT) Sender: n@arifumi.net Received: by 10.68.194.198 with HTTP; Mon, 27 May 2013 23:25:01 -0700 (PDT) X-Originating-IP: [2001:fa8:1010:0:640a:ca01:b6eb:b09d] In-Reply-To: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> References: <3dc2e7cf8e11e1928d71c08895be5c68.squirrel@www.trepanning.net> Date: Tue, 28 May 2013 15:25:01 +0900 X-Google-Sender-Auth: 0HAUsZLL9W8vKYFh1nkKYQIFAn0 Message-ID: From: Arifumi Matsumoto To: Dan Harkins Content-Type: multipart/alternative; boundary=047d7b33901738c64404ddc153cb X-Gm-Message-State: ALoCoQl1NDUVE2bpRW4e+bYhPpm3avXj7QWfKI/Mo+x5351j/ZPqNu4cuLPkakDdxf3xFXz5wNVj X-Mailman-Approved-At: Tue, 28 May 2013 01:27:42 -0700 Cc: "draft-ietf-6man-addr-select-opt.all@tools.ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-6man-addr-select-opt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 06:25:03 -0000 --047d7b33901738c64404ddc153cb Content-Type: text/plain; charset=ISO-8859-1 Hi Dan, I appreciate your review. Comments below. 2013/5/22 Dan Harkins > > Hello, > > I have reviewed draft-ietf-6man-addr-select-opt as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily > for the benefit of the security area directors. Document editors and > WG chairs should treat these comments just like any other last call > comments. > > draft-ietf-6man-addr-select-opt defines address selection options > for DHCPv6 that allow a network administrator to effect some > control over address selection behavior of nodes on their sites. > > This sounds like a reasonably straightforward problem but as I > read the draft it seemed like it might be have interoperability issues. > I don't believe this draft is ready for advancement until these issues > are resolved. > > For instance, while I think I understand the policy override of RFC > 6724, having the Automatic Row Additions Flag be part of the address > selection options seems problematic. If it is set to zero, then what are > the semantics of such a message? "Here's an address selection option > but don't you dare use it!"? What is the point? Me, as a node, can have > this as part of my policy state which would allow me to ignore such > an update but to have the bit be part of the option to update does > not seem to make much sense. The semantics of the message needs > to be explained much more clearly, or the bit needs to be removed > from the message. > If A flag is zero, it means Automatic Row Addition is indicated not to perform. If A flag is 1, it means it is up to the node. Even in the latter case, the Address Selection Option may contain other information to the node, such as the policy table and other flags. Make sense ? If not, splitting the flag into another new sub-option makes sense to you ? > > Section 3.3 says, "Even if the received policy from one source is > merged with one from another source, the effect of both policy are > more or less changed." I don't understand how both policies are > changed. And what does "more or less" mean? I think that a policy table has its own unique meaning. Even single insertion/deletion from the table makes the table different. For example, when adding a line, from one source, to the default policy table below, Prefix Precedence Label ::1/128 50 0 ::/0 40 1 ::ffff:0:0/96 35 4 2002::/16 30 2 2001::/32 5 5 fc00::/7 3 13 ::/96 1 3 fec0::/10 1 11 3ffe::/16 1 12 makes Prefix Precedence Label ::1/128 50 0 ::/0 40 1 ::ffff:0:0/96 35 4 2002::/16 30 2 + 2003::/16 10 6 2001::/32 5 5 fc00::/7 3 13 ::/96 1 3 fec0::/10 1 11 3ffe::/16 1 12 In this case, the prefix 2003::/16 has lower precendence than the default policy table. And, the table contains a lot of policy that is not intended by the source who deliver single line of policy. > 3.3 also says, > "It also should be noted that absence of the distributed policy from a > certain network interface should not be treated as absence of policy > itself, because it may mean preference for the default address > selection policy." So I use the default address selection policy then, > is that it? I mean, there is no way to tell the network with no policy distribution prefers default policy, or does not care about it. The conclusion is "using the default policy should be safe", though. > This whole section (3.3) screams out for some normative > language since it sounds like it refers to behavioral changes on the > node. > Do you mean this section should have more SHOULDs and MUSTs ? If so, on which part do you think should we put ? > > There is an "Implementation Consideration" mentioning that the > label is passed as an unsigned integer. But it then goes on to say, > "DHCPv6 clients SHOULD convert this label to a representation > appropriate for the local implementation (e.g., string)." This has > interoperability implications because it is not solely a local matter. > The node may represent these things differently than the network > administrator and the preference will not be done properly. RFC 6724 > does not really define what the label is from what I can tell. It's > used to just allow for policies to prefer a particular source address, > S, with a particular destination address, D, if "Label(S) = Label(D)". > But to pass a value over a network, and have it be used by the > recipient, means that a canonical representation of "label" has to > be defined. > Maybe, I don't understand your point quite well. As far as the one-to-one mapping in a node is performed between an unsinged integer and representation format, I think there will not arise interoperability issue, such that a policy has different meaning depending on a receiving host. > An appendix with examples would be most helpful! > RFC 6724 has a lot of examples for policy table. Do you think we need other examples, or just same ones ? > > Spelling nit: section 3.1 "The choice a SHOULD be default, as far as > the policy table is not configured by the user." There's an extra > word in there somewhere, or maybe there's some words missing, > it's hard to understand what is being implied. > It means the choice called "a" below should be default. Maybe using parenthesis (a) makes it clearer ? Best regards, > > regards, > > Dan. > > > --047d7b33901738c64404ddc153cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dan,
I appreciate your review.

Comments below.

2013/5/22 Dan Harkins <dharkins@lounge.org>

=A0 Hello,

=A0 I have reviewed draft-ietf-6man-addr-select-opt as part of the
security directorate's =A0ongoing effort to review all IETF documents being processed by the IESG. =A0These comments were written primarily
for the benefit of the =A0security area directors. =A0Document editors and<= br> WG chairs should treat these comments just like any other last call
comments.

=A0 draft-ietf-6man-addr-select-opt defines address selection options
for DHCPv6 that allow a network administrator to effect some
control over address selection behavior of nodes on their sites.

=A0 This sounds like a reasonably straightforward problem but as I
read the draft it seemed like it might be have interoperability issues.
I don't believe this draft is ready for advancement until these issues<= br> are resolved.

=A0 For instance, while I think I understand the policy override of RFC
6724, having the Automatic Row Additions Flag be part of the address
selection options seems problematic. If it is set to zero, then what are the semantics of such a message? "Here's an address selection opti= on
but don't you dare use it!"? What is the point? Me, as a node, can= have
this as part of my policy state which would allow me to ignore such
an update but to have the bit be part of the option to update does
not seem to make much sense. The semantics of the message needs
to be explained much more clearly, or the bit needs to be removed
from the message.

If A flag is zero, it= means Automatic Row Addition is indicated not to perform.
If= A flag is 1, it means it is up to the node.

Even in the = latter case, the Address Selection Option may contain other
information to the node, such as the policy table and other flag= s.

Make sense ?

If not, spli= tting the flag into another new sub-option makes sense to you ?
=A0

=A0 Section 3.3 says, "Even if the received policy from one source is<= br> merged with one from another source, the effect of both policy are
more or less changed." I don't understand how both policies are changed. And what does "more or less" mean?
I think that a policy table has its own unique meaning. Even single<= br>
insertion/deletion from the table makes= the table different.

For example, when adding a line, from one source, to the def= ault policy table below,

      Prefix        Precede=
nce Label
      ::1/128               50     0
      ::/0                  40     1
      ::ffff:0:0/96         35     4
      2002::/16             30     2
      2001::/32              5     5
      fc00::/7               3    13
      ::/96                  1     3
      fec0::/10              1    11
      3ffe::/16              1    12
makes
      Pr=
efix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      ::ffff:0:0/96         35     4
      2002::/16             30     2
+     2003::/16             10    6=

     =A02001::/32              5     5
      fc00::/7               3    13
      ::/96                  1     3
      fec0::/10              1    11
      3ffe::/16              1    12
In this case, the prefix 2003::/1= 6 has lower precendence than the default
policy table. And, the table co= ntains a lot of policy that is not intended by
the source who deliver si= ngle line of policy.

=A0
3.3 also says,
"It also should be noted that absence of the distributed policy from a=
certain network interface should not be treated as absence of policy
itself, because it may mean preference for the default address
selection policy." So I use the default address selection policy then,=
is that it?

I mean, there is no way to tel= l the network with no policy distribution
prefers default pol= icy, or does not care about it.
The conclusion is "using= the default policy should be safe", though.
=A0
This = whole section (3.3) screams out for some normative
language since it sounds like it refers to behavioral changes on the
node.

Do you mean this section should h= ave more SHOULDs and MUSTs ?
If so, on which part do you thin= k should we put ?
=A0

=A0 There is an "Implementation Consideration" mentioning that th= e
label is passed as an unsigned integer. But it then goes on to say,
"DHCPv6 clients SHOULD convert this label to a representation
appropriate for the local implementation (e.g., string)." This has
interoperability implications because it is not solely a local matter.
The node may represent these things differently than the network
administrator and the preference will not be done properly. RFC 6724
does not really define what the label is from what I can tell. It's
used to just allow for policies to prefer a particular source address,
S, with a particular destination address, D, if "Label(S) =3D Label(D)= ".
But to pass a value over a network, and have it be used by the
recipient, means that a canonical representation of "label" has t= o
be defined.

Maybe, I don't understa= nd your point quite well.
As far as the one-to-one mapping in= a node is performed between an
unsinged integer and representation form= at, I think there will not arise
interoperability issue, such that a policy has different meaning= depending
on a receiving host.
=A0
=A0 An appendix with examples would be most helpful!
<= br>
RFC 6724 has a lot of examples for policy table.
Do you think we need other examples, or just same ones ?
=A0

=A0 Spelling nit: section 3.1 "The choice a SHOULD be default, as far = as
the policy table is not configured by the user." There's an extra<= br> word in there somewhere, or maybe there's some words missing,
it's hard to understand what is being implied.
It means the choice called "a" below should be defaul= t.
Maybe using parenthesis (a) makes it clearer ?

Best regards,
=A0

=A0 regards,

=A0 Dan.



--047d7b33901738c64404ddc153cb-- From benl@google.com Tue May 28 01:47:47 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D241821F93A3 for ; Tue, 28 May 2013 01:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3375QFDHboHk for ; Tue, 28 May 2013 01:47:47 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB3C21F93D2 for ; Tue, 28 May 2013 01:47:47 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so929389iea.32 for ; Tue, 28 May 2013 01:47:46 -0700 (PDT) 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 :cc:content-type:content-transfer-encoding; bh=eFQhLE9mUe3DvgcDCvu03+vUG5LVSRE9EedDuuYKd78=; b=WsjKVG/nqFj4anbrJ0f2lyPV1Mhpv1WxKJSwI768NjiMhUCijstO5iGMYyK14Vw8My s12duJs0DvThE/Tim1EjqfEmjX/naxiVK+ESjn8ul4vC6rMFq1PCYSqitVD3Rp9n0L7Y xP20jAs3PYttV6Vo2BtBENxIt69Ki0y2ycubPwBXbPDZtCVGlmg3xkB8BbkuswIKdWX+ ML4dacsuNb/5sqvyr4bPcHnbcVCkHYgs6Oy6q6Oq5OytVTUdV6dTfZucCTEFIkdmOys+ OSqjdS0H8rgZ6KV9fL65FJaCItTeXm1EZ9K+7kRpV15H5B1RVpX2BFaRKfKTI02+RD9D W3YQ== X-Google-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 :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=eFQhLE9mUe3DvgcDCvu03+vUG5LVSRE9EedDuuYKd78=; b=EzSrFuQ2AK0YOmoyXC5zGfpLUPz1K8YDnSIrTRHLovtXNKkdy1d1lyaLBjelzt2EZC tkLgk7IRPd0mloAl/6mWjO8rlmqW8SfK6ZLcd3F6IQ86avoThF5ljnkCd3ZJlDONswp1 noJCSoxFf5pP/sO1gtXqBNNA5J0AQKzhzIjXyh3wmBA5DGZOEM0pHM+l5GMYjJDBUlTf SM5un1h2xXvsM2IYakVUOopCDPhR+Z8oAzugnVCweZc7W1OVndE/5/c7ddfKMgHoZbKC fgR6SMAw1+39ThpSJ3rfKK3rpOEF6DUonC2i1LBhXcr2XUsSwh2UlFSvtFj0puf+oX94 C5SQ== MIME-Version: 1.0 X-Received: by 10.50.85.101 with SMTP id g5mr6425002igz.26.1369730865770; Tue, 28 May 2013 01:47:45 -0700 (PDT) Received: by 10.64.230.232 with HTTP; Tue, 28 May 2013 01:47:45 -0700 (PDT) In-Reply-To: <3CD078EF-9CBB-4C19-A5F6-DFC21C522EAA@tzi.org> References: <3CD078EF-9CBB-4C19-A5F6-DFC21C522EAA@tzi.org> Date: Tue, 28 May 2013 09:47:45 +0100 Message-ID: From: Ben Laurie To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnDAWmufZHxA7JlHBXmQn6ZI5zDSPu+YB6pqCJoNsDzxAHMAeyZCwa6hmiiqPeP9UK+/udk+5sZKIwhoYCg9VyPgw/k7/YZy7t6nuVfhpcD7YjFdbhCYYi1q3IKI/APrnl14bE9oV/itwVxHHQLJwDdtN24RbsrXVjVn+MPKCFmO17tbi9Q7oiRqZdpOgUxaOh6Kdjt Cc: draft-ietf-lwig-terminology.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Security directorate review of draft-ietf-lwig-terminology-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 08:47:48 -0000 On 28 May 2013 07:58, Carsten Bormann wrote: > On May 23, 2013, at 13:48, Ben Laurie wrote: > >> I would >> suggest that this section could usefully contain a summary of the >> security implications of the various constraints discussed. > > Ben, > > thanks for reminding us. > > Interestingly, I just put in something like this as a new subsection 11.6= in draft-ietf-core-coap-17, which I have reproduced below. That section is= focused on three specific considerations. > > I would expect security considerations to be more actionable when discuss= ed in the context of a specific protocol, as opposed to the terminology tha= t is used for describing the constraints. > > Doing a more extensive discussion of security implications of constrained= ness would be a great document on its own, which maybe we should start look= ing into in the LWIG WG. There is also an activity to work on using DTLS p= roperly in constrained environments, which would also benefit from such a d= ocument. Sounds like a great idea (and see below). > So I'm not sure how much we should be putting in the terminology document= , but the WG will certainly need to discuss this. I'm opening a ticket for= now. I made the observation because there are various statements about security spread throughout the document, so clearly it is a matter already on your minds, for example: " Class 0 devices are very constrained sensor-like motes. Most likely they will not be able to communicate directly with the Internet in a secure manner." > > Gr=FC=DFe, Carsten > > > > 11.6. Constrained node considerations > > Implementers on constrained nodes often find themselves without a > good source of entropy [RFC4086]. If that is the case, the node MUST > NOT be used for processes that require good entropy, such as key > generation. Instead, keys should be generated externally and added > to the device during manufacturing or commissioning. As it happens, I'm a FreeBSD developer and in the wake of the recent low entropy attacks we had quite some discussion about constrained nodes ... one thing we thought would be of great benefit was, rather than create keys during manufacturing, add entropy - i.e. include a block of randomness in the ROM (or whatever) that's unique per device. Assuming the device itself is not physically attacked, even quite a small amount (say 256 bits) would be sufficient for the lifetime of the device, particularly when mixed with what little is available from the environment. Note that it is important to mix in a counter of some kind so the entropy is not re-used unmodified. > Due to their low processing power, constrained nodes are particularly > susceptible to timing attacks. Special care must be taken in > implementation of cryptographic primitives. > > Large numbers of constrained nodes will be installed in exposed > environments and will have little resistance to tampering, including > recovery of keying materials. This needs to be considered when > defining the scope of credentials assigned to them. In particular, > assigning a shared key to a group of nodes may make any single > constrained node a target for subverting the entire group. This is another reason per-device entropy is useful (clearly nothing can defend against any particular device that's been tampered with - for starters, it could easily be replaced with a malicious version). From sra@hactrn.net Wed May 29 09:31:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B20021F8CA5; Wed, 29 May 2013 09:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PalgTFkFe4gi; Wed, 29 May 2013 09:31:01 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id F190821F9298; Wed, 29 May 2013 09:30:52 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 3E45A9B42A; Wed, 29 May 2013 16:30:49 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 084F517058; Wed, 29 May 2013 12:30:49 -0400 (EDT) Date: Wed, 29 May 2013 12:30:49 -0400 From: Rob Austein To: iesg@ietf.org, draft-ietf-softwire-public-4over6.all@tools.ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20130529163049.084F517058@thrintun.hactrn.net> Cc: secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-softwire-public-4over6-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 16:31:02 -0000 I have reviewed draft-ietf-softwire-public-4over6-09 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. Given that this is an informational draft documenting existing practice, I have no serious security concerns with the draft. FWIW, I agree with the issue Sean Turner already raised in his discuss, not that Sean needs my approval. If the draft gets another spin, the security considerations could benefit from a bit more text making it clear that the proposed use of IPv6 address filtering is in the context of the constrained environment of a single ISP, where such filtering is based on the ISP's knowledge of its own topology and address allocation scheme. One can sort of read this between the lines anyway, but it would be better to make it explicit. From sra@hactrn.net Wed May 29 10:11:34 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E1821F965C; Wed, 29 May 2013 10:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+jreRyHhxJi; Wed, 29 May 2013 10:11:29 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE9321F85EB; Wed, 29 May 2013 10:11:14 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [10.0.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 364619B428; Wed, 29 May 2013 17:11:12 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 08F0217058; Wed, 29 May 2013 13:11:12 -0400 (EDT) Date: Wed, 29 May 2013 13:11:12 -0400 From: Rob Austein To: iesg@ietf.org, draft-arkko-iesg-crossarea.all@tools.ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20130529171112.08F0217058@thrintun.hactrn.net> Cc: secdir@ietf.org Subject: [secdir] secdir review of draft-arkko-iesg-crossarea-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:11:34 -0000 I have reviewed draft-ietf-softwire-public-4over6-09 as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Draft is an opinion piece by a private member of the community who happens to wear several other hats. No protocol content. Other than a pro forma note that the draft contains no security considerations section, I have no security considerations per se with this document. The one observation I will make is that, having now been a participant in two serious cross-area efforts (probably more than that, but the two I'm thinking of are DNSSEC and SIDR), I have noticed that there does not appear to be any way of hurrying up the process of growing experts in a complex new topic. That is: when we started DNSSEC, we had security people and we had DNS people, the two groups were almost completely talking past each other, and the ops people were only sort of in the room. It took years to get to the point where we had people who really understood both topics, and longer to get ops to care. Jury is still out on SIDR, but it sure feels like the same curve. If there's any way to speed the process, I don't know what it is; attempts to force the pace seem more likely to result in messes that require yet another return to the drawing board. From sra@hactrn.net Wed May 29 10:22:33 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F9921F8E1C; Wed, 29 May 2013 10:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phqc9FBy5+tD; Wed, 29 May 2013 10:22:32 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id C41DE21F8F28; Wed, 29 May 2013 10:22:31 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [10.0.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 107919B428; Wed, 29 May 2013 17:22:29 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 9D23A17058; Wed, 29 May 2013 13:22:29 -0400 (EDT) Date: Wed, 29 May 2013 13:22:29 -0400 From: Rob Austein To: iesg@ietf.org, draft-arkko-iesg-crossarea.all@tools.ietf.org In-Reply-To: <20130529171112.08F0217058@thrintun.hactrn.net> References: <20130529171112.08F0217058@thrintun.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20130529172229.9D23A17058@thrintun.hactrn.net> Cc: secdir@ietf.org Subject: Re: [secdir] secdir review of draft-arkko-iesg-crossarea-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:22:33 -0000 At Wed, 29 May 2013 13:11:12 -0400, Rob Austein wrote: > > I have reviewed draft-ietf-softwire-public-4over6-09 Message-ID <20130529171112.08F0217058@thrintun.hactrn.net> was about draft-arkko-iesg-crossarea, not draft-ietf-softwire-public-4over6. Cut and paste error in secdir review boilerplate. Sigh. Sorry for any confusion. From kivinen@iki.fi Thu May 30 02:31:09 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF31421F979D for ; Thu, 30 May 2013 02:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBdREGX9vhxy for ; Thu, 30 May 2013 02:31:09 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id F293321F901F for ; Thu, 30 May 2013 02:31:08 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r4U9V588027819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 May 2013 12:31:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r4U9V5lt014865; Thu, 30 May 2013 12:31:05 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20903.7257.636468.530994@fireball.kivinen.iki.fi> Date: Thu, 30 May 2013 12:31:05 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 09:31:09 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Ondrej Sury is next in the rotation. For telechat 2013-05-30 Reviewer LC end Draft Rob Austein T 2013-05-06 draft-ietf-bmwg-imix-genome-04 Ondrej Sury T 2013-04-23 draft-ietf-manet-olsrv2-mib-09 Last calls and special requests: Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-05-06 draft-ietf-geopriv-held-measurements-07 David Harrington 2013-05-09 draft-ietf-6man-impatient-nud-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Scott Kelly 2013-05-29 draft-ietf-cuss-sip-uui-10 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-10 Julien Laganier - draft-ietf-avtcore-rtp-security-options-03 Matt Lepinski 2013-06-06 draft-ietf-manet-nhdp-sec-threats-03 Chris Lonvick 2013-06-04 draft-ietf-mmusic-rfc2326bis-34 Catherine Meadows 2013-06-04 draft-ietf-mmusic-sdp-miscellaneous-caps-05 Alexey Melnikov - draft-ietf-payload-rtp-howto-03 Kathleen Moriarty 2013-06-03 draft-ietf-xrblock-rtcp-xr-discard-14 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Russ Mundy 2013-03-30 draft-ietf-roll-terminology-12 Russ Mundy 2013-05-31 draft-ietf-xrblock-rtcp-xr-jb-11 Sandy Murphy 2013-06-17 draft-jabley-dnsext-eui48-eui64-rrtypes-04 Magnus Nystrom 2013-06-11 draft-ietf-avtcore-6222bis-03 Hilarie Orman 2013-06-25 draft-thornburgh-adobe-rtmfp-07 Radia Perlman 2013-06-11 draft-ietf-avtcore-avp-codecs-02 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 Vincent Roca 2013-06-11 draft-ietf-avtcore-idms-09 Joe Salowey 2013-06-06 draft-ietf-l3vpn-virtual-hub-06 Yaron Sheffer 2013-06-07 draft-ietf-pce-gmpls-aps-req-07 David Waltermire 2013-05-14 draft-housley-rfc2050bis-01 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-08 Nico Williams - draft-ietf-httpbis-p5-range-22 -- kivinen@iki.fi From hallam@gmail.com Thu May 30 13:00:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285F721F9273; Thu, 30 May 2013 13:00:44 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fOgwDXBvjwQ; Thu, 30 May 2013 13:00:43 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9026221F9354; Thu, 30 May 2013 13:00:41 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hn14so56458wib.14 for ; Thu, 30 May 2013 13:00:40 -0700 (PDT) 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=aSF2ZcxNSEk8B6AEsM9NOfE/qPv9AH94fljFEeidwSM=; b=eFyS0wE3TXYdzhybVIdyJTK3obyfpIlfzY1H/xW0VDFlMinWb/rXl+GqXoMgj2TSou wurHhlMuOdz1S9JR9wG3S1GzS8upOieJymwNLBfsDfNegG/7CFU/9EUOiSQ1Umw2U8VW dNCPCwqnxaeFzIn+MbmMONj24rrZ0iUQakWkxERUci8ZWdmKy+k81e4k/9ThCW48wcJ1 JH9QkhRfHVWqKy0EbhsSlBpouDOfUrzNbtRkqblvqi2gPQoInMot26BfeiBv6fKDgCpy zIBCHM5e85zG//nzH+im/syuwyyplAC5UXO4vTqE8zCWGRv5Gtyl1VkgC3VBSZ4INNhv C76w== MIME-Version: 1.0 X-Received: by 10.194.172.66 with SMTP id ba2mr6394781wjc.22.1369944040627; Thu, 30 May 2013 13:00:40 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Thu, 30 May 2013 13:00:40 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com> References: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.com> <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com> Date: Thu, 30 May 2013 16:00:40 -0400 Message-ID: From: Phillip Hallam-Baker To: S Moonesamy Content-Type: multipart/alternative; boundary=089e01184dd4e766c804ddf4f3c1 Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, "secdir@ietf.org" , Douglas Otis , "iesg@ietf.org" Subject: Re: [secdir] [spfbis] draft-ietf-spfbis-4408bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 20:00:44 -0000 --089e01184dd4e766c804ddf4f3c1 Content-Type: text/plain; charset=ISO-8859-1 My point was a quibble, no more. The intent was clear enough to me and it is hard to imagine an implementer of code making a blunder if their code is timing out too often on real records they will raise their limits. A person writing records might however. I can see that attempting to clarify this point might add more confusion as John Levine pointed out. In fact that was the main concern I had with the document as a whole. I think it is done as well as it is going to be at this point. On Thu, May 23, 2013 at 3:14 PM, S Moonesamy wrote: > Hi Doug, > > At 11:58 23-05-2013, Douglas Otis wrote: > >> Greater clarity would have been achieved by separating transactions >> involving the SPF checkhost process (spfch-transactions) which may then >> generate some number of recursive dns server transactions >> (rdns-transactions). >> >> A transaction made at the spfch level will result in some number of >> transactions at the rdns level, which could then be described as >> representing some number of separate DNS queries. >> >> Confusion has been caused by conflating checkhost and recursive DNS >> transactions with that of non-recursive DNS which may involve dozens of >> unique queries to resolve any particular resource. This is bad and is a >> continuing source of confusion. >> > > What I noted among other things in the review was "the only quibble" and > "it is reasonably clear". > > > A practical means to simplify SPF's impact on a receiver's DNS is to >> first ignore SPF records containing macro expressions. This happens and >> this may explain the nearly 100% lack of macro use. They then limit the >> number of SPF resource records and MX mechanisms and ignore the PTR >> mechanism. Appreciate what receivers consider a reasonable demand on their >> resources that offers cache-able results. >> > > I don't see any relation between the security directorate review ( > http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03679.html) to the above (quoted paragraph). If the security directorate reviewer is > of the opinion that it is related to his review I will ask the SPFBIS to > comment about the matter. > > > Regards, > S. Moonesamy (as document shepherd) > -- Website: http://hallambaker.com/ --089e01184dd4e766c804ddf4f3c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My point was a quibble, no more. The intent was clear enou= gh to me and it is hard to imagine an implementer of code making a blunder = if their code is timing out too often on real records they will raise their= limits. A person writing records might however.

I can see that attempting to clarify this point might = add more confusion as John Levine pointed out. In fact that was the main co= ncern I had with the document as a whole. I think it is done as well as it = is going to be at this point.


On Thu,= May 23, 2013 at 3:14 PM, S Moonesamy <sm+ietf@elandsys.com> wrote:
Hi Doug,

At 11:58 23-05-2013, Douglas Otis wrote:
Greater clarity would have been achieved by separating transactions involvi= ng the SPF checkhost process (spfch-transactions) which may then generate s= ome number of recursive dns server transactions (rdns-transactions).

A transaction made at the spfch level will result in some number of transac= tions at the rdns level, which could then be described as representing some= number of separate DNS queries.

Confusion has been caused by conflating checkhost and recursive DNS transac= tions with that of non-recursive DNS which may involve dozens of unique que= ries to resolve any particular resource. =A0This is bad and is a continuing= source of confusion.

What I noted among other things in the review was "the only quibble&qu= ot; and "it is reasonably clear".


A practical means to simplify SPF's impact on a receiver's DNS is t= o first ignore SPF records containing macro expressions. =A0This happens an= d this may explain the nearly 100% lack of macro use. =A0They then limit th= e number of SPF resource records and MX mechanisms and ignore the PTR mecha= nism. =A0Appreciate what receivers consider a reasonable demand on their re= sources that offers cache-able results.

I don't see any relation between the security directorate review ( http://www.ietf.org/mail-archive/web/spfbis/current= /msg03679.html ) to the above (quoted paragraph). =A0If the secu= rity directorate reviewer is of the opinion that it is related to his revie= w I will ask the SPFBIS to comment about the matter.


Regards,
S. Moonesamy (as document shepherd)



--
= Website: http://hallambaker.com/
--089e01184dd4e766c804ddf4f3c1-- From catherine.meadows@nrl.navy.mil Thu May 30 13:58:41 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F73F21F8EDF; Thu, 30 May 2013 13:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVL2UHn4cZiZ; Thu, 30 May 2013 13:58:36 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id EA4FB21F8F0E; Thu, 30 May 2013 13:58:35 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.14.4/8.13.6) with ESMTP id r4UKwYwN031450; Thu, 30 May 2013 16:58:34 -0400 Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id r4UKwOoP027509; Thu, 30 May 2013 16:58:24 -0400 (EDT) Received: from ashurbanipal.fw5540.net ([10.0.3.109]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2013053016582422316 ; Thu, 30 May 2013 16:58:24 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_E29C7D43-7A2D-467E-99F4-D0F93BBD286A" Date: Thu, 30 May 2013 16:58:24 -0400 Message-Id: To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-mmusic-sdp-miscellaneous-caps.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [secdir] Secdir review of draft-ietf-mmusic-sdp-miscellaneous-caps-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 20:58:41 -0000 --Apple-Mail=_E29C7D43-7A2D-467E-99F4-D0F93BBD286A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This ID defines three new capabilities that can be negotiated in the = Session Description Protocols (SDP) using the SDP offer/answer procedure. These are bandwidth capability (proposed bandwidth to be = used by session or media), connection capability (network type, address type, and address), and title capability (human-readable textual = information about the session). None of these are directly security-related, although the authors point = out that an attacker who is able to modify traffic could modify the bandwidth value so that then = network winds up being under-utilized or over-utilized. They recommend using on of the security mechanisms = recommended in RFC5939 (which defines SDP capability negotiation in general) in case it is necessary to protect the bandwidth value. =20 I think this is a very appropriate recommendation for this ID, but = perhaps the authors should consider offering similar recommendations for the other capabilities. For example, in the connection capability = it is possible to offer an address together with a number of = alternatives. What happens if an attacker removes some or most of the addresses? = Could this lead to overuse of the remaining addresses? Likewise, one of = the reasons the human-readable title capability is provided is so that a human can make choices about = which media configurations to choose. If the attacker tampers with a = label so that the human is caused to make wrong choices, this could = again cause problems. I think it could be worthwhile to point out that there = may be cases for both connection and title capabilities where = adversarial tampering could have harmful effects, and if this is the case the security mechanisms in RFC5939 should be = applied as well.=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=_E29C7D43-7A2D-467E-99F4-D0F93BBD286A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. =  These comments were written primarily for the benefit of the = security area directors.  Document editors and WG chairs = should treat these comments just like any other last call = comments.


This ID defines three = new capabilities that can be negotiated in the Session Description = Protocols (SDP) using the SDP offer/answer
procedure.  These = are bandwidth capability (proposed bandwidth to be used by session or = media), connection capability (network type, address
type, and = address), and title capability (human-readable textual information about = the session).

None of these are directly = security-related, although the authors point out that an attacker = who
is able to modify traffic could modify the bandwidth value = so that then network winds up being under-utilized
or = over-utilized.  They recommend using on of the security mechanisms = recommended in RFC5939 (which defines SDP capability = negotiation
in general) in case
it is necessary to = protect the bandwidth value.  

I think = this is a very appropriate recommendation for this ID, but perhaps the = authors should consider offering similar recommendations
for = the other capabilities.  For example, in the connection capability = it is possible to offer an address together with a number of = alternatives.
What happens if an attacker removes some or most = of the addresses?  Could this lead to overuse of the remaining = addresses?  Likewise, one of the reasons the = human-readable
title capability is provided is so that a human = can make choices about which media configurations to choose.  If = the attacker tampers with a label so that the human is caused to make = wrong choices, this could again
cause problems.  I think = it could be worthwhile to point out that there may be cases for both = connection and title capabilities where adversarial tampering could have = harmful effects,
and if this is the case the security = mechanisms in RFC5939 should be applied as = well. 


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=_E29C7D43-7A2D-467E-99F4-D0F93BBD286A-- From scott@hyperthought.com Thu May 30 17:48:05 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD1C21F9921 for ; Thu, 30 May 2013 17:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wh7z5E7INDw2 for ; Thu, 30 May 2013 17:48:00 -0700 (PDT) Received: from smtp182.iad.emailsrvr.com (smtp182.iad.emailsrvr.com [207.97.245.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7D75921F9193 for ; Thu, 30 May 2013 17:48:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id DEEBAE0559; Thu, 30 May 2013 20:47:59 -0400 (EDT) X-Virus-Scanned: OK Received: from legacy18.wa-web.iad1a (legacy18.wa-web.iad1a.rsapps.net [192.168.4.108]) by smtp28.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id C25B5E0544; Thu, 30 May 2013 20:47:59 -0400 (EDT) Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by legacy18.wa-web.iad1a (Postfix) with ESMTP id ACBD536002E; Thu, 30 May 2013 20:47:59 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 30 May 2013 17:47:59 -0700 (PDT) Date: Thu, 30 May 2013 17:47:59 -0700 (PDT) From: "Scott G. Kelly" To: draft-ietf-cuss-sip-uui.all@tools.ietf.org, "secdir@ietf.org" , "iesg@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 Message-ID: <1369961279.70598635@apps.rackspace.com> X-Mailer: webmail7.0 Subject: [secdir] secdir review of draft-ietf-cuss-sip-uui-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 00:48:06 -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=0AI have no expertise in SIP, and am providi= ng this review as a first-level filter for our over-worked security ADs. So= , please take my comments accordingly. Also, this review is a day late -- I= hope it is still useful.=0A=0AThis document defines a method for exchangin= g a blob of information between user agents during SIP session establishmen= t (User to User Information, or UUI data) by adding a new SIP header. The d= ata is intended to be opaque to SIP.=0A=0AThere is a related problem statem= ent RFC (6567) that briefly describes 3 different approaches to security, b= ut neither document describes likely threats. They are implicit in the 3 mo= dels described in 6567 (e.g. treat the sip layer as "untrusted", treat the = sip layer as "trusted", treat the transport domain as "trusted"), but I fou= nd myself wishing I had more info about real-world threats and countermeasu= res.=0A=0AGiven that I am not a SIP expert (and don't have time to become o= ne as part of this review), I don't know if this is an issue or not, but th= is is an impression I think worth mentioning.=0A=0AA second question relate= s to the binding of the UUI to its originator. The security considerations = section suggests that the UUI might carry sensitive info requiring privacy = or integrity protection, but does not mention origin authentication. There = is a hint in the next paragraph (it says "History-Info can be used to deter= mine the identity of the inserter"), but the relative security of this mech= anism is not clear to me. Could an attacker forge History-Info? I don't kno= w. What are the consequences of such behavior? I don't know. Seems like a w= ell-written security considerations section would lay these questions to re= st.=0A=0AAgain, I have almost zero knowledge of SIP, so maybe answers are o= bvious to someone steeped in SIP lore, and I apologize if this is the case.= But, these are my impressions.=0A=0A--Scott =0A From Simo.Veikkolainen@nokia.com Fri May 31 04:19:05 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D797821F8717; Fri, 31 May 2013 04:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYEknXHpVEWr; Fri, 31 May 2013 04:19:00 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id C5D1821F8EFE; Fri, 31 May 2013 04:18:59 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r4VBIqLf012606; Fri, 31 May 2013 14:18:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.48]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 May 2013 14:19:02 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.223]) by 008-AM1MMR1-014.mgdnok.nokia.com ([2002:4136:1e30::4136:1e30]) with mapi id 14.02.0328.011; Fri, 31 May 2013 11:19:54 +0000 From: To: , , , Thread-Topic: Secdir review of draft-ietf-mmusic-sdp-miscellaneous-caps-05 Thread-Index: AQHOXXildvNZ2EoTpkCVEr5L56e6dZkfI/ow Date: Fri, 31 May 2013 11:19:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IpQCv9FX5PeIK/RR4/BbKzm/H1vuz873kAI8XNEuuGYLNsphiUF3B0u6NaMLQCrjfso5MRg7U/4xkmeCFs/FbHm3yHA2KrzzT60UNhIV4kW5ewaFWVwjqSTyYUeuwMZHSB2bGdFBjxbOE/fj2hzAeHpur34XC570mYq8Agn90wFmH20bS8s6PmEKJbwZbHhwmgn2NFgTd7Yi2LwRlJWj6qxuFZ38SGx1shd3xIX1SQ/UvPUFrvGrbniy6zikLiEwYV+FrQVmjDYWwN/+UpTQnr8= x-originating-ip: [172.21.81.112] Content-Type: multipart/alternative; boundary="_000_D09DAE6B636851459F7575D146EFB54B2405E532008AM1MPN1026mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 May 2013 11:19:02.0370 (UTC) FILETIME=[A77ACC20:01CE5DF0] X-Nokia-AV: Clean X-Mailman-Approved-At: Fri, 31 May 2013 04:36:34 -0700 Subject: Re: [secdir] Secdir review of draft-ietf-mmusic-sdp-miscellaneous-caps-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 11:19:06 -0000 --_000_D09DAE6B636851459F7575D146EFB54B2405E532008AM1MPN1026mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Catherine, Thank you for the comments, please see my answers below prefixed with [SV]. From: ext Catherine Meadows [mailto:catherine.meadows@nrl.navy.mil] Sent: 30. toukokuuta 2013 23:58 To: iesg@ietf.org; secdir@ietf.org; draft-ietf-mmusic-sdp-miscellaneous-cap= s.all@tools.ietf.org Cc: Catherine Meadows Subject: Secdir review of draft-ietf-mmusic-sdp-miscellaneous-caps-05 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 ID defines three new capabilities that can be negotiated in the Sessio= n Description Protocols (SDP) using the SDP offer/answer procedure. These are bandwidth capability (proposed bandwidth to be used b= y session or media), connection capability (network type, address type, and address), and title capability (human-readable textual informatio= n about the session). None of these are directly security-related, although the authors point out= that an attacker who is able to modify traffic could modify the bandwidth value so that then net= work winds up being under-utilized or over-utilized. They recommend using on of the security mechanisms recom= mended in RFC5939 (which defines SDP capability negotiation in general) in case it is necessary to protect the bandwidth value. I think this is a very appropriate recommendation for this ID, but perhaps = the authors should consider offering similar recommendations for the other capabilities. For example, in the connection capability it i= s possible to offer an address together with a number of alternatives. What happens if an attacker removes some or most of the addresses? Could t= his lead to overuse of the remaining addresses? Likewise, one of the reaso= ns the human-readable title capability is provided is so that a human can make choices about whic= h media configurations to choose. If the attacker tampers with a label so = that the human is caused to make wrong choices, this could again cause problems. I think it could be worthwhile to point out that there may= be cases for both connection and title capabilities where adversarial tamp= ering could have harmful effects, and if this is the case the security mechanisms in RFC5939 should be applie= d as well. [SV] I agree that just addressing the possible misuse of the bandwidth capa= bility might give an impression that there are no foreseen threats with the= two other capabilities. For the connection address capability ("ccap") att= ribute, the most harmful threat would actually that the attacker tricks the= endpoint to send media to an unaware destination. This type of DoS attack = in the context of voice over IP (called the "voice hammer") is discussed in= RFC5245. [SV] I have modified the relevant paragraphs and added new text to read: The bandwidth capability attribute may be used for reservin= g resources at endpoints and intermediaries which inspect the SDP. Modification of the bandwidth value by an attacker can lead to the network being underutilized (too high bandwidth value) or congested (too low bandwidth value). Similarly, by modifying the alternative connection address(es), an attacker would be able direct media streams= to a desired endpoint, thus launching a version of the well kn= own voice hammer attack (see Section 18.5.1 of [RFC5245]). The title capability provides for alternative "i=3D" line information, which is intended for human consumption. Howev= er, manipulating the textual information could be misused to provide false information, leading to bad user experience o= r the person using the service making wrong the choice regarding the available media streams. In case it is essential to protect the capability attribute values, one of the security mechanisms proposed in [RFC5939= ] SHOULD be used. Regards, Simo 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 --_000_D09DAE6B636851459F7575D146EFB54B2405E532008AM1MPN1026mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Catherine,

 <= /p>

Thank you for the comment= s, please see my answers below prefixed with [SV].

 <= /p>

From: ext Catherine Meadows [mailto:catherine.meado= ws@nrl.navy.mil]
Sent: 30. toukokuuta 2013 23:58
To: iesg@ietf.org; secdir@ietf.org; draft-ietf-mmusic-sdp-miscellane= ous-caps.all@tools.ietf.org
Cc: Catherine Meadows
Subject: Secdir review of draft-ietf-mmusic-sdp-miscellaneous-caps-0= 5

 

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

 

 

This ID defines three new capabilities that can be n= egotiated in the Session Description Protocols (SDP) using the SDP offer/an= swer

procedure.  These are bandwidth capability (pro= posed bandwidth to be used by session or media), connection capability (net= work type, address

type, and address), and title capability (human-read= able textual information about the session).

 

None of these are directly security-related, althoug= h the authors point out that an attacker who

is able to modify traffic could modify the bandwidth= value so that then network winds up being under-utilized

or over-utilized.  They recommend using on of t= he security mechanisms recommended in RFC5939 (which defines SDP capability= negotiation

in general) in case

it is necessary to protect the bandwidth value. &nbs= p;

 

I think this is a very appropriate recommendation fo= r this ID, but perhaps the authors should consider offering similar recomme= ndations

for the other capabilities.  For example, in th= e connection capability it is possible to offer an address together with a = number of alternatives.

What happens if an attacker removes some or most of = the addresses?  Could this lead to overuse of the remaining addresses?=  Likewise, one of the reasons the human-readable

title capability is provided is so that a human can = make choices about which media configurations to choose.  If the attac= ker tampers with a label so that the human is caused to make wrong choices,= this could again

cause problems.  I think it could be worthwhile= to point out that there may be cases for both connection and title capabil= ities where adversarial tampering could have harmful effects,

and if this is the case the security mechanisms in R= FC5939 should be applied as well. 

 

[SV] I agree that just ad= dressing the possible misuse of the bandwidth capability might give an impr= ession that there are no foreseen threats with the two other capabilities. For the connection address capability (“ccap”) a= ttribute, the most harmful threat would actually that the attacker tricks t= he endpoint to send media to an unaware destination. This type of DoS attac= k in the context of voice over IP (called the “voice hammer”) is discussed in RFC5245.

 <= /p>

[SV] I have modified the = relevant paragraphs and added new text to read:

 <= /p>

    &= nbsp;           The bandw= idth capability attribute may be used for reserving

    &= nbsp;           resources= at endpoints and intermediaries which inspect the

    &= nbsp;           SDP. Modi= fication of the bandwidth value by an attacker can

    &= nbsp;           lead to t= he network being underutilized (too high bandwidth

    &= nbsp;           value) or= congested (too low bandwidth value).

 <= /p>

    &= nbsp;           Similarly= , by modifying the alternative connection

    &= nbsp;           address(e= s), an attacker would be able direct media streams to

    &= nbsp;           a desired= endpoint, thus launching a version of the well known

    &= nbsp;           voice ham= mer attack (see Section 18.5.1 of [RFC5245]).

 <= /p>

    &= nbsp;           The title= capability provides for alternative "i=3D" line

    &= nbsp;           informati= on, which is intended for human consumption. However,

    &= nbsp;           manipulat= ing the textual information could be misused to

    &= nbsp;           provide f= alse information, leading to bad user experience or

    &= nbsp;           the perso= n using the service making wrong the choice

    &= nbsp;           regarding= the available media streams.

 

    &= nbsp;           In case i= t is essential to protect the capability attribute

    &= nbsp;           values, o= ne of the security mechanisms proposed in [RFC5939]

    &= nbsp;          SHOULD be used.


Regards,

Simo

 <= /p>

 

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

 

--_000_D09DAE6B636851459F7575D146EFB54B2405E532008AM1MPN1026mg_-- From stephen.farrell@cs.tcd.ie Fri May 31 08:01:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9989F21F9945 for ; Fri, 31 May 2013 08:01:02 -0700 (PDT) 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=[AWL=-0.700, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opTpOP3HYxea for ; Fri, 31 May 2013 08:00:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDD121F96EA for ; Fri, 31 May 2013 08:00:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E2A0ABEAA for ; Fri, 31 May 2013 16:00:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ1UKmfFHqQs for ; Fri, 31 May 2013 16:00:28 +0100 (IST) Received: from [192.168.147.94] (unknown [216.239.55.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BF762BE7B for ; Fri, 31 May 2013 16:00:27 +0100 (IST) Message-ID: <51A8BB08.9000304@cs.tcd.ie> Date: Fri, 31 May 2013 16:00:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "secdir@ietf.org" References: <20130531145733.25098.98066.idtracker@ietfa.amsl.com> In-Reply-To: <20130531145733.25098.98066.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130531145733.25098.98066.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: [secdir] Fwd: 87th IETF - Working Group/BOF/IRTF Scheduling - Cut-off Monday, June 3 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 15:01:02 -0000 FYI - if you've not gotten your meeting request in... S -------- Original Message -------- Subject: 87th IETF - Working Group/BOF/IRTF Scheduling - Cut-off Monday, June 3 Date: Fri, 31 May 2013 07:57:33 -0700 From: IETF Agenda Reply-To: IETF Agenda To: Working Group Chairs CC: irsg@irtf.org Subject: 87th IETF - Working Group/BOF/IRTF Scheduling ----------------------------------------------------------------- 87th IETF – Berlin, Germany Meeting Dates: July 28 – August 2, 2013 ----------------------------------------------------------------- IETF meetings start Monday morning and run through Friday afternoon (13:30). We are accepting scheduling requests for all Working Groups, BOFs, and Research Groups starting today. The milestones and deadlines for scheduling-related activities are as follows: NOTE: cutoff dates are subject to change. - 2013-06-03 (Monday): Cut-off date for requests to schedule Working Group meetings at UTC 24:00. To request a Working Group session, use the IETF Meeting Session Request Tool. - 2013-06-17 (Monday): Cut-off date for BOF proposal requests to Area Directors at UTC 24:00. To request a BOF, please see instructions on Requesting a BOF. - 2013-06-20 (Thursday): Cut-off date for Area Directors to approve BOFs at UTC 24:00. - 2013-06-27 (Thursday): Preliminary agenda published for comment. - 2013-07-01 (Monday): Cut-off date for requests to reschedule Working Group and BOF meetings UTC 24:00. - 2013-07-05 (Friday): Final agenda to be published. - 2013-07-17 (Wednesday): Draft Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool. - 2013-07-22 (Monday): Revised Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool. - 2013-08-30 (Friday): Proceedings submission cutoff date by UTC 24:00, upload using IETF Meeting Materials Management Tool. - 2013-09-18 (Wednesday): Proceedings submission corrections cutoff date by UTC 24:00, upload using IETF Meeting Materials Management Tool. Submitting Requests for Working Group and BOF Sessions Please submit requests to schedule your Working Group sessions using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information that the Secretariat requires to schedule your sessions. The URL for the tool is: https://pub.ietf.org/sreq/ Please send requests to schedule your BOF sessions to agenda@ietf.org. Please include the acronym of your BOF in the subject line of the message, and include all of the information specified in item (4) of "Requesting Meeting Sessions at IETF Meetings" in the body. (This document is included below.) Submitting Session Agendas For the convenience of meeting attendees, we ask that you submit the agendas for your Working Group sessions as early as possible. Draft Working Group agendas are due Wednesday, July 17, 2013 at UTC 24:00. Revised Working Group agendas are due no later than Monday, July 22, 2013 at UTC 24:00. The proposed agenda for a BOF session should be submitted along with your request for a session. Please be sure to copy your Area Director on that message. Please submit the agendas for your Working Group sessions using the "IETF Meeting Materials Management Tool," a Web-based tool for making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting. If you are a BOF chair, then you may use the tool to submit a revised agenda as well as other materials for your BOF once the BOF has been approved. The URL for the tool is: https://pub.ietf.org/proceedings/ Additional information about this tool is available at: http://www.ietf.org/instructions/meeting_materials_tool.html Agendas submitted via the tool will be available to the public on the "IETF Meeting Materials" webpage as soon as they are submitted. The URL for the "IETF 87 Meeting Materials" Web page is: https://datatracker.ietf.org/meeting/87/materials.html If you are a Working Group chair, then you already have accounts on the "IETF Meeting Session Request Tool" and the "IETF Meeting Materials Management Tool." The same User ID and password will work for both tools. If you are a BOF chair who is not also a Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been approved. If you require assistance in using either tool, or wish to report a bug, then please send a message to: ietf-action@ietf.org. =============================================================== For your convenience, comprehensive information on requesting meeting sessions at IETF 87 is presented below: 1. Requests to schedule Working Group sessions should be submitted using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information required by the Secretariat to schedule your sessions. The URL for the tool is: https://pub.ietf.org/sreq/ Instructions for using the tool are available at: http://www.ietf.org/instructions/session_request_tool_instruction.html If you require an account on this tool, or assistance in using it, then please send a message to ietf-action@ietf.org. If you are unable to use the tool, then you may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area Director(s). Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(s). When submitting a Working Group or BOF session request by e-mail, please include the Working Group or BOF acronym in the Subject line. 2. BOFs will NOT be scheduled unless the Area Director approves the BOF. The proponents behind a BOF need to contact a relevant Area Director, preferably well in advance of the BOF approval deadline date. The AD needs to have the full name of the BOF, its acronym, suggested names of chairs, an agenda, full description of the BOF and the information covered in item 4. Please read RFC 5434 for instructions on how to drive a successful BOF effort. The approval depends on, for instance, Internet-Drafts and list discussion on the suggested topic. BOF agenda requests, if approved, will be submitted to the IETF Secretariat by the ADs. 3. A Working Group may request either one or two sessions. If your Working Group requires more than two sessions, then your request must be approved by an Area Director. Additional sessions will be assigned, based on availability, after Monday, July 1, 2013, the cut-off date for requests to reschedule a session. 4. You MUST provide the following information before a Working Group or BOF session will be scheduled: a. Working Group or BOF full name with acronym in brackets: b. AREA under which Working Group or BOF appears: c. CONFLICTS you wish to avoid, please be as specific as possible: d. Expected Attendance: e. Special requests: f. Number of sessions: g. Length of session: - 1 hour - 1 1/2 hours - 2 hours - 2 1/2 hours For more information on scheduling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" (http://www.ietf.org/rfc/rfc2418.txt). =============================================================== For your convenience please find here a list of the IETF Area Directors with their e-mail addresses: IETF Chair Jari Arkko Applications Area (app) Barry Leiba Pete Resnick Internet Area (int) Brian Haberman Ted Lemon Operations & Management Area (ops) Benoit Claise Joel Jaeggli Real-time Applications and Infrastructure Area (rai) Gonzalo Camarillo Richard Barnes Routing Area (rtg) Stewart Bryant Adrian Farrel Security Area (sec) Stephen Farrell Sean Turner Transport Area (tsv) Martin Stiemerling =========================================================== 86th IETF Meeting Attendance Number 6man - 96 abfab - 34 aggsrv (BoF) - 93 alto - 36 appsawg - 98 avtcore - 57 avtext - 61 behave - 45 bmwg - 24 ccamp - 87 ccamp (2nd session) - 51 ccamp (3rd session) - 32 cdni - 51 cdni (2nd session) - 49 cfrg (RG) - 35 clue - 53 clue (2nd session) - 50 core - 67 core (2nd session) - 49 dhc - 54 dime - 24 dispatch - 66 dmm - 30 dnsop - 50 ecrit - 39 eman - 28 emu - 24 forces - 41 grow - 49 history (BoF) - 150 homenet - 137 httpauth - 64 httpbis - 79 i2rs - 228 iab-wcit (BoF) - 146 iccrg (RG) - 97 icnrg (RG) - 76 idr - 80 intarea (AG) - 72 ipfix - 19 ippm - 44 ippm (2nd session) - 36 iprbis (BoF) - 58 ipsecme - 47 IRTF Open Meeting - 63 isis - 46 jose - 65 json (BoF) - 86 karp - 29 l2vpn - 103 l3vpn - 82 lmap (BoF) - 100 lwig - 39 manet - 23 mboned - 24 mif - 40 mile - 39 mmusic - 92 mmusic (2nd session) - 61 mpls - 114 mpls (2nd session) - 107 mptcp - 43 multimob - 32 ncrg (RG) - 73 netconf - 67 nfsv4 - 13 nmrg (RG) - 15 nwcrg (RG BoF) - 40 nvo3 - 226 oauth - 42 oauth (2nd session) - 44 opsawg - 88 opsec - 32 ospf - 26 p2psip - 27 paws - 32 pce - 99 pcp - 43 pcp (2nd session) - 33 pim - 24 pkix - 50 precis - 27 pwe3 - 77 radext - 22 rmcat - 82 roll - 63 rtcweb - 170 rtcweb (2nd session) - 137 rtgarea (AG) - 51 rtgwg - 117 saag (AG) - 115 sacm (BoF) - 48 scim - 25 sdnrg (RG) - 265 sidr - 69 sidr (2nd session) - 57 siprec - 27 softwire - 75 softwire (2nd session) - 66 straw - 26 sunset4 - 82 tcpm - 39 tictoc - 26 tls - 76 trill - 55 tsvarea (AG) - 160 tsvwg - 94 tsvwg (2nd session) - 54 v6ops - 157 v6ops (2nd session) - 113 websec - 68 weirds - 55 weirds (2nd session) - 25 wpkops - 34 xmpp - 23 xrblock - 27 From new-work-bounces@ietf.org Fri May 31 08:39:09 2013 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 8840F21F9622; Fri, 31 May 2013 08:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1370014749; bh=IrcrPsefy1fr/0OWvlaEvN9D0IgTWwjkfllMqn5a2Bg=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=OxQKH1Yj0gRE+OnSJx3jfpDhFINWmuYSZJ3ilflTm+4J/JdmWUBI+tj5TSCiuluJV zXbmIwqgQ0z14OLDME3BME2LjxSICAKXXs1YuMN+epdx8VKNZlHbh5xyRuHjJvQdp3 d6Nbh4h7KFuOUJSWK6cOsNJI0IHJAAmS7TeAH86w= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5605221F9732; Fri, 31 May 2013 08:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.73 X-Spam-Level: X-Spam-Status: No, score=-101.73 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHQB9HoMHI2j; Fri, 31 May 2013 08:39:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDAC21F86CA; Fri, 31 May 2013 08:39:06 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130531153906.7497.80230.idtracker@ietfa.amsl.com> Date: Fri, 31 May 2013 08:39:06 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 31 May 2013 09:03:59 -0700 Subject: [secdir] [new-work] WG Review: SIP-TO-XMPP (stox) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 15:39:09 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure 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 at ietf.org) by 2013-06-10. SIP-TO-XMPP (stox) ------------------------------------------------ Current Status: Proposed WG Chairs: Markus Isomaki Yana Stamcheva Assigned Area Director: Gonzalo Camarillo Mailing list Address: stox@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stox Archive: http://www.ietf.org/mail-archive/web/stox/ Charter: Problem Statement The IETF has defined two signalling technologies that can be used for multimedia session negotiation, instant messaging, presence, file transfer, capabilities discovery, notifications, and other types of real-time functionality: o The Session Initiation Protocol (SIP), along with various SIP extensions developed within the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group. o The Extensible Messaging and Presence Protocol (XMPP), along with various XMPP extensions developed by the IETF as well as by the XMPP Standards Foundation. SIP has been focused primarily on media session negotiation (e.g., audio and video), whereas XMPP has been focused primarily on messaging and presence. As a result, the technologies are mostly complementary. However, there is also some overlap between SIP and XMPP, since there are SIP extensions for messaging, presence, groupchat, file transfer, etc., and there are XMPP extensions for multimedia session negotiation. This overlap has practical implications, since some deployed services use SIP for both media and messaging/presence, whereas other deployed services use XMPP for both messaging/presence and media. When such services wish to exchange information, they often need to translate their native protocol (either SIP or XMPP) to the other protocol (either XMPP or SIP). Implementers needing to perform such protocol mappings have often worked out their own heuristics for doing so. Unfortunately, these heuristics are not always consistent, which can lead to interoperability problems. Objectives To make it easier for implementers to enable interworking between SIP-based systems and XMPP-based systems, several Internet-Drafts have defined guidelines for protocol mapping between SIP and XMPP, starting with draft-saintandre-xmpp-simple-00 in early 2004. The current documents are: draft-saintandre-sip-xmpp-core draft-saintandre-sip-xmpp-presence draft-saintandre-sip-xmpp-im draft-saintandre-sip-xmpp-chat draft-saintandre-sip-xmpp-groupchat draft-saintandre-sip-xmpp-media These documents are fairly stable and the authors have received feedback from a number of implementers over the years. However, implementers do not always know about these documents because they are Internet-Drafts and sometimes they have become expired due to inactivity. Thus it would be helpful to polish them off and publish them as RFCs. It might also be helpful to at some point publish additional documents in the same series, covering topics like capabilities discovery and file transfer. However, any such work would require a recharter. The group shall not be tasked with defining any new protocols, only with specifying mappings between existing protocols that have been defined for SIP and XMPP. Deliverables 1. Address mapping and error handling 2. Presence mapping 3. Mapping for single instant messages 4. Mapping for one-to-one text chat sessions 5. Mapping for multi-user text chat sessions 6. Mapping for media signaling All of the foregoing deliverables are standards track, since they are subject to interoperability testing. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work