From kivinen@iki.fi Tue Sep 4 06:51:09 2012 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 C942321F850C; Tue, 4 Sep 2012 06:51: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+wj77S308VC; Tue, 4 Sep 2012 06:51: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 A10B021F84F8; Tue, 4 Sep 2012 06:51:08 -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 q84Dp23r010825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2012 16:51:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q84Dp1X8010549; Tue, 4 Sep 2012 16:51:01 +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: <20550.1861.349381.646147@fireball.kivinen.iki.fi> Date: Tue, 4 Sep 2012 16:51:01 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-httpbis-p6-cache.all@tools.ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 53 min X-Total-Time: 50 min Subject: [secdir] Secdir review of draft-ietf-httpbis-p6-cache-20 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, 04 Sep 2012 13:51:09 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is part 6 of the HTTP/1.1 and covers the caching in http. The security considerations section is quite short covering the case that caches are attractive targets for attackers and that the fact that cache can reveal information long after the information has been removed from the network. I think the security considerations section should list other attacks too. Things that comes to my mind: - Cache poisoning attacks, i.e. attacker who can control the www-server for a moment could pre-load cache with stuff that will stay there for long time (as long as the cache control attributes say). This includes negative result (404) caching. - Cache caching stuff that was not supposed to be cached, like authentication credentials in forms of cookies (the RFC6265 - "HTTP State Management Mechanism" says that the presense of the cookies does not preclude HTTP caches from storing and reusing a response). This can be problem unless all applications using cookies actually make sure that they set all pages as non-cacheable. - Cache might leak out information to other users of the cache who fetched the page in the first time. This leaking can happen in multiple ways (for example cookies, etc). Actually just timing can tell that someone has already fetched the page to the cache, which in some cases might be enough to leak information out. There most likely are still other attacks which I did not list above. Also as cookies are quite often used in various things like authentication, session identifiers, language selection etc, I think the section 3 should mention something about them, especially mention that RFC6265 says they can be cached (this was suprise for me, I would have expected cookies to be counted in the same category as authorization fields i.e. fields thta disable caching). I was also suprised not to find warning about the caching of the cookies in the RFC6265, but perhaps we should add note here in security considerations section saying that by default cookies are cachable, so applications using them must make sure they are not cached unless wanted so. It might not be able to reach its intended users (the ones writing web applications), but at least it might spread the information to some relevant parties. In summary I think this document needs bit more work in security considerations section. -- kivinen@iki.fi From mnot@mnot.net Tue Sep 4 19:11:47 2012 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 803F321F84B9; Tue, 4 Sep 2012 19:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiZS4NHdqWAp; Tue, 4 Sep 2012 19:11:46 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BDE5921E80AC; Tue, 4 Sep 2012 19:11:45 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C11F322E1F4; Tue, 4 Sep 2012 22:11:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <20550.1861.349381.646147@fireball.kivinen.iki.fi> Date: Wed, 5 Sep 2012 12:11:31 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20550.1861.349381.646147@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1486) Cc: "ietf-http-wg@w3.org Group" , draft-ietf-httpbis-p6-cache.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-httpbis-p6-cache-20 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, 05 Sep 2012 02:11:47 -0000 Hi Tero, CC:ing the HTTP mailing list. These all seem reasonable. I'll work to update the Security = Considerations and publish in -21, will ping you once that happens. Thanks, On 04/09/2012, at 11:51 PM, Tero Kivinen wrote: > I have reviewed this document as part of the security directorate's=20 > ongoing effort to review all IETF documents being processed by the=20 > IESG. These comments were written primarily for the benefit of the=20 > security area directors. Document editors and WG chairs should treat=20= > these comments just like any other last call comments. >=20 > This document is part 6 of the HTTP/1.1 and covers the caching in > http. >=20 > The security considerations section is quite short covering the case > that caches are attractive targets for attackers and that the fact > that cache can reveal information long after the information has been > removed from the network. >=20 > I think the security considerations section should list other attacks > too. Things that comes to my mind: >=20 > - Cache poisoning attacks, i.e. attacker who can control the > www-server for a moment could pre-load cache with stuff that will > stay there for long time (as long as the cache control attributes > say). This includes negative result (404) caching. >=20 > - Cache caching stuff that was not supposed to be cached, like > authentication credentials in forms of cookies (the RFC6265 - "HTTP > State Management Mechanism" says that the presense of the cookies > does not preclude HTTP caches from storing and reusing a response). > This can be problem unless all applications using cookies actually > make sure that they set all pages as non-cacheable. >=20 > - Cache might leak out information to other users of the cache who > fetched the page in the first time. This leaking can happen in > multiple ways (for example cookies, etc). Actually just timing can > tell that someone has already fetched the page to the cache, which > in some cases might be enough to leak information out. >=20 > There most likely are still other attacks which I did not list above. >=20 > Also as cookies are quite often used in various things like > authentication, session identifiers, language selection etc, I think > the section 3 should mention something about them, especially mention > that RFC6265 says they can be cached (this was suprise for me, I would > have expected cookies to be counted in the same category as > authorization fields i.e. fields thta disable caching). >=20 > I was also suprised not to find warning about the caching of the > cookies in the RFC6265, but perhaps we should add note here in > security considerations section saying that by default cookies are > cachable, so applications using them must make sure they are not > cached unless wanted so. It might not be able to reach its intended > users (the ones writing web applications), but at least it might > spread the information to some relevant parties. >=20 > In summary I think this document needs bit more work in security > considerations section. > --=20 > kivinen@iki.fi -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Sep 4 20:53:30 2012 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 0DC6821F844E for ; Tue, 4 Sep 2012 20:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBrbzH6dt1dV for ; Tue, 4 Sep 2012 20:53:29 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 08C1D21F844F for ; Tue, 4 Sep 2012 20:53:29 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9A84922E1F4; Tue, 4 Sep 2012 23:53:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: Date: Wed, 5 Sep 2012 13:53:13 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20550.1861.349381.646147@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1486) Cc: draft-ietf-httpbis-p6-cache.all@tools.ietf.org, "ietf-http-wg@w3.org Group" , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-httpbis-p6-cache-20 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, 05 Sep 2012 03:53:30 -0000 [ removing the IESG from the CC list] Please see: = https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cac= he.html#security.considerations Cheers, On 05/09/2012, at 12:11 PM, Mark Nottingham wrote: > Hi Tero, >=20 > CC:ing the HTTP mailing list. >=20 > These all seem reasonable. I'll work to update the Security = Considerations and publish in -21, will ping you once that happens. >=20 > Thanks, >=20 >=20 > On 04/09/2012, at 11:51 PM, Tero Kivinen wrote: >=20 >> I have reviewed this document as part of the security directorate's=20= >> ongoing effort to review all IETF documents being processed by the=20 >> IESG. These comments were written primarily for the benefit of the=20= >> security area directors. Document editors and WG chairs should treat=20= >> these comments just like any other last call comments. >>=20 >> This document is part 6 of the HTTP/1.1 and covers the caching in >> http. >>=20 >> The security considerations section is quite short covering the case >> that caches are attractive targets for attackers and that the fact >> that cache can reveal information long after the information has been >> removed from the network. >>=20 >> I think the security considerations section should list other attacks >> too. Things that comes to my mind: >>=20 >> - Cache poisoning attacks, i.e. attacker who can control the >> www-server for a moment could pre-load cache with stuff that will >> stay there for long time (as long as the cache control attributes >> say). This includes negative result (404) caching. >>=20 >> - Cache caching stuff that was not supposed to be cached, like >> authentication credentials in forms of cookies (the RFC6265 - "HTTP >> State Management Mechanism" says that the presense of the cookies >> does not preclude HTTP caches from storing and reusing a response). >> This can be problem unless all applications using cookies actually >> make sure that they set all pages as non-cacheable. >>=20 >> - Cache might leak out information to other users of the cache who >> fetched the page in the first time. This leaking can happen in >> multiple ways (for example cookies, etc). Actually just timing can >> tell that someone has already fetched the page to the cache, which >> in some cases might be enough to leak information out. >>=20 >> There most likely are still other attacks which I did not list above. >>=20 >> Also as cookies are quite often used in various things like >> authentication, session identifiers, language selection etc, I think >> the section 3 should mention something about them, especially mention >> that RFC6265 says they can be cached (this was suprise for me, I = would >> have expected cookies to be counted in the same category as >> authorization fields i.e. fields thta disable caching). >>=20 >> I was also suprised not to find warning about the caching of the >> cookies in the RFC6265, but perhaps we should add note here in >> security considerations section saying that by default cookies are >> cachable, so applications using them must make sure they are not >> cached unless wanted so. It might not be able to reach its intended >> users (the ones writing web applications), but at least it might >> spread the information to some relevant parties. >>=20 >> In summary I think this document needs bit more work in security >> considerations section. >> --=20 >> kivinen@iki.fi >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From new-work-bounces@ietf.org Wed Sep 5 15:20:15 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CFE21F86F8; Wed, 5 Sep 2012 15:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1346883615; bh=5rIISHWJB3zCYvl9332OUtdK9eu3S4QP5e8jVnGq9h0=; 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=muMVS5XZQykxjkUarn2mDdqcduF2RsLv6mWx0zhWBfgbfXkElsxoSq7AbNOzWae5d oSDcuV0G7EjlF6dw4l8ytRjacHWdCU6vjbQPvAQMkHoPGNU6V9Jio9ixnyxPyvyneM M3GALrcwcKVtm5SXXRc+oXtDB1ZJo2b5NyRRdXnA= 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 8803C21F86FA; Wed, 5 Sep 2012 15:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.859 X-Spam-Level: X-Spam-Status: No, score=-101.859 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMObgOFLPU3r; Wed, 5 Sep 2012 15:20:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E490F21F86F4; Wed, 5 Sep 2012 15:20:12 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120905222012.15283.86677.idtracker@ietfa.amsl.com> Date: Wed, 05 Sep 2012 15:20:12 -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: Wed, 05 Sep 2012 15:21:06 -0700 Subject: [secdir] [new-work] WG Review: RTP Media Congestion Avoidance Techniques (rmcat) 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, 05 Sep 2012 22:20:15 -0000 A new IETF working group has been proposed in the Transport 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 2012-09-12. RTP Media Congestion Avoidance Techniques (rmcat) ------------------------------------------------ Current Status: Proposed Working Group Assigned Area Director: Wesley Eddy Charter of Working Group: Description of Working Group Today's Internet traffic includes interactive real-time media, which is often carried via sets of flows using RTP over UDP. There is no generally accepted congestion control mechanism for this kind of data flow. With the deployment of applications using the RTCWEB protocol suite, the number of such flows is likely to increase, especially non-fixed-rate flows such as video or adaptive audio. There is therefore some urgency in specifying one or more congestion control mechanisms that can find general acceptance. Congestion control algorithms for interactive real time media may need to be quite different from the congestion control of TCP: for example, some applications can be more tolerant to loss than delay and jitter. The set of requirements for such an algorithm includes, but is not limited to: - Low delay and low jitter for the case where there is no competing traffic using other algorithms - Reasonable share of bandwidth when competing with RMCAT traffic, other real-time media protocols, and ideally also TCP and other protocols. A 'reasonable share' means that no flow has a significantly negative impact [RFC5033] on other flows and at minimum that no flow starves. - Effective use of signals like packet loss and ECN markings to adapt to congestion The working group will: - Develop a clear understanding of the congestion control requirements for RTP flows, and document deficiencies of existing mechanisms such as TFRC with regards to these requirements. This must be completed prior to finishing any Experimental algorithm specifications. - Identify interactions between applications and RTP flows to enable conveying helpful cross-layer information such as per-packet priorities, flow elasticity, etc. This information might be used to populate an API, but the WG will not define a specific API itself. - Determine if extensions to RTP/RTCP are needed for carrying congestion control feedback, using DCCP as a model. If so, provide the requirements for such extensions to the AVTCORE working group for standardization there. - Develop techniques to detect, instrument or diagnose failing to meet RT schedules due to failures of components outside of the charter scope, possibly in collaboration with IPPM. - Develop a mechanism for identifying shared bottlenecks between groups of flows, and means to flexibly allocate their rates within the aggregate hitting the shared bottleneck. - Define evaluation criteria for proposed congestion control mechanisms, and publish these as an Informational RFC. This must be completed prior to finishing any Proposed Standard algorithm specifications. - Find or develop candidate congestion control algorithms, verify that these can be tested on the Internet without significant risk, and publish one or more of these as Experimental RFCs. - Publish evaluation criteria and the result of experimentation with these Experimental algorithms on the Internet. This must be completed prior to finishing any Proposed Standard algorithm specifications. - Once an algorithm has been found or developed that meets the evaluation criteria, and has a satisfactory amount of documented experience on the Internet, publish this algorithm as a Standards Track RFC. There may be more than one such algorithm. - For each of the Experimental algorithms that have not been selected for the Standards Track, the working group will review the algorithm and determine whether the RFC should be moved to Historic status via a document that briefly describes the issues encountered. This step is particularly important for algorithms with significant flaws, such as ones that turn out to be harmful to flows using or competing with them. The work will be guided by the advice laid out in RFC 5405 (UDP Usage Guidelines), RFC 2914 (congestion control principles), and RFC5033 (Specifying New Congestion Control Algorithms). The following topics are out of scope of this working group, on the assumption that work on them will proceed elsewhere: - Circuit-breaker algorithms for stopping media flows when network conditions render them useless; this work is done in AVTCORE - Media flows for non-interactive purposes like stored video playback; those are not as delay sensitive as interactive traffic - Defining active queue management algorithms or modifications to TCP of any kind - Multicast congestion control; common control of multiple unicast flows is in scope - Topologies other than point-to-point connections; implications on multi-hop connections will be considered at a later stage The working group is expected to work closely with the RAI area, including the underlying technologies being worked on in the AVTCORE and AVTEXT WGs, and the applications/protocol suites being developed in the CLUE and RTCWEB working groups. It will also coordinate closely with other Transport area groups working on congestion control, and with the Internet Congestion Control Research Group of the IRTF. Deliverables: - Requirements for congestion control algorithms for interactive real time media as an Informational RFC - Evaluation criteria for congestion control algorithms for interactive real time media as an Informational RFC - RTCP extensions for use with congestion control algorithms as a Proposed Standard RFC - Interactions between applications and RTP flows as an Informational RFC - Identifying and controlling groups of flows as a Proposed Standard RFC - Techniques to detect, instrument or diagnose failing to meet RT schedules as either an Informational RFC or on the Standards Track if needed for interoperability or other aspects that would justify it. - Candidate congestion control algorithm for interactive real time media as Experimental RFCs (likely more than one) - Experimentation and evaluation results for candidate congestion control algorithms as an Informational RFC - One or more recommended congestion control algorithms for interactive real time media as Proposed Standard RFCs Milestones: _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From kivinen@iki.fi Fri Sep 7 02:49:42 2012 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 2F9D121F8763 for ; Fri, 7 Sep 2012 02:49:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjs44KWs2-VT for ; Fri, 7 Sep 2012 02:49:41 -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 4E68221F8731 for ; Fri, 7 Sep 2012 02:49:40 -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 q879nXV9010271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Sep 2012 12:49:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q879nXgV015620; Fri, 7 Sep 2012 12:49:33 +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: <20553.49964.912955.635261@fireball.kivinen.iki.fi> Date: Fri, 7 Sep 2012 12:49:32 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 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: Fri, 07 Sep 2012 09:49:42 -0000 The review tool has new feature where secretary can mark the document "Ready", "Ready with nits", "Ready with issues", "Almost ready", "Not ready" etc so it would be nice if you could put that kind of summary in your email too. ---------------------------------------------------------------------- Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Vincent Roca is next in the rotation. For telechat 2012-09-13 Reviewer LC end Draft Alan DeKok T 2012-08-23 draft-ietf-mmusic-media-loopback-22 Warren Kumari T 2012-09-03 draft-ietf-mpls-entropy-label-06 Julien Laganier T 2012-08-29 draft-ietf-sieve-imap-sieve-06 Vincent Roca TR2012-02-06 draft-ietf-simple-chat-16 For telechat 2012-09-27 Alexey Melnikov T 2012-08-13 draft-ietf-storm-iscsi-cons-06 Last calls and special requests: Dave Cridland 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-11 Phillip Hallam-Baker 2012-10-03 draft-kumaki-murai-l3vpn-rsvp-te-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-02 Catherine Meadows - draft-ietf-isis-mi-06 Alexey Melnikov 2012-09-05 draft-ietf-pkix-rfc5280-clarifications-09 Kathleen Moriarty 2012-09-18 draft-ietf-dime-rfc4005bis-11 Russ Mundy 2012-09-20 draft-ietf-eai-5738bis-09 Sandy Murphy 2012-09-20 draft-ietf-eai-popimap-downgrade-07 Yoav Nir 2012-09-20 draft-ietf-eai-rfc5721bis-07 Magnus Nystrom 2012-09-20 draft-ietf-eai-simpledowngrade-07 Hilarie Orman 2012-09-13 draft-ietf-grow-ops-reqs-for-bgp-error-handling-05 Radia Perlman 2012-09-18 draft-ietf-sipcore-proxy-feature-09 Eric Rescorla 2012-07-25 draft-ietf-websec-strict-transport-sec-12 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-09 Nico Williams - draft-ietf-httpbis-p5-range-20 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-08-14 draft-ietf-mptcp-api-05 -- kivinen@iki.fi From radiaperlman@gmail.com Sun Sep 9 22:42:30 2012 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 C0C3021F8489; Sun, 9 Sep 2012 22:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGOhgjOlQLEO; Sun, 9 Sep 2012 22:42:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 07DC021F847B; Sun, 9 Sep 2012 22:42:29 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so75673vbb.31 for ; Sun, 09 Sep 2012 22:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=t+RqQ9yq7zrp2wnR3Y80PW7a8NJzkSdnQxY/4A9Dncc=; b=goJdzoCaSiPP19s0CcH5Pv3S3jYeYWkDYFU3EsI/BxPSQH6aRQIsHMad9Lfg8w4sWH 5lChsZs2h07geiUxevke0MtZlbdxFGrk+QmQ+eJuQoNDSISXpJI3z1dvKsp+cSDbg+/J t04jTInnOz3r2DB6njMsuWaj0dBG0ku1uqe8ClUBHNCf5IgdPTGO4XH7V3l+yniC6dVb UgA6PVdE3u4PhTooyDL9bAwzE0XLsig1VLuYSIobJao0KyToRLDZe7oGbYuI8u0hjli8 NZvUU1VDy4UW1E+Lg2E6Sm9fEqDiw5fT/RvwJX7kLhoK1BDIuTzji7iRR0Huk5L0gYwe TvCQ== MIME-Version: 1.0 Received: by 10.52.69.106 with SMTP id d10mr14441305vdu.111.1347255748954; Sun, 09 Sep 2012 22:42:28 -0700 (PDT) Received: by 10.58.155.97 with HTTP; Sun, 9 Sep 2012 22:42:28 -0700 (PDT) Date: Sun, 9 Sep 2012 22:42:28 -0700 Message-ID: From: Radia Perlman To: secdir@ietf.org, The IESG , draft-ietf-sipcore-proxy-feature.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] SECDIR review of of draft-ietf-sipcore-proxy-feature 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, 10 Sep 2012 05:42:30 -0000 The draft is ready with nits A couple of typos: In section 4.2.1 "Procedures how features" should probably be something like "The procedure by which features" 4.2.2 tense doesn't match "The procedures in the section applies" should be "apply" This draft is basically just being able to advertise your capabilities to another node. As the security considerations section points out, this could divulge information that might be sensitive. Radia From christer.holmberg@ericsson.com Mon Sep 10 01:06:42 2012 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 51F2021F85A8; Mon, 10 Sep 2012 01:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv9vusE7-3yy; Mon, 10 Sep 2012 01:06:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EF59E21F859A; Mon, 10 Sep 2012 01:06:34 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-4e-504d9f899727 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7D.37.17130.98F9D405; Mon, 10 Sep 2012 10:06:33 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 10 Sep 2012 10:06:33 +0200 From: Christer Holmberg To: Radia Perlman , "secdir@ietf.org" , The IESG , "draft-ietf-sipcore-proxy-feature.all@tools.ietf.org" Date: Mon, 10 Sep 2012 10:06:31 +0200 Thread-Topic: SECDIR review of of draft-ietf-sipcore-proxy-feature Thread-Index: Ac2PF1iOwQ3tmYwNSlSZ8Yd+CNjQvwAE7auw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A4D3CC6@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+JvrW7nfN8Ag9fdmhaT+uawWcz4M5HZ Ysuct6wWHxY+ZHFg8dg56y67x5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CV8XTvScaCG0wV M+ZfZ2pg7GHqYuTkkBAwkXh46TErhC0mceHeerYuRi4OIYFTjBLNK3rYIZwFjBJnD/9m7GLk 4GATsJDo/qcNEhcRuMMosf/fcyaQOIuAqsTsZQEgg4QFHCUWzjvPAmKLCDhJ3NtwnA3CNpLY 3rIHzOYVCJdYcHcDM4gtJBAg8WTBAbB6ToFAiXnvPjKC2IxAB30/tQbsUGYBcYlbT+ZDHS0g sWTPeWYIW1Ti5eN/rBD1ohJ32tczQtTrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJ2FZOws JC2zkLTMQtKygJFlFaNwbmJmTnq5uV5qUWZycXF+nl5x6iZGYAQd3PLbYAfjpvtihxilOViU xHn1VPf7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBscckpPlE79ZNq4wJvK7W8R261pWet 1x6Y6qq1aFbd6jo+9eQz3N0yH62tpM9rTSjeelnodNjxN7PZ74Tc7Zn4rEk7fhVLU8oqPUVt vj/sQYf3yOotrS+uKtnzbG3c1by3a2avTErnCOMSCXs7e83PdwlXHQ577lur69jELxHKeWvz ndWf8u8osRRnJBpqMRcVJwIAG1fdoW4CAAA= Subject: Re: [secdir] SECDIR review of of draft-ietf-sipcore-proxy-feature 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, 10 Sep 2012 08:06:42 -0000 Hi Radia, >The draft is ready with nits > >A couple of typos: >In section 4.2.1 "Procedures how features" should probably be something li= ke "The procedure by which features" >4.2.2 tense doesn't match "The procedures in the section applies" >should be "apply" I'll fix the text as suggested. Thanks! Regards, Christer From alexey.melnikov@isode.com Mon Sep 10 07:11:06 2012 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 DCCD221F8694; Mon, 10 Sep 2012 07:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZSeYE2HhTkx; Mon, 10 Sep 2012 07:11:06 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 18CB321F867E; Mon, 10 Sep 2012 07:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1347286265; d=isode.com; s=selector; i=@isode.com; bh=i8vxhcq36UaHP/WfTq6nXBZvMv2HjiwuBqLD1RWdFGU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=qoJZ51eN7++CtYrUydabez59b5E+HEwCwscEfl8jNtDE7GWnOy0Nsi7faLavmHbjCzYHZj 7qfUa8ZMwLS/Z3BsyJkZRb/NFDdyRIhwLG96saQhijXQi4pBThtBvSwPpLlkkD1sKcLbI0 ZSpEnXjVFdXPm71PKzdsdVbQ+NQmGPU=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 10 Sep 2012 15:11:04 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <504DF506.5090107@isode.com> Date: Mon, 10 Sep 2012 15:11:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-pkix-rfc5280-clarifications.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-ietf-pkix-rfc5280-clarifications-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, 10 Sep 2012 14:11:07 -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 updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. The Security Considerations section is basically a patch to the Security Considerations in RFC 5280. I think the new text is a good addition and the whole section is adequate. I think the document is basically fine as far as SEC Area is concerned, but there are some related Apps issues: In Section 3 The explicitText string SHOULD NOT include any control characters (e.g., U+0000 to U+001F and U+007F to U+009F) I think you should really properly define what you are talking about here. Are you talking about Unicode Control characters? If yes, please say so. Suggested replacement: The explicitText string SHOULD NOT include any Unicode Control characters (i.e., U+0000 to U+001F and U+007F to U+009F) You should also consider whether you should reference RFC 5198 here (which restricts the set even further). Section 5 only talks about IDNA 2003. What about IDNA 2008? From kent@bbn.com Mon Sep 10 09:36:45 2012 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 5631321E8047 for ; Mon, 10 Sep 2012 09:36:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzLENX1S-ZzJ for ; Mon, 10 Sep 2012 09:36:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B94F521E8037 for ; Mon, 10 Sep 2012 09:36:41 -0700 (PDT) Received: from dhcp89-089-153.bbn.com ([128.89.89.153]:50879) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TB6yW-0001CK-BR; Mon, 10 Sep 2012 12:36:40 -0400 Message-ID: <504E1718.1030501@bbn.com> Date: Mon, 10 Sep 2012 12:36:40 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Alexey Melnikov References: <504DF506.5090107@isode.com> In-Reply-To: <504DF506.5090107@isode.com> Content-Type: multipart/alternative; boundary="------------010209010106020406090407" Cc: secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-pkix-rfc5280-clarifications-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, 10 Sep 2012 16:36:45 -0000 This is a multi-part message in MIME format. --------------010209010106020406090407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Alexey, Thanks for noting that ambiguity re "control characters." Peter: please adopt Alexey's suggested text in Section 3, in v-10. > The explicitText string SHOULD NOT include any *Unicode* Control > characters (i.e., U+0000 to U+001F and U+007F to U+009F) > > You should also consider whether you should reference RFC 5198 here > (which restricts the set even further). The goal the text here was to allow BMP string, based on deployment experience. The clarification you suggested is good, as it avoids ambiguity re what was said in 5280. Citing 5198 and adopting a more restrictive character set is too big a change for this doc. > Section 5 only talks about IDNA 2003. What about IDNA 2008? We're not prepared to move to IDNA 2008, at this time. This is a clarifications doc that updates 5280; the switch to IDNA 2008 would be too big a change for this doc. Steve --------------010209010106020406090407 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alexey,

