From hilarie@purplestreak.com Thu Mar 1 12:28: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 5E94C21E82DB; Thu, 1 Mar 2012 12:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XO8Acn9Ml3a; Thu, 1 Mar 2012 12:28:22 -0800 (PST) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by ietfa.amsl.com (Postfix) with ESMTP id E59AC21E80BF; Thu, 1 Mar 2012 12:28:22 -0800 (PST) Received: from mx02.mta.xmission.com ([166.70.13.212]) by out03.mta.xmission.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1S3Cbt-0006EH-Gr; Thu, 01 Mar 2012 13:28:21 -0700 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1S3Cbs-0002Kf-Je; Thu, 01 Mar 2012 13:28:21 -0700 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 q21KSExZ023401; Thu, 1 Mar 2012 13:28:14 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id q21KSE3q023399; Thu, 1 Mar 2012 13:28:14 -0700 Date: Thu, 1 Mar 2012 13:28:14 -0700 Message-Id: <201203012028.q21KSE3q023399@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx02.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; sa05 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 mx02.mta.xmission.com) Subject: [secdir] review of draft-ietf-dnsext-ecdsa-07.txt 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, 01 Mar 2012 20:28:23 -0000 Security review of draft-ietf-dnsext-ecdsa-07.txt 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. >From the Introduction: This document defines the DNSKEY and RRSIG resource records (RRs) of two new signing algorithms: ECDSA (Elliptic Curve DSA) with curve P-256 and SHA-256, and ECDSA with curve P-384 and SHA-384 Looks good to me. Hilarie From weiler+secdir@watson.org Thu Mar 1 14:00: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 4D2A421E8119 for ; Thu, 1 Mar 2012 14:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2d5t3VJ3ak7 for ; Thu, 1 Mar 2012 14:00:22 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id A502421E8024 for ; Thu, 1 Mar 2012 14:00:22 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q21M0KUD069553 for ; Thu, 1 Mar 2012 17:00:21 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q21M0K3p069550 for ; Thu, 1 Mar 2012 17:00:20 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 1 Mar 2012 17:00:20 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 01 Mar 2012 17:00:21 -0500 (EST) 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, 01 Mar 2012 22:00:23 -0000 Several of the newly assigned docs are also on the IESG telechat two weeks from today. As fair warning, the IESG tends to try to clear its backlog before the IESG-member-changeover in March, so the docs listed in the last call section of this email are more likely than usual to be on the March 15th telechat, also. -- Sam Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview David McGrew is next in the rotation. For telechat 2012-03-15 Reviewer LC end Draft Phillip Hallam-Baker T 2012-03-13 draft-ietf-pcn-3-in-1-encoding-08 Leif Johansson T 2012-03-06 draft-ietf-decade-problem-statement-05 Stephen Kent T 2012-03-08 draft-ietf-ipfix-rfc5815bis-01 Julien Laganier T 2012-03-08 draft-ietf-mediactrl-6231-iana-00 Barry Leiba T 2012-03-08 draft-ietf-opsawg-management-stds-05 Matt Lepinski T 2012-03-09 draft-ietf-pwe3-packet-pw-03 Nico Williams T 2012-03-14 draft-garcia-shim6-applicability-03 Last calls and special requests: Reviewer LC end Draft Rob Austein 2012-02-28 draft-ietf-adslmib-gbond-tdim-mib-07 Jeffrey Hutzelman 2012-03-21 draft-betts-itu-oam-ach-code-point-03 Charlie Kaufman 2012-03-12 draft-ietf-hokey-rfc5296bis-06 Scott Kelly 2012-03-15 draft-ietf-appsawg-xdash-03 Tero Kivinen 2012-03-14 draft-ietf-marf-dkim-reporting-11 Warren Kumari 2012-03-14 draft-ietf-marf-spf-reporting-08 Chris Lonvick 2012-03-28 draft-melnikov-smtp-priority-07 Tim Polk 2012-02-07 draft-ietf-oauth-v2-bearer-17 Eric Rescorla 2012-02-08 draft-ietf-sieve-notify-sip-message-08 Vincent Roca 2012-02-06 draft-ietf-simple-chat-13 Klaas Wierenga 2012-03-08 draft-desruisseaux-caldav-sched-10 Glen Zorn 2012-02-28 draft-ietf-adslmib-gbond-eth-mib-05 From klaas@cisco.com Sat Mar 3 08:05:12 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 CD96321F86AD; Sat, 3 Mar 2012 08:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.222 X-Spam-Level: X-Spam-Status: No, score=-9.222 tagged_above=-999 required=5 tests=[AWL=1.377, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHAAZbnKsATq; Sat, 3 Mar 2012 08:05:11 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7A26921F867D; Sat, 3 Mar 2012 08:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=5406; q=dns/txt; s=iport; t=1330790711; x=1332000311; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=hsLlmoseo6ZL+DG0NNCx6CJAlN5sZR69XRnTwe8oQfw=; b=aazt9Roip5rIOOs85+aCGwVa2HQBVPTIfpbDrgQWDI2J4zU/ThScIziG cVB/+Q4pfQUdDfBqAFaxdlxRLW4AG21f7p1eMuq91rqwb4KcykeEghaE3 hUmfCCmkTDz6LTdABUOSY2FtpBXJ4RsdQHTI8Xl6bTUud7+m5LS3BhZtA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAOU/Uk+tJXHB/2dsb2JhbABDtD+BB4IWASeBfQE0h2WaTQGeFI96YwSVPoUzil+CZIFVFw X-IronPort-AV: E=Sophos;i="4.73,526,1325462400"; d="scan'208";a="63537150" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 03 Mar 2012 16:05:11 +0000 Received: from rtp-kwiereng-8714.cisco.com (rtp-kwiereng-8714.cisco.com [10.116.7.37]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q23G5952011712; Sat, 3 Mar 2012 16:05:10 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Mar 2012 17:05:08 +0100 Message-Id: To: draft-desruisseaux-caldav-sched.all@tools.ietf.org, The IESG , secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [secdir] review of draft-desruisseaux-caldav-sched-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 16:05:13 -0000 Hi, 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. This draft defines the calendar-auto-schedule feature, a standard way of = scheduling of iCalendar based calendar components between calendar users = leveraging the iCalendar Transport-independent Interoperability Protocol = (iTIP). I have read the document specifically from a security PoV but will share = my other comments with you as well. Some of them may be due to a lack of = understanding of the underlying protocols, in that case apologies. Regards, Klaas =3D=3D=3D=3D=3D=3D 1.2 approach ------------------ bullet 1 and 2 together seem to form 1 problem, bullet 1 is just stating = a fact. something that must have been discussed in extremes, but I can't help = wondering what the reasoning is for not making the server responsible = for sending and processing scheduling messages, is that a legacy thing? = It seems to overly complicate this document that always 2 cases need to = be distinguished. 1.3 limitations ------------------- I can't help a chuckle with the statement "to keep this specification = simple", I think simplicity got lost somewhere in the process. I = probably would have considered breaking the document up in multiple = documents. 4. scheduling collections --------------------------------- can the server only create or also delete the collections? 4.1 scheduling outbox collections --------------------------------------------- caldav-max-resource-size, not using this seems to invite DoS attacks, = perhaps make it a SHOULD to support this and mention in the security = considerations the possibility of DoS attacks? (same goes for 4.2) 5.2.2.2 create ------------------ In which cases can scheduling messages be delivered directly to the = client? And can't you forbid that? 6 processing incoming scheduling messages ------------------------------------------------------------- Can you be more specific about WHERE in RFC5546 these rules are = specified? 7.1 status codes ---------------------- These are EXAMPLE response codes? Why not normative? And doesn't that = give interoperability issues? 7.2.1 day:need-privileges precondition ---------------------------------------------------- How is the user authenticated? 8. Avoiding conflicts when updating scheduling object resources = --------------------------------------------------------------------------= ------------- First paragraph: reference for ETag and If-Match? Fourth paragraph: I don't really get the text, a simple example might = help. 9.2 schedule status values ------------------------------------ Is there any reasoning behind the delivery status codes? To the = uninitiated (me) they seem randomly chosen. 11.1 additional message header fields ---------------------------------------------------- It might make sense to point out that T and F stand for True and False 12.2 caldav:schedule-default-calendar-url property --------------------------------------------------------------------- What does it mean that a property is protected? 15. Security Considerations -------------------------------------- You write that servers and clients MUST use TLS. That is not = sufficiently strong, you must make sure that server and client mutually = authenticate each other. I would at the very least expect some text = about server validation [RFC6125] Also, in the main text there is no mentioning of HTTPS, but only HTTP, I = think you need to say also in the main text that you expect a secure = channel (unless you don't?) This document leverages iTIP [RFC5546], however that document specifies = an abstract transport protocol, and assumes other documents to implement = particular transports. Furthermore it does't contain any normative = language for dealing with the threats that are identified: - 6.1.1 Spoofing the "Organizer" - 6.1.2 Spoofing the "Attendee" - 6.1.3 Unauthorized Replacement of the Organizer - 6.1.4 Eavesdropping - 6.1.5 Flooding a Calendar - 6.1.6 Procedural Alarms - 6.1.7 Unauthorized REFRESH Requests I would expect in the security considerations mention of these threats = and normative language about at least the authentication of the = organizer to the attendee and the attendee to the organizer.=20 In the examples there is mention of users @example.org and users = @example.com, I suspect that that means that multiple calendaring = domains can operate in a federated manner, how is the authenticity of a = user in another domain validated? Can only "local users" look up = free/busy information? If not, how do you make sure that not the whole = Internet can lookup for example free/busy information? 15.3 Privacy Considerations Especially in large deployments spanning many organizations (like Google = Calendar) I think Schedule-Reply request header is not going to cut it. = I would expect at least some discussion about privacy and free/busy = information, information about calendar event traveling over = organizational boundaries (or not) etc..=20= From shawn.emery@oracle.com Sun Mar 4 00:03: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 48C9911E8073; Sun, 4 Mar 2012 00:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.265 X-Spam-Level: X-Spam-Status: No, score=-9.265 tagged_above=-999 required=5 tests=[AWL=1.334, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i13LW3wk0p7x; Sun, 4 Mar 2012 00:03:47 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5B911E8072; Sun, 4 Mar 2012 00:03:46 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2483hwL020575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Mar 2012 08:03:44 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2483gHd010865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Mar 2012 08:03:43 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2483gLv027175; Sun, 4 Mar 2012 02:03:42 -0600 Received: from [10.159.34.98] (/10.159.34.98) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Mar 2012 00:03:42 -0800 Message-ID: <4F5321A2.1070504@oracle.com> Date: Sun, 04 Mar 2012 01:02:42 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:9.0) Gecko/20120113 Thunderbird/9.0.1 MIME-Version: 1.0 To: secdir@ietf.org References: <4F0410AE.8050600@oracle.com> In-Reply-To: <4F0410AE.8050600@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090209.4F5321E1.0017,ss=1,re=0.000,fgs=0 Cc: draft-ietf-manet-smf.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-manet-smf-13 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, 04 Mar 2012 08:03:48 -0000 I know that the telechat has passed, but since I started this before then, I have posted the completed review below... 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 experimental draft describes a multicast forwarding design specifically for limited wireless mesh and mobile ad hoc networks (MANET). The security considerations section does exist. The section states several attacks and provides mitigation of the associated attack. Most of the attacks listed are related to DoS. Solutions to some of these issues involve caching TTL/hop-limits to thwart against an attacker replaying packets with reduced TTL/hop-limits. The section goes on reference RFC6130's security consideration section in regards to MANET's neighborhood discovery protocol (NHDP). I had originally reviewed that draft as well and had found no additional concerns. General comments: None. Editorial comments: Well written, thank you. Shawn. -- From julien.ietf@gmail.com Mon Mar 5 10:35:29 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 7654E21F88B1; Mon, 5 Mar 2012 10:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GCWu0AzJWmV; Mon, 5 Mar 2012 10:35:29 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD4321F88AF; Mon, 5 Mar 2012 10:35:28 -0800 (PST) Received: by ghbg16 with SMTP id g16so2047318ghb.31 for ; Mon, 05 Mar 2012 10:35:28 -0800 (PST) Received-SPF: pass (google.com: domain of julien.ietf@gmail.com designates 10.236.92.201 as permitted sender) client-ip=10.236.92.201; Authentication-Results: mr.google.com; spf=pass (google.com: domain of julien.ietf@gmail.com designates 10.236.92.201 as permitted sender) smtp.mail=julien.ietf@gmail.com; dkim=pass header.i=julien.ietf@gmail.com Received: from mr.google.com ([10.236.92.201]) by 10.236.92.201 with SMTP id j49mr28684717yhf.60.1330972528275 (num_hops = 1); Mon, 05 Mar 2012 10:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QTgHmhlY6Vzq9y3HUhYjn27Q/VkXCOvtgaznFWVZzFI=; b=lyElj2+Phnaad4Mjg172d3HAicn1jXpiH+qwnlhmhpeiSiHvvKzGVhYu6zj6skqsOY 6/UlVMiiVCSL1+fOgXuIBoy5J3+7qW50PKTPCurswoR9ZWJPpUOuzYrp+NNSvAIM3BHv XK52sx6Si/7vmGIwx10Z7OMgjY07FAeRV8FiinxIP226uTMSwCq0idbG8G1ITXwNtGJa VNVjnvyGPMjQLEf/jHKzZUWqFp03bMZdI/h48ZgCp1ILjhCqbHc7kR0oVhNGJSY7uYwZ E3k5rw4rOVDYARenHuY2YnmSULHBXwsoa8hlMBHdGrLtxBIuSpD2qdc2NYoZ7PyYkUv9 1SRg== MIME-Version: 1.0 Received: by 10.236.92.201 with SMTP id j49mr22577009yhf.60.1330972528231; Mon, 05 Mar 2012 10:35:28 -0800 (PST) Received: by 10.147.122.19 with HTTP; Mon, 5 Mar 2012 10:35:28 -0800 (PST) Date: Mon, 5 Mar 2012 10:35:28 -0800 Message-ID: From: Julien Laganier To: secdir@ietf.org, The IESG , draft-ietf-mediactrl-6231-iana-00.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] SECDIR review of draft-ietf-mediactrl-6231-iana-00 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, 05 Mar 2012 18:35:29 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I am going to shamelessly paraphrase the document: "This document creates an IANA registry for the response codes for the MEDIACTRL Interactive Voice Response Control Package [RFC6231]." I agree with the included security considerations section that states that there are "None, other than those described in the MEDIACTRL Interactive Voice Response Control Package. [RFC6231]." --julien From macker@itd.nrl.navy.mil Mon Mar 5 12:12: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 197F611E8089; Mon, 5 Mar 2012 12:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reTeiX-0jR1U; Mon, 5 Mar 2012 12:12:41 -0800 (PST) Received: from s2.itd.nrl.navy.mil (unknown [IPv6:2001:480:20:1083:213:21ff:fe1f:5b9c]) by ietfa.amsl.com (Postfix) with ESMTP id 3418511E8088; Mon, 5 Mar 2012 12:12:41 -0800 (PST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id q25KCdaV029444; Mon, 5 Mar 2012 15:12:39 -0500 Received: from aes247010.nrl.navy.mil ([132.250.247.10]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2012030515123928297 ; Mon, 05 Mar 2012 15:12:39 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Macker In-Reply-To: <4F5321A2.1070504@oracle.com> Date: Mon, 5 Mar 2012 15:12:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <07F5BD20-6838-48B6-94F8-EE79F230BDF9@itd.nrl.navy.mil> References: <4F0410AE.8050600@oracle.com> <4F5321A2.1070504@oracle.com> To: Shawn Emery X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 05 Mar 2012 13:41:09 -0800 Cc: draft-ietf-manet-smf.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-manet-smf-13 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, 05 Mar 2012 20:12:42 -0000 Shawn: I want to thank you for the comments and your time. -joe On Mar 4, 2012, at 3:02 AM, Shawn Emery wrote: >=20 > I know that the telechat has passed, but since I started this before = then, I have posted the completed review below... >=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 experimental draft describes a multicast forwarding design = specifically for limited wireless mesh and mobile ad hoc networks = (MANET). >=20 > The security considerations section does exist. The section states = several attacks and provides mitigation of the associated attack. Most = of the attacks listed are related to DoS. Solutions to some of these = issues involve caching TTL/hop-limits to thwart against an attacker = replaying packets with reduced TTL/hop-limits. The section goes on = reference RFC6130's security consideration section in regards to MANET's = neighborhood discovery protocol (NHDP). I had originally reviewed that = draft as well and had found no additional concerns. >=20 > General comments: >=20 > None. >=20 > Editorial comments: >=20 > Well written, thank you. >=20 > Shawn. > --=20 >=20 From carl@redhoundsoftware.com Tue Mar 6 05:47: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 33F9D21F87CC for ; Tue, 6 Mar 2012 05:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1YrzQ-wb-aw for ; Tue, 6 Mar 2012 05:47:15 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52F5B21F87EB for ; Tue, 6 Mar 2012 05:47:14 -0800 (PST) Received: by vbbez10 with SMTP id ez10so5062825vbb.31 for ; Tue, 06 Mar 2012 05:47:13 -0800 (PST) Received-SPF: pass (google.com: domain of carl@redhoundsoftware.com designates 10.52.99.169 as permitted sender) client-ip=10.52.99.169; Authentication-Results: mr.google.com; spf=pass (google.com: domain of carl@redhoundsoftware.com designates 10.52.99.169 as permitted sender) smtp.mail=carl@redhoundsoftware.com Received: from mr.google.com ([10.52.99.169]) by 10.52.99.169 with SMTP id er9mr41076251vdb.126.1331041633758 (num_hops = 1); Tue, 06 Mar 2012 05:47:13 -0800 (PST) Received: by 10.52.99.169 with SMTP id er9mr35198176vdb.126.1331041633656; Tue, 06 Mar 2012 05:47:13 -0800 (PST) Received: from [192.168.1.4] (pool-173-79-133-63.washdc.fios.verizon.net. [173.79.133.63]) by mx.google.com with ESMTPS id e18sm17928555vdh.20.2012.03.06.05.47.11 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 05:47:12 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 06 Mar 2012 08:47:06 -0500 From: Carl Wallace To: Suresh Krishnan Message-ID: Thread-Topic: secdir review of draft-ietf-netext-pmip-lr-08 In-Reply-To: <4F4EF893.1060201@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQkFgZszZR/uElrUbQEXvG+9vu4aqqFgBb4iLmDi0npWZNrS3246SUDz1GyUCDwenmOI4pSY Cc: "draft-ietf-netext-pmip-lr.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netext-pmip-lr-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: Tue, 06 Mar 2012 13:47:15 -0000 It's probably more a style thing than anything else. I don't like to see requirements introduced in the security considerations section. I do not feel particularly strongly about this though. On 2/29/12 11:18 PM, "Suresh Krishnan" wrote: >Hi Carl, > Thanks for your review. I will add the reference to RFC4832 like you >stated. Is there a specific reason why you prefer the security related >text be moved to the body of the document instead of the Security >Considerations section? > >Regards >Suresh > >On 02/28/2012 08:00 AM, Carl Wallace wrote: >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written primarily for the benefit of the security >>area >> directors. Document editors and WG chairs should treat these comments >> just like any other last call comments. >> >> >> This document proposes initiation, utilization and termination >>mechanisms >> for localized routing between mobile access gateways within a proxy >>mobile >> IPv6 domain. The security considerations section introduces (for this >> document) the requirement for IPSec and the reuse of a security >> association described in RFC 5213. This text belongs in the body of the >> document in my opinion, with the security considerations possibly >>changed >> to simply reference RFC 4832 and RFC 5213 security considerations. >> >> >> > From kivinen@iki.fi Tue Mar 6 08:01: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 4EA9821F89CB; Tue, 6 Mar 2012 08:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEfHYulxIP3a; Tue, 6 Mar 2012 08:01:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DC421F8768; Tue, 6 Mar 2012 08:01:13 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q26G1A44006981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2012 18:01:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q26G19jk020747; Tue, 6 Mar 2012 18:01:09 +0200 (EET) 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: <20310.13509.461991.185885@fireball.kivinen.iki.fi> Date: Tue, 6 Mar 2012 18:01:09 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 20 min X-Total-Time: 19 min Cc: draft-ietf-marf-dkim-reporting.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-marf-dkim-reporting-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: Tue, 06 Mar 2012 16:01:15 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document adds a way to DKIM verifier to send reports to the DKIM signer when something goes wrong with the signature verification. It provides two fold authentication to verify that signer has really requested the reports to protect signers from bogus reports: The DKIM-Signature field of the email in question needs to have tag "r=y" to indicate signer wants to see reports, and the _report._domainkey subdomain needs to have TXT record which also indicates that signer really wanted these reports. This is all fine, but the security considerations section should really point out that the TXT record is the only part that is really protecting the signer from distributed bogus reports. Even if signer does not ever put "r=y" tag in any of the messages, but still publishes the TXT records "just in case" they ever want to get those reports, the attacker can modify every single email in transit to include bogus DKIM-signature field with "r=y" and "d=" matching the signer and DKIM verifiers will start flooding reports to the signer. Note, that those emails do not even need to be originally have anything to do with the domain being attacked. Actually just adding "r=y" to valid DKIM-Signatures will cause the signature to fail (if I have understood things correctly), thus triggering the report. So the only way the signer can protect himself against bogus reports is to remove the TXT records from the DNS. There should be text about this in the security considerations sections, as otherwise adminstrators might put those TXT records out there just in case they are needed, and open themselves to the attack. On the other hand, even when signer requests reports to verify nobody is messing up its DKIM-Signatures the attacker can remove the "r=y" tag from the email (or the whole DKIM-Signature) and in that case the verifier do not send report to the signer (unless the Author Domain Signing Practices (ADSP) is in use, but I didn't really check whether those records are checked if no DKIM fields are found in the email). Attacker who wants to modify the emails do not want to advertise this, thus it will of course remove the "r=y", so it can fly under the radar... The proposed Extension to the DKIM-Signature tag does not really protect or detect against attacks, but it might be useful for debugging and detecting misconfigurations in the system. I think the DKIM-ADSP extensions are more useful for detecting attacks, as those will be checed even when there are no DKIM-Signature fields in the email (at least I think so, as otherwise they could not report "unsigned" messages. ---------------------------------------------------------------------- There is also some smaller issues: ---------------------------------------------------------------------- ADSP is not spelled out ever, and the reference to the RFC5617 uses different title than what is the actual title of the RFC5617: "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)" vs "DKIM Sender Signing Practises". so it was bit hard to see what ADSP actually meant, until I actually checked the RFC5617. I am not sure why the references are getting wrong titles, as shouldn't the http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml references get those directly from RFCs. On the other hand it might be the references are written out manually... ---------------------------------------------------------------------- In section 4: only. To construct the actual address to which the report is sent, the Verifier simply appends to this value an "@" followed by the domain whose policy was queried in order to evaluate the sender's ADSP, i.e., the one taken from the RFC5322.From domain of ^^^ the message under evaluation. Therefore, a signer making use of this extension tag MUST ensure that an email address thus constructed can receive reports generated as described in Section 6. ABNF: It seems there is extra . between the "RFC5322" and "From". ---------------------------------------------------------------------- In section 5: This memo also includes, as the "ro" tags defined above, the means by ^^ I do not think this document defines "ro" tag, I assume it was meant to mean "rr" tag instead? ---------------------------------------------------------------------- In section 5.2: How can DKIM ADSP failures ever report "d" type errors, as if they have DNS issues for fetching ADSP records, they will not get the "rr" tag saying "d" or "all" types should be reported... -- kivinen@iki.fi From kent@bbn.com Tue Mar 6 10:17: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 D9D8721F88ED for ; Tue, 6 Mar 2012 10:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.08 X-Spam-Level: X-Spam-Status: No, score=-106.08 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7g+cZaLSZUmD for ; Tue, 6 Mar 2012 10:17:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B842321F88E8 for ; Tue, 6 Mar 2012 10:17:01 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:42233 helo=[192.168.1.4]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S4ywP-00083P-Kq for secdir@ietf.org; Tue, 06 Mar 2012 13:16:54 -0500 Mime-Version: 1.0 Message-Id: Date: Tue, 6 Mar 2012 13:16:27 -0500 To: secdir@ietf.org From: Stephen Kent Content-Type: multipart/mixed; boundary="============_-881064676==_============" Subject: [secdir] review of ipfix-5815bis 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, 06 Mar 2012 18:17:03 -0000 --============_-881064676==_============ Content-Type: multipart/alternative; boundary="============_-881064676==_ma============" --============_-881064676==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document, "Definitions of Managed Objects for IP Flow Information Export"is a "bis" of RFC 5815, which was published about 2 years ago (April 2010). This is a longish document (68 pages), and it's a MIB. Since I am not a MIB expert I focused on the Security Considerations section of the document, which is about a page and a quarter in length. The text in this section is identical to the corresponding section from the version of RFC 5815 that this document is updating. The security considerations text is clear. It enumerates tables/objects in the MIB that have a MAX-ACCESS other than "non accessible" and that contain data that might be considered sensitive. It notes why these tables/objects might require (read) access security controls. Other text in this section focuses on security issues applicable to MIBs in general. It admonishes users to employ SNMPv3 and to enable crypto security. I suggest the following minor, editorial revisions to the end of this section (see the attached PDF for the full MS Word change tracking graphics). SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410] Section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and confidentiality). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED that SNMPv3 be deployed and that cryptographic security be enabled. It is then a customer/operator responsibility to ensure that the SNMP entity granting access to an instance of these MIB modules is properly configured to grant access to objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. --============_-881064676==_ma============ Content-Type: text/html; charset="us-ascii" review of ipfix-5815bis
I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document, "Definitions of Managed Objects for IP Flow Information Export"is a "bis" of RFC 5815, which was published about 2 years ago (April 2010).

This is a longish document (68 pages), and it's a MIB. Since I am not a MIB expert I focused on the Security Considerations section of the document, which is about a page and a quarter in length. The text in this section is identical to the corresponding section from the version of RFC 5815 that this document is updating.

The security considerations text is clear. It enumerates tables/objects in the MIB that have a MAX-ACCESS other than "non accessible" and that contain data that might be considered sensitive. It notes why these tables/objects might require (read) access security controls. Other text in this section focuses on security issues applicable to MIBs in general. It admonishes users to employ SNMPv3 and to enable crypto security.
I suggest the following minor, editorial revisions to the end of this section (see the attached PDF for the full MS Word change tracking graphics).


   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in these MIB modules.

   It is RECOMMENDED that implementers consider the security features
   provided by the SNMPv3 framework (see [RFC3410] Section 8), including
   full support for the SNMPv3 cryptographic mechanisms (for
   authentication and confidentiality).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED that SNMPv3 be deployed and that
   cryptographic security be enabled.  It is then a customer/operator
   responsibility to ensure that the SNMP entity granting access to an
   instance of these MIB modules is properly configured to grant access
   to objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.
--============_-881064676==_ma============-- --============_-881064676==_============ Content-Id: Content-Type: application/pdf; name="secdir review of ipfix-rfc5815bis.pdf" ; x-mac-type="50444620" ; x-mac-creator="4D535744" Content-Disposition: attachment; filename="secdir review of ipfix-rfc5815bis.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVnW2T2zaSx9/rU/BenV21K/P54d7t Js6W7yqb3NpVe1XJvpBnZFs5jeSMZuzka+7WfZ/7NYAmQFLSkJqRo5SrPGAThBpgo/uP RqP5c/Tf0c9RPc+bKI/nRRbHWVQ0xTxOoypP500d3S6jv0eb6MVXuyS62kXxvMmbOGnK faXZ7irKs2YeV3mUVM08TfIkSgoKTVVEZRLPsybPpMl3/neTKpsnSVFFeZXM07ytNuv/ chTzj1/4mZ9O6ryOYyHwr73Ks3lTJWUJ7/E8rtPo6ib68xsqUDWZvbmKCvuE+/PmJnrx TTKPoyR68y569grGPq2Wn5fX0d2H1S663l7d3yw3d9FiF31c3N5F23fcWEa75dX97eru 1+h6dbu8utveLu6W/76Lns/e/BS9fEPH2iE91LXBoE7pWtrMm6SehV2LHuradvN+u9q8 j5bv3m3pyN3WdTVarNfRq5dvvmk7u4veLqXmx9vt1XK3Yyze/mp6/aW6lzTzqsgnde8H 3t3L13+ZR8+jBJl4pn/ffFjultHV9kbe4i76vESiPvPm7pYb+re6Wdyu1r9GjIjp4Nvl Zvlu1b7l57N/RG/+80u80LiZ53GRTu1yK4aL2+WilcUdozDrjMLXKsbL6xXCuosWm+vo 73+Jrj4sVlztnkcTOnrCpMzKbF6lJQrFddTOypmdlQ+K7oft/ZoJSR/veK+jp9gJjLba o2zQWHni1MdYRlENobT9dL+7i9ar/10y3r9GW+7eRusFtCuZcyqU8/NOq4w+ZU2JUnVd ckJ2VA9+sWGuxVJUOsyXwVNVo10z5WmkjL4JzcUfzjx+SVrNk7xIo7LL69Hx++d5pw4j Ni+BBX2eRo7f1yjezeputd3sxMh+u9gs3mN5vnv7E/YVBfXmp9nZDGvKzIizyrN+AVMk i/N5Uaeep2kqUyzaq++jb9bbz2eWRa8yy3pe5c3EefNqA6s3C3nx0ctfPgJNziym8FtV TROVXXaPTp1/nZunZp6led3naeTUAacuon++Xe3OzGaKSFZVNmDz6NCdWfpSWVAkdXXi 0KFp/vbNV1FRJ8Ufos8fVlcfos8C9e/frle7D+ifxdvtPaDjy+D6smAVFsfTkO+zNPp1 uRBM934b/fjsT6DadZTGSfzj8zMji6RO50WTY4W6fP+W8oAoyJLT8+TU5m/Jk9eQeT1P s7K4KJ6yGgTGmtssJscCXYN2jN5Zs65kqrSLR0SwrFkrv1/ufnz+B7PQWN39n2iob1/9 eR69Xm2ultGraHETbbZfbmKBl5q4njixDMvR8pePS9bLZ7YASTmPiwKQ7jid9jpesYK9 upeVOlZU/BOv1T/xFXhqdb3EP2GQFQtGY2mdG+NL6bWkAhnkE4dffS+qmEXcjDZeGPEy orWIfr7HLcO6arWJ1svN+7sP84g1f3S3/OVOaF+qh3HFIqsoJy3gnxkXk74SuseL2tyt WByKd0Ze49X29na5+7jdXIs/Rmu+u93efEl/TNGgU7NkYuc+LW93AuoCEwvTrOC7jjW6 ff/xGvHcvD+zucrScl6VSYVzs9OfizANBXYrLqvykkxDUZVozUx5GolGZfYhqdY9enVm tZkm89L4q09itasbrcrYRVdr4JTje3YeT26KmztjER/pEE/TG/Po1V203OCZFr8zbufQ JzYznvxzuJ2LkgmEK2kas3eLt+vl7sXWLuRFJ4tmAwxYbfBh8Qn3WPTtn/7nvKraD3m3 F0dn/x87I2v3SA6N7AnexhSprQu2RXRkp1n9P3311cvXr51fEdW6if65QeEGPM/cvs4h nh+zCVEUJSYvnrgLsbiSLYUVIvEvY8CNRbjabu4WCAZmYGGl4mb1/sMd2xBYQItfgDa7 JcW71aeluLdHO4Ef1cW8nKdpObGLzE2gLdPy8wezbYJHuDcHbO9ulz/fs3sEYMaxff3j 88iOzXn7lrFmY82M5un27eg0CEVKtwoPidQJ06BdHxUZKLhM62nTwBsbxOh2u2b74ztU DDs6DgN2YJYFyvgYN95KnXfIfffSYl439URxWu129wjT4uPHNdCQiSPgEPUJXNxE79mw ul2sjUFYXN+ctyMpGKXJ2dctTurIdiMuFeDeDmQonVjefFxvfzXCdT7frh/9pMB65c00 6/X6r99+/yk78wRgTlZ1wX564XicNgFkM0+Gc2Ok4+r2149c6axAWZ7Xd17gTy2IGOgO 72Xok7iYZ7XDr92N/1lv43/KG+6ZlJkNKBgXlZATWJGmzkfuohIG+5995l6dmbuCYI8y ycvoJO529+9x9si6jpiO7ZodB1msBijkDCYjqVgu5U22l+MHozxuVpvt7bn36FImRF2y eto3qA+yaDfqV7gCJCBFFtK7/zjvkLbL4y6/nYncF8wpb/lRs6ZGQguHC7oTOXpzMwsj eB7BUhSbqTxyIlc5xty5TQcs2aCimQ0qehRLLiwIJO9jnA5EPOUl+zOZtR3RH6k+UCwM Vpez6NG8SbzXYd6Kal7jOSqiDm8HPAl96RLbGzk3EnsytyuJ0tlGziRfr66NCxmH8vr+ mjXkNXia5bC3fOdFQwSHzKsYl63tmoMVnenSDreLLpsy2I/B0XmRY/fa4JXjoqC8TRKF E7jzotDl7oAw9Mfu5ScitlY2+m6zvPu8vf3faHW3W67fRbgQBe2c93WnrJeyosbiOPan 4UizzpNN+eUvC2DvUkLq7ndiKF99D/NslZyX/TwFpjVEjPTYvwx5zXMWpZcRBVSzpSnh o2xXhDyNlFJZdy5FIDdbcV3IclRCR9Fanz9sdXPGQPNl1Erx7ryvPmPXMU4IANMunaqq 9kcHH1QFLOaJE0bi8mTeNCZamB2uPE4IDMY4wRBDdeYg4DzLAQ6ZM4qzS9OEXe5Gyhix g1sToLx1HiPjSPvLyzcvXhMhZb1JL4js3LxfvriSmMnli+vlenm3xMUkGN15Ys8rdLzn eU5cFbHg9g2cKnTn8DOJMqxrVg92z/vSpKLL3UipsH51fI3iWb/ZXt/jdJ93VgxPvjGQ AIHTSpaNjuOLeseJhBzjmLDv+DLsXEwoboXiu0y563I3Uu7wdmPu/vbyq+++/fblX79+ +bV14K8E5EjMvfj61Ilv1A/W77yqJwOpYcERS9ehaUjNbly+Q2/es/fehexPPoXylN26 RGBZl9fJ4nqqbY6TeVLUNYvLL26bsyYDYbWRRxemhXvcjZwNHJn5RBRHe2LGrVXf3S5u lmbJ8uOz3XIZ/UDQYZYn8T8kUMcE5NQSLGWXsiwKzjtBWtusfbwkvZ3VGZ69+kJ1ZI+7 kVLx7p7jHrv7jxLd3J41cqJh3fXvbxcfiT6NbpYC3Fa7mx1AjuXieQUh49hd3SRJpN26 KEGoUkBafqmC0OVupCAs7gHgJsTLTHrZuOlAtIkRBkTnoLvRoMRAp02eJKLHtXTUL5dw IEvOT0aZ68c0G4lBf2eD1RZrTkF2+vDkNrL1vJzGq4RBh/ExE8f44WOZKZ6tPK+ZRV2Z eCIbzip51jt9e/ytm3croWRZFc/BQXWESuUELosx60Lm5JAs2t+ZrpnjtLpUb5/4LeBA iT81jS8qODorUgB7ohFwlwZRutyN1EHf3N+Kl+oP0fVStt/N6WZiNI8724H4f/3uzZmt UZ1z2DxuIh31i7JGnIRP4zY+89IkocvdOEngyHSwbJM4gc6Z4Veb3R1xSaDSwQrvceei h1aLUwejrFaKIstS4oOyTn9Ra3K4f7Db1d9PklizCaYg3LCcSdqDh01BRsBBEWOQewx2 TEGfrSkQIOSJVAxjQg+yhPQGOfuCPZ5GDpqDqY8Zt+ELHwtTCNdhD52QbeV9GkwhftAq ORZkEzpw0KN9eJ8z5/wGJ7eKllHn4jkwyP3NrQNAcOSi/qHxlWlD7BaAgLwcjRzRTdN5 UoEILCCo6qyxgMCMd1IENQmWLdKKHCAGOkhN67VvJ0MLHbTtPnSwLU/PhzHs1Vg10YZ8 ZRxJjnMNYL8cNcGgJkWSyjB3GJysJvYLSE9J0G+3TggGsKNx3YBFKOF5DVtGPCS7C0uE Y6/cVX+qN/6wfvVvlsD/umpD0TsD159c5576umOYOZ6mTf3u+t9sDa66VurJF1TEY3Dc Hb+9cjwGaHUXeRMXUSqAiJQael86vlBlDVOwcT2J10e98cfwyrxO8Vj0xnWkEcBa2RDO 6/PaKo5yMaSZZ3OSwIIah1DRIERxbXCSg3OId1tOprzYcm5yQbaZx6HFEUpBA3F6wz5Z KezXpgM08JCAJCKyEs2bkceoJOlNiQLGcI5YfrsH+grVmtwHTeiA0xFjp9myBCVWYvkv cmuqx93ICWWPTnLYZCVOKhsivWNTx+5QyVa4WfSKQ47bj1ncDkUiMLVH9RunwHDBEvrS 7eJYrILfGO7ZMBjv4XLoYBZkczvuTzqMejM8X2nBfqYyP8aQPEo5PyzRGW6kOk5Y7nQl eqTM2DM4IiuLzYRBPWXqgZ4yomH6jD6R2uI1T3MbGknkUFeUSY4uEL+svUzUjjiKj/gM qZ4lhNh0tBZBR5VbKpxXb7GBmZVlc6F6q8vdSBlc4XlZSJoEe0q/G9Mhu+3sMmJbyVtn /PDvUWnmAMhvpMHIowOYRIN1OjtFg02YaOHaxjhlhqo3AJnHVW+DxKZElSvjY7RXF5p/ MRjMqVuydMQyOa28j+H1zJoW3TUvjbOg8+KxfHu9cf1lmTvtON5wnaJjCT6raxYPHQ67 0fpj3HH7kWEoiy4vqrWkgfHvLHMypkpKlohIEo4lcnwlwzNTihE4sNaeqXulfaKjZccH UQ7MwcOWtF1spw1JWePU6VhzsuDB8yvRFwsn73I3Vvow8BO0zgmiR2xcXpZZwbsOR28s f3pcfrtBzcPs3YctdoAzEJur1cfFWsIDzDlKE9NJUg1zjH69fM8BaZKpLR9jCkZIhq64 tG+naqP98+rgaLeToSZDY01s34mT4eAPHIa6fjLUuNMzIqYucqGUdrkbqYpv5bS9ybE4 MtftCQPILEhISlZFPRYnw90nDAjGqJY52WD6PI0cNqblanO9BHwRfB1xtsPGXx8Ovb45 d4YbhWI6xqfOyyccYz9xcIvUFSEnFxSQm+KaqZL4ZJ726y+1tT9wtCohs3IcXdvc6V+9 RmMdi9l5/dXgLJ3sNLtE5yaxC/74eZHIi00l7LqIkppjf0XEtax45ZqFWxGto9cmCbl/ XLZsjrTG0/Is3mxpi1Aid2EbGustmPHjVcMWrRw2YSVZ0tiAtI74mZIYP3M0hOxzcJtX OCUlEFafWw+bWkcfiFr5wY5oX1fv75pIWyrjNEvqjM1Z6ZsbNnNJqkSSk5lRk57LpR1E vdut/EFGlWOd8o/FRcESomEbAq5JlE9qP5of0tbQiMBJQVBtPfImsrNJqkcZAl5hSh1L sdnzCQyOpP0+7TBlZrLu958j51WNp19Y0KZSTonGknuoZYr9nqZk7JX1Wa6UsItK01qE /fee8xS+AcDUIvV/6tviHeMvahgvXy8niQyTEElQrgKKZZ2mXCWasiQl8NQBgn/ID6f8 vv6aG/SZ50hfoPLtX5Xvi6cNas0GFF6fSGsafR45p0VUM2LBkVQ+kGDLMgkz3h5naJFh nDLmOkM/UyL8J+cjDe5KjhUEZaHSknHOmdrB/SaLTZtCJ2zQNOx/oSnEJ4U4JFKSNoWn LjW8z44HJ7rkPrMnZ0dTmDLXoqH8L7irLJ5dGd3FHfhoqUFJ7wv30qa0or31v8DIzOxv yxjJM8KHlPeV5G2IRjyqgM3HK1ohYXFW1lklGszTyBQtc2yPMAXi7YRpr1AMBWUEhSHz 005F9ZheQVQP6RXTlioD+VKH9Merh8OUjj6yYzMLx0HHa+1O9QGtyBdM9JwxVAk4KzFb T0QiJDVqqSmTcAkt7pxWs4p2j9GoRC2ybyL//KVvlwVB3Ob3II+WVLR/7Kqe3XWa5MMe 7Fq9xnUTz9Po2fK5mEEKH7XwQQvtLXy/tg7bAqbufw1v0Z7/asIUfh0q8/zKmdyCz6TE 1keCrbBcP/s3v0Z9yh8Ih4VlsOlgpj1+4QilJcyeKSHRGqkW9Nn2DikqTGOx1si1YKvO nn3/bThq4hrOSR4MBLMmwHw1BtMb16ywMMhxXOElYcumEwEr7/l43gEvIqQqasJ8K7IE 4VMpTGsRFvvHCgvnFFth+ZrXnUXP1s+j0ggMZV53oWV2aJEfeluZL40EYoC0oIL2fZeG BVDckKg673CElMUN3xros4QkdNNaBO4KEYVDP8JRX0J9ej8i65k6FZ9Np9t9j9xSjtjL Lu7e1Cj7sa6uBL8M1iU8mCW/YDiLddOYFc+JWJdnBScLHsQOuqupYJc9HLZMQLsc38pL ZBZbMaChI+WYF0sfcZnGpbFqOYl+iceyJ7/kUVGlex49BfHO6JKMC8NF+JbtYnCNSU0J VZf7ZgjkWuK8tL657+vDmDWdrXL2piimWsH6KYS9SgvNk6PNvJmJQW4JQQgBJZ+XFXa8 Tzl0PcvJR999gvGcE+oo64n2KXIUMtBcOwiO7wbAQ4xm2wulhEZWacNaeygBQtTnjGF0 aFdpHkY4nlpY0fId4FalgVEdalVK2I7rb/CcG5XQMLuxDtCuviMPPZQS9CVX2qBWAGy0 zslo13iWHdo15QDtmmuDb1N8bh7tih5QtGvKBu22JRFkfz8BgUibMsvlwykCo1u0myao RINmTcmh3R41vG+wpbkvyNShXXNtcGr7C+5KsiZbBMvCEse/YNleSe8Lz9Km1NDe+l/A /27RrvXEUw+0a8r7StPRLkiLbVyi70O0ayfYHlEKsK4TgL0iMRCcdlmIKnSqY1AnnIZt rT3KhImoKPaAMukgXduX4BmjPPrXgfppR8T3fxbQbOaKFmhkfMmIFGrNcYwr20RGjSp8 eRjjYjIq2V43bjOHbvWPSecEmrOJph4Bci1sA+RKigygTYt/TwC5juEzotyRv3CZMFcE pYpJzpR4nIs6Yg/wETA3A11mJRrBSgmA7zfHuUOW5GuMezBoB+cu9m1D7IeeOl4B9LRB TWdxs6YSNRtCz5Tl7qnQM2VfWtqq+ZgO7ki5mIg82fnlhQM45dBhUwFBb6IhbQ1Ndpip BW7mEwz8TEKAlESft08CVfY9eRLwxPtCX0hwKU5U+hderukuJyVlQd/2meRwvj4VgvpH YGcmH3lparFVAYhztMBSaD0POzMSCRYl0WGt3pejzzne7lDxO9KgjhJm+x6SL5eCAxhh rRZlwGu+btdAUfBZgvr50mPLNxv8jiIMOG9ySxtD8YDNtyUWS8Gntu9hpHLlKcq7h5Ez jj3a/gxrDSn+OXOUXMYzNJo66J4pfYGt8ddXxXsY0pTCuLuXrBR+zlGm4k8xTw7XMS3C cog/E+455Eie29bbKsqgxZ+UZ64OVF8SLCmYk7Uqo+HK+O66+DPF0Wr5kNIVLfEn7VI9 zXk5zf0Qf0p9ixz53/yCXLEO5LcVX0rZ1emU9L70SfFn4nqr+HPGN5WAmwZzSkn56FLD +we9rXhI9AwAOyiBLOG6kEwkAf7UaeZlifftJrDK0nGZGMrJYYpvKZyKKl971Eow0ZUr nfp7NcRDaqWdO6EuYiEvw2LWk7oOdDTeVh+EMtlJSso2wdM6WrOabF6lJpRU9HnBnlZl +HwgdOwvfDkQWkzwtUokWon35UkxKBiDj3wHua1/eww6YGkMBiXK6tPiat+BpxFAlE9G n3e/H9+d81s6H6isSRU/9l3DrObUU9yPHpD9/pQzqwaosf4AidqriUg0Y/GNS9Meyjb7 ll0Cpk9ORbtDpZx1MN4YVuN5LsceMFdmg9M9NFPCKfATHEvWN/CnoIJiJog4uEZd0k3Z 7G87Ksuutr65363v/J5mwz/c7ifiXL6IJVuDAURztNBSaD1vF8DtOXuuge0Aj2cFjpdQ 6ytNnwNKulpKAezteQ73eCI7SSEINek/5YsfLQiVT39UxidqASeD7iih5VOa7+Fhikdt vq0QhOqT3twrV56ivHtQMGNcbH+GtYYU/5wfLY8cGC838oocqOXemMcESvH9GdaipSPP Tdvz9yhUAtEVhUo5RKEmSN1iSQy8R6FoghaFUnYoVKgObQb3s1x0hKVnsi3Q8YLSJYdC paQotEu1KNTcd0hQyiEKlWuLMPUXLAqV31aUKWVXp1PS+8K9otDU9dajUBkJizKlpCi0 Sw3vT0ahjExD/t8OCtWJ5oUJoegJ03GhGArYYYpvKZyMKnLHlIvn6riS0P5oLZ7rKRdP 8UqJyejGJhwHT+tDUaZ8zQeu9kLRzsmkdltp1BZ3RlBB1ubd93vosiWs7tB2G/cC9vwd v2cEonZAHvqBC8WhhP3xSaoQhz5+z1+yWLCJckGu0JChI1vwMwky0C+b9aGcR3LmAx14 8wBPQUc77fYPtWx9u+1xvBFgVoJXZ+cMXiXARwCb39B/GjArbtXTwCwnG1KCTxwuFYPc IYgFJa7KZFJpoawkVRF/qkJZ98hjoaz1hXooG1xjIXHs9qCsdaWa+uZ+t/5BKJsXkotd 3kEA9BwttDZaT60G3cMjlrLjpRRGAJ+hRMx5q+Fpw1pKoaU9zxELQWyXgAGtR14FSSnP mRoPZQmmIYpB4LRCWaWE1lNpWouWes95iod+s7ZWCGX1SQ9AlauA4nj3kJS2HG1Ya0jx z/nx81bXj7yHsvp2PK5Qiu8Pbbn3qrVoqUfxdU53qLIl0UJZKYdQVq4dCOWoioey6IEW ylJ2UFaornZwnz1X06Y4V3PZ2OhAWYKveMb4QykplO1Sg/sOTsr9EMrKtYWp+gsWyspv K1SVsqvTKel94V6hLJ9jMb31UFZGwkJVKSmU7VLD+5OhLNuLhLmIb9sLmE40L0y8cDeN VZiOC4WKjheUwxTfUjgZVeSOKRfPlU5+2tqjJJSmtXjO1RpSvFKaZTo24Th4Wh/KMuUr CVLf51V9DJQlpAWV5k6f/B68qo7hh7Dm6QGs2chfuFA0iyXIEuN+fziEldx9R4+n+8gS ggfZtFUxuYi9/QFLY/yqNhdfEMg6BYqe369aGN+gh6KiNU/2q/JJRYFUJMZAyZuLiW5V s20rOTQkR1xiThYNSOtI3AKSyImQkow6ELDnYNb2KSiyv0xDKD3b0ImnqDJi9sV1I/uL uFbDS2ONTUCpdlWcwlrZ3PXPcumwqERCSRxUgMqIwW4w6yEW5WCQoYXmQmleyXMUiZV2 Fez0p+xG2G3aoJajjaCEsWMZsWqxnF8IsShObXIqShip7u3j006I7gn64yhhRFt2sNbw OVCBN67aVohFtS1v4JWrgOJ4DzGl608QWqo9PP6cjmloNnXkFT4gje6Ned6VEvZHaYNa PpKwbWkqFm2PUqU5x0PUrSrlEIvKtUWXsqL2WBRF0GJRKUudWaqlyJR0c59EaqZNwaIF CYy7WBQ542nBolLS4NIuNbxv8Z7cD7GoXFucqb/grmBLsabw0VKDUnuffigW1d4qFqV6 XbrgUhkTxaJSthx1SycElyZEahbA3BCLHhGmIHzFicleoRiITjBdDovXPoUzSrkwQV3A aeZ47ygJ7c+g1vA5htjXcmPT2eHX8Rru8DPlSzkwsg+Ltqdkph+lQsZJ5cVJ1j1hppfp V3UMnxGLjvyFC8WiWAJWx3Lm7imxKBgplgw2F+Rc7bLUcYN2TzhNdq8eafl342AtXSgm 29Vmq7swfywY7buYH4oWKPhuo3HWEt+X2ouJqFZTAUiqTgkVwR64fAFKAVrY3ACSPbMo 0UhQ8HRKboCgjn0Kr5pt50RMS3ycgamNDRcIL8VamswAbUdtZoA0l8pyN3iWy4OYlpNh MfmnOphWaaHZUZo3DMQmpE1aeEzbJoEKzEdLa587TAnNVVrjSyX9Gaz7JwEwfIBBEgE4 TCupw+OKQIcWoyslxLRKG9baQwkwoD5nTJ+LV1Wad1qlylWLTVveA0yrNI9plRK25Poc PqepuEJMqyPvMa2+HQ85lBL0J1PaoFYAX7TO6Zi2jOMW00o5xLRybTFtKWkcNT1Aihpo Ma2ULabVUtS9zwFSaVMgZdnIabnwwFRFpJDFrFJSTNulhvctgpT7IaaVa4tX9RfcVV21 mLaEj5YalBTTCveKabW3HtMyEg7TypgoppWy5ahbmo5pU+YIy/MA0bYTb48oBYjWCcBe kRgIToBoVXAGdcKp2IrgKNXC9HSIVnnvqAidGoNaw+dCRGtHJsSzbqwGaFYme8nxhKNg Vr5zMS1GICWxUyJHPH8vYFYZPh+YHfsLlwlmxQQkNccmAjD76DNTKUHbHDhhrX8T/fkN J+B++zNTPZbOlByg+ysmI+H+k1nRi284r26jaZ7Z3PTjvbdfODNARS6QMJCgwO95qve2 wK0qbbEvLkDXXE0EumwDELfP3o7A7pKzYsZi92liZTm+JcGzWOs0JQpUSHzbgrPe7aNo 0mFzpyHeGR5RA3kL80e6GF6bk2Aybm2nGQK7bDDV5H5QH8YC2NtJiCUZ6KqqkxhASYFl UpIamFnKQYM4J8+tUqK0kiMNZod0SDtMme19Du94FbORF2JeSawkrimPeUvGP2HhoZh3 liolcB21NK0FVuo95ykeI/q2BCQo5tUnPcJVrgKK491jV9pytGGtIcU/58fUAxU/8p4r 9wpbvKFvy/fGJE6U19yv48GNf2haZKxoZYGRvMjE7qSIG1XKMhtcNixzbYFqhcPPw120 QQt3pWzhrpZoJ7hfA5KlTYG7pKTowd2aSDILZ6WkcLdLDe9bcCn3Q7gr1xbK6i+4qzht 4a7w0VKDksJd4VnhrvbWw11GxsFdGSOFu1J2ALxTOgHuSsYQohg6gFfnppcjhtDN4L4c 7ROJvtgM5GhI8FMQkbU65ohC8ewMVYVfRHtlMaw1pPjnkCM3KH4AaKul9eIIWGTxNUmi 8x+CuxNTBKTkGm7kUOkeuGs9YKC6S0oRoAyfEe66IXnoFy4U7qLeEsn58KRwl5D1qpJz q5cDdwcsjQkjeL/6xBdPxgPRTp6A84cR1L0UVSUbpKcCUTwcFogKRBQfTdvS6Hyscgad THuCMIlAA+QIEB3QsH+SO5jAV3EEAFwNEAVCcxwDIOoeFSC659FTjmpJQkkDRDl45roY XgM0G/H6+k7bRJVcm/pyP6h/DIhqit8gpqBN+xtaDlcv8LaSmI5ghCBFFagYZN5xdViK NxLda3aNB0+Q37bMmNshBiWmIg+yBBC7PMff7bMEYMMtJXT1KK3FqW2tPZQQs2lbIQLV X/S40fIUXDu+Qxzp+hL4XLV3x5+zo+KNJusNO9Y+RVX7jjxG0DcZ9kVpg1oB3NA6p3tc a1L3ahSBlEMIKtcOPHZSVKEHWggqZQtBtQQwCe7LiSOFoM0gRVWDj8JCTCkpBO1Sw/sW 8Mn9EILKtYWX+gvuKkhRJXy01KCkEFR4VghK7pJORCs9alNUyZgoBJWyguKwdAIELdBg VTdFlZtge0QpXF7ZLN97RWIgOAHkVMEZ1OlMQ621R5kwEdW/ekCZdPytXeUhi3BRN0Eb A2WiI+L7j8pxozT0trKUJzDryVNUpWjiWs6T/m7wp2P4IXR4ehyrDslDv3Ch+BNB4bPL Hfx58FjW6DhW1qp4XySO/3IA6IClkQB0eSL8jP7BcJ31QFUDpg79oCVr9JPhZ2X9oJmc ui3NxUQ3aFVIbgC2ycyXYoBsmNEhbR2xXCv4Zib1yM5ZN8bEVpxLkBQB+iggb9+jJ6HP TBxI9Mn8EUAcXGKIcczJXdfjDI3aVhYIHFaeHfSAkki7lO2FEHgqLbQVSlM9P0s52dXY Q01qPYjhqUpjVLUWSQ4c7TCFlvY8J3ELJUemQgDKyoJs/pIGXDf+5VOk8okddW+SAchR vAeGCIlerWMUD9t8WyEE1bY8dFSuAorj3YNQyXFk+zOsNaT45/z4hbZTR947r/TteAyg FN8f2nLvWmsx8j2KrzMVhooNcfDOfxcg5RycgYwijOzPm2sLQ4nqCDyh6IMWhlJ2B6uE 6mr7++wd22ACPKGEKSP04cY/WTzcdwFMyR2s6lENn/a+BX2mHMBQc20gZvsLcjUzv+1g pim7OvqFgPA+e5ntdwH4nJrtrXpCZ2YkHAT23wXoUcP7dgLv+S7AgUxVaUYypNhMbC9g OtG8MPHC3TRWYTouFCo6XlAOU3xL4WRUkTumXDxXqjb2Kwntj9biuYPqxjtEacuNTWcc WlrfISohs9nwuwCcput9vXTi/j8nHWpRoHsA6UUGs6aO4Yfg4iMA6chfuFBAiqBUkjUn cIg+ASDFM1fmEhh1OYB0wNIYQCqfsg4O+P8/y2jnqgplbmRzdHJlYW0KZW5kb2JqCjUg MCBvYmoKOTIzNQplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMg MCBSIC9SZXNvdXJjZXMgNiAwIFIgL0NvbnRlbnRzIDQgMCBSIC9NZWRpYUJveCBbMCAw IDYxMiA3OTJdCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4 dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YzLjEgMTEg MCBSCi9GMi4wIDkgMCBSIC9GMS4wIDggMCBSIC9GNC4wIDEyIDAgUiA+PiA+PgplbmRv YmoKMTMgMCBvYmoKPDwgL0xlbmd0aCAxNCAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZp Y2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VFPZFofPvTe9 0BIiICX0GnoJINI7SBUEUYlJgFAChoQmdkQFRhQRKVZkVMABR4ciY0UUC4OCYtcJ8hBQ xsFRREXl3YxrCe+tNfPemv3HWd/Z57fX2Wfvfde6AFD8ggTCdFgBgDShWBTu68FcEhPL xPcCGBABDlgBwOFmZgRH+EQC1Py9PZmZqEjGs/buLoBku9ssv1Amc9b/f5EiN0MkBgAK RdU2PH4mF+UClFOzxRky/wTK9JUpMoYxMhahCaKsIuPEr2z2p+Yru8mYlybkoRpZzhm8 NJ6Mu1DemiXho4wEoVyYJeBno3wHZb1USZoA5fco09P4nEwAMBSZX8znJqFsiTJFFBnu ifICAAiUxDm8cg6L+TlongB4pmfkigSJSWKmEdeYaeXoyGb68bNT+WIxK5TDTeGIeEzP 9LQMjjAXgK9vlkUBJVltmWiR7a0c7e1Z1uZo+b/Z3x5+U/09yHr7VfEm7M+eQYyeWd9s 7KwvvRYA9iRamx2zvpVVALRtBkDl4axP7yAA8gUAtN6c8x6GbF6SxOIMJwuL7OxscwGf ay4r6Df7n4Jvyr+GOfeZy+77VjumFz+BI0kVM2VF5aanpktEzMwMDpfPZP33EP/jwDlp zcnDLJyfwBfxhehVUeiUCYSJaLuFPIFYkC5kCoR/1eF/GDYnBxl+nWsUaHVfAH2FOVC4 SQfIbz0AQyMDJG4/egJ961sQMQrIvrxorZGvc48yev7n+h8LXIpu4UxBIlPm9gyPZHIl oiwZo9+EbMECEpAHdKAKNIEuMAIsYA0cgDNwA94gAISASBADlgMuSAJpQASyQT7YAApB MdgBdoNqcADUgXrQBE6CNnAGXARXwA1wCwyAR0AKhsFLMAHegWkIgvAQFaJBqpAWpA+Z QtYQG1oIeUNBUDgUA8VDiZAQkkD50CaoGCqDqqFDUD30I3Qaughdg/qgB9AgNAb9AX2E EZgC02EN2AC2gNmwOxwIR8LL4ER4FZwHF8Db4Uq4Fj4Ot8IX4RvwACyFX8KTCEDICAPR RlgIG/FEQpBYJAERIWuRIqQCqUWakA6kG7mNSJFx5AMGh6FhmBgWxhnjh1mM4WJWYdZi SjDVmGOYVkwX5jZmEDOB+YKlYtWxplgnrD92CTYRm40txFZgj2BbsJexA9hh7DscDsfA GeIccH64GFwybjWuBLcP14y7gOvDDeEm8Xi8Kt4U74IPwXPwYnwhvgp/HH8e348fxr8n kAlaBGuCDyGWICRsJFQQGgjnCP2EEcI0UYGoT3QihhB5xFxiKbGO2EG8SRwmTpMUSYYk F1IkKZm0gVRJaiJdJj0mvSGTyTpkR3IYWUBeT64knyBfJQ+SP1CUKCYUT0ocRULZTjlK uUB5QHlDpVINqG7UWKqYup1aT71EfUp9L0eTM5fzl+PJrZOrkWuV65d7JU+U15d3l18u nydfIX9K/qb8uAJRwUDBU4GjsFahRuG0wj2FSUWaopViiGKaYolig+I1xVElvJKBkrcS T6lA6bDSJaUhGkLTpXnSuLRNtDraZdowHUc3pPvTk+nF9B/ovfQJZSVlW+Uo5RzlGuWz ylIGwjBg+DNSGaWMk4y7jI/zNOa5z+PP2zavaV7/vCmV+SpuKnyVIpVmlQGVj6pMVW/V FNWdqm2qT9QwaiZqYWrZavvVLquNz6fPd57PnV80/+T8h+qwuol6uPpq9cPqPeqTGpoa vhoZGlUalzTGNRmabprJmuWa5zTHtGhaC7UEWuVa57VeMJWZ7sxUZiWzizmhra7tpy3R PqTdqz2tY6izWGejTrPOE12SLls3Qbdct1N3Qk9LL1gvX69R76E+UZ+tn6S/R79bf8rA 0CDaYItBm8GooYqhv2GeYaPhYyOqkavRKqNaozvGOGO2cYrxPuNbJrCJnUmSSY3JTVPY 1N5UYLrPtM8Ma+ZoJjSrNbvHorDcWVmsRtagOcM8yHyjeZv5Kws9i1iLnRbdFl8s7SxT LessH1kpWQVYbbTqsPrD2sSaa11jfceGauNjs86m3ea1rakt33a/7X07ml2w3Ra7TrvP 9g72Ivsm+zEHPYd4h70O99h0dii7hH3VEevo4bjO8YzjByd7J7HTSaffnVnOKc4NzqML DBfwF9QtGHLRceG4HHKRLmQujF94cKHUVduV41rr+sxN143ndsRtxN3YPdn9uPsrD0sP kUeLx5Snk+cazwteiJevV5FXr7eS92Lvau+nPjo+iT6NPhO+dr6rfS/4Yf0C/Xb63fPX 8Of61/tPBDgErAnoCqQERgRWBz4LMgkSBXUEw8EBwbuCHy/SXyRc1BYCQvxDdoU8CTUM XRX6cxguLDSsJux5uFV4fnh3BC1iRURDxLtIj8jSyEeLjRZLFndGyUfFRdVHTUV7RZdF S5dYLFmz5EaMWowgpj0WHxsVeyR2cqn30t1Lh+Ps4grj7i4zXJaz7NpyteWpy8+ukF/B WXEqHhsfHd8Q/4kTwqnlTK70X7l35QTXk7uH+5LnxivnjfFd+GX8kQSXhLKE0USXxF2J Y0muSRVJ4wJPQbXgdbJf8oHkqZSQlKMpM6nRqc1phLT4tNNCJWGKsCtdMz0nvS/DNKMw Q7rKadXuVROiQNGRTChzWWa7mI7+TPVIjCSbJYNZC7Nqst5nR2WfylHMEeb05Jrkbssd yfPJ+341ZjV3dWe+dv6G/ME17msOrYXWrlzbuU53XcG64fW+649tIG1I2fDLRsuNZRvf bore1FGgUbC+YGiz7+bGQrlCUeG9Lc5bDmzFbBVs7d1ms61q25ciXtH1YsviiuJPJdyS 699ZfVf53cz2hO29pfal+3fgdgh33N3puvNYmWJZXtnQruBdreXM8qLyt7tX7L5WYVtx YA9pj2SPtDKosr1Kr2pH1afqpOqBGo+a5r3qe7ftndrH29e/321/0wGNA8UHPh4UHLx/ yPdQa61BbcVh3OGsw8/rouq6v2d/X39E7Ujxkc9HhUelx8KPddU71Nc3qDeUNsKNksax 43HHb/3g9UN7E6vpUDOjufgEOCE58eLH+B/vngw82XmKfarpJ/2f9rbQWopaodbc1om2 pDZpe0x73+mA050dzh0tP5v/fPSM9pmas8pnS8+RzhWcmzmfd37yQsaF8YuJF4c6V3Q+ urTk0p2usK7ey4GXr17xuXKp2737/FWXq2euOV07fZ19ve2G/Y3WHruell/sfmnpte9t velws/2W462OvgV95/pd+y/e9rp95Y7/nRsDiwb67i6+e/9e3D3pfd790QepD14/zHo4 /Wj9Y+zjoicKTyqeqj+t/dX412apvfTsoNdgz7OIZ4+GuEMv/5X5r0/DBc+pzytGtEbq R61Hz4z5jN16sfTF8MuMl9Pjhb8p/rb3ldGrn353+71nYsnE8GvR65k/St6ovjn61vZt 52To5NN3ae+mp4req74/9oH9oftj9MeR6exP+E+Vn40/d3wJ/PJ4Jm1m5t/3hPP7CmVu ZHN0cmVhbQplbmRvYmoKMTQgMCBvYmoKMjYxMgplbmRvYmoKNyAwIG9iagpbIC9JQ0NC YXNlZCAxMyAwIFIgXQplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlh Qm94IFswIDAgNjEyIDc5Ml0gL0NvdW50IDEgL0tpZHMgWyAyIDAgUiBdID4+CmVuZG9i agoxNSAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIgPj4KZW5kb2Jq CjE2IDAgb2JqCjw8IC9MZW5ndGggMTcgMCBSIC9MZW5ndGgxIDg5MjQgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvVoLeFRFlj5Vt/PuTnceHZI0JLdpAsgNhIeP BFvoPDojBLATgnaDQgc6EEAgkvB+pEUDscEH6Mh86ijuzM63j1FuOnHsrGKyuvjJ7riD rK9ZXUEdH9+u7DizjviNLr1/3Xu7IZmMH/vp7u2c+qvOqXPq1KlTde/tTufmLa1koTBJ 5Fva0r6atGu8CihftaGlXW87vwEWr9raKevt7HSi1F+sbl+zQW/nDxFZZq25fUdCX/Tz tLW2hHQ5Cf1r28DQ2+xq4IS2DZ3b9bbzC2D67ZtWGfLxhWinbmjZboxP76Itb2zZ0Kr3 H98DnNy+qaPTaAe19uZWoz/zE5mPEwOX0zay0k2UhpaNptMuopRzllmYL9PkqSzVGlh/ fIXV/QfmwLRw9Xe99LzAoZQTH17Y+keHxZmxEM0Mrb8QwG7a8xd9mHPJha0Xai3OpERI xcVjdIcSozWg20CLlepsMOvJBuLUxeuI8bncDT2Fz+HuKFN++xy/Acwb0MgvpROQ2UCc HWA90eJST4zd02crqKLqbNZDNhBnd7Fu2FLY3QbuZ91RroSfY10we5bt9qxmZ88VjBn7 +hsodu0ucFh3le6q2CXt2l302hmwtm5DsaEdxe2bUKzfWOBYsbFrPV+/sWtzceeWfPvY NetQrF6LorUt33F/67HW061Sa1v3HcVFHQU7a4ucO0B8QGqS5mNk2wmpnnwgTh6pKpqV XTUQH5Iqo9lGpS/DXOWrzpKmEpOmSzOwAgr/gv8XpQM/jL7AlRh/t++FEObK3+mbMbtK YNQ1SVhBJT9fq/w6OqvKqEyZZlScLqMypsioZOdoldPRHFR4mG8X7lUrvJN8II7Q3oba bahl8QXkAK0HSWg1oNVAnM/mJiqgUl4JzAXO5DNEsPl0AyuAJeBP4zOiJaVyDJBbUDXA LrAPo5KSWS2zL4ix37L/FFrsvIGfGfgfBn7KPhFhYB8DTcCPgOgf/0f2YV8WXK8eBwaj rSj3CxF7iB3RDD5o4BH2AKVC8TAwDXg/UAx4H3sAUx4cRJNRO8qwELBbokdMSowtjh4W cFP0qIBr+7okBQlWFc0trKrOYBNYmeaUjeVoaPJc/w3C95XvK+75uLi46pFHJeWxR03K o0czlQdh7/CRVOUILP0Q9KOjXHn4qKQcO8qeOHr86OBR6XnpRmmemJw0L9rNFZEStX22 nKrSFyRsAjonSuka6WpETa7OlWbRdJAH5AOZpFlSvnBCmmlghZSPnhWDaGIXIntkEOef R0+kIn8+iA6miyH4+9Exk7UUeD+KXIjxc9EDmZCf7Rs0Yar8rT5Xmcivt6J2LBr6n4nC pWoLf5mfFPHkL/IhDf/ewEPC9+f5Vr5NTIVvM6bC79CnwjeLqWilhwcTRoPRzCzN+oro mEKtsjw64SqtslTTq87nyzRFUVr5fJQFfB5NBHHK4FOpCMThnhLNsWt6V/VZcqqQbS6R bSf4eC6L5eZOLkdNyinYk3GGlKAUm6tUl7Iv2a+0hTzHniGZnOwseyY60SnH2NloibOq upj9G3tXy5p3DPxXA39t4NvsLc3AW+xNrd+b7HVklzqIJmNvsNc15r9ozLXVWewM5jEg SnbGkL2myTDi6SgOgQHk969EfiuD7Cf0U1A/SIqfYz+L5tmxDOxedkgb8KCBEaBI65uj +3FMsCXRsARoju5PATRFDwhojPYI8EV7hGxRtFvAArFQMVYZPSBgRnRQMMfrzGxPFoR/ /NqkfC06xYc8mX8QifklO/clE82MXvvYKs9HSHnRmnbcYq2Cp55+X3+wv70/3D/Uf7r/ XP/n/Rn9x0Oln35iUu6JpCmRg6nKIRBUnr1v+syq++7FkFDPv7fEVXXvQa4c7E5X9t1p Uu4Uc4gP9YXnLxT2+8Jza3W8ukrHydO0cc3hca6q8F6udO3VrHrMe7zzqvagsReWhGm5 B6Z7MMMDYOzvTlXuujtTuRvY3h3u5oPdrDpTWiw1U7bkkxpRLpJuEmVUCpVWL5EWSAvJ KjmksdI4MktWySblAM2SRcoGTgJeRRbJCbkLWAK5DJxEbskJKgE5QFaQmdz8Kf40P05m /iT/C/4T4OP8CX4MOAB8jiy8D/JngCrkUeAAdPpAqtAFPQl6HHQn30fZfC/vQrmb7xGl 5u8WvpPvwl6x8RyeC7sWns2tQMY5l8jMLrI4x70fJ3kOPQrioi/Oehs9ARoEnQWl4OS2 0FxQF0iiUnYR+6YIug74lAebdmAR/MgD2UAWUCqIkRt93ewEe4ENYrxeFmV9wKfZcaYC TwH/iSzsJchPAocgfxF4CjovgYaELqgX9DRoA9vINkGvha1kq4DL2QoW1Nqro2NKS6tr 2GqaC+oCSWwHpLtgrQNaW4Dt0NoM3AFLHaB2YRG0GtQCWg4qZ1PJyiaySSgns6som01h CspCVgROLstDmc/s4BSwMShTWCpKziSU2MKi9PwVUuVi3Oq4zl54rd1+jT33art1lt08 054xw5463S5V2GmafeKk7MmTrFOU7HLFOt6VPcFlLSnNlkutVluOOSMzy5yalm6WTClm RNpMkiev2EVSXmmqNLa01DrX2mWVZImVSjdJg1JcMjnYOEthWrHFbhtjyTXlWx5wsHL3 FPdk90T3BPd4t+wucTvchW67O9dtdWe4U92Sm9y+WUzNbaCG5ho1jwEX16izlIaYJDep M5UGNcO3zN/L2H0BcFXeE2PUrJp6YhyQW7t0mT/GioS42zEg5q02BLvvDfRyqlFZj+pa 7BfgafSrck/MRs3+Xs5qAoGAel2DD3WqCSjj1FADuoXHBdSZovLAuAA1qLMbVYerRhl5 dQhGR6cGl2S9kyd61SneFrXcG6y7xFYUQgMOe9WL3pYY465hwkTHEcYSbGAHLqMZ47u9 Mb4TZvje0c0k9WLSIm9MWoCukk907exgSdkolY5OMJlWjpRqg3dugSPDJGDg6kAYhKqI hwaXFZrbHbqALhdT0lKCm8DLBrls2oZNodWhsFq/I6AoaqHqQpIkFAyLAliM7Za96+pi bI8Oe3Xo0iGsw5067NPhLh3u1qFbh/06HNChR4d7BBgzw1PJ9RqXu3W4QYc5OszVwaND tQ41OtTqUKeDV4d6HX4gAHHD3Dp6M0T2+5pqGtT0JpBvmVrsQuMVNK5Fw+yqoVSFivBm 9AqVJUr9RUYvTXNIvJFR/B2t/DRRv7glrtWJLr4teN/lEu9egkzfxYjQPUk4UOPXxw/H v6BBaqP8eHX8R/HPRjW7L76XztIZOkX99BQ9Su+hfpJeoAH6W/oQ9ZdRe4p+SCuh/VP6 MXUD/4aepIdoM/gCBefkn9pmk4fxLtAFOsqqaT5w5PUQrDw0kvln2x/Hi0eRvRcfT7tp N9/Cf0Nb8HkEFn9Oxy7ruRb1v6QOvP+eZOdpJXueVmM+PRSi+7kv/u8pp6hA2o5Xnk2m YyIThl0Pk592UEh6LP475Ik1zYeb6vH478S79LDr2/ptwtiJa4AOsUzai7jNwJv5I1ST EAxHxPAC5rAKc9mHz1GsRh8+uzHu4ct7ptaJVsLvdNKzNZFHKeK7BlzxT0DbtepJEW8j Y9+nrRjBTVPxOmeNlyJvboy3xnfEfxw/gWwQq/8zIysG0fprOsyOwoOVdCvdzH+JFzvR 2oT2zTSfjWMWehy2r9FGSRbGrpJ0hshxcSX8MxlRNPYWvNSv+PWJGjuCG/MFeoVeopjm z2N0hCIURhw6kd9LyQffZ+NrCb3fR1oOC88v9VlOzcg9XMjBOZjPewnbAlPe0Pa+8d3N n/gn9v5J6UVdR0RRvy4mKkSvYiX13dCDaGxBPFZhZS9ou0es30ms2pPItYTs5qT0ZW1t Rf85NFN4EZ8d34vY/zPdQpt4Hx5Y7oJez6WhkrWfg5vI5EJ6j81JSoZXvkve78YeOkkP DzPYTbdR6zDOiMbI+I0Qj9JMOY9Hx4ewar/AeLvw2T1KpwHk90nEaSc1UjUdwDq+h/3R hj0cQsTPMBnr8xpOsdGuFtg9jVXZJK2WjFUerRsyRHxGuVLO68x0YiZkfjJ3E1313E20 huGcFIneZrnIjwfpbeTEU/QszpI1goss1q//3Rrto400xfiQx9M070b39bOrKq+79pqr Z82cMb1i2tRyZcpVkydNLJvgGu+US0vGjXUUFxWOKbDn5+Xm2KzZFnNWZkZ6WmqKScLz fDkrVAtr/d51alFtEPfCOpdNVs2LPl9YoVKuw+nKkWdVBKYavdQURaW8BjUfz3zkqQyo qcrILotUqcz2eyeUFzpkr2oqw59rfktIndzkd7psbzqS8gDMqsW1fqfTofIy/M2DCH/z W+SQavOBD4HGmaeSzy8oFv+gEkyqdAZQNvnVkkQTj6KjODmAHTU0ws1FLGLrNRfV1qmU 30vmD1Syi26fVxJewtTJeDQus6GmWaMKleX/XmV5KrMvxJSGDyHUzlWOEgNvaJ3LG1qL iIaCl2L6uR5RpxyRI03+nFkOp1NzGk8ijf7erMxaV21rJmaBh2YwqDczC5wswcCytPcy 8xymVbjZOxtP3OkWhC9XuOsVtE71HAyi4qpD3CDJuyTBS/Khy0UENb0ToZtWY9qYamqt mqY7Ia9VPS0qHZR7y4cih/DEvzKomEOuUMutflVqgVO9JJV525rVsQ2+pWDBCVCwTRbL XacVYvFkb5scQVv0DaJ01UF1OD/U1hoUacKCrjrIMmr9B5xDDryS+A941RxFtUDdsvM3 DiniLVwri2YkckBWj+FV5DKpU/RBEhROLZcjXhdGgzHvuhqxYhXJZdOycV5IWxzPwRZZ Da9ch5jhr+VQIv+dEZtq/tKJ1cH6QFPsDhFgQaHgOjGVddA0AeTIwVZtqoe0qSFfxWOn IKGI7Kcl0F7q97a5vIinMSACAn2pbKSu06kWKUIxEvEKF1tC8F5EBn9FeFiHG3oDe8Kh MPhTq3qaNaBmbQ0woqelLmCwjA6QmLAOqidYFwiISekLoKaVHUiZ5pIjwmhamZqv2Jz/ ANnQ1PKGJr+3TmQnevJa/w3nCx3nUceLXoLNCtEnUnFeBElIFrsaGvUsaBPxEUWwWd/A iJqx8uhq9NesvlroeBW69a76YCRS75LrI8FISyweXumSba5Ir9kcafcGZW3nM/D/7qBD rT8UUG3BNjYbiyzyrR5P8HmNy8Ty1MttLeDgb67LWelw5sC03gcnx+hiY58h45H3Yp9F bJ9hxmacSA65XhwvMZwKDtVWKbYpPFnixz5YhSG8Ia3A/sBrLneInSIFyrxrFxsBcjgx pJYw4txrNLgw4nSKPXQw5qGVaKjhRr/elmmlI0qeCgVrFxSSoYTEvkRIwglJUj3owloV itdsLSf+XE7jPE/mcyTHlStXicMc3uFvXkgdasYcv6pU0xExbbnzav2Sg4suqHGHJGqZ Cm4JbnWMoimKmOCUjNhc8mmXalPUlFr/kMMdkG05OCBZMhkMiyJNbaddp5g4RCnfpjK3 ygrEtiIcqggjDv0xlRAmFWVvJGhk3+XzQ1fRO9SW3Ef6LLBxxSQRBpsL+9ahxyMn1yWm +kuR7foNTk0pqxebCmujRWx+QM0WNzs1+zOtwOQctX4ZxxC2baNWkb1ym1h1VQ7WaedB wCHkCXYsfi5YJ84/PxINXRxGfiPLETZjTxhhaGj2J2pN/j2OnYGp+FWsvCFGGbiTiu9k YizeHaO6cQP4nU1asRzi5nJZ9q6tw4BoLCkHY4oTtZvLkZsi9f2ugLiTzAtFZJH8IUxL QwhaI4EK5OtiP85LfFXjVD0BR7LaGgjMhp1bhB2ooHskAAvrDAtAjVXx3+jkL2/ASTXR 58dhG65DoteJLYzpDmFXDYkZi4kEkp7C4z1rCw2fl8LnwBTIl+lWkKthmAhEIsLmYr8L aR6JOCKYh9HGNzwjGR6DESOhgol7Yyzsgy7ApT0feF1Ol4h8oA5D3Yq4J04p/Pb47RFe nvQbmivg7XItwsHvKcItVxLhlVcU4VVJT4dFOASfV4kIt44eYZVP/JYYXx5Sjx5Szygh XT0spGu+PaRtSUfh1Vq416aFdN33FNL1VxLS268opBuSng4L6Ub4vEGEdNPoIf2/SNr2 YRG+49sjvDnpN5zsgLebtQh3fk8R3nIlEd56RRHelvR0WIS3w+dtIsI7/v8ivPOyCOOH TWa8eKGiV81gmsEU/8mQEMokg4M3JHxDgA9+Jkmj/GdTuYkEVbz6+qtaMWO6M8eZU4aC 4b3wG48U/iacQl+TxxSGJn6A0a54Jd5TR7uEXB+R4Yd2vZZKeUSNCxY0LVygLNiyam2o 5QebWzaGtNduvYewZAONjRuXYCTrRp//AU+fgLUKZW5kc3RyZWFtCmVuZG9iagoxNyAw IG9iago0NzUwCmVuZG9iagoxOCAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3Ig L0FzY2VudCA5NjcgL0NhcEhlaWdodCA3MjMgL0Rlc2NlbnQgLTIxMSAvRmxhZ3MgNAov Rm9udEJCb3ggWy0xMDY3IC03MzcgMTY0MSAxMTYyXSAvRm9udE5hbWUgL1FMTFJNTCtM dWNpZGFHcmFuZGUgL0l0YWxpY0FuZ2xlCjAgL1N0ZW1WIDEwMyAvQXZnV2lkdGggLTQ5 MCAvTWF4V2lkdGggMTY0MCAvU3RlbUggNzcgL1hIZWlnaHQgNTMwIC9Gb250RmlsZTIK MTYgMCBSID4+CmVuZG9iagoxOSAwIG9iagpbIDAgXQplbmRvYmoKMjAgMCBvYmoKPDwg L0xlbmd0aCAyMSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZDB bsMgDIbvPIWP3aEi6RkhTZ0q5bB2WtYHIOBESAsghxzy9jMs7aQh+cD/+zM/lufurQs+ g/ygaHvMMPrgCJe4kkUYcPJBtCdw3ub9VjU7myQkw/22ZJy7MEZQSgDIT0aWTBscXl0c 8KVoN3JIPkxwuJ/7qvRrSt84Y8jQCK3B4cjj3k26mhlBVvTYOfZ93o5M/XV8bQmBEzHR /kay0eGSjEUyYUKhmkary0ULDO6ftQPDuHeeWq1KNXxq/8MpaPniM5JdiThN3UMNWgL4 gM9VpZjKg7V+AG2acBAKZW5kc3RyZWFtCmVuZG9iagoyMSAwIG9iagoyMjMKZW5kb2Jq CjExIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZv bnQgL1FMTFJNTCtMdWNpZGFHcmFuZGUgL0ZvbnREZXNjcmlwdG9yCjE4IDAgUiAvV2lk dGhzIDE5IDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAzMyAvVG9Vbmljb2RlIDIw IDAgUiA+PgplbmRvYmoKMjIgMCBvYmoKPDwgL0xlbmd0aCAyMyAwIFIgL0xlbmd0aDEg MTQ2MzYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBhXoLfFTF9f/M3Hv3 7nvvbja7m+xm9242WR5LBJJACERyAwk+AvIMZjEpCRDlpYABFBSJVkEiCrWVivWtrWir bB7gJmhN1WrFUmmxWK0PaqlSf41Q/5SqkOz/O3c3KP356W/vnpkzM+fO45wzZ87M3LXX r2shVtJGBKItvrZ5NdF/uaMQvbx4/Vo1nbb5CDHMu3r1Ndem01krkb7umpUbrk6n/QFC 8h5f2tK8JJ0m5xCPX4qMdJqWIi5Yeu3aG9PpnPcRz1q5anGmPPcU0iOvbb4x0z7h5ep1 zde2pOnLrTy9elXr2nR6Qh/i6auvb8nQ03pCLL/s2589VS9/OwexnRCKlJt8QSrIQ0Qm jChkNJlPiPgLMY9ISPNyydHww96nJix0VPzL6Dfqrz/+12EjOfLrnyy68uu9A9coxMjb N+n0vADvyZMHryBTFfL13q83KumWeMnQz91D5gnDu6K+0OEXhBHkGIAJIzpjeaEeYZiQ 1zkppCWFSJcru9hRVSSoqHG0HqoIVwH2Al4CiGShEESpgnAzoA2wF/AS4DDAQAhCXqoC VgEeARwDGIQ8IdCphpSqYUIO3s3BeB2Cl5wEpAACCSEcDZgJWAjYAXgEYNDpeM4qwGbA S4BTAAPRBG/nvSXou7fzLj3qWr6yWE82p5MNjXqy68p4Op4xOx1XX5Ymm5gmG1uazr5o SjoeNioduwqL21B5l9lW3FflETwYpAcdX42QsleJg1ISIo8K2SQBYAK6qudogqurIFr8 yEuCSKjABEqWkFCqT6CdNmdxlZml2EniIiH2OetPl7D+Lruz+JGqy9nHZC/gJYDAPsbz F/YXspkd4zxHWAl4BPAS4C3ASYCBHcPzEZ4P2YfEwT4gowGVgIWARwAvAU4CZPYBQoW9 zzVGDzleCWDsfYQK+zOG9WeEDvYesPfYe6k+dqSzrLy4R0diozNIqDCDeP0ZxOUpTrI/ dH41AhoVhaShUQeEfDKZlAj5nYVjQ0nB11mxLJRkf+1SY6FHq8awt0kCwNCTt9Hy20QF zAI0AVYDDMCOAjtK2gA7AY8CEgBoGUIFoLKDgN8CjpIxAA0wC2BkhzvRTJK91RmdEqry sN+x14kXHD/EfqPHv2Wv6fGb7Nd6/AbiIMoPstc6gyFSZUE5wTsKYgXxaJRL7FddBa5Q qsrJXgIHQwhHAyoBMwELATsABvYSy+9cEnKhkgPkIOZwiHWSv+vxz8jjRqItD2nRqVBA lQfRiRcDQ/CI+kiUadFdu5HkQfSee4HxIHr7dmA8iG68FRgPoivXA+NBdMlyYDyILlgI jAfRmfOAIUiyh58vGBYqm7mCqlUOdgO4dAO4dAO4dAMR2Q38IV+JvI8/6Rw5Ehx7QIuN GBlq66VtL9C2ObTtcdrWQttuoW230rYK2vY92hajbQHaFqRtGm07QCeAFW1U674gWa75 aNtB2vYsbWulbVHaVkjbCmibSsu0JAt3XoZZh6hGj7qq+KRj4a6LJ8P6OFgYHA1D58Ow CS8hfAuQ0lMaiNT8NHFOkMf5XSMr0+mLJhavqrqUvYIXX4EYXiEfAUQI6BWo0Suo5BVU 50BYCVgI6AOcBKQABlDnYxw79NCBcDSgErAQsBlwEmDQu3MSXWFkFULexb16x0YjrATM 5Cn2Cp58PGEW1vKUgBJTLhV2BKgjSGcGU0FWRjwe2GWX0+hMUtv+f9u+/LeNmKpM7B62 g+RBEDsz8Y7Or/JCSXp/Z/RAqCqb/pgERWgdLSdRWoh4AmnV0+NIwMjzS0mA/RxxcWdg Pl5zdEZHhXqpnb+1P/RV4Hjo74EkA3oicCD0jpoUaWfoj8j5+f7Q24FtoTdGJ43IeSGa pIh6VZ20JzAh9OxBnfRWFDzQGbqFR/tDmwKXhFYE9IKWdMH3WpHSHKE50QWhS1FfdWBR SGtFnftDlYHvhSrSVOP4O/tDY9CFWBodic6OCOiNRoJ6hXVlSbpUGyXvkuvlmfJ4uVge JYflkJwn+2W30WVUjHaj1Wg2Go0Go2hkRmJ0J1PHtBhf9dwGffEzQKEpEXVcgYWh3Mwg JIwaGbmcJLKEWlY7dwqtTfQtJrWL1MSZuZEkNc9ekJAiU2jCVUtq501JTIjVJuXUnERZ rDYhz7qqvoPSe+LITbA7k5TMq0/SFM+6w59wTa3vIZQ677jbz+Phd9wdjxOfZ32lr9I1 2Vk+rfo7giY9s6k69s3P9w0a88XyErtq59YnnsmLJ4o5ksqL1yZ+OFdtqO+hX9BTNdU9 9J88itf3CJPpFzVzeL4wuToer03S+TodUek/QQeNQQQ6IxZmTkdUYzBN90CarhDvg66A R6AzmUihTldoMul0IuV0Ha0FNdUdBQhA41VJq07T6lW/TXOwEDSFCEDjaSMHdZqDnjZO k5isVxMIgCSIACQ0lwR0kgDN1Un0nnfoJKMzJNvOk2zTWxLSvdFpeIBqbMeGaGzHQPMt Rv53tGVKLEa7JsUXN9S0RGqaIjUtgKbEXeuX+hJti1S1Y3GcF6gJIdq0aPFSHje3JOKR lurE4ki12jFJf+8/iht48aRIdQdpqJlX39GgtVR3TtIm1USaq+Ndl8wqLbugrW3n2yqd 9R1tzeKVlfK2LtHf+4+2ynjxJbytMt5WGW/rEu0SvS2i6/is+g4jmRKfCvnxuItZzNDX Jn84PsWjrJ6sK++ksO8Wfy+8lT3EEosnrJEpCRuA63VRVVEVL8Kc4kV2ZDsyRb5bJoX9 vXRPpkhBtjMyhcTWrmtdR3w1y6rT/1b8kLV2HRdFOozxvO/8gaQmoTVXc9+6NjFybm2i cvaC+g5ZRm5TdRx5E4fyLJaaZKovnXkRMidyQkE4T8jzKnieyZQh/N+6oPcJ2eBODxyN A11UC9K1pDUuJIK18xhMwbwFYEPDgvpe+FJ8kWiNY4CtNEZbh2rj49Bxks4hGHbrEKxd l8EyvFibiXXS1hiJtQ6xZKi6GGeWHui8WhuDaZN6SQ4gV3qK5IhRgv1P6lPACR4PLkud 4OU8Zp/B0CUzQMge8ixdRp4lL5GX6Sm8tZf0kG7CXaBq8iC5mfyIbMWytgA528gcPBLy f0RzUt3YmTyGBfMxcgi0V5JbSC/xUF/q72QzuUM4grfuIDaST6rILLKK3E2np9aRBvKR +H1SRqaT68hq2paqT92Tujf1JPkp6RF+kxogFpJLFuM5lPpc+lPqfVKEN+4ju8lH9F7T PqKhlTZQPkSuJw8IjSJNXZP6Gj0IkxvQB5HMIIdoH4uh9hbyKfXRm4WpqOWJVCL1KqgC pJEsJQ+QXjqOXsLCUkNqRuoQ8aCNG1HrbtJJ9uNJkhfJe9QqnUo9mTpFcsgochnG001+ R/uEwYFbByvBNwlcGkHKUbKK/JK8Tg7TCP0VWyVZpWJJkzam3sYObiypQ2+fwpuf0H+z W/BsFl4Tp6WmYJN3B/kB5zb5NfkLzaWj6Uw6n41gq9jDwvXEiBbH4llCloHf96P2D6FG +5mVvSU8If5cPGvIGzyWskMiUfIT8hD5FbVhpCptpbfRo/SvbCpbyH7CPhZ+JD4t/kFu xqi/R64ld5Ofk39TF51AZ9Or6FJ6M91Kf0B300P0MD3Bqtg8toKdFJYKa4QXxSl45oqt 4velLdJdhhOD9YOvDv5+8N+p4tQWMhv6cCt6fx95GCPrIW+Rd/F8RD6mErVQOx6Vhmkd vQnPLfRu+jjdQ5+m3WjlMP2Y/h1L0r/oWYaVlhmYH84Pd4Ei7Hp4mD9iD7K38Bxm/2Bf CV4hX4gJ44QKIS6sQq+2Cjvx7BP+IuaKb4kp8LlY2iU9Iu2Rfi69LJ0yWOXbsMb/9twT AyMHPhwkg3cO7hrsHOxO/YVkQ4ZYPbAFq0Dvm/Esh7x3QeP2kiPUCt7l0pF0Mp0Oziyk y+kaeiM4eTt9gP5U7/tz9AVw6R16En22sYDe54vYODaFzcTzPdbC1sAZu5d1s6Psa0EW LIJDyBZGCpcIjUKLsFbYIOwSEsJvhQ+Ej4Uzwjk8KdEshsR8MSrGxEvEheI68WHxU/FT qUF6U/qbwWy41rDFkDT8E17NZHmWPFtulHfI++W3jU3QzlfIPvI8NPD8jx4TbhVqhH3k HlYi5mAL8zvo80KyRJjBoKlsD72TbaLdrEC60TCJTaJXkFNiFLx+jT3CzrBJwgxaS+eS 5WxsukKDW3wGWIX4CukXX8DYfoeabzRY6S3spMFKOuEjlcNH+rUwRowJb5L3hI+oLD5G /iyaqZf2s6eEWdCCF8XJUj0JCw+S54Q1dBPZx2oIMZ81boceX0GfgV2YR4vpl0IKbvAV 0KIy4a/k+2QF+xPpxzy+k/yYLhGvIfeQEnoz+ZT8DLNihHSdYaQhm77BlontLIt2EyY+ jdGV0wIqSG5yO20UHjCcZO+SdeQt0Uw+FH6B3r/FnhNmiKekOXQpZsAmsoWsSd1KNkj1 4h/oNUSg80mheAzW7WahWAwj3gyr0gCbth+zuxd2oEqYgRwfNGc69KIOFuIBPPfDTojQ oGWY41fCiv2OdBvmsSS5RrJTWB2c1Lw5OIcsSP2M7E5dQ65L3UuKYA+2pm5GjXvI38gO sofeMXgTWY2t5LuY29OlaewtaVqqiLWzd9lctutC+YLbhdRHPsPzHCQzWTpA2sV3yFxS mdqe+iO0ezgs7G6yCA7rcYzyc7RwqdBHSgavYB2pacJqjPcjMjv1VCpEzWRpaiWZSV4g P5Ul0izHIOME/QPGexNpYXNSa4WWwWXgww5wQQO31sH+bNOm1s2r0ionX1wxaWL5hLJx pSXFY8eMvqhoVGzkiOHDooUFkfywGgrmBfy5OT6vJ9ud5XIqDrvNajGbjLJBEgVGyaia yLQmNRFtSojRyKWXFvF0pBkZzd/KaEqoyJp2IU1C5e81o+gCSg2UV/8HpZam1M5TUkWt IBVFo9SaiJo4VB1Rk3TB7Hrgd1dH4mqiX8dn6PhOHbcBD4fxglrjW1qtJmiTWpOYtn5p e01TddEo2mExT41MbTEXjSIdZgtQC7CEN7K6g3onUx1h3pqJHYwYbRhiIjdSXZPIieBV VCMU1jQvScyaXV9T7Q+H40WjEnTq4siiBOGeUkwnIVP1ZhKGqQlZb0ZdBh8nQe5SO0b1 tW9PKmRRU8y6JLKkuaE+ITSjjpqEM4Z2qxPejcd93yRROXyyrd8u9QvtNb5lKidub9+q Jh6dXf+td/1hXkM8jjrwLiuc1tQ+DU1vh6RquS+eYHfE6xP0DjQJx7JQH1V6fGmvt7Bp uZowRaZElrYvb4JoctsTZM6GcGdurtaTOkZya9T2efWRcKLSH4k3Vwc63KR9zoauHE3N ubCkaFSH4kwztsPuyCBW27eRFjA9XaZjOjnHauec5yzlfYxcBk8woS5W0ZP6CMY0gQct E0j74gkQAH5xircSSyCRZQnT1KZ2ZSLPxxBpQipUImr7vwg0INL/jwtzmjM5hkLlX4QX cj05r2oJ2jyEJ2KxxMiRXEXkqZAp+jhZT48rGrU+ySKR1Qr2z3zTQGaBt83xiaPB/nCY C/iupEYWIZFom12fTqtkkb+TaKPhW7MmXtI3VJJdx0vahkrOv94UgSZ38/0syU4Yo+f/ DsWTVbN0YoJ6/ktxS7q8dm6kFq6xWtPelNHa2nkXpNLlnKHgG8oyWCJrar3gZ8jjGPML emnaQx4igbtcb02IhfgbdKVekpSN0Eo9h6rTEkrTpekwbg6HM3Pm/3opmTrF39Kjb17L DCMxMZbpaLrbiUkXpC/onrVdqJ0Hk8Pg2be3my8og6qle3lZJoLGY6MfVqcmSB1mZiH+ 2HJM4BD3JzSwDCXzMIv07Lg/k7yA0J95KY4f186iUdNgM9vbp0XUae1N7c3JVNuiiKpE 2nvYy+zl9tU1sHZpxUmmeu/yJ6Ztj4NjS+lETA9GpnRE6J2zOzR659wF9T044lDvnFff ySib2jQl3lGAsvoelRBNz2U8l2dyEpUnSC3FIDuZUaf392iEtOmlop6hpxfjdEPPSxMh j5LFSZbOU4boGPLEdJ6m5/HxcRszdV59Riy6QvCpBx3CDQ2q4T4GB7GV1AE+AlQA5gNy ATxvBsp7pPlkl+EZcj/ihwENyK8FbB0C0BQQggr5JCC4MTLA2yBEhWeeztGzvyNg2C2I 8PINuIEx4g4l/TN/B+WFWRYk+a0Lwb6H/3Cd83/+HDoFRHT+5wTmyqSyMnE2VvoZ8J92 w6f5iVgrDTdkGarkBuM/TWvNb1j2WDfaGu2V9t+DGsst36BIuGRB70nYGXYWIsBJFzmn Cn3nNImcJarYx/mCfSErl46Acm4PEVIfdrrLWTL1oaa6y38sUCY8IuzFxcR6Qt2gRsUC MQsnCDtBk/TpfZBP10ZfTKlQTvcr/aSyorJiq3RRrHGT8urYMbQxFsumJZQ+vXOwPkf6 x9eogZG61KeiU+rDnVYereuA3s2r18y5QVFyB202rymZOtHtcLA6jmg5NhswJ7HyHOKx WhFaeR4ZjT3wIQSHSGV/Zf/YMf4Ow/+u6TRqMvCaPum22XTkcy3HYgHmJArPIYrVykOe d77Kb+rsNqg5SgCGBFPC8kssYh6AC+DAMeIi0bCV3Wm50/GGXTLJFh+ryZqefXnOVP+8 rIbshpw5/hXyCsvirJXZK3Ka/BvYDYb1lo2OrYb75V3KG7732FHDUcufHbnnB95q0sKR 0jEmSkyKiZl2hpytBMZDsyNXhSvGyM7g63eB1WcaY/0I1sTAbn3otHENNrUT+I8C4vEs xTW+pNjjcWUrzBDJHxbNUjwlxeOdSjSSLxvqVhx5dH3n2inLjzz29oYf9Dx9881PP33L zZc3siNUpBf/YmHXYOq9wcHBV569/3n60OCPT57CTnH558u2cF35CAI8C9mZyV5NFTSb s3SFuJntYLuNuJqkJmKQmGCSqJXRg2a992Y+JkJVvIuj125FgeiSqc80py7QgC5Quy5Q cFnL4eIakokun1yrpNkcpdIQJ8ZIVMXumkk5ll5aQe8gvtgVynEwA3zJnIogUTFjoIJU VnrLqbOcqyFpjIUjToNBHjd+fFkJO9tddWTejz8evVa8afLNoecuObiQj60CuixjbEH6 ekaXTE7F5svKMtTZkqnT3U6njnyumRQFWNAtBbmKejlBMMhLgwE7SoJQUIRJdkCzMrPX i5tMJ2NqyOkqH/32IR4eIqP7eWcrefgqXGl/ZhrwBq0uF9Mb1EwOJ7B0O8c0iyuL1QXd PI/X3Ymq+VSxWFgdkH9oOhe/qzU+R3h7vDW9MW38JGmS4YD0kuGA/LrxjYB8mTVunWdf YV1i3+jamLXN9YLrb7l/85/Ktb5keT6L+XExkacEFcMvcRQiQ/mNiE2QVm7QrBgNhoOB XHcgkGsM5MJaGHMDgi2oJNmTXTOdFNcWvn18BERnh4Myq7nVewTc5rpOD7BbYYcVOkGz OvdV4shiFdvMRNbLCnA5saMjreywK2di3LzAuAxUVPYPNB53urhkEWy1XxSzw9QgATnr U4DPgAmkkTZeH48XZoejZZD4+PHjSqH6BnnYeD4vst3QBPxF+VwZ8xY+8cDJPbtvuu1B 2pP15e+PnLn0qZcfbwg++2xVxeK+W17929Urfvhge9Zb7372bP0zLzx5Z/NYaMr81Cei B5oSo/GM4Cw5Po1rsS9AKFfVmBUJOiJitjmsjqDZPCI7GBCDIwLSCFvEZvXlUOJSYXpY nSpHuRQ5eXQ0N2iHRvOHuMorKxVYVGhL/2vKa65y5dVYMQcoizZcsnlsNbYtNrHGeaVz vV+Y41mpLHcv8ayzbXBvsbW7t/l/ajNLqsBvOywWq80uyhTtUi4WDQM4gM3kCGKj47qt 1mzR18ueJDlsqTYMvZTQTZurdaG6SmWqj2uy2ia3RnXbFKUkqkQZenz6eV4S3VnkS9IJ nTlHaC+dgIWkT7N8Y61GJem9GRnG+nUpcpt1OtaYtlsDECMGp+jyTIsTUxUmDLOVroln lXm4zdIFJ5edR4dkyIUoexCSSH50fnfovhWb9z6+qWS622VpTW5Zvmy7uzv82XM3Hlxx 9ZLbdg6eOPqrFP2+b/fWxG03P+Z+mN24afFtt9+u7nv9ms4lCx+8KPjiPX2D//oEJjYX NkCRemHfbDSqjXfVW5daH7A+bX3DKk0Xptt+JAou6DixGgRZMlsEmVgx2Q8KolsQRMFG mNUmysIBXOYasQQ/qpmJKIKEHDSLSXb185Jk1vJCpeYhSwiEL0ysDsjn+gplTtIyzSZr +ZFSuS08Tt7pwFIMrtrcpYQp8MsEpI/p7wA5vp9Lge2zJ+l2ndP/iMUadUN4mpuXCuUT RbeDyumKMxXOcs7k8vKtF8VETBmHwwF262fZNqz5rnLYuLc1S0m5kF9ULoh5eRW8ijiE ARrNbdUs5da2WeVWLVpuzQ8gLirnBLE43IpxtMRZkh1xCk7Kdg3czh764WuvdQ+Oowt/ Kuw/d/lPBx/DpL5vYAUUj6/9YelnsLHz0zMHd2AYn40zgQbs5mB2dsDFLafFIYrBgM1O iezDeqF7BDqizzK+7vNZwtc/KNHAq5gZfGKMcOm216GHtbkb8trzdmU9lfWK9aj1z36j KctnH5krmMZIYyy9sGMCZoeSZc52ZWUdtDvc9iy33WHDFNGyeEc0+6N2Zrc7tGya6dTz DpEe4dMHVk1TefecC5VVymZlhyIqmCQ+fZL4KPEpPobOpieJb6fqeoGOw/ce90GpJnTa 933XZME17LcnyzfTpRELGbd5+kAbneWjG2EWjm81XhSTIEWiGz7d5tE18LYumDaYK1nh 7LAAm0ey3TI8gWjdi9m7V97W/ez2K7cPf/oe9u7A8zNv/0EfNa69+/RvBmib0n7Xq48/ 0Dmz0sP++YvB9Q2DZ37/+g86j3GvbQYklw2bl0dG0pkZqxdy0BCOSwXqHx7UbNRmw5Lo l/KDbps5SEmhAhakPTgl6FX4gu/VbZ4X4gGe8eAOvX1I+fWQJBv7lVcbuSSLVuTQalnL rs6pVhe45qkrhCXyEuNy1xJ1rXFd4A7jlsBR49sep6zyGTAsPScMdRHd4PGssF4g84Jh akQN8wIn7+UsG0M//fTIQi5IGD3TUJ/hz07QXGRfYauiC1LBhzTwVzCKU89zL1HZOcrM zVyQlmueSu9C7yrvZq/ohVNqqPN6eKPeJCvoiqWdNMzEfr5y6TYvY/H4ygUBwlvVJcan D7d2cSpHh+mumUHmC5SLL1CRfOJUypDyUPc3ltAgnO3yjbpsxfyqukWs6oVrugduOHz7 XwaPP7TtxLMfDJTNvOeK6598/KaNz4hz7cvHzBgz+fP3FzcN/vsP7f234Ij3Zvr0r/a8 fO6DxmfiyYfv37sXUu3BUrwFt0R8lzABOo3djmxihgpRqKAG0cwqMMcIU8Gqx4yP3Q/n 83TjGgymEiuTbkxgT8aOyRpXki0Aeg4dOiTEDx0699ShQ3hjF3Ygc2BLLXRQCwr5ZeVG 08Rh5nGG8eZLzFcKW4R3BHm9+V3hXbNg4IqCtYbVDZe2i+3SM+JnRsks0nHiUZHBez+m mVzhUkHlAXYmXdZyF8/tQtqYiUUe54VLEfd1uTw8/0Pt4hy0WVh4sdGUk3MxFnwTTiPN kiCKqmR2wxibjEZVNrhl2WA245sdkTLZggsEs8As2Ckl2UTNAX/zUSkh9UnHJFG63Mjz LGNkqsptckIW5CTbolktKmeQmvFtz+i2Ck7uGd1MA/kaq6zu9nIE/m0y9YVm5vpCGq2T 9nCmck3gCjMA7nIOYztVUYGJj4ADlIZvqring9in22/ZqFQYK/BZgg9Xl36cz/QQMfWn CfG068oTp7qsTs6vU5oXiEGxO0uNil0pNXHMrNiU0swlZBz6mO4Bv9vUnKZ88G1UTrnI Id9fDuf7w/0eoJ5ySOpDeKLlxnx3uai5yzmb9xUCzU6vBulqcO0JzV5zfWOMcKOExcGJ +yD8Zeeul9mfqDywm92WIgNnTkm9AyPYOwPPnbufffLZIC6VcbJODA5ojcKOD60QxtQZ zcJZaLTb4P1i4cNiCQT9+lwbzjGrixdLDquATx2Z0WSxE6OJmS0GLhMLdnoIIYf9nMqi QACfDO1EvhyS1rm0tDJGSd9XVvb1KYcP93FHM4blhfOIDG0zQ7LK94wGPRT0UNRDSQ/B ly+0CKdgVh4KBi55ZuehycpDsx7CQH2pL/x44UstxJUiiu2TanaVOvRAsgqE2i3EaKRM 9xJ4bTqiV3KAzccpgcLmazaiN0T0hjDCdLWE8gGdHg0N0/fmFenBwMQOSRzXyvzn1zYT 5jC6md8orrdusf4GrLReZr3MIYwQC22j7PXCVeJ62432rTajhUnGctt4+0xWK8BEG2fY ptjN97Pdwi55l3GP8JRscDGH3T5GYphjzAhjP0YyAjVa5zjmUI0yZjSazBaLzWa34wNV E2tytbmYq5ftwfo4tlNSjUk6VjNbTWZVs262UEsvBmmnFpSwJLVgW4TJ5litUOwy5j+v Sk1SmyRISbanyzkp7ovlwEadbqzwDVQo/bk5CuZTRe75xPFG4qvElOITbOjJVfr7+fTa uunVrZhciLCVqE1YMK+CmFcvEmvqLPY8RwlLHcXeIo45Z0XZcH3O2VJfdtjNPDfjSr29 P1xuHxXW3an9ZeX24jId3VeE3IzLFItfv6YRM4M2xuMlOJTxeMeX0bAz4sQFsvN+3GZd NcaTA++JSgcG5+8drJd6z37xg0tn/UQ49/U08c2z48RjZ1XY7ofhqw5gpthwO9WpjWpx rnCzWqXWfZVylVu0WIOQAfH6gjjvI0ZX1AiLgxmkn3RA2U5rfq5Axlw1l+Kf67Op+ib9 v1ix9BzMqFnaqunG7NSQMcuZ1MCPJ3R9gjXDbu0KZU0jT8/gawbSMGQIoXxY9TDyYm+Q ZbtZOOwEzl19rILhh9mIe2esvDf++eAbg3fSm154uHH62NsHt0m9dlfL/msPDA4M/EKg 2zc3fD8bx2uUNMAv+R+cXo1h2dqwxcJisVVYK4qFw8YJ5YGpwmXy9LyaUHXBtGFzhbjc kHfl8G1ZdngJX+jzv2AIwZFsOgdbmzQClyKNgBiGHGYExGkExGkExGkExGe0aZxouC1a wAqEYYXjHfgOp7Bm9AJ1fqSucKVluW2F/Wp3i2+DZaNto2OTsq6gtXCL0G7ZZmt33K3c UfD9wnttuxy7soOZo4eicNTlj+aaoiNolJARuS6xeGwUHzQwYiva4N/mZ/5Cj60oOKyQ FkoeGMLTmm5PpGCRKRj0CLo/FYO30QjIRI36lnl0f/qBi1VYYLdZpHAgL+jHJR3u6Ay0 sCAfeQa4REW5qJHV7YBu9OPrCH1Xq1tZhap0Fi47VtOd1ACfKaFlFfEmedPo8eWmKBlB R3Cf3W5ndUBOazZe04jcYoyJRl04rNCLgIB9UEogX2oOTgNHDyLNGbv4Kn6sc7pxxnEo D3yNK7hWNc7ALlIfGPaMseM8OM3NmRN/+CEUKFYyws+Chn44GcsqCzLsI9PaVTAsGh1X qh8CeLxylJ8JZLu9Hjhx+qFAJL8g2vC8beFvNq16Zu6shkmDK2cvu+aWL370xFdbpF7H s08nHiufQN+tb9u45exDrw/+v930HeW6u6+c0lpdc03E2xwre6Jl1a+WLPvtrfa77rn1 qpklJSuGT9q3ft1brWv/zj3o2tQJMShOJtk495yreUMkkM3qhEap0VRnaRFWSKtMLRZj NnZ1+oLgBKLN4QtCXoCHw1zvSl+7z+SKY10Tc8YGqlwzcqsCs104Zww0u67NbQ7caLgx +ww741Pw+Y3D5vXO8jR5VuND9IBjp/Io3FhF9AfMMullz/Atl67/ulDh48K3pZTelxUQ LV4N+8D3dbEASW9KgXymey5A+jTTsJGlCTj7uSHuahVGS3msVQVxzheiIU+JUiBrBSNL Q3IlvskU+DLJ6mQfl66MgSC08yVMxtEfQt1tlnOCpWW6wNNya4zNGDgO0xGLndFlya0H XKNYLLMJqhhYU5HxPtOmBK/B26DejNdMsN9xuuWw7jbTsO5bG4Tv9Y76vOfvgyep+/0/ 4guVcyfMnXcs3j7wHpttnTB/281P0/neJ7qxnxHwOcjwwQ8Hv1LUvb1L6X1bpi79GZRy K47S+bdTbtrcg2Pgvq5sL3eujvFzN0NdoTgO31/02kQ9a6I3p9RrdFqdbkGixBGQZLfF bC00aSXjS1Mm2meiHo2zxaNx/8Q0XA/dfLrArf2H5uRsMomcZaZcTodceECcbSY3lxbS X+JMAO2azJkD7jPwbZC8wsOF4S0dX5rwnPKw1Z5HPQlPyiN6mLuQn8D2aQr6cArjwcHb YXIM9wHckmdc1681L+8E0ZsmRt40EXmznEjz6IezjLeDj2DQOLki+5JZ37L4fK8D864g yni0GXnqR9U4uqt0ljsxT7FlmLpBsxvscqHdYPVTm9HhpzhMi8VuJTi/oLrDyHc+nmws ivrJnSHbubX7lr71z9V2r1sx6+4K+I1f3Nv45IMDC9ljW2+ae8+mgQMZGX2CGeahm7Qs STBksT1KUvmr8GnWKeFMlgF7g1NahcVWukGh9yuHfcd8KZ+oGt12t8cFGVGDx2a22a32 Ap8uF58uI4suHYsuHfiQGelYdBZZ8jmLkHs6LR2LLh2kv0pLx6JLB+kzGkynoc6iK4CF puDUXIEDgj4tl0vKd8rHVvse9SV8fT7RJ7CSbI8urDM4cs7sG75TQPChLhAQztS5aHQB ibqAeBOu/xT4FV799mDIRnKRndaFxu8Uvv3rh4vEvcbK/m+k5jE4TWajWcamTYk6DXY/ dZhdGemNvJXfREAL+GmQLj98CqJLUDe0zq2Pr/ug6bFZirl75IpLW58Soz/eW7N6RvGm gVa25bprq+797cAL3E5uHVwmhiFFF3bai7R7rEqRcrFSq4iVakJlIXWENZJXnF2cNyVv tbpTNU70TvRf7r3cHzdeZW3wNviXG1dYlynXelf4+9Qj7g98H+QeCR53Hw8eU1OqJyLG lFj2OHGiMk28XFmg/M3yP3mDisVph5kMGLgGBOBr23MKDpupYtbMTeY2s6jqeqDq57v8 xA5nUzjKMOv7VaTTu7tv++bpWyfknNAiXBjmtTSrhJW4Cgnpo1g1H6UJeoqKIVqJb/4E GOFzWh6fd1TfqFD9jITCUUOO7tOD4gymqKFOJ9WnIdVXe+riUqY5oUvKfJQvmOel17jm +ooZysBprJJDeZmNuy5N/bQc/uea68maLC6s9Gxz89ui6DCn4PYMHb0atj458d6ldx5e vu6jmxbsuMj5s/U3/vypta0dg8ukF9tnz96euv+JwbN3TZ84cFZ48tCrb/7xzYPvcK+s IPUFGyntxhehf+ohZljLSLQUVgvrBJA2HH9Tq81MBeJRTDGHGWwXLA4ln+RTm6vQSlOy scZU0ySvxi57pywSWZUfxXa7Tz4sG7Bj+ly3V0A4o7GgcFeN8w8I3/VkEH3FSRs3LDR8 6kNuwPQNEtIn9GVW7mXLiY+O77j624YMOgzW9XNjdvw0P4DjzquzHK5USYnyBl90YrFC L2dWdJwzMq7EWaaff+oHNUzJnV6xaOWo22/v2rcvKzY8+NgjyuSWx9ni7VReOXj39oEf zhiFY2au6fovNYyflHzHD5elOJdxkSx8Y5ZNPOClD18x5pGLyBhSQsaTS0ktvmWci+/P +A83CgD+M/Ab5yunTK2ecWWs6vplzStnzPv/PzH6eAplbmRzdHJlYW0KZW5kb2JqCjIz IDAgb2JqCjEwMjk2CmVuZG9iagoyNCAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0 b3IgL0FzY2VudCA5MDUgL0NhcEhlaWdodCA3MjggL0Rlc2NlbnQgLTIxMiAvRmxhZ3Mg MzIKL0ZvbnRCQm94IFstNjY1IC0zMjUgMjAwMCAxMDA2XSAvRm9udE5hbWUgL1dCQ0RN VytBcmlhbE1UIC9JdGFsaWNBbmdsZSAwIC9TdGVtVgowIC9BdmdXaWR0aCA0NDEgL0xl YWRpbmcgMzMgL01heFdpZHRoIDIwMDAgL1hIZWlnaHQgNTMwIC9Gb250RmlsZTIgMjIg MCBSCj4+CmVuZG9iagoyNSAwIG9iagpbIDI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMjc4IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAwIDAgMCAyNzgKMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2NjcgMCA4MzMgMCAwIDY2NyAwIDAg NjY3IDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCA1NTYgMCAwIDU1NiAw IDAgMCAwIDAgNTU2IDAgNTU2IDAgMCAwIDI3OCBdCmVuZG9iago5IDAgb2JqCjw8IC9U eXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1dCQ0RNVytBcmlh bE1UIC9Gb250RGVzY3JpcHRvcgoyNCAwIFIgL1dpZHRocyAyNSAwIFIgL0ZpcnN0Q2hh ciAzMiAvTGFzdENoYXIgMTE2IC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+Pgpl bmRvYmoKMjYgMCBvYmoKPDwgL0xlbmd0aCAyNyAwIFIgL0xlbmd0aDEgMjMyNTYgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB1XyJY5TF+f/M+757JbvZezebve8z 2SP3AexCOARBVOQ0yi2KKMihSFu0QgUR8UBExKMICNQqcmnwrsGjlao/8aDVFjVV/DZN /VqqFMPm95nZDYa0/QO+2TzzzvXOO/PMc80z875Lblg6h2jILUQk46fOWDiX8L/LXiFE Vj5rwYyFhbTOQQhdNWvZEk8hXXqaEOHuuQuvWlBIl63Bdf1V1y4v3m8IEDL043lzZswu lJMeXOvmIaOQpjW4BuYtWHJTIa0tR/vStdfPKpbrH0P+qgUzbio+n3yCtOe6GQvmFOpf xso9C69fvKSQnsDa377whjnF+nQyISUPE4rcHL2HqMjNREYEoiNZoidEcbLklxgv5eWo s/bd6zqv1Lb8k+qVvLnHby1cX3U0LjzzWs/zcpfyWRTIeX1WA/fIlXlUkm8689qZ38hd 50r4/QhyuV7hFpojRiLSLFEjHEzyCAfxsIkMRryRPI+wgefU83gdaUNOLdmEsIbnV/P8 DJmNnBTPqeRhggZwldEYT0XJfJRHSC3CMI+H+DODvJTVFKmft+qhbuLDfR6ex+IidfG6 Tuogl6LEyeuxuEjt5EKEFTxu43eUUyuuMh6K1EJe5SkTLzPy5xvISNyjpzpyBvX0vITF RarlcTUPS3lYQlXEiVosFKmS/IOUIKXEPIlUQf4fWpLh2oqUnNeX8VAq1pN4SuShwDFK SRXqEjYC0ov8Msw6u7I6Z0EF7P4ypFhcBE2iNvmBl58h/yI/RfkZnmJxkZwmBoTfk+/I RpR8z0u+J68QCTn/JDOQx0pEhLcg75/kFNqT8RKR/DPXC1qTkMfHxMtEHhfJN8SMu/7O 2+smfyOluKubp1hcJF3kS2JFXhfP+yv5H17jrzzF4iL5mrgQniQ7EX5FGhF+Sf5ClLiH 3SnyuEg6ydMMn7gyDHzBw88ZhZHPePwEykXyZx7/Ew//yMM/EBPyj5OPOUaO8zwWF8lH vORDnvMBOUByaP0DnjrGw/cLc0be5zPA5k8k7/GSd3n4DqlAzu95K0d5/G2e/zvyWzbX 5Hc8xeIieYu8iXoyXFnvWVwkb5DXeR4LRXKEUTrpYBxCXiO/4SWvkSBL9bJZ+k1x/KxE 5JQqkpfIi+ROtPoSb/UlPpsvkhfIFOSxEhEhm80X0GoIeaxERMjmkuWI5HBx3IdJBql2 jpfneGvP8vAQH9dBzH8BPwd57sHed9ECyxHJfrKP92E/L9nP+7CPPMP7wEpElLM+PEP2 8j6wEhEp1oe9xTGxEpHHRTqcRED1rSwkT/E5/TVv+Uke/oqHe0AdItnF40/wcCcPt5PH GZ/yUCTbGJ+SX5IxCB8jjzJ5gCvDL4uL5BF+z8NkK6cMFopkC3kQuTIeimQzr3E/L9kI idmEko28vfuYlCH38vJ7yN2cplkokg2Md8ldZD2JovZdnCtZXAQu2Nyv4+EdPFxL1qC2 jKzlT2BxkdzOS37BKXs1p4lV5DbkyXgokp/z8lvRFxF4hcQjK8nPyAiUryR7kGJxkSzn 99/E272R37GMLOX9X8ZTLC6SRTx+HQ8XkGuJFq0sINUoYXERT2c9vobkMf8iuZrMgyyT 4co4jcVFchWpRziXTOW8OZdJNzKHP3U2mcBrz+azMIvMBMZkZBZvkcVFyJzp0NUyXCuR YnGRXIF+Mz5hoUimFdudxu9izxBBPaxPk4utT+aYnUTcXB5O4mUT+fMvK9a4jOexvoiY dXbvJaSOz9clPHUxb2E8j4/j1D6W338hD8eQBtwxmpdewPQWGcXjI7lMGMFl1nCeM4xL saHFtoeSm1A3x9vOYl6Z5Mry+4cUU0N4C6xEJIN42MLbaeZhEw8bedgAHJfj/gaOyfri E1ieyOMiqeFtVfPaGR6meZjidyRJAjWreA7Xt0gzPMR5GON1okSBnEiRxiN87GHOKyFW K7cJkojpoQCeyuYnwGnVz1vw8dDLQ66J+WyIwIfE67o4VTiBRZE4inkOXtsOfEfQmp2n WFwktuITbDyPPU2EFmD9tfCQa2dYIgauIVgowgrSAdMyHoqg3DJoehmujP9ZXARtFbhX w9tQY/4ZR7FQBO5VaFvGQxHtsTxFsb6C44DdK6JGYTwyLgFYXMSP1aacbgjXsJSWr15P 4/+H/8j/rb47C1bqZuiyqdCsRyG1d5ISwS6MIitAxweQ3kqeJEeEErqJfECH0OfIfXQt fZXOpmt57aNowCQmQT1q+qqkFLpwx1PIWwtZfJR+IR0nfwTtrid/FLeQ5eIQlCwnT9Gp 4lDYeYskE09vR50PCJEaxWayiZbQF+hx+ke6juykb1A8XZxMvkV7a8Wt4iH0cq1kI9+K 1aKAJ23CM3bxNtAu8jeLAt1GP6Xd5BCx0rn0Kaomu4TNeOaN9Axk+CayllaSe8g9dAhk 5kzpMeTdCnnIft/gKZvJevo7jHs94FXxQtR/CqM9Su3ox1FygC4is0UlvRX2Yp6eEctE K2sLuvB2/O4jm4Xb6Ah6j+CEJcUwsB4hkb6TthV+SLiBt248cz3xSt3sJysjSwU7eoI6 yF0vN8kn0jeESvocfQOYni1YhfV0AWwaQmx0NrtLLEG9e4Rx4kqyXnxPsMEiWY8x3EpX SNuE7cJcpNQYyQa6WZiKuzYJzZDZK+QmqQT44z/krmcjFUbJjsoGyZwY8yZxK90gbiUv UTmx4bqCPCJukq8Gzm6ke4C9nzL8k0XA2mzpMfT0evwWAVagrcnQcd9Ao10vKqGBjrLe otdWYKqEYQptLAKmvGSFbBFsrcXCe2QxD+8DtpZD7/4ZvcHfyl70aTM0dCqrkMskTCRJ eHR7heAFs/dmL57seXOKtzIxIOnRKTx7yfi9muWe53p7x0+W7LIpe2WOvWJQuVcK+j/7 b4WfVSbGjJ/seY4OG95abHb49FZkXjoZT8A/y8bjhrdWomfSUTIXgKuglI7SrYAtgAXI Y9dtuH4FOIq4hCtLHwLsAzwJQD55p1CvN4/4BMA4wEzAUMDlgFbASwA1wAsYDZgMaAZs ALA6AmAi2mHPB5DbAey+6QBWl/XxBcBqwGzATsDXgHmAw9JR/mwWnwpgz2V9YGNg/WT3 jwJEUa8L10sAjYA/Ak7jeYeAhsIamYC65HQZ0h7wGBZY/f4ESHOJp2XQAApoAxX0Qynu 0ECTaFGiA2DV3e/PAG1kwirIAj2FlT80WOGvAnrNARlBoAndeBb788JiY39+QIDHCDRr iISh+6IkBp2cgDVURZIkRdKwyauh22uh5euh/RuhhZpJC6yF/2t/gwmTmlnebR8wMAFS 6XPqo+PodfQxQRImCyfFmyWHtFFGZHfLXpdPln+imKn4vXK28lvVvaoTJXeUWkpnl/5e /TNNVvNK2eXajHaJ9jldq+47/TJDxPAb4ziTwdRhbjEfsqyxnLB+WH5H+ce2eysurPit /V3HbEePc41rtHumR+nZ6PV4r4XnZG5+kzRXth1zrSDWrEoCOShlgkSSb3/ydprojr19 7O2UUe/VB71671yJ9CwW7T1/yW9SlJ3+9gZ5lA2DCkpxgXBENhW0EMiay9QyUSLPKvcb 9GUqpUjkakEy6I51WRvRXE+ntTFFfaGwWFtT10wzFicVy6hfmGqzSO5y65XWcrdksYkL bCG6SF1us5Wr8xtCICJKt+avF9PSEdCQN6sXVdo37PtdamK8W07lerML7bd1ZvgDGvEA k1whF8wmi9VFzSa5H88LCbU1hvrBtDpjEdPD9K2NqbRtklHnvjAz/5pJU5pmhnRGabN5 XfTR/Om7bvvnzUP3my223KgH6fj23bT67iun8z5sOdeH6qxPJdrf0O532VQ20Wa0WaOq qBg1Rq3KR3mPjGqCTrWc6mpLt7Fhs17V1NXXGWprQuEqitGjJ1aLwWwSFECAL0S3tBqG NaUzFRNNOu8Y9GrKlMFtIZ0p/4hpbfQxqlp/y/c/GbrfYrLlRm7OP9W+O//23TMvr+D4 pwvyL4mV9EJwXGW2otygL5XKSoitTDxqY4kSCZacwma2nZuEtw2NjXo2EYMpmwOgSEF5 J5IUXWuh9fQbZYX7j1qDJOX/pigvExXKETqdQK0+o1ol0ynOdmgNglihMKhLVTJIjS2Q ntVCEjLBm0WeJEqK98i7Oq1SQaRSUac71sEn/xSbfKMvNAiYqPayucfcHDFZrSZxkLXC ZaQLbJZrjBaL8RoDkxSUbuv9VozTiZA5pqxKPKZ6Xy23EzWGgYk+1ZUKciQWJphuWzBp yrULJk++dvu42TPHj585E/36qneDJMk2Qya5sjpRY5pL5hoFY4mKSDq5qdArTM6xjpSM jx6TUg+UYGI4RlZbwnZHTC4TFtpCdldMJrNnAlGn0qyW5WqCEYfSpIKrlBzt/bNEoPdL IfGuzU6Tt6tJu+El9QflzaXNihpaIxtTOkbRSltl0/TTNBOM8/XzNbOND5U+pNhIN8p2 l+5W7KQ7Ze2l7YpD9JDsdfq67CP9R5qPjR9bv9J/pTlpPGkNqBRmUaF1lGPIGDk63NnT pesGF4HCDdUZUJQg+gS9jsX1OkGYu/iWWxYvueWWJS98+ukLL/zpT9LK/Den/5X/O9X/ 6zTV/TCdzqK1tIbOym/NH8XvoQINQdKLZ2RKSOVcNuDVAUkyUfOSW99RXuIpN5h1xKZy Sx65Wef0yLUO6vDpjrV1HOvp0BusjXrQkwHsnezK9GCqUwViYugMFtCpL+DU7/WFON/r 6Y0ajcwd9nlotNRcarQ8NiUViZzdE4mkpuyU0oLgd5YHVONF0e/64XVnJIC/iFN8j2mt bejnF8B3NVmdnRWQw97RtK80UZMzGuxwvkRcthXqm2UrlL/wrZUeVT4k2yJtsW9yP2zb rt1u2CPfo9ij3CPbI/3atiPYrjwYfF7xvPx5+wvSCzJHMlGdCkFaBWRKX1DhEUsUCU/Q KtaAPF451tHFhomBNgL/ya6eDt3rbd1s1I0pPqQhtK6egLP9PggeBRM4bPBFUqJyLfX2 kZWZcTstqa1+xemsp1NvnjFksV+uCVYFXGXG7Iuzdv45/+SkqhX0LSns9YYgWF3l8crc foejho64f/7qmoTSOCwxOOA1Dr7gw60d+ecvrloWr0yERK041s30KCWHev8sngZ+0uSB 7BLiNPvbUyEaSjjbzdp2tfyDxEvmjFRpqrwkcEnZNN2swKyyq3ULAwvLVphWuFboNsKU 3pjeGLi3aqPsnrIdVdvT2+ljZTs0jwX2lu0nB9L76IGqvYGXlV4zsXkUSYNioUjF6dGF USGqs3lsgk3lyuhOdbR1tB1rA7HqGxm+dB1dpzpAsUWcpWifUAaOQBfVmTomE/Grraln SCvgsYDDAt2IwtJbTx/Z/Le4W//B5Tfef9VUe2LCJR7zuOnLpk14xuIInliz9Z1Zwl7P 7puf/vPSEa7w3DXXTlmhl4myXHOJKKnnjb7ypnkB+6DlL95x9RrGs/tAQ90yNWIN5MHs rDvoYSpQj9NRYTYpguUJrS4ulQa9pCNZmlZ1lL8kRswN5onCXGGZ8Atho7BTOCio4pGG TNInJTyCSS1q5U6HRyWaRTkhtbQ2EZG7S4hTG6ERd8qzUku1jWCWYy2dbT0tnbrXM22M mJgI5qzTR1Xd3ZljLfmW14uZqTaqV0FTcn6pBZVBagI9XD5ZLW6GRHAVQyCElRYcF6fm IpcJh/OrqTbl84eX5CttDqdMpDvLDFq5VpLmlumrLeVak0MQlQq7c4I/C76jR4WdZ6fm q93RgHeXxzU8koAF8LatTKBUJ9gtZ5V+l0WlVUYDFbvcoQA31Sh5EnJPkLphp92Yvcgd 9RGXOMR+kf1Ku2gvb9eCLD4ytI/H0FXRDt+Hqg/i863XGucrV1h/Ytxou1u/3faYXuVz Rf3ErAhpoTGJ83r1SrWgnu6irjgTLaCfNrAdFyxFmQee+64t39HGUce1Fx+wdI5UCqQE JmQ5+oKSYerBS1cPXVj99Nf5/Fu7vog5Sj+Y9osnHrlp6q8NLlu0mp5JpTJV+WaxrNz6 jwMvn56Wq4iO/eXKn+yYmmii33qd4XAwWpDzYg+X8wEyIzvcY/epzarjWozwI7Hd7Gu3 v2T+ICj5Tf4JlgnCfOV8abYw27JCuUJaIiyxrKpYZVql2+nXyRUun4F41AqDt9wR1J3q 7OnUdXafE+rftXUbmDSFBVPkCwwm3Cc7/EzKEyhOkCkzcOiGn8+dvmLl7BkrLXWrxj3y 6YdPHPkbvYK6ZwxeNi75yBG6esVD9y67efO9m0eM6H7q0P/QRiqjE+jDjnBWoCpXvhfy QiTvQF7ki/orSe7JLg6Ua59WUdUfxPaYud31UuyDVIlT5q5wmt03K2+WlpYsFVZZVpX9 vOTnwjrTOt065TrpIedD8Y3ujdGHyjcGHko+ZNvo3xjc7t8e/FXyV7bdjp2eQ55D/kPB dke7rb0qFChXGxRev1wRVivs/jBRVDpS0GwdpyAhTnUXJQbXcKfafs9tuR8xYeyHFWOf EcV0dT+JQhevvu761Wuunb+m5La5V91221VX/dw7Y+affr3n8+lz5lz7xcGDn19LJ1+z 6pZr5t26knbP+tnK2dN/+tP88tR9Mx964827529MRR+dv+Pd//fE3EeZXoT/gdkgWJ0z /e7J6lTHRO0x8/viP8oNcrualMPG62J2ZxfrPzPxijzoCzH648wJYvzROumzUoSjRTMl H+6zV4TePFalH0nbQG0psjGbGSNME4SI2F5C2t1flHQmvU5R2xGxpMTSMi2sbpfb41Un Kip1RmqsClYqEom07lhn56m2TogQKOOWLmum0C0shHM2jKUV7cJDh6sb4AJo8SvjJSKU RyvxALwAVi+lkOm6urp0XQp2UXZNIW3UC3uMyyRmv1mLptI5tR72KopDhrzigotupg9+ tOHeQen4dOqsD+vo7fq6SKgm/82F8WSubUZemjhjaCp+Qf5f2VisxSgQweANR93OcE/S has7GnJ3d7tDLBZ2sfkQsV4i0mLgSInVRoYsy14UVX2l+NKua/d12kiHQYpKQVPUFAwE p0Svll0dvVpcLi6XLY/+In6HWObw2YySuyKTMERDuhKq8BvkRKMJuS0hSZOwqIi2Ilmt 6+nKdBzr6tB16LphI3N2ZIKaKf7uTJ79N6aCBUkTp7V9EWPfiPVFacTZtEiZXOff86cX ttzXfvK9u9b+ZMnpt/JZvz9xqdc7NhHw0feP/al12LVXT70kfdN166+87vorVky9YsqV P3Rzq2e1O+oP7nj4omWh8J3XTtuUcrA1NSXjer+QLpFexUzdlJ2sTCgrhWn6+foV+nX6 TfaH9I+ndtr3p543Hw6crjyd0CxxHHAIxKhSi7Yj7oj6a2OHeLJqf+RgGksQc8gaMi8p X2JaF91eeaBSpbPISdqnsmjiqTQzOTu6CmYPzE4mrV5ndo+hsS3VtojrIggjSy1bY0GD V2EhUzBKzxk/cr66IZBboAxxW0nAF3RJnuhQk0Iy3j3jmQ+P72u6qcl+hckdT2Yn7Lni +/xLdMT3Q9dKt9otgYaZu0uT3isc2jFX5s/+4Q/5s15v2bCoy1Ufqa+hbVRHNXS2h+nz mb090lLQhBoegynZJpVV3e4SO2Jm0uHq1NiVdimujEvNymbpV77d4eeVz0slWle5WbIY vESuCVTbDTUeDdFaMpVs8jOdmVNdbNoLc97VlTnWpcu3HEkFXaB3ZqswK09f5INmWpzw ZjFD9BBFfCVBb/QMcX33ly/PJtPmRyqDwXiLQddSGQzHH/n0XzRy2cVjPtptunK9KH7y t+7jgsgmOuwSV3siQX/+5fzfV3dOHDdSwhwPBa03YlyDyJ3Z8ZGqZNwbcJt1qurGuiYF CXS7v4p3kyT9JkmTXU5Vu+2vus60oqPuf8ggg8OsK1FQSSlVedLhjCNtJmH6TZiGUy5t o7lWIymTg3U9HRhqT0tH2yJddwb/BXMEJhsInZE5oG1RZ74T8w2xzGZdz8LGVHWBxH8c Ou1bzDErBX6CgmHHl3f/nnM4GQjGx2azYyqDoUqxyednnH62i8qdAb/dEQjY82cEE+P8 gLeP/oP+aLirJpIYuyH/dG1drHL04TGx1HB/fvi2sYloY08gBFxdDlxdDlw1YF0wpjZZ l4mE4o5yfbw79FWmm9TRb+poXVdA3+75a3lnGelQKEg4aPM7yg1lSklXSiVSG05X+dMO iVTRb6poVX1Q6zCX6hp1n3RkOjiWIBA4ljhpMKQAFwxX56OqD0kQEcwy65ONQn+5ADoB Cv8zqoQrwrFQwJc3+gLhpHfIkAvjAZ+41Of3+2Kus59RpSPgcdp9AUf+9HpvwB8M+oMe kYuIaDifh0xhOKq4IBOK5TOhzAXO/HDgprX3M+k+6TX4zDZl541OTUtNs8y3zE/9NLXC siH1aOrR5OOe5y2Haw7U7fdovZlIOB4wlOuJvkFL24coqfLvDR3l8a8zHYGTrv3lB5st NZa6UE2obkn1kvrtToVWpVMrhUpvUiYLp2VRolXrajX2VDOXHT2dXdyeLSwEChKkO98G YuMUxVAIa6ctWHue1IxTPdPqYCVPUXJYuQ1UoKjzBY24/bTLWRGkeyts3phGbWj8w8L8 qfwhOuxM69rRJX5H0u2L1ViVsuAdU/Z/2NXRuPzJbo835PB6g478X8vt5hJfik6kUKF0 rttdYW2YsyYdzhpLLpqYP/vJF/lT0DoUfm4ilYG2fKQ+6/bo2q2MguRlSqte0pZ6KuRE coqNXq2ptFHr130CpurMsEUx18JYEndlUsEiMfw75xTIBCMWN42Nx8ee/WUyEEqM/fzz MVWhUKVwJZilcszn652RqPtHbggEou4e5qxH39To26voW45syV4vy2nhXjXnkiSYq3XW BuF/yNVkW53wP+Ras3PI086ng9vIy86Xg/vgog0GXM4cVXgHeetK2wdJnTUhu6jpqDQF XDhbJXMGy7MOZ5myRd3s0OqHaGLZULCsqaWuWTNocEibHlLrHgr7tSvTeaqzU/el7stu doWwKNge3dZMvqU787qB+ZnaqPGcpylOjedzBi0tuAvCpQPNCWMftmBqCPM+KktXbfd4 o/U6hzUHrZn/qimWGRk3v65NJGKJsrcMw5pTseb8SfBAzuLU1cd8nu1VaQ3tEm4IePze kLPnBmcE3BKBqL387KsxNCUM6dnuCUY8HLN3OUNevwerG0q8vd9Ia4HTZujWhpC31jvX e3WzFGmq8TZ7ZA5lxmdojzk6daSjXtnkafZahmnCQ73hZE21bGhzuFpT49Crci26npaW zg5m3+c5XhobSbIDwgJY4aI2BavsZW5swZXNTC/8vDC1dF1T0qQtWHTMxYWiJdUnP1Lc bWql5xSQwEkLBMSFSpjSidWj66riF5xJgkyajbYJzdWNEdMVVUEbPR0eWZeODft7KuCP N6rt6bTVfrZrvSfYR1tQQF7BHO/ZIlr8hUxPj95pKa0S7wetCWQ05MhtkCPMFh6UTag7 REOHar94sDxgDFjj+rimWVNjrLE269mqYFXJKkGt1ZBWs0aeYs6rU/2dVzri9xV4m1Du woJShTtLui3/7t/+mn+HVnX/jabOfrHr1Vd37X75VeGSfHf+l3Q6Tp+ZaFv+sbNqSj// nNLezs/5MgZ9w7lALv+V2D24IjuIthO4PcphOXdaVB3akC8UmKaYJs5XzBdXKFaISrfN opOsRq1KKYQ8chzH0PjVYaL1D3cYrVEm8zsh82EBcunVz/r7sA1WPlt4MzvAeJ6I77ME mGkM8YUZoS89//DWh7da0gkQptUHcX3riMmQ5/Sdf/Sc+efTkiGfWrJ08ZKeFd5AxBOE iC9I8heeffZw/h2MqRlj2gc6VJIseSI7iQ3g8hY2hLlVy6oUlS000lI1RBXHWIfohghD Kki7tzNpVXXU6epS1RG7Ve+VbKaqlrhSGNKYVEaorsQ3RNKQapkmommAuRtxmWzJHDME oOE6dd3cmcc4ts8UwCIC1AqjF8Pm+q5AtI0g1yRpQVjF9mcUZbouLBUY2cIs60OOeD6b 91eABbc8Vm3WoiyAMQWpLlbBiUFvf+fO9Xes/aC1KRVryu/1BSJV3qamMQm/n+588IGa YWPX/6wianzL2xDz+xalk3LxleaxQ1ZL9vy1c2bPmdtzA+NnrhTvcoR9Pqe/cuNli3d4 tBFH/m13yB8cJZeof0pNQXZu6H1fqsaewjDyWvbuaNPI5rW2XzTf1/ygbaNua/oR6MUd vl8N29nYPuxg82HbAZ8+FvFVBom8RGwutzVJOXfl1zWlXxtgS+dqOoIn3ftzB1stQy7M XJ6Zo5vtml07u3G+cb51iWtJ7ZLGFdYVxqW61bp1xlUtq1yrak3z0yvS69Kiljiaym3N vrS8PhI1yx2KqHnE4PoRCkcriBAuNEwJQzwjw8ZGvpcAJdrVJ1PYTHFFCqusLchNz2Rh b8HK9j4KZMqd+nwxWtCi7sKeSFGNgusK3iQuPuhQWSAci4oamKwV6lL/A1ff+stZV258 56WzL9bfPFZw+BI+qSwSqHWWlXl/ctHyBxYteeypvWfeG3WXv9Kfrj9pSEUmxi0jLrz5 youml5mcj93z4LtOt9NSkX6vxB8eHTNn6m6aceFkncn6xF27fufj+ovZbYtA42lyfXaI w07SJXqN3WxQyYncUS6mHO2azkpXRyhcmYx5Qk5/mUEv2s2aEhV8bfa0eZR/pJOk5aOc 2tjIZAbLX7bg7YQfoci3fegp2mmZ1zN8TdeYUpQpjBxftam6Wmgnvp6Ff4EvZUCKXn1R AP9owHm/EdyVfr9QIgRC4pxQgJYKoVDEJZTkP9vCbbaz73CbbUv+M7FsTDQYcOvo6CAM jfwhg4cG/NExVGKs3me0FWhQwPiPYPxNZF0287KPjqyYVCH4fDTSGC8XS9oz+k4p5PTU JcsEW0UsTpVNxKcqKU2ay0ab60YnmzHkY1zptrEV/+vQLtYMY9KciajAnyrIjgpSgpgN P2wXIcY0XIw0IRbHL8ZW+TolFvkydmGL/DZAUWFb7WxvitnzfUIN23Vs6QNtXYyIAyrQ 2U+qrK5Kp0312syHq+LRBjrM4guF1HeJeuNIa7nq+CsKi22MCdtt6nDYY6Wt9dF45XpK hIkevcF+dqdo9/hDrrDT5+0pd5sMNmHv2XE2ndEnfunzukKuEGxCNoKJwNuNwFuOfJud JPdekBvhnZKb6F2rv137oP4B7R79Tm27/lntc7mySC7t1Uk+j16DU502eWc2kxR9HY2R VEmqbohlSEIiWp3e4/Wl0plsTj0oaEk4gyV1QXHQUPj+O47BE/AhF4xwADDschQzq4Zh OUHSwCPzmOgho/Wwm1qJDpBCH/W4MqWeIRnEsryc1WZ1mN/Fx+9jtbUAwu9JIeZjZTJY AtzvwoJCXMkjELO0reD8Omci2PmUcIdLQSOpij72PqcEPV8Y19NX40G/rycYziSMJV90 lZhTdbFAj88fTeZfpZcnIOfyp2oCiWy0l/RUDk/BYfOdLxKropdIBsEL6YqbQ/mXaQ6b FOGgP+TLj8/HRZ/HG2bWFZ2Rf9QVjnjCXpAxfYfv3a7H3u02WA1NWY/aoi0l/6v41vK/ 2s5yrbLUosNClRjhDsCsXlQKjxrbyi2wKdvQBUczKZeS9dMnP/p241QYtcsZ8Dnz/3DH Ym6qcfoCzl2nPXanP+SQ3eMIebFaAr1g/7ivD4OzPtYHBUEPvkVPfuyF9CjvgtEoMb8e 9m6ZKmSLPN4LdIL1oz9DMJurD8fC6l0uv9dF1Z5YzJM/5cTCdhd2cRxOrDbOXO8I+Z0O N3T67b1fSbeLB2C315LbspNulq2TYZfKfL/iV7LtCvhMI3vMB0uedx/WayqctlpNWkXU MVtUPHHCQi09qjM6z2nnidD3uvdjP6Tj+ibDYYOYjlfVZkDbVW4bCUfHyyN+Yx1THqdg m0MMslUq27Tq7IEtytZeUBgFncFG04YdX256cS+rtSASC8pi4D5McROPc7/YWn9V9ZZ9 109ceVx5yatz73/2H580LRt83ZJxr7idoU+f3HsgPRIbCw87AnJ62KCfN7l18upR74we t3P1I09pdYrF101IBpsv2f90vtkVDgR8HuCltbdbug27eaXgg+O5y6CTNTijqsFpNQvO MGtwLsqC89Xs7GIKXp4g8KdFnJ2QdIB3TuDMSZASlMgR1+JMvxln1RN4R8CP9wAcOKXI TipSnKKVASjZAV7dgX3hg7gexFWJcydR1HXiHhE868DJkwCkJ2ufnc+N4DwjZgJnUwzk MtS8FHUuQY2LSRqb+52d2BFkvmtglG2sF7YJu7s78/AY9BVwbAf7HEjQuiJb0xKzCZZw KMwNxvNNfc7ewtb1e/ffse6ZZ37dsOuat6g6/7fXr96aMVqeDYeqWs3GVqzWN7vs6/bd te7A/jvvPCDcOmJ0/n/fPJLvHj1mvL2cLWwk4sEGqsmMUU8H7VWC9hJkRfby1Y4N2gf9 j2ofKnvQsD3xvPaw/0CiRFmqoETUSxeVXll6felsxxLHytJHS58u3e7Y6ypxWc8ESvUn pNj3gfcrWw2tlgmGCZbdod2Rw6HDEWWZiaS9igmmSHgi86Nhy4+jAW7DDnhTsW3DdTKj uPPcQ9xpyIwQGCvY3yr4zLGlg+1U7jK8L4SlbyhkDztSa6dsfe35+4YtrzN6ckF3OP/B ruP5P1PPxxc+KE6XvO7UmMPBoDt98aXP3Xv/i8Gg2lYbdl+0g1refZda2UEVrBEw/i2g sQBo6KPcRNCYFjOpBY3JcF5cCTrTgs5kOD2pBK1pETow/3qcc6oC5RVOQ0VAXwrIdoKS KsQ1oDUFaK0ctOYErRHCbONWUMoEXCfgugc0vQfUcxjXw1wjMw9uHL1wYbedPcGAc1as dTPqxfG0MPInoeQy0HkEZ64mMirrwmZRB05QMBrr42kwNdtYLZIepzCIo0F8QY0DLwyB 1j7/JIVqKLKwv//2knifWd9y4OoXe6nud1dtb66dVB0NH3XZK9OJkKdn7761d+x7Zt36 p8yuS8ZcSjVvvkONF4ykK7FVCJL64UFvAJsbr96x99n16w6wU2UCmQscT8XJTge46cXc OJyHl5FlgJ0cLGQ3xrcb9Q4hzc5ZM271IjQDe+3kFvAvBWxAWyd4exDdKPsetd4Hxlpx 5wTATuiS3eDb3Zid3bjjINKHkT6M9GGkS/h5M3YCzQnsOoB1FzCpAq4nI4dx80QS6KNS 4A3/fBOuq4ftPDKUgk6ZAR0oaJ2CF5tjFByLtV3Qy+UmNSn3P7QUpw9cUI+zP7gaHE99 X79PLcl52rNzhHXa3StWH6Lb7n74pyGHM2VN11DF8U+poZccagjdduM9d6KD6O0LsGWa ZW7YwBty1Zh9drLcDnnnRewEYuxkTTt6rUUeJRYqIK8XlEdAb3Lk6RDHURvgoARpAvmU RIrt4VjRWhhXF3g+jJwwcFSCHZ8MW+L2wLjpv8ZlvkwoCCz5wK7ACNRDn99qoGQqsDAw AdkF9eFkHmCW8urFLdF4NHz2Bhbu2R6tjEUe+f2XC+dXBQxr04tm0pnReCKU37kh4GeH OvwBYVYIsdaDj2dq3ZHyK69rhDoIn32Y4UUgq/OLpNXiI+CbevK33Azwawwn2D3g2Rj8 vR68meHB6dMY+QmuTwIeR/wFXA+D9vYjzvYD4jgxmIRTjL8LB9tKDl8wQQ7D8AnQAaMz dtb/BMoMlEn67+FTl+BHbgWuW0GlE3CdgOsdoJw90BN7MCuHcT2Mqwqtp3AWJYlnqfAs FzBcjadtQPppgACYAPyHQcNB0gCDsutUG3Mt6Is8DOuuE/sL3cB4n7eBreUo84ZwlVwT YqfZ+ullyMkCg3OzHAz+o90HY2j0bTt33vbzJ56gKYev4bdrb7i62m9f6Nz4k0Ebpz// z57DY+8bY3c+EIlkhhtE5bZbVz7++MqV289W3rk0MXpsIuVOatfsWD5y6L9efuVsY9Mo s8nvj3gw+tmgzxWQm43krdwo0FoYFKeGdGTriAAoio2P2VgEeWG8aaADDpWg0Dhwyt4M YHSaAb4dSPuZgxLxctyXQC7DXCNwxt5dqAMOGc5kuMMN/erHLJdDEhpRaxKfzzDKLkV6 GupeglpTSBP0L8Qg3BeFrYrCWpnp4SKwdRHM9m6mi4t+DRSl6s+Ti0wV/yge+0w6Pd/r OSc1C9nV3cZWiMjNdtcFG8Y+8OtkJhGJ5L9LeqON/mvmXPWQvyXmTea/C4eTresLqtdi zDe35l7YmW/GhkbAHY046WNLV9wxNz+d7XwwFc1ofSdwPF42HbQeJjfnYgj9wBd7P1JF ZcQB3PpBlRXAzw8YvwkxD7g7AEziFCTmRAcaZvaLB1i5AvEsciifpzDqeVAvAp7v6MHR HHaqoogddgGCmJP6FM44wbrtt2tt7GPq4gqwzwXJsoWScHZwJJjLhtuxDAj6kz2nI5FY jKZfi8ZxoiRod0svXNuQnDwxGurReOGvBrP7hFvh5PJbjGy8X+eXilv4eGNkWY6d9w1x HnVjxvmoz3GoG2NnOAhh/IxD4+BEB8YWxsjlGFkI9FQYsxoxP3LDaAmHSLB3qTtW1I2F IxbwnBT4DAg4f6z/zmS1+uJ88+Gui+QGhQPZXIRqXb7G365ZdA0Y6wbnvT/JL5+RjkSE MBvw/MaqKZPD4R8Or1wFfqpi/HT7TuEdbOCyQVOcqifSZvBRC/kuNwKUnCDDASNgaw7F qCYgfgmuW1C+Bb4/5slk7wF5gAkTZrgF5TaU4wVu5FJQikQ0wI2JRBB6gB0TeK4ZrZWC RmpQyu6owB2VyMWmLu5ktk8DYkrwD7NCwtCXajKILRcyncegDxiHgGGwDdrFTAuQBLNn uYJk610LSeCtRCZVK3Ftxq+FxFkOoIWX4Ig9rtzbgGUr1qxdzMEAx0IK61bmpP63jVPK OC9YOM7BKQ6HW8qolnKWPLfAqqd0r7eiPRxJjk1FJ2ai4ZftLur1uhMxqg1FZhhLozMz 99AVE+NBbIT9byISDuc/oivzxyOpghHMLBaL8Wz1t2U+q8vl87WUCIKsNrEyP5u5C11e e1iNtTeFVCcSe4vCTqbk3MAksqBbe89xXoHXlChRoIjxoYQfOwvPOHc8eI0CWI6DuQ/a CickgcBzjDZgCcmH3LeMrPYK/j0z0tEwHY3hNUG3Js9CSoCxzNL6whCY0VVgJzyD8jMj X8HeuohW5K7BG5kN5H706T7+ThqBxjRhJHJOaxdB25Wh14OgTas5z7C35s7A85TAGKtB P1nEv4fOizHJg5o/YM3kxz3DQZ+YX9ijQwEtZA5gKUCOs+xhjHc46o3CsyqhC2tAG07c xSTOIFgs7K20MuBGDs1NUGsWwstR14N3He3IZ1r9SpTWI3U57p+EFhkXsDy22hoPPsbO UldGx7aXdN2dnBaZ9mSyi+GVXZlnNNnC5Tzc1WybliGc1+D7T+cJckaBg6i+bye/n1+B nUnvpxcK/tJC2KcFOPmKx6sHj55kGBT1+VfG3a3NlWPswZaYLwW5H0y2mgwjqiORB71m IXpF84hplth1I2+9UTc4FvAvj4SEyvWzblmYn85OtUaGOunOcWMm1dacPc50gT8YcQq3 eiJ+vzWYiA0aPKRl1wuFJXIKHuuC/FiJ9VszeSc3GhKhDHJAiRmOw7Zgb94RpM+Ao7km xnzqMZsJzAV7K53p4GrMK9MRAWDfAbvRhnur+axp0A57i74ZXgn2Bn0DrERNURMXVrqX o/Yk1GczFEdZQROboIkbMF/MoT6FsD2v/6iM2UT0wX/Qx/20MXaznMVzJf38DdzEOV8b FzfGqr+FNo4lk9N/VMfJlk+zgVgTtPHcrdDGgRGH6qJRaGOG2aDXYmztU8ZhrysGd9U5 ZRxzsQnAqKdiDbNY3AfqtJLh2RpyQis/Yf5e+355q6K1dIxsDJ2gmFA6TTaN7tHvMe6w 7tAc1h82HrQe1OjEiHq2KmKYWM49RgWlAzEKO7p4cARWHWUr/sLylghztxx5/cEHj3QI T+Q/+fpk/hMaOHmSBhe/9sADR448sPk3dOqH+W+o7sMPqTb/DXAskKGwiW+DTRwBzv+U mwS7NwAIw/Z1wvYNAMKwfZ3gHvYWTRBc5cAodKAVRgEK5J1AbhJ04oankuC9OokoqAjv iQI532P+x2BdOwYyYBqu03DdgXXITtDNQVwP4aqEPsqgTT3aVELSaYEnJguZzEvgqT7E mLXHtIsP8sKEcrbKvpjUwlbjG2vc1mUkUfSV6LrgQuHLrsIJC0YsMIL/O2cWaARLMXb4 M3wedmd/EwoFk/mRkWj1cKNxeHU0AgdJ644r36JlveSNa/a10Lp1+/bfccfep3sJzt14 ArBxpTLGdCbzjBEj8t8cPZIfM0J4et2aZ/auvWMvw/k44HwDX4fUkE/gm9qDsf8Ko38c mGArzucR34+4HJLXhjnAmXRgXIRlwqw19kb3CaQDwLYT3HUCnPc99KcI/CuIE/ivhcwt AbC1bQlAwBMMaNnAZWAM1gzzRmGOMAM1mJU02nUixXQ684Exi4d5DGLAcxAYZ3LAiBUu 8M1kJ5YbbDlXYMD/gnFWmGrrf8CS6tmiI1D0IvRfZPR5EYr2Uc/edfBPrbvzaWHx4H3z j+R7qfa3V2wfYXc9EAmlhxmZjyqSH5EMRkL0jTVPPbN2zTP7ep6iG0aMyR/5PdWOGDHD bMIun+eHbzEHAQ/8geg/xbv3RLoesi5ObsslQU0RUJyDSzroWka3GCnzxTCaZTTcR98b gYntgAMA9sYzo1NGpSbMj7ZIpwXaNIE6S5GXYHZxB5DE1Unx1BfMH+7TKwiuVPA8LX2e kugTV31rYYUg0QuZRXz2hnAkGn+qdUYqHOm0O678/Y1Trqv3WhfEx/36apzd6TOJmXVo Nu25ccmoxmDjoOtvwtj39X4tWTH2LJ2Wux/fzMjARtRjfjOYUz3er2zGe5UVADvAga8o GMla0MoqyPJfoM7DKL+P2wB2XB3kIZQ/iPKNKN+E8k2gzgdBK79GvcdR73G08zjq7ea8 rgH2UqC/KlB1M6i6AmAHOECPMXghKoHZNHDvA3hRkgB1Yp8aWqAUbRvQP6Y9yrk8KMX8 NOCd0CDeLI2AqoM0i/oncEc5Zm0wyt4nCzE3kB0oycEmrcETNJAyzHdRinaVaBPvovF2 zZjNOfhehRcray/B0QnU8YJ3ksgl0HE5ZsUeg/uGaX4+jTq2kwD3Y1cbc5EVF38FPgCx 13MnRr+N0qJlCqmDNTbC844bsfX4j6+T8fX4Pm8wWq7TxLbPuuaWq35a//aH77049jGp dLDL5/X4XQm3qfami69YvOy1d185dqDxzmv8GT32n/clQg0+fV1u4oiRLXfdvureeDiT WVqbrPYb0vFLs0PqJNnt62/fZrZZrcxep/BZdkszpcPAyGO5JqzENWQJYBVgI2A7QAZZ YAWmXIAyyIMkZHwC9zKr6wxK3MhrR06Ie9XAOlSJ3PcxiyHigTxnuoLZuCLietyNk3H4 aZFPAThT3IblADikaFBhN6Szp60FC4aCl6goV5i87vMBcc9FQXgXPBdw8sLggqjmYoS/ /8Vf/bsxXRmL5edfdtW0vMsRTjfPfHj40kfDJv2eWKjmskXBcMInzvZhzZjft33eNRGn N20NB8aM9k+f7abjgHzX0dp4NDPldwxPo/Cm62K865wmu3KMHpl0FEH5adAOs3rZe6cV yGF+nhA0HgEll0Fu+IAJI6R0BcZcCQoPImYCfrSg7R9t1yrkE+CT+ZGYXWoFNxrg22QS l+m5ILRbBtKWnXBr6SwKWyY7CnYPW2KjACjr2yWA5us75H8OLz96IAoWasHp07+YLrhm 8YKH1ob9odgHIXdVGj42+CGmr71wxw5zayYcfcBvp4t+tuSOefRhrz8U8GbPXuIJsnVP 6+j6p5+hv2FazsH2JimJ9n4qPQZ8hcgvc2HIBC3WnEHwKPMyyouU4eJ2A2xHLm/lwJYf 2Arj/hAw4QFetaihAKZE4IzJaPYFjzDWPfjnK0mQCjuGDjRAobMFpAGbncNxawiN6BBj zbh5XgjTMRy5aJxvSbNdT2XhVAneGWS8WpDBcarqvwXHFpTFA2Rbh2IlTssbQ5lhQSpR b8vYulAjrY1E0kMN+UO2dDKetIlc07uxPXl2uXA7jpW7mY/rbLje62nAo2lvF/DyHvDS RI7lhkBTKzDHzLYl+NYLVBLG6AfNODBatg5vhsSiqMu8r25ANfS0DThQAmMJDEvCukYC zppRg+3E21Gb7Vc14T7mCwvgDg30dxNaj5KrwOUUMSNiasL29rG5z/bwwHI4qQtE6l6H /i7uPRvgERrOexPAtRq/GmJHjFl8Fbgq2TPZPrKyqxCynWP+ui1MpvN37cGlcXwVgXvB sOXfJwgLCFewN3RxizD91pJIJBDR/UUVC4ZDtLQuZNHrKz1NT95aGgkHorqf7iiPD08F aqja7Q5kPtOEw4FYGe3JB7FrnxGOe8O+gDtc7pdk0tld9AD2+NP56cJkOMRc2EXwCGeN LIsRGzx7Er4PQYbRZVjT1gFfdSCTpbjeCH1wO2AtVqK3g/pWIY+dTbsfo9+NvAO4qoFZ LywFgnpeYHYYtKYX39zx4ssGw8CzPnwBYRhaGAYtOAw8HUHIauowU2wX3oeZxHdUMINR Uo4ZzKHNMuQw+5nNtBZSMo08D2oORa4Sc1wKgl4A+TEfWm0B0g6EZqQkXLNIjwdMB4iA UtIK9mjDuUndl6e+LDpcBh4sqMLgh+PgwHA8pHBUYDjnl6F4uA+5afzwh1jhKAHjJXbH UADrGjt0MBwHDMBrAD06CiiWVTP+Al0UzhMMPF3ADoAMOLx8juP6ThxQa31BmPfjyYK8 L5JOMw3Tdc5MQ7o23+WK1DWbaGv+N2VNldWjjtal62uUHx01N9Sl6qjkDmfqHfnP6BUl oVhqzNu1mVSsoWd90BfwRVxBH72Q1rr5wtgXeP99rz/sD7txRv6D/J4gyn0Bb+g7Ri+N sM/Xg16S5KVcBgjzwJb2kDmAuXxWmQ8tBQQwG7EdM5jEbLuKcwy7EnPMVkApoFKHWknU YmLJi5lNQK4FwY0JzGQpOIvFsAbG/MFbpitMXlHGFVYuxbM3bDoY4ll7TOCxiWC7DoTn upHC+WqiYxPBZwJ+Mn58roDEc2cKjPBU/CfJV5wHhWCPX1ADf1d1MhgOH9+Wv4dLQGsD l4BaagoPrwk1fh8NJxp6CexMbl3TIcI7TA9wGXhcYEc2IAPBf+gc5P8fhRfEt6QjkGLV ZHmO0Xklxsz0YgDyywbZZMCoSiHpmYXhhK82Cg5i6x9sN/K6rKYLJRXAXwpYLNzD7mC7 nIxfLOBXBUruRzlesMUxN+ZjhMmGgxYt7Ow0e4O4SEn17HBWxmqpLh4a/O8l4nSFqXxv aZkkfKLUKWVKfIdRraE0r0P2U2qtKP5RpSuRKQWhHglB+MqhLVGIagU9oi0TBLOkL1Gq xPx1/5YrlcA8EshpYYv4F2kbLNc0WQG8pCFh2O6HH+NjO7j6Ik7YWqwMOGEetE6w4Y/1 nMizYfRVoK0f7+jDiRkY8QAjVZAbDDs4zMbeoAVWBmDm3EnqolwuHu9jb4b2kUVBYJ8r mKkw2Z4q0QEBckOpoFA0qDFg+o3CiNwyUTwu16sFubJeU0apdKNDW6oEVvLNGg0VTTKt SiqV0Y3/lgtcMXqh9JCwTgwDLzYyLMfo40dMyIGHGMcCy7eeKymMWIUx3o+xVmCchZln Xwf4L4Oor6kVggqzbR+bxs9lhlKFXGosw/usSx36UqW8VJavZL23StoSuVqkbL74X/4+ 7D3/p78cMtnXrtjXTApcf/6XS2zgdeYn6/89kgSotfAdksJXSNgXSAZDurfC/zkCq7RR 5AJ8G2kM/JxjyThyEWT+xdBkl2I9fxk00CTsPE/B946mwct5AL4U9t1RCpygs/gDrgiZ NHzUiLGj4sOuX3rD1XNuKJawajjjT7GXTSMAWCl0FGAyAPsJ9CbAGsBmwC7Ac4A3AR8D TgJOAxlKQDkgAmgAjAJMBswD3ARYA9gM2AV4DvAm4GPAScBpIEoJKAdEAA2AUYDJgHmA mwBrAJsBuwDPAd4EfAw4CTgNXa4ElAMigAbAKMBkwDzATYA1gM2AXYDnAG8CPgacBJyG maXsLf4xVJ2LU/DL+WlmmfYvjwxIs1Mg/cvZKql/GnsX56WrBqSZ/O5fn1nS/dNcJffr X2ZAefWAND+G3K9+7YByZvn0b79hQLppQJpRdf/6Qwekhw1Itw5Ic/O7X39GDCgfOSB9 wYD02AHpcQPSFw1Ijx+QZju6/fvP1lb90xMGpCcNSE8ekJ42IN02ID1jQHrmgPSsAenZ A9JzBqTnDkhfNSA9b0CarSj6j++aAen5A9LXDkjDR3be/dcNSF8/IL1wQHrRgPQNA9KL B6SXDEgzi7x//7ms7Uc/Nw4ov2lAevn5aQ9bGfVrz8O+AtM/zXYsyf8Hpv00WgplbmRz dHJlYW0KZW5kb2JqCjI3IDAgb2JqCjE1MzY5CmVuZG9iagoyOCAwIG9iago8PCAvVHlw ZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA3NTQgL0NhcEhlaWdodCA1OTUgL0Rlc2Nl bnQgLTI0NiAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstNjU1IC00MDkgNzY0IDEwODldIC9G b250TmFtZSAvV0VIRk1IK0NvdXJpZXIgL0l0YWxpY0FuZ2xlIDAgL1N0ZW1WCjAgL01h eFdpZHRoIDgyMyAvWEhlaWdodCA0NjIgL0ZvbnRGaWxlMiAyNiAwIFIgPj4KZW5kb2Jq CjI5IDAgb2JqClsgNjAwIDAgMCAwIDAgMCAwIDYwMCA2MDAgNjAwIDAgMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDAgNjAwIDAgNjAwIDAg MCAwIDAgMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDYwMCAwIDAgMCA2 MDAgNjAwCjYwMCA2MDAgMCA2MDAgNjAwIDYwMCAwIDAgNjAwIDYwMCAwIDAgNjAwIDAg NjAwIDAgMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwCjYwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAow IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYwMCA2MDAgMCA2MDAgXQplbmRv YmoKOCAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VG b250IC9XRUhGTUgrQ291cmllciAvRm9udERlc2NyaXB0b3IKMjggMCBSIC9XaWR0aHMg MjkgMCBSIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDIxMyAvRW5jb2RpbmcgL01hY1Jv bWFuRW5jb2RpbmcKPj4KZW5kb2JqCjMwIDAgb2JqCjw8IC9MZW5ndGggMzEgMCBSIC9M ZW5ndGgxIDg4NjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvVoNdBPX lb5vZiRkS7JGsmXLlo1HFgaHMdjYEGxQg7AtAnFozE8SCUqQwSa2AZu/NCQ0RQnxwhEk hYJJTk/PSfqT7W5/DmO5JTIhweU0lLbJlqQhyW7SLKXZpnsSn5AfStKAtd8bjY1xCcue pjvWffe9d+997/69N29mvGXTPa1kpxiJ1LSsecMa0q8SXn5/9frmDel24VHg46u/ukVJ tzMriUw1azbcvT7ddrQR2avvXnefIV90gEiytbU2t6TpdBH4xjZ0pNtsOvCEtvVbtqbb hd8GVtZ1rTboRTG0Xeubtxrz05uc3tm8vhUYl+8VFOUbujZv0ZvkexJ4+oZNrQY/CxNZ XieGXgutJwfdRuPQkqmStkGzuL0a9jKdzmjHQOeR91Y6AueZ16IP99Pdx7m+NGB69k8X mi5us5/JWAbeDJ2fEzDuuKNDTURZdKHpwmz7mREKp/LLkqSNapLuBqwALFHnltBtQjb4 VqLsAmwHfAPwBMBEJLhIBiiASoAGMAku0HLJq+P81AB7M3hPhrX2P8/k5hW+chrFtq/l erd9Lf+ll1H/6r0o1m9Asa4LxdrOXO/Kzq7O7Z0irWVrO7dvKthyT4678O4OFGvaUbS2 5Xi72ra3faNNpFa5VWnVWs+0mgZaWWtb98aC/M2599fn++4DCEK/cFDo+dns4qGUoCaZ 0AcUTDI6nJlZe65nnDo3S5gtzKLZVCwoQjGZSRUmskvwsJoaEIoSTmfts0KRUGh0FCYq Kmv7QSlM5BcYFYcMlsIRmYJEdrZOKUjYs0DJB4WPmssuJcxq5txK9ioxdpq9TAKp7BUD /87ALxn4lIFfZL/U+V4w8G8M/Gtg6Mh+ZeCTBj7BfpmQVOvcDPY84mVFrxcgpE6xXyRu rIVer6JS7DMqOXnpSl9GVq3jKHuQigECUxMHRfjqhsQ+jib17bNwl5X2ZWTWAvv7rDYd J9BOMm+ix1ecZL7EvmIgTxpJh+Haz/F4MjUQnP0nV3btQ/st6q4eSd23n6n0KHu0J1Pd 1yOq+3sE9fGequInHmOnDp45eO6geLCHqcGefG9tsAfOTgqdiQdNalJYlzhmUnkwVvUh mLFnhPnE0PL2TZwE/YBzc3WcsNn1gLgTSolRyfPU9gtewZ0QYZmQl8hFG6I5iQwbCDns YkLPkot9UBMmX0wgdfvZW+yxxHgf2m8lcvJr52ay4+yYHp2fG3iAHYMgzZ3Mfk8yQCAF ZaVei7HnEPdnWFKXOGLgfgM/beDDBv6ZgRNpnDrDkglbFnToY72YwvoM64Wxp5g2HFVt OKpawoiqlkBUn2U72EPkpGKswIf4CEdZG2unKkQ6L7HdjPBOTnRzVJbYJQFNTDzM0YS+ B2HHEVYClUv6wACj8xP547mXUPHo7kIly4kMKA7KO3zFly7Cl5/BsZ/FkDWpgb5P3O5a HTtdHAdtn9jttX85L6rnYxad4aOqap3howkTdAbrR7kFtZW9wd6mXlEX6HV6aoNvT6mo ld9mfKREwXid8caE7KzVDpnUQ90mVf5j0x/3/lHc040kPZufX6ucnXP2ibOHzh47e+as +YHt6P26w1H7dWPO2KzZ+pwxY+7Y5PJ026sP3Rfzp3XJieV4amPdgrq3W1IfxCjbMT5X yruzrql2Z3emuoNP2F1aWhvsLi5GgcUw9z5BFCTBRDZ2gX3CPgX+mJ1nfyEbdhe+Zxez CzQH0AQQBQc7LzjJLmRAxgpsZp8IFmAHBYQMgBkgUgC8AfYx4An2JPsOxtzPDrAe4L1s H/sm8I+Af0J29hToPwD+LujfB/4RZJ4CfJfLAvYD9gJq2Gxs/sVsNguwL0G+glWyacDl bAqbCnwz8ALIzwW9Hvgm0IPAN0N2LuAmwGxABaA8uD/gnen23Oh2z3C7prsd1W5blTtj mttc6RYr3DTVPXFSVtkkx2Q1q1x1lPizJvgd44uzlGKHQ3baMjKtNvM4i02UTDZigo1E V3GxeJt4TEyJUrFjjqPJIXpZkd0zrsDulvPsLinHXh6YHCgLTAxMCJQElMD4gDfgCbgD roAjkBEwB8QABZqqmeZqpMaldVo2A15Sp1WrjUlRWaxVqY1aRtPycC9jj0bQqwm7cC9Y qkm7kgKQq37Z8jAynZO7vf1IftIao92PRHoFqtPYLs2/JMxRcFFYU3YlZVoa7hVYXSQS 0WY2NqFOdRG1SGtpBFusKKJV8creogg1arMWaV5/nXq1a/Pm0b29ZRND2uRQs1YeijaM JvzvdX0gdhU+TKDPgWLLWPIVk19ubN58VU6CeFrfvyEPz3F5DM47djpVZfVhb4SDqmoe LYjwQCvDB6NckWSvKaGOhiR7PY3+PY3+I43eSKM3OdJV2tKbwYN70+K6Rs2yGNC0XCvw o3ESjRvRsPnrzCrl4+x3kvzpg86VpXQLpxKlfq+X7+jlG0RD96T+TGSeidoLvO/vufgZ jYP09wzCZX9Kd0DTW1M/RL2fVqB+c+p7nz8o1u6HbDqzsRn0MtbueVaGg+BEOoljJLf5 EuAoeqz0G2OMfvpv+gGd/PwROYX982g69osy6HKCuujC6H69/hOUHC5fD16uXqP2JA2f or+T5hKnCC4xTseoj3rorTGS/Zj5AO3DjSuDPmCluIXtZkdZNr1NL+HsvFt4Wvwn+lfI 9I+R48238LcL0iMXu4EusBjNpddwAp9GfczLWukFhmMzvQtL36R36SE6xgpHfGZI8vjy SyLpJ+mMSrf/AeU2+Pp5Wn39I7MyJjLP5/FjZZRifYhp+mU70m3J8HYKawL5pq8PvTY7 TUc+dCIHZmKOQpaLXLMwkT6h9+D915AV/bSXHqatPJ4631TwKfCpzCQm0Kfw6jl6jr41 zIU7DZGqZ/np1A9ZKU1C+/nhma6NTWu434fXs4Wgx0uX15zptLHO0yv84+Gxhj7Qa4fp MP2VztD79G9MpsNsDzR7no4j3/Yg6nug4TZaRR8xNkTicdjVhL9rXKZCE7fkymsbHYD1 fLV0QZe32IuY6WrXAeTjmBw3N7HTY1YS0c+xjp/EeKOvH49uGPUD4lb6mG65gvI27HlJ eJp2Y908RJ06rUt6UurHLJPTf8Hg4gXzA7Nn1dbMvHHG9OqqaZUVU6eUq5NvKJs0sXSC v8SnFI8vKvQW5Hvyct052S6n7Miy26yZGZZxZpMkCozKmUfz1IdDHVp+fRRbcYNfVjTb l88trNDI5fX5nUp1RWSKwaWZVI2yG7Uc3FEpWBPRzOpYli9rYqn8oQ/CC71KSJNK8fPf 0tyilS0O+/zyq94RegTDagX1YZ/Pqwml+C0ACb9bmpUWTW5CPwh6zwKNmsIckqmzNeik Gl8E5eKwNn64iRv9VZTEbpIaGKPml1lc7rXl1zdolNNLtrMauTnbuRrSKKCV4eBRKqOm j0YVGsv5UGPZGnMvhElXTsHFztRcxQehlg5/qKUdHm2JXvbpubRHfUpciS8OO6u9Pp+u NG6Ei8K91sx6f31rJqzAkQQd1JtpRY+VdyAsG3qZ7SamVwRbaBbOMxY73Ofi6oY4dGjB 3VFU/A3wGyjZlyk4HO8ZTSKIpZkIbHqN6XNq5nptXFoJpV0LNmu0W+ktH4jvwXlqVVS1 tfhbmr8S1sRmKNVLYmmobalW2Ni0DF1QAhBtU3i4G/SCB08JtSlxtDlvFKW/AaJX9re0 tUZ5mrCovwG0jPrwTt+AFwe+8M6Q5lQ1O8Tt97/tFeMhT7vCm/H4TkV7Ege9UVQf50ES eKaUK/GQH7NhsFBHHY9YxUjY9Gxc0KIHJ7i7WdFiqzrgM/ya9wznvy8ua7a/+BAdxAeS fHVwB3NoiXZwUzogKQEp8d2tuql7dNOQr/zQw4ELIvvpdkgvC4fa/CH405gQDoG8WDpW 1ufT8lUuGI+HuIrNLdCeewa/fBzIoEa6gTXhVRn0qdeCS3VES/UYYMZgc0PE6DIYQJEQ By0YbYhEuFHpAGjjSneapvqVOB90XKmWo8q+X4A2MKW8cXE41MCzE5xCffhLgx7vIOo4 Rg93Mw944hWD3EmcssTfuCidBW3cP7yILk0vYHjNiDxYDX591Bc93hchO88/LxqPz/Mr 8+LReHMyFVvlV2R/vNdmi28IRRV95TP0H9nt1ebtiWhytI3NQpB5vs3DATJ70XIennlK WzN68Jvj99V4fU4MnebBznF1srHOkPHIe77O4vJ7sNiGHcmrzOPbSxK7gleTa/gyhSa3 h7EOVmOKUIteYH3gIULw8pUiRkpD7UsMB3l9mFJPGL7vLTJ6MYjPx9fQ7mSQVqGhxRaF 022FVnkTFKxQEbsopwwMU9y3c0psmDIiHvUjVh7+EKPnxOflNPbzkXyOO/0upZZv5tAO vwUt2sBS2PhJjWaBx/RwZ9eHRa/AWVATvCKvZaq4JQS0PFUX5D7BLhmX/copvyarmqk+ POANRBTZiQ2SjSSDMSJPU/mU/1eMb6KUI2ssoLFcvqwImyrciE0/rwbEEUElFI8a2Tfa PrBy7pa2kXWUtgILlxsJN8h+rFtv2h9Ol5+b+gLP9vQNTjOVzuOLCrHRPXZLRMviNzst 6z29gHHe+rCCbQjLdpFeUUJKG4+6pkQb9P0g4uX04e5k6ky0ge9/YSQaWLxGfiPL4TZj TRhuaFwaHq4tDj/gvT8yBW9vyxuTlIE7KX/iTbJUd5IaivrxPlhceRfIS8sVJdTegAnR uL0cHZN9qN1RjtzkqR/2R/idZEFLXOHJ3wKzdAxCazxSgXxdEsZ+iQdhnxaMeEeqrZHI LIxzJx8HImCPRzBChzECsN5VcQlM4fJG7FQTm8LYbGMNSPQGvoRh7gBW1QC3mBsSGdEU Gj/Q7jF0XgadI5NBX54eBbkawxCReJyPuSTsR5rH49447DDaeOAf2xE0OpLERWB4KMli TZAF8uvng5Df5+eejzRgqq/A78O7FN6RX9vDd43oDcmV0PYu3cPRL8jDzdfj4VXX5eHV I5pe4eEW6Lyae7j16h7WhInX8PFolwbTLg1exaVrrnDp3dd2aduIotCqHeq16S7t+IJc uvZ6XLruuly6fkTTK1zaCZ3Xc5d2Xd2l/4ik3XCFhzde28ObRvSGkpuh7Sbdw1u+IA/f cz0e/up1efjeEU2v8PBW6Hwv9/B9/38evn+Uh/HJh5GANzLsr9RuDlO/aSGtkDS6Q/gW 9Ys30a14zkp/wyO8HTbjfQ6RQrej7/9+CVcRMZ7hr0K5vi6Jf9cbdZlH1Xl1nNGeRbNo DR3Hu+PvsufwxhofA7kJJi4uggs3nyX4hmipwE0IYJGTRKcAvI26+CbqwBKwCGx6k47o L8fugJAkH8G3EjPxuiBXTvM5fc5SFAwcF4Ni7GLMRJ9RUIqBqx3u3Icnfj7nlKBHOmRy sEPkMh8ymQWTcIgFLRnsUFWlygo88sLBAXlAHqQ5g3MGp1VWY1QGaGdlQ6/zp/Kh18US XnJb+Jsi00W8F7FQNnUE56+ysi6ZNUkbpJi0V5KWj2NLRbbczPDu3mVOmI+bxfUOZrcW WQW7XCQLGVLGPsrO3sdE+w5TxnYKuk1dQg6tFfAWVFdkRAu28q4VK1bQio0ocUEphZwy +Uqrq1zO6ZOmMpX1Cw+wMOsc+trQ94Ze/tNH70frjiSOmE4O7R/6l6FvDq19mdmZ65VH mvnTvUArUu9IPXjfmUUeeiC46A6ZdTvYo9ks4mY73SwsMSs+f6lCoyBl5pVl2udL1hzr BKsokkt2CXYTuT0s96CY67A6ezJkG1k91J2Vs8McLMhqE/LNay4bcOnUAM2ZM1hVpcO0 Sm4IrVyhcnNwsRW+GWZ/iTBDdlVX5XFXT/SXmN1yddVMcd2m8yfOpl778SPshqHX1t6/ /qHXH9762z+zkiGWw+bvEpo+PS2qW1/uHTrEX9nBpjtg00xpNb6Eu+mx4AQnvlDYF9lf sv/B/oHd1C2xHukpSSgwM7PHlTv/ZulOScBnpHPBAlfe/FtEdn8msz3mcLJjzt86Bacz K4cel/kHHcWRPV/OelzIzemxyLLDxTJE1w6rzbnDFLTm5ZpgKvPIJwrkhZeelwdhHMwd nHPpVXUQn7UqVmxEBrEVG1V8Kd+I4G0sNfsRuOnEw+Zz+apmMp/sL5Fm/u7ZocGh48z/ /gdvXbpzPJvd88ylJSz+s2TpTfgck5ViM4dODT09dCLEvs1fyDKed+wPiJ9IhcEscjMS u5HpJuoeyWF4PZ28/azMrH56mvuI0a2pd4T3TaXI1tuCVZkW6sl29gi5WSarqcfisDvM ktVhkbId3VFpQBKwwiQFubwXr3s06YxkkWDQpRNYHAPyCfkEDEUNtg7KL06r5JblM/+M 6hml7mq335mDEArvd3xpaPu2bazs3XefmjjDXMzahLr+/pI3+i/916+zeMz0K1VDw/9L ke4YLi2oiFSEd3s303y8Zb1TJzByGfugGdlLdy4ML1i0TL31ntXtLc03b2rubGmdUte1 jo94ebfk776mAxoASwGcugXwMOBAyrhQp5E6w357ZXvWmDYfazQ/H3N0u3VMe92YNp+f /gfqu4gPCmVuZHN0cmVhbQplbmRvYmoKMzEgMCBvYmoKNDkxMAplbmRvYmoKMzIgMCBv YmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2NlbnQgOTY3IC9DYXBIZWlnaHQg NzIzIC9EZXNjZW50IC0yMTEgL0ZsYWdzIDMyCi9Gb250QkJveCBbLTEwODYgLTQ0MCAx NzM0IDExNjldIC9Gb250TmFtZSAvV01YSVFaK0x1Y2lkYUdyYW5kZS1Cb2xkIC9JdGFs aWNBbmdsZQowIC9TdGVtViAxNTAgL0F2Z1dpZHRoIC01MjMgL01heFdpZHRoIDE3NTAg L1N0ZW1IIDEwMCAvWEhlaWdodCA1MzYgL0ZvbnRGaWxlMgozMCAwIFIgPj4KZW5kb2Jq CjMzIDAgb2JqClsgMzMwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMjQ3IDAgMCAwIDAgMCAwIDAKMCAwIDc5MyAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDY2Mwo1ODYgMCAwIDAgMCAwIDAgMzI1IDAgMCAwIDAgMCAwIDAgNDA1IF0KZW5kb2Jq CjEyIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZv bnQgL1dNWElRWitMdWNpZGFHcmFuZGUtQm9sZCAvRm9udERlc2NyaXB0b3IKMzIgMCBS IC9XaWR0aHMgMzMgMCBSIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDExNiAvRW5jb2Rp bmcgL01hY1JvbWFuRW5jb2RpbmcKPj4KZW5kb2JqCjM0IDAgb2JqCihNaWNyb3NvZnQg V29yZCAtIHNlY2RpciByZXZpZXcgb2YgaXBmaXgtcmZjNTgxNWJpcy5kb2N4KQplbmRv YmoKMzUgMCBvYmoKKE1hYyBPUyBYIDEwLjYuOCBRdWFydHogUERGQ29udGV4dCkKZW5k b2JqCjM2IDAgb2JqCihTdGVwaGVuIEtlbnQpCmVuZG9iagozNyAwIG9iagooTWljcm9z b2Z0IFdvcmQpCmVuZG9iagozOCAwIG9iagooRDoyMDEyMDMwNjE4MDYxNlowMCcwMCcp CmVuZG9iagozOSAwIG9iagooKQplbmRvYmoKNDAgMCBvYmoKWyBdCmVuZG9iagoxIDAg b2JqCjw8IC9UaXRsZSAzNCAwIFIgL0F1dGhvciAzNiAwIFIgL1Byb2R1Y2VyIDM1IDAg UiAvQ3JlYXRvciAzNyAwIFIgL0NyZWF0aW9uRGF0ZQozOCAwIFIgL01vZERhdGUgMzgg MCBSIC9LZXl3b3JkcyAzOSAwIFIgL0FBUEw6S2V5d29yZHMgNDAgMCBSID4+CmVuZG9i agp4cmVmCjAgNDEKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDUxNTA2IDAwMDAwIG4g CjAwMDAwMDkzNTEgMDAwMDAgbiAKMDAwMDAxMjM2MyAwMDAwMCBuIAowMDAwMDAwMDIy IDAwMDAwIG4gCjAwMDAwMDkzMzEgMDAwMDAgbiAKMDAwMDAwOTQ1NSAwMDAwMCBuIAow MDAwMDEyMzI3IDAwMDAwIG4gCjAwMDAwNDUzOTMgMDAwMDAgbiAKMDAwMDAyOTAwNiAw MDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMTc5NTMgMDAwMDAgbiAKMDAw MDA1MTA1MiAwMDAwMCBuIAowMDAwMDA5NTkxIDAwMDAwIG4gCjAwMDAwMTIzMDYgMDAw MDAgbiAKMDAwMDAxMjQ0NiAwMDAwMCBuIAowMDAwMDEyNDk2IDAwMDAwIG4gCjAwMDAw MTczMzYgMDAwMDAgbiAKMDAwMDAxNzM1NyAwMDAwMCBuIAowMDAwMDE3NjEyIDAwMDAw IG4gCjAwMDAwMTc2MzQgMDAwMDAgbiAKMDAwMDAxNzkzMyAwMDAwMCBuIAowMDAwMDE4 MTIwIDAwMDAwIG4gCjAwMDAwMjg1MDcgMDAwMDAgbiAKMDAwMDAyODUyOSAwMDAwMCBu IAowMDAwMDI4Nzc4IDAwMDAwIG4gCjAwMDAwMjkxNzggMDAwMDAgbiAKMDAwMDA0NDYz OCAwMDAwMCBuIAowMDAwMDQ0NjYwIDAwMDAwIG4gCjAwMDAwNDQ4ODEgMDAwMDAgbiAK MDAwMDA0NTU2NSAwMDAwMCBuIAowMDAwMDUwNTY1IDAwMDAwIG4gCjAwMDAwNTA1ODYg MDAwMDAgbiAKMDAwMDA1MDg0OCAwMDAwMCBuIAowMDAwMDUxMjM1IDAwMDAwIG4gCjAw MDAwNTEzMDkgMDAwMDAgbiAKMDAwMDA1MTM2MSAwMDAwMCBuIAowMDAwMDUxMzkyIDAw MDAwIG4gCjAwMDAwNTE0MjUgMDAwMDAgbiAKMDAwMDA1MTQ2NyAwMDAwMCBuIAowMDAw MDUxNDg2IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgNDEgL1Jvb3QgMTUgMCBSIC9J bmZvIDEgMCBSIC9JRCBbIDxlOTYxNjc4ZjYwYWY1ZTc1YTFkNDI2MjgxNTcxM2VmNj4K PGU5NjE2NzhmNjBhZjVlNzVhMWQ0MjYyODE1NzEzZWY2PiBdID4+CnN0YXJ0eHJlZgo1 MTY2NQolJUVPRgo= --============_-881064676==_============-- From new-work-bounces@ietf.org Tue Mar 6 10:16:44 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 EACA121F88D0; Tue, 6 Mar 2012 10:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331057803; bh=B89gznlswRU06CeT3aCBtiKgmOTwUk0jDBeShdSw8tA=; 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=a0mLuRldS7Z5sXZhy5ssNg0Jj9M+zjieabH7PyPkk6eqEc7dH6BWxKju/4hsXw/AP 6ajpUm9SbyyjOv3YLm2xf8CJr4lRukXGGxfPIWStnivGt+W1GZC7OjovfWvewGUgPT rorBAv8Sxbx0UFVRvyJuGHp/x8dqu/tXYHwp5QeE= 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 AA6F621F88DF; Tue, 6 Mar 2012 10:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58ReJzzAvcTu; Tue, 6 Mar 2012 10:16:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8165021F88DA; Tue, 6 Mar 2012 10:16:41 -0800 (PST) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120306181641.6343.29418.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 10:16:41 -0800 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, 06 Mar 2012 12:37:31 -0800 Subject: [secdir] [new-work] WG Review: INtermediary-safe SIP session ID (insipid) 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, 06 Mar 2012 18:16:44 -0000 A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, 13 March 2012. INtermediary-safe SIP session ID (insipid) ------------------------------------------ Status: Proposed Working Group Last Updated: 2012-03-01 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: TBD To Subscribe: TBD Archive: TBD An end-to-end session identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediate devices, and management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices, hops, and administrative domains. Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification. Perhaps the most important factor worth describing is that in real-world deployments of Back-to-Back User Agents (B2BUAs) devices like Session Border Controllers (SBC) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through. An end-to-end session identifier should allow the possibility to identify the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It should have the same aim as the From-tag, To-tag and Call-ID conjunction, but should not be mangled by intermediaries. A SIP end-to-end session identifier has been considered as possible solution of different use cases like troubleshooting, billing, session tracking, session recording, media and signaling correlation, and so forth. Some of these requirements come from other working groups within the RAI area (e.g., SIPRec). Moreover, other standards organizations have identified the need for SIP and H.323 to carry the same "session ID" value so that it is possible to identify a call end-to end even when performing inter working between protocols. This group will focus on a document that will specify an SIP identifier that have the same aim as the From-tag, To-tag and Call-ID conjunction, but is less likely to be mangled by intermediaries. In doing this work, the group will pay attention to the privacy implications of a "session ID", for example considering the possibility to make it intractable for nodes to correlate "session IDs" generated by the same user for different sessions. Goal and Milestone: Dec 2012 - Specification of the new identifier sent to the IESG (PS) _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From ulrich@herberg.name Tue Mar 6 12:31: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 3DA1021E8024 for ; Tue, 6 Mar 2012 12:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI3HT8YjHTpb for ; Tue, 6 Mar 2012 12:31:06 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 694AD21F8658 for ; Tue, 6 Mar 2012 12:31:02 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so4650215pbb.31 for ; Tue, 06 Mar 2012 12:31:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GjrVtLiMNP29kt/h3ROnpC5qUW+Hnly1gcNXlVyZqJA=; b=z6RdjJD1x7PL3VRyDLQYtrNGoeqjga0bZ8TEGEPjCQL3Qe3SOAKr/iZEl8eAu5Mvx4 btRAF38DwqPCaGJKR3p7XbirVNornOeJp8pXwZQIKXjAqWBEEuI3g7pbOZF5sWjHDhq5 BSSq/A6/ae6KhSh5MWww0+o8ebKas9PC3k1bM= MIME-Version: 1.0 Received: by 10.68.239.195 with SMTP id vu3mr7009pbc.49.1331065862098; Tue, 06 Mar 2012 12:31:02 -0800 (PST) Received: by 10.68.43.105 with HTTP; Tue, 6 Mar 2012 12:31:02 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Mar 2012 12:31:02 -0800 Message-ID: From: Ulrich Herberg To: Donald Eastlake Content-Type: multipart/alternative; boundary=047d7b33d5cce20ee204ba98ebbc X-Gm-Message-State: ALoCoQkQS+/9w67ytbyOGH+LnJeP5nwK1ML7PWYWwI3m6g0duf97USHYFqXSyW/rPbYCv/ZfKamd X-Mailman-Approved-At: Tue, 06 Mar 2012 12:37:31 -0800 Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-manet-packetbb-sec.all@tools.ietf.org Subject: Re: [secdir] draft-ietf-manet-packetbb-sec-08 SecDir review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 20:31:06 -0000 --047d7b33d5cce20ee204ba98ebbc Content-Type: text/plain; charset=ISO-8859-1 Dear Donald, thank you very much for your review of the draft. We have addressed your comment about section 8.1 and 9.1 in a new revision which we just submitted. Best regards Ulrich On Wed, Feb 29, 2012 at 7:53 AM, Donald Eastlake wrote: > My apologies for getting this review in late. > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. Document editors and WG chairs should treat these comments just > like any other last call comments. > > Overall, I do not have security concerns with this document. See > comments below. > > This document describes "signature" and "time" building blocks for > constructing messages/packets as described in RFC 5444. There is > actually noticeable overlap with Section 7.1 of RFC 5444, enough that > I am inclined to say that this draft should indicate the it Updates > 5444. > > The Security Considerations Section says "... has the same security > considerations as [RFC5444]." In turn, RFC 5444 says "This > specification does not describe a protocol; it describes a packet > format. As such, it does not specify any security considerations; > these are matters for a protocol using this specification." :-) But, > in fact, the Security Considerations Section of 5444 continues with > design suggestions for authentication/integrity and confidentiality. > Arguably, this draft provides a more detailed syntax with some > processing rules for authentication/integrity with signatures > extending 5444. But it still defers much to any specific MANET > protocol making use of RFC 5444, this draft, and probably additional > "building block" drafts or RFCs. > > It appears that the MANET WG is approaching all this through a series of > overlapping documents each of which is of limited content but provides > more details. For example, this draft sets up hash function and > cryptographic function IANA registries but provides only the identity > function as initial content for these registries. Presumably additional > documents will request allocations from these registries for other > functions. There is nothing inherently wrong with this approach and > trying to produce large monolithic documents can have problems. But a > swarm of smaller inter-related and partly overlapping documents can be > confusing. > > Section 8.1 and 9.1: These sections provide that when adding a packet > or message signature TLV, respectively, any pre-existing packet or > messages signature "MUST" be removed, etc., before signature calculation > but > only "SHOULD" be restored afterwards. I would have guessed that > "SHOULD" would be a "MUST". In any case, it might be good to say when > you don't need to restore a signature TLV, which I would assume would > be if that signature TLV is not needed by the recipient. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > --047d7b33d5cce20ee204ba98ebbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Donald,

thank you very much for your review of the draft. We ha= ve addressed your comment about section 8.1 and 9.1 in a new revision which= we just submitted.

Best regards
Ulrich

On Wed, Feb 29, 2012 at 7:53 AM, Donald Eastlake <d3e3e3@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> My apologies for getting this review in late.

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

Overall, I do not have security concerns with this document. See
comments below.

This document describes "signature" and "time" building= blocks for
constructing messages/packets as described in RFC 5444. There is
actually noticeable overlap with Section 7.1 of RFC 5444, enough that
I am inclined to say that this draft should indicate the it Updates
5444.

The Security Considerations Section says "... =A0has the same security=
considerations as [RFC5444]." In turn, RFC 5444 says "This
specification does not describe a protocol; it describes a packet
format. =A0As such, it does not specify any security considerations;
these are matters for a protocol using this specification." :-) But, in fact, the Security Considerations Section of 5444 continues with
design suggestions for authentication/integrity and confidentiality.
Arguably, this draft provides a more detailed syntax with some
processing rules for authentication/integrity with signatures
extending 5444. But it still defers much to any specific MANET
protocol making use of RFC 5444, this draft, and probably additional
"building block" drafts or RFCs.

It appears that the MANET WG is approaching all this through a series of overlapping documents each of which is of limited content but provides
more details. For example, this draft sets up hash function and
cryptographic function IANA registries but provides only the identity
function as initial content for these registries. Presumably additional
documents will request allocations from these registries for other
functions. There is nothing inherently wrong with this approach and
trying to produce large monolithic documents can have problems. But a
swarm of smaller inter-related and partly overlapping documents can be
confusing.

Section 8.1 and 9.1: These sections provide that when adding a packet
or message signature TLV, respectively, any pre-existing packet or
messages signature "MUST" be removed, etc., before signature calc= ulation but
only "SHOULD" be restored afterwards. I would have guessed that "SHOULD" would be a "MUST". In any case, it might be go= od to say when
you don't need to restore a signature TLV, which I would assume would be if that signature TLV is not needed by the recipient.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell)
=A0155 Beaver Street,=A0Milford, MA 01757 USA
=A0d3e3e3@gmail.com

--047d7b33d5cce20ee204ba98ebbc-- From cyrus@daboo.name Tue Mar 6 13:04:08 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 7D5B821F878A; Tue, 6 Mar 2012 13:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.633 X-Spam-Level: X-Spam-Status: No, score=-102.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt6u2Bv9IPCL; Tue, 6 Mar 2012 13:04:07 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0621721F8675; Tue, 6 Mar 2012 13:04:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 59FD2230F866; Tue, 6 Mar 2012 16:03:57 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STpM5iMVMPGx; Tue, 6 Mar 2012 16:03:55 -0500 (EST) Received: from [17.45.162.181] (unknown [17.45.162.181]) by daboo.name (Postfix) with ESMTPSA id AC515230F855; Tue, 6 Mar 2012 16:03:53 -0500 (EST) Date: Tue, 06 Mar 2012 16:04:18 -0500 From: Cyrus Daboo To: Klaas Wierenga , draft-desruisseaux-caldav-sched.all@tools.ietf.org, The IESG , secdir@ietf.org Message-ID: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=12851 Subject: Re: [secdir] review of draft-desruisseaux-caldav-sched-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 21:04:08 -0000 Hi Klaas, Thank you very much for our review. FYI, following some other comments we have received, we have undertaken some significant editorial-only changes to this draft to, in particular, clarify and simplify introductory and descriptive elements. As such, several of your issues have been addressed (or eliminated) in our working copy. --On March 3, 2012 5:05:08 PM +0100 Klaas Wierenga wrote: > ====== > > 1.2 approach > ------------------ > bullet 1 and 2 together seem to form 1 problem, bullet 1 is just stating > a fact. That bulleted list has been eliminated as it was added as justification for a change of approach made earlier during the lifecycle of this draft and is no longer relevant. > something that must have been discussed in extremes, but I can't help > wondering what the reasoning is for not making the server responsible for > sending and processing scheduling messages, is that a legacy thing? It > seems to overly complicate this document that always 2 cases need to be > distinguished. So the SCHEDULE-AGENT parameter defined in this spec defaults to having the server do scheduling operations (sending, processing etc). However, there may be times when the client really needs to be able to do it itself. In particular, if there are attendees in an event who are not hosted on the CalDAV server, then the server might not be able to deliver any message to those attendees. In such a case a client might want to take over scheduling for those attendees (send iMIP - email - messages instead). In that situation it is important that all clients know this is going on, hence the need for SCHEDULE-AGENT=CLIENT. In other cases it might be known that the attendee has been informed of the meeting in an "out-of-band" manner and there is no need for actual iCalendar-based scheduling - that defines the need for SCHEDULE-AGENT=NONE. Having these different modes of operation does mean more complexity, but they are driven by important requirements. > 1.3 limitations > ------------------- > I can't help a chuckle with the statement "to keep this specification > simple", I think simplicity got lost somewhere in the process. I probably > would have considered breaking the document up in multiple documents. That has been rewritten and that particularly humorous statement is now gone :-) > 4. scheduling collections > --------------------------------- > can the server only create or also delete the collections? Well the only case where the server might delete them is if the user were "downgraded" and had scheduling capability totally removed. That is probably an unlikely scenario, and in any event, can be accomplished by simply setting scheduling ACLs for the user to deny scheduling. So at this point I would rather leave it as-is and not mention that servers can delete. > 4.1 scheduling outbox collections > --------------------------------------------- > caldav-max-resource-size, not using this seems to invite DoS attacks, > perhaps make it a SHOULD to support this and mention in the security > considerations the possibility of DoS attacks? (same goes for 4.2) I have added a new section to Security considerations: 11.1 Preventing Denial of Service Attacks Servers MUST ensure that clients cannot consume excessive server resources by carrying out "large" scheduling operations. In particular, servers SHOULD enforce CALDAV:max-resource-size, CALDAV:max-instances and CALDAV:max-attendees-per-instance pre-conditions as applicable for scheduling Inbox and Outbox collections. Does that address your concern? > 5.2.2.2 create > ------------------ > In which cases can scheduling messages be delivered directly to the > client? And can't you forbid that? This again reflects the possibility of scheduling with users not hosted on the CalDAV server. In this case an attendee receives a scheduling message via iMIP (email) from an organizer not on the server. They may want to store the event on their CalDAV server so they can view it on all their devices. I have added an "e.g." into that sentence to help clarify: However, in some cases a scheduling message can get delivered directly to the client (e.g., via email [RFC6047]) Hopefully, that will clarify what is meant. > 6 processing incoming scheduling messages > ------------------------------------------------------------- > Can you be more specific about WHERE in RFC5546 these rules are specified? Well it is really all of Section 2 and 3 of RFC5546 - which is pretty much the whole specification. I don't think it is possible to be more specific than that without having a long list of sub-sections. > 7.1 status codes > ---------------------- > These are EXAMPLE response codes? Why not normative? And doesn't that > give interoperability issues? Well WebDAV and HTTP have traditionally allowed response codes to varying depending on what a server might want to do. e.g., in some cases a server might want to return a body on a successful PUT, in which case a 200 would be returned instead of a 204. Now, the WebDAV base spec (RFC4918) uses the term "common status codes" rather than "example status codes" so I will change our draft to use that same terminology. I have now adopted the RFC4918 text as follows: The list below summarizes the most common status codes used for this method. However, clients should be prepared to handle other 2/3/4/5xx series status codes as well. > 7.2.1 day:need-privileges precondition > ---------------------------------------------------- > How is the user authenticated? As per requirements of WebDAV, WebDAV ACL and CalDAV - namely HTTP authentication. This is covered in Section 13 of RFC3744. > 8. Avoiding conflicts when updating scheduling object resources > ------------------------------------------------------------------------- > -------------- First paragraph: reference for ETag and If-Match? > > Fourth paragraph: I don't really get the text, a simple example might > help. This section has been significantly reduced in size and the 4th paragraph is pretty much gone. I have made sure the term ETag is qualified by "HTTP". > 9.2 schedule status values > ------------------------------------ > Is there any reasoning behind the delivery status codes? To the > uninitiated (me) they seem randomly chosen. Servers might send scheduling messages synchronously or asynchronously with respect to the HTTP request. i.e., for synchronous, all scheduling messages to attendees will have been sent and delivered by the time the response is sent back to the client. Whereas, for asynchronous, the server might queue up messages to attendees and process those after sending the HTTP response to the client. Since we do not wish to dictate the nature of a server's implementation in this regard, we have provided sufficient detail in the scheduling status values to accomodate both modes of operation, and to also cover the case where the server might be sending scheduling messages without any guarantee of an acknowledgement (code 1.1). Now strictly speaking we did state in the introduction that we do not cover the case of scheduling with "external" users, but for completeness we felt it important to include the 1.1 code, as many existing implementations do in fact have an "email gateway" feature that does allow sending of iMIP messages - but that is not directly in scope for this specification. > 11.1 additional message header fields > ---------------------------------------------------- > It might make sense to point out that T and F stand for True and False Done. > 12.2 caldav:schedule-default-calendar-url property > --------------------------------------------------------------------- > What does it mean that a property is protected? That is standard WebDAV terminology. See second paragraph of Section 15 of RFC4918. > 15. Security Considerations > -------------------------------------- > You write that servers and clients MUST use TLS. That is not sufficiently > strong, you must make sure that server and client mutually authenticate > each other. I would at the very least expect some text about server > validation [RFC6125] I have added the following to the end of the first paragraph of Section 11: Clients MUST use the procedures detailed in Section 6 of [RFC6125] to verify the authenticity of the server. Servers MUST make use of HTTP authentication [RFC2617] to verify the authenticity of the calendar user for whom the client is sending requests. Would that suffice? > Also, in the main text there is no mentioning of HTTPS, but only HTTP, I > think you need to say also in the main text that you expect a secure > channel (unless you don't?) The requirements for CalDAV (RFC4791) does require TLS. Since there has been push-back from others about the length of the spec and unnecessary repetition, I am tempted to not add an additional statement about TLS support in the main body of the spec, but rather leave that to the security section. > This document leverages iTIP [RFC5546], however that document specifies > an abstract transport protocol, and assumes other documents to implement > particular transports. Furthermore it does't contain any normative > language for dealing with the threats that are identified: > - 6.1.1 Spoofing the "Organizer" > - 6.1.2 Spoofing the "Attendee" > - 6.1.3 Unauthorized Replacement of the Organizer > - 6.1.4 Eavesdropping > - 6.1.5 Flooding a Calendar > - 6.1.6 Procedural Alarms > - 6.1.7 Unauthorized REFRESH Requests > > I would expect in the security considerations mention of these threats > and normative language about at least the authentication of the organizer > to the attendee and the attendee to the organizer. So these threats are covered by the existing requirements in the security section. To make that more obvious, I have added a new sub-section titled "Mitigation of iTIP Threats" that lists each of the iTIP threats and a reference to parts of our specification that deal with those threats. > In the examples there is mention of users @example.org and users > @example.com, I suspect that that means that multiple calendaring domains > can operate in a federated manner, how is the authenticity of a user in > another domain validated? Can only "local users" look up free/busy > information? If not, how do you make sure that not the whole Internet can > lookup for example free/busy information? Unfortunately, because we are limited to "example.ZZZ" domains, it is sometimes confusing in examples where one wants to illustrate the use of different domains, as the only way to do that is by varying the TLD part. In this case the goal is to indicate that example.com users are locally hosted on the server, whereas users in other example.org domains are not. example.net is meant to illustrate an alternative calendar user address that is also valid for calendar users on the server. I have added the following paragraph to the examples section to clarify this: The server is assumed to be hosted in the "example.com" domain, and users whose email address is at the "example.com" domain are assumed to be hosted by the server. In addition, the email addresses in the "example.net" domain are also valid email addresses for calendar users hosted by the server. Calendar users with an email address at the "example.org" domain are assumed to not be hosted by the server. In terms of who can do what, the scheduling privileges basically control that and the fact that the Security section always refers to "authenticated" users - i.e., users "known" to the server. So "external" users are never allowed to access the system to deliver scheduling messages direct to the server or request freebusy of hosted users. > 15.3 Privacy Considerations > > Especially in large deployments spanning many organizations (like Google > Calendar) I think Schedule-Reply request header is not going to cut it. I > would expect at least some discussion about privacy and free/busy > information, information about calendar event traveling over > organizational boundaries (or not) etc.. I have added a new paragraph to the privacy section to try and address this: This specification only defines how calendar users on the same server are able to schedule with each other - unauthenticated users have no way to carry out scheduling operations. Access control privileges (as per Section 6) can control which of those users can schedule with others. Calendar users not wishing to expose their calendar information to other users can do so by denying privileges to specific users, or all users, for all scheduling operations, or perhaps only freebusy. Is that sufficient? -- Cyrus Daboo From msk@cloudmark.com Tue Mar 6 14:21:05 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 6713D21E80CA; Tue, 6 Mar 2012 14:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEBGRw5djAgV; Tue, 6 Mar 2012 14:21:04 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E580721E8013; Tue, 6 Mar 2012 14:21:03 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 6 Mar 2012 14:21:00 -0800 From: "Murray S. Kucherawy" To: Tero Kivinen , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: Review of draft-ietf-marf-dkim-reporting-11 Thread-Index: AQHM+7Jn5hDXdigsDk2cMOfl5q2RKJZd1I8g Date: Tue, 6 Mar 2012 22:20:59 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392807D2D5@exch-mbx901.corp.cloudmark.com> References: <20310.13509.461991.185885@fireball.kivinen.iki.fi> In-Reply-To: <20310.13509.461991.185885@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-marf-dkim-reporting.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-marf-dkim-reporting-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: Tue, 06 Mar 2012 22:21:05 -0000 Hi Tero, thanks for your review. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Tuesday, March 06, 2012 8:01 AM > To: iesg@ietf.org; secdir@ietf.org > Cc: draft-ietf-marf-dkim-reporting.all@tools.ietf.org > Subject: Review of draft-ietf-marf-dkim-reporting-11 >=20 > [...] > This is all fine, but the security considerations section should really > point out that the TXT record is the only part that is really > protecting the signer from distributed bogus reports. Even if signer > does not ever put "r=3Dy" tag in any of the messages, but still publishes > the TXT records "just in case" they ever want to get those reports, the > attacker can modify every single email in transit to include bogus > DKIM-signature field with "r=3Dy" and "d=3D" matching the signer and DKIM > verifiers will start flooding reports to the signer. > Note, that those emails do not even need to be originally have anything > to do with the domain being attacked. >=20 > Actually just adding "r=3Dy" to valid DKIM-Signatures will cause the > signature to fail (if I have understood things correctly), thus > triggering the report. >=20 > So the only way the signer can protect himself against bogus reports is > to remove the TXT records from the DNS. There should be text about this > in the security considerations sections, as otherwise adminstrators > might put those TXT records out there just in case they are needed, and > open themselves to the attack. I've added this paragraph to the end of the current Security Considerations= "Deliberate Misuse" section (pardon the XML): The presence of the DNS record that indicates willingness to accept reports opens the recipient to abuse by any attacker that generates or alters signatures bearing the victim's domain in a DKIM "d=3D" tag by adding an "r=3Dy" tag. Positive caching of this DNS reply also means turning off the flow of reports by removing the record is not likely to have immediate effect. A low time-to-live on the record needs to be considered. Is that sufficient? > On the other hand, even when signer requests reports to verify nobody > is messing up its DKIM-Signatures the attacker can remove the "r=3Dy" > tag from the email (or the whole DKIM-Signature) and in that case the > verifier do not send report to the signer (unless the Author Domain > Signing Practices (ADSP) is in use, but I didn't really check whether > those records are checked if no DKIM fields are found in the email). >=20 > Attacker who wants to modify the emails do not want to advertise this, > thus it will of course remove the "r=3Dy", so it can fly under the > radar... We cover that already in the "DKIM Reporting Algorithm", final paragraph. > ADSP is not spelled out ever, and the reference to the RFC5617 uses > different title than what is the actual title of the RFC5617: >=20 > "DomainKeys Identified Mail (DKIM) Author Domain Signing > Practices (ADSP)" >=20 > vs >=20 > "DKIM Sender Signing Practises". >=20 > so it was bit hard to see what ADSP actually meant, until I actually > checked the RFC5617. I am not sure why the references are getting wrong > titles, as shouldn't the > http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml > references get those directly from RFCs. On the other hand it might be > the references are written out manually... They are, and actually it seems it was imported from a much older document.= ADSP went through several name changes in its lifetime, and that's a fair= ly old one. Anyway, fixed; expanded on first use, and the reference has be= en repaired. > ---------------------------------------------------------------------- > In section 4: >=20 > only. To construct the actual address to which the report is > sent, the Verifier simply appends to this value an "@" followed by > the domain whose policy was queried in order to evaluate the > sender's ADSP, i.e., the one taken from the RFC5322.From domain of > ^^^ > the message under evaluation. Therefore, a signer making use of > this extension tag MUST ensure that an email address thus > constructed can receive reports generated as described in > Section 6. ABNF: >=20 >=20 > It seems there is extra . between the "RFC5322" and "From". Actually it's correct to strike "one taken from the", so I've done that. T= he RFC5322.From notation is introduced by one of the normative references, = namely RFC5598, so I believe it's correct. > ---------------------------------------------------------------------- > In section 5: >=20 > This memo also includes, as the "ro" tags defined above, the means > by > ^^ >=20 > I do not think this document defines "ro" tag, I assume it was meant to > mean "rr" tag instead? Yes, it was renamed during the document's evolution and I missed this one. = Fixed. > ---------------------------------------------------------------------- > In section 5.2: >=20 > How can DKIM ADSP failures ever report "d" type errors, as if they have > DNS issues for fetching ADSP records, they will not get the "rr" > tag saying "d" or "all" types should be reported... It looks like that was copied from the DKIM reporting flags without realizi= ng this discontinuity. I'll remove it. Thanks again, -MSK From d3e3e3@gmail.com Wed Mar 7 07:56: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 EAA6F21E808A; Wed, 7 Mar 2012 07:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.362 X-Spam-Level: X-Spam-Status: No, score=-104.362 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB1cH5VEUARB; Wed, 7 Mar 2012 07:56:45 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B72221E80A7; Wed, 7 Mar 2012 07:56:44 -0800 (PST) Received: by lagj5 with SMTP id j5so9062837lag.31 for ; Wed, 07 Mar 2012 07:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=JdNoi4bw2BfEza5QUuXclREBDb1IPgWA8oK9VykE2lY=; b=V9bKwgsbeQUq2r2GGt0QeFcxHWxM9KQrq74iF1ajQk25Li17NqNF4dxu3JVMGi/A9l 3Z7jzfcJoy3UNlwjVW5zGcpnnk75hqGOFe78RR9xAEdoodFmDTvvNFBdlVupgGSLSbJ6 WXj2NYqQIYHUs6i7Rqafbl2fiSsAjL2MVXECvJJNaOJ/5m2R/a2gTii1oQVDxY3opeaR kVj95gqY6I7WGwqL67oD3kdfFR+ZnrdXn72UBo4CYsTaBbdbpRAIH0VUqkOKGxmjdeM1 mno2EMkUztHOosZcg6jhFXm5QKKEk+I2t/NlzZMwKk2Q0bHZogwlNEZoRPxVarmheUsj hLsA== Received: by 10.152.147.1 with SMTP id tg1mr1762534lab.22.1331135474333; Wed, 07 Mar 2012 07:51:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.29.76 with HTTP; Wed, 7 Mar 2012 07:50:53 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Wed, 7 Mar 2012 10:50:53 -0500 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-manet-packetbb-sec.all@tools.ietf.org Subject: Re: [secdir] draft-ietf-manet-packetbb-sec-08 SecDir review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:56:46 -0000 Thanks, at quick scan, the changes look good. Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, Mar 6, 2012 at 3:31 PM, Ulrich Herberg wrote: > Dear Donald, > > thank you very much for your review of the draft. We have addressed your > comment about section 8.1 and 9.1 in a new revision which we just submitt= ed. > > Best regards > Ulrich > > > On Wed, Feb 29, 2012 at 7:53 AM, Donald Eastlake wrote= : >> >> My apologies for getting this review in late. >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. =A0Document editors and WG chairs should treat these comments just >> like any other last call comments. >> >> Overall, I do not have security concerns with this document. See >> comments below. >> >> This document describes "signature" and "time" building blocks for >> constructing messages/packets as described in RFC 5444. There is >> actually noticeable overlap with Section 7.1 of RFC 5444, enough that >> I am inclined to say that this draft should indicate the it Updates >> 5444. >> >> The Security Considerations Section says "... =A0has the same security >> considerations as [RFC5444]." In turn, RFC 5444 says "This >> specification does not describe a protocol; it describes a packet >> format. =A0As such, it does not specify any security considerations; >> these are matters for a protocol using this specification." :-) But, >> in fact, the Security Considerations Section of 5444 continues with >> design suggestions for authentication/integrity and confidentiality. >> Arguably, this draft provides a more detailed syntax with some >> processing rules for authentication/integrity with signatures >> extending 5444. But it still defers much to any specific MANET >> protocol making use of RFC 5444, this draft, and probably additional >> "building block" drafts or RFCs. >> >> It appears that the MANET WG is approaching all this through a series of >> overlapping documents each of which is of limited content but provides >> more details. For example, this draft sets up hash function and >> cryptographic function IANA registries but provides only the identity >> function as initial content for these registries. Presumably additional >> documents will request allocations from these registries for other >> functions. There is nothing inherently wrong with this approach and >> trying to produce large monolithic documents can have problems. But a >> swarm of smaller inter-related and partly overlapping documents can be >> confusing. >> >> Section 8.1 and 9.1: These sections provide that when adding a packet >> or message signature TLV, respectively, any pre-existing packet or >> messages signature "MUST" be removed, etc., before signature calculation >> but >> only "SHOULD" be restored afterwards. I would have guessed that >> "SHOULD" would be a "MUST". In any case, it might be good to say when >> you don't need to restore a signature TLV, which I would assume would >> be if that signature TLV is not needed by the recipient. >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) >> =A0155 Beaver Street,=A0Milford, MA 01757 USA >> =A0d3e3e3@gmail.com > > From stpeter@stpeter.im Wed Mar 7 07:56:49 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 CA38521E80DA; Wed, 7 Mar 2012 07:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyK8aOTZCgB2; Wed, 7 Mar 2012 07:56:49 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1586A21E80D9; Wed, 7 Mar 2012 07:56:49 -0800 (PST) Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 32FAC4005B; Wed, 7 Mar 2012 09:08:48 -0700 (MST) Message-ID: <4F57853F.2050601@stpeter.im> Date: Wed, 07 Mar 2012 08:56:47 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Richard Barnes References: <3E9A3BC9-6AEB-4E03-A053-5E7A172DA4E7@bbn.com> In-Reply-To: <3E9A3BC9-6AEB-4E03-A053-5E7A172DA4E7@bbn.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Zach Shelby , draft-ietf-core-link-format@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-core-link-format-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: Wed, 07 Mar 2012 15:56:49 -0000 Hi Richard, Thanks for the review. Those suggestions all look reasonable to me, but I will let the document editor (Zach Shelby) reply in detail. Peter On 2/25/12 3:40 AM, Richard Barnes wrote: > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > This document defines a format for describing a list of resources linked from a server, e.g., an HTTP or CoAP server. The document suggests the use of TLS or DTLS on the underlying transport for transport security. My only remaining security concern is that there could be access control concerns as well. For example, a server might not authorize all clients to see all services, or might provide some clients with different levels of access (e.g., read vs. read/write). The document already envisions that the list of links will have some dynamism, allowing for filtering based on link attributes. I would suggest simply noting that servers may want to support HTTP, CoAP, or [D]TLS client authentication and adaptation of the list of returned links based on the client's identity and authorizations. > > Suggested text for Section 6: > " > Some servers may provide resource discovery services to a mix of clients that are trusted to different levels. For example, a lighting control system might allow any client to read state variables, but only certain clients to write state (turn lights on or off). Servers SHOULD support authentication features of the underlying transport protocols (HTTP, CoAP, or DTLS/TLS) and allow operators to return different lists of links based on a client's identity and authorization. > " > > Non security-related comments follow. > > General: This document seems a little bit awkward semantically. The HTTP Link header is intended to provide links from a given resource (identified by the request URI) to associated resources. The service described in this document seems to provide a general list of URIs, without a firm idea of what the "source" of these references is. Indeed, with the "anchor" parameter, it seems like this document allows a service at "/.well-known/core" to act as a general "Tell me about this URI" service, which seems over-broad. Is this the intent of the WG? Perhaps the "anchor" parameter should be restricted to relative, not absolute, URIs? And how is this different from just doing a HEAD request to the URI to get a Link header that would contain the same information? > > General: In a similar vein, it seems like this format need not necessarily be restricted to CORE. Might it not have more general utility for HTTP service discovery? Really the only impact would be to change the name of the well-known URI from "core" to something more generic. > > Section 1.2.1: Quotes or angle-brackets around "/.well-known/core" > > Section 1.2.3: The word "filtering" is used here before it is defined. > > Section 2: The document hints at conversion from the HTTP Link header a couple of times. It seems like it would be helpful to lay out the conversion rules in detail. It seems like you may at least need to convert some things to UTF-8? > > Section 2.1: It sounds like the default context URI you're envisioning here is essentially the same as the Origin associated with the scheme, host, and port: > > > Section 3.1: s/semantically important/application specific semantic/ > > Section 3.3: The MTU might not be the relevant metric for TCP-based transport (e.g., HTTP) > > Section 4.1: It seems like the byte-equality matching here might create a disconnect here between the query patterns you can write and parameters you can have. In particular, it seems like you might at least need to decode percent-encoding before comparison. Otherwise, you might have parameters that are un-filterable. > > Section 7.3: Should the "Encoding considerations" say something about it always being UTF-8? > > > From klaas@cisco.com Thu Mar 8 03:11:46 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 D9F0721F8680; Thu, 8 Mar 2012 03:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.359 X-Spam-Level: X-Spam-Status: No, score=-9.359 tagged_above=-999 required=5 tests=[AWL=1.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmvzyB8dquYI; Thu, 8 Mar 2012 03:11:45 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 14AD621F867F; Thu, 8 Mar 2012 03:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=14702; q=dns/txt; s=iport; t=1331205105; x=1332414705; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MVSZSH1uLM9KQRWpMBRP0Tju/RruJ+lwxkOJ746n86w=; b=dasrvu8dhAHEnK16dJrcTvZLT20E1vtahM4DuCuFw4E3DV6HdbwClh12 eyU1L4RRZCqGNsYygXZXSN9T6LIbA0dVvdZtcb0g/rWHLqSpQHcC4916a G69AblZ/t6csAbjEpRda+Q5S2MCcd4ybLVn9fWIDe8fYBcryw+nIIa07x I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKCTWE+tJXG+/2dsb2JhbABCtSuBB4IKAQEBAwESAWUBBQsLGAkWDwkDAgECAUUGDQEFAgEBHodjBZ99AZc4iiIBhksEkWWDYIU3imGCZIFTAgYR X-IronPort-AV: E=Sophos;i="4.73,551,1325462400"; d="scan'208";a="64760445" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 08 Mar 2012 11:11:44 +0000 Received: from macmini.wierenga.net (rtp-kwiereng-8714.cisco.com [10.116.7.37]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q28BBgMZ009098; Thu, 8 Mar 2012 11:11:43 GMT Message-ID: <4F5893EE.1060202@cisco.com> Date: Thu, 08 Mar 2012 12:11:42 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Cyrus Daboo References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-desruisseaux-caldav-sched.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] review of draft-desruisseaux-caldav-sched-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 11:11:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/6/12 10:04 PM, Cyrus Daboo wrote: Hi Cyrus, > Thank you very much for our review. FYI, following some other > comments you're welcome > we have received, we have undertaken some significant > editorial-only changes to this draft to, in particular, clarify and > simplify introductory and descriptive elements. As such, several of > your issues have been addressed (or eliminated) in our working > copy. > > --On March 3, 2012 5:05:08 PM +0100 Klaas Wierenga > wrote: > >> ====== >> >> 1.2 approach ------------------ bullet 1 and 2 together seem to >> form 1 problem, bullet 1 is just stating a fact. > > That bulleted list has been eliminated as it was added as > justification for a change of approach made earlier during the > lifecycle of this draft and is no longer relevant. ack > >> something that must have been discussed in extremes, but I can't >> help wondering what the reasoning is for not making the server >> responsible for sending and processing scheduling messages, is >> that a legacy thing? It seems to overly complicate this document >> that always 2 cases need to be distinguished. > > So the SCHEDULE-AGENT parameter defined in this spec defaults to > having the server do scheduling operations (sending, processing > etc). However, there may be times when the client really needs to > be able to do it itself. In particular, if there are attendees in > an event who are not hosted on the CalDAV server, then the server > might not be able to deliver any message to those attendees. In > such a case a client might want to take over scheduling for those > attendees (send iMIP - email - messages instead). In that situation > it is important that all clients know this is going on, hence the > need for SCHEDULE-AGENT=CLIENT. In other cases it might be known > that the attendee has been informed of the meeting in an > "out-of-band" manner and there is no need for actual > iCalendar-based scheduling - that defines the need for > SCHEDULE-AGENT=NONE. Having these different modes of operation does > mean more complexity, but they are driven by important > requirements. ok, fair enough, this shows my lack of understanding of the specifics > >> 1.3 limitations ------------------- I can't help a chuckle with >> the statement "to keep this specification simple", I think >> simplicity got lost somewhere in the process. I probably would >> have considered breaking the document up in multiple documents. > > That has been rewritten and that particularly humorous statement is > now gone :-) ;-) > >> 4. scheduling collections --------------------------------- can >> the server only create or also delete the collections? > > Well the only case where the server might delete them is if the > user were "downgraded" and had scheduling capability totally > removed. That is probably an unlikely scenario, and in any event, > can be accomplished by simply setting scheduling ACLs for the user > to deny scheduling. So at this point I would rather leave it as-is > and not mention that servers can delete. ok, it is just that I believe I will not be the only one wondering about delete. > >> 4.1 scheduling outbox collections >> --------------------------------------------- >> caldav-max-resource-size, not using this seems to invite DoS >> attacks, perhaps make it a SHOULD to support this and mention in >> the security considerations the possibility of DoS attacks? (same >> goes for 4.2) > > I have added a new section to Security considerations: > > 11.1 Preventing Denial of Service Attacks > > Servers MUST ensure that clients cannot consume excessive server > resources by carrying out "large" scheduling operations. In > particular, servers SHOULD enforce CALDAV:max-resource-size, > CALDAV:max-instances and CALDAV:max-attendees-per-instance > pre-conditions as applicable for scheduling Inbox and Outbox > collections. > > Does that address your concern? yes, thank you! > >> 5.2.2.2 create ------------------ In which cases can scheduling >> messages be delivered directly to the client? And can't you >> forbid that? > > This again reflects the possibility of scheduling with users not > hosted on the CalDAV server. In this case an attendee receives a > scheduling message via iMIP (email) from an organizer not on the > server. They may want to store the event on their CalDAV server so > they can view it on all their devices. I have added an "e.g." into > that sentence to help clarify: > > However, in some cases a scheduling message can get delivered > directly to the client (e.g., via email [RFC6047]) > > Hopefully, that will clarify what is meant. yes it does > >> 6 processing incoming scheduling messages >> ------------------------------------------------------------- Can >> you be more specific about WHERE in RFC5546 these rules are >> specified? > > Well it is really all of Section 2 and 3 of RFC5546 - which is > pretty much the whole specification. I don't think it is possible > to be more specific than that without having a long list of > sub-sections. perhaps just say "in sections 2 and 3 of RFC5546"? but no big deal > >> 7.1 status codes ---------------------- These are EXAMPLE >> response codes? Why not normative? And doesn't that give >> interoperability issues? > > Well WebDAV and HTTP have traditionally allowed response codes to > varying depending on what a server might want to do. e.g., in some > cases a server might want to return a body on a successful PUT, in > which case a 200 would be returned instead of a 204. Now, the > WebDAV base spec (RFC4918) uses the term "common status codes" > rather than "example status codes" so I will change our draft to > use that same terminology. I have now adopted the RFC4918 text as > follows: > > The list below summarizes the most common status codes used for > this method. However, clients should be prepared to handle other > 2/3/4/5xx series status codes as well. ack >> 7.2.1 day:need-privileges precondition >> ---------------------------------------------------- How is the >> user authenticated? > > As per requirements of WebDAV, WebDAV ACL and CalDAV - namely HTTP > authentication. This is covered in Section 13 of RFC3744. ok > >> 8. Avoiding conflicts when updating scheduling object resources >> ------------------------------------------------------------------------- >> >> - -------------- First paragraph: reference for ETag and If-Match? >> >> Fourth paragraph: I don't really get the text, a simple example >> might help. > > This section has been significantly reduced in size and the 4th > paragraph is pretty much gone. I have made sure the term ETag is > qualified by "HTTP". ok > >> 9.2 schedule status values ------------------------------------ >> Is there any reasoning behind the delivery status codes? To the >> uninitiated (me) they seem randomly chosen. > > Servers might send scheduling messages synchronously or > asynchronously with respect to the HTTP request. i.e., for > synchronous, all scheduling messages to attendees will have been > sent and delivered by the time the response is sent back to the > client. Whereas, for asynchronous, the server might queue up > messages to attendees and process those after sending the HTTP > response to the client. Since we do not wish to dictate the nature > of a server's implementation in this regard, we have provided > sufficient detail in the scheduling status values to accomodate > both modes of operation, and to also cover the case where the > server might be sending scheduling messages without any guarantee > of an acknowledgement (code 1.1). Now strictly speaking we did > state in the introduction that we do not cover the case of > scheduling with "external" users, but for completeness we felt it > important to include the 1.1 code, as many existing implementations > do in fact have an "email gateway" feature that does allow sending > of iMIP messages - but that is not directly in scope for this > specification. sorry, I formulated poorly, I was just refering to the fact that the numbering didn't go 1,2,3,4.... so I was wondering about the significance of the chosen numbers >> 11.1 additional message header fields >> ---------------------------------------------------- It might >> make sense to point out that T and F stand for True and False > > Done. ok > >> 12.2 caldav:schedule-default-calendar-url property >> --------------------------------------------------------------------- >> >> What does it mean that a property is protected? > > That is standard WebDAV terminology. See second paragraph of > Section 15 of RFC4918. ok > >> 15. Security Considerations >> -------------------------------------- You write that servers and >> clients MUST use TLS. That is not sufficiently strong, you must >> make sure that server and client mutually authenticate each >> other. I would at the very least expect some text about server >> validation [RFC6125] > > I have added the following to the end of the first paragraph of > Section 11: > > Clients MUST use the procedures detailed in Section 6 of [RFC6125] > to verify the authenticity of the server. Servers MUST make use of > HTTP authentication [RFC2617] to verify the authenticity of the > calendar user for whom the client is sending requests. > > Would that suffice? for me it does, but having gone through this discussion myself for draft-ietf-sasl-saml myself the IESG might have some additional comments ;-) > >> Also, in the main text there is no mentioning of HTTPS, but only >> HTTP, I think you need to say also in the main text that you >> expect a secure channel (unless you don't?) > > The requirements for CalDAV (RFC4791) does require TLS. Since there > has been push-back from others about the length of the spec and > unnecessary repetition, I am tempted to not add an additional > statement about TLS support in the main body of the spec, but > rather leave that to the security section. ok, I can live with that > >> This document leverages iTIP [RFC5546], however that document >> specifies an abstract transport protocol, and assumes other >> documents to implement particular transports. Furthermore it >> does't contain any normative language for dealing with the >> threats that are identified: - 6.1.1 Spoofing the "Organizer" - >> 6.1.2 Spoofing the "Attendee" - 6.1.3 Unauthorized Replacement of >> the Organizer - 6.1.4 Eavesdropping - 6.1.5 Flooding a Calendar - >> 6.1.6 Procedural Alarms - 6.1.7 Unauthorized REFRESH >> Requests >> >> I would expect in the security considerations mention of these >> threats and normative language about at least the authentication >> of the organizer to the attendee and the attendee to the >> organizer. > > So these threats are covered by the existing requirements in the > security section. To make that more obvious, I have added a new > sub-section titled "Mitigation of iTIP Threats" that lists each of > the iTIP threats and a reference to parts of our specification that > deal with those threats. perfect > >> In the examples there is mention of users @example.org and users >> @example.com, I suspect that that means that multiple calendaring >> domains can operate in a federated manner, how is the >> authenticity of a user in another domain validated? Can only >> "local users" look up free/busy information? If not, how do you >> make sure that not the whole Internet can lookup for example >> free/busy information? > > Unfortunately, because we are limited to "example.ZZZ" domains, it > is sometimes confusing in examples where one wants to illustrate > the use of different domains, as the only way to do that is by > varying the TLD part. In this case the goal is to indicate that > example.com users are locally hosted on the server, whereas users > in other example.org domains are not. example.net is meant to > illustrate an alternative calendar user address that is also valid > for calendar users on the server. I have added the following > paragraph to the examples section to clarify this: > > The server is assumed to be hosted in the "example.com" domain, > and users whose email address is at the "example.com" domain are > assumed to be hosted by the server. In addition, the email > addresses in the "example.net" domain are also valid email > addresses for calendar users hosted by the server. Calendar users > with an email address at the "example.org" domain are assumed to > not be hosted by the server. ok, that clarifies at least for me a lot. > > In terms of who can do what, the scheduling privileges basically > control that and the fact that the Security section always refers > to "authenticated" users - i.e., users "known" to the server. So > "external" users are never allowed to access the system to deliver > scheduling messages direct to the server or request freebusy of > hosted users. yes, with the previous item that makes sense > >> 15.3 Privacy Considerations >> >> Especially in large deployments spanning many organizations (like >> Google Calendar) I think Schedule-Reply request header is not >> going to cut it. I would expect at least some discussion about >> privacy and free/busy information, information about calendar >> event traveling over organizational boundaries (or not) etc.. > > I have added a new paragraph to the privacy section to try and > address this: > > This specification only defines how calendar users on the same > server are able to schedule with each other - unauthenticated users > have no way to carry out scheduling operations. Access control > privileges (as per Section 6) can control which of those users can > schedule with others. Calendar users not wishing to expose their > calendar information to other users can do so by denying privileges > to specific users, or all users, for all scheduling operations, or > perhaps only freebusy. > > Is that sufficient? > yes Thank you! Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9Yk+4ACgkQH2Wy/p4XeFIp2ACfTcBrL62BU1AnqdEkdEDOu9NT ycwAnRSE0gJRLd7ArU4Qum3vTSrrREza =0h0R -----END PGP SIGNATURE----- From kivinen@iki.fi Thu Mar 8 05:59:49 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 0E66821F867E; Thu, 8 Mar 2012 05:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6L4PlBIThjN5; Thu, 8 Mar 2012 05:59:48 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F2D21F8674; Thu, 8 Mar 2012 05:59:47 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q28DxeD0017540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 15:59:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q28DxdlY028724; Thu, 8 Mar 2012 15:59:39 +0200 (EET) 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: <20312.47947.44384.921886@fireball.kivinen.iki.fi> Date: Thu, 8 Mar 2012 15:59:39 +0200 From: Tero Kivinen To: "Murray S. Kucherawy" In-Reply-To: <9452079D1A51524AA5749AD23E00392807D2D5@exch-mbx901.corp.cloudmark.com> References: <20310.13509.461991.185885@fireball.kivinen.iki.fi> <9452079D1A51524AA5749AD23E00392807D2D5@exch-mbx901.corp.cloudmark.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 11 min Cc: "draft-ietf-marf-dkim-reporting.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-marf-dkim-reporting-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 13:59:49 -0000 Murray S. Kucherawy writes: > I've added this paragraph to the end of the current Security > Considerations "Deliberate Misuse" section (pardon the XML): > > The presence of the DNS record that indicates > willingness to accept reports opens the > recipient to abuse by any attacker that generates > or alters signatures bearing the victim's > domain in a DKIM "d=" tag by adding an "r=y" tag. > Positive caching of this DNS reply also means > turning off the flow of reports > by removing the record is not likely to have > immediate effect. A low time-to-live on the > record needs to be considered. > > Is that sufficient? It is actually inaccurate, as the "d=" tag is not needed, as attacker can add (or modify the existing d= tag) it as needed. The attacker can even add DKIM-Signature headers to completely unrelated emails with "d=" matching the intended victim. I.e spambot system could add DKIM signature header to all spams it is sending out and put d=victim.example.com and r=y to the headers and cause all spam recipient seeing this kind of email to attack the victim. The comment about the positive caching and low TTL is actually very good, and I missed those when reading the document myself. > > On the other hand, even when signer requests reports to verify nobody > > is messing up its DKIM-Signatures the attacker can remove the "r=y" > > tag from the email (or the whole DKIM-Signature) and in that case the > > verifier do not send report to the signer (unless the Author Domain > > Signing Practices (ADSP) is in use, but I didn't really check whether > > those records are checked if no DKIM fields are found in the email). > > > > Attacker who wants to modify the emails do not want to advertise this, > > thus it will of course remove the "r=y", so it can fly under the > > radar... > > We cover that already in the "DKIM Reporting Algorithm", final > paragraph. Partially yes, but I think it should also be mentioned in the Security Considerations section from the attackers point of view. The text in the DKIM Reporting Algorithm section is mostly from the Signers and Verifiers point of view. > > ---------------------------------------------------------------------- > > In section 4: > > > > only. To construct the actual address to which the report is > > sent, the Verifier simply appends to this value an "@" followed by > > the domain whose policy was queried in order to evaluate the > > sender's ADSP, i.e., the one taken from the RFC5322.From domain of > > ^^^ > > the message under evaluation. Therefore, a signer making use of > > this extension tag MUST ensure that an email address thus > > constructed can receive reports generated as described in > > Section 6. ABNF: > > > > > > It seems there is extra . between the "RFC5322" and "From". > > Actually it's correct to strike "one taken from the", so I've done > that. The RFC5322.From notation is introduced by one of the > normative references, namely RFC5598, so I believe it's correct. It would be useful to put some kind of quotes around it, i.e. either or "RFC5322.From" or similar so reader will understand it is one token, not just mistake. Also I searched that form from RFC5322, as that was where I expected to find it, so adding reference to [RFC5598] at this point would help a lot too. -- kivinen@iki.fi From msk@cloudmark.com Thu Mar 8 10:51:26 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 D4B1721F861A; Thu, 8 Mar 2012 10:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xOTEn3QWeet; Thu, 8 Mar 2012 10:51:24 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A2DC621F85AD; Thu, 8 Mar 2012 10:51:24 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 10:51:23 -0800 From: "Murray S. Kucherawy" To: Tero Kivinen Thread-Topic: Review of draft-ietf-marf-dkim-reporting-11 Thread-Index: AQHM+7Jn5hDXdigsDk2cMOfl5q2RKJZd1I8ggAMhkID//73RAA== Date: Thu, 8 Mar 2012 18:51:23 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928080B06@exch-mbx901.corp.cloudmark.com> References: <20310.13509.461991.185885@fireball.kivinen.iki.fi> <9452079D1A51524AA5749AD23E00392807D2D5@exch-mbx901.corp.cloudmark.com> <20312.47947.44384.921886@fireball.kivinen.iki.fi> In-Reply-To: <20312.47947.44384.921886@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-marf-dkim-reporting.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-marf-dkim-reporting-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:51:29 -0000 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Thursday, March 08, 2012 6:00 AM > To: Murray S. Kucherawy > Cc: iesg@ietf.org; secdir@ietf.org; draft-ietf-marf-dkim-reporting.all@to= ols.ietf.org > Subject: RE: Review of draft-ietf-marf-dkim-reporting-11 >=20 > Murray S. Kucherawy writes: > > I've added this paragraph to the end of the current Security > > Considerations "Deliberate Misuse" section (pardon the XML): > > > > The presence of the DNS record that indicates > > willingness to accept reports opens the=09 > > recipient to abuse by any attacker that generates > > or alters signatures bearing the victim's=09 > > domain in a DKIM "d=3D" tag by adding an "r=3Dy" tag. > > Positive caching of this DNS reply also means > > turning off the flow of reports > > by removing the record is not likely to have > > immediate effect. A low time-to-live on the > > record needs to be considered. > > > > Is that sufficient? >=20 > It is actually inaccurate, as the "d=3D" tag is not needed, as attacker > can add (or modify the existing d=3D tag) it as needed. The attacker can > even add DKIM-Signature headers to completely unrelated emails with > "d=3D" matching the intended victim. The proposed text above says "generates", which covers the case of delibera= tely adding bad signatures to messages. The "alters" case would be someone= taking a valid signature and adding "r=3Dy" to it, optionally changing the= "d=3D", to cause the attack. "d=3D" is always needed in a DKIM signature, or it's syntactically invalid = to begin with. > I.e spambot system could add DKIM signature header to all spams it is > sending out and put d=3Dvictim.example.com and r=3Dy to the headers and > cause all spam recipient seeing this kind of email to attack the > victim. Doesn't the "generates" case in the above text already cover that instance? Let's try this instead, which I hope is more clear and explicit about the p= roblem and the solution: The presence of the DNS record that indicates willingness to accept reports opens the recipient to abuse. In particular, it is possible for an attacker to attempt to cause a flood of reports toward the domain identified in a signature's "d=3D" tag in one of these ways: 1. Alter existing signatures by adding an "r=3Dy" tag (and possibly altering the "d=3D" tag to point at the target domain); 2. Add a new but invalid signature bearing an "r=3Dy" tag and a "d=3D" tag pointing at the target domain; 3. Generate a completely new message bearing an "r=3Dy" tag and a "d=3D= " tag pointing at the target domain. Implementers are therefore strongly advised not to advertise that DNS record except when reports desired, including the risk of receiving this kind of attack. Positive caching of this DNS reply also means turning off the flow of reports by removing the record is not likely to have immediate effect. A low time-to-live on the record needs to be considered. How does that look? > > > On the other hand, even when signer requests reports to verify > > > nobody is messing up its DKIM-Signatures the attacker can remove the = "r=3Dy" > > > tag from the email (or the whole DKIM-Signature) and in that case > > > the verifier do not send report to the signer (unless the Author > > > Domain Signing Practices (ADSP) is in use, but I didn't really check > > > whether those records are checked if no DKIM fields are found in the = email). > > > > > > Attacker who wants to modify the emails do not want to advertise > > > this, thus it will of course remove the "r=3Dy", so it can fly under > > > the radar... > > > > We cover that already in the "DKIM Reporting Algorithm", final > > paragraph. >=20 > Partially yes, but I think it should also be mentioned in the Security > Considerations section from the attackers point of view. The text in > the DKIM Reporting Algorithm section is mostly from the Signers and > Verifiers point of view. I think to address this I'll move the text at the end of 3.3 into Security = Considerations, where I will describe the problem from both sides. Here's = the new subsection: 8.3. Unreported Fraud An attacker can craft fraudulent DKIM-Signature fields on messages, without using "r=3D" tags, and avoid having these reported. The procedure described in Section 3.3 does not permit the detection and reporting of such cases. It might be useful to some Signers to receive such reports, but the mechanism does not support it. To offer such support, a Verifier would have to violate the first step in the algorithm and continue even in the absence of an "r=3D" tag. Although that would enable the desired report, it would also create a possible denial-of-service attack: such Verifiers would always look for the reporting TXT record, so a generator of fraudulent messages could simply send a large volume of messages without an "r=3D" tag to a number of destinations. To avoid that outcome, reports of fraudulent DKIM- Signature header fields are not possible using the published mechanism. > > Actually it's correct to strike "one taken from the", so I've done > > that. The RFC5322.From notation is introduced by one of the normative > > references, namely RFC5598, so I believe it's correct. >=20 > It would be useful to put some kind of quotes around it, i.e. either > or "RFC5322.From" or similar so reader will understand > it is one token, not just mistake. Also I searched that form from > RFC5322, as that was where I expected to find it, so adding reference > to [RFC5598] at this point would help a lot too. Fair enough, but I prefer to have references like that, which introduce not= ational conventions, up in the "Definitions" section. I'll take care of th= at now too. Thanks, -MSK From rbarnes@bbn.com Thu Mar 8 11:54: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 ABF6B21E800C; Thu, 8 Mar 2012 11:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.347 X-Spam-Level: X-Spam-Status: No, score=-106.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqQONsJshhfH; Thu, 8 Mar 2012 11:54:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D9A3621F8672; Thu, 8 Mar 2012 11:54:29 -0800 (PST) Received: from ros-dhcp192-1-51-17.bbn.com ([192.1.51.17]:51778) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S5jPk-00094a-Qz; Thu, 08 Mar 2012 14:54:16 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 8 Mar 2012 14:54:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <95A990F2-89D7-4CE9-B751-36E58E725AF0@bbn.com> References: <3E9A3BC9-6AEB-4E03-A053-5E7A172DA4E7@bbn.com> To: Zach Shelby X-Mailer: Apple Mail (2.1257) Cc: draft-ietf-core-link-format@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-core-link-format-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:54:30 -0000 Hey Zach, Glad to be helpful. Sounds like we're basically on the same page; = couple of minor responses inline. > Richard, >=20 > Thanks for the review, see my responses in-line.=20 >=20 > On Feb 25, 2012, at 12:40 PM, Richard Barnes wrote: >=20 >> I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >>=20 >> This document defines a format for describing a list of resources = linked from a server, e.g., an HTTP or CoAP server. The document = suggests the use of TLS or DTLS on the underlying transport for = transport security. My only remaining security concern is that there = could be access control concerns as well. For example, a server might = not authorize all clients to see all services, or might provide some = clients with different levels of access (e.g., read vs. read/write). = The document already envisions that the list of links will have some = dynamism, allowing for filtering based on link attributes. I would = suggest simply noting that servers may want to support HTTP, CoAP, or = [D]TLS client authentication and adaptation of the list of returned = links based on the client's identity and authorizations. =20 >>=20 >> Suggested text for Section 6: >> " >> Some servers may provide resource discovery services to a mix of = clients that are trusted to different levels. For example, a lighting = control system might allow any client to read state variables, but only = certain clients to write state (turn lights on or off). Servers SHOULD = support authentication features of the underlying transport protocols = (HTTP, CoAP, or DTLS/TLS) and allow operators to return different lists = of links based on a client's identity and authorization. >> " >=20 > Excellent suggestion, I will make a ticket.=20 >=20 >>=20 >> Non security-related comments follow. >>=20 >> General: This document seems a little bit awkward semantically. The = HTTP Link header is intended to provide links from a given resource = (identified by the request URI) to associated resources. The service = described in this document seems to provide a general list of URIs, = without a firm idea of what the "source" of these references is. >=20 > The source (context) of the references is meant to be the server = itself. Our main use case is the discovery of resources that a web = server is hosting. A secondary use case would be to describe relations = between resources on the same server (but this is rare for constrained = devices).=20 >=20 >> Indeed, with the "anchor" parameter, it seems like this document = allows a service at "/.well-known/core" to act as a general "Tell me = about this URI" service, which seems over-broad. Is this the intent of = the WG? =20 >=20 > No, that is not the intent.=20 >=20 >> Perhaps the "anchor" parameter should be restricted to relative, not = absolute, URIs? =20 >=20 > Yes, this is something that we could certainly do. One aspect that I = would point out is that the list of resources that a web server has may = also be hosted by a resource directory on behalf of the server (see = draft-shelby-core-resource-directory). Currently we are not using the = anchor parameter for that, so your suggestion should not be a problem.=20= >=20 >> And how is this different from just doing a HEAD request to the URI = to get a Link header that would contain the same information? >=20 > Of course that would work for the HTTP case (CoAP does not have a Link = header), but it would only provide links related to that particular = request URI. The intention of this link document available on = /.well-known/core is that it returns the resources the server has = available (at least the top-level ones that are useful to discover).=20 Sorry, I had missed this subtlety. Now the .well-known approach makes = more sense. >> General: In a similar vein, it seems like this format need not = necessarily be restricted to CORE. Might it not have more general = utility for HTTP service discovery? Really the only impact would be to = change the name of the well-known URI from "core" to something more = generic. >=20 > That is the intention that this is equally applicable to both HTTP and = CoAP, and in general CoRE is about RESTful environments so I wouldn't = think the /.well-known/core really limits anything. Although I would = mainly recommend this /.well-known/core mechanism for machine-to-machine = web applications, for more general web page discovery there are other = technologies already available in the App area. =20 If the idea is to describe things on this server, maybe the right tag is = "/.well-known/here" :) Best, --Richard From zach@sensinode.com Thu Mar 8 11:46:41 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 9B2C121F84F5; Thu, 8 Mar 2012 11:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93fIbXn75YNn; Thu, 8 Mar 2012 11:46:40 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 469DB21F84E0; Thu, 8 Mar 2012 11:46:39 -0800 (PST) Received: from [192.168.1.103] (178-55-87-130.bb.dnainternet.fi [178.55.87.130]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q28JkFgW003139; Thu, 8 Mar 2012 21:46:16 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <3E9A3BC9-6AEB-4E03-A053-5E7A172DA4E7@bbn.com> Date: Thu, 8 Mar 2012 21:46:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3E9A3BC9-6AEB-4E03-A053-5E7A172DA4E7@bbn.com> To: Richard Barnes X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 08 Mar 2012 14:34:34 -0800 Cc: draft-ietf-core-link-format@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-core-link-format-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:46:41 -0000 Richard, Thanks for the review, see my responses in-line.=20 On Feb 25, 2012, at 12:40 PM, Richard Barnes 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. >=20 > This document defines a format for describing a list of resources = linked from a server, e.g., an HTTP or CoAP server. The document = suggests the use of TLS or DTLS on the underlying transport for = transport security. My only remaining security concern is that there = could be access control concerns as well. For example, a server might = not authorize all clients to see all services, or might provide some = clients with different levels of access (e.g., read vs. read/write). = The document already envisions that the list of links will have some = dynamism, allowing for filtering based on link attributes. I would = suggest simply noting that servers may want to support HTTP, CoAP, or = [D]TLS client authentication and adaptation of the list of returned = links based on the client's identity and authorizations. =20 >=20 > Suggested text for Section 6: > " > Some servers may provide resource discovery services to a mix of = clients that are trusted to different levels. For example, a lighting = control system might allow any client to read state variables, but only = certain clients to write state (turn lights on or off). Servers SHOULD = support authentication features of the underlying transport protocols = (HTTP, CoAP, or DTLS/TLS) and allow operators to return different lists = of links based on a client's identity and authorization. > " Excellent suggestion, I will make a ticket.=20 >=20 > Non security-related comments follow. >=20 > General: This document seems a little bit awkward semantically. The = HTTP Link header is intended to provide links from a given resource = (identified by the request URI) to associated resources. The service = described in this document seems to provide a general list of URIs, = without a firm idea of what the "source" of these references is. The source (context) of the references is meant to be the server itself. = Our main use case is the discovery of resources that a web server is = hosting. A secondary use case would be to describe relations between = resources on the same server (but this is rare for constrained devices).=20= > Indeed, with the "anchor" parameter, it seems like this document = allows a service at "/.well-known/core" to act as a general "Tell me = about this URI" service, which seems over-broad. Is this the intent of = the WG? =20 No, that is not the intent.=20 > Perhaps the "anchor" parameter should be restricted to relative, not = absolute, URIs? =20 Yes, this is something that we could certainly do. One aspect that I = would point out is that the list of resources that a web server has may = also be hosted by a resource directory on behalf of the server (see = draft-shelby-core-resource-directory). Currently we are not using the = anchor parameter for that, so your suggestion should not be a problem.=20= > And how is this different from just doing a HEAD request to the URI to = get a Link header that would contain the same information? Of course that would work for the HTTP case (CoAP does not have a Link = header), but it would only provide links related to that particular = request URI. The intention of this link document available on = /.well-known/core is that it returns the resources the server has = available (at least the top-level ones that are useful to discover).=20 > General: In a similar vein, it seems like this format need not = necessarily be restricted to CORE. Might it not have more general = utility for HTTP service discovery? Really the only impact would be to = change the name of the well-known URI from "core" to something more = generic. That is the intention that this is equally applicable to both HTTP and = CoAP, and in general CoRE is about RESTful environments so I wouldn't = think the /.well-known/core really limits anything. Although I would = mainly recommend this /.well-known/core mechanism for machine-to-machine = web applications, for more general web page discovery there are other = technologies already available in the App area. =20 > Section 1.2.1: Quotes or angle-brackets around "/.well-known/core" OK. >=20 > Section 1.2.3: The word "filtering" is used here before it is defined. OK. > Section 2: The document hints at conversion from the HTTP Link header = a couple of times. It seems like it would be helpful to lay out the = conversion rules in detail. It seems like you may at least need to = convert some things to UTF-8? Yes, I will make a ticket to open up that explanation.=20 > Section 2.1: It sounds like the default context URI you're envisioning = here is essentially the same as the Origin associated with the scheme, = host, and port: > Yes, I think that would be a useful reference (Section 4 of RFC6454). So = the default context URI is the Origin of the requested URI. I will make = a ticket to add that reference unless someone thinks that would be a bad = idea.=20 >=20 > Section 3.1: s/semantically important/application specific semantic/ OK. >=20 > Section 3.3: The MTU might not be the relevant metric for TCP-based = transport (e.g., HTTP) Right. Still would like to recommend that even for HTTP knowing the size = ahead of time would be useful.=20 >=20 > Section 4.1: It seems like the byte-equality matching here might = create a disconnect here between the query patterns you can write and = parameters you can have. In particular, it seems like you might at = least need to decode percent-encoding before comparison. Otherwise, you = might have parameters that are un-filterable. OK, I will work with Carsten to figure that out.=20 > Section 7.3: Should the "Encoding considerations" say something about = it always being UTF-8? Peter, I think we discussed that with both you and Alexey at some point = during earlier reviews, and the end result was just to say "Binary = data". Anyone remember why we didn't mention UTF-8? Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From weiler+secdir@watson.org Thu Mar 8 14:41:39 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 C010D21E8021 for ; Thu, 8 Mar 2012 14:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqXVJM7s1DOk for ; Thu, 8 Mar 2012 14:41:39 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 16E1521F85E0 for ; Thu, 8 Mar 2012 14:41:39 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q28MfcvI078706 for ; Thu, 8 Mar 2012 17:41:38 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q28MfcAe078700 for ; Thu, 8 Mar 2012 17:41:38 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 8 Mar 2012 17:41:37 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 08 Mar 2012 17:41:38 -0500 (EST) 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, 08 Mar 2012 22:41:39 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yaron Sheffer is next in the rotation. For telechat 2012-03-15 Reviewer LC end Draft Rob Austein T 2012-02-28 draft-ietf-adslmib-gbond-tdim-mib-07 Phillip Hallam-Baker T 2012-03-13 draft-ietf-pcn-3-in-1-encoding-08 Leif Johansson T 2012-03-06 draft-ietf-decade-problem-statement-05 Scott Kelly T 2012-03-15 draft-ietf-appsawg-xdash-03 Warren Kumari T 2012-03-14 draft-ietf-marf-spf-reporting-08 Matt Lepinski T 2012-03-09 draft-ietf-pwe3-packet-pw-03 David McGrew T 2012-03-08 draft-ietf-opsawg-management-stds-05 Magnus Nystrom T 2012-03-20 draft-ietf-multimob-igmp-mld-tuning-05 Nico Williams T 2012-03-14 draft-garcia-shim6-applicability-03 Glen Zorn T 2012-02-28 draft-ietf-adslmib-gbond-eth-mib-05 For telechat 2012-04-12 Alexey Melnikov T 2012-03-22 draft-ietf-behave-nat64-learn-analysis-03 Kathleen Moriarty T 2012-03-20 draft-ietf-bmwg-protection-meth-09 Russ Mundy T 2012-03-20 draft-ietf-fecframe-raptor-10 Sandy Murphy T 2012-03-19 draft-ietf-ippm-rt-loss-03 Tim Polk T 2012-02-07 draft-ietf-oauth-v2-bearer-17 Eric Rescorla T 2012-03-20 draft-ietf-savi-dhcp-12 Last calls and special requests: Jeffrey Hutzelman 2012-03-21 draft-betts-itu-oam-ach-code-point-03 Charlie Kaufman 2012-03-12 draft-ietf-hokey-rfc5296bis-06 Chris Lonvick 2012-03-28 draft-melnikov-smtp-priority-09 Catherine Meadows 2012-03-22 draft-ietf-avtcore-ecn-for-rtp-06 Hilarie Orman 2012-03-21 draft-ietf-pwe3-pw-typed-wc-fec-03 Radia Perlman 2012-03-21 draft-ietf-pwe3-redundancy-06 Tim Polk 2012-03-21 draft-ietf-pwe3-redundancy-bit-06 Eric Rescorla 2012-02-08 draft-ietf-sieve-notify-sip-message-08 Vincent Roca 2012-04-03 draft-johansson-loa-registry-04 Vincent Roca 2012-02-06 draft-ietf-simple-chat-14 Joe Salowey 2012-04-18 draft-templin-aero-10 From barryleiba@gmail.com Thu Mar 8 19:02: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 F08A111E8075; Thu, 8 Mar 2012 19:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx+5hdneneH7; Thu, 8 Mar 2012 19:02:46 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C680911E8072; Thu, 8 Mar 2012 19:02:44 -0800 (PST) Received: by obbta4 with SMTP id ta4so1704137obb.31 for ; Thu, 08 Mar 2012 19:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nhlRFa/PvaH1qo23LVngIMkxcqTAesSQ0RuOtCaaAAs=; b=VqtlDlaOyCr1760CyqZfx+Dqju+uRN7CRU7UZYfkGu1KggHJA3wqwOqAIhLh1kmeBC Z3EwmGe0jxkdDD8C4epao26YQzWX+/qBOWeebqyzXdtJ0PygiHmiQ3aS/kzvZMdIDJnV DNH4R52Us+yfMUF3yLqiMI/Trz0cHMOin3Q1reCNCG8jlqHVhRHIBMSRiyXulqWBSlel bpCWKm6IMGKcsg+R1j6pS2MTrO2DopeBoNmb5A0oMrxeYItIoExyZ7brm89q4xCpXQ6Q +Xxo9yx2I5u3uI3K9dV0eVydM06Q7JrkDJv3OuXQEZrhL2Nzxu+f3eY0g5rG4ez5vuIU gFYQ== MIME-Version: 1.0 Received: by 10.182.182.101 with SMTP id ed5mr212841obc.64.1331262164455; Thu, 08 Mar 2012 19:02:44 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.60.125.37 with HTTP; Thu, 8 Mar 2012 19:02:44 -0800 (PST) In-Reply-To: <9452079D1A51524AA5749AD23E003928080B06@exch-mbx901.corp.cloudmark.com> References: <20310.13509.461991.185885@fireball.kivinen.iki.fi> <9452079D1A51524AA5749AD23E00392807D2D5@exch-mbx901.corp.cloudmark.com> <20312.47947.44384.921886@fireball.kivinen.iki.fi> <9452079D1A51524AA5749AD23E003928080B06@exch-mbx901.corp.cloudmark.com> Date: Thu, 8 Mar 2012 22:02:44 -0500 X-Google-Sender-Auth: JG4kU_idqDO4fTKiVHHlj56CBo8 Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-marf-dkim-reporting.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-marf-dkim-reporting-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, 09 Mar 2012 03:02:47 -0000 > =A0 The presence of the DNS record that indicates willingness to accept > =A0 reports opens the recipient to abuse. =A0In particular, it is possibl= e > =A0 for an attacker to attempt to cause a flood of reports toward the > =A0 domain identified in a signature's "d=3D" tag in one of these ways: > > =A0 1. =A0Alter existing signatures by adding an "r=3Dy" tag (and possibl= y > =A0 =A0 =A0 altering the "d=3D" tag to point at the target domain); > > =A0 2. =A0Add a new but invalid signature bearing an "r=3Dy" tag and a "d= =3D" > =A0 =A0 =A0 tag pointing at the target domain; > > =A0 3. =A0Generate a completely new message bearing an "r=3Dy" tag and a = "d=3D" > =A0 =A0 =A0 tag pointing at the target domain. > > =A0 Implementers are therefore strongly advised not to advertise that DNS > =A0 record except when reports desired, including the risk of receiving > =A0 this kind of attack. > > =A0 Positive caching of this DNS reply also means turning off the flow of > =A0 reports by removing the record is not likely to have immediate > =A0 effect. =A0A low time-to-live on the record needs to be considered. > > How does that look? And I've now seen it in context, in the -12 version. Some typos in there, but we'll let the RFC Editor sort it out. But... You're going to hate this, but I think the copious new text in section 8.2 really wants another paragraph. In between the three numbered items and this: Implementers are therefore strongly advised not to advertise that DN= S record except when reports desired, including the risk of receiving this kind of attack. ...I'd like to see an extreme-case (but a very-possible-case) example, thus= : Consider, for example, the situation if someone should send out a multi-million-message spam run, and include in the messages a fake DKIM signature containing "d=3Dexample.com; r=3Dy". It won't matter= that those signatures couldn't possibly be real: each will fail verificat= ion, and any implementations that support this specification will report those failures, in the millions and in short order, to example.com. I don't think the text that's there lays out the scary possibilities clearly enough. I think something like this does. Barry From msk@cloudmark.com Thu Mar 8 20:49:51 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 EE89921E8063; Thu, 8 Mar 2012 20:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWqYtqQuZL3H; Thu, 8 Mar 2012 20:49:51 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 824BA21E804B; Thu, 8 Mar 2012 20:49:51 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 20:49:51 -0800 From: "Murray S. Kucherawy" To: Barry Leiba Thread-Topic: Review of draft-ietf-marf-dkim-reporting-11 Thread-Index: AQHM+7Jn5hDXdigsDk2cMOfl5q2RKJZd1I8ggAMhkID//73RAIABHPkA//+XlfA= Date: Fri, 9 Mar 2012 04:49:50 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392808166E@exch-mbx901.corp.cloudmark.com> References: <20310.13509.461991.185885@fireball.kivinen.iki.fi> <9452079D1A51524AA5749AD23E00392807D2D5@exch-mbx901.corp.cloudmark.com> <20312.47947.44384.921886@fireball.kivinen.iki.fi> <9452079D1A51524AA5749AD23E003928080B06@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-marf-dkim-reporting.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-marf-dkim-reporting-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, 09 Mar 2012 04:49:52 -0000 > -----Original Message----- > From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Bar= ry Leiba > Sent: Thursday, March 08, 2012 7:03 PM > To: Murray S. Kucherawy > Cc: Tero Kivinen; draft-ietf-marf-dkim-reporting.all@tools.ietf.org; > iesg@ietf.org; secdir@ietf.org > Subject: Re: Review of draft-ietf-marf-dkim-reporting-11 >=20 > ...I'd like to see an extreme-case (but a very-possible-case) example, > thus: >=20 > Consider, for example, the situation if someone should send out a > multi-million-message spam run, and include in the messages a fake > DKIM signature containing "d=3Dexample.com; r=3Dy". It won't matt= er that > those signatures couldn't possibly be real: each will fail verific= ation, > and any implementations that support this specification will repor= t > those failures, in the millions and in short order, to example.com= . >=20 > I don't think the text that's there lays out the scary possibilities > clearly enough. I think something like this does. Fair enough. Added almost verbatim for -13. -MSK From kivinen@iki.fi Fri Mar 9 03:52: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 07D6021F8624; Fri, 9 Mar 2012 03:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPHfvw1rHR7H; Fri, 9 Mar 2012 03:52:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA6921F85F1; Fri, 9 Mar 2012 03:52:42 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q29BqYTC026457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2012 13:52:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q29BqWlw002441; Fri, 9 Mar 2012 13:52:32 +0200 (EET) 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: <20313.61184.568181.566675@fireball.kivinen.iki.fi> Date: Fri, 9 Mar 2012 13:52:32 +0200 From: Tero Kivinen To: "Murray S. Kucherawy" In-Reply-To: <9452079D1A51524AA5749AD23E003928080B06@exch-mbx901.corp.cloudmark.com> References: <20310.13509.461991.185885@fireball.kivinen.iki.fi> <9452079D1A51524AA5749AD23E00392807D2D5@exch-mbx901.corp.cloudmark.com> <20312.47947.44384.921886@fireball.kivinen.iki.fi> <9452079D1A51524AA5749AD23E003928080B06@exch-mbx901.corp.cloudmark.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 13 min Cc: "draft-ietf-marf-dkim-reporting.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-marf-dkim-reporting-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, 09 Mar 2012 11:52:50 -0000 Murray S. Kucherawy writes: > > -----Original Message----- > > From: Tero Kivinen [mailto:kivinen@iki.fi] > > Sent: Thursday, March 08, 2012 6:00 AM > > To: Murray S. Kucherawy > > Cc: iesg@ietf.org; secdir@ietf.org; draft-ietf-marf-dkim-reporting.all@tools.ietf.org > > Subject: RE: Review of draft-ietf-marf-dkim-reporting-11 > > > > Murray S. Kucherawy writes: > > > I've added this paragraph to the end of the current Security > > > Considerations "Deliberate Misuse" section (pardon the XML): > > > > > > The presence of the DNS record that indicates > > > willingness to accept reports opens the > > > recipient to abuse by any attacker that generates > > > or alters signatures bearing the victim's > > > domain in a DKIM "d=" tag by adding an "r=y" tag. > > > Positive caching of this DNS reply also means > > > turning off the flow of reports > > > by removing the record is not likely to have > > > immediate effect. A low time-to-live on the > > > record needs to be considered. > > > > > > Is that sufficient? > > > > It is actually inaccurate, as the "d=" tag is not needed, as attacker > > can add (or modify the existing d= tag) it as needed. The attacker can > > even add DKIM-Signature headers to completely unrelated emails with > > "d=" matching the intended victim. > > The proposed text above says "generates", which covers the case of > deliberately adding bad signatures to messages. The "alters" case > would be someone taking a valid signature and adding "r=y" to it, > optionally changing the "d=", to cause the attack. Actually yes. I missed the word "generates" first. It is always hard when the difference needs to be derived from a single word, meaning other readers might miss the same word too, especially as the rest of the sentence ("by adding an "r=y" tag") could be more readily interpreted only in the "alter" case... I think we both have seme understanding what the attack is, so the problem is just how to express it so it is clear for normal reader of this text... > "d=" is always needed in a DKIM signature, or it's syntactically > invalid to begin with. > > I.e spambot system could add DKIM signature header to all spams it is > > sending out and put d=victim.example.com and r=y to the headers and > > cause all spam recipient seeing this kind of email to attack the > > victim. > > Doesn't the "generates" case in the above text already cover that > instance? Partially, but when I read the rest of it saying 'by adding an "r=y" tag', that gave me feeling that DKIM-signature needs to be there, and thats why I missed the word generates before. If those two cases (alters vs generates) are separated in separate senteces I think that might be more clear for everybidy. > Let's try this instead, which I hope is more clear and explicit > about the problem and the solution: > > The presence of the DNS record that indicates willingness to accept > reports opens the recipient to abuse. In particular, it is possible > for an attacker to attempt to cause a flood of reports toward the > domain identified in a signature's "d=" tag in one of these ways: > > 1. Alter existing signatures by adding an "r=y" tag (and possibly > altering the "d=" tag to point at the target domain); > > 2. Add a new but invalid signature bearing an "r=y" tag and a "d=" > tag pointing at the target domain; > > 3. Generate a completely new message bearing an "r=y" tag and a "d=" > tag pointing at the target domain. > > Implementers are therefore strongly advised not to advertise that DNS > record except when reports desired, including the risk of receiving > this kind of attack. > > Positive caching of this DNS reply also means turning off the flow of > reports by removing the record is not likely to have immediate > effect. A low time-to-live on the record needs to be considered. > > How does that look? That looks very clear and good... > > > > On the other hand, even when signer requests reports to verify > > > > nobody is messing up its DKIM-Signatures the attacker can remove the "r=y" > > > > tag from the email (or the whole DKIM-Signature) and in that case > > > > the verifier do not send report to the signer (unless the Author > > > > Domain Signing Practices (ADSP) is in use, but I didn't really check > > > > whether those records are checked if no DKIM fields are found in the email). > > > > > > > > Attacker who wants to modify the emails do not want to advertise > > > > this, thus it will of course remove the "r=y", so it can fly under > > > > the radar... > > > > > > We cover that already in the "DKIM Reporting Algorithm", final > > > paragraph. > > > > Partially yes, but I think it should also be mentioned in the Security > > Considerations section from the attackers point of view. The text in > > the DKIM Reporting Algorithm section is mostly from the Signers and > > Verifiers point of view. > > I think to address this I'll move the text at the end of 3.3 into > Security Considerations, where I will describe the problem from both > sides. Here's the new subsection: > > 8.3. Unreported Fraud > > An attacker can craft fraudulent DKIM-Signature fields on messages, > without using "r=" tags, and avoid having these reported. The > procedure described in Section 3.3 does not permit the detection and > reporting of such cases. I think it might be useful to point out here that this whole mechanism does not really work agains attack, but is more useful detecting misconfigurations or errors in setup, because of attacker can do what is desribed above... > It might be useful to some Signers to receive such reports, but the > mechanism does not support it. To offer such support, a Verifier > would have to violate the first step in the algorithm and continue ^^^ Add reference to section 3.3 (i.e. ... in the algorithm described in section 3.3 and continue ...). Or use single term (either procedure or algorithm) describing it. Now you have first paragraph talking about the procedure described in section 3.3, and then the next paragraph talks about the algorithm with out specifying which algorithm... > even in the absence of an "r=" tag. Although that would enable the > desired report, it would also create a possible denial-of-service > attack: such Verifiers would always look for the reporting TXT > record, so a generator of fraudulent messages could simply send a > large volume of messages without an "r=" tag to a number of > destinations. To avoid that outcome, reports of fraudulent DKIM- > Signature header fields are not possible using the published mechanism. > > > > Actually it's correct to strike "one taken from the", so I've done > > > that. The RFC5322.From notation is introduced by one of the normative > > > references, namely RFC5598, so I believe it's correct. > > > > It would be useful to put some kind of quotes around it, i.e. either > > or "RFC5322.From" or similar so reader will understand > > it is one token, not just mistake. Also I searched that form from > > RFC5322, as that was where I expected to find it, so adding reference > > to [RFC5598] at this point would help a lot too. > > Fair enough, but I prefer to have references like that, which > introduce notational conventions, up in the "Definitions" section. > I'll take care of that now too. Ok. -- kivinen@iki.fi From scott@hyperthought.com Fri Mar 9 04:42:41 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 F0E6A21F8655 for ; Fri, 9 Mar 2012 04:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbbQ9gsaSjqI for ; Fri, 9 Mar 2012 04:42:41 -0800 (PST) Received: from smtp112.iad.emailsrvr.com (smtp112.iad.emailsrvr.com [207.97.245.112]) by ietfa.amsl.com (Postfix) with ESMTP id 49B9A21F864B for ; Fri, 9 Mar 2012 04:42:41 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp51.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 8FC6E2043D; Fri, 9 Mar 2012 07:42:40 -0500 (EST) X-Virus-Scanned: OK Received: from dynamic9.wm-web.iad.mlsrvr.com (legacy7.wa-web.iad1a.rsapps.net [192.168.2.216]) by smtp51.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 6A51A20437; Fri, 9 Mar 2012 07:42:40 -0500 (EST) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic9.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 3AE263200AF; Fri, 9 Mar 2012 07:42:40 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 9 Mar 2012 04:42:40 -0800 (PST) Date: Fri, 9 Mar 2012 04:42:40 -0800 (PST) From: "Scott G. Kelly" To: draft-ietf-appsawg-xdash.all@tools.ietf.org, "secdir@ietf.org" , "iesg@ietf.org" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1331296960.23996089@apps.rackspace.com> X-Mailer: webmail7.0 Subject: [secdir] secdir review of draft-ietf-appsawg-xdash-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: Fri, 09 Mar 2012 12:42:42 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A=0AThis document deprecates the use of the "X= -" prefix in application protocols (e.g. HTTP). The security considerations= section says that issues with security-critical parameters can result in u= nnecessary vulnerabilities, and points the reader to an appendix for furthe= r discussion. The appendix says =0A=0A "Furthermore, often standardization= of a non-standard parameter or=0A protocol element leads to subtly diffe= rent behavior (e.g., the=0A standard version might have different securit= y properties as a result=0A of security review provided during the standa= rdization process). If=0A implementers treat the old, non-standard param= eter and the new,=0A standard parameter as equivalent, interoperability a= nd security=0A problems can ensue."=0A=0AI agree with the part about inte= roperability issues, but I think the security discussion is a bit more nuan= ced. In general, unauthenticated header fields are not reliable, and for th= is reason, it should not matter whether there is an X- prefix or not: you s= hould not be basing security decisions on this.=0A=0AI can see where some p= arameters might *relate* to security somehow, but it seems that the associa= ted data would be self-contained in terms of its security properties, in th= e same way that, e.g., an encapsulated CMS payload is self-contained.=0A=0A= In such cases, it is true that there would be interop issues if the receive= r mis-interpreted the payload, but in no event should the receiver be trust= ing something just because it has (or does not have) the X- prefix.=0A=0AI = think this is very subtle, and after trying to compose a simple email I can= see that it gets complex very quickly, so I don't want to rush into a rath= ole here. Still, I wonder if the security considerations should make the po= int that presence or lack of an X- prefix must not be relied upon for secur= ity decisions.=0A=0A--Scott=0A From msk@cloudmark.com Fri Mar 9 09:22:12 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 26BC421F8682; Fri, 9 Mar 2012 09:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay6ruUFc7NWH; Fri, 9 Mar 2012 09:22:11 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9F57C21F867E; Fri, 9 Mar 2012 09:22:11 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 9 Mar 2012 09:22:11 -0800 From: "Murray S. Kucherawy" To: Tero Kivinen Thread-Topic: Review of draft-ietf-marf-dkim-reporting-11 Thread-Index: AQHM+7Jn5hDXdigsDk2cMOfl5q2RKJZd1I8ggAMhkID//73RAIABsP8A///U9FA= Date: Fri, 9 Mar 2012 17:22:10 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280822FA@exch-mbx901.corp.cloudmark.com> References: <20310.13509.461991.185885@fireball.kivinen.iki.fi> <9452079D1A51524AA5749AD23E00392807D2D5@exch-mbx901.corp.cloudmark.com> <20312.47947.44384.921886@fireball.kivinen.iki.fi> <9452079D1A51524AA5749AD23E003928080B06@exch-mbx901.corp.cloudmark.com> <20313.61184.568181.566675@fireball.kivinen.iki.fi> In-Reply-To: <20313.61184.568181.566675@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-marf-dkim-reporting.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-marf-dkim-reporting-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, 09 Mar 2012 17:22:12 -0000 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Friday, March 09, 2012 3:53 AM > To: Murray S. Kucherawy > Cc: iesg@ietf.org; secdir@ietf.org; draft-ietf-marf-dkim-reporting.all@to= ols.ietf.org > Subject: RE: Review of draft-ietf-marf-dkim-reporting-11 >=20 > > How does that look? >=20 > That looks very clear and good... OK, it's in the version I'll post when LC closes. > > 8.3. Unreported Fraud > > > > An attacker can craft fraudulent DKIM-Signature fields on messages, > > without using "r=3D" tags, and avoid having these reported. The > > procedure described in Section 3.3 does not permit the detection and > > reporting of such cases. >=20 > I think it might be useful to point out here that this whole mechanism > does not really work agains attack, but is more useful detecting > misconfigurations or errors in setup, because of attacker can do what > is desribed above... It does work where there's an attack in progress, with the caveat that aski= ng for reports about the attack could produce a huge amount of feedback. B= ut I think the text we've landed on spells that out. > > It might be useful to some Signers to receive such reports, but the > > mechanism does not support it. To offer such support, a Verifier > > would have to violate the first step in the algorithm and continue > ^^^ >=20 > Add reference to section 3.3 (i.e. ... in the algorithm described in > section 3.3 and continue ...). Or use single term (either procedure or > algorithm) describing it. Now you have first paragraph talking about > the procedure described in section 3.3, and then the next paragraph > talks about the algorithm with out specifying which algorithm... Right; changed the first one to "procedure". Thanks, -MSK From mlepinski@bbn.com Fri Mar 9 14:17: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 9376921F848B; Fri, 9 Mar 2012 14:17:23 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbwYIRiMoqau; Fri, 9 Mar 2012 14:17:23 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id EE75621F847D; Fri, 9 Mar 2012 14:17:22 -0800 (PST) Received: from mail.bbn.com ([128.33.0.48]:57628) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S687b-0009B0-2Q; Fri, 09 Mar 2012 17:17:11 -0500 Received: from [128.89.253.89] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1S687i-0003s8-Lk; Fri, 09 Mar 2012 17:17:18 -0500 Message-ID: <4F5A8186.7030002@bbn.com> Date: Fri, 09 Mar 2012 17:17:42 -0500 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-pwe3-packet-pw.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [secdir] SECDIR review of draft-ietf-pwe3-packet-pw-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: Fri, 09 Mar 2012 22:17:23 -0000 I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. Thes= e comments were written primarily for the benefit of the security area di= rectors. Document editors and WG chairs should treat these comments just= like any other last call comments. This document considers the case of two MPLS Label Switching Routers (LSR= s) that are connected over an arbitrary packet-switched network (i.e., an= IP or MPLS network). This document provides a mechanism (i.e., a pseudow= ire) to simulate a direct data-link (in particular, an Ethernet link, as = Ethernet is the encapsulation mechanism specified) between the two MPLS L= SRs. This pseudowire provides an interface to exchange IP packets (and in= deed, multiplex IP packets associated with a variety of protocols) betwee= n the two MPLS LSRs in a manner that is completely isolated from the MPLS= traffic that they exchange. For example, the document claims that the ps= eudowire could be used to exchange packets for adjacency formation, contr= ol, routing, label exchange, management and monitoring purposes. The security considerations section of the document claims that this use = of pseudowires creates no new security considerations that are not covere= d in the pseudowire architecture (RFC 3985) or the specification for crea= ting/maintaining pseudowires using LDP (RFC 4447). I would generally agre= e with the authors, that this use of pseudowires introduces no fundamenta= lly new security considerations. However, I think it would be valuable fo= r the authors add a small amount of additional cautionary text to the sec= urity considerations section (and I think it would be perfectly reasonabl= e to copy text from, for example, the beginning of the RFC 3985 security = considerations). The key issue is that Pseudowires do not provide any integrity or authent= icity guarantees and in particular security assumptions that are reasonab= le when using physical Ethernet links are no longer reasonable when you a= re using a virtual pseudowire traversing an arbitrary packet-switched net= work. The motivating examples in this document discuss routing protocol c= ontrol traffic and network management traffic as things you might send ov= er a packet pseudowire. When you send this type of control or management = traffic over a physical Ethernet link one might reasonably choose not to = invoke all integrity and authenticity mechanisms available in these proto= cols, but when using a pseudowire the use of such intregrity and authenti= city mechanisms is much more important to the correct operation of one's = network. All of this is said quite nicely in RFC 3985, but I believe addi= ng a bit of cautionary text to the security considerations section of thi= s document (in addition to the reference to RFC 3985) could be quite help= ful to the reader of this document. From charliek@microsoft.com Sat Mar 10 18:49: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 0834821F858D; Sat, 10 Mar 2012 18:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6JHydE3jbz8; Sat, 10 Mar 2012 18:49:44 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 67DFD21F8487; Sat, 10 Mar 2012 18:49:44 -0800 (PST) Received: from mail15-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Sun, 11 Mar 2012 02:49:44 +0000 Received: from mail15-tx2 (localhost [127.0.0.1]) by mail15-tx2-R.bigfish.com (Postfix) with ESMTP id DC1EF201F8; Sun, 11 Mar 2012 02:49:43 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail15-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=charliek@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail15-tx2 (localhost.localdomain [127.0.0.1]) by mail15-tx2 (MessageSwitch) id 1331434182278156_19843; Sun, 11 Mar 2012 02:49:42 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.235]) by mail15-tx2.bigfish.com (Postfix) with ESMTP id 3F63BA0066; Sun, 11 Mar 2012 02:49:42 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 11 Mar 2012 02:49:42 +0000 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.156]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0283.004; Sun, 11 Mar 2012 02:49:40 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-hokey-rfc5296bis.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-hokey-rfc5296bis-06 Thread-Index: Acz/ML12mHkKpkpRQg6yyBgJwngbOg== Date: Sun, 11 Mar 2012 02:49:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B091247A9A480TK5EX14MBXC115r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [secdir] secdir review of draft-ietf-hokey-rfc5296bis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 02:49:45 -0000 --_000_D80EDFF2AD83E648BD1164257B9B091247A9A480TK5EX14MBXC115r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document incorporates the errata from rfc5296, but (as far as I could = tell) contained no technical changes. Advancing it should be non-controvers= ial. I found no typos. My only quibble is that it would have been helpful i= f there had been an appendix (perhaps to be deleted when advanced) enumerat= ing the changes since rfc5296. --Charlie --_000_D80EDFF2AD83E648BD1164257B9B091247A9A480TK5EX14MBXC115r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

This document incorporates the errata from rfc5296, = but (as far as I could tell) contained no technical changes. Advancing it s= hould be non-controversial. I found no typos. My only quibble is that it wo= uld have been helpful if there had been an appendix (perhaps to be deleted when advanced) enumerating the cha= nges since rfc5296.

 

        &nbs= p;       --Charlie

--_000_D80EDFF2AD83E648BD1164257B9B091247A9A480TK5EX14MBXC115r_-- From leifj@sunet.se Sun Mar 11 13:39: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 94D2A21F85A3; Sun, 11 Mar 2012 13:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ0gN5KzgVVV; Sun, 11 Mar 2012 13:39:23 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 30BE521F85A5; Sun, 11 Mar 2012 13:39:23 -0700 (PDT) Received: from [10.0.1.91] (70-91-87-57-BusName-metrodr.md.hfc.comcastbusiness.net [70.91.87.57]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2BKdGkc001958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2012 21:39:20 +0100 (CET) Message-ID: <4F5D0D74.5030209@sunet.se> Date: Sun, 11 Mar 2012 21:39:16 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: draft-ietf-decade-problem-statement.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-decade-problem-statement-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 20:39:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. My main problem with the draft is that the Security Considerations Section is weak. I would have liked a more in-depth analysis of the enumerated threats in the context of decade. For instance the privacy aspects of using in-network storage for P2P networks is only covered briefly as part of a discussion on traffic analysis. Also in section 3.2 it is noted that E2E encryption may render P2P caches ineffective. This speaks to a fundamental flaw (imo) in the architecture: the standard way to protect against many of the stated attacks also leads to inefficiency of decade. At the very least the document needs to call this issue out clearly. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9dDXQACgkQ8Jx8FtbMZndzfQCdGlV5Vun5Khv9doeYdcjebALX ++EAn0VVTjtEMsDlFFM86NlWC+pRlr7X =Ob4+ -----END PGP SIGNATURE----- From clonvick@cisco.com Sun Mar 11 18:05:26 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 3592C21F8547; Sun, 11 Mar 2012 18:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQLkajpJ4-SP; Sun, 11 Mar 2012 18:05:25 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0E51821F852A; Sun, 11 Mar 2012 18:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=751; q=dns/txt; s=iport; t=1331514321; x=1332723921; h=date:from:to:subject:message-id:mime-version; bh=XhWCgEjfYqt5Xb4t7Gm0dc7Ccz1Ms2n0XraV9VLDBRo=; b=POVDj45TyFYSoJym8yA/nefb9+Ub+yQF3kuoXowglb0xpIspNhUwd+nj gtTU7mXZ8VqTmhhhXHYBsi8ZOuyyUscivp+DUOvjmwYi0QTYCF4P90LNs Xo2IJkGuIFAheRAH9IjuA5DhtbFy/yPayyUqjUDldZ5r9apAPdxR28dGK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgIANFKXU+rRDoG/2dsb2JhbABCpDIBkROBB4IiASUCgX40h2ebXgGdbZEBBIhUnRuDAw X-IronPort-AV: E=Sophos;i="4.73,568,1325462400"; d="scan'208";a="33067245" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 12 Mar 2012 01:05:21 +0000 Received: from sjc-cde-021.cisco.com (sjc-cde-021.cisco.com [171.69.20.56]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2C15KS6031045; Mon, 12 Mar 2012 01:05:20 GMT Date: Sun, 11 Mar 2012 18:05:20 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-melnikov-smtp-priority.all@tools.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] SECDIR review of draft-melnikov-smtp-priority-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 01:05:26 -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. Overall, the proposal to insert a MT-PRIORITY header appears reasonable. I don't think that it opens any security threats that are not noted in the document. I am concerned that this feature can disrupt the DKIM protection as noted in section 11.1. I see the problem here and I can't offer any suggestions to fix that. I think that the authors have done well to document this. Thanks, Chris From new-work-bounces@ietf.org Mon Mar 12 08:43:42 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 83A6621F86A4; Mon, 12 Mar 2012 08:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331567022; bh=Hx0j18uu7mB0uLlhnb2PckeZE0Rj8eYHyjOATOC0ouM=; h=From:To:Date:Message-ID:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=FE1/9HID2qmIgWM522ngEXtPNajtJXmmo6DhVRirTmzaExtV6+Wk1R0x6/R3k3Mcw Ou3AicMe07mNwqE4IbyN0sY+CckRaL+X4DwFjtqswTV/k542DkUskBjmXwrhNcheUy 7CVZb+qhPYCAQ4dkUk20ovQSV/N2VVU9oU0XTv3A= 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 8149021E8062 for ; Fri, 9 Mar 2012 11:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p1n8m75yPdc for ; Fri, 9 Mar 2012 11:39:37 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id DD36F21E8025 for ; Fri, 9 Mar 2012 11:39:36 -0800 (PST) Received: from 30-7-72.wireless.csail.mit.edu ([128.30.7.72]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1S65f5-0008Ka-Rt for new-work@ietf.org; Fri, 09 Mar 2012 14:39:35 -0500 From: Philippe Le Hegaret To: new-work Organization: World Wide Web Consortium Date: Fri, 09 Mar 2012 14:39:30 -0500 Message-ID: <1331321970.14953.18.camel@chacal> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 X-Mailman-Approved-At: Mon, 12 Mar 2012 08:43:40 -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: Mon, 12 Mar 2012 08:51:13 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web Applications Working Group (until 2012-04-09) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:43:42 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Web Applications Working Group charter [0] (see the W3C Process Document description of Working Groups [1]): http://www.w3.org/2012/03/webapps-proposed-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2012-04-09 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 , Team Contact. Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2010/webapps/charter/ [1] http://www.w3.org/2005/10/Process-20051014/groups.html#GroupsWG [2] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From stpeter@stpeter.im Mon Mar 12 09:38:27 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 2FE0921E8012; Mon, 12 Mar 2012 09:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.723 X-Spam-Level: X-Spam-Status: No, score=-102.723 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJPSEulit6Md; Mon, 12 Mar 2012 09:38:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E6DA421E800E; Mon, 12 Mar 2012 09:38:25 -0700 (PDT) Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 405ED40058; Mon, 12 Mar 2012 10:50:41 -0600 (MDT) Message-ID: <4F5E267F.8070602@stpeter.im> Date: Mon, 12 Mar 2012 10:38:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Scott G. Kelly" References: <1331296960.23996089@apps.rackspace.com> In-Reply-To: <1331296960.23996089@apps.rackspace.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-appsawg-xdash-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: Mon, 12 Mar 2012 16:38:27 -0000 On 3/9/12 5:42 AM, Scott G. Kelly 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 deprecates the use of the "X-" prefix in application > protocols (e.g. HTTP). The security considerations section says that > issues with security-critical parameters can result in unnecessary > vulnerabilities, and points the reader to an appendix for further > discussion. The appendix says > > "Furthermore, often standardization of a non-standard parameter or > protocol element leads to subtly different behavior (e.g., the > standard version might have different security properties as a > result of security review provided during the standardization > process). If implementers treat the old, non-standard parameter and > the new, standard parameter as equivalent, interoperability and > security problems can ensue." > > I agree with the part about interoperability issues, but I think the > security discussion is a bit more nuanced. In general, > unauthenticated header fields are not reliable, and for this reason, > it should not matter whether there is an X- prefix or not: you should > not be basing security decisions on this. > > I can see where some parameters might *relate* to security somehow, > but it seems that the associated data would be self-contained in > terms of its security properties, in the same way that, e.g., an > encapsulated CMS payload is self-contained. > > In such cases, it is true that there would be interop issues if the > receiver mis-interpreted the payload, but in no event should the > receiver be trusting something just because it has (or does not have) > the X- prefix. > > I think this is very subtle, and after trying to compose a simple > email I can see that it gets complex very quickly, so I don't want to > rush into a rathole here. Still, I wonder if the security > considerations should make the point that presence or lack of an X- > prefix must not be relied upon for security decisions. Hi Scott, I see your point, but it's not clear to me that this document is the place to make a general statement about secure handling of application parameters. Further, not all parameters are header fields, so this is not a matter of headers vs. payloads. However, I do think there's an issue here, so I will think about it more today and perhaps reply again. Peter -- Peter Saint-Andre https://stpeter.im/ From dcrocker@bbiw.net Mon Mar 12 09:45: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 8721C21F87C3; Mon, 12 Mar 2012 09:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppTTP4y0+jS1; Mon, 12 Mar 2012 09:45:22 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C442921F87BF; Mon, 12 Mar 2012 09:45:22 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2CGjEcW021774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2012 09:45:20 -0700 Message-ID: <4F5E2806.7070808@bbiw.net> Date: Mon, 12 Mar 2012 09:44:54 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Chris Lonvick References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 12 Mar 2012 09:45:20 -0700 (PDT) Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, Murray Kucherawy , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-melnikov-smtp-priority-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:45:23 -0000 (copying Murray, in case he has further thoughts...) On 3/11/2012 6:05 PM, Chris Lonvick wrote: > I am concerned that this feature can disrupt the DKIM protection as noted in > section 11.1. I see the problem here and I can't offer any suggestions to fix > that. I think that the authors have done well to document this. Predictably, the DKIM reference caught my attention. I think the existing draft text in 11.1 is good. I think it entirely reasonable to leave it alone. That said, since the concern about broken DKIM signatures is raised it's worth at least considering adding more text. However I think there's a challenge in what that 'more' should be. In general, the world is moving in a direction that is likely to impose penalties when an origination DKIM signature is broken. (I'm not happy about that; I think it represents some problematic thinking about DKIM, but it is nonetheless the direction things are going.) The draft might suggest /not/ covering the MT-Priority: field with a signature. There is a common view that DKIM "protects" and or "validates" the fields it covers. Although DKIM obviously provides data integrity between the time of signing and validating, DKIM semantics do not offer anything like authentication of validation of the data that are signed. It only validates the authorization of the associated identifier (sdid, d=), with the message it is attached to. As such, having MT-Priority: be outside a signature probably isn't that onerous, unless there is a serious threat of in-transit header field modification attacks. Arguably, it's better to have the agent assigning priority be the one to sign. In the case of revising the priority, that's not the originator. This is only problematic for cases that demand origination signatures (usually translating into requiring the DKIM sdid (d=) value be the same as, for example, the rfc5322.From domain. There is private pursuit of a specification that allows intermediaries that break DKIM signatures to report that they were valid before being broken. For this mechanism to be useful, there needs to be transitive trust between the intermediary and the validating receiver. But, as I say, that's work in progress. Although it sounds appealing, I've no idea how useful it will actually prove to be. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Mon Mar 12 09:46:26 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 0BC4221F880E; Mon, 12 Mar 2012 09:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.722 X-Spam-Level: X-Spam-Status: No, score=-102.722 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6p41HSuuL6X; Mon, 12 Mar 2012 09:46:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D811A21F87EE; Mon, 12 Mar 2012 09:46:24 -0700 (PDT) Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2A1C240058; Mon, 12 Mar 2012 10:58:40 -0600 (MDT) Message-ID: <4F5E285E.9040908@stpeter.im> Date: Mon, 12 Mar 2012 10:46:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Scott G. Kelly" References: <1331296960.23996089@apps.rackspace.com> <4F5E267F.8070602@stpeter.im> In-Reply-To: <4F5E267F.8070602@stpeter.im> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-appsawg-xdash-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: Mon, 12 Mar 2012 16:46:26 -0000 On 3/12/12 10:38 AM, Peter Saint-Andre wrote: > On 3/9/12 5:42 AM, Scott G. Kelly 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 deprecates the use of the "X-" prefix in application >> protocols (e.g. HTTP). The security considerations section says that >> issues with security-critical parameters can result in unnecessary >> vulnerabilities, and points the reader to an appendix for further >> discussion. The appendix says >> >> "Furthermore, often standardization of a non-standard parameter or >> protocol element leads to subtly different behavior (e.g., the >> standard version might have different security properties as a >> result of security review provided during the standardization >> process). If implementers treat the old, non-standard parameter and >> the new, standard parameter as equivalent, interoperability and >> security problems can ensue." >> >> I agree with the part about interoperability issues, but I think the >> security discussion is a bit more nuanced. In general, >> unauthenticated header fields are not reliable, and for this reason, >> it should not matter whether there is an X- prefix or not: you should >> not be basing security decisions on this. >> >> I can see where some parameters might *relate* to security somehow, >> but it seems that the associated data would be self-contained in >> terms of its security properties, in the same way that, e.g., an >> encapsulated CMS payload is self-contained. >> >> In such cases, it is true that there would be interop issues if the >> receiver mis-interpreted the payload, but in no event should the >> receiver be trusting something just because it has (or does not have) >> the X- prefix. >> >> I think this is very subtle, and after trying to compose a simple >> email I can see that it gets complex very quickly, so I don't want to >> rush into a rathole here. Still, I wonder if the security >> considerations should make the point that presence or lack of an X- >> prefix must not be relied upon for security decisions. > > Hi Scott, > > I see your point, but it's not clear to me that this document is the > place to make a general statement about secure handling of application > parameters. Further, not all parameters are header fields, so this is > not a matter of headers vs. payloads. However, I do think there's an > issue here, so I will think about it more today and perhaps reply again. OK, I thought about it quickly. :) I think your point relates to our recommendation against making programmatic distinctions between "standard" and "non-standard" (and therefore perhaps "secure" and "insecure") parameters based solely on the names. In version -04 (to be posted before the deadline tonight, I hope), the content of Section 2 ("Recommendations for Implementers of Application Protocols") will read as follows: Implementations of application protocols MUST NOT programatically discriminate between "standard" and "non-standard" parameters based solely on the names of such parameters (i.e., based solely on whether the name begins with 'x-' or a similar string of characters). Now, the leap from "standard" to "secure" and "non-standard" to "insecure" is unwarranted, I think -- sometimes it might be true, but not in the general case -- so we might want to recommend against making such an assumption based solely on the names of parameters. But that is a slightly different point than the one you're making, it seems. Peter -- Peter Saint-Andre https://stpeter.im/ From msk@cloudmark.com Mon Mar 12 09:52:44 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 56F0A21E8068; Mon, 12 Mar 2012 09:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1GZ5TzPWzbs; Mon, 12 Mar 2012 09:52:43 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id E5DAC21E8048; Mon, 12 Mar 2012 09:52:43 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 09:52:43 -0700 From: "Murray S. Kucherawy" To: Dave Crocker , Chris Lonvick Thread-Topic: SECDIR review of draft-melnikov-smtp-priority-09 Thread-Index: AQHM/+yUuS4x68FErE2AlyFJQDNkCpZnVGYA//+MWmA= Date: Mon, 12 Mar 2012 16:52:43 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392808623C@exch-mbx901.corp.cloudmark.com> References: <4F5E2806.7070808@bbiw.net> In-Reply-To: <4F5E2806.7070808@bbiw.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-melnikov-smtp-priority.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-melnikov-smtp-priority-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:52:44 -0000 > -----Original Message----- > From: Dave Crocker [mailto:dcrocker@bbiw.net] > Sent: Monday, March 12, 2012 9:45 AM > To: Chris Lonvick > Cc: iesg@ietf.org; secdir@ietf.org; draft-melnikov-smtp-priority.all@tool= s.ietf.org; Murray S. Kucherawy > Subject: Re: SECDIR review of draft-melnikov-smtp-priority-09 >=20 > (copying Murray, in case he has further thoughts...) I agree with Dave's points, and would also add that this draft doesn't need= to call out a "right" solution. It would probably be just fine calling ou= t the pros and cons regarding choosing whether to cover the MT-Priority hea= der field with a DKIM signature, and leaving it to the implementation to de= cide. -MSK From stpeter@stpeter.im Mon Mar 12 09:58:00 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 5527E21F8738; Mon, 12 Mar 2012 09:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.721 X-Spam-Level: X-Spam-Status: No, score=-102.721 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6p7bAaA2LQiW; Mon, 12 Mar 2012 09:57:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1C021F8618; Mon, 12 Mar 2012 09:57:59 -0700 (PDT) Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C7B7B40058; Mon, 12 Mar 2012 11:10:14 -0600 (MDT) Message-ID: <4F5E2B15.6000409@stpeter.im> Date: Mon, 12 Mar 2012 10:57:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Scott G. Kelly" References: <1331296960.23996089@apps.rackspace.com> <4F5E267F.8070602@stpeter.im> <4F5E285E.9040908@stpeter.im> In-Reply-To: <4F5E285E.9040908@stpeter.im> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-appsawg-xdash-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: Mon, 12 Mar 2012 16:58:00 -0000 On 3/12/12 10:46 AM, Peter Saint-Andre wrote: > On 3/12/12 10:38 AM, Peter Saint-Andre wrote: >> On 3/9/12 5:42 AM, Scott G. Kelly 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 deprecates the use of the "X-" prefix in application >>> protocols (e.g. HTTP). The security considerations section says that >>> issues with security-critical parameters can result in unnecessary >>> vulnerabilities, and points the reader to an appendix for further >>> discussion. The appendix says >>> >>> "Furthermore, often standardization of a non-standard parameter or >>> protocol element leads to subtly different behavior (e.g., the >>> standard version might have different security properties as a >>> result of security review provided during the standardization >>> process). If implementers treat the old, non-standard parameter and >>> the new, standard parameter as equivalent, interoperability and >>> security problems can ensue." >>> >>> I agree with the part about interoperability issues, but I think the >>> security discussion is a bit more nuanced. In general, >>> unauthenticated header fields are not reliable, and for this reason, >>> it should not matter whether there is an X- prefix or not: you should >>> not be basing security decisions on this. >>> >>> I can see where some parameters might *relate* to security somehow, >>> but it seems that the associated data would be self-contained in >>> terms of its security properties, in the same way that, e.g., an >>> encapsulated CMS payload is self-contained. >>> >>> In such cases, it is true that there would be interop issues if the >>> receiver mis-interpreted the payload, but in no event should the >>> receiver be trusting something just because it has (or does not have) >>> the X- prefix. >>> >>> I think this is very subtle, and after trying to compose a simple >>> email I can see that it gets complex very quickly, so I don't want to >>> rush into a rathole here. Still, I wonder if the security >>> considerations should make the point that presence or lack of an X- >>> prefix must not be relied upon for security decisions. >> >> Hi Scott, >> >> I see your point, but it's not clear to me that this document is the >> place to make a general statement about secure handling of application >> parameters. Further, not all parameters are header fields, so this is >> not a matter of headers vs. payloads. However, I do think there's an >> issue here, so I will think about it more today and perhaps reply again. > > OK, I thought about it quickly. :) > > I think your point relates to our recommendation against making > programmatic distinctions between "standard" and "non-standard" (and > therefore perhaps "secure" and "insecure") parameters based solely on > the names. In version -04 (to be posted before the deadline tonight, I > hope), the content of Section 2 ("Recommendations for Implementers of > Application Protocols") will read as follows: > > Implementations of application protocols MUST NOT programatically > discriminate between "standard" and "non-standard" parameters based > solely on the names of such parameters (i.e., based solely on > whether the name begins with 'x-' or a similar string of characters). > > Now, the leap from "standard" to "secure" and "non-standard" to > "insecure" is unwarranted, I think -- sometimes it might be true, but > not in the general case -- so we might want to recommend against making > such an assumption based solely on the names of parameters. But that is > a slightly different point than the one you're making, it seems. I would suggest, therefore, adding the following paragraph to the Security Considerations: As a corollary to the recommendation provided under Section 2, implementations MUST NOT assume that "standard" parameters are "secure" whereas "non-standard" parameters are "insecure", based solely on the names of such parameters. Strictly speaking that shouldn't be necessary because the security of a parameter is just one instance of the parameter's (assumed) properties, but it might be a helpful clarification. Peter -- Peter Saint-Andre https://stpeter.im/ From hilarie@purplestreak.com Mon Mar 12 13:14:00 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 2255321F8999; Mon, 12 Mar 2012 13:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL0ihzXqavxG; Mon, 12 Mar 2012 13:13: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 5B12E21F8984; Mon, 12 Mar 2012 13:13:51 -0700 (PDT) Received: from mx01.mta.xmission.com ([166.70.13.211]) by out01.mta.xmission.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1S7Bct-0001tP-1w; Mon, 12 Mar 2012 14:13:51 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1S7Bcp-0007eK-FL; Mon, 12 Mar 2012 14:13:50 -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 q2CKDOgq005119; Mon, 12 Mar 2012 14:13:24 -0600 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id q2CKDOe9005117; Mon, 12 Mar 2012 14:13:24 -0600 Date: Mon, 12 Mar 2012 14:13:24 -0600 Message-Id: <201203122013.q2CKDOe9005117@sylvester.rhmr.com> From: "Hilarie Orman" To: secdir@ietf.org, iesg@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx01.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; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;secdir@ietf.org, iesg@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 mx01.mta.xmission.com) Subject: [secdir] security review of draft-ietf-pwe3-pw-typed-wc-fec-03.txt 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: Mon, 12 Mar 2012 20:14:00 -0000 Security review of draft-ietf-pwe3-pw-typed-wc-fec-03.txt 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 abstract: The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80) and Generalized PWid (0x81) FEC element types. In doing an SR for a WC semantic one has to be mindful of the overall ops SC. The TM might be insider MW or external DDoS. In this case, the chances for semantic ambiguity and resulting misconfiguration could be significant, or not. Users should invest in an RA before accepting these types. The sec5's of all predecessor documents have sufficient handwaving to cover the basic ideas of this draft. See my earlier review of draft-ietf-pwe3-segmented-pw-13.txt. Hilarie From stephen.farrell@cs.tcd.ie Tue Mar 13 14:52: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 254ED21F8629 for ; Tue, 13 Mar 2012 14:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.841 X-Spam-Level: X-Spam-Status: No, score=-102.841 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSDVlmwVzj7e for ; Tue, 13 Mar 2012 14:52:56 -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 6D59C21F8627 for ; Tue, 13 Mar 2012 14:52:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D9722171D8D for ; Tue, 13 Mar 2012 21:52:55 +0000 (GMT) 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=1331675575; bh=WwLVbKswamJlHiz+1/+1P+Yj 2JjNr+aaQTO3UdJxdPs=; b=lKpl7UaOkuiXzjSM64DjkXo5DQXQBC92kYRz/vWe P2jK3CN2JvwCymZtsE8qPw6PqMm5wdggoG9z5WDPte+R3IX+HT7sFP2HuTsarJQ/ RngecHuJC7iZAJf5GhmlChORzMgssTjWOZEVRT9sQgfgclimuY/v1G9raElpRPN9 ATuekx3u6KBRP10t9f9OZNaTH24mqznDVatn3X2dmzDnuOkBC/KMkkErrY808r7F HuDgXTwA+mbugj8Rd4NzDwhkC6RKyYYe5D0oFM9NHjkKjx4pLIGeam2djGAXm1q3 2/3Fy9QlulJxMY/dKqZhDFmQAz+WIQl6o4Bq4byKehREmg== 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 RYy7PsNRt4Se for ; Tue, 13 Mar 2012 21:52:55 +0000 (GMT) Received: from [10.227.22.241] (unknown [194.230.159.113]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 886AB171D8C for ; Tue, 13 Mar 2012 21:52:54 +0000 (GMT) Message-ID: <4F5FC1B1.2090806@cs.tcd.ie> Date: Tue, 13 Mar 2012 21:52:49 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "secdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] secdir lunch question 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, 13 Mar 2012 21:52:57 -0000 Hi all, ISOC are organising an openid and oauth briefing session in Paris that clashes with our usual secdir lunch session. The clash is unfortunate but there's nothing to be done about it now, since slots are so scarce. So Sean and I wanted to check with you if you'd rather: a) go ahead with the secdir lunch as usual or b) skip the secdir lunch this time to allow interested folks to go to the ISOC gig. Can you let Sean and I know which you prefer say by Monday? (Off list is fine and I'll summarise or use the list if you prefer.) Thanks, S. From leifj@sunet.se Tue Mar 13 14:58:11 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 E332521E802B for ; Tue, 13 Mar 2012 14:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEBaufbkrArC for ; Tue, 13 Mar 2012 14:58:11 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id F164321E802F for ; Tue, 13 Mar 2012 14:58:10 -0700 (PDT) Received: from [10.0.1.91] (70-91-87-57-BusName-metrodr.md.hfc.comcastbusiness.net [70.91.87.57]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2DLw4Mn023478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Mar 2012 22:58:09 +0100 (CET) Message-ID: <4F5FC2EC.2070808@sunet.se> Date: Tue, 13 Mar 2012 22:58:04 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: secdir@ietf.org References: <4F5FC1B1.2090806@cs.tcd.ie> In-Reply-To: <4F5FC1B1.2090806@cs.tcd.ie> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir lunch question 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, 13 Mar 2012 21:58:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/13/2012 10:52 PM, Stephen Farrell wrote: > > Hi all, > > ISOC are organising an openid and oauth briefing session in Paris > that clashes with our usual secdir lunch session. The clash is > unfortunate but there's nothing to be done about it now, since > slots are so scarce. > > So Sean and I wanted to check with you if you'd rather: > > a) go ahead with the secdir lunch as usual or b) skip the secdir > lunch this time to allow interested folks to go to the ISOC gig. Leaning towards (b) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9fwuwACgkQ8Jx8FtbMZnfyxwCgwQ++fERojTZyp3OUjc/kNstY M7oAnRohpSm2vtNlpS9Z02FEQi2VLmKc =oJcL -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Tue Mar 13 17:02:29 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 95ACB21E807A for ; Tue, 13 Mar 2012 17:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.693 X-Spam-Level: X-Spam-Status: No, score=-102.693 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V75IAxL2J+a2 for ; Tue, 13 Mar 2012 17:02:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2477F21E8013 for ; Tue, 13 Mar 2012 17:02:29 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2E02MRp011933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2012 17:02:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F5FC1B1.2090806@cs.tcd.ie> Date: Tue, 13 Mar 2012 17:02:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2659937D-335C-4174-8A59-42256C364910@vpnc.org> References: <4F5FC1B1.2090806@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) Cc: "secdir@ietf.org" Subject: Re: [secdir] secdir lunch question 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, 14 Mar 2012 00:02:29 -0000 On Mar 13, 2012, at 2:52 PM, Stephen Farrell wrote: > a) go ahead with the secdir lunch as usual > or > b) skip the secdir lunch this time to allow interested > folks to go to the ISOC gig. (a). We can't all go to the ISOC lunch (and I doubt they would want us = to), and it is not clear that they will be covering anything new to most = of us. --Paul Hoffman From dwing@cisco.com Tue Mar 13 18:07: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 30D3821F85A1; Tue, 13 Mar 2012 18:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.208 X-Spam-Level: X-Spam-Status: No, score=-109.208 tagged_above=-999 required=5 tests=[AWL=1.391, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mjk29KZc4PQ; Tue, 13 Mar 2012 18:07:56 -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 7BFF521F85A0; Tue, 13 Mar 2012 18:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2851; q=dns/txt; s=iport; t=1331687276; x=1332896876; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=Z29SJJJTGgIFcyM2qW9wLKxwR81nKN81CgMzi31iC/c=; b=OS1m726SE5VpMNoT/YNlDqCr7hNN/X2IV58LcJPeOVpSOsMo0EZT1S0+ dRg2DNKjOFvjmJnezagGkJsQxgNvZHu7TjHEvNKyh2wYZc9HlfkctUNKH gls/55qUTsdW9j0zIW3TPWOsgnFOAy6CFPkOt7Mom6kbtcS652I2H52qL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADHuX0+rRDoH/2dsb2JhbABDpg+PZYEHggkBAQEDAQgKARcQRAcBAwIJDgECBAEBKAcZIwoJCAEBBAESCxeHYwScTQGebZB2BIhVhRKYDIMF X-IronPort-AV: E=Sophos;i="4.73,580,1325462400"; d="scan'208";a="36014009" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 14 Mar 2012 01:07:56 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2E17uUO029804; Wed, 14 Mar 2012 01:07:56 GMT From: "Dan Wing" To: "'Dan Harkins'" , , , References: In-Reply-To: Date: Tue, 13 Mar 2012 18:07:56 -0700 Message-ID: <0a8301cd017e$e4091540$ac1b3fc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz3GtTmpExhpeVqSVyZmWzmYXKQRQKY6o6g Content-Language: en-us Subject: Re: [secdir] secdir review of draft-ietf-pcp-base 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, 14 Mar 2012 01:07:57 -0000 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Wednesday, February 29, 2012 11:46 AM > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-pcp- > base.all@tools.ietf.org > Subject: secdir review of draft-ietf-pcp-base > > > My apologies for the tardiness of this review. The tracker says > it's on the agenda for the next telechat so maybe this isn't completely > useless. > > 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 a simple request/response protocol to create > and manage mappings on upstream devices (like NATs) to control how > incoming packets get forwarded. It defines two threat models (a simple > one and an advanced one) that seem reasonable for the different use > cases. The Security Considerations are well-written and address all > attacks I could think of. The draft is very well-written and complete. > > PCP has a THIRD_PARTY option in which a PCP client can create a > mapping on a PCP server for a different device. This has the potential > for abuse. The implications of this option are mentioned somewhat in > passing in the section that describes the option ("Determining which > PCP > clients are authorized to use the THIRD_PARTY Option for which other > hosts is deployment-dependent....A cryptographic authentication and > authorization model is outside the scope of this specification") but > it would be nice if they were addressed a bit more in the Security > Considerations section. It would be nice to see mention of: > > a) what capabilities should a PCP server have to properly address > authorization of requests that include the THIRD_PARTY option; > and, > b) what are the implications of enabling the THIRD_PARTY option on a > PCP server? In other words, what does a user need to understand > before he enables it? In -24, I added the following new paragraph to the THIRD_PARTY section. It doesn't fully answer your point, but provides some guidance to when and where THIRD_PARTY is intended to be used: A management device would use this Option to control a PCP server on behalf of users. For example, a management device located in a network operations center, which presents a user interface to end users or to network operations staff, and issues PCP requests with the THIRD_PARTY option to the appropriate PCP server. > I understand that this is a very tardy request, my apologies again, so > I understand if this comment is not resolved. -d From barryleiba.mailing.lists@gmail.com Tue Mar 13 19:58: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 E28F521F8577 for ; Tue, 13 Mar 2012 19:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.983 X-Spam-Level: X-Spam-Status: No, score=-102.983 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHny-R2tzROH for ; Tue, 13 Mar 2012 19:58:17 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 50CE221F855F for ; Tue, 13 Mar 2012 19:58:17 -0700 (PDT) Received: by yenm5 with SMTP id m5so1506163yen.31 for ; Tue, 13 Mar 2012 19:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nvX3spzrY0B+cq7Z5Qgpzvw8l+W5guGAiiUr7jS5AfM=; b=yQ16i1QUuoy4kK45VPWkFi56jvJb5lsiShCRIyqy5FS/Ken1gGjzZvFF48kW2hM4Nn T7fkmYvRAETYLbBG/85VScYr5U12pPWjgg9RO8WYI8b3eYFrFN2PTkPiybuRe3cdjPos SQuk/pqmXCumrLWt+VG5AM7p/5v1smII46lnree/ME/OuwEyAhEu43W1HJc7Kh+dolcc u7/Dsa0lkTHBJhu972f1F+nODOe+7XcG8Bi1vJLlJE13z51U2mi2nUgqf/hLtD6VI69Z jxJAOh2LQO5vE2R7chCPEzWfyxRn2YeOAQBnh+oF4sdIpZJc+tCpWtPVu3Ss5TY6EOz3 zu/Q== MIME-Version: 1.0 Received: by 10.236.181.193 with SMTP id l41mr1065993yhm.38.1331693896961; Tue, 13 Mar 2012 19:58:16 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Tue, 13 Mar 2012 19:58:16 -0700 (PDT) In-Reply-To: <4F5FC1B1.2090806@cs.tcd.ie> References: <4F5FC1B1.2090806@cs.tcd.ie> Date: Tue, 13 Mar 2012 22:58:16 -0400 X-Google-Sender-Auth: Q_9WeirCO8TONipjJeqUgQWNPOs Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: multipart/alternative; boundary=20cf30563a13ad8fcd04bb2b2574 Cc: "secdir@ietf.org" Subject: Re: [secdir] secdir lunch question 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, 14 Mar 2012 02:58:18 -0000 --20cf30563a13ad8fcd04bb2b2574 Content-Type: text/plain; charset=ISO-8859-1 I certainly want to go to both. But using the Peter Bergman Memorial "How Can You Be In Two Places At Once When You're Not Anywhere At All?" principle, I'll go to SecDir if we have it, and ISOC if we don't. Barry --20cf30563a13ad8fcd04bb2b2574 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I certainly want to go to both. =A0But using the Peter Bergman Memorial &qu= ot;How Can You Be In Two Places At Once When You're Not Anywhere At All= ?" principle, I'll go to SecDir if we have it, and ISOC if we don&= #39;t.

Barry
--20cf30563a13ad8fcd04bb2b2574-- From new-work-bounces@ietf.org Tue Mar 13 19:01:31 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 A6E1121E8041; Tue, 13 Mar 2012 19:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331690491; bh=s1kqtI+9B3os+XR8hyxVrxJKxqYx8mT0SIZl8nQysLg=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=tBwu5QBteHdoX2K8+T7+BCQCKTjTe/xK4HoUouZQla5wnvy2Rh0aFDWOfuuYaGyFk koRWF36TLomo47gYRzHpVYvAvj+KsZLbKi6s5tSoYt9fr6wEKo+8/QCUsHzpPb8oZF NvId+dPLUF0sE+9zbqzHUeVh3HvRjhwe8PzrM/2M= 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 BE70521E8041 for ; Tue, 13 Mar 2012 19:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXhF5vc+pJTg for ; Tue, 13 Mar 2012 19:01:29 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 1E51D21E8040 for ; Tue, 13 Mar 2012 19:01:28 -0700 (PDT) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1S7dWn-0004NF-RF; Tue, 13 Mar 2012 22:01:25 -0400 From: Ian Jacobs Date: Tue, 13 Mar 2012 21:01:25 -0500 To: new-work@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 14 Mar 2012 02:00:50 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: SVG Working Group (until 2012-03-15) 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, 14 Mar 2012 02:01:32 -0000 Hello, On 16 February W3C Advisory Committee Representatives received a Proposal to revise the Graphics Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the SVG Working Group: http://www.w3.org/Graphics/SVG/2011/charter 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. This call for review supersedes an earlier call for review [3] that mistakenly included a link to an older draft of the charter. We did receive some comments during the previous review. We have incorporated them into the charter that is part of this review. W3C invites public comments through 2012-03-15 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, Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/Graphics/Activity [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List [3] http://lists.w3.org/Archives/Public/public-new-work/2011Oct/0000.html -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From rbarnes@bbn.com Wed Mar 14 06:45:54 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 74F6821F87DC for ; Wed, 14 Mar 2012 06:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.354 X-Spam-Level: X-Spam-Status: No, score=-106.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvXd5iOa48Eb for ; Wed, 14 Mar 2012 06:45:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B84CB21F87C6 for ; Wed, 14 Mar 2012 06:45:53 -0700 (PDT) Received: from ros-dhcp192-1-51-17.bbn.com ([192.1.51.17]:60126) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7oWK-0001dg-Hk; Wed, 14 Mar 2012 09:45:40 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <2659937D-335C-4174-8A59-42256C364910@vpnc.org> Date: Wed, 14 Mar 2012 09:46:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <45285D50-DC3C-488B-B50B-CA6A40518882@bbn.com> References: <4F5FC1B1.2090806@cs.tcd.ie> <2659937D-335C-4174-8A59-42256C364910@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) Cc: "secdir@ietf.org" Subject: Re: [secdir] secdir lunch question 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, 14 Mar 2012 13:45:54 -0000 On Mar 13, 2012, at 8:02 PM, Paul Hoffman wrote: > On Mar 13, 2012, at 2:52 PM, Stephen Farrell wrote: >=20 >> a) go ahead with the secdir lunch as usual >> or >> b) skip the secdir lunch this time to allow interested >> folks to go to the ISOC gig. >=20 >=20 > (a). We can't all go to the ISOC lunch (and I doubt they would want us = to), and it is not clear that they will be covering anything new to most = of us. +1 Isn't the ISOC thing usually press-oriented (vs. technically-oriented) = anyway?= From leifj@sunet.se Wed Mar 14 06:52:01 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 4A4C721F87D7 for ; Wed, 14 Mar 2012 06:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlsLtdFreDkF for ; Wed, 14 Mar 2012 06:52:00 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 398A821F87A9 for ; Wed, 14 Mar 2012 06:51:59 -0700 (PDT) Received: from [129.6.252.156] ([129.6.252.156]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2EDpqQa009649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Mar 2012 14:51:57 +0100 (CET) Message-ID: <4F60A278.1000802@sunet.se> Date: Wed, 14 Mar 2012 14:51:52 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: secdir@ietf.org References: <4F5FC1B1.2090806@cs.tcd.ie> <2659937D-335C-4174-8A59-42256C364910@vpnc.org> <45285D50-DC3C-488B-B50B-CA6A40518882@bbn.com> In-Reply-To: <45285D50-DC3C-488B-B50B-CA6A40518882@bbn.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir lunch question 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, 14 Mar 2012 13:52:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2012 02:46 PM, Richard L. Barnes wrote: > > On Mar 13, 2012, at 8:02 PM, Paul Hoffman wrote: > >> On Mar 13, 2012, at 2:52 PM, Stephen Farrell wrote: >> >>> a) go ahead with the secdir lunch as usual or b) skip the >>> secdir lunch this time to allow interested folks to go to the >>> ISOC gig. >> >> >> (a). We can't all go to the ISOC lunch (and I doubt they would >> want us to), and it is not clear that they will be covering >> anything new to most of us. > > +1 > > Isn't the ISOC thing usually press-oriented (vs. > technically-oriented) anyway? not sure it will be that way this time at least. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9goncACgkQ8Jx8FtbMZnfxcgCfc8/lUok63PytFiAzpBeWBdBT Bv0An1h8VrZpw0eyaJIM1YEciLfZ+Yre =cvJX -----END PGP SIGNATURE----- From kent@bbn.com Wed Mar 14 06:59:46 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 D1C4621F87DF for ; Wed, 14 Mar 2012 06:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.428 X-Spam-Level: X-Spam-Status: No, score=-106.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joElygSm0B2F for ; Wed, 14 Mar 2012 06:59:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5B83E21F87D6 for ; Wed, 14 Mar 2012 06:59:46 -0700 (PDT) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49162) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7ojm-0001xR-Op; Wed, 14 Mar 2012 09:59:34 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F5FC1B1.2090806@cs.tcd.ie> References: <4F5FC1B1.2090806@cs.tcd.ie> Date: Wed, 14 Mar 2012 09:53:10 -0400 To: Stephen Farrell , Sean Turner From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "secdir@ietf.org" Subject: Re: [secdir] secdir lunch question 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, 14 Mar 2012 13:59:46 -0000 At 9:52 PM +0000 3/13/12, Stephen Farrell wrote: >Hi all, > >ISOC are organising an openid and oauth briefing session >in Paris that clashes with our usual secdir lunch session. >The clash is unfortunate but there's nothing to be done >about it now, since slots are so scarce. > >So Sean and I wanted to check with you if you'd rather: > >a) go ahead with the secdir lunch as usual secdir lunch as usual Steve From derek@ihtfp.com Wed Mar 14 08:58: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 78C0E21F85D6 for ; Wed, 14 Mar 2012 08:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.616 X-Spam-Level: X-Spam-Status: No, score=-101.616 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEECFMaVs7-f for ; Wed, 14 Mar 2012 08:58:42 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id E753D21F85CC for ; Wed, 14 Mar 2012 08:58:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E2AC7260268; Wed, 14 Mar 2012 11:58:39 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 22713-08; Wed, 14 Mar 2012 11:58:39 -0400 (EDT) Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id E1B762600BB; Wed, 14 Mar 2012 11:58:38 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q2EFwQ9P006104; Wed, 14 Mar 2012 11:58:26 -0400 From: Derek Atkins To: Stephen Farrell References: <4F5FC1B1.2090806@cs.tcd.ie> Date: Wed, 14 Mar 2012 11:58:20 -0400 In-Reply-To: <4F5FC1B1.2090806@cs.tcd.ie> (Stephen Farrell's message of "Tue, 13 Mar 2012 21:52:49 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: "secdir@ietf.org" Subject: Re: [secdir] secdir lunch question 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, 14 Mar 2012 15:58:42 -0000 Hi, Stephen Farrell writes: > Hi all, > > ISOC are organising an openid and oauth briefing session > in Paris that clashes with our usual secdir lunch session. > The clash is unfortunate but there's nothing to be done > about it now, since slots are so scarce. > > So Sean and I wanted to check with you if you'd rather: > > a) go ahead with the secdir lunch as usual > or > b) skip the secdir lunch this time to allow interested > folks to go to the ISOC gig. > > Can you let Sean and I know which you prefer say by > Monday? (Off list is fine and I'll summarise or use the > list if you prefer.) I suspect that, being one of the OAUTH Chairs, I should probably attend the ISOC Lunch.... I should probably figure out how to RSVP to it. > Thanks, > S. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From Sandra.Murphy@sparta.com Thu Mar 15 10:23:13 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 E2FB421F87B0; Thu, 15 Mar 2012 10:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwz3iKkOxnL1; Thu, 15 Mar 2012 10:23:10 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8DA21F87D0; Thu, 15 Mar 2012 10:23:10 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2FHN9qB028844; Thu, 15 Mar 2012 12:23:09 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2FHN7st006939; Thu, 15 Mar 2012 12:23:07 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Thu, 15 Mar 2012 13:23:07 -0400 From: "Murphy, Sandra" To: "secdir@ietf.org" Thread-Topic: Review of draft-ietf-ippm-rt-loss-03 Thread-Index: Ac0Cy61aoe3WD3DWSdeekjjL3uBB8g== Date: Thu, 15 Mar 2012 17:23:07 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7F35@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg@ietf.org" , "draft-ietf-ippm-rt-loss.all@tools.ietf.org" Subject: [secdir] Review of draft-ietf-ippm-rt-loss-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 17:23:13 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments 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 draft-ietf-ippm-rt-loss-03 draft defines a round trip loss metric. A r= ound trip loss measurement capability is specified in RFC5357 ("Two-Way Act= ive Measurement Protocol (TWAMP)"), but no metric has been defined in the d= efined RFC2330 framework. As this draft defines a new metric, not the means to implement measurements= with the metric, I do not see that security considerations apply. But I s= ee no problem with discussion of the considerations that should guide imple= mentations. (Indeed, RFC2861 which defines a delay metric says much the same: Conducting Internet measurements raises both security and privacy concerns. This memo does not specify an implementation of the metrics, so it does not directly affect the security of the Internet nor of applications which run on the Internet. However, implementations of these metrics must be mindful of security and privacy concerns.) I have a few comments about the security considerations section. =20 The section mentions both active and passive use of the metric. But the ab= stract and intro imply this metric is for use in TWAMP, which is active. I= s use of the metric possible in passive measurements as well? In section 9.3, it says: It may be possible to identify that a certain packet or stream of packets is part of a sample. With that knowledge at the destination and/or the intervening networks, it is possible to change the processing of the packets (e.g. increasing or decreasing delay) that may distort the measured performance. It may also be possible to generate additional packets that appear to be part of the sample metric. These additional packets are likely to perturb the results of the sample measurement. To discourage the kind of interference mentioned above, packet interference checks, such as cryptographic hash, may be used. How would a simple crypto hash prevent either the distortion of performance= (delaying a packet will not change its hash) or the injection of additiona= l packets (a cryptographic hash can be computed for the injected packets as= well). RFC2861 mentions similar injection concerns and recommends: Authentication techniques, such as digital signatures, m= ay be used where appropriate to guard against injected traffic attacks. Is there reason to suggest authentication in this metric definition as well= ? TWAMP provides (but does not mandate) both authentication and encryption= . If TWAMP is the only use of the metric, those features should be mention= ed. If TWAMP is just one important use of the metric, it could be good to = mention the features here. --Sandy= From weiler+secdir@watson.org Fri Mar 16 05:59:44 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 8757221F8675 for ; Fri, 16 Mar 2012 05:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty9wzFZ+hYaN for ; Fri, 16 Mar 2012 05:59:44 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id D7C3621F865A for ; Fri, 16 Mar 2012 05:59:43 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2GCxgEK047252 for ; Fri, 16 Mar 2012 08:59:42 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2GCxg57047247 for ; Fri, 16 Mar 2012 08:59:42 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 16 Mar 2012 08:59:42 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 16 Mar 2012 08:59:43 -0400 (EDT) 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, 16 Mar 2012 12:59:44 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Klaas Wierenga is next in the rotation. For telechat 2012-04-12 Reviewer LC end Draft Alexey Melnikov T 2012-03-22 draft-ietf-behave-nat64-learn-analysis-03 Kathleen Moriarty T 2012-03-20 draft-ietf-bmwg-protection-meth-09 Russ Mundy T 2012-03-20 draft-ietf-fecframe-raptor-10 Tim Polk T 2012-02-07 draft-ietf-oauth-v2-bearer-18 Eric Rescorla T 2012-03-20 draft-ietf-savi-dhcp-12 Vincent Roca T 2012-04-03 draft-johansson-loa-registry-04 Ondrej Sury T 2012-03-26 draft-ietf-bmwg-ipflow-meth-09 Brian Weis T 2012-04-09 draft-jivsov-openpgp-ecc-10 Last calls and special requests: Reviewer LC end Draft Jeffrey Hutzelman 2012-03-21 draft-betts-itu-oam-ach-code-point-03 Chris Lonvick 2012-03-28 draft-melnikov-smtp-priority-09 Catherine Meadows 2012-03-22 draft-ietf-avtcore-ecn-for-rtp-06 Magnus Nystrom 2012-03-20 draft-ietf-multimob-igmp-mld-tuning-05 Radia Perlman 2012-03-21 draft-ietf-pwe3-redundancy-06 Tim Polk 2012-03-21 draft-ietf-pwe3-redundancy-bit-06 Eric Rescorla 2012-02-08 draft-ietf-sieve-notify-sip-message-08 Vincent Roca 2012-02-06 draft-ietf-simple-chat-14 Joe Salowey 2012-04-18 draft-templin-aero-10 Yaron Sheffer 2012-03-26 draft-ietf-avtcore-feedback-supression-rtp-15 Tina TSOU 2012-03-23 draft-ietf-mpls-tp-oam-analysis-08 Carl Wallace - draft-ietf-roll-minrank-hysteresis-of-07 Sam Weiler 2012-03-23 draft-sakane-dhc-dhcpv6-kdc-option-14 From kathleen.moriarty@emc.com Sat Mar 17 12:03: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 2557E21F864C; Sat, 17 Mar 2012 12:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.017 X-Spam-Level: X-Spam-Status: No, score=-10.017 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgv309zeW8A8; Sat, 17 Mar 2012 12:03:32 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6150821F864A; Sat, 17 Mar 2012 12:03:31 -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 q2HJ3Ifr009012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Mar 2012 15:03:19 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Sat, 17 Mar 2012 15:03:04 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2HJ335q030680; Sat, 17 Mar 2012 15:03:03 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Sat, 17 Mar 2012 15:03:02 -0400 From: To: , , Date: Sat, 17 Mar 2012 15:03:01 -0400 Thread-Topic: sec-dir review of draft-ietf-bmwg-protection-meth-09.txt Thread-Index: Ac0EcJNm6pQrUct0Q6qImOcFcoan6A== 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 Cc: jeanlouis.leroux@francetelecom.com, sporetsky@allot.com, svapiwal@cisco.com, jkarthik@cisco.com, srao@du.edu, rajiv.papneja@huawei.com Subject: [secdir] sec-dir review of draft-ietf-bmwg-protection-meth-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 19:03:33 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft is ready for publication. Summary: I do not see any security concerns raised by this draft. The draft specifi= es benchmarking methods including report formats and metrics to consistentl= y benchmark MPLS protection mechanisms. The draft does not specify the pro= tection mechanisms. The security considerations section limits the recomme= nded tests to closed environments, further limiting any possible security c= oncerns. Best regards, Kathleen From magnusn@gmail.com Sun Mar 18 22:32:13 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 2378C21F85F6; Sun, 18 Mar 2012 22:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDDObl93liZV; Sun, 18 Mar 2012 22:32:12 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 679EA21F85EF; Sun, 18 Mar 2012 22:32:12 -0700 (PDT) Received: by qaea16 with SMTP id a16so619330qae.10 for ; Sun, 18 Mar 2012 22:32:11 -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=ky+4Q9wpg73wOmMi8hyFMipiu4LqD3cPugF1XgMBlTw=; b=BAY9u4tEahASPsU4XLeXNbZmivOyzvfHvyuSEk8CC/YlJYcqFXHiJALX+WVd/ZuWnJ 9lqBHMjNwgNjhnzgUVPRqSPQ0RK06B4BVIMPwwCNkv0E1UUrV6RJOOax+asohZi6Ef2u uXPdRT3mjmwLqNA37qnpImAORT1qMG9RT9eO2Eo9BejCgTWepn1Tu3hQwYLOGYc2j82j YfVLenv+JYuLIevTDh31cJ2jcWBcvO73wF/wzUvPdhRwybE3Y5bbGv1mNB4iiQdGjMDN 4IeYnLyxLc5loI/Fdag8WkeNFtLn6uEO4QK1N3qduZoIbVsSDXDzL0R2wSZ43Vs0CaIy 6CuA== MIME-Version: 1.0 Received: by 10.224.106.66 with SMTP id w2mr13883353qao.1.1332135131899; Sun, 18 Mar 2012 22:32:11 -0700 (PDT) Received: by 10.229.182.204 with HTTP; Sun, 18 Mar 2012 22:32:11 -0700 (PDT) Date: Sun, 18 Mar 2012 22:32:11 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, draft-ietf-multimob-igmp-mld-tuning@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] Secdir review of draft-ietf-multimob-igmp-mld-tuning-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 05:32:13 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This informational document suggests profiles of the IGMPv3 and the MLDv2 protocols. In particular, it suggests tuning and optimization for mobile and wireless networks. The document does not propose any new functionality and as such, seems correct in stating that no new security considerations are warranted beyond those present in the core protocol documents. My only suggestion is that the document is reviewed by a native English speaker for grammatical enhancements. -- Magnus From radiaperlman@gmail.com Mon Mar 19 15:22: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 DF5DC21F885D; Mon, 19 Mar 2012 15:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.843 X-Spam-Level: X-Spam-Status: No, score=-3.843 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YyratlH7fQy; Mon, 19 Mar 2012 15:22:23 -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 AC38121F885C; Mon, 19 Mar 2012 15:22:22 -0700 (PDT) Received: by eaaq11 with SMTP id q11so3047198eaa.31 for ; Mon, 19 Mar 2012 15:22:21 -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 :content-transfer-encoding; bh=igMBIxRhnLPn5RER0beZmS0wBo9KVGjilHjjLogY+aY=; b=vA3uhnZlXNdOoj+HCNcXq+oQjaI02olDVXYF8iJ3UNfdFHf8W1MEvNFr4AKb5/X4jG RktT4B9XPuqjfeN4bDLvOPRxCZ1VA7DmixfVIrWxGSlCQT9sFTN1Wh1ZN2IM/sPIpOUU Nwp2BKHVdwHLhnvNF7JH2bOS9rv4VsGDXElygcRM9m0LaXd16WIav8pCh6iGsFmrHL9Y XJcnC1cIDRVvH+0yruOWlyBfjKS0FqG8ih8hqFGgIIntCGHwXDj7heVAs20TCxyN9ecD m54kNHd99RiZFTzlWToqV9Goy6lxCSl2s2xs9K9OP1reW6Fy2fi8jmXIgET2PVzNItmy jiNA== MIME-Version: 1.0 Received: by 10.213.15.130 with SMTP id k2mr644747eba.129.1332195741686; Mon, 19 Mar 2012 15:22:21 -0700 (PDT) Received: by 10.213.19.129 with HTTP; Mon, 19 Mar 2012 15:22:21 -0700 (PDT) Date: Mon, 19 Mar 2012 15:22:21 -0700 Message-ID: From: Radia Perlman To: The IESG , secdir@ietf.org, draft-ietf-pwe3-redundancy.all@tools.ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [secdir] secdir review of draft-ietf-pwe3-redundancy-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:22:24 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a requirements document (intended as informational) for a routing protocol. At this level of abstraction, I don=92t think there are any interesting security issues. There are some messages in the protocol that need to be communicated securely, and the security considerations section references some other RFCs and says the new messages will =93inherit at least the same security properties=94 as the messages in those other RFCs. I didn=92t look up what kind of protection existed there. The interesting routing protocol issue has to do with nesting of routing algorithms and the needed multipliers in timeouts. It would appear that pseudo-wires run over a conventional routed infrastructure and also connect parts of a conventional routed infrastructure. The spec assumes that failures within the inner routed infrastructure will heal themselves quickly enough to not be noticed by the pwe3 redundancy protocol (if they are capable of healing at all), and that pseudo-wire failover (triggered by this inner failure) will happen quickly enough to not disrupt the routing protocol that is running over the pseudo-wires. But that requirement is not explicitly acknowledged in the document, and it intuitively seems like a significant challenge. Micro-level issues: In terminology (section 2), the Primary PW is defined as the one that will be used when any one will do, and that if it goes down and comes back the PW will revert to it. But it also defines non-revertive protection switching as an option where the traffic will not switch back to the primary unless the secondary fails, and in section 4.1 it says that non-revertive protection MUST be supported and revertive is optional. Typos: Section 4.1: besupported -> be supported suported -> supported Section 4.2: Orphaned bullet From haibin.song@huawei.com Thu Mar 22 00:46: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 4BED421F854F; Thu, 22 Mar 2012 00:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed3Hjc10IrMU; Thu, 22 Mar 2012 00:46:18 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6086221F865E; Thu, 22 Mar 2012 00:46:18 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEP27150; Thu, 22 Mar 2012 03:46:16 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 00:43:26 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 00:43:07 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.30]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Thu, 22 Mar 2012 15:43:19 +0800 From: Songhaibin To: Leif Johansson , "draft-ietf-decade-problem-statement.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: secdir review of draft-ietf-decade-problem-statement-05 Thread-Index: AQHM/8ckkXYM1WOcX0uR8SdmSpAMmJZ1/Tbw Date: Thu, 22 Mar 2012 07:44:01 +0000 Message-ID: References: <4F5D0D74.5030209@sunet.se> In-Reply-To: <4F5D0D74.5030209@sunet.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 22 Mar 2012 02:01:33 -0700 Subject: Re: [secdir] secdir review of draft-ietf-decade-problem-statement-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 07:46:19 -0000 Thank you Leif, > My main problem with the draft is that the Security Considerations > Section is weak. I would have liked a more in-depth analysis of the > enumerated threats in the context of decade. For instance the privacy > aspects of using in-network storage for P2P networks is only covered > briefly as part of a discussion on traffic analysis. Because many of the security threats are not very special compared to other= client-server interactions, so we did not give much analysis there, but on= ly quote the potential threats here. But we will try to think a little more= deeper. > Also in section 3.2 it is noted that E2E encryption may render P2P > caches ineffective. This speaks to a fundamental flaw (imo) in the > architecture: the standard way to protect against many of the stated > attacks also leads to inefficiency of decade. At the very least the > document needs to call this issue out clearly. You are right. But this issue seems to be better covered in the architectur= e document than this one. BR, -Haibin > -----Original Message----- > From: Leif Johansson [mailto:leifj@sunet.se] > Sent: Monday, March 12, 2012 4:39 AM > To: draft-ietf-decade-problem-statement.all@tools.ietf.org; iesg@ietf.org= ; > secdir@ietf.org > Subject: secdir review of draft-ietf-decade-problem-statement-05 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=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 >=20 > Also in section 3.2 it is noted that E2E encryption may render P2P > caches ineffective. This speaks to a fundamental flaw (imo) in the > architecture: the standard way to protect against many of the stated > attacks also leads to inefficiency of decade. At the very least the > document needs to call this issue out clearly. >=20 > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk9dDXQACgkQ8Jx8FtbMZndzfQCdGlV5Vun5Khv9doeYdcjebALX > ++EAn0VVTjtEMsDlFFM86NlWC+pRlr7X > =3DOb4+ > -----END PGP SIGNATURE----- From leifj@sunet.se Thu Mar 22 03:39:10 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 3593D21F8565; Thu, 22 Mar 2012 03:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBcOFW4VsaCG; Thu, 22 Mar 2012 03:39:09 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 49CE321F855D; Thu, 22 Mar 2012 03:39:09 -0700 (PDT) Received: from [130.229.141.185] (n141-p185.kthopen.kth.se [130.229.141.185]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2MAaxvi013270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2012 11:37:05 +0100 (CET) Message-ID: <4F6B00CB.40707@sunet.se> Date: Thu, 22 Mar 2012 11:36:59 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Songhaibin References: <4F5D0D74.5030209@sunet.se> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "secdir@ietf.org" , "draft-ietf-decade-problem-statement.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-decade-problem-statement-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 10:39:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/22/2012 08:44 AM, Songhaibin wrote: > Thank you Leif, > >> My main problem with the draft is that the Security >> Considerations Section is weak. I would have liked a more >> in-depth analysis of the enumerated threats in the context of >> decade. For instance the privacy aspects of using in-network >> storage for P2P networks is only covered briefly as part of a >> discussion on traffic analysis. > > Because many of the security threats are not very special compared > to other client-server interactions, so we did not give much > analysis there, but only quote the potential threats here. But we > will try to think a little more deeper. > I think thats where we disagree. My argument is that since some of the architecture is invalidated by common solutions to the usual threat vectors (eg e2e encryption). Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9rAMYACgkQ8Jx8FtbMZndKTQCfRPosiDyR8qVxzVv5mxOCZybE 7ggAnjrKN/BC5ZL5F5I/5griYLcwnTa/ =dAdC -----END PGP SIGNATURE----- From haibin.song@huawei.com Thu Mar 22 04:42: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 CCB1621F86AD; Thu, 22 Mar 2012 04:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0CgB-iUl9fd; Thu, 22 Mar 2012 04:42:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3161321F86AB; Thu, 22 Mar 2012 04:42:45 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEP39025; Thu, 22 Mar 2012 07:42:44 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 04:40:02 -0700 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 04:40:01 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.30]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 22 Mar 2012 19:39:57 +0800 From: Songhaibin To: Leif Johansson Thread-Topic: secdir review of draft-ietf-decade-problem-statement-05 Thread-Index: AQHM/8ckkXYM1WOcX0uR8SdmSpAMmJZ1/Tbw//+sioCAAJGbEA== Date: Thu, 22 Mar 2012 11:40:45 +0000 Message-ID: References: <4F5D0D74.5030209@sunet.se> <4F6B00CB.40707@sunet.se> In-Reply-To: <4F6B00CB.40707@sunet.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "secdir@ietf.org" , "Woundy, Richard" , "draft-ietf-decade-problem-statement.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-decade-problem-statement-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 11:42:45 -0000 Hi Leif, I do not say your suggestion is wrong. Instead, I think your comment is ver= y reasonable. I say this is the problem statement draft, I admit we are goi= ng to dig a little deeper with the potential threats in our context (withou= t an architecture as the basis), but these threats are not going to be solv= ed here, they will be considered when designing the architecture document. BR, -Haibin > -----Original Message----- > From: Leif Johansson [mailto:leifj@sunet.se] > Sent: Thursday, March 22, 2012 6:37 PM > To: Songhaibin > Cc: draft-ietf-decade-problem-statement.all@tools.ietf.org; iesg@ietf.org= ; > secdir@ietf.org > Subject: Re: secdir review of draft-ietf-decade-problem-statement-05 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 03/22/2012 08:44 AM, Songhaibin wrote: > > Thank you Leif, > > > >> My main problem with the draft is that the Security > >> Considerations Section is weak. I would have liked a more > >> in-depth analysis of the enumerated threats in the context of > >> decade. For instance the privacy aspects of using in-network > >> storage for P2P networks is only covered briefly as part of a > >> discussion on traffic analysis. > > > > Because many of the security threats are not very special compared > > to other client-server interactions, so we did not give much > > analysis there, but only quote the potential threats here. But we > > will try to think a little more deeper. > > >=20 > I think thats where we disagree. My argument is that since some of > the architecture is invalidated by common solutions to the usual > threat vectors (eg e2e encryption). >=20 > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk9rAMYACgkQ8Jx8FtbMZndKTQCfRPosiDyR8qVxzVv5mxOCZybE > 7ggAnjrKN/BC5ZL5F5I/5griYLcwnTa/ > =3DdAdC > -----END PGP SIGNATURE----- From leifj@sunet.se Thu Mar 22 04:53: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 7AE5721F86E4; Thu, 22 Mar 2012 04:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiDipLy393GN; Thu, 22 Mar 2012 04:53:22 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 71E6121F86DC; Thu, 22 Mar 2012 04:53:22 -0700 (PDT) Received: from [130.229.141.185] (n141-p185.kthopen.kth.se [130.229.141.185]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2MBqmJi019223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2012 12:52:51 +0100 (CET) Message-ID: <4F6B1290.50006@sunet.se> Date: Thu, 22 Mar 2012 12:52:48 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Songhaibin References: <4F5D0D74.5030209@sunet.se> <4F6B00CB.40707@sunet.se> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "secdir@ietf.org" , "Woundy, Richard" , "draft-ietf-decade-problem-statement.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-decade-problem-statement-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 11:53:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/22/2012 12:40 PM, Songhaibin wrote: > Hi Leif, > > I do not say your suggestion is wrong. Instead, I think your > comment is very reasonable. I say this is the problem statement > draft, I admit we are going to dig a little deeper with the > potential threats in our context (without an architecture as the > basis), but these threats are not going to be solved here, they > will be considered when designing the architecture document. > I'm not asking for solutions in the problem statement draft but a clear statement that the problems exist and need to be solved. I could not see that in the current draft, in particular wrt the issue I raised. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9rEpAACgkQ8Jx8FtbMZnfjNACggLa66HWz8XgBZhUcMuP6d1EI QI0AoJdax9sqfAmg9bd5WVirAovfGhrU =yNLy -----END PGP SIGNATURE----- From ietfdbh@comcast.net Thu Mar 22 05:56:51 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 375F921F85D9 for ; Thu, 22 Mar 2012 05:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.308 X-Spam-Level: X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGd0Y3Shedy3 for ; Thu, 22 Mar 2012 05:56:50 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 327D021F857D for ; Thu, 22 Mar 2012 05:56:50 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta01.westchester.pa.mail.comcast.net with comcast id obsq1i0051ZXKqc51cwq6M; Thu, 22 Mar 2012 12:56:50 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta21.westchester.pa.mail.comcast.net with comcast id ocwQ1i01Y3Ecudz3hcwY70; Thu, 22 Mar 2012 12:56:50 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 22 Mar 2012 08:56:21 -0400 From: David Harrington To: Songhaibin , Leif Johansson Message-ID: Thread-Topic: secdir review of draft-ietf-decade-problem-statement-05 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "secdir@ietf.org" , Richard Woundy , "draft-ietf-decade-problem-statement.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-decade-problem-statement-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 12:56:51 -0000 Hi, I think the problem is "security issues are part of the problem", not just part of the solution. The threats associated with in-network storage should be identified as part of the problem. The need to mitigate the threats is part of the requirements. How to mitigate those threats is part of the solution. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/22/12 7:40 AM, "Songhaibin" wrote: >Hi Leif, > >I do not say your suggestion is wrong. Instead, I think your comment is >very reasonable. I say this is the problem statement draft, I admit we >are going to dig a little deeper with the potential threats in our >context (without an architecture as the basis), but these threats are not >going to be solved here, they will be considered when designing the >architecture document. > >BR, >-Haibin > >> -----Original Message----- >> From: Leif Johansson [mailto:leifj@sunet.se] >> Sent: Thursday, March 22, 2012 6:37 PM >> To: Songhaibin >> Cc: draft-ietf-decade-problem-statement.all@tools.ietf.org; >>iesg@ietf.org; >> secdir@ietf.org >> Subject: Re: secdir review of draft-ietf-decade-problem-statement-05 >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 03/22/2012 08:44 AM, Songhaibin wrote: >> > Thank you Leif, >> > >> >> My main problem with the draft is that the Security >> >> Considerations Section is weak. I would have liked a more >> >> in-depth analysis of the enumerated threats in the context of >> >> decade. For instance the privacy aspects of using in-network >> >> storage for P2P networks is only covered briefly as part of a >> >> discussion on traffic analysis. >> > >> > Because many of the security threats are not very special compared >> > to other client-server interactions, so we did not give much >> > analysis there, but only quote the potential threats here. But we >> > will try to think a little more deeper. >> > >> >> I think thats where we disagree. My argument is that since some of >> the architecture is invalidated by common solutions to the usual >> threat vectors (eg e2e encryption). >> >> Cheers Leif >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk9rAMYACgkQ8Jx8FtbMZndKTQCfRPosiDyR8qVxzVv5mxOCZybE >> 7ggAnjrKN/BC5ZL5F5I/5griYLcwnTa/ >> =dAdC >> -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Thu Mar 22 08:01: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 5364221F852E for ; Thu, 22 Mar 2012 08:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0Bwf0dJJXI4 for ; Thu, 22 Mar 2012 08:00:19 -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 BFEBF21F866A for ; Thu, 22 Mar 2012 08:00:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A7A0B153B52 for ; Thu, 22 Mar 2012 15:00:18 +0000 (GMT) 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=1332428418; bh=/vFcgNZm/U8bxu vYyJJXC2bCQ8kuUW+SueLBnzI40O0=; b=A11SSlnfOiuyID4fk2RXow1sNQc+bA BC4S3ONVl4yLG+y3udI04LDxx6r7g4IA5kyM4RBYamgqAziKRMe2eeDU8kqtCbVG jepAYMS2cF1K68w+r4tMZzo6Epu9xuIFN/o4V2nszxzfpJ7pfMXeBF4iDxNuDqfW OmgfYi1IcPAp7OqTZF69MvwIul+p48Y2fzQlXtd1a6Zd/i9JYJ9VjFFNK0TDY+7X bhQmgvciQsPcumkKiCkZs8oeoLxHq0/ST0zlJ9dJSEDzH3jVPkZRAwKcLHexq4/a Yf3/kkht031keeoAE44NUiQ9gXib6Co2o1+n/KoEQ6YI02uCpPWUDljw== 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 X3ysW7gOqlrM for ; Thu, 22 Mar 2012 15:00:18 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.45.51.117]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2FBFF153B51 for ; Thu, 22 Mar 2012 15:00:18 +0000 (GMT) Message-ID: <4F6B3E81.7070303@cs.tcd.ie> Date: Thu, 22 Mar 2012 15:00:17 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "secdir@ietf.org" References: <4F5FC1B1.2090806@cs.tcd.ie> In-Reply-To: <4F5FC1B1.2090806@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir lunch question 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, 22 Mar 2012 15:01:33 -0000 Hiya, Sorry for being slow getting back to this, it got lost (in my head) when travelling last week. Summary of the responses I've seen on and off list included is: - find another time please (1) - (a) secdir lunch anyway (4) - (b) skip secdir this time, go to ISOC gig (4.5) - have both (0.5) - no opinion (dunno why we got a mail then;-) (1) - will go to secdir if on, otherwise ISOC (2) - whichever has beer (1, no it wasn't me:-) Having seen that, Sean wisely suggested we go for a possibly smaller secdir lunch crowd this time and I'll ask for 10 seats to be reserved for secdir folks at the ISOC gig. Please let me know if you need one. So, secdir lunch will be on (room tbd) and some of us will skip that to check out the ISOC thingy this time. S. On 03/13/2012 09:52 PM, Stephen Farrell wrote: > > Hi all, > > ISOC are organising an openid and oauth briefing session > in Paris that clashes with our usual secdir lunch session. > The clash is unfortunate but there's nothing to be done > about it now, since slots are so scarce. > > So Sean and I wanted to check with you if you'd rather: > > a) go ahead with the secdir lunch as usual > or > b) skip the secdir lunch this time to allow interested > folks to go to the ISOC gig. > > Can you let Sean and I know which you prefer say by > Monday? (Off list is fine and I'll summarise or use the > list if you prefer.) > > Thanks, > S. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From turners@ieca.com Fri Mar 23 05:29: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 768D321F84DD for ; Fri, 23 Mar 2012 05:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUNLOs+VrXdm for ; Fri, 23 Mar 2012 05:29:43 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.7.11]) by ietfa.amsl.com (Postfix) with ESMTP id 931F621F84D9 for ; Fri, 23 Mar 2012 05:29:43 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id E46C3187721D9; Fri, 23 Mar 2012 07:29:42 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id D413E187721B4 for ; Fri, 23 Mar 2012 07:29:42 -0500 (CDT) Received: from [198.180.150.234] (port=61074 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SB3ci-0003jg-Np for secdir@ietf.org; Fri, 23 Mar 2012 07:29:42 -0500 Message-ID: <4F6C6CB3.4030203@ieca.com> Date: Fri, 23 Mar 2012 13:29:39 +0100 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: "secdir@ietf.org" References: <4F5FC1B1.2090806@cs.tcd.ie> <4F6B3E81.7070303@cs.tcd.ie> In-Reply-To: <4F6B3E81.7070303@cs.tcd.ie> 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: v234.vpn.iad.rg.net (thunderfish.local) [198.180.150.234]:61074 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [secdir] secdir lunch question 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, 23 Mar 2012 12:29:47 -0000 Room 251 for the secdir lunch. spt On 3/22/12 4:00 PM, Stephen Farrell wrote: > > Hiya, > > Sorry for being slow getting back to this, it got lost (in > my head) when travelling last week. > > Summary of the responses I've seen on and off list included > is: > > - find another time please (1) > - (a) secdir lunch anyway (4) > - (b) skip secdir this time, go to ISOC gig (4.5) > - have both (0.5) > - no opinion (dunno why we got a mail then;-) (1) > - will go to secdir if on, otherwise ISOC (2) > - whichever has beer (1, no it wasn't me:-) > > Having seen that, Sean wisely suggested we go for > a possibly smaller secdir lunch crowd this time and > I'll ask for 10 seats to be reserved for secdir folks > at the ISOC gig. Please let me know if you need one. > > So, secdir lunch will be on (room tbd) and some of > us will skip that to check out the ISOC thingy this > time. > > S. > > > On 03/13/2012 09:52 PM, Stephen Farrell wrote: >> >> Hi all, >> >> ISOC are organising an openid and oauth briefing session >> in Paris that clashes with our usual secdir lunch session. >> The clash is unfortunate but there's nothing to be done >> about it now, since slots are so scarce. >> >> So Sean and I wanted to check with you if you'd rather: >> >> a) go ahead with the secdir lunch as usual >> or >> b) skip the secdir lunch this time to allow interested >> folks to go to the ISOC gig. >> >> Can you let Sean and I know which you prefer say by >> Monday? (Off list is fine and I'll summarise or use the >> list if you prefer.) >> >> Thanks, >> S. >> _______________________________________________ >> 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 Tina.Tsou.Zouting@huawei.com Fri Mar 23 23:12:14 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 555FC21F867B for ; Fri, 23 Mar 2012 23:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjPvIZUkRlIy for ; Fri, 23 Mar 2012 23:12:13 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A307321F85CE for ; Fri, 23 Mar 2012 23:12:13 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEQ65725; Sat, 24 Mar 2012 02:12:13 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 23:11:02 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 23:10:59 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.214]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Sat, 24 Mar 2012 14:10:55 +0800 From: Tina TSOU To: "secdir@ietf.org" , "draft-ietf-mpls-tp-oam-analysis@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-mpls-tp-oam-analysis-08 Thread-Index: AQHNCYTfIZ8uMvCtg0mge42m/0NwfQ== Date: Sat, 24 Mar 2012 06:10:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.127] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [secdir] secdir review of draft-ietf-mpls-tp-oam-analysis-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: Sat, 24 Mar 2012 06:12:14 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any= other last call comments. Some comments which may not be from security aspects only are below. 1) One missing OAM function I compared the OAM functions listed in this draft and those required in RFC= 5860 and find out one OAM function named Client Failure Indication (Section= 2.2.10 of [RFC 5860]) is missing. I cannot see a reason for this. Since th= is is an informational analysis document, it is recommended to give a whole= view. Specific clarifications are appreciated in the document.=20 2) Lack of analysis about the compatibility with existing tools It is said in this document that compatibility with the existing tools has = been maintained. But there is no detailed analysis which IMHO might be of g= reat interest to the industry and should form an important part of this ana= lysis document. 3) 1.1 Scope In the middle of this section, under the "three objectives", the first bull= et reads =20 o The OAM toolset should be developed based on existing MPLS architecture, technology, and toolsets. However, in the following paragraph it is written as o ITU-T OAM for Ethernet toolset as defined in [Y.1731]. This has been used for functionality guidelines for the performance measurement tools that were not previously supported in MPLS. There seem to be conflicts between the objective (should...existing MPLS...= .) and the toolset development (...tools...not...supported in MPLS). [RFC 5= 860] says that "...the MPLS-TP design, SHOULD as far as reasonably possible= , reuse existing MPLS standards." which looks more appropriate to me as the= objective. Please clarify this point. 4) 1.1 Scope The third one of the "three objectives" in this draft reads=20 o The OAM toolset developed for MPLS based transport networks needs to be fully inter-operable with existing MPLS OAM tools as documented in [RFC 5860]. I may be wrong but I find [RFC 5860] only requires OAM interoperability bet= ween distinct domains (w/wo IP capabilities). The original description is a= s follows: It is REQUIRED that OAM interoperability is achieved between distinct domains materializing the environments described in Section 2.1.4. =20 My understanding of the "OAM interoperability" mentioned here refers to MPL= S-TP OAM interoperable in different domains, but not MPLS-TP OAM and MPLS O= AM interoperability.=20 5) MPLS-TP v.s. MPLS based transport networks The draft uses both "MPLS-TP" and "MPLS based transport networks". E.g. is = it "MPLS-TP OAM" or OAM toolset developed for MPLS based transport networks= ?=20 Are they the same? Or what is the relationship between them? Tina From stephen.farrell@cs.tcd.ie Mon Mar 26 00: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 EBE2D21F855F for ; Mon, 26 Mar 2012 00:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.65 X-Spam-Level: X-Spam-Status: No, score=-103.65 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7j5Aton8+dp for ; Mon, 26 Mar 2012 00:42:23 -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 901AC21F8517 for ; Mon, 26 Mar 2012 00:42:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D5B75171C08 for ; Mon, 26 Mar 2012 08:42:22 +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=1332747742; bh=ja5vlvNQRlEC8y ynt8vmGHE+tCmxo0hq4C2GzWnTfho=; b=3I84D0bBLx+8YnUXKEWNHJdYg7pzQs 8/h9fEtP9m4tic5kLeAbTelTTBXAqn1nuoItwD52rr36/g2uI8V8v1Nc1EUMdHxn 2TGY3pMdNSXr+k1D+VUd7PljPBFvMuwdmVVGn4+Onw+r4PTCJfo0Y4tOn5KFY3IJ k7lq6U/sIXhUhG4XWGXYGjznYRWY066AZUI94ZqhFnJX3XR2+S33bzqKGqG5iz+i x5FjoWof+AqmnsznGNWjw4ESQYitYHZsIX2Q81G6WLoCvvlsN2dPHKl4NpMq1r7C x+X+vzu0PnpX8qyfLreJc1jBHgup0kQWvp/EphoH7alZ2AQW2kgx0WxQ== 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 ZrOC6PG3AOCu for ; Mon, 26 Mar 2012 08:42:22 +0100 (IST) Received: from [130.129.37.121] (dhcp-2579.meeting.ietf.org [130.129.37.121]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 527A4171C02 for ; Mon, 26 Mar 2012 08:42:22 +0100 (IST) Message-ID: <4F701DDD.6060405@cs.tcd.ie> Date: Mon, 26 Mar 2012 08:42:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "secdir@ietf.org" References: <4F5FC1B1.2090806@cs.tcd.ie> <4F6B3E81.7070303@cs.tcd.ie> <4F6C6CB3.4030203@ieca.com> In-Reply-To: <4F6C6CB3.4030203@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir lunch question 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, 26 Mar 2012 07:42:30 -0000 And for those of you who prefer the ISOC gig this time: "We will set aside 10 places for secdir folks. Please tell them to identify themselves as "secdir" participants at the door. The briefing panel will be held in Room 242AB at La Palais tomorrow at 11:45." Cheers, S. On 03/23/2012 12:29 PM, Sean Turner wrote: > Room 251 for the secdir lunch. > > spt > > On 3/22/12 4:00 PM, Stephen Farrell wrote: >> >> Hiya, >> >> Sorry for being slow getting back to this, it got lost (in >> my head) when travelling last week. >> >> Summary of the responses I've seen on and off list included >> is: >> >> - find another time please (1) >> - (a) secdir lunch anyway (4) >> - (b) skip secdir this time, go to ISOC gig (4.5) >> - have both (0.5) >> - no opinion (dunno why we got a mail then;-) (1) >> - will go to secdir if on, otherwise ISOC (2) >> - whichever has beer (1, no it wasn't me:-) >> >> Having seen that, Sean wisely suggested we go for >> a possibly smaller secdir lunch crowd this time and >> I'll ask for 10 seats to be reserved for secdir folks >> at the ISOC gig. Please let me know if you need one. >> >> So, secdir lunch will be on (room tbd) and some of >> us will skip that to check out the ISOC thingy this >> time. >> >> S. >> >> >> On 03/13/2012 09:52 PM, Stephen Farrell wrote: >>> >>> Hi all, >>> >>> ISOC are organising an openid and oauth briefing session >>> in Paris that clashes with our usual secdir lunch session. >>> The clash is unfortunate but there's nothing to be done >>> about it now, since slots are so scarce. >>> >>> So Sean and I wanted to check with you if you'd rather: >>> >>> a) go ahead with the secdir lunch as usual >>> or >>> b) skip the secdir lunch this time to allow interested >>> folks to go to the ISOC gig. >>> >>> Can you let Sean and I know which you prefer say by >>> Monday? (Off list is fine and I'll summarise or use the >>> list if you prefer.) >>> >>> Thanks, >>> S. >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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 Mon Mar 26 00:59: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 52BF421F85B4 for ; Mon, 26 Mar 2012 00:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.475 X-Spam-Level: X-Spam-Status: No, score=-103.475 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBtgETLbyZ5M for ; Mon, 26 Mar 2012 00:59:00 -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 5780621F85BB for ; Mon, 26 Mar 2012 00:58:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 973F4171C17 for ; Mon, 26 Mar 2012 08:58:53 +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=1332748733; bh=86sQCdqTDhM/qy5UioZwaWyl uDDlQfMonUC6R9ZUewM=; b=58560j2yf649YNCtzd9FiHTPjBeO6D4yOpnPFR6T 8dkr6BeMrlqCpAvA9HLZPNckO6QkqQw4kau9UkJ599NXhsp9/20k5PpSNTSzucjX CM4TMbMLd+VlUIZFwDKl15TYXbEDAqJU31YqKaId0z2jlpplkyJ/mvulIPkXWhg8 3AuEjm8Ia3q1BXKzz5kcgUoAOI+FHdMdbf4tUBhmC3Q59h/hOa0NNbzeIFkSOKre rvvaD0IftGIt/zxdtUkkwzAQEtysVckyHjDsyyZ5Kqxeaofmgi0TQqdbvVG7MVb0 mJMXj3R/PFr7IvtTzOcI6BgoMVhAAx9WY/ADRrq1zopk9Q== 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 J6bYc1i3lKto for ; Mon, 26 Mar 2012 08:58:53 +0100 (IST) Received: from [130.129.37.121] (dhcp-2579.meeting.ietf.org [130.129.37.121]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3C136171C02 for ; Mon, 26 Mar 2012 08:58:53 +0100 (IST) Message-ID: <4F7021BC.1010406@cs.tcd.ie> Date: Mon, 26 Mar 2012 08:58:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "secdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Feedback about secdir reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 07:59:06 -0000 Hi all, The IESG got some anonymized feedback today from the nomcom process. Part of that was that authors were unsure as to how to react to secdir reviews. And in particular, as to whether or not to engage with the secdir reviewer. I know we have some boilerplate [1] that tries to handle this, but it might be worth taking another look at that to see if we can make it better. Something for the lunchtime session on Tuesday. Cheers, S. [1] http://trac.tools.ietf.org/area/sec/trac/wiki/SecDirReview From ietfdbh@comcast.net Mon Mar 26 02:02: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 2677421F84F6 for ; Mon, 26 Mar 2012 02:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, DATE_IN_FUTURE_03_06=0.274, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kbe88+gorC-7 for ; Mon, 26 Mar 2012 02:01:54 -0700 (PDT) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC5121F854D for ; Mon, 26 Mar 2012 02:01:54 -0700 (PDT) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta07.emeryville.ca.mail.comcast.net with comcast id q8zy1i0031zF43QA791u8G; Mon, 26 Mar 2012 09:01:54 +0000 Received: from [130.129.17.13] ([130.129.17.13]) by omta24.emeryville.ca.mail.comcast.net with comcast id q91f1i00D0Gv34a8k91ifR; Mon, 26 Mar 2012 09:01:52 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 26 Mar 2012 11:01:37 -0400 From: David Harrington To: Stephen Farrell , "secdir@ietf.org" Message-ID: Thread-Topic: [secdir] Feedback about secdir reviews In-Reply-To: <4F7021BC.1010406@cs.tcd.ie> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [secdir] Feedback about secdir reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:02:17 -0000 Hi, I made some assumptions from that feedback during the IESG meeting given my experiences in non-sec areas. Many secdir reviewers have a strong security background, but the authors of reviewed documents don't necessarily have the same level of grokking security. Authors may not grok "authn+authz+integrity+confidentiality+access control+..." Authors certainly may not know the best current practices for achieving authn [+authz] [+integrity] [+confidentiality] ... There is an RFC to explain how to write a security considerations section but the security considerations section example is HUGE - multi-pages of discussion. It might be really helpful to have a wiki that discusses common problems in security reviews, plus some suggestions of how to solve the common problems. And I recommend the wiki be updated as new problems are run across in document reviews. Being able to point authors to such a wiki might help. There is still the issue of the authors and Wgs not grokking security. Soemtimes the right answer is that the draft looks like it might have security issues, but actually doesn't introduce any new security problems, and a security person may be able to reach that conclusion fairly easily. But somebody that does not grok security needs to go learn all about security and trust domains and possible protocols and cryptosuites and so on to reach the same conclusion. They need advisors to help them work through the issues that may or may not be a problem. The authors of raqmon got a review that said they had issues to consider. It took something like eight months (IIRC) for them to learn about and consider each issue and determine that the problems cited in the review really didn't exist for their protocol spec. That leaves a pretty bad taste in people's mouths. My $.02 -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/26/12 3:58 AM, "Stephen Farrell" wrote: > >Hi all, > >The IESG got some anonymized feedback today from the nomcom >process. > >Part of that was that authors were unsure as to how to react >to secdir reviews. And in particular, as to whether or not >to engage with the secdir reviewer. > >I know we have some boilerplate [1] that tries to handle this, >but it might be worth taking another look at that to see if >we can make it better. > >Something for the lunchtime session on Tuesday. > >Cheers, >S. > >[1] http://trac.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 paul.hoffman@vpnc.org Mon Mar 26 04:49:43 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 F223021F85B1 for ; Mon, 26 Mar 2012 04:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS18FFBMT27r for ; Mon, 26 Mar 2012 04:49:43 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DF56521F8691 for ; Mon, 26 Mar 2012 04:49:42 -0700 (PDT) Received: from dhcp-2121.meeting.ietf.org (dhcp-2121.meeting.ietf.org [130.129.33.33]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2QBnVb0070416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Mar 2012 04:49:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 26 Mar 2012 13:49:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Harrington X-Mailer: Apple Mail (2.1257) Cc: "secdir@ietf.org" Subject: Re: [secdir] Feedback about secdir reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 11:49:44 -0000 On Mar 26, 2012, at 5:01 PM, David Harrington wrote: > The authors of raqmon got a review that said they had issues to = consider. > It took something like eight months (IIRC) for them to learn about and > consider each issue and determine that the problems cited in the = review > really didn't exist for their protocol spec. > That leaves a pretty bad taste in people's mouths. That happened over five years ago; maybe those people would believe that = the SecDir processes have changed since. --Paul Hoffman From stephen.farrell@cs.tcd.ie Mon Mar 26 23:38:13 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 C4B7521E805A for ; Mon, 26 Mar 2012 23:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMhONdJeI4aF for ; Mon, 26 Mar 2012 23:38:12 -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 913D721E801F for ; Mon, 26 Mar 2012 23:38:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1A20C171C04 for ; Tue, 27 Mar 2012 07:38:11 +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=1332830290; bh=7c4DPJyFlmeOEv/+Pk+Paq4n lARKwEnJEZhdxL7QGYw=; b=ohTkfhK2ZY/ZmMfvDfmHy0eeNrdxeYmA0NJtur90 TagMbnrHnOqTEPp2L5jerGZKFW1LopLx7Zj4YsRQj3uceBbppuofXbOww6nxqHN6 lB6rucPz7n1mFqaLdLJZHObfguLv5t+3o8UtSwqQm/+BHOEBLtCeSRBb4YS5tpxe vQGot8ilv4g4ulZvIKqZejuBBO2JX+HTaz0vUa7LNGKhUD4djcaTp1/JlLidKbeD N2ZmcF+GeMcMp4bfh6G0bHn0v92XExaFOCImhFOlXX2B3NVDCSEwj6cVBdoR/4my TQS8NbeXjsCvYhAdQtZEGOEPj5lYzYanUp+iqn31Gtxc4w== 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 th3VIqcABSlb for ; Tue, 27 Mar 2012 07:38:10 +0100 (IST) Received: from [130.129.19.33] (dhcp-1321.meeting.ietf.org [130.129.19.33]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 742E7171C03 for ; Tue, 27 Mar 2012 07:38:10 +0100 (IST) Message-ID: <4F716052.5060701@cs.tcd.ie> Date: Tue, 27 Mar 2012 07:38:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "secdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Anyone got a spare hour? 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, 27 Mar 2012 06:38:13 -0000 If you do, today or tomorrow, and are in the mood, I'd appreciate if you could take a look at a discuss point ([1], point #1) I have on a document [2] where I've not had the time yet to go through it in enough detail and the WG are meeting Thursday and understandably would like to progress it before then. The situation is a mobile node ("MN") talking to a bit of MIP infrastructure (a "HAC"), over a TLS session, with TLS-server-endpoint channel bindings. (There's a separate issue about how they describe the TLS session but that's being addressed already.) Their MN authentication then goes: " MN HAC | | | Request/MHAuth-Init (...) | |------------------------------------------------------>| | | | Response/MHAuth-Init (...) | |<------------------------------------------------------| | | | Request/MHAuth-Done (...) | |------------------------------------------------------>| | | | Response/MHAuth-Done (...) | |<------------------------------------------------------| | | Figure 4: Authentication of the Mobile Node Using Shared Secrets 1) Request/MHAuth-Init: (MN -> HAC) mn-id, mn-rand, auth-method=psk 2) Response/MHAuth-Init: (MN <- HAC) [mn-rand, hac-rand, auth-method=psk, [status],] auth 3) Request/MHAuth-Done: (MN -> HAC) mn-rand, hac-rand, sa-scope, ciphersuite-list, auth 4) Response/MHAuth-Done: (MN <- HAC) [sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand, hac-rand, status, auth Where: auth = HMAC-SHA256(PSK, msg-octets | CB-octets) The length "mn-rand", "hac-rand" is 32 octets. Note that "|" indicates concatenation and optional parameters are shown in square brackets [..]. The square brackets can be nested. The shared secret PSK can be variable length. 'msg-octets' includes all payload parameters of the respective message to be signed except the 'auth' payload. CB-octets is the channel binding input to the auth calculation that is the "TLS-server-endpoint" channel binding type. " My concern is that there may be reflection attacks, or similar but I've not had the time yet to get down to the nitty-gritty. The attack I've in mind is an MN connecting to the HAC, getting a variant of message 2 and replaying that as message 3. I might want to hold the discuss to get them to add some directional thing in any case, but would really appreciate if someone can delve a bit into how these messages would look on the wire to see if this is a practical attack or just being careful for the future. And since I saw the above problem, I'm a bit concerned there might be more issues, so more eyeballs would be good for that in any case. Feel free to reply on or off list if you do have time to look at this. Thanks in advance, S. [1] https://datatracker.ietf.org/doc/draft-ietf-mext-mip6-tls/ballot/#stephen-farrell [2] https://datatracker.ietf.org/doc/draft-ietf-mext-mip6-tls/ From secdir-bounces@mit.edu Tue Mar 27 01:38:51 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 703FC21F8929 for ; Tue, 27 Mar 2012 01:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.636 X-Spam-Level: X-Spam-Status: No, score=-105.636 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p4ZWuPC7W6I for ; Tue, 27 Mar 2012 01:38:50 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by ietfa.amsl.com (Postfix) with ESMTP id 577B021F8916 for ; Tue, 27 Mar 2012 01:38:50 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id q2R8cnRY004533 for ; Tue, 27 Mar 2012 04:38:49 -0400 Received: from mailhub-dmz-2.mit.edu (MAILHUB-DMZ-2.MIT.EDU [18.7.62.37]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id q2R8ckqH004515 for ; Tue, 27 Mar 2012 04:38:46 -0400 Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id q2R8cj2c021897 for ; Tue, 27 Mar 2012 04:38:45 -0400 X-AuditID: 12074424-b7fae6d000000906-1f-4f717c956137 Authentication-Results: symauth.service.identifier Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 5C.9B.02310.59C717F4; Tue, 27 Mar 2012 04:38:45 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (dhcp-9251.meeting.ietf.org [130.129.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D1F0A20464 for ; Tue, 27 Mar 2012 04:38:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 085E84766; Tue, 27 Mar 2012 04:38:44 -0400 (EDT) From: Sam Hartman To: secdir@mit.edu Date: Tue, 27 Mar 2012 04:38:44 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRWlGSWpSXmKPExsXiKnlERndqTaG/wZleQ4u2Z7vZHBg9ms4c ZQ5gjOKySUnNySxLLdK3S+DK+HvBrmAmU0XHpdIGxuuMXYycHBICJhKLfq1hAbEZBYwkdp97 xQoRF5O4cG89WxcjF4eQwAtGieWvTrJCOKeZJFr6dzGBVAkJ1ElMXHePGcRmE9CUePe2H8wW ERCSuLHgP9hUYQF9ib1ne8DqWQRUJRqO3WYHsXmB7M/TvgBdwcEhKmAv0bqWCyIsKHFy5hOw VmYBLYkb/14yTWDkm4UkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdc73czBK91JTS TYzAMBJid1HZwdh8SOkQowAHoxIPr+H0An8h1sSy4srcQ4ySHExKorynqwv9hfiS8lMqMxKL M+KLSnNSiw8xSnAwK4nwakcB5XhTEiurUovyYVLSHCxK4rwaWu/8hATSE0tSs1NTC1KLYLJM HOyHGGU4OJQkeHmAkSMkWJSanlqRlplTgqyGE0RwgazhAVrDBlLIW1yQmFucmQ5RdIpRUUqc Vw4kIQCSyCjNgxsAi/1LjLJSwryMDAwMQjxAFwA9jir/ilEc6GlhXj6QKTyZeSVw018BLWYC WrzkSD7I4pJEhJRUA2Pi10m3zIoEF02xsOGdb1a/V+fIapY/lnM2We8oVxP5+3vHEt8avYhM ucmyCXuN59my/9QrLUjNEzotIlTxX2jSFsbQgODGo/KnrDvrMo8Vnyved9epoTG8wfwIs6BY us2i2Rbvciw8D7EGr9OJ9i72UlnmeODGLeVbVz+nqV1tXGwiPtfhtBJLcUaioRZzUXEiAIcJ rqX4AgAA X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] Can I get help getting to secdir lunch 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, 27 Mar 2012 08:38:51 -0000 I was wondering if I could get someone to agree to help me grab a lunch and make it to the secdir room? I'm sitting at the tables over by registration and will remain here, but I will not be able to find the room or food on my own. Thanks for your consideration, - --Sam _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From hartmans@painless-security.com Tue Mar 27 01:50:46 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 0F9D021F88D8 for ; Tue, 27 Mar 2012 01:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.565 X-Spam-Level: X-Spam-Status: No, score=-103.565 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uX9hV6V91bw8 for ; Tue, 27 Mar 2012 01:50:45 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 932F821F8802 for ; Tue, 27 Mar 2012 01:50:45 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-9251.meeting.ietf.org [130.129.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7C61A2021E for ; Tue, 27 Mar 2012 04:50:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 39FF54766; Tue, 27 Mar 2012 04:50:44 -0400 (EDT) From: Sam Hartman To: secdir@ietf.org User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) Date: Tue, 27 Mar 2012 04:50:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [secdir] Can I get help getting to secdir lunch 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, 27 Mar 2012 08:50:46 -0000 I was wondering if I could get someone to agree to help me grab a lunch and make it to the secdir room? I'm sitting at the tables over by registration and will remain here, but I will not be able to find the room or food on my own. Thanks for your consideration, - --Sam From hartmans@mit.edu Tue Mar 27 02:19: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 AA51221F8954 for ; Tue, 27 Mar 2012 02:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.447 X-Spam-Level: X-Spam-Status: No, score=-103.447 tagged_above=-999 required=5 tests=[AWL=-1.182, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4ZMJckpUbrA for ; Tue, 27 Mar 2012 02:19:38 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 97A5221F8951 for ; Tue, 27 Mar 2012 02:19:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-9251.meeting.ietf.org [130.129.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 691722021E; Tue, 27 Mar 2012 05:18:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7224B4766; Tue, 27 Mar 2012 05:19:35 -0400 (EDT) From: Sam Hartman To: Sam Hartman References: Date: Tue, 27 Mar 2012 05:19:35 -0400 In-Reply-To: (Sam Hartman's message of "Tue, 27 Mar 2012 04:50:44 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: secdir@ietf.org Subject: Re: [secdir] Can I get help getting to secdir lunch 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, 27 Mar 2012 09:19:38 -0000 I'm all set; Ale xey has volunteered to help me. From rbarnes@bbn.com Tue Mar 27 03:00:43 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 B9A0F21E8133 for ; Tue, 27 Mar 2012 03:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.243 X-Spam-Level: X-Spam-Status: No, score=-106.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzlD8UN-ZIsE for ; Tue, 27 Mar 2012 03:00:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 29E0E21E8132 for ; Tue, 27 Mar 2012 03:00:42 -0700 (PDT) Received: from [128.89.254.221] (port=50617 helo=neutrino.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCTCV-000H9L-Tz for secdir@ietf.org; Tue, 27 Mar 2012 06:00:28 -0400 Message-ID: <4F718FC7.1000207@bbn.com> Date: Tue, 27 Mar 2012 12:00:39 +0200 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: secdir@ietf.org References: <4F67AD46.6040703@w3.org> In-Reply-To: <4F67AD46.6040703@w3.org> X-Forwarded-Message-Id: <4F67AD46.6040703@w3.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Fwd: Beyond HTTP Authentication: OAuth, OpenID, and BrowserID: Meeting on March 29th at IETF83 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, 27 Mar 2012 10:00:43 -0000 FYI -------- Original Message -------- Subject: Beyond HTTP Authentication: OAuth, OpenID, and BrowserID: Meeting on March 29th at IETF83 Resent-Date: Mon, 19 Mar 2012 22:03:06 +0000 Resent-From: public-identity@w3.org Date: Mon, 19 Mar 2012 23:03:50 +0100 From: Harry Halpin To: http-auth@ietf.org , public-identity@w3.org , dev-identity@lists.mozilla.org Not sure how many people are making it to IETF83, but W3C is hosting an onsite meeting on Thursday to discuss OAuth, BrowserID, OpenID, and the upcoming W3C Web Cryptography Working Group. Everyone is invited! ==Beyond HTTP Authentication: OAuth, OpenID, and BrowserID== =Time and Location= Thursday lunchtime (1130 to 1300) in room 252A just between the SCIM BoF and OAuth WG as part of IETF83 in Paris. = Problem Statement= While OAuth has solved the authorization problem, currently authentication on the Web is still insecure as it has yet for the most part failed to go beyond user-names and passwords. However, at this point a number of new client-side capabilities, including the possibility of W3C standardized Javascript cryptographic primitives, are emerging and a number of specifications such as OpenID Connect, BrowserID, and discussions over the future of HTTP Auth have shown that there is interest in understanding better how client-side key material can be used to enable a more secure Web authentication. However, there has yet to be consensus on how client-side cryptography can enable higher-security OAuth flows. The purpose of this side meeting is to look at a more coherent picture of how technologies in the space of identity, authentication, and authorization combine and interact and to help frame future work in Web authentication. This informal meeting will present a number of proposed technical proposals in brief, including relationships to other existing work (such as RTCWeb and the upcoming W3C Web Cryptography Working Group), and to help frame future work in the area.and then precede with open discussion. For any questions, please contact Harry Halpin (hhalpin@w3.org) =Schedule:= 11:30-11:45 Lightning presentations to "level-set" participants. Mike Jones (Microsoft) will present the latest work from JOSE and OpenID Connect Eric Rescorla (Mozilla hat on) will present Mozilla Persona and RTCWeb/WebRTC work Blaine Cook will present OAuth 2.0 Harry Halpin (W3C) will present the upcoming W3C Web Cryptography API. 11:45-13:00 Open discussion on co-ordination between OAuth, HTTP Auth, OpenID Connect, BrowserID, and W3C.