Thanks for noting that ambiguity re "control characters."

Peter: please adopt Alexey's suggested text in Section 3, in v-10.

   The explicitText string SHOULD NOT include any Unicode Control
   characters (i.e., U+0000 to U+001F and U+007F to U+009F)

You should also consider whether you should reference RFC 5198 here (which restricts the set even further).
The goal the text here was to allow BMP string, based on deployment experience. The clarification
you suggested is good, as it avoids ambiguity re what was said in 5280. Citing 5198 and
adopting a more restrictive character set is too big a change for this doc.
Section 5 only talks about IDNA 2003. What about IDNA 2008?
We're not prepared to move to IDNA 2008, at this time. This is a clarifications doc that
updates 5280; the switch to IDNA 2008 would be too big a change for this doc.

Steve
--------------010209010106020406090407-- From vincent.roca@inria.fr Tue Sep 11 07:14:37 2012 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 7C4F721F8807; Tue, 11 Sep 2012 07:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eWn4P6t5vTl; Tue, 11 Sep 2012 07:14:37 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8607321F87BF; Tue, 11 Sep 2012 07:14:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,405,1344204000"; d="scan'208";a="155352745" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 11 Sep 2012 16:14:34 +0200 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 11 Sep 2012 16:14:34 +0200 Message-Id: <50F825B5-5FDA-4F28-BDE2-7A77B6FF87AF@inria.fr> To: IESG IESG , draft-ietf-simple-chat.all@tools.ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-ietf-simple-chat-16 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, 11 Sep 2012 14:14:37 -0000 Hello, 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. Since we already exchanged emails during the secdir review of version -14 of this document, I'll be brief. ** It is said: "If a participant wants to avoid eavesdropping, the participant's MSRP client can send the messages over a TLS [RFC5246] transport connection, as allowed by MSRP. It's up to the policy of the MSRP switch if the messages are forwarded to the other participant's in the chat room using TLS [RFC5246] transport." A participant cannot prevent eavesdropping if he does not control the end-to-end use of TLS. Additionally, as discussed previously, there are other benefits in the use of TLS, like preventing faked packet injection, or on-the-fly corruption of messages. So I suggest to clarify a bit: NEW: "If a participant wants to avoid security concerns on the path between himself and the MSRP switch (e.g., eavesdropping, faked packet injection or packet corruption), ..." ** About attacks with close but different nicknames: I see that a new paragraph has been added to section 7.1 to discuss this issue. That's excellent. However the security section does not provide any pointer to this discussion, nor does it mention the problem. The only aspect discussed is the reuse of nicknames which is a different (but important) topic. So I suggest to add a paragraph: NEW: "Section 7.1.discusses the problem of similar but different nicknames (e.g., thanks to the use of similar characters), and chat rooms MAY provide a mechanism to mitigate confusable nicknames." BTW, current I-D says that a chat room **MAY** provide such a mechanism. Should we change it for SHOULD? Said differently, is there a good reason for a chat room not to perform such verifications? If the answer is yes, then we can keep MAY. Cheers, Vincent From ynir@checkpoint.com Wed Sep 12 13:49:24 2012 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 D701821F857A; Wed, 12 Sep 2012 13:49:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTX89EO79-pV; Wed, 12 Sep 2012 13:49:24 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 766EC21F8574; Wed, 12 Sep 2012 13:49:23 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q8CKnKmd016098; Wed, 12 Sep 2012 23:49:20 +0300 X-CheckPoint: {5050F519-12-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 12 Sep 2012 23:49:18 +0300 From: Yoav Nir To: "secdir@ietf.org" , "iesg@ietf.org IESG" , "draft-ietf-eai-rfc5721bis.all@tools.ietf.org" Date: Wed, 12 Sep 2012 23:48:30 +0300 Thread-Topic: SECDIR review of draft-ietf-eai-rfc5721bis-07 Thread-Index: Ac2RJ/gAOiefXN7WRX+vZ/FKxkTrUQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SECDIR review of draft-ietf-eai-rfc5721bis-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, 12 Sep 2012 20:49:25 -0000 Hello, Summary: the document is almost ready. I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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 any= other last call comments. This document is a standards track version of RFC 5721, which was experimen= tal. It introduces two capabilities for POP3: UTF8, which indicates support for,= well, UTF8 in user names, passwords and other fields, and LANG which allow= s the client to set the localization used by the server for human-readable = responses. The security considerations section points to the sections of other RFCs fo= r the security considerations for UTF-8 and SASLPrep. That's a good thing I= MO. It also discusses an information disclosure issue, where the response t= o a "LANG *" command shows an eavesdropper the preferred language (and by e= xtension - nationality) of the user. The section advises that servers be co= nfigured to prevent this disclosure, but does not specify how that can be a= ccomplished. The section goes on to discuss a MitM attacker injecting a LANG command int= o the stream, but does not discuss a similar attack for the UTF-8 command. = That is probably OK, because it does not lead to any useful attack. Two more issues require a better explanation IMO: The draft says that STLS MUST NOT be used after the UTF8 command. It does n= ot say why, and I think it should. Section 2.1 requires the maildrop to run a conversion of data to UTF-8 when= the client supports it. I'm wondering if this can be exploited. Suppose we= have a spam filter that works only with ASCII and UTF-8. So the spammer ca= n send a message that is encoded in something else (EBCDIC?) that will bypa= ss the filter. Before this extension, the client would not be able to parse= this, but now, it gets converted to UTF-8 in the maildrop, and the spam ge= ts delivered after having bypassed the spam filter. So I think the authors should address these three minor issues, and then th= e document will be ready: (1) How do you protect against disclosure of user preferred language? (2) Why not STLS after UTF8? (3) Why attacks on the converter, or subverting it to bypass filtering is = not an issue (or maybe that it is) =20 Yoav=20 From hilarie@purplestreak.com Wed Sep 12 22:50:59 2012 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 DA3E121F84FE; Wed, 12 Sep 2012 22:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvmZkccxYMAx; Wed, 12 Sep 2012 22:50:59 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by ietfa.amsl.com (Postfix) with ESMTP id 64C9F21F84FA; Wed, 12 Sep 2012 22:50:59 -0700 (PDT) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out01.mta.xmission.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1TC2KE-0000og-R2; Wed, 12 Sep 2012 23:50:54 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx03.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TC2K6-0003Hh-UD; Wed, 12 Sep 2012 23:50:54 -0600 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id q8D5ohVf024951; Wed, 12 Sep 2012 23:50:43 -0600 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id q8D5ofpj024949; Wed, 12 Sep 2012 23:50:41 -0600 Date: Wed, 12 Sep 2012 23:50:41 -0600 Message-Id: <201209130550.q8D5ofpj024949@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600) X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com) Cc: draft-ietf-grow-ops-reqs-for-bgp-error-handling@tools.ietf.org, rob.shakir@bt.com Subject: [secdir] Security review of draft-ietf-grow-ops-reqs-for-bgp-error-handling-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 05:51:00 -0000 Secdir review of Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 draft-ietf-grow-ops-reqs-for-bgp-error-handling-05 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document intends to specify "requirements for ongoing work" in handling errors in BGP-4 protocol messages. The document says that it will not define the protocol mechanisms for implementing solutions. A lot of experience and thought has gone into writing this document. Nonetheless, I had a great deal of trouble finding the requirements because the writing is narrative and overly wordy. I would like to see the requirements stated clearly and separated from the rationalization. There are many requirements that seem to be dictated (not to be the subject of "ongoing work", apparently) and others that are quite vague: There is a requirement that where subsets of the RIB on a device are no longer reachable from a BGP speaker, or indeed an AS, that some visibility of this situation, alongside a mechanism to determine the cause is available to an operator. Whilst, to some extent, this can be solved by mandating a sub-requirement of each of the aforementioned requirements that a BGP speaker must log where such errors occur, and are hence handled, this does not solve all cases. It's difficult to untangle this sort of thing into analyzable requirements. >From a security standpoint, the requirement that offending BGP messages be returned to the sender is problematic. BGP has a lightweight cryptographic mechanism for protecting message integrity and providing authentication. The returned erroneous messages might help an attacker undermine the protection and thus insert bogus messages into a channel. The security considerations should point out that any new form of error handling requires cryptanalysis. Some minor editorial comments: "Whilst" is rarely used in American English. The synonym "while" is preferred, but in this document the word "although" would be a better replacement. In many cases omission altogether would improve the sentence. In this introductory paragraph "... numerous incidents have been recorded due to the manner in which [RFC4271] specifies errors in routing information should be handled." we do not learn why the "incidents" require any changes to error handling. The very term "incident" appears to be a pejorative in the mind of the author. Grammo: "It should, however, be noted" replace with "It should be noted, however" or "Note that ..." From kivinen@iki.fi Thu Sep 13 06:18:32 2012 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 A88AE21F84F9 for ; Thu, 13 Sep 2012 06:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0PJiWPzN+Ww for ; Thu, 13 Sep 2012 06:18:32 -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 C46FF21F84F8 for ; Thu, 13 Sep 2012 06:18:30 -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 q8DDIQ6a008562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Sep 2012 16:18:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q8DDIPlb014815; Thu, 13 Sep 2012 16:18:25 +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: <20561.56609.579642.75195@fireball.kivinen.iki.fi> Date: Thu, 13 Sep 2012 16:18:25 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 3 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, 13 Sep 2012 13:18:32 -0000 The review tool has new feature where secretary can mark the document "Ready", "Ready with nits", "Ready with issues", "Almost ready", "Not ready" etc so it would be nice if you could put that kind of summary in your email too. There is no new assignments this week, but there seems to be some missing reviews for this weeks telechat (and missed reviews for 2012-08-30 telechat too). ---------------------------------------------------------------------- Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Vincent Roca is next in the rotation. For telechat 2012-09-13 Reviewer LC end Draft Rob Austein T 2012-06-26 draft-ietf-bmwg-2544-as-06 Alan DeKok T 2012-08-23 draft-ietf-mmusic-media-loopback-22 Warren Kumari T 2012-09-03 draft-ietf-mpls-entropy-label-06 Julien Laganier T 2012-08-29 draft-ietf-sieve-imap-sieve-06 For telechat 2012-09-27 Alexey Melnikov T 2012-08-13 draft-ietf-storm-iscsi-cons-06 Last calls and special requests: Dave Cridland 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-11 Phillip Hallam-Baker 2012-10-03 draft-kumaki-murai-l3vpn-rsvp-te-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-02 Catherine Meadows - draft-ietf-isis-mi-06 Kathleen Moriarty 2012-09-18 draft-ietf-dime-rfc4005bis-11 Russ Mundy 2012-09-20 draft-ietf-eai-5738bis-09 Sandy Murphy 2012-09-20 draft-ietf-eai-popimap-downgrade-07 Magnus Nystrom 2012-09-20 draft-ietf-eai-simpledowngrade- Eric Rescorla 2012-07-25 draft-ietf-websec-strict-transport-sec-12 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-09 Nico Williams - draft-ietf-httpbis-p5-range-20 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-08-14 draft-ietf-mptcp-api-05 -- kivinen@iki.fi From kivinen@iki.fi Fri Sep 14 05:25:28 2012 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 0C27B21F8505 for ; Fri, 14 Sep 2012 05:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHL9e13nZfFe for ; Fri, 14 Sep 2012 05:25:27 -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 2C46221F84B5 for ; Fri, 14 Sep 2012 05:25:26 -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 q8ECPILV017522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Sep 2012 15:25:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q8ECPFBA003543; Fri, 14 Sep 2012 15:25:15 +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: <20563.8746.905008.389152@fireball.kivinen.iki.fi> Date: Fri, 14 Sep 2012 15:25:14 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 11 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: Fri, 14 Sep 2012 12:25:28 -0000 This is 2nd assignment email this week, because the one I sent earlier missed 5 new last calls (there was old mirrored copy of one file in the tool server running review tool). ---------------------------------------------------------------------- Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2012-09-27 Alexey Melnikov T 2012-08-13 draft-ietf-storm-iscsi-cons-06 Last calls and special requests: Dave Cridland 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-11 Phillip Hallam-Baker 2012-10-03 draft-kumaki-murai-l3vpn-rsvp-te-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-02 Catherine Meadows - draft-ietf-isis-mi-06 Kathleen Moriarty 2012-09-18 draft-ietf-dime-rfc4005bis-11 Russ Mundy 2012-09-20 draft-ietf-eai-5738bis-09 Sandy Murphy 2012-09-20 draft-ietf-eai-popimap-downgrade-07 Magnus Nystrom 2012-09-20 draft-ietf-eai-simpledowngrade-07 Eric Rescorla 2012-07-25 draft-ietf-websec-strict-transport-sec-12 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-09 Vincent Roca 2012-09-24 draft-ietf-dime-erp-12 Joe Salowey 2012-09-26 draft-ietf-krb-wg-camellia-cts-01 Yaron Sheffer 2012-09-26 draft-ietf-krb-wg-kerberos-referrals-14 Ondrej Sury 2012-09-26 draft-ietf-nea-asokan-01 Tina TSOU 2012-09-25 draft-ietf-v6ops-ivi-icmp-address-05 Nico Williams - draft-ietf-httpbis-p5-range-20 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-08-14 draft-ietf-mptcp-api-05 -- kivinen@iki.fi From miguel.a.garcia@ericsson.com Mon Sep 17 07:17:56 2012 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 1A49421F842D; Mon, 17 Sep 2012 07:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cExr3axgyYHJ; Mon, 17 Sep 2012 07:17:55 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D8DF121F8437; Mon, 17 Sep 2012 07:17:54 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-6b-505731115769 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2F.6E.25676.11137505; Mon, 17 Sep 2012 16:17:53 +0200 (CEST) Received: from [159.107.24.224] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Mon, 17 Sep 2012 16:17:53 +0200 Message-ID: <5057310F.3050903@ericsson.com> Date: Mon, 17 Sep 2012 16:17:51 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Vincent Roca References: <50F825B5-5FDA-4F28-BDE2-7A77B6FF87AF@inria.fr> In-Reply-To: <50F825B5-5FDA-4F28-BDE2-7A77B6FF87AF@inria.fr> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvra6gYXiAwZv1ihbNa18wWcz4M5HZ 4sPChywWPav6WRxYPJYs+cnkMenFIRaPL5c/swUwR3HZpKTmZJalFunbJXBlLLq9na1gq1jF pubyBsZlgl2MnBwSAiYSC450MELYYhIX7q1n62Lk4hASOMUosWT2N3YIZw2jRN/VW0AZDg5e AW2J3s+6IA0sAqoSz3bdZwGx2QTMJVo3bmQHsUUFgiXObdzGBmLzCghKnJz5BKxGREBD4u7D 18wgM5kFFjBKfHw9jxFkpjBQ8/KLkiA1QgLWEpv/tIMdxClgI7Hr+FpmEJtZwFbiwpzrLBC2 vMT2t3OYIeo1JSbfXMo8gVFwFpJ1s5C0zELSsoCReRWjcG5iZk56uZFealFmcnFxfp5eceom RmAYH9zyW3UH451zIocYpTlYlMR5rbfu8RcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOHnN kdpvlhZLFmef0LL2NLz+ZLqtv8ChmVGKqyUTfQ9oXDdJ28M5c3XzsczNziy8lkLV2e3bJ3RY HfzKZx0/P1bvs9a9fRUdQY8n8thePrIiKIchPd2kN2hd5ItzU6ULGXZFdTJsEjHccJI76ume XDHrooanprfVXBt3lWk6yweZVC82SNZUYinOSDTUYi4qTgQA0Dr96zECAAA= Cc: "draft-ietf-simple-chat.all@tools.ietf.org" , IESG IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-simple-chat-16 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, 17 Sep 2012 14:17:56 -0000 Hi Vincent: Thanks for your comments, please see my inline answers. On 11/09/2012 16:14, Vincent Roca wrote: > Hello, > > 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. > > > Since we already exchanged emails during the secdir review of version > -14 of this document, I'll be brief. > > > ** It is said: > > "If a participant wants to avoid eavesdropping, the participant's MSRP > client can send the messages over a TLS [RFC5246] transport > connection, as allowed by MSRP. It's up to the policy of the MSRP > switch if the messages are forwarded to the other participant's in > the chat room using TLS [RFC5246] transport." > > A participant cannot prevent eavesdropping if he does not control > the end-to-end use of TLS. Additionally, as discussed previously, > there are other benefits in the use of TLS, like preventing faked packet > injection, or on-the-fly corruption of messages. So I suggest to clarify a > bit: > > NEW: > > "If a participant wants to avoid security concerns on the path between > himself and the MSRP switch (e.g., eavesdropping, faked packet injection > or packet corruption), ..." > > Perfect. > ** About attacks with close but different nicknames: > I see that a new paragraph has been added to section 7.1 to discuss > this issue. That's excellent. However the security section does not > provide any pointer to this discussion, nor does it mention the problem. > The only aspect discussed is the reuse of nicknames which is a different > (but important) topic. So I suggest to add a paragraph: > > NEW: > > "Section 7.1.discusses the problem of similar but different > nicknames (e.g., thanks to the use of similar characters), > and chat rooms MAY provide a mechanism to mitigate confusable > nicknames." Excellent, paragraph added. > > > BTW, current I-D says that a chat room **MAY** provide such a mechanism. > Should we change it for SHOULD? Said differently, is there a good reason > for a chat room not to perform such verifications? If the answer is yes, > then we can keep MAY. Well, the problem is that having a MUST, SHOULD, or MAY to hyperspace has the same effect. My point is that if we have a clear and precise mechanism to mandate, we should mandate it. But not having a clear mechanism means that the change of a MAY for a SHOULD or a MUST has no effect in live deployments. BR, Miguel > > > Cheers, > > Vincent > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From kivinen@iki.fi Tue Sep 18 01:53:50 2012 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 440B121F878B for ; Tue, 18 Sep 2012 01:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYLUHCcNpuYQ for ; Tue, 18 Sep 2012 01:53:49 -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 50C9A21F876A for ; Tue, 18 Sep 2012 01:53:48 -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 q8I8rje4002453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2012 11:53:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q8I8riPw016336; Tue, 18 Sep 2012 11:53:44 +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: <20568.13975.955380.415363@fireball.kivinen.iki.fi> Date: Tue, 18 Sep 2012 11:53:43 +0300 From: Tero Kivinen To: Mark Nottingham In-Reply-To: References: <20550.1861.349381.646147@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 6 min Cc: draft-ietf-httpbis-p6-cache.all@tools.ietf.org, "ietf-http-wg@w3.org Group" , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-httpbis-p6-cache-20 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, 18 Sep 2012 08:53:50 -0000 Mark Nottingham writes: > Please see: > https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#security.considerations > On 05/09/2012, at 12:11 PM, Mark Nottingham wrote: > > On 04/09/2012, at 11:51 PM, Tero Kivinen wrote: > >> I think the security considerations section should list other attacks > >> too. Things that comes to my mind: > >> > >> - Cache poisoning attacks, i.e. attacker who can control the > >> www-server for a moment could pre-load cache with stuff that will > >> stay there for long time (as long as the cache control attributes > >> say). This includes negative result (404) caching. The current text for this seems to be ok (from the work in progress draft): Implementation flaws might allow attackers to insert content into a cache ("cache poisoning"), leading to compromise of clients that trust that content. Because of their nature, these attacks are difficult to mitigate. > >> - Cache caching stuff that was not supposed to be cached, like > >> authentication credentials in forms of cookies (the RFC6265 - "HTTP > >> State Management Mechanism" says that the presense of the cookies > >> does not preclude HTTP caches from storing and reusing a response). > >> This can be problem unless all applications using cookies actually > >> make sure that they set all pages as non-cacheable. Same for this: Likewise, implementation flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information (e.g., authentication credentials) that is thought to be private, exposing it to unauthorised parties. Note that the Set-Cookie response header [RFC6265] does not inhibit caching; a cacheable response with a Set-Cookie header can be (and often is) used to satisfy subsequent requests to caches. Servers who wish to control caching of these responses are encouraged to emit appropriate Cache-Control response headers. > >> - Cache might leak out information to other users of the cache who > >> fetched the page in the first time. This leaking can happen in > >> multiple ways (for example cookies, etc). Actually just timing can > >> tell that someone has already fetched the page to the cache, which > >> in some cases might be enough to leak information out. This was not added to security considerations at all. Was this intentional, or just left out by accident? Was there something unclear about this attack? -- kivinen@iki.fi From trammell@tik.ee.ethz.ch Tue Sep 18 07:53:17 2012 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 6F28C21F85E7; Tue, 18 Sep 2012 07:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW1CVC1bSp7D; Tue, 18 Sep 2012 07:53:16 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8787021F847F; Tue, 18 Sep 2012 07:53:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D2ABAD930D; Tue, 18 Sep 2012 16:53:15 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ABoN7P-ez3hY; Tue, 18 Sep 2012 16:53:15 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A27B1D9309; Tue, 18 Sep 2012 16:53:15 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <82F50D2E-18BC-42DF-9F5C-3B04FBB55180@checkpoint.com> Date: Tue, 18 Sep 2012 16:53:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8F7FACED-F39B-4E38-8828-981F87EE87AE@tik.ee.ethz.ch> References: <56C143E9-A517-4DDE-8CCC-3C4E1B0FF17F@checkpoint.com> <82F50D2E-18BC-42DF-9F5C-3B04FBB55180@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Tue, 18 Sep 2012 08:10:59 -0700 Cc: "draft-ietf-ipfix-ie-doctors.all@tools.ietf.org" , "iesg@ietf.org IESG" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-ipfix-ie-doctors-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: Tue, 18 Sep 2012 14:53:17 -0000 Hi, Yoav, Many thanks for the review (and the summary, which did indeed make it = easier to read)... I believe that revision -04 of the document addresses = these. Best regards, Brian On Jul 12, 2012, at 7:50 AM, Yoav Nir wrote: > Reading my own review again, I think it's missing a summary. >=20 > The draft does a good job of describing the need to review new = information elements for the security implications of sending them in = IPFIX. I'm missing two things: >=20 > 1. A list of security and privacy issues to consider (PII, actual data = leakage, traffic flow data) > 2. A clear statement that the IE doctors need to make these = considerations. That would be clearer if the security stuff (that is = part of the review process) was not in the "Security Considerations" = section, but could be made clear with a clarifying sentence. >=20 > Yoav >=20 > On Jul 11, 2012, at 2:27 PM, Yoav Nir wrote: >=20 >> Hi >>=20 >> I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >>=20 >> The document defines the criteria by which the "Information Element = Doctors" - experts to be appointed by the IESG - should evaluate = requests for assignment in the IANA registry for IPFIX information = elements. The registry has the "expert review" procedure, and these IE = doctors are the designated experts.=20 >>=20 >> The target audience for this document are two groups: the IE doctors = themselves, and the people who request assignments in the registry. The = document itself does not define any new protocol or information = elements. >>=20 >> The documents has a lot of advice about meaningful names, about = avoiding having >1 IEs with the same or similar semantics, and what = registry applications should look like. >>=20 >> The Security Considerations section is used in a surprising way. It = does not specify how to securely implement this document (as this = document specifies no protocol), but it specifies what to consider when = evaluating a request for assignment. This is important information, and = the section is well-written. IMO there are a few issues with it: >>=20 >> - The section says that you should "not give a potential attacker too = much information". It would be better to explicitly list the kinds of = threats that leaking too much information may lead to: breach of = privacy, vulnerability to traffic analysis, and leaking actual data. >>=20 >> - The section also talks about what should be included in the = Internet Draft that specifies the new information element. That I-D = would have its own security considerations sections, which would be = reviewed in due course, but writing an I-D is not required. Section 9 = says that "When a new application is complex enough to require = additional clarification or specification as to the use of the defined = Information Elements, this may be given in an Internet-Draft." This = language is not strong enough to make anything with potential security = concerns go though the I-D route. IEs may still be submitted directly to = IANA, with the security concerns only mentioned in the IE description.=20= >>=20 >> I think this document should explicitly state that it is part of the = task of IE doctors to consider the security aspects of new IEs, as well = as to give guidelines about what they should look for. >>=20 >> Yoav Nir >>=20 From new-work-bounces@ietf.org Tue Sep 18 09:13:16 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3054321E80E7; Tue, 18 Sep 2012 09:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1347984796; bh=ZngJWjLq4bk0hG0gKXq+BBg6+1JMt7i5zNGJ7dvhN4s=; 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=CcBpF5o5p+qk4S8FKWOgkoqvpZse+G2Ewni4nA7Ab9drWWHIMy1elzEswhb47y7+Z +/90JxcnPg6Arq0RGgHdmmnQj2M3Wtku3l2AmeYRbYbsSLVgL4kWtZeo63QKfPELed fIPR4rhVYGg5ZKKALCh1FTU0vAd2M8q6gcEI7NDw= 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 B775821E80E8; Tue, 18 Sep 2012 09:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWX-zaXbdNmc; Tue, 18 Sep 2012 09:13:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95EF21E80E5; Tue, 18 Sep 2012 09:13:13 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120918161313.20374.9674.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2012 09:13:13 -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: Tue, 18 Sep 2012 09:20:06 -0700 Subject: [secdir] [new-work] WG Review: Hypertext Transfer Protocol Bis (httpbis) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:13:16 -0000 The Hypertext Transfer Protocol Bis (httpbis) working group in the Applications Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2012-09-25. Hypertext Transfer Protocol Bis (httpbis) ------------------------------------------------ Current Status: Active Working Group Chairs: Mark Nottingham Assigned Area Director: Barry Leiba Mailing list Address: ietf-http-wg@w3.org To Subscribe: ietf-http-wg-request@w3.org Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Charter of Working Group: This Working Group is charged with maintaining and developing the "core" specifications for HTTP. The Working Group's specification deliverables are: * A document (or set of documents) that is suitable to supersede RFC 2616 as the definition of HTTP/1.1 and move RFC 2817 to Historic status * A document cataloguing the security properties of HTTP/1.1 * A document (or set of documents) that specifies HTTP/2.0, an improved binding of HTTP's semantics to an underlying transport. HTTP/1.1 -------- HTTP/1.1 is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications It will also incorporate the generic authentication framework from RFC 2617, without obsoleting or updating that specification's definition of the Basic and Digest schemes. Finally, it will incorporate relevant portions of RFC 2817 (in particular, the CONNECT method and advice on the use of Upgrade), so that that specification can be moved to Historic status. In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments HTTP/2.0 -------- There is emerging implementation experience and interest in a protocol that retains the semantics of HTTP without the legacy of HTTP/1.x message framing and syntax, which have been identified as hampering performance and encouraging misuse of the underlying transport. The Working Group will produce a specification of a new expression of HTTP's current semantics in ordered, bi-directional streams. As with HTTP/1.x, the primary target transport is TCP, but it should be possible to use other transports. Work will begin using draft-mbelshe-httpbis-spdy-00 as a starting point; proposals are to be expressed in terms of changes to that document. Note that consensus is required both for changes to the document and anything that remains in the document. As part of that work, the following issues are explicitly called out for discussion: * A negotiation mechanism that is capable of not only choosing between HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other transports (for example). * Header compression (which may encompass header encoding or tokenisation) * Server push (which may encompass pull or other techniques) It is expected that HTTP/2.0 will: * Substantially and measurably improve end-user perceived latency in most cases, over HTTP/1.1 using TCP. * Address the "head of line blocking" problem in HTTP. * Not require multiple connections to a server to enable parallelism, thus improving its use of TCP, especially regarding congestion control. * Retain the semantics of HTTP/1.1, leveraging existing documentation (see above), including (but not limited to) HTTP methods, status codes, URIs, and where appropriate, header fields. * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in intermediaries (both 2->1 and 1->2). * Clearly identify any new extensibility points and policy for their appropriate use. The resulting specification(s) are expected to meet these goals for common existing deployments of HTTP; in particular, Web browsing (desktop and mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of scales), and intermediation (by proxies, corporate firewalls, "reverse" proxies and Content Delivery Networks). Likewise, current and future semantic extensions to HTTP/1.x (e.g., headers, methods, status codes, cache directives) should be supported in the new protocol. Note that this does not include uses of HTTP where non-specified behaviours are relied upon (e.g., connection state such as timeouts or client affinity, and "interception" proxies); these uses may or may not be enabled by the final product. Explicitly out-of-scope items include: * Specifying the use of alternate transport-layer protocols. Note that it is expected that the Working Group will work with the TLS working group to define how the protocol is used with the TLS Protocol. * Specifying how the HTTP protocol is to be used or presented in a specific use case (e.g., in Web browsers). The Working Group will coordinate this item with: * The TLS Working Group, regarding use of TLS. * The Transport Area, regarding impact on and interaction with transport protocols. * The HYBI Working Group, regarding the possible future extension of HTTP/2.0 to carry WebSockets semantics. The Working Group will give priority to HTTP/1.1 work until that work is complete. Other HTTP-Related Work ----------------------- The Working Group may define additional extensions to HTTP as work items, provided that: * The Working Group Chairs judge that there is consensus to take on the item and believe that it will not interfere with the work described above, and * The Area Directors approve the addition and add corresponding milestones. Additionally, the Working Group will not start work on any extensions that are specific to HTTP/2.0 until that work is completed. Goals and Milestones Done First HTTP/1.1 Revision Internet Draft Done First HTTP Security Properties Internet Draft Done Call for Proposals for HTTP/2.0 Sep 2012 Working Group Last Call for HTTP/1.1 Revision Oct 2012 Working Group Last Call for HTTP Security Properties Oct 2012 First WG draft of HTTP/2.0, based upon draft-mbelshe-httpbis-spdy-00 Nov 2012 Submit HTTP/1.1 Revision to IESG for consideration as a Proposed Standard Nov 2012 Submit HTTP Security Properties to IESG for consideration as Informational RFC Apr 2014 Working Group Last call for HTTP/2.0 Nov 2014 Submit HTTP/2.0 to IESG for consideration as a Proposed Standard Milestones: Done - First HTTP/1.1 Revision Internet Draft Done - First HTTP Security Properties Internet Draft Mar 2012 - Working Group Last Call for HTTP/1.1 Revision Mar 2012 - Call for Proposals for HTTP/2.0 Jun 2012 - Working Group Last Call for HTTP Security Properties Jul 2012 - Submit HTTP/1.1 Revision to IESG for consideration as a Proposed Standard Jul 2012 - Submit HTTP Security Properties to IESG for consideration as Informational RFC Aug 2012 - Re-charter to work on HTTP/2.0 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From mnot@mnot.net Tue Sep 18 13:19:31 2012 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 23ECD21E8042 for ; Tue, 18 Sep 2012 13:19: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuTo4F6bW2mV for ; Tue, 18 Sep 2012 13:19:30 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF1B21E8040 for ; Tue, 18 Sep 2012 13:19:30 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D916F22E25C; Tue, 18 Sep 2012 16:19:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <20568.13975.955380.415363@fireball.kivinen.iki.fi> Date: Tue, 18 Sep 2012 13:19:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5968E08E-1A55-440E-9A3C-1477A5832C50@mnot.net> References: <20550.1861.349381.646147@fireball.kivinen.iki.fi> <20568.13975.955380.415363@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1486) Cc: draft-ietf-httpbis-p6-cache.all@tools.ietf.org, "ietf-http-wg@w3.org Group" , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-httpbis-p6-cache-20 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, 18 Sep 2012 20:19:31 -0000 On 18/09/2012, at 1:53 AM, Tero Kivinen wrote: > Mark Nottingham writes: >> Please see: >> = https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cac= he.html#security.considerations >> On 05/09/2012, at 12:11 PM, Mark Nottingham wrote: >>> On 04/09/2012, at 11:51 PM, Tero Kivinen wrote: >>>> I think the security considerations section should list other = attacks >>>> too. Things that comes to my mind: >>>>=20 >>>> - Cache poisoning attacks, i.e. attacker who can control the >>>> www-server for a moment could pre-load cache with stuff that will >>>> stay there for long time (as long as the cache control attributes >>>> say). This includes negative result (404) caching. >=20 > The current text for this seems to be ok (from the work in progress > draft): >=20 > Implementation flaws might allow attackers to insert content > into a cache ("cache poisoning"), leading to compromise of > clients that trust that content. Because of their nature, > these attacks are difficult to mitigate. >=20 >>>> - Cache caching stuff that was not supposed to be cached, like >>>> authentication credentials in forms of cookies (the RFC6265 - "HTTP >>>> State Management Mechanism" says that the presense of the cookies >>>> does not preclude HTTP caches from storing and reusing a response). >>>> This can be problem unless all applications using cookies actually >>>> make sure that they set all pages as non-cacheable. >=20 > Same for this: >=20 > Likewise, implementation flaws (as well as misunderstanding of > cache operation) might lead to caching of sensitive > information (e.g., authentication credentials) that is thought > to be private, exposing it to unauthorised parties. >=20 > Note that the Set-Cookie response header [RFC6265] does not > inhibit caching; a cacheable response with a Set-Cookie header > can be (and often is) used to satisfy subsequent requests to > caches. Servers who wish to control caching of these responses > are encouraged to emit appropriate Cache-Control response > headers. >=20 >>>> - Cache might leak out information to other users of the cache who >>>> fetched the page in the first time. This leaking can happen in >>>> multiple ways (for example cookies, etc). Actually just timing can >>>> tell that someone has already fetched the page to the cache, which >>>> in some cases might be enough to leak information out. >=20 > This was not added to security considerations at all. Was this > intentional, or just left out by accident? Was there something unclear > about this attack?=20 I didn't see how it was materially different than the previous one = (unintentional caching of sensitive information). Could you explain how = it is? Regards, -- Mark Nottingham http://www.mnot.net/ From magnusn@gmail.com Wed Sep 19 22:07:24 2012 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 36A7421F862A; Wed, 19 Sep 2012 22:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hu7+lINUxxH; Wed, 19 Sep 2012 22:07:23 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8454621F8643; Wed, 19 Sep 2012 22:07:23 -0700 (PDT) Received: by qaec10 with SMTP id c10so61838qae.10 for ; Wed, 19 Sep 2012 22:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PrmgSvo+K9u2VaozEnXICRt9GYkBF02Zlv/ClstcBRs=; b=nVmMxNCo7rcLt7t2iyaBQqZMRmFN2hXffRLpDRrsDlhUfIoD78stbuyJmgR3J+Hsp7 ggt2QD1xsTdExHeVLWUdZrWAsYlFs6kOGl1FvwzF9YQmdUDcpiivFIqOHlZqWj1NaENU eFlHgsa9jYzMVENHoxrlJeCN2SKD/c/3VwS0KDsdoSgAscHVImvib2Bo4w7GoWbeLilM YA7h2cGnrzxNLcn5M3ryHG0t7zugQA/cYTECgV5GfR+l0FIFO96+5chtexZNcGFYZo5y qQI8kpW1MdDOBUGcYg8XkOM88lrE2mp+UJ5bFyTXoowS/ThIrQtCfejl7KaOTuNNBgoE cCbg== MIME-Version: 1.0 Received: by 10.224.39.147 with SMTP id g19mr2211098qae.46.1348117642837; Wed, 19 Sep 2012 22:07:22 -0700 (PDT) Received: by 10.49.119.73 with HTTP; Wed, 19 Sep 2012 22:07:22 -0700 (PDT) Date: Wed, 19 Sep 2012 22:07:22 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, draft-ietf-eai-simpledowngrade@tools.ietf.org Content-Type: multipart/alternative; boundary=20cf306f74d6377f2904ca1b1979 Subject: [secdir] Secdir review of draft-ietf-eai-simpledowngrade-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: Thu, 20 Sep 2012 05:07:24 -0000 --20cf306f74d6377f2904ca1b1979 Content-Type: text/plain; charset=ISO-8859-1 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 standards-track document suggests a method for internationalized mail servers to "downgrade" internationalized messages to standard/basic mail clients. The document is clearly written and the Security Consideration section does discuss the potential issues I could think of. I have no further comments. -- Magnus --20cf306f74d6377f2904ca1b1979 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the sec= urity directorate's
ongoing effort to review all IETF documents being processed by the
IESG. =A0These 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 standards-track document suggests a method for internationalized mail = servers to "downgrade" internationalized messages to standard/bas= ic mail clients.
=A0
The document is clearly written and the Security Consideration section does= discuss the potential issues I could think of. I have no further comments.=

-- Magnus
--20cf306f74d6377f2904ca1b1979-- From kivinen@iki.fi Thu Sep 20 05:23:25 2012 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 781C421F878B for ; Thu, 20 Sep 2012 05:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjsVO5TjSi80 for ; Thu, 20 Sep 2012 05:23:24 -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 23A4921F847C for ; Thu, 20 Sep 2012 05:23:23 -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 q8KCNEjD024182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Sep 2012 15:23:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q8KCNCc8008574; Thu, 20 Sep 2012 15:23:12 +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: <20571.2736.108137.777603@fireball.kivinen.iki.fi> Date: Thu, 20 Sep 2012 15:23:12 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 2 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, 20 Sep 2012 12:23:25 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Glen Zorn is next in the rotation. For telechat 2012-09-27 Reviewer LC end Draft Catherine Meadows T 2012-09-05 draft-ietf-isis-mi-06 Eric Rescorla T 2012-07-25 draft-ietf-websec-strict-transport-sec-12 For telechat 2012-10-11 Alexey Melnikov T 2012-08-13 draft-ietf-storm-iscsi-cons-06 David Waltermire T 2012-10-02 draft-ietf-6man-udpchecksums-04 Sam Weiler T 2012-10-02 draft-ietf-6man-udpzero-06 Last calls and special requests: Dave Cridland 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-11 Phillip Hallam-Baker 2012-10-03 draft-kumaki-murai-l3vpn-rsvp-te-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-02 Kathleen Moriarty 2012-09-18 draft-ietf-dime-rfc4005bis-11 Russ Mundy 2012-09-20 draft-ietf-eai-5738bis-09 Sandy Murphy 2012-09-20 draft-ietf-eai-popimap-downgrade-07 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-09 Vincent Roca 2012-09-24 draft-ietf-dime-erp-12 Joe Salowey 2012-09-26 draft-ietf-krb-wg-camellia-cts-01 Yaron Sheffer 2012-09-26 draft-ietf-krb-wg-kerberos-referrals-14 Ondrej Sury 2012-09-26 draft-ietf-nea-asokan-01 Tina TSOU 2012-09-25 draft-ietf-v6ops-ivi-icmp-address-05 Carl Wallace 2012-10-03 draft-ietf-6man-dad-proxy-04 Brian Weis 2012-10-01 draft-ietf-fecframe-ldpc-02 Klaas Wierenga 2012-10-01 draft-ietf-fecframe-pseudo-cdp-04 Nico Williams - draft-ietf-httpbis-p5-range-20 Nico Williams 2012-10-01 draft-ietf-sidr-pfx-validate-09 Tom Yu 2012-10-12 draft-snell-http-prefer-14 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-08-14 draft-ietf-mptcp-api-05 -- kivinen@iki.fi From stephen.farrell@cs.tcd.ie Thu Sep 20 05:50:33 2012 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 8CD5421F8806 for ; Thu, 20 Sep 2012 05:50: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6hNY63DjsfI for ; Thu, 20 Sep 2012 05:50:33 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id CFDB721F8805 for ; Thu, 20 Sep 2012 05:50:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 20182171476; Thu, 20 Sep 2012 13:50:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1348145431; bh=XFUtknEbIFKtVmWyjPS8e2+8 mVIWP5qVHXMC8O9p5dY=; b=dh22JT7muvYC1XAAXxH6w5U9Pdg2MpG3Q2evZ1mX dGp2OMUYHeobGtVqVfPoGisrF4/rjVtZskY3cI96rY3eTcycSgMBaxxKO8CQtuKW TYnUgCm5NhKIeUB6LCbwoEtU2Rx28Iv/3LWzsroLC7EaVUY3YF3fyHB12HYHwv+O 0b4a/5c5ekgAM2bTgkR8SzBOq6AgXRMY9Dcal8C67unK95VNnSgPX1//JwMEM26W 5jmmNy7mBQ3zWYzqMDa6I4t5XHDfLl3ihZAj375jbQFUMha58WXFSHmk0FFHejLu bgfDFX8movJdEiAl3kRPubyi9eGhNidt6PXIc7udovOSGQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id i-JEXpZdul8G; Thu, 20 Sep 2012 13:50:31 +0100 (IST) Received: from [192.6.10.171] (bri-event-72.hpl.hp.com [192.6.10.171]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3F8FE171473; Thu, 20 Sep 2012 13:50:30 +0100 (IST) Message-ID: <505B1115.7060204@cs.tcd.ie> Date: Thu, 20 Sep 2012 13:50:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "secdir@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Murray S. Kucherawy" Subject: [secdir] WEIRDS looking for help 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, 20 Sep 2012 12:50:33 -0000 Hi, We've gotten a request for a bit of security co-author help from the WEIRDS WG, [1] who're doing a webby whois. They'd love to get someone with some web security clue who'd be willing and able to help write a document. Please let Murray (WG co-chair) know if you're interested and he can provide more information. Same applies if you can't do it, but can provide Murray with the name of a potential victim^H^H^H^H^H^Hvolunteer. Thanks, S. [1] http://tools.ietf.org/wg/weirds/ From hallam@gmail.com Fri Sep 21 10:19:19 2012 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 6330521F8707 for ; Fri, 21 Sep 2012 10:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.89 X-Spam-Level: X-Spam-Status: No, score=-3.89 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvk6r-O3AZet for ; Fri, 21 Sep 2012 10:19:18 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5FB21F86FF for ; Fri, 21 Sep 2012 10:19:18 -0700 (PDT) Received: by oagn5 with SMTP id n5so3362471oag.31 for ; Fri, 21 Sep 2012 10:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=53jnykOMI0oIaOoZEOG6ibEFfn+pRVv9PkfXoUcWQ7E=; b=rA91hjRV+Dz9y778/B3aWlXxdYckL2vBKhE+35kaCFvIIMeS4NwnTDYKHOpmLZpCHG WwqIygRqfktON2kKbhDJm5RFwH1iYXxmRY5m1+mXp25NX0XlL2pMWxkc6DB0u76mtUn/ 9tKEmjF55XvfgzvmeH6ETbEx+59D6Th6fC41LuW5hbA+MYcwAwouz6nlVWI5+zMxNbw4 mzszAPjHcjik/3CXu0CV4xdh4lbNCVt7iMsYdHmURASjepn9mZIVRRDzlvnBBwkZkec4 LGG0VzN7GysrbiRl1C/znrc2Q9ANj0BYoS0iFJmlT81BfIw6soJ2yj2OM/hz9ziNBK3T pESw== MIME-Version: 1.0 Received: by 10.60.170.9 with SMTP id ai9mr1435942oec.36.1348247957803; Fri, 21 Sep 2012 10:19:17 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Fri, 21 Sep 2012 10:19:17 -0700 (PDT) Date: Fri, 21 Sep 2012 13:19:17 -0400 Message-ID: From: Phillip Hallam-Baker To: secdir@ietf.org, ke-kumaki@kddi.com, murai@fnsc.co.jp, dean.cheng@huawei.com, satoru.matsushima@tm.softbank.co.jp, pe-jiang@kddi.com, draft-kumaki-murai-l3vpn-rsvp-te@tools.ietf.org Content-Type: multipart/alternative; boundary=bcaec54a3e029812f404ca397082 Subject: [secdir] SECDIR Review of draft-kumaki-murai-l3vpn-rsvp-te/ 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, 21 Sep 2012 17:19:19 -0000 --bcaec54a3e029812f404ca397082 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The specification describes a mechanism for exchanging RSVP routing information to support multi-site VPNs in the case that a connection supports multiple VPNs. The document lacks a substantive security considerations section, instead referencing RFC3209 for security considerations. I do not think this is appropriate since that document was published in 2001 when security considerations were still insubstantial and in the case ofd RFC 3209 consist of a reference to RFC 2205 which is also pro-forma. rfc6437 has a much better presentation of the issues involved. While people tend to use Security Considerations to list the problems with a protocol there is no real reason this should be the case. The SC should address all the considerations, positive and negative Here we have a model where the VPN is providing authentication and integrity checking end to end. That only leaves service and traffic analysis as concerns with respect to routing level attacks. But there should be discussion of the possibility that a member of the VPN network might introduce malicious routing data to redirect traffic. Either to do traffic analysis or to perform a DoS attack. While this is not something members of a VPN are likely to do intentionally, it is something an attacker might do if they own one site. The risk here is that when you join a VPN club you may be exposing yourself to the vulnerabilities/exploits of the weakest member of the club. And they may be able to clobber you through them. So large scale systems might well have rules about auditing and security policies they would need in place. They should also sanity check the routes advertised. Using a VPN does have a penalty as well as it means that the packet contents are now opaque to the good guys as well as the bad. Port filtering is no longer possible, spam filtering is hard and so on. -- Website: http://hallambaker.com/ --bcaec54a3e029812f404ca397082 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have reviewed this= document as part of the security directorate's
ongoing effort to re= view all IETF documents being processed by the
IESG. =A0These comme= nts were written primarily for the benefit of the
security area direct= ors. Document editors and WG chairs should treat
these comments just = like any other last call comments.


The spec= ification describes a mechanism for exchanging RSVP routing information to = support multi-site VPNs in the case that a connection supports multiple VPN= s.

The document lacks a = substantive security considerations section, instead referencing RFC3209 fo= r security considerations. I do not think this is appropriate since that do= cument was published in 2001 when security considerations were still insubs= tantial and in the case ofd RFC 3209 consist of a reference to RFC 2205 whi= ch is also pro-forma.

rfc6437 has a much be= tter presentation of the issues involved.

While = people tend to use Security Considerations to list the problems with a prot= ocol there is no real reason this should be the case. The SC should address= all the considerations, positive and negative

Here we have a model = where the VPN is providing authentication and integrity checking end to end= . That only leaves service and traffic analysis as concerns with respect to= routing level attacks. But there should be discussion of the possibility t= hat a member of the VPN network might introduce malicious routing data to r= edirect traffic. Either to do traffic analysis or to perform a DoS attack.= =A0

While this is not som= ething members of a VPN are likely to do intentionally, it is something an = attacker might do if they own one site. The risk here is that when you join= a VPN club you may be exposing yourself to the vulnerabilities/exploits of= the weakest member of the club. And they may be able to clobber you throug= h them. So large scale systems might well have rules about auditing and sec= urity policies they would need in place. They should also sanity check the = routes advertised.

Using a VPN does have= a penalty as well as it means that the packet contents are now opaque to t= he good guys as well as the bad. Port filtering is no longer possible, spam= filtering is hard and so on.

<= /font>

--
Website: http://hallambaker.com/

--bcaec54a3e029812f404ca397082-- From kathleen.moriarty@emc.com Fri Sep 21 15:28:57 2012 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 94A6121E808F; Fri, 21 Sep 2012 15:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWf3Ik+H0bVl; Fri, 21 Sep 2012 15:28:57 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E244E21E803A; Fri, 21 Sep 2012 15:28:56 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8LMSnEc022177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Sep 2012 18:28:53 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 21 Sep 2012 18:28:32 -0400 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8LMSUXU027132; Fri, 21 Sep 2012 18:28:31 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Fri, 21 Sep 2012 18:28:30 -0400 From: "Moriarty, Kathleen" To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-dime-rfc4005bis.all@tools.ietf.org" , "glenzorn@gmail.com" Date: Fri, 21 Sep 2012 18:25:15 -0400 Thread-Topic: SecDir review of draft-ietf-dime-rfc4005bis-11 Thread-Index: AQHNmEf5ogx3Rp/zS0qV+lA4m6/dcg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [secdir] SecDir review of draft-ietf-dime-rfc4005bis-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, 21 Sep 2012 22:28:57 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary:=20 This document describes the extension of Diameter for the NAS application.= =20 As such, should the abstract be updated to ensure the reader is aware of th= e scope limitation in the first sentence? In reading through the draft, I agree with the summary in the Security cons= iderations section. This document is limited in scope, it extends the defi= nition and doesn't go into the details of the protocol and the associated s= ecurity considerations. The base protocol is defined in RFC3588bis along wi= th the security requirements. =20 I think a reference to the authentication security requirements/considerati= ons defined in ietf-dime-rfc3588bis would be very helpful so that the reade= r knows the extent of possible security issues and solutions since they go = beyond what is described in this document. Having the reference either in = Sections 4.3.1 and 4.5.6 or the Security Considerations section would ensur= e the reader is aware this is addressed elsewhere. Some issues are address= ed in these sections, but they do not go as far as the base protocol and th= ere could be issues as this document just relies on session encryption to p= rotect plaintext passwords, etc. The base protocol describes other mechani= sms and risks. Editorial nit: Section 1.1, first sentence of last paragraph Change from: "There are many other many miscellaneous" To:=20 "There are many other miscellaneous"= From zzhang@juniper.net Wed Sep 19 12:42:48 2012 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 124DF21E8034; Wed, 19 Sep 2012 12:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8ikv68iLmFd; Wed, 19 Sep 2012 12:42:47 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8E021F8468; Wed, 19 Sep 2012 12:42:47 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUFogNjBRqthRkUb05X/sAQQt/4d1L7b1@postini.com; Wed, 19 Sep 2012 12:42:47 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Sep 2012 12:41:08 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 19 Sep 2012 12:41:08 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.187) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Sep 2012 12:42:36 -0700 Received: from mail33-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 19:41:08 +0000 Received: from mail33-co1 (localhost [127.0.0.1]) by mail33-co1-R.bigfish.com (Postfix) with ESMTP id 05315400204; Wed, 19 Sep 2012 19:41:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -30 X-BigFish: PS-30(zz9371I103dK1521I542M1432Id6f1izz1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received: from mail33-co1 (localhost.localdomain [127.0.0.1]) by mail33-co1 (MessageSwitch) id 1348083665464325_17646; Wed, 19 Sep 2012 19:41:05 +0000 (UTC) Received: from CO1EHSMHS027.bigfish.com (unknown [10.243.78.225]) by mail33-co1.bigfish.com (Postfix) with ESMTP id 6E69650004C; Wed, 19 Sep 2012 19:41:05 +0000 (UTC) Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by CO1EHSMHS027.bigfish.com (10.243.66.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 19:41:04 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.3.218]) by BY2PRD0510HT005.namprd05.prod.outlook.com ([10.255.84.40]) with mapi id 14.16.0190.008; Wed, 19 Sep 2012 19:41:02 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Murphy, Sandra" , "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: secdir review of draft-ietf-ospf-hybrid-bcast-and-p2mp Thread-Index: Ac17uYA1ZqB188w9QjGy7M9E8oHAGAauGo0g Date: Wed, 19 Sep 2012 19:41:01 +0000 Message-ID: <0BF0FCC78340F147BE76A6F5762318A8022E77@BY2PRD0510MB389.namprd05.prod.outlook.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6014F@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F6014F@Hermes.columbia.ads.sparta.com> 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%SPARTA.COM$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 X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-Mailman-Approved-At: Sat, 22 Sep 2012 11:37:22 -0700 Cc: "draft-ietf-ospf-hybrid-bcast-and-p2mp.all@tools.ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-ospf-hybrid-bcast-and-p2mp 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, 19 Sep 2012 19:42:48 -0000 Sandra, Sorry for the late response. I've been pulled into other things. > -----Original Message----- > From: Murphy, Sandra [mailto:Sandra.Murphy@sparta.com] > Sent: Thursday, August 16, 2012 12:11 PM > To: secdir@ietf.org; iesg@ietf.org > Cc: draft-ietf-ospf-hybrid-bcast-and-p2mp.all@tools.ietf.org > Subject: secdir review of draft-ietf-ospf-hybrid-bcast-and-p2mp >=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 provides a new way of communicating connectivity on a > shared network. Currently there are two methods, one used for > broadcast/NBMA nets and one used for point-multipoint networks. The > broadcast net case elects a DR that then floods a network LSA noting > all routers on the net so that LSA database synchronization uses the DR. > The p2mp case establishes links from each router to each other router > on the p2mp network. The broadcast/NBMA case does not permit different > metrics for the links to each router on the broadcast network. The > p2mp case allows different metrics for the links between adjacent > routers on the p2mp network. >=20 > This draft introduces a hybrid case for broadcast/NBMA networks - using > the neighbor discovery and LSA database synchronization of the > broadcast/NBMA case but the establishment of links with different > metrics of the p2mp case. The draft specifies changes to LSAs and > processing that would produce this hybrid behavior. >=20 > The security considerations section says there are no new security > vulnerabilities that result. OSPF authenticates all routers on a > shared network (whether broadcast/NBMA or p2mp) with a single shared > key, and this mechanism's changes share that authentication. OSPF does > not protect against bad behavior by legitimate participants so no > misbehavior possible with these changes would create new > vulnerabilities. >=20 > The draft introduces changes to the LSAs and behavior but does not > explain why the changes are needed or what their intent is. This makes > it very hard to understand or analyze what the effect would be. I was > able to figure out why the a router LSA type 1 link is introduced to a > neighbor that is also mentioned by the DR (that's the combination of > the broadcast discovery feature into the p2mp links part of the hybrid). > But I was not able to figure out other changes, such as why it was > necessary to introduce type 3 stub network links for the router's > subnet. Perhaps the authors expect that readers will be so intimately > familiar with OSPF design that the motivation for each change will be > obvious. But it does make readers work hard. Indeed the assumption is that readers are familiar with base OSPF protocol.= The LSA behavior is basically to follow p2mp model. >=20 > Section 5 considers cases where some routers on a broadcast network > follow the hybrid behavior and other follow the broadcast/NBMA behavior. > OSPF works on the assumption that all routers share the same dataset > and therefore each will compute shortest paths that will not introduce > loops. In this case, not all routers will be working from the same > dataset of links, raising concern about loops. Section 5 (briefly) > says that in this case there would be "no traffic traversing certain > pairs of routers" but no loops. I can understand that enough to > believe it. But I am not as confident that a router that produces > both the network LSA and a router LSA with the p2mp links could not > confuse the situation sufficiently to produce loops. I wonder if the > authors have considered that case. I'm sorry that I was not able to > devote the time to the shortest path computation to resolve this lack > of confidence for myself. We have considered this case and there should be no problem.=20 >=20 > NOTE: this concern would be a case of mis-behavior by a valid > participant and OSPF is well understood to be unprotected from such > mis-behavior. This is NOT a newly introduced security concern. >=20 > section 4.5 says "the DR MUST NOT generate a network LSA for the > interface." OSPF's specs in general do not recommend reporting errors, > or I would suggest a new error report if a network LSA were spotted on > an interface that was designated as hybrid. Indeed. I guess I'm off the hook :-) I've taken care of the two editorial comments below. Thanks! Jeffrey >=20 > --Sandy >=20 > Nits: >=20 > page 3: >=20 > network. Further, it mandates establishment of adjacencies to all > all configured or discovered neighbors on the network. >=20 > "all all" -> "all" >=20 > page 8 >=20 > o If a router is in state DROther on the interface, it MUST > consider > an adjacency to non-DR and non-BDR neighbors as reestablished > when > the neighbor state reaches 2-Way. >=20 > I think there is a separate adjacency for each neighbor, not one for > all neighbors, so I think this should be something like: >=20 > o If a router is in state DROther on the interface, it MUST > consider > an adjacency to a non-DR or non-BDR neighbor as reestablished > when > the neighbor state reaches 2-Way. >=20 >=20 >=20 >=20 From yaronf.ietf@gmail.com Sun Sep 23 13:46:17 2012 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 3684621F851A; Sun, 23 Sep 2012 13:46:17 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbnbluyKNrdG; Sun, 23 Sep 2012 13:46:16 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 23B7C21F8518; Sun, 23 Sep 2012 13:46:15 -0700 (PDT) Received: by bkty12 with SMTP id y12so2525986bkt.31 for ; Sun, 23 Sep 2012 13:46:15 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=I3+BTBiJZr5aoWl+1VNWAuYU5/KvhXEwaRcVqS5x2dU=; b=c1JZhl+34zgoAvPLzJc5fqfQUgsIH7VhANTkS91xjl/B+S2i4h2XBr6crbftQG7I0D P5f5rWyNNMd+E4PUhBj8aBmez4fZVk4z1edymFQCngUn87gq2o9AgcY4kVqzDouaIrLy BanCTmHmHRVbsYknsh6oSqTuHVkPf1tZHKhWLvyUtnolO0jRUIxDqI30+P4IkiTwrSPo fwNjnQ8sWs6QavAK2NhI7NR5lrKQF103TEajXmVLElaYhNutCXSj3rSCLtg/jdCcdB4j xEjqNv9Y3hE03GEOjYaoGP6Hf8CQFe0vIW3r+tLtZEAd20kHW3Yq3q3xRLnn03yHBQ5q xF2Q== Received: by 10.204.130.11 with SMTP id q11mr4036831bks.88.1348433175079; Sun, 23 Sep 2012 13:46:15 -0700 (PDT) Received: from [10.0.0.3] ([109.65.145.148]) by mx.google.com with ESMTPS id j24sm1946245bkv.0.2012.09.23.13.46.13 (version=SSLv3 cipher=OTHER); Sun, 23 Sep 2012 13:46:14 -0700 (PDT) Message-ID: <505F7514.8030908@gmail.com> Date: Sun, 23 Sep 2012 22:46:12 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-krb-wg-kerberos-referrals.all@tools.ietf.org, iesg@ietf.org References: <4FBFAE5F.8010305@gmail.com> In-Reply-To: <4FBFAE5F.8010305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-krb-wg-kerberos-referrals-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: Sun, 23 Sep 2012 20:46:17 -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 adds a "referral" mechanism to Kerberos, where a client (e.g. an end user) can use a generic enterprise-wide name, and have it mapped to one that is specific to its correct realm; similarly, a generic name can be used for a service, and the KDC will respond with the correct principal name (and realm) for the service. Summary It is obvious that the analysis in the document's Security Considerations is very thorough. Unfortunately I do not have the Kerberos expertise (which apparently requires knowledge of specific implementations' quirky behavior) to determine if all relevant cases were covered. A cursory reading of the Considerations is quite discouraging: several security mechanisms exist but they are not universally applied, some implementations do not even follow the base protocol etc. I can only hope that modern Kerberos implementations have improved in the 11 years since this protocol first got started. Details - Sec. 4: "trusted name service" is not well defined. In fact it can be construed as a euphemism for "enterprise-internal DNS", which is advised against earlier. - 4.1, last paragraph: is there no possibility to an "issuing realm" to "publish" ownership of some resources to the consuming realm, and thus effectively claim those resources? - 6. In the authorization ASN.1 snippet, what is the value of MAX? - 7, first paragraph: when the client sends the request to example.com, shouldn't it ensure first that it has a pre-existing (pre-configured) trust relationship with example.com? - 10: the last paragraph ("Accordingly") is a bit too vague and probably does not provide implementors with sufficient advice. - 10: overall it is not clear if this section also applies to caching of client referrals. - 11: surprise! FAST (which was an optional SHOULD in Sec. 6) is now a MUST! Even if it's just FAST negotiation that's a MUST, but FAST itself (or an equivalent) is just a SHOULD, this still doesn't make a lot of sense, and should at least be explained. - 11: this section defines a new structure, but only explains a few of its members. Please mention where all the other members are defined (RFC 4120?). By the way, key-expiration is said to be deprecated in RFC 4120, but what do I know. - General: the document is said to update RFC 4120. A short section with a summary of the specific updates would be very useful, so that implementors can find out if they need to change anything, even if they do NOT support the Referral functionality. (This is really a shortcoming of the IETF notion of "RFC X updates RFC Y.") - Appendix A: in "current implementation", do you mean post-Win 2003? Please clarify. - Appendix A: a reference to the MS documentation might be appropriate: http://msdn.microsoft.com/en-us/library/cc233855(v=prot.13).aspx Thanks, Yaron From glenzorn@gmail.com Mon Sep 24 01:10:22 2012 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 480A521F8540; Mon, 24 Sep 2012 01:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO4PgHNKTlOm; Mon, 24 Sep 2012 01:10:21 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5413A21F8543; Mon, 24 Sep 2012 01:10:20 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so1198527pbb.31 for ; Mon, 24 Sep 2012 01:10: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=jNKhBF1L8UGWd20NLhk1koARGrm9fmR4Y0K4edBFNlw=; b=IkLYi7DGTYNc41DDF/QqTxI7N+MkQCw4zowhfIEhM++L4UM4SJN/iehUGz+Db/X1wQ u7uF72TdW/Ktv384i8I3Ry12JVSBt+TPKpEPk+l32fspkp6I4dO5J1bGmqvK0Tx0wuGJ YhLcEdQHfp17FtUzGFN2FE7xSVgrhidW4SQdz6YaGMEjiVCGPKZwimNZV2qB6+ImlgK6 IrbMA8ov/hYF+dbLFLyMqBcIB5cRKRDCkg155ULrfVdkiS0rtUKflp+mFWRBoyzONiqM MaRM1Z5QGje5unsmROzE3aXoL3AxNZTPXiB6cx215AHermjHPc0hgbrF6uVknfxh5Zza Milw== Received: by 10.66.74.100 with SMTP id s4mr30638227pav.27.1348474219820; Mon, 24 Sep 2012 01:10:19 -0700 (PDT) Received: from [192.168.0.102] (ppp-58-11-133-109.revip2.asianet.co.th. [58.11.133.109]) by mx.google.com with ESMTPS id ho7sm9295503pbc.3.2012.09.24.01.10.16 (version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 01:10:19 -0700 (PDT) Message-ID: <50601567.3010008@gmail.com> Date: Mon, 24 Sep 2012 15:10:15 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: "Moriarty, Kathleen" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime mailing list , "iesg@ietf.org" , "draft-ietf-dime-rfc4005bis.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-dime-rfc4005bis-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, 24 Sep 2012 08:10:22 -0000 On 09/22/2012 05:25 AM, Moriarty, Kathleen wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: This document describes the extension of Diameter for the > NAS application. > > As such, should the abstract be updated to ensure the reader is aware > of the scope limitation in the first sentence? I don't understand: the first sentence of the introduction is virtually identical to the first sentence of Section 1. What do you want me to do? > > In reading through the draft, I agree with the summary in the > Security considerations section. This document is limited in scope, > it extends the definition and doesn't go into the details of the > protocol and the associated security considerations. The base > protocol is defined in RFC3588bis along with the security > requirements. > > I think a reference to the authentication security > requirements/considerations defined in ietf-dime-rfc3588bis would be > very helpful so that the reader knows the extent of possible security > issues and solutions since they go beyond what is described in this > document. Having the reference either in Sections 4.3.1 and 4.5.6 or > the Security Considerations section would ensure the reader is aware > this is addressed elsewhere. Since the reader must have read & understood RFC 3588bis to expect to be able to read & understand this doc (draft-ietf-dime-rfc3588bis is cited as a normative reference), presumably the reader is already aware of this. Some issues are addressed in these > sections, but they do not go as far as the base protocol and there > could be issues as this document just relies on session encryption to > protect plaintext passwords, etc. ?? > The base protocol describes other > mechanisms and risks. > > Editorial nit: Section 1.1, first sentence of last paragraph Change > from: "There are many other many miscellaneous" To: "There are many > other miscellaneous" Fixed, thanks! From turners@ieca.com Tue Sep 25 10:06:57 2012 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 335221F0CCC for ; Tue, 25 Sep 2012 10:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf+S+XZ0GkO4 for ; Tue, 25 Sep 2012 10:06:56 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [70.85.130.30]) by ietfa.amsl.com (Postfix) with ESMTP id 81B521F0CC6 for ; Tue, 25 Sep 2012 10:06:56 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 74D8720D30A8C; Tue, 25 Sep 2012 12:06:58 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 6734E20D30A6B for ; Tue, 25 Sep 2012 12:06:58 -0500 (CDT) Received: from [108.18.174.220] (port=49854 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TGYb1-0004Ha-IH; Tue, 25 Sep 2012 12:06:55 -0500 Message-ID: <5061E4AE.2030701@ieca.com> Date: Tue, 25 Sep 2012 13:06:54 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Yaron Sheffer , draft-ietf-krb-wg-kerberos-referrals.all@tools.ietf.org References: <4FBFAE5F.8010305@gmail.com> <505F7514.8030908@gmail.com> In-Reply-To: <505F7514.8030908@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:49854 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-krb-wg-kerberos-referrals-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: Tue, 25 Sep 2012 17:06:57 -0000 Did these ever make it to the krb-wg mailing list? spt On 9/23/12 4:46 PM, Yaron Sheffer 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 adds a "referral" mechanism to Kerberos, where a client > (e.g. an end user) can use a generic enterprise-wide name, and have it > mapped to one that is specific to its correct realm; similarly, a > generic name can be used for a service, and the KDC will respond with > the correct principal name (and realm) for the service. > > Summary > > It is obvious that the analysis in the document's Security > Considerations is very thorough. Unfortunately I do not have the > Kerberos expertise (which apparently requires knowledge of specific > implementations' quirky behavior) to determine if all relevant cases > were covered. > > A cursory reading of the Considerations is quite discouraging: several > security mechanisms exist but they are not universally applied, some > implementations do not even follow the base protocol etc. I can only > hope that modern Kerberos implementations have improved in the 11 years > since this protocol first got started. > > Details > > - Sec. 4: "trusted name service" is not well defined. In fact it can be > construed as a euphemism for "enterprise-internal DNS", which is advised > against earlier. > - 4.1, last paragraph: is there no possibility to an "issuing realm" to > "publish" ownership of some resources to the consuming realm, and thus > effectively claim those resources? > - 6. In the authorization ASN.1 snippet, what is the value of MAX? > - 7, first paragraph: when the client sends the request to example.com, > shouldn't it ensure first that it has a pre-existing (pre-configured) > trust relationship with example.com? > - 10: the last paragraph ("Accordingly") is a bit too vague and probably > does not provide implementors with sufficient advice. > - 10: overall it is not clear if this section also applies to caching of > client referrals. > - 11: surprise! FAST (which was an optional SHOULD in Sec. 6) is now a > MUST! Even if it's just FAST negotiation that's a MUST, but FAST itself > (or an equivalent) is just a SHOULD, this still doesn't make a lot of > sense, and should at least be explained. > - 11: this section defines a new structure, but only explains a few of > its members. Please mention where all the other members are defined (RFC > 4120?). By the way, key-expiration is said to be deprecated in RFC 4120, > but what do I know. > - General: the document is said to update RFC 4120. A short section with > a summary of the specific updates would be very useful, so that > implementors can find out if they need to change anything, even if they > do NOT support the Referral functionality. (This is really a shortcoming > of the IETF notion of "RFC X updates RFC Y.") > - Appendix A: in "current implementation", do you mean post-Win 2003? > Please clarify. > - Appendix A: a reference to the MS documentation might be appropriate: > http://msdn.microsoft.com/en-us/library/cc233855(v=prot.13).aspx > > Thanks, > Yaron > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From yaronf.ietf@gmail.com Tue Sep 25 10:13:17 2012 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 2D9D121F87E5 for ; Tue, 25 Sep 2012 10:13:17 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDaY5WXc2yf7 for ; Tue, 25 Sep 2012 10:13:16 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECA821F87A2 for ; Tue, 25 Sep 2012 10:13:15 -0700 (PDT) Received: by eaak13 with SMTP id k13so882240eaa.31 for ; Tue, 25 Sep 2012 10:13:15 -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=K1aHdYalcl8bVZru0jVznNS6wZSMF7KnQJ364OW7d0c=; b=R9BXgTHJPp5N46XjQk63XMAVM9zfUUPqzC1uahtpWh/LuO/G2MYY4R6WTcXEiYy90N baKUYBEuEDgg+ewDgBJRt5waULs370J8A3+WJdidjemT22SahU/MY1OiLGbs1qvlLcs7 zopZpEEup9fUg7wWt3eMLvHhjPsiRhbY6M/mGFWLWnEflhCABmjnxaKv43ggRkj+XWJg Zk5OXB5fj/Aj/EfTW3sr7OUgOoJWMsbQPUXbuLwdtceC9s5YwY3L4B2wKSk+WSZ5hFHu +NirWW5X/A3SN8QKMHiT5A4Uk7kERCpjcogZNjdUj6GZYLWOhUNId96gOspKsLYNMegl 1E0Q== Received: by 10.14.205.9 with SMTP id i9mr10095618eeo.21.1348593195348; Tue, 25 Sep 2012 10:13:15 -0700 (PDT) Received: from [10.0.0.3] ([109.65.145.148]) by mx.google.com with ESMTPS id z25sm966805bkz.15.2012.09.25.10.13.13 (version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 10:13:14 -0700 (PDT) Message-ID: <5061E628.2070708@gmail.com> Date: Tue, 25 Sep 2012 19:13:12 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Sean Turner References: <4FBFAE5F.8010305@gmail.com> <505F7514.8030908@gmail.com> <5061E4AE.2030701@ieca.com> In-Reply-To: <5061E4AE.2030701@ieca.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-krb-wg-kerberos-referrals.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-krb-wg-kerberos-referrals-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: Tue, 25 Sep 2012 17:13:17 -0000 Nope, but that's per the process described in http://trac.tools.ietf.org/area/sec/trac/wiki/SecDirReview. The WG chairs are supposedly on the ".all" alias. Thanks, Yaron On 09/25/2012 07:06 PM, Sean Turner wrote: > Did these ever make it to the krb-wg mailing list? > > spt > > On 9/23/12 4:46 PM, Yaron Sheffer 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 adds a "referral" mechanism to Kerberos, where a client >> (e.g. an end user) can use a generic enterprise-wide name, and have it >> mapped to one that is specific to its correct realm; similarly, a >> generic name can be used for a service, and the KDC will respond with >> the correct principal name (and realm) for the service. >> >> Summary >> >> It is obvious that the analysis in the document's Security >> Considerations is very thorough. Unfortunately I do not have the >> Kerberos expertise (which apparently requires knowledge of specific >> implementations' quirky behavior) to determine if all relevant cases >> were covered. >> >> A cursory reading of the Considerations is quite discouraging: several >> security mechanisms exist but they are not universally applied, some >> implementations do not even follow the base protocol etc. I can only >> hope that modern Kerberos implementations have improved in the 11 years >> since this protocol first got started. >> >> Details >> >> - Sec. 4: "trusted name service" is not well defined. In fact it can be >> construed as a euphemism for "enterprise-internal DNS", which is advised >> against earlier. >> - 4.1, last paragraph: is there no possibility to an "issuing realm" to >> "publish" ownership of some resources to the consuming realm, and thus >> effectively claim those resources? >> - 6. In the authorization ASN.1 snippet, what is the value of MAX? >> - 7, first paragraph: when the client sends the request to example.com, >> shouldn't it ensure first that it has a pre-existing (pre-configured) >> trust relationship with example.com? >> - 10: the last paragraph ("Accordingly") is a bit too vague and probably >> does not provide implementors with sufficient advice. >> - 10: overall it is not clear if this section also applies to caching of >> client referrals. >> - 11: surprise! FAST (which was an optional SHOULD in Sec. 6) is now a >> MUST! Even if it's just FAST negotiation that's a MUST, but FAST itself >> (or an equivalent) is just a SHOULD, this still doesn't make a lot of >> sense, and should at least be explained. >> - 11: this section defines a new structure, but only explains a few of >> its members. Please mention where all the other members are defined (RFC >> 4120?). By the way, key-expiration is said to be deprecated in RFC 4120, >> but what do I know. >> - General: the document is said to update RFC 4120. A short section with >> a summary of the specific updates would be very useful, so that >> implementors can find out if they need to change anything, even if they >> do NOT support the Referral functionality. (This is really a shortcoming >> of the IETF notion of "RFC X updates RFC Y.") >> - Appendix A: in "current implementation", do you mean post-Win 2003? >> Please clarify. >> - Appendix A: a reference to the MS documentation might be appropriate: >> http://msdn.microsoft.com/en-us/library/cc233855(v=prot.13).aspx >> >> Thanks, >> Yaron >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> From stephen.farrell@cs.tcd.ie Tue Sep 25 10:36:19 2012 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 4420B21F88A3 for ; Tue, 25 Sep 2012 10:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl8ky8c80Xd2 for ; Tue, 25 Sep 2012 10:36:18 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6037321F887B for ; Tue, 25 Sep 2012 10:36:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C6A6D17147C; Tue, 25 Sep 2012 18:36:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1348594577; bh=07zuSma7ddAh6l lrKXnIjjLHUneD+TbmNGNFy8lvtj8=; b=gOQ2dMBy/3veTj0sLb/BT5/CSZvw/P yDvAmoMSzACPE1S0FbEenFcr2CxiQgy1gQAmCboDrzHAASKE9Fh3GhGUaEd8IAfT 5IZRvvkFlN4qwBePVz78H8HYspl6HtYysmUPIt7/Y0Ji0TXobeoa+yzXkFdJJNk8 ryZOnLxByc6G7wbnm+gBCzwRnPvg0Cf9wqfA7eSZP7cKdTMwFrI3haH2oryoNndS 0/mMrOZ5T3BUWB7CEDgR9pRPTXzOjyIEMQR0DKyyQUNQbNRZcgldyO/14sR4M9o+ 4EFMbG69EFuXIwMUJAWZK0YRnPPiF1ud/Mi7cWz0j10Z5C5l9FvKwMXA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id TQomB1YVHBkR; Tue, 25 Sep 2012 18:36:17 +0100 (IST) Received: from [IPv6:2001:770:10:203:5c16:c238:b5a:f540] (unknown [IPv6:2001:770:10:203:5c16:c238:b5a:f540]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 03C70171476; Tue, 25 Sep 2012 18:36:15 +0100 (IST) Message-ID: <5061EB90.3080409@cs.tcd.ie> Date: Tue, 25 Sep 2012 18:36:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Yaron Sheffer References: <4FBFAE5F.8010305@gmail.com> <505F7514.8030908@gmail.com> <5061E4AE.2030701@ieca.com> <5061E628.2070708@gmail.com> In-Reply-To: <5061E628.2070708@gmail.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-krb-wg-kerberos-referrals.all@tools.ietf.org, "krb-wg mailing list \(ietf-krb-wg@lists.anl.gov\)" , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-krb-wg-kerberos-referrals-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: Tue, 25 Sep 2012 17:36:19 -0000 Re-tx'ing so the list see the secdir review. S. On 09/25/2012 06:13 PM, Yaron Sheffer wrote: > Nope, but that's per the process described in > http://trac.tools.ietf.org/area/sec/trac/wiki/SecDirReview. The WG > chairs are supposedly on the ".all" alias. > > Thanks, > Yaron > > On 09/25/2012 07:06 PM, Sean Turner wrote: >> Did these ever make it to the krb-wg mailing list? >> >> spt >> >> On 9/23/12 4:46 PM, Yaron Sheffer 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 adds a "referral" mechanism to Kerberos, where a client >>> (e.g. an end user) can use a generic enterprise-wide name, and have it >>> mapped to one that is specific to its correct realm; similarly, a >>> generic name can be used for a service, and the KDC will respond with >>> the correct principal name (and realm) for the service. >>> >>> Summary >>> >>> It is obvious that the analysis in the document's Security >>> Considerations is very thorough. Unfortunately I do not have the >>> Kerberos expertise (which apparently requires knowledge of specific >>> implementations' quirky behavior) to determine if all relevant cases >>> were covered. >>> >>> A cursory reading of the Considerations is quite discouraging: several >>> security mechanisms exist but they are not universally applied, some >>> implementations do not even follow the base protocol etc. I can only >>> hope that modern Kerberos implementations have improved in the 11 years >>> since this protocol first got started. >>> >>> Details >>> >>> - Sec. 4: "trusted name service" is not well defined. In fact it can be >>> construed as a euphemism for "enterprise-internal DNS", which is advised >>> against earlier. >>> - 4.1, last paragraph: is there no possibility to an "issuing realm" to >>> "publish" ownership of some resources to the consuming realm, and thus >>> effectively claim those resources? >>> - 6. In the authorization ASN.1 snippet, what is the value of MAX? >>> - 7, first paragraph: when the client sends the request to example.com, >>> shouldn't it ensure first that it has a pre-existing (pre-configured) >>> trust relationship with example.com? >>> - 10: the last paragraph ("Accordingly") is a bit too vague and probably >>> does not provide implementors with sufficient advice. >>> - 10: overall it is not clear if this section also applies to caching of >>> client referrals. >>> - 11: surprise! FAST (which was an optional SHOULD in Sec. 6) is now a >>> MUST! Even if it's just FAST negotiation that's a MUST, but FAST itself >>> (or an equivalent) is just a SHOULD, this still doesn't make a lot of >>> sense, and should at least be explained. >>> - 11: this section defines a new structure, but only explains a few of >>> its members. Please mention where all the other members are defined (RFC >>> 4120?). By the way, key-expiration is said to be deprecated in RFC 4120, >>> but what do I know. >>> - General: the document is said to update RFC 4120. A short section with >>> a summary of the specific updates would be very useful, so that >>> implementors can find out if they need to change anything, even if they >>> do NOT support the Referral functionality. (This is really a shortcoming >>> of the IETF notion of "RFC X updates RFC Y.") >>> - Appendix A: in "current implementation", do you mean post-Win 2003? >>> Please clarify. >>> - Appendix A: a reference to the MS documentation might be appropriate: >>> http://msdn.microsoft.com/en-us/library/cc233855(v=prot.13).aspx >>> >>> Thanks, >>> Yaron >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>> > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > From new-work-bounces@ietf.org Tue Sep 25 14:18:47 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E4621F88B1; Tue, 25 Sep 2012 14:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1348607927; bh=NXhVyGLV36nERfkWxMq75dZxDdKi08/kIFwCjutEAMI=; 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=nBkQE3nactrNOqCLOctpyDiVoa4vdASeTYOVjwQqCuM91cl/5NzbBZ7e7drx40jJA ZnM6bTh/jsod6E0J5q9X9n9hQCBWZ7aQwUz41BwE/2B9+s03IlVLRNISByICBVbTax Vsiwz+XdAjYWGyySHc0LGVYUnPMd7JzzmIZr0qRk= 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 8AA5D21F88B1 for ; Tue, 25 Sep 2012 14:18: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSCMw0Yen1uo for ; Tue, 25 Sep 2012 14:18:46 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0963721F88AC for ; Tue, 25 Sep 2012 14:18:45 -0700 (PDT) Received: from bleuazur.com ([88.173.33.195] helo=sith-wifi.sophia.w3.org) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.69) (envelope-from ) id 1TGcWi-0007El-5L; Tue, 25 Sep 2012 17:18:44 -0400 To: new-work@ietf.org Date: Tue, 25 Sep 2012 23:18:43 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/12.02 (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: Tue, 25 Sep 2012 14:19:16 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: WebFonts Working Group (until 22 October 2012) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 21:18:47 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Fonts Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the WebFonts Working Group: http://www.w3.org/2012/06/WebFonts/draft-charter-ac.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 22 October 2012 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 Chris Lilley, Fonts Activity Lead . Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/Fonts/Activity [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 W3C/ERCIM - B219 - 2004, rte des lucioles - 06410 Biot - FR mailto:coralie@w3.org +33492387590 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From hartmans@mit.edu Wed Sep 26 05:12:23 2012 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 0EDE621F8834 for ; Wed, 26 Sep 2012 05:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.612 X-Spam-Level: X-Spam-Status: No, score=-97.612 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NabXixNzK9Gl for ; Wed, 26 Sep 2012 05:12:22 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 18D9221F8810 for ; Wed, 26 Sep 2012 05:12:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 37125201E2; Wed, 26 Sep 2012 08:02:59 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1BA7B414A; Wed, 26 Sep 2012 08:02:28 -0400 (EDT) From: Sam Hartman To: Yaron Sheffer References: <4FBFAE5F.8010305@gmail.com> <505F7514.8030908@gmail.com> <5061E4AE.2030701@ieca.com> <5061E628.2070708@gmail.com> Date: Wed, 26 Sep 2012 08:02:28 -0400 In-Reply-To: <5061E628.2070708@gmail.com> (Yaron Sheffer's message of "Tue, 25 Sep 2012 19:13:12 +0200") 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 Cc: draft-ietf-krb-wg-kerberos-referrals.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-krb-wg-kerberos-referrals-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: Wed, 26 Sep 2012 12:12:23 -0000 Hi. I wanted to respond to a few points you raised. First, things are a bit more encouraging than it might seem. The security mechanisms (FAST negotiation and FAST as well as a lot of policy constraints) have been significantly motivated by the security analysis of this protocol. Adopting of the security mechanisms is increasing, not decreasing. We have fairly good to excellent (depending on mechanism and usage) bid-down protection. So, things are improving fairly rapidly. In Kerberos, realms cannot claim ownership of resources. Some systems such as Active Directory built on Kerberos do support that. Thanks for your review; I'm discussing with Stephen what changes we want to make to the specific points you raise. From tlyu@mit.edu Wed Sep 26 13:00:40 2012 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 2791821F85ED; Wed, 26 Sep 2012 13:00:40 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6VJTwWQBLNu; Wed, 26 Sep 2012 13:00:39 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id B0D6B21F85C0; Wed, 26 Sep 2012 13:00:37 -0700 (PDT) X-AuditID: 1209190e-b7f756d000000904-46-50635ee4cc56 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 45.C3.02308.4EE53605; Wed, 26 Sep 2012 16:00:36 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id q8QK0WP2029967; Wed, 26 Sep 2012 16:00:32 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q8QK0RSC029856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Sep 2012 16:00:29 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id q8QK0QiW009718; Wed, 26 Sep 2012 16:00:26 -0400 (EDT) To: Yaron Sheffer References: <4FBFAE5F.8010305@gmail.com> <505F7514.8030908@gmail.com> From: Tom Yu Date: Wed, 26 Sep 2012 16:00:26 -0400 In-Reply-To: <505F7514.8030908@gmail.com> (Yaron Sheffer's message of "Sun, 23 Sep 2012 22:46:12 +0200") Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixCmqrfskLjnAYP42BYv5vRdZLGb8mchs 8WHhQxaLVfdnsDuweOycdZfdY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DK2Hq/l63gKlvF y7XTWBsYJ7B2MXJySAiYSFxf+pgNwhaTuHBvPZDNxSEksI9R4sKDsywQzgZGiY87fjBCOFeY JPYs+soM4XQxSnyffoO9i5GDQ0RAU2LaUSuQUcwCKRJ7mlcwgdjCAn4Sa88/ALOFBFwlznyd zghSziYgLXF0cRlImEVAVeJT3yKwKzgFMiT+tTwAs3kFLCTWfrzNAmLzCHBKTP7WwwwRF5Q4 OfMJC8QqLYkb/14yTWAUnIUkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK9 1JTSTYzgMJbk28H49aDSIUYBDkYlHt4Z1skBQqyJZcWVuYcYJTmYlER5b8YAhfiS8lMqMxKL M+KLSnNSiw8xSnAwK4nwPstKChDiTUmsrEotyodJSXOwKInzXkm56S8kkJ5YkpqdmlqQWgST leHgUJLgPRkLNFSwKDU9tSItM6cEIc3EwQkynAdo+BaQGt7igsTc4sx0iPwpRkUpcd65IAkB kERGaR5cLyzNvGIUB3pFmHc3SBUPMEXBdb8CGswENHjpJpCri0sSEVJSDYzcl9bsaN/0btVN i41nJ9wyzTtak33FNdr20LosofechSm22ilNGu/+fHqg3eGxUGn317WlB2MLstpUONJk50T9 En65XfWY/pxTFllil7OmV5zJ9338Y9uE3/OYqxc1NrxS7Hu/7UrE2ahTi1qKP3dqFtz20K3t S8rK3bMkiXFfIvMhSfaE+iIlluKMREMt5qLiRABtLw4NDgMAAA== Cc: draft-ietf-krb-wg-kerberos-referrals.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-krb-wg-kerberos-referrals-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: Wed, 26 Sep 2012 20:00:40 -0000 Yaron Sheffer writes: > - 6. In the authorization ASN.1 snippet, what is the value of MAX? In ASN.1 constraint notation, "MAX" in a value range means an indefinite upper limit. In this case, I believe the intent is to prevent the SEQUENCE OF type from being empty. I think there is a minor error in the ASN.1 in the document; instead of AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number 80 -- login-aliases [0] SEQUENCE(1..MAX) OF PrincipalName, ... } it should be AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number 80 -- login-aliases [0] SEQUENCE (SIZE(1..MAX)) OF PrincipalName, ... } If the constraint were absent (e.g., "SEQUENCE OF PrincipalName"), there would also be no upper bound on the number of elements, and an empty sequence would also be a valid value. From jsalowey@cisco.com Wed Sep 26 17:25:02 2012 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 E80FA21F8602; Wed, 26 Sep 2012 17:25:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZyLOUKDVJwt; Wed, 26 Sep 2012 17:25:01 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3E77821F8615; Wed, 26 Sep 2012 17:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1138; q=dns/txt; s=iport; t=1348705501; x=1349915101; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=MOgeHfy/pbBA5P+v/jERFUGT/lKPVbUmaUcXTantSJA=; b=X0SKY3/wdCsXAtpUuPygDIX2iih9ba1a59XSvn0mDYR8glO9+G8cHn6F IJdsmcDbX3W8JB1HyLtIN+Oc/2Tl1CRtDdKw4YvtrWazu1MVcQjgeR6iD h9wjmSDQzXv5cCUJOWkE4DezYn4b1MrpwidDtbpJrcvCMtr/DkK6tXze0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKSbY1CtJV2c/2dsb2JhbABFvj+BCIInEgEnUQE+QicEATSHY5dYoCiQQWADlWmOQoFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,492,1344211200"; d="scan'208";a="125706036" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 27 Sep 2012 00:25:00 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8R0P0Pr011565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Sep 2012 00:25:00 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 26 Sep 2012 19:25:00 -0500 From: "Joseph Salowey (jsalowey)" To: "secdir@ietf.org" , "draft-ietf-krb-wg-camellia-cts.all@tools.ietf.org" , The IESG Thread-Topic: secdir review of draft-ietf-krb-wg-camellia-cts-01 Thread-Index: AQHNnEaGnyDgSpi90UuEmG8RUqbF8w== Date: Thu, 27 Sep 2012 00:24:58 +0000 Message-ID: <6BFA95AE-9F90-490B-9C63-8C7C96D2BCF3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.65] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19210.004 x-tm-as-result: No--33.359400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-krb-wg-camellia-cts-01 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, 27 Sep 2012 00:25:02 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. The only big issue I see is that the draft uses a different key derivation= than the simplified profile in RFC 3961. What is the reason for this? A= ssuming there is a suitable reason for this I think the draft is ready to g= o with some minor issues.=20 1. I think in section 3 random2key should be random-to-key as in section 4. 2. It would be good to reference section 6 for random-to-key and RFC 3961 f= or k-truncate as well.=20 3. Section 6 does not provide an entry for "string-to-key parameter format" 4. The encryption and decryption description in section 6 seems a little in= complete. In particular the setting of newstate seems to be missing in the= encryption. In the decryption perhaps you should define how newIV is dete= rmined. =20 Cheers, Joe= From hartmans@mit.edu Wed Sep 26 19:59:04 2012 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 8B7CC21F843C; Wed, 26 Sep 2012 19:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.389 X-Spam-Level: X-Spam-Status: No, score=-97.389 tagged_above=-999 required=5 tests=[AWL=-1.677, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwLhqtFf+n-9; Wed, 26 Sep 2012 19:59:04 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0740421F8435; Wed, 26 Sep 2012 19:59:03 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E68A0201E2; Wed, 26 Sep 2012 22:58:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 072A0414A; Wed, 26 Sep 2012 22:58:20 -0400 (EDT) From: Sam Hartman To: "Joseph Salowey \(jsalowey\)" References: <6BFA95AE-9F90-490B-9C63-8C7C96D2BCF3@cisco.com> Date: Wed, 26 Sep 2012 22:58:20 -0400 In-Reply-To: <6BFA95AE-9F90-490B-9C63-8C7C96D2BCF3@cisco.com> (Joseph Salowey's message of "Thu, 27 Sep 2012 00:24:58 +0000") 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 Cc: The IESG , "draft-ietf-krb-wg-camellia-cts.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-krb-wg-camellia-cts-01 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, 27 Sep 2012 02:59:04 -0000 >>>>> "Joseph" == Joseph Salowey (jsalowey) writes: This was discussed in the WG. The simplified profile is showing its age, and perhaps should be renamed the neither simple nor preferred profile. The authors and apparently WG felt that their mechanism represents better cryptographic practice than the RFC 3961 profile. From new-work-bounces@ietf.org Thu Sep 27 00:34:09 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B5D21F847D; Thu, 27 Sep 2012 00:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1348731248; bh=qGBBue8Gytg8cj5FVsW74v1YF6SVWXgaPAWX/XpA9/I=; 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=sNQYB/914y23XK+RAeMEHCZuHcJQYkVoGYBozdDsarMA1t/CmhiiqWR39n0SFkGt1 iGzDV6Hf46guIdauXXnO3CxlguH3hnguWzbmwxyUK3FyRZA4kon9qugKM82GJGMPBJ XM9A20X5a5sgzJYzciA3YM1AaFOA8/ykXwBfE7Rw= 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 1CE8621F847D for ; Thu, 27 Sep 2012 00:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.185 X-Spam-Level: X-Spam-Status: No, score=-8.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiaOsQjrCVBe for ; Thu, 27 Sep 2012 00:34:06 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 560B221F847A for ; Thu, 27 Sep 2012 00:34:06 -0700 (PDT) Received: from gw.sophia.w3.org ([193.51.208.72] helo=sith-wifi.sophia.w3.org) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.69) (envelope-from ) id 1TH8bj-0003PI-SS for new-work@ietf.org; Thu, 27 Sep 2012 03:34:04 -0400 To: new-work@ietf.org Date: Thu, 27 Sep 2012 09:34:03 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/12.02 (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: Thu, 27 Sep 2012 05:44:56 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Pointer Events Working Group (until 2012-10-25) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 07:34:09 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Rich Web Client Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Pointer Events Working Group: http://www.w3.org/2012/pointerevents/charter/charter-proposed.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 2012-10-25 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 Doug Schepers, Rich Web Client Activity Lead . Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/2006/rwc/Activity.html [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 W3C/ERCIM - B219 - 2004, rte des lucioles - 06410 Biot - FR mailto:coralie@w3.org +33492387590 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From kivinen@iki.fi Fri Sep 28 02:12:38 2012 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 4F68921F8546 for ; Fri, 28 Sep 2012 02:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8bh51sULM2P for ; Fri, 28 Sep 2012 02:12:37 -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 198AC21F8516 for ; Fri, 28 Sep 2012 02:12:32 -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 q8S9CTUS014386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Sep 2012 12:12:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q8S9CTG5022687; Fri, 28 Sep 2012 12:12:29 +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: <20581.27133.11381.175443@fireball.kivinen.iki.fi> Date: Fri, 28 Sep 2012 12:12:29 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 1 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: Fri, 28 Sep 2012 09:12:38 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Alan DeKok is next in the rotation. For telechat 2012-10-11 Reviewer LC end Draft Alexey Melnikov T 2012-08-13 draft-ietf-storm-iscsi-cons-06 Tina TSOU T 2012-09-25 draft-ietf-v6ops-ivi-icmp-address-06 Carl Wallace T 2012-10-03 draft-ietf-6man-dad-proxy-05 David Waltermire T 2012-10-02 draft-ietf-6man-udpchecksums-04 Sam Weiler T 2012-10-02 draft-ietf-6man-udpzero-06 Last calls and special requests: Derek Atkins 2012-10-22 draft-gp-intarea-obsolete-ipv4-options-iana-02 Rob Austein 2012-10-23 draft-leiba-extended-doc-shepherd-00 Richard Barnes 2012-10-04 draft-ietf-abfab-gss-eap-naming-05 Dave Cridland 2012-06-28 draft-ietf-nfsv4-federated-fs-admin-12 Dave Cridland 2012-10-04 draft-ietf-geopriv-local-civic-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-02 Russ Mundy 2012-09-20 draft-ietf-eai-5738bis-09 Sandy Murphy 2012-09-20 draft-ietf-eai-popimap-downgrade-07 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-10 Vincent Roca 2012-09-24 draft-ietf-dime-erp-12 Ondrej Sury 2012-09-26 draft-ietf-nea-asokan-01 Brian Weis 2012-10-01 draft-ietf-fecframe-ldpc-02 Klaas Wierenga 2012-10-01 draft-ietf-fecframe-pseudo-cdp-04 Nico Williams - draft-ietf-httpbis-p5-range-20 Nico Williams 2012-10-01 draft-ietf-sidr-pfx-validate-09 Tom Yu 2012-10-12 draft-snell-http-prefer-14 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-08-14 draft-ietf-mptcp-api-05 Glen Zorn 2012-10-25 draft-leiba-3777upd-eligibility-04 -- kivinen@iki.fi From klaas@cisco.com Fri Sep 28 06:50:22 2012 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 08A8021F859A; Fri, 28 Sep 2012 06:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhl9zE6jBXHG; Fri, 28 Sep 2012 06:50:21 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id EFEAA21F84EA; Fri, 28 Sep 2012 06:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1343; q=dns/txt; s=iport; t=1348840220; x=1350049820; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=h4OHAWA2EYjg+FrD4RZdOD6GXRe6cJ+OTsaDw72Sw+A=; b=lkFWSiJeII9IJJIpUfU921HCjZ88JRPknAozPpK553X62zrRurucBCig L2TzkzoZGeAFxD8dz65Q9bKO8quXEfI0MaF9wtuFUMtrcUHvNux13G9Ss s8IpSSnjPHB0ZPU0p2a2WJBAstOAVDw1LWO/5hbDb9LZc0W9AxIRVKJh0 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEABCqZVCrRDoG/2dsb2JhbABFvhCBCII5AYIkATSHYpd0oCuQX2ADlWmFYohggWmCaQ X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="59730917" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 28 Sep 2012 13:50:19 +0000 Received: from [10.21.79.254] ([10.21.79.254]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8SDoHcH025051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Sep 2012 13:50:19 GMT From: Klaas Wierenga Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <3883FA36-0368-48FB-AF8E-C7D23865E76E@cisco.com> Date: Fri, 28 Sep 2012 15:50:14 +0200 To: The IESG , "secdir@ietf.org" , draft-ietf-fecframe-pseudo-cdp.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Subject: [secdir] secdir review of draft-ietf-fecframe-pseudo-cdp-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: Fri, 28 Sep 2012 13:50:22 -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 draft describes how Forward Error Correction (FEC) Framework and = the Session Description Protocol (SDP) elements can be combined to = defined a pseudo Content Delivery Protocol (CDP) to protect multiple = source flows with one or more repair flows. The draft is concise and well written, minor nits: ** the code below figure 5: v=3D0 o=3Dali 1122334455 1122334466 IN IP4 fec.example.com s=3DFEC Framework Examples t=3D0 0 =85. comes out of thin air, is it supposed to be part of Figure 5 (in that = case the caption is at the wrong position)? Some = explanation/introduction is useful. *** 4. Reconstruction of Source Flows from Repair Flow(s) *** 4.1. Example: Multiple Source Flows Protected by a Single Repair = Flow I think for consistency with 3 and 3.1 you should have text in 4 *** Security considerations I agree with the author that no additional security implications are = introduced Cheers, Klaas= From pe-jiang@kddi.com Thu Sep 27 17:14:57 2012 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 DB4FE21F8522 for ; Thu, 27 Sep 2012 17:14:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQEwyPt+LUdf for ; Thu, 27 Sep 2012 17:14:56 -0700 (PDT) Received: from UTMC1104.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id C359E21F8514 for ; Thu, 27 Sep 2012 17:14:55 -0700 (PDT) Received: from UTMC1135 (unknown [10.5.16.204]) by UTMC1104.kddi.com (Postfix) with SMTP id 7DAE52B1F; Fri, 28 Sep 2012 09:14:53 +0900 (JST) Received: from UTMC1122.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id D7E3723FD; Fri, 28 Sep 2012 09:14:46 +0900 (JST) Received: from UTMC1115.kddi.com (unknown [10.5.16.21]) by UTMC1122.kddi.com (Postfix) with ESMTP id B9CA52400; Fri, 28 Sep 2012 09:14:46 +0900 (JST) Received: from KDDI-0806PC0671 ([10.200.129.117] [10.200.129.117]) by post-ims.kddi.com with ESMTPA; Fri, 28 Sep 2012 09:14:46 +0900 To: hallam@gmail.com, secdir@ietf.org, ke-kumaki@kddi.com, murai@fnsc.co.jp, dean.cheng@huawei.com, satoru.matsushima@tm.softbank.co.jp, pe-jiang@kddi.com, draft-kumaki-murai-l3vpn-rsvp-te@tools.ietf.org From: Peng JIANG References: In-Reply-To: Message-Id: <201209280914.DIF26020.OJHQFtBK@kddi.com> X-Mailer: Winbiff [Version 2.51 PL3] X-Accept-Language: ja,en,zh Date: Fri, 28 Sep 2012 09:14:46 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 1209280914470000511745 X-Mailman-Approved-At: Fri, 28 Sep 2012 08:07:04 -0700 Cc: daniel@olddog.co.uk Subject: Re: [secdir] SECDIR Review of draft-kumaki-murai-l3vpn-rsvp-te/ 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, 28 Sep 2012 00:14:57 -0000 Dear Phillip, Thank you for your detailed Security review of our draft. We will endeavor to review and update our draft based on your recommendations, use cases and referral to RFC6437. Our plan is to address the Security aspect and any further IESG comments in a new version of draft after Last Call has completes. If ok I will contact you with our new Security text to confirm it is suitable for addressing the issues you raise. Thank you. Peng > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > > The specification describes a mechanism for exchanging RSVP routing > information to support multi-site VPNs in the case that a connection > supports multiple VPNs. > > The document lacks a substantive security considerations section, instead > referencing RFC3209 for security considerations. I do not think this is > appropriate since that document was published in 2001 when security > considerations were still insubstantial and in the case ofd RFC 3209 > consist of a reference to RFC 2205 which is also pro-forma. > > rfc6437 has a much better presentation of the issues involved. > > While people tend to use Security Considerations to list the problems with > a protocol there is no real reason this should be the case. The SC should > address all the considerations, positive and negative > > Here we have a model where the VPN is providing authentication and > integrity checking end to end. That only leaves service and traffic > analysis as concerns with respect to routing level attacks. But there > should be discussion of the possibility that a member of the VPN network > might introduce malicious routing data to redirect traffic. Either to do > traffic analysis or to perform a DoS attack. > > While this is not something members of a VPN are likely to do > intentionally, it is something an attacker might do if they own one site. > The risk here is that when you join a VPN club you may be exposing yourself > to the vulnerabilities/exploits of the weakest member of the club. And they > may be able to clobber you through them. So large scale systems might well > have rules about auditing and security policies they would need in place. > They should also sanity check the routes advertised. > > Using a VPN does have a penalty as well as it means that the packet > contents are now opaque to the good guys as well as the bad. Port filtering > is no longer possible, spam filtering is hard and so on. > > > -- > Website: http://hallambaker.com/ > > > From david.waltermire@nist.gov Sat Sep 29 15:33:15 2012 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 1AF7521F85C7; Sat, 29 Sep 2012 15:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ayib25CN66U; Sat, 29 Sep 2012 15:33:14 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 514E021F85AF; Sat, 29 Sep 2012 15:33:13 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.379.0; Sat, 29 Sep 2012 18:32:29 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Sat, 29 Sep 2012 18:30:51 -0400 From: "Waltermire, David A." To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-6man-udpchecksums-04.all@tools.ietf.org" Date: Sat, 29 Sep 2012 18:27:07 -0400 Thread-Topic: SecDir review of draft-ietf-6man-udpchecksums-04 Thread-Index: Ac2ejfe/nVclsdjNT6GW9xQZ5WazMQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: [secdir] SecDir review of draft-ietf-6man-udpchecksums-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: Sat, 29 Sep 2012 22:33:15 -0000 I have reviewed this document as part of the security directorate's ongoin= g effort to review all IETF documents being processed by the IESG. These c= omments were written primarily for the benefit of the security area directo= rs. Document editors and WG chairs should treat these comments just like a= ny other last call comments. Summary: This document provides an update to IPv6 (RFC2460) providing requirements f= or using a performance optimization for use cases where a UDP-based tunneli= ng protocol is used, where the inner protocol includes a checksum. In this= case the outer UDP checksum can be assigned a zero value to avoid the comp= utational cost of checksum calculation and verification. In general I found this draft to be very clear on the protocol implications= . The security considerations section addresses the fact that no new vulne= rabilities have been added as the result of these changes. In general this = document is ready with one suggestion and a couple minor nits. My only concern is around clearly communicating to application developers w= hat the security risks are. According to Section 4, paragraph 4, bullet 4,= if the packet is corrupted and sent to the wrong endpoint, but the same tu= nneling protocol is used with a matching context, then the packet should be= decapsulated and forwarded. It is the application developers responsibili= ty to verify and discard the data if needed. It looks like this situation = could be used to craft datagrams for use in a denial of service attack, by = flooding an application with junk datagrams or worse yet could be used to a= ffect the application state (according to I-D.ietf-6man-udpzero examples). = It is also looks like it is possible to achieve this using a crafted datag= ram with a valid checksum. It might be good to include text warning applic= ation developers about this possible situation in the security consideratio= ns section. The warning could reference any other appropriate documents de= scribing possible scenarios or any guidance related to addressing this issu= e. =20 Additional editorial nits: - In the last sentence of the abstract "defines" should be "define" - One other NIT in draft-ietf-6man-udpzero-06, section-5.1, item 5: in the = last sentence "mechanisms" should be "mechanism". Sincerely, David Waltermire