From tobias.gondrom@gondrom.org Mon Nov 1 09:54:53 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F713A6A35 for ; Mon, 1 Nov 2010 09:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.362 X-Spam-Level: X-Spam-Status: No, score=-97.362 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_INVITATION=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOxpaU5CUF9w for ; Mon, 1 Nov 2010 09:54:52 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id E47E63A6A2D for ; Mon, 1 Nov 2010 09:54:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Xj7tRHAefUXySkq5f/xa/kvcJYevVu9a6CIHCPB+LadvvRaawvUp+AY5BmBlVJU/rMtlVXDyXG15jEn0conKzVYsNyOcrVHOCrSzlQbNNiwl2dukQ1Y9Fjd+5RTkmbx1; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 18349 invoked from network); 1 Nov 2010 17:53:54 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Nov 2010 17:53:54 +0100 Message-ID: <4CCEF0A4.3050004@gondrom.org> Date: Mon, 01 Nov 2010 16:53:56 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: websec X-Priority: 4 (Low) X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [websec] Fwd: Nomcom 2010-11: Second Call for Community Feedback on Nominees X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 16:54:53 -0000 Hello dear websec members, Nomcom is asking for input and feedback about the IESG/IAB/IAOC candidates. They're working hard to select the best candidates and your community input is very important for them. So if you know a candidate and could spare a few minutes to provide feedback on him/her, your help would be very valuable for the good functioning of the IETF. Deadline is Nov-12, but the earlier the better. Please find details in their email below. Kind regards, Tobias chair of websec ---------- Forwarded message ---------- From: NomCom Chair Date: Fri, Oct 29, 2010 at 9:52 AM Subject: Nomcom 2010-11: Second Call for Community Feedback on Nominees To: IETF Announcement list Nomcom 2010-2011 requests your input on the willing nominees for the IETF open positions. We request that as much as possible, comments are provided within two weeks of this announcement posting. Please provide comments as soon as possible and no later than November 12th. Comments received after the Beijing meeting may receive less consideration, although we will make every effort to consider any and all input. The feedback form is available at the following URL: https://wiki.tools.ietf.org/group/nomcom/10/input/ Note, you must have an IETF tools login to respond to this invitation. If you do not have one, http://www1.tools.ietf.org/newlogin can be used to get one. The web-based feedback tool gives the NomCom an automated process for collecting input on the nominees. Your input will be encrypted before it is stored by the feedback tool, and can only be decrypted by the NomCom. When you access the feedback form, you will see a list of all of the willing nominees. By clicking on a nominee's name, you will be presented with a text-input form into which you can type your input. While we encourage feedback through the form, you may send feedback to the nomcom list, nomcom10@ietf.org, directly. Community feedback is essential for the nomcom process to be effective. Notes on comparison of nominees to each other are also useful to the nomcom. You are also encouraged to provide notes on how a nominee satisfies the IESG/IAB/IAOC's desired expertise; if you feel that the nominee has a different set of skills necessary for the job and those skills are different from the posted requirements, please provide details. If you prefer to provide anonymous input, please send it directly to the nomcom chair, Tom Walsh, or any other member of the nomcom and request them to anonymize your input. All information provided to the nomcom and the sources of such information are confidential. Thanks in advance for your feedback. Regards, Thomas Walsh NomCom 2010-11 nomcom10@ietf.org nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From tobias.gondrom@gondrom.org Mon Nov 1 10:23:01 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145E53A69AC for ; Mon, 1 Nov 2010 10:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.362 X-Spam-Level: X-Spam-Status: No, score=-96.362 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaKdtXdTQGQX for ; Mon, 1 Nov 2010 10:23:00 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id A62743A63D3 for ; Mon, 1 Nov 2010 10:22:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=DSNUE1pOOSflik3HvLqtWRZHjgzNt/4FeWUTSNmL4nQM9cRrYLCZSO6PKtla5SgKdjFtzg/ZLLs0qzGAyErIsWI1lva6upt175HDyFx6mg+QkSYPLmi9NL+8RUUPlRtj; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 24262 invoked from network); 1 Nov 2010 18:23:01 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Nov 2010 18:23:00 +0100 Message-ID: <4CCEF776.8000206@gondrom.org> Date: Mon, 01 Nov 2010 17:23:02 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: websec@ietf.org References: <4CCA01A5.4030608@KingsMountain.com> In-Reply-To: <4CCA01A5.4030608@KingsMountain.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] WEBSEC and The Need for More Than DNSSEC X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 17:23:01 -0000 I agree with Jeff in that this is out of scope of the current websec charter, especially as it fits nicely with the frame of NEA's charter: http://datatracker.ietf.org/wg/nea/charter/ Kind regards, Tobias chair of websec On 10/29/2010 12:05 AM, =JeffH wrote: > > Some minimal standard of > > compliance, such as the use of digital signatures for the core > > components of the browser or server software might represent WEBSEC > > level one (1) compliance. > > ... > > The use of digital signatures in establishing the integrity of the > > two sides of the client-server relationship > > This is entirely out-of-scope for the websec wg. You should perhaps go > investigate the work occuring in the NEA (network endpoint assessment) > working group . > > Our chartered scope for websec is HTTP applications security (modulo > some scope restrictions), in a protocol-specific on-the-wire sense. > > =JeffH > > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Mon Nov 1 11:04:51 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763F03A6A55 for ; Mon, 1 Nov 2010 11:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.093 X-Spam-Level: X-Spam-Status: No, score=-94.093 tagged_above=-999 required=5 tests=[AWL=-2.603, BAYES_40=-0.185, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYwkEuXCe5gv for ; Mon, 1 Nov 2010 11:04:50 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id F3E103A6A51 for ; Mon, 1 Nov 2010 11:04:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=oJ2yxui/fMVR1ulat86IyvVcI99OPeLkd/Sv4EBPWCN2v+GgMlOl843F/mIE2ytyCVOJpaMRFuZF6io5C20CihqTOcAts/UAO2V5fVmaLBGriJ5Z6l2ltxt/Queg3yum; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 20346 invoked from network); 1 Nov 2010 19:04:19 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Nov 2010 19:04:19 +0100 Message-ID: <4CCF0125.3010709@gondrom.org> Date: Mon, 01 Nov 2010 18:04:21 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: websec X-Enigmail-Version: 1.1.1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [websec] Draft agenda for Beijing is uploaded X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 18:04:51 -0000 http://www.ietf.org/proceedings/79/agenda/websec.txt

Please let me know if there is anything that should go in here that is currently not.

Tobias

From hannes.tschofenig@gmx.net Mon Nov 1 11:31:11 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E8F28C0EC for ; Mon, 1 Nov 2010 11:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.699 X-Spam-Level: X-Spam-Status: No, score=-97.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MANGLED_WRLDWD=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfPCj+wxKftj for ; Mon, 1 Nov 2010 11:31:10 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 21CEB3A6A2C for ; Mon, 1 Nov 2010 11:31:09 -0700 (PDT) Received: (qmail invoked by alias); 01 Nov 2010 18:31:10 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.7]) [88.115.222.204] by mail.gmx.net (mp005) with SMTP; 01 Nov 2010 19:31:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Pa9tXpTCPn1JckUJYjyZDflHgpFvD+tGwSEFr1t co28c3hp0e/tkR Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1081) From: Hannes Tschofenig Date: Mon, 1 Nov 2010 20:31:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78CAF048-A16E-4A13-94E9-488CB4FBAA43@gmx.net> References: <20100920210002.96EF53A6876@core3.amsl.com> To: websec@ietf.org X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Subject: [websec] Reminder: Internet Privacy Workshop: 8 and 9 December 2010 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 18:31:11 -0000 Hey guys,=20 Tobias dropped me a note to remind you about the upcoming privacy = workshop. The deadline for submitting a short (1-2 page position paper = is this weekend).=20 I can imagine that someone of you has ideas about how to improve privacy = on the Internet.=20 Ciao Hannes Begin forwarded message: > From: IETF Secretariat > Date: September 21, 2010 12:00:02 AM GMT+03:00 > To: ietf-announce@ietf.org > Subject: Internet Privacy Workshop: 8 and 9 December 2010=20 >=20 > The Internet Architecture Board (IAB), World Wide Web Consortium = (W3C), > Internet Society (ISOC) and Massachusetts Institute of Technology = (MIT) > will hold a joint Internet privacy workshop on 8 and 9 December 2010 = at > MIT, Cambridge, Massachusetts on the question: >=20 > "How Can Technology Help to Improve Privacy on the Internet?" >=20 > Information about who we are, what we own, what we have experienced, = how > we behave, where we are located, and how we can be reached are among = the > most personal pieces of information about us. This information is > increasingly being made more easily available electronically via the > Internet, often without the consent of the subject. >=20 > The question for the workshop therefore is: How can we ensure that > architectures and technologies for the Internet, including the World > Wide Web, are developed in ways that respects users=82 intentions = about > their privacy? >=20 > This workshop aims to explore the experience and approaches taken by > developers of Internet including Web technology, when designing = privacy > into these protocols and architectures. Engineers know that many = design > considerations need to be taken into account when developing = solutions. > Balancing between the conflicting goals of openness, privacy, = economics, > and security is often difficult, as illustrated by Clark, et al. in > "Tussle in Cyberspace: Defining Tomorrow's Internet", see > http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf >=20 > As a member of the technical community, we invite you to share your > experiences by participating in this important workshop. Workshop > participants will focus on the core privacy challenges, the approaches > taken to deal with them, and the status of the work in the field. The > objective is to draw a relationship with other application areas and > other privacy work in an effort to discuss how specific approaches can > be generalized. >=20 > Interested parties must submit a brief contribution describing their > work or approach as it relates to the workshop theme. We welcome > visionary ideas for how to tackle Internet privacy problems, as well = as > write-ups of existing concepts, deployed technologies, and > lessons-learned from successful or failed attempts at deploying = privacy > technologies. Contributions are not required to be original in = content. >=20 > Submitters of accepted position papers will be invited to the = workshop. > The workshop will be structured as a series of working sessions, > punctuated by invited speakers, who will present relevant background > information or controversial ideas that will motivate participants to > reach a deeper understanding of the subject. The organizing committee > may ask submitters of particularly topical papers to present their = ideas > and experiences to the workshop. >=20 > We will publish submitted position papers and slides together with a > summary report of the workshop. >=20 > There are no plans for any remote participation in this workshop. >=20 > To be invited to the workshop, please submit position papers to > privacy@iab.org by November, 5th 2010. >=20 > More detailed information about the workshop, including further = details > about the position paper requirements, is available at: > http://www.iab.org/about/workshops/privacy/ >=20 > We look forward to your input, > Bernard Aboba (IAB), Trent Adams (ISOC), Daniel Appelquist (W3C), = Karen > O'Donoghue (ISOC), Jon Peterson (IAB), Thomas Roessler (W3C), Karen > Sollins (MIT), Hannes Tschofenig (IAB) > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From thassloc@adobe.com Mon Nov 1 13:46:04 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0120A3A6A76 for ; Mon, 1 Nov 2010 13:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQsu7Ib6lfsc for ; Mon, 1 Nov 2010 13:46:00 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by core3.amsl.com (Postfix) with ESMTP id 3030F3A6A3E for ; Mon, 1 Nov 2010 13:45:59 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTM8nCEpAmkYQFavmSkqmtfwkLZQB+x7n@postini.com; Mon, 01 Nov 2010 13:46:02 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oA1KjkXJ003003; Mon, 1 Nov 2010 13:45:47 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oA1Kjxtm010583; Mon, 1 Nov 2010 13:45:59 -0700 (PDT) Received: from nambx07.corp.adobe.com ([10.8.189.232]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Mon, 1 Nov 2010 13:45:58 -0700 From: Travis Hassloch To: Marsh Ray , Sam Caldwell Date: Mon, 1 Nov 2010 13:45:57 -0700 Thread-Topic: [websec] WEBSEC and The Need for More Than DNSSEC Thread-Index: Act1NvTwT0Xkc6/USEuIZO3e+cUTRwEztO1F Message-ID: In-Reply-To: <4CC715FA.9040602@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] WEBSEC and The Need for More Than DNSSEC X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 20:46:04 -0000 On 10/26/10 10:55 AM, "Marsh Ray" wrote: > I don't like where this is going. > What's a "web browser"? A: Two echoes and a netcat. > There have been innumerable code-signing schemes proposed and deployed > over the years and I doubt any of them have increased security one bit. http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc2= 7 .3 > In your vision of the secure web, everyone will be required to be > running an approved, "compliant" browser and register their computer > with some central authority. http://xkcd.com/129/ > But you didn't explain how this grand scheme of "compliance" is going to > prevent any of the current real-world security holes: >=20 > Q: What will it do about Adobe PDF and Flash plugins that come > preinstalled with dozens of exploitable security holes? It will distract me from fixing them :-) Sorry, I couldn't resist this chance to introduce myself. I'm on the Flash security team (not responsible for Acro*). I'm tasked wit= h implementing many of the HTTP-related security headers. I'm thinking that S-T-S, C-S-P and nosniff might be the most important. If anyone thinks tha= t others might be more apropos, please email me off-list; I'm trying to set priorities without having had time to become an expert on them. I'm also looking for information on current status; we don't want to be the weak lin= k in deploying them, but it's important to not pass on one that's currently deployed in order to implement one that will have only latent value. Security is gaining increasing importance here, despite not being a (for lack of a better word) flashy kind of thing you can demonstrate on-stage at developer conferences. > Q: What will it do to support individual privacy, anonymity, and control > the leakage of their personal data and prevent > marketers/credit bureaus/insurers/governments/attackers from tracking > their every movement online? http://knowyourmeme.com/memes/i-for-one-welcome-our-new-overlords BTW, Barth, typo: http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=3Ddraft-abarth-or= igi n The first instance of "principal" lacks an r. Thanks! --=20 Travis Hassloch Flash Player Security Engineer From ietf@adambarth.com Mon Nov 1 13:54:08 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1DDE3A6A79 for ; Mon, 1 Nov 2010 13:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-4.577, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3a8p4Ph9Nr2 for ; Mon, 1 Nov 2010 13:54:08 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 028B13A6A75 for ; Mon, 1 Nov 2010 13:54:07 -0700 (PDT) Received: by vws3 with SMTP id 3so4175626vws.31 for ; Mon, 01 Nov 2010 13:54:10 -0700 (PDT) Received: by 10.224.179.70 with SMTP id bp6mr8617486qab.364.1288644849883; Mon, 01 Nov 2010 13:54:09 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id s34sm5397209qcp.8.2010.11.01.13.54.06 (version=SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 13:54:08 -0700 (PDT) Received: by iwn40 with SMTP id 40so7923686iwn.31 for ; Mon, 01 Nov 2010 13:54:05 -0700 (PDT) Received: by 10.231.36.77 with SMTP id s13mr13973255ibd.190.1288644845682; Mon, 01 Nov 2010 13:54:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.158.139 with HTTP; Mon, 1 Nov 2010 13:53:35 -0700 (PDT) In-Reply-To: References: <4CC715FA.9040602@extendedsubset.com> From: Adam Barth Date: Mon, 1 Nov 2010 13:53:35 -0700 Message-ID: To: Travis Hassloch Content-Type: text/plain; charset=ISO-8859-1 Cc: Sam Caldwell , "websec@ietf.org" Subject: Re: [websec] WEBSEC and The Need for More Than DNSSEC X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 20:54:08 -0000 On Mon, Nov 1, 2010 at 1:45 PM, Travis Hassloch wrote: > BTW, Barth, typo: > http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-abarth-origin > The first instance of "principal" lacks an r. Yeah, that one is pretty embarrassing. I've fixed it locally. Thanks. Adam From hannes.tschofenig@gmx.net Sat Nov 6 19:55:40 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61BA83A69B5 for ; Sat, 6 Nov 2010 19:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGv0AL-Fmb-p for ; Sat, 6 Nov 2010 19:55:40 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id C1A123A69A7 for ; Sat, 6 Nov 2010 19:55:39 -0700 (PDT) Received: (qmail invoked by alias); 07 Nov 2010 02:55:55 -0000 Received: from dhcp-7730.meeting.ietf.org (EHLO dhcp-7730.meeting.ietf.org) [130.129.119.48] by mail.gmx.net (mp004) with SMTP; 07 Nov 2010 03:55:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/HGxcEln7HD7kC3yrGPX9JwkQV+wLZI98YvG2GyV vSQFa8TCQhZ1ar Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1081) From: Hannes Tschofenig Date: Sat, 6 Nov 2010 21:55:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net> To: websec@ietf.org X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Subject: [websec] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 02:55:40 -0000 Hi all,=20 please consider attending the following two meetings!=20 ** OAuth Security Session ** =95 Date: Monday, 13:00-15:00 =95 Location: IAB breakout room (Jade 2) =95 Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The security consideration section of OAuth 2.0 (draft -10) is still = empty. Hence, we would like to put some time aside to discuss what = security threats, requirements, and countermeasures need to be = described. We will use the Monday, November 8, 1300-1500 slot to have a = discussion session. As a starting point I suggest to look at the following documents: =95 = http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations =95 http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy =95 = http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt Note: If you are unfamiliar with OAuth then the OAuth tutorial session = might be more suitable for you! ** OAuth Tutorial ** =95 Date: Wednesday, 19:30 (after the plenary) =95 Location: IAB breakout room (Jade 2) =95 Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth allows a user to grant a third-party Web site or application = access to their resources, without necessarily revealing their = credentials, or even their identity. The OAuth working group, = seehttp://datatracker.ietf.org/wg/oauth/charter/, is currently trying to = finalize their main specification, namely OAuth v2: = http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ Based on the positive response at the last IETF meeting (in Maastricht) = we decided to hold another OAuth tutorial, namely on *Wednesday, = starting at 19:30 (after the IETF Operations and Administration Plenary) = till about 21:00. (Note: I had to switch the day because of the social = event!) It is helpful to read through the documents available int he working = group but not required. Up-to-date information can be found here: = http://www.ietf.org/registration/MeetingWiki/wiki/79bofs Ciao Hannes From hannes.tschofenig@gmx.net Sat Nov 6 19:49:07 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C181D3A697B for ; Sat, 6 Nov 2010 19:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71FQZ94THeLO for ; Sat, 6 Nov 2010 19:49:06 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id A020C3A69A1 for ; Sat, 6 Nov 2010 19:49:05 -0700 (PDT) Received: (qmail invoked by alias); 07 Nov 2010 02:22:41 -0000 Received: from dhcp-7730.meeting.ietf.org (EHLO dhcp-7730.meeting.ietf.org) [130.129.119.48] by mail.gmx.net (mp054) with SMTP; 07 Nov 2010 03:22:41 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19n/CxaxKRnPOLWqdig6r/No3Jvg6FTHRPuMNzUOR hWWFzgaMPScol0 From: Hannes Tschofenig Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sat, 6 Nov 2010 21:22:33 -0500 Message-Id: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net> To: ietf@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Sat, 06 Nov 2010 21:50:40 -0700 Cc: abfab@ietf.org, rai@ietf.org, secdir@ietf.org, websec@ietf.org, xmpp@ietf.org, kitten@ietf.org, "iab@iab.org Board" , iesg@ietf.org, oauth@ietf.org Subject: [websec] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 02:49:08 -0000 Hi all,=20 please consider attending the following two meetings!=20 ** OAuth Security Session ** =95 Date: Monday, 13:00-15:00 =95 Location: IAB breakout room (Jade 2) =95 Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The security consideration section of OAuth 2.0 (draft -10) is still = empty. Hence, we would like to put some time aside to discuss what = security threats, requirements, and countermeasures need to be = described. We will use the Monday, November 8, 1300-1500 slot to have a = discussion session. As a starting point I suggest to look at the following documents: =95 = http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations =95 http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy =95 = http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt Note: If you are unfamiliar with OAuth then the OAuth tutorial session = might be more suitable for you! ** OAuth Tutorial ** =95 Date: Wednesday, 19:30 (after the plenary) =95 Location: IAB breakout room (Jade 2) =95 Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth allows a user to grant a third-party Web site or application = access to their resources, without necessarily revealing their = credentials, or even their identity. The OAuth working group, see = http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to = finalize their main specification, namely OAuth v2: = http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ Based on the positive response at the last IETF meeting (in Maastricht) = we decided to hold another OAuth tutorial, namely on *Wednesday, = starting at 19:30 (after the IETF Operations and Administration Plenary) = till about 21:00. (Note: I had to switch the day because of the social = event!) It is helpful to read through the documents available int he working = group but not required. Up-to-date information can be found here: = http://www.ietf.org/registration/MeetingWiki/wiki/79bofs Ciao Hannes From torsten@lodderstedt.net Sun Nov 7 15:04:07 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A981F28C11F; Sun, 7 Nov 2010 15:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwtw++ocQDAp; Sun, 7 Nov 2010 15:04:06 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by core3.amsl.com (Postfix) with ESMTP id 89E1A3A6919; Sun, 7 Nov 2010 15:04:06 -0800 (PST) Received: from [79.253.37.94] (helo=[192.168.71.43]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PFEHg-0007pK-9T; Mon, 08 Nov 2010 00:04:24 +0100 Message-ID: <4CD73075.8050408@lodderstedt.net> Date: Mon, 08 Nov 2010 00:04:21 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hannes Tschofenig References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net> In-Reply-To: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de X-Mailman-Approved-At: Sun, 07 Nov 2010 23:15:31 -0800 Cc: abfab@ietf.org, rai@ietf.org, ietf@ietf.org, secdir@ietf.org, websec@ietf.org, xmpp@ietf.org, kitten@ietf.org, "iab@iab.org Board" , iesg@ietf.org, Mark Mcgloin , oauth@ietf.org Subject: Re: [websec] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 23:04:07 -0000 Hi all, Mark McGloin and me have been working on OAuth 2.0 security considerations for a couple of weeks now. Since we both cannot attend the IETF-79 meetings, we would like to provide the WG with information regarding the current status of our work. I therefore uploaded a _preliminary_ version of our working document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf. The focus of this version was on consolidating previous work as well as results of mailing list discussions and start working towards a rigorous threat model. Please give us feedback. regards, Torsten. Am 07.11.2010 03:22, schrieb Hannes Tschofenig: > Hi all, > > please consider attending the following two meetings! > > ** OAuth Security Session ** > > • Date: Monday, 13:00-15:00 > • Location: IAB breakout room (Jade 2) > • Contact: Hannes Tschofenig hannes.tschofenig@gmx.net > The security consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we would like to put some time aside to discuss what security threats, requirements, and countermeasures need to be described. We will use the Monday, November 8, 1300-1500 slot to have a discussion session. > > As a starting point I suggest to look at the following documents: > > • http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations > • http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy > • http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt > > Note: If you are unfamiliar with OAuth then the OAuth tutorial session might be more suitable for you! > > > > ** OAuth Tutorial ** > > • Date: Wednesday, 19:30 (after the plenary) > • Location: IAB breakout room (Jade 2) > • Contact: Hannes Tschofenig hannes.tschofenig@gmx.net > OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. The OAuth working group, see http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to finalize their main specification, namely OAuth v2: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ > > Based on the positive response at the last IETF meeting (in Maastricht) we decided to hold another OAuth tutorial, namely on *Wednesday, starting at 19:30 (after the IETF Operations and Administration Plenary) till about 21:00. (Note: I had to switch the day because of the social event!) > > It is helpful to read through the documents available int he working group but not required. > > Up-to-date information can be found here: http://www.ietf.org/registration/MeetingWiki/wiki/79bofs > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From tobias.gondrom@gondrom.org Mon Nov 8 03:53:10 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08F73A69BB for ; Mon, 8 Nov 2010 03:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.904 X-Spam-Level: X-Spam-Status: No, score=-93.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erXpYA2rwNXz for ; Mon, 8 Nov 2010 03:53:08 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 64D0F3A69B4 for ; Mon, 8 Nov 2010 03:53:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=MKbXblQLVwCJyhM+qiCAy+THqnvLBBNXDPy8Xh2Yept55+1evRN7JH0/iMH8UJULSJ+gq3Jp9rBb/EQnv535VW669Mo6q3VtD4GogKI8FUBFY7ZgekK0sOwYzpE7dhaI; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 11948 invoked from network); 8 Nov 2010 12:52:03 +0100 Received: from dhcp-45ee.meeting.ietf.org (HELO seraphim.heaven) (130.129.69.238) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Nov 2010 12:52:02 +0100 Message-ID: <4CD7E45E.4030506@gondrom.org> Date: Mon, 08 Nov 2010 11:51:58 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 SUSE/3.1.6 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: websec X-Enigmail-Version: 1.1.1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [websec] agenda and slides for meeting tomorrow 13:00-15:00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 11:53:10 -0000 Hi dear websec fellows,

if you are remote participating - just fyi:
Agenda: http://www.ietf.org/proceedings/79/agenda/websec.txt
all slides are on the meeting material manager:
https://datatracker.ietf.org/meeting/79/materials.html

the WG charter: https://datatracker.ietf.org/wg/websec/charter/
Live Audio stream: http://videolab.uoregon.edu/events/ietf/ietf797.m3u
Jabber: websec@jabber.ietf.org  (to submit comments during meeting)

And if you have some minutes to spare: Under #5 I will give a short presentation on behalf of Phillip. But he also prepared a longer 12 minute youtube video (which I will not show) in case you want to watch it:
http://www.youtube.com/watch?v=2zmJCfUx6Uc

Many greetings and cu tomorrow,

Tobias (chair of websec)



Ps.: and for easy access agenda below again:
Tuesday, November 9, 2010                   1300-1500, Valley Ballroom B
=========================================================================
CHAIR: Tobias Gondrom <tobias.gondrom@gondrom.org>

AGENDA:
1. Administrativia, Blue sheets - 3 minutes
2. WG Status, draft status - Tobias - 10 Min
- Sniffing,
- Web Origin Concept
- X-FRAME-OPTIONS
3. draft-hodges-strict-transport-sec - Jeff 10 Minutes
4. DNSSEC for strict security - Presentation - Paul 15 Min
5. DNSSEC for strict security - Phillip (Tobias on behalf of) 0-10 Minutes
6. DNSSEC for strict security - Discussion 15 Minutes
7. Requirements - Jeff - 15 minutes
8. open discussion about requirements and next steps - 30 minutes
9. other topics / open mike - 10 Minutes

From ietf@adambarth.com Mon Nov 8 12:00:41 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351A928C0E6 for ; Mon, 8 Nov 2010 12:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.16 X-Spam-Level: X-Spam-Status: No, score=-4.16 tagged_above=-999 required=5 tests=[AWL=-2.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZe4YxUKWar8 for ; Mon, 8 Nov 2010 12:00:40 -0800 (PST) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id DA67A28C0FD for ; Mon, 8 Nov 2010 12:00:21 -0800 (PST) Received: by pxi6 with SMTP id 6so1368771pxi.31 for ; Mon, 08 Nov 2010 12:00:44 -0800 (PST) Received: by 10.229.240.144 with SMTP id la16mr3235028qcb.50.1289246443362; Mon, 08 Nov 2010 12:00:43 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id x45sm183645yhc.45.2010.11.08.12.00.41 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 12:00:42 -0800 (PST) Received: by ywp6 with SMTP id 6so4025379ywp.31 for ; Mon, 08 Nov 2010 12:00:40 -0800 (PST) Received: by 10.42.165.71 with SMTP id j7mr1934593icy.529.1289246440703; Mon, 08 Nov 2010 12:00:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.158.139 with HTTP; Mon, 8 Nov 2010 12:00:08 -0800 (PST) In-Reply-To: <4CD7E45E.4030506@gondrom.org> References: <4CD7E45E.4030506@gondrom.org> From: Adam Barth Date: Mon, 8 Nov 2010 12:00:08 -0800 Message-ID: To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] agenda and slides for meeting tomorrow 13:00-15:00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 20:00:41 -0000 On Mon, Nov 8, 2010 at 3:51 AM, Tobias Gondrom wrote: > And if you have some minutes to spare: Under #5 I will give a short > presentation on behalf of Phillip. But he also prepared a longer 12 minute > youtube video (which I will not show) in case you want to watch it: > http://www.youtube.com/watch?v=2zmJCfUx6Uc I'd just like to say that I found this video very helpful. Thanks Phillip. Adam From Jeff.Hodges@KingsMountain.com Mon Nov 8 18:26:25 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BFB28C126 for ; Mon, 8 Nov 2010 18:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.035 X-Spam-Level: X-Spam-Status: No, score=-100.035 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmBrm5zZAE-s for ; Mon, 8 Nov 2010 18:26:24 -0800 (PST) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 1052E28C1E1 for ; Mon, 8 Nov 2010 18:26:15 -0800 (PST) Received: (qmail 18898 invoked by uid 0); 9 Nov 2010 02:26:37 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 9 Nov 2010 02:26:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:X-Identified-User; b=RD2cCLmPQNEVUJAjKZx5l55pCekQ0sRXXbAbhl73/wV4bSJ3pilxgEESBES3jgJRw10qN05LuaOhqv6Kb+w5ARLgXNUkz4ZlaDgOhFPo4xkaDQVZplcpHF9L0fyiwMWZ; Received: from dhcp-749c.meeting.ietf.org ([130.129.116.156]) by box514.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PFduu-0002PJ-AG for websec@ietf.org; Mon, 08 Nov 2010 19:26:37 -0700 Message-ID: <4CD8B158.7070006@KingsMountain.com> Date: Mon, 08 Nov 2010 18:26:32 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF WebSec WG Content-Type: multipart/mixed; boundary="------------030907040904010606070906" X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.116.156 authed with jeff.hodges+kingsmountain.com} Subject: [websec] new rev of requirements preso X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 02:26:25 -0000 This is a multi-part message in MIME format. --------------030907040904010606070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please see attached. Pls upload to meeting materials when u get change Tobias. thanks, =JeffH --------------030907040904010606070906 Content-Type: application/pdf; name="hodges-ietf-79-websec-requirements.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="hodges-ietf-79-websec-requirements.pdf" JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nJVSTWvDMAy9+1foPEgmyXYcQwi0TXvYrRDYYey2dWNsg/Wy vz9ZjpvSNodhELI+np6ejTXBr/kBhAprCyHaugUfvfjHV3i8g29DkM7xzWBKwJdJRUH9T8i+ 9LJccHZy9t0c7hQ8HUFYj8ZGqXepbHyB+51AOxgPHVI/fpjtaPZX9b72/2kgTIxsCLKIdjBY 6T08pZbKdshqrVqHHpu+ohINfdUWv8WomZXe1upv1A5TT45tcdCK3Rn6hImt3uJcTdhzmUY0 IxNPscIrI/jcS06qnseHmwJRUzdgHdXxYl/yMxdqyn6+TA99003Uc0m7NIIDifwcUD7LxYiY lxZhqC3yLFO1VziMGUdE5o5EiqCYSlL1ppCs5DZKeljCdsjy4Lc4TgJrPw60VZzzx1ot7t02 tQO2rny+EyZjwmTiLKUXrmw15FKA/fyy3ExjvJDzffpYE4PT1D38AVhRwHwKZW5kc3RyZWFt CmVuZG9iagoKMyAwIG9iagozNTEKZW5kb2JqCgo1IDAgb2JqCjw8L0xlbmd0aCA2IDAgUi9G aWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyVlEtr3DAQx+/+FDoH7I5GD0tgBN7s7qG3 gCGH0FvzoLSF5tKv33nItZzNg7Awq9U89NN/RguDNX+7PwZMD4MzY3ZDMiEHWj/fm9sr87uz hj/Pjx2ww/zqOGiU9U+ja8pF+gHbQr1P3cOVFOcPVTgsncsU7zls+W6+nKm0N8vDBLYsP7rT 0t1cxIchfCYBA50OcfAaj8Zz/N0Ep9LbCc5sbZR1LGQyYP3BVtb2xI5D6d2EAJm/yUFbY/m2 fH3tUJ+IzztHqHKqI8rhfc6RhfMYyVZQhwKKSQ/EDAFnQCVjZDdZK1DEDPNbLAmJxaVILVxZ cIjvslgYCcMlWHPQYFKYQwmBtUBWpaflUWgceNFrLH2sqkESS3KhiEc2kGiYFZn105y59H6N 4xbUbuSawpeXUlZ6VUup97w1qe7PtWVOivoiNbmEFpI064uv8Xi9dV5vYtni2uTtTrMmWCg2 iSfUWNp/Q/kqo8/0qPYy6hX18GpzpWT2VxQ4NpKuKOvUbqiqwfXmpcZwSU4MOwHJjev2qW5j S7Fry1pj34SaiE0Xhf/csH4kjh2H/EKc3Y2cWB0UoYgXnbmcthmPzdQdio0T4vbc2/u1F/nM KGt28+8hE13106K2qoMfqoCpefbrSwM5R0+WjtYZUAGE7sWc2N2Y/Mfi53bcAG7MP/C5QXwK ZW5kc3RyZWFtCmVuZG9iagoKNiAwIG9iago1MTIKZW5kb2JqCgo4IDAgb2JqCjw8L0xlbmd0 aCA5IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyVVkuL2zAQvvtX6LwQVzN6 WAZjcF6H3hYMPSy9dbeltIXupX+/85BtOVmHhMBYGc+Mvu/TaBJbg/lX/TXW7GztTNO6OpnQ Blq/v5ovT+ZPBYY/798ryy/M74qDGln/MrqmXKQvdlno2x/V25MU5w9V2I+Vaynec9j4zXw6 U2lvxrfOQj/+rE5j9XwVH+rwSAKmUHsTbCQrGWg8Z7x0eOp30Nmj2Lbfuc4GXuMAsV+7clAS O/Rfx88fbeUTofLOEUDZyRG2+ja6huXyGMlmcA5ncKGzHlvGQbuG/PSMCk4WBd1+QkfrQ4/Z AY4d2BIPfjEQZH5qylAmUhI/93mLIcf7D+I3SCck0i5F6pCJNNbxJmmwDfF1yU45aDBxBgxb GdBQY15nvBDV1dmQRijA1x44TqRpHUWipM/sE5IrT9OnXAigcEsIHhZLpTeUAWgZtPeFNEKT ym7Q9MDCkJ17FXOvEoHYYZPPZ59pkiEXOMaYHXBSsyu/54QjL6M0ljoiM8RJtkjNDpqFQ++L fDxLgEoQlirHBcEsGyM8T2imHajAbZUs24dUohsNFyo5y/iHvHPBU3glJiKXxPfKOS6nSq9a ChIjtDKTUgJVgJJOfZBOQC1abtIuQsk9QmkfEVT7STQpouZ9dphPsYB0UHOHgNjwpH5EQGxs 3V4KqK2uJypawIG4ZryimCoIU6NYNwuKmbQEO1x1jIyjRbXBnvtCJtHbQdKKejDcgFxkOiO+ AYW9LYZLxQy+SwwXeGitxCjvBrjtPWUCosVpht89AaEt5n6eZ86pssvokkGkM07GOaTb5CHa Ask95CE0U+/M5EEhSPs7PV+9ULgcXJ4a7JZ21cswaIcUs6a8E8fLW3M1k8Rx6KFlyw232fki PKCf2vh+4SEVra/C06Wef+cb3jeP/Tw6eNLH4idGWnr9t2ClyjnLNx9bXmvGYaH0bP4D7kIH jAplbmRzdHJlYW0KZW5kb2JqCgo5IDAgb2JqCjcyMQplbmRvYmoKCjExIDAgb2JqCjw8L0xl bmd0aCAxMiAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVZNb9swDL37V+hc IJ5IyrIMGAbsND3sViDADsNuWzcM24D1sr8/fliymrVeig0BFEUSqUe+Ryq+Bfer+em8O/iW XD9Qm1w3dDx//OTe3bgfDTj5PH5uvGy4740c6nX+zdmcbZF/+G1iu1+ahxt1Lh/2sJwbGvh8 kGPnj+7NHbsO7vwwepjOX5vTubn/43zXdq8xQOg4ps7HNpgFuiAW70c8TQcY/a2Og++mA404 TzhCtCVZkOVyKE08zNMBR0LdXIDkV9lWMwryDafpw/ntc4hCYvCBiONQQMQhtPtB9JLVgJHH NQZCjYEM9TAxGIM0KIg7nd/qqNFA9EuOhNeOOl84WEwWpsTFnvqp2HU+VR6XqUsjLnrouI3s HVcDSRuPpMsGANnrC1lIyFmgFFlZOQvYxt0sgO85AZR8tkGHSdMAyhKnATJ5syBQ2MwPHjcS MdMKCjXYVJKn3L6AFmBgFVEIFdykYPElsAEELI9Fd2i6A2IkqHJBEVzS21l2gb9RhIMrbgD5 HRSlLghvaIg5jm41XA+TjxIiShhBdRpWZ3pdzxEqSasDvp+vVwOKYmAHNIlU+fXBwGYzmnRN drAg9TOj1zODYpFb2Osu9z5VFXAl9x6zTeEeVcVyIULBQ71KVLeU/HWU4KzSgbYyz6HVZWzC yeoGDTlvwslKSldi0VMRUeHLEJnDY9Up4qY+LAtk5bbsaxBjrNJ2jQYxkiT3f2nQFPSMHMEE caGdw3PiqbQTTa7rDa+TEJLPHfFqCSGGrYvm9nEUPgQRIvc/nZHp4pR3uNNWi2EkfQf4siD7 u5RB6jIB5BCuoAw0vAuQppdKozibejh3WUimzMKcbj4t40NXqNhUjZvV2jdxU/jqEyu1z5ck l7LZdW0tSdGmrfbsFqa6/2sb1rQAP6DhlaxDwKoPrwl9Sjjaw2UFXj0e1kry34TLFGnlWmCo y1zF+2LwtL0hV4lhGNrhX7WAc3nq1rZly/KPhsg0nPnEKvi6G92737DMKp0KZW5kc3RyZWFt CmVuZG9iagoKMTIgMCBvYmoKNzYwCmVuZG9iagoKMTQgMCBvYmoKPDwvTGVuZ3RoIDE1IDAg Ui9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVUuL3DAMvudX+LwwqSXbiQ3BMM9D bwuBHkpv3W0pbaF76d+vHnYenZ10tgwYjyzLnz7pU2wL5nfzy1izs60zfXJtNCEF2r88mQ8P 5mcDhn8vXxrLB+ZHw0697L8b3dNdpD923ujp1+b5QYLzjyIcxsYl8vfsNn427y4U2pvxebCQ x2/NeWwer/xDG950wUZGB4FWuYHG842PgztYn3cwWJR1b1PeucEG+XeSNeZP4/vXovrYchxX YTiC0W4D6ZkZ7zp2UxwOBQfYjIO98OPQCYQkjx9kDZkMezGLAfa84pERugGTDeDkqidHOM03 8XILfESC7VI3Qce224QOtifsLtmKHKMgR5t3yMzRg0FgayLCKW01G6yYUPKb9ueSH/scM3S8 cgD17/JUmSh5U5Z+HQwW1ZO3oc+xGhZXi7uS2OddV3FoYMFRLGlGQFzq1TC7K+rA5hvcFqpC JN2sydL38Ti3F6ZcCQBH9fNSP1fw/qt+iIvmu7OC0JGQ17Ccm4nGmQ/FUPg4XVVQed0T4X5V a/FxRzYsi6zhtbxacOaSzFvywr6rJN4rL+zt3+JCec6D6utSO3ISVWIgQdXEaVGJtDinTfoR U/tWASG6eQhV+m2W2YNXpF8WzO1L7+OwktpCKdLWxU+jKNtyqPUjF7D1FLjbZLacc33YaeIy AJd7JgQ3CAFI9NmA2NfsiJEofOAtPjyQL0S/4EOHslCBVe1eOotaZlK4L+I4lsbESUVBRbSN MWAdv/di9Im+N2uMNx9nbB0D9tPRzRaXLgISZHhjFwHY2nnzID7kIFPpv8bcJFwletFEy3mt k6tYuqkidX7pt1SSZp9QfBaj97XRV+e6TL8CQifJHG7COTH5aP4AKoza7gplbmRzdHJlYW0K ZW5kb2JqCgoxNSAwIG9iago2NjEKZW5kb2JqCgoxNyAwIG9iago8PC9MZW5ndGggMTggMCBS L0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nJWUTYvcMAyG7/kVPi9Mqg87sSEYMpuZ Q28LgR5Kb91tKW2he+nfrywrOzNNJyUMGMeSrEfS64EW3e/mlwN3gJZdn7iNLqQg+9dn9+HB /WzQld/rlwaKwf1oilOv+++u7iWW5AMum2r92rw86OXlJzcc54aT+PviNn92785ytXfzywCY 52/NaW6eVv6hDXsCkLhNLjDIqhHkfIn4OCDlAw0gKw7IuvcZB+jKAQRdUz7wgD6L7Vi2HNRv Ej9SW/Wr4ejhCCeNm3SNZaUxv2Xx2OXl3FKqQS7/NL//J36fpPc+orTpFp9qpmv8s+4vKQqc II7Q69eoTrWO0TyOmWAgygixRJZ4VOpkt9/h8lEm4JllGIrFMod2exJ9kYan7lIJUx3EY0Eq EGWpXcakpKhFsZbJCijrqX7ZoMZNRI5csPYgct+13V+IFJWLsWZWMu5ru0U1hapyylkUWlB/ WJqo1BYpOumz3JWW/i+mGjLayGoQa9q4XSLvL5HWJVqjJ8uveMQKaUVZSWRzsC4sdagMbSbT dSk2s+nSH4sPEEkfCne5moLozsZ+1WKR8aIAOz6pkh+rUaS6mM1w9zVp8ZJiJcGaiPUB3c6a zjYC+t8cyPd750DyR7aSmqb1cC01q67L3Y2mIFqPg3V3kdAWJqbdmJjWmFWaby+RFrBtXhPX Xd4n9wcwMmQfCmVuZHN0cmVhbQplbmRvYmoKCjE4IDAgb2JqCjUyMAplbmRvYmoKCjIwIDAg b2JqCjw8L0xlbmd0aCAyMSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniclVZN i9swEL37V/i8EFeakWwJjMHOx6G3hUAPpbd2W0pb6F769ztfUrybTTYhIBRpRn7z5s1IrvPt v+Zv69qN67AdMnapjTnS/Plb++mh/dP4ln/P3xvHG+3vho0Gmf9qdU6+QH/caaK7P5qnBzmc f3TCcmwwk31gs+PX9sOBjg7t8Wl0fjr+bPbH5vHMPnbxHgffh65vI0CX1QPawB6fR4zTBka3 mzZ+hMyjizx65HUf3OJBZriy24odTDTMsrxMGxxxdomXlsmnEWjXpdH3cphfHQ/Tl+PHt0AK xtAnIlswIkXVXY8rO0pV6KEEhVCDQgIL2UUGjhTIhAKTwOx1U8Zh2ihI5LhpSDKdZRRzM9xO UPzFmjmoY2bP8iXZ5ojtSAbhJHQCcSH0nDh08DSW0IHn11IKgWP3kaRj0UOS6L3jBBDPm8g4 BHeEERaaauosgYsmVpPKtEh2aMQsO/sSLq3rSn/yw6FESzZpveOFvXIuM1r89fT1ihd2MRnf BSC7RuZV5KhqDDq1M+ZLVHrk2sAhF16IyyRMwiUmYyImcehXTGpxgOp2J0gPjI6mvYXp9gwM KMMkt2t5xYArSd+WV8ThVKolr1v6IPAHQbMUJ3AGBmbjpaqPOdI8ssh704PlgWM5pZ2WZzum su8r+5pLrajbuHe+YL+ReyCe8s3cq5aJBdEc2V0jH/p7Swp6biovqa8dr1JsGtitVkSoB2uh VeZv8Vqt75U1CMK7qKWm4l9RK0Ly8kFWEtocofTynsUdyzLBQzzthnQH/T6lckndnACfoINX CZBiI55LayDBzoClkZctFeudKXgp7XVz07UqwXqUgMGZa8hPgWkCbmFXeQhx1Y9u5AHzWW9H PGlFG+gwpRcy9GktzXPhrvu5krRu07MIsnDg36BA59bpTUigbekdIuR+986tBHHT/U6vqfDq gve4usN3FnZ0ImaWBT857FafSyax3PyLEqN++kQovpfrT7IYhxP2zB3r3RxGoKotKVTskEyI LCd7b8ifzMjiqI8osPYQyzuLA4mcvVW/qY8qelmQ4aLPkVImtDnzchTHfTnVvhJN78aCXfUC QxwUU6oO9azyAnILX0DFSVwOYm3bmX6lKn15EIWTMWNBIAoy+dU9iZLO2E/16cUYMKhqCcul BqnNe31tmlYGqlGNhuFofUQrHAYB2R4bUuBuW2wlRthaFRivgLURmWIMZagfQNsp6dhN50/r mgB7RNegHtv/h9Ot+gplbmRzdHJlYW0KZW5kb2JqCgoyMSAwIG9iago5MzYKZW5kb2JqCgoy MyAwIG9iago8PC9MZW5ndGggMjQgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nJVXy67bNhDd+yu0DmCFHD4kAgIBObYX2QUwkEXQXZsWRVug2fT3O0+K1762Y1xAlxKH8zhz ZoZ2ox/+2/07uGHvxjBMJYzzkErC9Y/fhq8fhn92fqC/H7/vHG0Mf+9IaOL1X4Os8Szgi9sW svvH7vsHVk5/qOFw2YWC8pHELr8OH8+oOg6X74vz9fLn7nTZfbmRT2N65QAkGMuQIOMxPgFD pBPflujrFBaf694vLld8pLoPizvyh0gf1rqHxR3oMzh9kydvA0uu9ZfL5/dMJ0+xpWnMYjmg r+Njb6cJA4vJIerqbAB2FqB679gkujiTF/g/kbP0zs9DhcV7XopYIf/8VLN9gCaJG/DJwsXo CgaPYAR68VEE3CrvKvKp00ymZBlypT0nMMquOLe6BKs5rObXbv9wDzcBAbEqVyBQrkyZP4mT /rS5JS5iLEcMYar7eYuYodCwZOeoWkDP3E3jnDCNYYpGIEwjUEofpNF7jyGEPG+kg5lDEM7A kUjkz+YUginrwmt+UjB+CbyWp5xFwCdjLUaCpBBJKI2Sqj4olUUKdcASJR1R0qsEZlRDZ1T2 iUqmNuGDyBCXGFiidxf1Z5K7g58HgisE6ACcGT64B19MBB8UqxyET2o2uGqOo+GMq4OEioAA MUPKNUvQHCnvzio3SdnU5vtZT7Q90CJqn0kxwiLYcP1Hs0GyZqjTackCIqc5hDpBK0s3MZFR 1KsOsaJphDdZFJnyoGgUMwdb61DMiCuKTfMHFtXaocDRZA2NcGOcBeaHtQG5WKn+dG1Ajk8r Q9bqrpDYsrFPRlXGfWa+duWECWd1CLhSRCM9djInXrcayVZVybqM10Yn6jNZFUHr/KrafEiq GWbMbAhUM/C4KgDml2oCIF1lF05kd2Opso08kCp5B4Imtb5KxCbij12457tBZsCbgy/dCCyP yTEVPhDGjR5O4jxUGVmRntyXtJ44MElt1CGYWaxIFG1erewyTW4q8MgEiHRO8s/nuvR7O6Em 6OtZe2zkrgm2ZhWGfngOSKZbzyuA5HQDiHeVHdpH9bs0+xgC9P6IfzO7iveIJUSOa5VdVmQP KTiDkFFQmPgrnUbGzXgfCcj6rJ+F+7RJbGug4cmGJ3rDPkmP9YbfM7y4SnzI42t14kO46YNh 5dLNXUMJN4UjHJ+N/61hl65nXrXwrlpSTTomeamnRLH0nLW3y42DT2qre6UalXhdRQboxtbd lq0Auel6TKCaSacgPlPanNqzV7NNEp5EMg3vN4k71gNaL+9ZZ+/z1prhbXANLpnx6xarzeEi 9p9xCe9x00tUmvztRHXaDMAgKR3yebtBcASxvhUAKiqbDpjewA3cVz1qt5t+Vs9tU28b8Oai U7a5aGRuUPnthvOsLcVoTebnuhL+CvPXXdpXGcTaMIBv34F/RkgH5+ZBUkFjQKGVG5a2nNZn 0LoH+pVWemHtuNz9GTkkXovqy/A/Lr4r8AplbmRzdHJlYW0KZW5kb2JqCgoyNCAwIG9iagox MTA2CmVuZG9iagoKMjYgMCBvYmoKPDwvTGVuZ3RoIDI3IDAgUi9GaWx0ZXIvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJyVVMGK3DAMvecrfF6Y1JJsJ4ZgSDYzh94WAj2U3tptKbuF7qW/X1lS MpndzpQloGgs6fnpSRnfgvvT/HbeHXxLrsvU9i7myP7LN/fpzv1qwNXn5Xvja8A9NzWpE//J qc+1yD/82dHoj+bxTsDrwwjT0lDm/FDTlq/uw4mhg1seBw9l+dkcl+bhTX5s43sKoKc2uehT G7QCXagVn4cApYMBUoHBp3JgG8XOYoPYsRxw8BN689RqDDWD+E2cAyQxre7FZpJMOJYvy8d/ kQs99xGIuCXhRtxNe7ufrgocMLG1dgilHR9R70Z7T9XSsbKC4OfKuvK8xgVyx1PeIYcNGaRS +yTGuYKA6QqzSdVY1aX1JFQ9N2Q5g2Sx/hyBrqS15CTHCjIa5K6Ay7ty6K2QcBdHON0WQJSl 7HnjL/nrFBWY16WCRMyFhlVwuSsxSYtKJt5XH7OGOZXHQDv2kqTQFzxzwUuV7F7oX2tl7Z98 NB1VQVFLAWStoYf55gJS6N67gMRf4OsxqxqmSSw07FmZLzsIuk+zKmRdxNpnNAVZNa26F5vO kuh095DbebwUZ1SgyiOa8PvwbNiTfaFbfJ1bWbH540H7gxBMW4f/7JEPb/bI+kUbDa4cd8dG NG8a4mj54/m6B/cXUvQ1cAplbmRzdHJlYW0KZW5kb2JqCgoyNyAwIG9iago0OTAKZW5kb2Jq CgoyOSAwIG9iago8PC9MZW5ndGggMzAgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVh bQp4nJVTyWrDMBC96yt0DsTVzGgzCEE2H3oLGHoovbVpKW2hufT3Oxp5SbeQYngZzyK/90Yx DegP9a6NXpqGdGipidq1juPjg75Z6DcFujzHR2VKQb+q0hQkftE15lnkFzMHtfqkDgs5vDx8 wrpX1HK/LW39vb7q+Gir+0MykPtntevV/ke/a9x/BiBS47UzvrF1ArUtE7fJQg6QwGdIxucl oxPcClrBVV5iMms0Q1Sx1rB2EP8S9wBJrU5HwZakE3b5rr/+jZyNrMMSsSThRqymOa8nFIMt esZBDqHIISc8ttgaV7hQApsLsSqtUOK3ThBHwaYVgl6ysY6xsD/oRmS6FD3fhpEusrln7TeB mVI04wxqjMLX7PJktiBEXkD11bGvhTgmWJVU4LoRmpBwM2MdELOhk8R6XtDQUjOtYHeyuNO8 H3RPVdjywWWzODQib96W/Z+1xtK4lsutocB/sa/WwIa/Dpj5s8grlGiyozBlP/zldvD9m00O 2Y7X8zJn4LsxkwN7/QkGo+RiCmVuZHN0cmVhbQplbmRvYmoKCjMwIDAgb2JqCjM5NAplbmRv YmoKCjMyIDAgb2JqCjw8L0xlbmd0aCAzMyAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3Ry ZWFtCniclZRNi9wwDIbv+RU+L0yqD9uxIQQmm8yht4WBHkpv7baUttC99O9XlpyP2d0ZGAY0 Tiwp7yPJhhbdv+avA3eAll2XuU0u5CDrl2/u04P706Arv5fvDZQN97spTp2ufzlbSyzJA2wL 2/3RPD9o8vKTDOO54Sz+vridv7oPJ0nt3fm5BxzOP5v53Dy98Q9tuCcAE7fRBYittwhyvkR8 7j0OHfYYB+whDgexQe2k1qs9DgfqYSSoK7O2R+bB8s/ig6x7Fp3UZlZPnIcv54/vifNJODyz IKk2Fpr2Nk9XCuwpiq04TIrDQXVMlCEULdyjH4owldINh1RYi0vSzYgnfTL5ul/XCbLGjEs5 lhh7w0CjPh3t+SLrXP2kEmENukKvKJxBRuwSZQ3NJY+JihuGvcFZOONuLwBJf658K5FUmgMs UyCVJpmLm5MDXdHn/TY5lEzfPBi2WIZTnR1re+jxtFSPelYCXdJj2axTo0Mnw+Rr4LGUnJbd ZJl1m24TicZ8LxHgErMSlb5tI73qqiiqh02hypU2ICgR9pSHhVaKsR//XZ59+mjjZydky3kZ eQUaMcsNRTHsqJMy0zVmj8JMkXbMdv6LfC25mAiPtV2HaBi0NWXcRCZ5T5O2c7qqMaTyRQ6l G6Yx325LFzQA5ZZdJIJJHEsJca4l1GqSVo3rcqpj57WivnSD7Pwhvg44koxUt48hu7M05lTH Detb7IZOr0Q7YHRjFCuxTNd9xMBviBnKCRfuEA2jdMkvCiYF5XqQbMTCYpXUSnGqI8kGS0fz tiQLqNXs1vVsXNjl+7iKfc3lvX51XDWaAC29VBoXONOIepFYG43WNtPauaqfrXf16t98jlt8 XN/WEVINu3qCf9cjb26aXhpxeTKf3H81BcDeCmVuZHN0cmVhbQplbmRvYmoKCjMzIDAgb2Jq CjY3MQplbmRvYmoKCjM1IDAgb2JqCjw8L0xlbmd0aCAzNiAwIFIvRmlsdGVyL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCniclZNNSwMxEIbv+ytyFjZOZpJsAktgt3YP3goLHsSbVhEV7MW/72SS bWu1BVmYJpP5ePJOCtqor+ZTgWpBk+oi6aBcdLzePam7K/XRGJW/3XMD+UC9Nzmok/WbKmvO Rd7AYVFOX5rtlRTPH1cY54Yix9scNj+q64lLWzVvezBpfm3Wc7P5Fe+0+08CYqejcuC1LRmo bM64780qtaaHm2xNJ+sxtdRDLD4YyaUWe/A1jsNIHCgOsWbNbpzSw3z7V3cbGNQSMbM0J8bV l4G7rKBFz7byEhZeFDprpvxbLBTfULgTs7kMz5uQLcpF2J7BC8h4FDyPd8FD7S/iGeiYjAIs OagwCB9kKap0QbShKi6rZjNe1m7MFoFRkQQxJFO9sKpy78vwVPxyyOmuh0n8LocM9WCQ6mUm Q925ExSyRxlYBu8XAeWkBEs2YVpAwUrXoYbtSXCpPp6TtupkI/+jTnQaagUnAOWOVgYVZbLl vck0UdpLW35ph6tXSe3lS+NB8XIYj56v/9Gr+Pd32ahvHpfcugplbmRzdHJlYW0KZW5kb2Jq CgozNiAwIG9iago0MDIKZW5kb2JqCgozOSAwIG9iago8PC9MZW5ndGggNDAgMCBSL0ZpbHRl ci9GbGF0ZURlY29kZS9MZW5ndGgxIDE4MTI+PgpzdHJlYW0KeJzllM1rXFUYxp9z780k1TbJ xGi6KPGMVZsujJmKtULRlmJKobWQTEcrQbm5npm5zf3K/ZBMENLBpQiCu1ptpkUIoiC4cOPC RXcVEVx2URC3CkVdiE3jc2fOTEIN+Ad4hzn3977vc97zno970jhTeAiXYUI6vh2NC2EA+AIQ Y847qVxE/ojv2Fh1r1n7vLTh0r5J+92Gst/++Y27hwDjBO2jDTre23xtkPYK7ScbfrqysPXD MO2rtPd6oWPPYYZobLAZ8u2VqIjTuf0VGxnYvhra+PJ72j9yuINRmKTjuLQFFP7I43kh/OXP XmIhtw38759FGGgBZqtQ4y5y9Z8rlopPlYqllonNNQP3Uaj9daU1UOPa3QEG1qx17ANK8tDT oy8cLcmJx0YHC+Yz9+9eW1+/JkbEvhvXr99orxuT6+12e/OXdhti6564ZYXGm8wPs/R8ybKS vz8Qtz4COvshDkz9Vvvw9bdGjv+Jh4c6Rd2s/l7tFbh1Lx+V1XHP0dsw9husbq7tmId4YF6m BbQKC7hjxXkGjPPovNRRmRjWeQz0zsSJfr8nxKf9XJP9vIKnfFKzwVWa0mzS/6xmi/yi5gGe sVOaC/Sf7zKb/bioWWAPljUbKGJVs4lRvN9dmY7+Y825/mvNBh7Ht5pNjOF2hw02JfyqmXox rNnAhJjQbKIoprsrweZR8bJmgSFR0cx6xIJmE48Iv8MWmwPisuY8/1XNBsbEZ5pNar7hyghr D+3j4ifNAuPGiGYDw8ZBzSb9Zc0W+RXNA9hvXNRcoH95yjksj8zMHJPzWSDPuU4cJs0kVX4i zwTO9PlIBfNNfzH05lQ98+x427FNVRUnbhjI8nS5vO096Xmy0ozCemxHDdeRs8pOs1glZ916 F7RA9SOnQt9nmr5gNgyclIkTmfbzLGc7MlTCLFWJrP2XTl5IMuV5nSFVT1RzE6ehOOcrdc91 GkvKTVXQ6xJ0lCezZFUxFmRBPbFjxl8NY99mpK+bzYJVDu3KiquzMulZ1Y1WsjRVkvKeqheQ kfuJ5HSzwP13SXJJBb6Klx6shiLVD51WvlIB5XYUKc+9tLSjJn5IDg7zcj7Cz3MGx0jzyBDw fQ4uYzFCJGjyn0LB51viDOMOpvlRRfQF7NFkZJFKD3P01JnBg82+uyl281XpiZnbpZWPXWb2 Mn+7afNbrHMv1Xmn7PL8A+f+Q+gKZW5kc3RyZWFtCmVuZG9iagoKNDAgMCBvYmoKOTAyCmVu ZG9iagoKNDEgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9EQUFBQUEr T3BlblN5bWJvbAovRmxhZ3MgNAovRm9udEJCb3hbLTE3OSAtMzEyIDEwODIgOTE2XS9JdGFs aWNBbmdsZSAwCi9Bc2NlbnQgNzk5Ci9EZXNjZW50IC0yMDAKL0NhcEhlaWdodCA5MTYKL1N0 ZW1WIDgwCi9Gb250RmlsZTIgMzkgMCBSPj4KZW5kb2JqCgo0MiAwIG9iago8PC9MZW5ndGgg MjMwL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF2QQWvEIBCF7/4Kj7uHRWPpTQIl y0IO25am/QFGJ6nQqEzMIf++o7ttoQfFx3vf8BzR9ec++CxeMdoBMp98cAhr3NACH2H2gTWK O2/zXdXbLiYxQeywrxmWPkxRaybeyFsz7vzw5OIIRyZe0AH6MPPDRzeQHraUvmCBkLlkbcsd TDTnatKzWUBU6tQ7sn3eT4T8Bd73BFxV3dyq2OhgTcYCmjAD01K2XF8uLYPg/nnqRoyT/TRI yYaS6rGjrJaqvGXzULl7okwoX/xpxu2GSK3qHmqdUsQH+F1ViqlQ9XwDLOZv6gplbmRzdHJl YW0KZW5kb2JqCgo0MyAwIG9iago8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9CYXNl Rm9udC9EQUFBQUErT3BlblN5bWJvbAovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDIKL1dpZHRo c1s1MDAgNzk0IDU1NSBdCi9Gb250RGVzY3JpcHRvciA0MSAwIFIKL1RvVW5pY29kZSA0MiAw IFIKPj4KZW5kb2JqCgo0NCAwIG9iago8PC9MZW5ndGggNDUgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGgxIDM2NjEyPj4Kc3RyZWFtCnic1Lx5fBRF+jhcVX33dM/03GeSmUwyOSYQ IOeESBohIEI4BRJgJJH7TsIhIAgIAiIquoriBXiCigQIGFBXZFlvFlyvFVdhVzx3o3xXZFch M7+negbE3f2+n9/nff96p9NdT1dXV1c/9dz1dBa0LpyCFLQSMUifNKepecC0MVcjhN5BCNsm LVoQvO/PC04CfBohvsfU5mlzxj5WaEVI1BDi2qbNXjL15WFNLyCkHkboml7TpzRN7t03akFo 9Dnoo3w6VPwmcYuA0JgiOM+ZPmfB4t9nlLFwPpz2P3vepKZ9j7pXIDR2MlzfOKdpcfN0+Rm4 PvYsnAfnNs2ZMvz1Y7chVA/Pi77bPG/+gs2oMInQ6jP0enPrlOZHljzqQ2gN3CN3QR2Gjf4U AHl6ThiW4wVRkk2KarZoVpvd4XS5PV6fP5CRmRUMZYdzciN5+QWF0aJu3Yt79OxVUlpWXlEZ q+pdfVWfGr3v1f36o/8//7hDyAu7j3saedkI8iCU/Ar2r2mZmJH8ml6nJfkWGnekd4R2oF14 BtqFXkFH8Fm4azc6iNrRG8iN+qOH0TJ0L1qHeDQOam5DI2HjoP5e7E22o2K0HWhpOzoGbcei m9Eh5MKe5DdoBbqVeQ/uuhWpKBv1RcPRPHQHHpJciCagU+xqVIGGoLmoGa9M1ifvTN6TfAI9 iQ4ybyS7kAn50CTYjiW/4/6U/DPqBnfch7agU/geaT/S4SkroeUjqBU9yMRZnJyW/BlGEEI3 whhYVIeO4cMkCr1PQV9hD17G9INeHk+2JY9CqwCKo+noQXQIl+GBJMRNSNYljyEXPGMx9LoF 7UUHYOtAL6OTWOHOJp9InkVeVIQGwfu0oz/gw0yia1WihiIasFSAYnBlHvoteh2dwGH8KpnH KVwvTueWJt9HDtQTjYbRPg13fon/SW6GbQXzGjsgeTUyA17upthGv0d/wT5cjIfhMaSAzCOP Mq1IhCf2hG0ymgH4fgB6/wxH8QGikOPM4+yz7AU+I3E6aYYZiaCH0CPoVazCmwbxfHwL/hB/ TvqRieQh8lfmXnYn+0ehCd76ejQH3YGeRf/ENlyJR+DxeDpehtfhu/EWfAyfwF+TvuQ6Mot8 z0xnWpiX2athG8XOZ1dza7nb+a8T9YmjiXcT/0z2Sq5FI4AeVsHo70OPwpsdRMfRx7CdQn/F HDZhM2xBHMKj8U2w3YzvwI/hHXgnboennMB/xd/gf+Af8QWCYOOJn4RINmxh0kpuJPeSh8lx 2E6Qv5OfGDeTzUSZMqaaaWDmwajWMZtg28/8hfWxx9kk4LkXt5nbyu3gnuWOcGd5RbhFROI7 Fx/vKuz6LIES6xObE3sT7cm/ICfMoQ+wkIWqYfRNsM2E+d4MFLcbvYcVwJ0PF+I+eAhgZiKe iVvwYsDkGvwgftIY+/P4JcDSR/h7GLNKAsaYu5MycjUZBtv1ZAppIZvIPaSdfEh+ZgTGxFgY J1PIDGTizBRmAbOE2cy0Me8wnzJ/Zc4zF2FLsjKbxWazETbKDmQnsgvZR9mv2K+4Cdzb3Be8 zM/h1/Id/P8I5UIfYbgwQogLdwkHhPfFRqDO36H96IUreR6fZlYxtcx+dCcpYb3kD+QPQM8T 0WSmjgClkh14PVmO20kOt5jvTXrjoegsGwFcv0a2kvOkN1OHB+NRaCbpmeqNd7DPQFHN/g51 si/Bu/0Bel7MK/hm8j2voL0YkRg88/dMDzbKvI1OMqewwG5Hn7AyduNO8jQzHKjgZbYPV49C zMPoeaYFL0f7SS1I7AviRqDjofgZkAvX4V74X0wSMWQoUFEF8zlajWaRP6FO4OP16H48mZ2G 7kQleBn6Cj0FXFHAzeULeSd+k8xgNxA7bkeE3QlvF8M5mOEcaA2OMw/y35OP0UJ0nJXRZ8xz MPrj5Hmmjj3LjcTTgQOWo7WoJbkKLeHq2T/iaYjBY1Auexqk2zKmFxuCcgVIlQkg0w4Adx8C OdCXqYMaD1DOEKCL0SAhHoTtAZATLFDQDODxsSDF/oDa+etIB5rGmTFIHYTYtxMj0bjkU2hL chqam7wHdQN5sC65DHrcgb5Ad6Ed+NbETagZZQLnfIaHcAPIcW5AshvZQD4mo8jmX88vYDsX e9C3sD2PBqA+3ItoA/sRGoVqkhuTHwB154OE3YJuQNeiM/CW38ETrmEOo5LEULInOYBphvc9 hUYkn05mYRlNT85Gw9BL6EmBQ01CVO/bV6/pc1V176pYZUVZaUmvnj2Ku3crihYW5OdFcnPC 2aFgVmZGwO/zetwup8Nus2oWs6qYZEkUeI5lCEZFteEBjcG2SGMbGwlfc003eh5ugoqmKyoa 24JQNeDXbdqCjUaz4K9b6tBy6r+11FMt9cstsRasRtXdioK14WDbsf7hYAceN6Ie4Dv6hxuC bZ0GXGfAmwxYBTgUghuCtZ7p/YNtuDFY2zZg0fQNtY39obs9JrlfuN8UuVsR2iObADQB1OYO N+/B7j7YAIi7tmoPQaIKg2rzhfvXtnnD/ekI2pjc2qbJbcNH1Nf294dCDd2K2nC/SeEb2lD4 6jZL1GiC+hmPaeP7tQnGY4Iz6Nug24N7ig5v2NihoRsao8rk8OSmCfVtTFMDfYY1Cs/t3+Ze esbzyyl0butXv+7Kq35mQ61nRpCebtiwLti2bUT9lVdD9NjQAH3AvSR3QOOGAfDojYDEwaOC 8DRya0N9G74VHhmkb0LfKvV+U8K1tKZxZrBNCl8dnr5hZiNMjW9DGxq5JLTX59MPJk8jX21w w3X14VBbjT/c0NQ/sMeBNoxcss+rB72/vtKtaI9mTSF2j9mSBhT1SmDK5WsGZDSn0OCRlzGL 6YjCg4Ag2oKTgjCS+jC8UyU9TKlEGyZVQjP4NWC4q20yzMiMNqlf4watitbT+9u4XC0c3PAj AgoId/791zVN6Ro+V/sRUZDSyWVSg+uX4LZotK2wkJKI0A/mFMbYxzgv61a0qIOEw81aEApA HxoOuG1qqCoG9IdCdIJv79DRDXDStnJEfeo8iG7w70V6cbShjTTSK4cvXXGOpldWXrpy+fbG MFByu2H8OtvEyOU/i+ay106vasOu/4fLU1LXB48KDx4xrj5Yu6ExjdvB1/3qLHW98vK1NNRm 71fP+EkaIn7GuApEOeFyY3pSr7SxufDHG0Q9uUMQgSqNGhwc0KY1XpM6Nsih0P/lTR3Js/Qu o/jltvQw26qivz7v/avzXw1P2cDAgEEJDr5u3IYN8q+uAamlHjgoXQDFo+vqQ8F+bWg0cGYu /HUkD1fSvcHfpgPK+tEGQH+pqvTprxr603AD/Ch1disaAIJuw4YB4eCADY0bmjqSK28IB7Xw hoPkCDmyobm28RLhdCQP3e5vG7CxAXA1HVd1QwQbxieHwJoV0NXtBJ/hhQ6yRbcjjj3DIFlg z2DkFXnuDGFeAqUugYnXHXmi2vnqruqh2rnquq5qVAOwdhEOPXuErCFrLhwwqLSLQebwRZ1D F1CQPQzKFex6xO0Cn8GDsvEQ3WIzmbGtPDAua6o4J4u1dST/us/mK4Xy7L7svFIrPc/IK9XS pSVdwvU/7cuIpK5Dey1d0uv6fAByzdcGrg2OMk0IzAm0SovNSyy3yust96s7LR2Wr81fWTSz ogStFofVarFaFMkGVqPPJfOgi1SF80iSy+3zZrrdKJSdSTBBHo/FYhYzI+aH+XgwpzlnZQ6T k+0J4iAwRDzce4cnCmiIUzxo8fPeM55OQIcGG0WKLVYM1dWxYps7hq3u2Dpz9yi3XDvasweO Ry/9UBwoVZdF3RKzaFVWWxXUNeAWqDyIzMnPdJ83Zs32xmywm/VATMt2wJ4FuzOW7qGhxBrq 5QKFygsut8ttDzPdSV4kHLZCdXl5WWkkHNpONhx9Z+lb79Xljx6SPHdk9Nyx3UKD/4K337p5 6P2PJ3pwh4a9seThDzNyc4YuTLTgnms2VpqEroVMScWSgdPX0rkbnPyazWT7gH2QgT7TJ2eh gJOMZuJcXBptmsLM4uZJU0zg2GtYI3m2j7mfHed9Qk9blbdnoK+tztc3MMI2wTsy0GSb42sK LOYXO8+T8x4NvDuL6nYPdzW6ml2MK2DZpG3TiKax/oAsoA7yjC7h++wB1uTWVaB4XcorLG1T serLgrN9uZFSWuoZmeHSHlk4y1Wi5Qh6TmFpllAjDBMYwZtZWpGanmhd15mhWks0er4lWgcz 1Nl1pqYTZide3dVSja22WMwWo5OC4rilFbt5PpyNrBoq6YWsDiHkcpX0KsehCOA0m2euP1T0 3cFvEt9jx58/APfk4tfy3lsnbew6SUYolWNuW7YTj3E/3o6zMAO+QH7is8RPWnD3oen4vrX9 pj9FMXlNYgZzGjCpgQ/xW/0BE4mSQk9vMpgsUfgaZ413sHdT5rZMrtRe6q/J7G/v7x9lH+Wf ZJ/kb8xcmfk+/4HtS/4b5VuPVkCylagzRsqUQWSAMo7MIB8rn3g+d33j/dJ/kVgwqzp8AZNg 5h2AQGR2m0tQrqadsGDNolsaLSstrGWBNecV4bhwSkgK7GWkZWQuCJUO90SjQ8/FW+o6u+It 1VrXOeDymk74sxqYAjzFW1ALtqYwVVpeXtLLXVZixQ6KKkpxgKiiwvtHv5z4ft57N/++5bGu 0HOL5z+1e9HCxxMziNh7KO6OhW2J1U/d+XM/ZtexY797/f0PX6cRmNXJrwE7NNbw8kHko3Pu dJeSoN1FGfysXmBzlEbtOEe0uxRsd5l4JFsDjAmVuHI9br2kvDTpxofd2D3URynDWVpe2uY7 6yPNvm2+Nl/Sx/qUXMm4Ak3PShhJQemEdFpipaHegcOpWIu3RDs1OFCguusMoi9dHYtRGunZ o98S3cdqZtWiEl4QeZETGV5jFT9SRasfoSiOFhauAtwAT4bKADMRIJkya4nV4TZIqJzCTM2y D65/fJhmajdZ544YcWfv9ofbr5kzrGw+uadr3x09B44Yddd6ErtwEihlPSCkGuQllc3L9fgw aZO0TWqTDkunpLOSgKQsqVlaKW1NV52WkpKcBe8EHhRhJJ65GSOe41mZF3I5xG5lt7Ft7GH2 NMsfZs+yBLFB9gScsexQ8dKrt1ZTaV5TXdNp8ATdKVe0ttjLSpwMDH59e3s7+7fjxy842cgF GtpDtwJJvwbUbEWr9d7FdqyxOMyWsv3A4Z/KLmB5ySpKoqTarZKKGBGbAryAYdKk/E0iFrOD dmwn2dZcjC5PCrUzgugEOg0aZKht4NH0pMBcaPFzrTAhBhHGrKk5iSHtzXXm5UcpSbbieIm1 xGnQokApUOCd1lsf6zOjZvz1fa6+uvf1jkw2sr3lmqqn8wbWNLZ2vU/Hvw581AiMP4xeO4ik 5J/0via1NJc9w56R/uL+Ish9wJ0PErcYDEsef1BimHBmgHcGTCb6GmGfV5NP5OJNudtySa7b 7TPnbrJiaweO7/fkbvJjP0C6F5GScC4+gfAmtA2RLFQDHhODvDm5HXjxvtDAS5zWCirkDIiq znPxrqG1U/p/2dIKmqS6GqajTuvUOq1u44XTZGhWHPaIQ7H6sU11+jElvegqKr+il1DgctOD 0xq2lkYoMlIQAACt297rqZmL7s+6+a1Hn9kXntCn+d72+slDVlWxkfuGTryh/tDuA1155JHZ E6vue6LrfrJ38eLhD97d9XEKW8yXgC0Xeke3cwxvJzu0Du1z5iv7Wea8nWcpi/YEBC7R8APa Cc9pT9LDBkWH2eGyBTjAmEuVVbNizjEZrGrC8Gca6qFz76Os6jnrIc2ebZ42z2EP62FIidOV Jg3bf5CGO00W1eeqL/FrJ+hawJlBIDiNKBdvlWRRFmTg1IiVN/uxRbalEVa4ikqxaLzFwBlg C7TnlQhb99jCTxu3D9fk9sJZ18x/mo3cv7u2ua7X8q75ZO3cOX3veafrJRhSTvIfpJDbgtxo 5UEkg14KR0oNGdMXgJVe4EdFlTGDXJoUtci8C8SVRcsGE0i15So4KYi1Um2j0CysFDYJLBKC wjahTTgsnBB44RCZiTy4fM/UFBOcO6N1UlPrDJXGndTAoNLYWlKivZmyKHLdhtAps4ZBFlfA S4WtDip5iOYbUn3D7KI1a/bt32+P5mdu36r1mfIYmbQRC7MTd2zs+k1dkY9yQw1I3z0wvz3w x/pNbLYju0q6VuqfMyZ7SvYy6U5pTc5T9meLjjCq5PZ53D0GF33o5vxkNCFaLyx7JogTpAny BNMEZYI6U5wpzZRnmmYqM9X2SHueJS+Sk5dTUJ4zTm4wTY5Mzl8QXgCm1G/kh5V78u8vuq/H E/JO5fG8J/L3RX4fcWV0gN1jy4yNE/NyFZn1BSNO1tQ9w0ctgkCWt8Y7zDvRu9t73MtbvFne ed5TXjbLe5eXeF8ko8FCQdBM07COiYZPgAmHNUwwtRgcrlJa6plmaynG3SdkzM4gGQGnwAa6 m7J82Jfj1e2eUm8HGb9XyCmEli8EYicKcaGvF70rAtZHY6/DvUhNr5W9SC8NY5yDgjmW7FMI U6YmyNvzksHRUncOeLZ1qEGa1OY4F+1spZPW2QJmRxRorvWM1kWPwNPwB6ztThGsntctM8w5 iiJWzabZNYbPVoN+JOULfsx1g0OmA05D5rAfZYdVRSyQ/Tg/T5L5KOtHWVoGJe0otT9TB6qK ooXRVatWUTqnojxur3CllHReJK87KSstryhP0b6QIntQVrBlEjAnKTXV7LXcdtOyxWW5v3lt y7C+lYV3j1r+8jhrmzJ/xrKZLlexf80r94+Z8dry4x/jqwKzWqf0vyrsye01aNXQgUvys6LX 3DTNM3LCyIpwIMMu55T0XTZh3Naxz1FKs8MsreTeA67Zp2c6JGzxFnt7eHVvs/ch5WF1pyr6 1Hy1zXvYy3op7vN9WaUZosooloCMnSTqsLMMqJGtDuxI2nXWncsihtyDDWGxr2dlqSE05EBW 6SZ41uMe70v4EAqh81gG3wVkRTRaDb6LVg1z1BmnGq8amKmmE7SKMQcOzcpLAi/yhNfAQUBW 3uLHVLuvWoWjLXHUWkI5rKy04hdd43RSbtu7davdt3rRkAn+yl4j+x8/zjy4sWVW6YCxtkfk AY03bLw4FYikP1jSecBjKvKiV/W4TZC9ykD+GnEM3yBO42eIYqlWZatylXlqtcG2wa5azwRu gjRSi9virpGeOdwcabI2xzbHNdlzI3ZKPKeOZ67jrpPHK7OZKdwUebYiuwOsYAUV5cgRKBbs ObmlPQSMBA1kCyP0PEUVE9R7qdkMsDkH6dCEKiaCevooBYOwASuoJRo/HwfAIFsQMPDi1CvR pVHcKOkG7gaJxfEGu1YBOEApYkH2K+y//k/c9vtPsOumv91+KtF5cO+6tXv33bpuL7HjvDsX Jf7Sdexvt+BMrL7z9jvv/v7tt2CWpia/4hYBRWSgDr1xEpmZQYKolzoJNaMFGSvRmoxN6EHu WeZJ9SDTrr6unkBnMn7IsJptGdaMDKaQz7cWBoJZA9UxjrHOMd7p3KyMm2y32x5ktpgfDOzA T5Ad1g/MduRAPs2h+VgCAmZvfswQBnn5Mc2CMOu3ZyqMP5OVtIjlWhQJAnv7styRINgp3sxJ E1J8Xdc5FJAD7JzCipUyLfBYHPRIHFPPgQ1n5wBT2XJKerFpjgJOslG0sO1Hrkr87ovOxEcP 7cb9jvwZF/V+peTIb3Z+PmHOl2sf/yshPb+/8Cqe+8cv8Og9p9/utu2exxLf3/1i4psNL6U1 L11vc6A9B5ELhq2CXZzLljG1zCGVZTqSp/Uct7fULVoVq4PhMLKAwnWYZLB3DV0r4cMSloa6 6Bu7qa51nXWRZtc2V5sr6WJdxPG/2mDOy4Yx1T1QnKOqlurZzhpr7BdNa+bNQq6ZV/xYFS2X TBKQOpiaJFZDxPzKBmm/+fCi5we3L5w1/A4wcrv+cU/8iYe7JpLt624adefyrhdhDF6EhEU0 XoA36v0LUMRaYIt4YqgctF65ZxAaaB1kG+ipR2Ot9baxHu0B8QELXbDlqG0ucrJJUSTVbLGA pWSz0WVbj7MjWb2PQ54gLRWblZb6OKcoBRFHSBAjBwgQDyeKmU6Pw+n02BRJynTaALRZFYsl qFkdmma1SYrocXIWq6YgwjkVjvFoFoskiSIhmHhsNqsViT6wBrW+Eh4BeFTg6IRdRxwecSBI Ccvr7cC370nHDnzeui6fp6vL5+3yGJbf5QiClt5o+CBtjxt7LLaurnt03fKj67p7/rMAib/O rB09Cofqo5egKw94cJtl1OA264hx9XttMphf5ysrG6AyFyoLofIgQjS8hAa3maDGDDX7FJ3T oREQe2s8hEvsYF1WQGGDwl6CwziSBwYxfjRx0+uncnyVMnZ/+8dh4UC3L3+XmPti4u08we1I vMkdulhz/31/y2E+6/Il/v7D7e3M8z8PYOMbg1MGXnicesZrQTJmwXxrIAM+1J/DnGLJ4cq4 Wo6ryWrLIllZ2YGSwNWB5qxNWXyVvdpV7RviGuKLi3G13hJ3Xe+bKc5Wp1vmuub6Dmd9rJx0 n/T+1f5399+9n2eczkpmeYNcsaXY0YOrsejcEMtwbip3MuNH9mdN0ZxmlifIT30T2Rkwmzw5 J0xYM+mmRtNKE2tagK0lqITJJeQwxpvwNtyGz2I2C9fgYeDlezMHXlL6YMODq2wodkM+pDjk ssPcilpC4RQvgHrVUDg7jwFte1li4m5Pt7fuuWF3i574x8svzSKlo+9e9NyTCxc9B+zx413D 7nprfuL7xIeP4M2vjL792NsnXjsGPDIh+RX7N5CaPVBCf3gSM4mdzyxg2dy8MiYW6McMEoZk 1Gb1zxmQN4ppECZkjM2/zW7OVyM5JIfJyy23lIb759YWjwuOCY/OnW2aqc4yT3VM8SwxLVWX WpZrC3Pm565lNphuUzdY7tBuzVmde4+62bLZmZmbY1ZNXCiQkekXBZ5lCI9zc7Khjucy/d3u Akuq04W6aTiIh+NG3Aw443EHbtNzu2Vmuhgus5vkj/iulSKoABf4eoUiNhyxXUcDat6ek8an Be0Z0M2/krWAVYrZc9RSArlLGQEbRhOihk2LvSKTlKTCXdTWBCu49D/sGtZtRMlAU+VEJryg Tnxj+bxnRg2f0Dsxe8SMaTf/497Hf1rLHbLs2tm2PVaJP65fuXTthUdeT/ywBX+kzb1j7NXz +9dOC7ubohWPT5n36uQZ76wy337nqvHDSkpm5ffev2jh8fkLvoF3GA42dCfodx86pg+UFJwV 6Gfv5x5lH+VutDe6HyIPMQ+qT2hP+BRR9cozyQxmJrdQaVZXqk8p+6UD8n5FcSlrlc8JY86e aJlnWWFhLJgavoN6gAQZjhpBIVJP8jQ6iyRksZgQYm0Bk+AJsKaABVtyzNl+6pWYolkgzUDW DAo4c44LmMZ3iNDTX5r2qDvh0JoObx9EmDJ8Z+u5tJEKNqo1VqwBwuNnLiH4Ulis1GZ4l5ew SsmXqd6T8f3zJxP/bP3mtl1/ztrtXTFu/TNPrJl5J77V/cJxnIHl5zBZtXu7f9bs37334ZFb YHyhxAjmOzaCfHjdPksAW6jF/0Qglu8YY9ktM7qqW4glmN+jVKMHQZFsLtVjyzPlKXlquVKu lpm3WE35tnz7Na4GW4O9wTnDNsM+w7mEX6QusS51LHXeqm6wbrRttN/meEDeYXpJe9F6yPGt /JXjR7VL+8mRDGTaQDOAMLfJiPE67PZcm+yAE4tisSq5JtlhMsmgNhTFxDMBrwUFtAApDrwS IIEOUrPfYtdtuqODXKebamy6jUy0vWIjtg589QELzka1fpleslmCJl0PKj2UYQozXEkqRIEW +4phjqCPdn9wGbh1Pq/W1QKSw+fpBLDTo50749XOwOz4PFqnASEPdfWoFljHdY+Ky7WjUHqi ZgAQ8AAV8tXiURDTIKo9MJcvIiX5NTIlv8YpeW3EkR3Jzw5UxOTsipi5I/n1fmfMmo4eN4Au j6KWeBTH7Xl0KivolhbwINl5gU76Ckfvoupr3NYIZ0rMOfJpNDsr+nl7YnbfnB7LxpQmpu3U 8nP8sywZbH7XloWrli0isy68sfvqhlHUzt8B5HkryHQJDdYLQTyI4l0CFgTEsEZ0XRQeDpKg iRCfiZXSQXW594RfguqGCKBRn1Q4PV6t0WWGEmvIGTL2HcynF78gbV3DuUO7ElW7uqiFfS3o kQBwYD6qwBn6nZIqFXpVX2GBWlgYU8udFf6qwkGFcTVeOFOdUdjYY4O6tuBB10O+narzKe8z +Qe8L+Yf9R7P/6Pz03yxvwtnubM80aLC0hgbKxrEXlM0RmyIThVnRBcp65Q3lZ/Un6LWilIz ZrXinFJ3r5DDM7FgXgEpCBSba8x3mbeak2Zuq3m3+XszYzYHGDdlZZfnPkcgIKDaPLlXgDEV NGlNKDeUA36nruXpKKJFgpEekd0RLtIzRo2yLGqqxw7HyLYYjrlzPdnFOa/wx3mSxdeAi9Kz 0uDnc+m4Zee56q4vvqBsfIbGua0Uay2dLSk/85KjSQPdYM7nGi4elZTGvBtOIQ2c5fUh6XAI MLg7HGF4wUxSvA6NmOrJB2fufmng/GvKZp2chktq169YktHmmXvitvXPDNckd/ZLAfcNR+dN 6DVnxvTHIhmrRw949tahq4Y6zKovJ1ee2+2qhhZPy+2D9aZruy8+e+HWqyrxp/kBLb+u+JrG 8cOuuhFogEeIewGkg43s0TWLAxeyBTK51jreeqeVsdIgk5QVKtUCGXk00nJW35WVU8ryimTn /ZLXxrGI5U2SySzaNGRnHEJA9JsywM3JFQrFqLkUlQlVYm9zf2Ygrwt14mBTP8tA67W28ZaR tlnCZHGabQm/VFggHuQPWQ7YfuQvSPkmaz7KV/PM+ZY8W7GjElXYbhTXig8w9ytP4x1khwkk NzrAHzK/wX7Ifyx9zX5t+cp2jv9ZCtgYwxwVOEmWRTBIZc1qBVE3GKxQG1ifg/SpssUc/J1V EIMCyKIomOwcJ5hlRclVzQ5VNYtWiyUqiw64ndqouSkbFREs2FgRRJVZla0yy9hURRFFQQAL lAfBZjYj2XFeU3GjShULo3bgp3U5OEzG8+QVMgHxNFqXhlnxPOsKK7HSM5PG4UaumVvJMRw0 3o/P289PNbjQW3cuHveARQN/YKEC/N/t09QiCrVNbf9X5qkAgovuFKb74LasUfXtalAJkpeS p0EhnUbm5Il21MMStIF3A9Is9WsY3FY6CkSamDyxR+iBjYoQyL4SQ4+JydN7hGCq1ga1mUYt dHTAEqR9ix3JE3uFHrTHvaiSHEo96XLnl+9zG/dZk6f3yUE2iCqvkKXm5PsHbDFUBHtH8v09 9lhKjLZGDUGKDfPYEJ52t2EbM3kMHpx48dDOGrZk58GtZVcd2J1of3FnwUdspOuhM9a3yNyu B94+RqZeOEmW7b94HKh/Pfh6/wKZacLv6D6BH8OPkxiL+gN3nmdGMzfKxMYH7aFSkS6U2lIc 0A6ljTMqQimWWAM1PMtyLF8hDWS5XL6bXC/fyCyUTzKf88JTPA7zESFXjPGVUo06TG1gG/h6 oUFazi7htkiv8X8ESj7DfyP8k/9JdNpkmWMYlvC8AG4OnICvkyvwDkHgGbA1ORmIVpYlOBFB pBsps6LJhGS2A1v2ctkiFHo4aNgfvk0qVk25CCgZb7ocNlPUv4QGTk0HwlPh7qFayyXbL01s NdV0BRV0IHulDhQ0sVqsZoxjaoZ0WSrKiEliRkY1T938jBgU7+8NGsWeUGrRtCFO56oFRaPG nPLJw3tDMfCiD+910eKzvVqMTxXGmWIUe0zpFdcGGlajj7J9ymLR4YKnORzVxgHuOr/XQ2/+ +x5/qjmONxjmP3WDcQkGb0mwrm/Hz3yTmIlf+SyxfQU4Ri/htsSirskka2liPFBARfIrpgko wIrqdG0KmcYvIAv59ep6Ky8RsKR9eojNBJczAmIhYooH7Tho1+3D7Y121o4jaLDtQAM18qhC ON9ZrVH7ubOGCv107M9YiEqF93rvFponDZqZf6Th1VtePYa3eXYs6zf/ZuYfF70db838jHpl o5gfyDjwMEzIjf6kT9jq3e0l3wvf28kp4ZSdHBeO28krwit2slvYbSdbha12cpdwl53cLNxs JxfECw4yW5ztIOPEcQ6iiIqDOOyi4FbAbmUsP5mZn4hZJVipVlG1Cm82XC+2zxNWCHcJjIDt lY5qs6pUg0DT3b5S80IsVIrVBKNqhrkLrAevp+XpS5YCmAVa1xntfLQ6BaGaOFgMQEiGhIIS pxQg0t6k0XLU2tLSglvSPxzHzjAN51WAjSuEroCx49Vg4fiiilIG33sJYo++++Ta6uEFA9zj x/4CAaZa8Xa2iuWN9bqBeh7HY1aQUC6Dcxki5LIsn9uD4K3kOCHkFQ75JOwVx46jL3BG+xIV 13WCmqZDrTZGa4hSoOhQGRg6ZSG26mIl8wbdmet3dD20g9pWT4CWzKZyAk0/iFQayrI7S1km U5K3ySdAzIPCMIkiB7pF4OMrgfGIKWViGYEeaIviSlDFQXW4ShUF2xuoJt4COIwbkZ7zFJU0 zlMdixcb2R2pUE4I9jAcnzhCfj5ypIsH7/QpMu7nAWRfVx1gYSDzDRnKvWnQyyf6UINezopn HQSL2EFOC6ft5IRwwk4OC4ftpE1os5PHhMfs5B7hHju5RbjFTpqFZjuZIk5xkFHiqDS9WBQT gxzP2imFKCoQjhlIBovPCrSiBwYyIqgaY7OlWgGqyVPdfRRFpUSjLiSEqUZAOHmIRl5mGjQD BlM19dOrDYI5oxkwcAlFf1fnpfLXJHOZWlpagHrAXi4rcToEsJXAeCq5Ah77alZ0fBFYSX+6 BLD/AjLpPaJgoGviqF8gylsDwFc8ZfA5jXg8KxNWzVVL1f4qV+YoC4wl18kjHaMC08hkboo0 ydEYOJz1PveB/VPvF/YvHN+7/+b9wohsuLKyoj4aDhnso7ERoTvJUbu7qkiZOpjUqgMcgwJj 5THqNPUL/ivXz/icWcNOxmzSLMgPfqMVyU6wQT0lGOVaLTRDwIo1q25ttK60stYFtv+SIZBJ 0wNSqxyp9ABAVrWxVE5jgtW/hDyoiZleCC9Lu43Wf0sSqJxydMUHC2e+v7pxc/G+ruBzCxc9 ueOmxdvXPrrxwuNbMbNhRF9iBtKyvfPWq6+dfOco4Oxq8By/Bes+ExWis3qjycQ5iky5jiGm WgcvZXgzikwRR1E4Zip3XGsa4Bgj1Jumm36Wf3Sau4eL8vqE++QNydtUtK1IKA+VF9QUDTAN CNUWXBe6rmCGMCk0qaCxaGXRybyvQ9+Fv8+zul28s4Psac8P2AXDB9eCqIfhga9Eh9EJRHNU lut9uUDAItdmBxTZ5SzJLZFzPZ4Tbqy5dXeje6WbdS+w4FyUnZXziuW45ZQlaWGzLDWWYeDX e6NFv8q1OEeDHDTd4sx5So3Ufo+foSXlPRpibnHTxRnDCs8DtJIUVmnmRUqaXxl/n7rb1Kvf guXrPWa8qO2Ts3PfveOlpU9N+WTbb7/d8tTyZTt2LV28o943IrfX5HEVbbfj6k8fwHjjAysv zvzX8cXPMoXvHn7lnd+99jsQFq+AqFllZCHcu596bISjayyVV5UaZUlpquzWI1XmF6TKcG6q zMhMlR6fUerFqlYa5DZxu8GiCIIlexfahtoQW2zENk6hs4izBaFyEzzuMfZDQ43R/Ki9KxEG PUozFC5nTtFUBeoKllhfOcId+nkAjPUx8Da/NiTieN1peJuXXU1ZyjSBu0nHENBspcJ1zLVB OagS2ade9jyV3uP/zfM8dyZqpLel3c9/9z5DzsfYnIuPMtGLHzBrqAda81xC3UVlcw8YySEY iYCG6SpHMlmGOrs8x0odZP6+IIvBOMIv8EFMihnMALwfp0QzXBUPbEmJKDoSIIb4l5qxsl1z KcWujD6b2BMZ7IaEn1N37fr5B/rMvkCjM8kcQF2R7m0mzQypw3XgEoQR8XHNNLzGNt9h6Jt4 SuEAkxqCLOTsSwpwx/79tJcmGLmLexqpqFk3H1UxC39EZCVGhcG9qIMKYyVFnc8wRA+FS4eR iWQeYYjPIs6X/oaG4Yl4ImFqoJiHV2AWe80d+J49t6flRXXdORrUa4lSIy/1QnQFwZAXIC3o SEB98kK43GaraGL2b0x0Di63HGRu+eE29uddG+9L2BIXOj7Zhb/Frz9M5efo5FeslztsyILf 6qVVviEuPTzeNTY8lZntmuObFl7qW5650Xd75oOunb6XfN+6vgyeD9qvcj3q2uViqgom8ySP ugDh5GndEwrywfzMYeaJZgKOenamg8PvDTdmZHo7mxlQsw7hGJjklbrVQ1+8hwcjj+Yhnk1F YLdUtqP9ufOtlLrMcDEIApRYN0Vfvz29mHauM5VaZOSexdPJZ3RRjfocRnwtZZr1AZbO41Os jUBe2qwaoYyNS3+JtjXvci1rGrV8eDkuf3HOgYtYeO2uzpuW/s9jz50kbz+5YPHencuWb8ej tKVzh6z4U7PiGTMLi386hbUHE58n/pH4KrHv+VeY0ocOHH144+7dNO9zM8z3N2kdVIhW6cNZ dkB4THhqeL60RuJn+BZyzdJ802putYnPc0mMJ68w05UhSXZbZmFhQQEKZFDuysrMtCLRE+Gv y40ovqKMzDRHRWksh5KywU9pe/5X7EQjjXQB3AhL0AyWK5IZ4WgmYRzqVWHEdSNhoP1eFRRH FN5MIjvenj912q13jV356sbEb/BVqyqvHTzglkcTn+A510f6jau67r6NiV3coYaDU65/qiTv pZXT9jT2ZEZaXVPrBs0ruLBNUCpnDRi5pCdQUvKxxAhcZUg5G9qi14HHxPVmS7i1HOcWwSVn WcJydgS+C2EcCmvlTALNrzLxQsBq2eTADrfbBxZHrixvMuEsU41pmIkxee2OXb8k+Bg26lDN SO1BNXVGMh3N57mcamUtKVmnUS+GLqaJmiUiarIfS2YhlVpG83uozYErDBlPLXgBSGNte2J6 dnlWRXl7Sd/7B7HfvPvuTzdtMQ+6h51wYdvRusmUSx4FO3EcvJsFZniNHglm4X5iatqsWqYF ie5IUMKSLytDS89a5i+zBsdfpswYWjnjT+W+sSLLez0+D+FNsiKrMsM7XQ6X3cXwfsYdwjYz HDxiIIRdsjUEnhbNuIHfKmxMMVVkNqeDwATnhqhCS0Xuw6FH8U/Pjru5YcH8oUvvPnZrYg+O 3f1kz9q6+2cP3ZV4hzvkzBhyQ+L40acTiZ1NvXaV96z95qkv/1mYaeQOwqHCmMONBxEHSqei MqV8SstSZY+eqTI7pZz0XKe71MJlcVu5Uxw7DA5nOSbLiIIkORaUk0yY1LIo7cmwmn0lZaVb ET4MiopcsUbKXs6gi0ZTOXSGwm419BTVUKvb0xrKR9dx2QiS8fUvlHEYZVtjMo19q9aY5LIF SkV6IB3Jb/dBidMltPiTLmWGSlE+HODsa12Cd0AuOMDZSX1/fvdSFISDRSlA+eAXxlCZfA0a KI/BY0iDWC9NxVPJDHGGtBjdiG8kS8TF0o3yOryOrGVuE9aLG6RH0APS3fJz6DH5ZfSCsEd+ E/1ePok+kP+OPpcvoHNykYw42YNccj6KyBXyMAReNqfbXKWcblJLZXD4cyXZIUkyYi5HqThZ RnJqWZQXZIlBmCtWsJIt6rourZSI1IH9+3VANlgU2K9LQaLjbNO3fzRcVxpq6or7PJ1n4unI 0uVAgNWIAvwSUAItBsTV8ktGtZFUHfoliI2fT8z+7ZncLE/07wcTc9lI15pp865bRNbTDEaS 7ALuaDA0tRln6pOKtR7aNHG61KitZzZpb3Kv8Ye1s5pJ5BoAlcO16aY27QflB/UHs8QqrMqa GRNggmUV1SzygqAALPKKQBfQBcUBFQTsHFZxQAspk+PETJ7hO0izLiFR+UYHFiSHsAlsG5Nu U4JoisCMHM4eZ0+xzKaUiaCbhiuHhVMKswlQR881C9jjZIWwUiDCbywffgTYAuHihR3+POA6 0nWETuSpqfZ11pwB2xz+KL5o0ATwBQW+tIasHT1qPnp0HZcqgWJTC740ZtbOWhhROJQ8i1Dy X0ZcDLe2xMOYxrNCjD3E0AVfhpS8S+o/fbbroe0f4//ZMiA7UEKpHL+U6E/G4c0Hb7zjduCS dYkZbAjsdRto6eP6k4rWTbtKG6yxNcG2IMkKFijhjF7OXhlXZzQHNwXFKneV/1r3tf4Gcbwy wT3BP1OcpczQ5rhn+Q8H33N86vnU917mGceZzNPBZNAVZqNa1FnGVmkD2Gu1cdoXpr9lJDST 1cy4AkaiqStgNiGzN+eEjDVZlxvllTIrL8D2ElJiy0Xovy7nZg2s8OD/tp777/nPrajFfinZ EjSVoafzrMwVJvi6J6rumb7+xMyFp24ad1d361OLFj/79IL5exIzuJc3jBixMfnA44kLtw+p 6rrAPHHs6NsfvP3WRyAhDoEUW4eOgRTL1T2kGoRQ9UQ0D61AuxG7Da5vY7c/YAgbKpjBhKC+ 56Fjx45RCfgAQryFrqDjhfoKRCyig/hFdpGyVnlDYSRlkDLIwhSwuWqRuZ4Zzy5SF5vXqaKJ cGJMLTcPI4OZ/oIu1qlXm+UHyBZms7BZ3ME8LfA2YjGbe3DEwXFEVFS1BycCKCojLSNplh0R 6SfyJlU1mzUkSqTRttJGbIfIDqTinnu5oNiBe+qyIslBXVlhwqZDZAzwmgmukA4gfMmCUdDS rGGtg4x5Icg1pqLQZMc+K41IeGEmwA72gC4yaBtg3+WTM3Gg9Jrqy5FouvmA/v9DQvxC2i8j JXkBickPgfc/rExlPihwLd8I+arJf+0xy7TWCAyqyfcPhGLmolBM7QCwImbuVWGA+7tBbbdL 8cDWFiOeSBUbNlIjQtawFYex9QGcg8f3cHnLwCDmXkyM2Z2o5w5d+Mfd1wx/iLn48wD27Qtl 7OkLQaqlx4EdpnDvAZdkg5YuBqvVT5b5lvnJDb4pfjJLaTKTccp1ZlJu7m8mfq8osEjLs1qR WuDAmWCl7tbDoexQdZacVZ2dHawOhTLR9Zlz5evdM3O064NWbJ0ZptEmqtBBvp6jgTGQDV1G 1ON8tWGRnknlM8Xhh+JxHDHCYIa5ZSwKUUpnqWFmJgJDLZE/4UxXz5wXK5+4cf6DnoPef779 EUbjVteX+0jHMTwjxzazrqp39MkbqmZs3bTFdezkt081PrZg6LWNsxP3H6O5C9uTXxnxKwdq 0eWIpZ6tF98UWSNFyWV3lpayvUXga3GR5Snua4ugILpU8aIe4CVHhMSDLhx0DXcR+unIShfj UiNBGcvGVyJwrxx3UtoBLo7GO+u0eLzlvPHdR8qTBvWAwXwiqWQtakkZYVEr23hkcuLC+39I /Nx8ZOCu5R8e4A5d3PNp4uLjd2L1G2bYxb2v7L/hCHZQTpNAawyCsdvJWL0gYsNe7DKRAluB vRJXMJVipVSpVpnLbBV22WYP2kKlNnowdyRP0wi9mi6ldCnS9K03AGBpK4YeQE2bSIQtEPJN heaIrZytEqtMtMdrxOvYuDjBNM58nW0ansKCgDTNME+xLWSXijRx40bbjfa17AZhg3wf2yG+ YHuNfVP8iP2T+LH5Q9tX7Nfi1+YvbUX0n1pImH5yy5g0zW4xqyrWNNVqs9tN8G5ENTGKXTZh XiN2Sbbbg0iCt5YYoqpBBQxghZElCTxAYldVRUFisRM7wQIOKrqxyj3xhaC8ST4sM3IHeJUT yVZCgNM7dJlv17Xh2nGN0aCRLgeR1+E8EmrcYZjINA8q7vnC2xnvBNWfSoWK/2qtaR33q3Ul uv4NP4slvQh+ZZHKdDqa/qjnkllg8LQJzC2TN4bpB1Uef8xGA/z+mD1VsGBcHfDHxGx/jCZx 7w3EjC+PsgIxux6IMbCrZpe72m5zua8SJYAYFiATNeG6gy2fbYuZlIzQVRhlhKpNMoUIhRS7 G+rsbqijEAEo+qsfvgJuwDTfAuyWkpQwMdYMjAwriVQklK+wPCrcsx/Oe6+ri0TPJu7KCvV0 JjaRi+S3ifULa4aPxbd21V38iZi6lQ3PTGBKrc8kPsOrQafIaOh+mUHCszyNm0YwUw3GmYyp kmHgBPGVQtUwlFI32xCHtpkMXQMCmKaea6kQ6S/B0ZTycaTingeODR/bK1bOHDvWcnukzttE 1zHASeeyjNX/b/fYTBSRZcCcIrWJBBGsIxEECSNKLCGSILJMkOe5eNCEg6bhpkZTs2mliTOJ UjAVsFbgznR+QCoslM5HPHc5TG0sb4Ndw3ZPCX1M57td1AcYKzsHBsREvVcK7BUTYPZpFugB L4C9UiCtDRugbgrHBLMDdjs9P3fADmBGCswA0EnBf+25/AVeevZQ+mu8EkxD5Nj68OsMOfT6 xQSI/FXsChD3Ky+shDcYx+zDeYAVDkV0J+IYzH1HELMqCMYIwTP5dICaiiuc+gTHTqUts777 sR5wp+3HHxPfpbw6tgt6UZEHjdXLplhnOchgbbBjvDbewZqUTLoK7PaksixsEdEX9GH483nU tJPnvdI1b4kb8vGSX24E+9O+uJEKTkIh42vCSz4aKbinbvY9Dd8l3kysxze99Gh8SM81idu4 Q2bblANzXkx0dT3H4I0rJqx2qvAoC/g8/wM+j4ZvfMFiwxZAPV1c0wH34yyb2c3iFvODlsPc Yf6w8LZFsuiumI+xS07Vp5XhKtMqfKdJLLaNZRuEBlO9+X78gPyA6QXSobxhesv8jnaS+UB6 V/1E+0K22XieSQk2XjJEm8WiUclmsajaZbGmybyFWGTtNfSaRLTcy4LtNRWruVfKNl4zZJs8 zIZtg9SblWzZ0sRLN+sg0/wv6PxwfqVhyvfTzUHmZpI9DF50kHVZKrvqXMp/AfdF+0I71/kf Yqx7NJ4WY/F0Hg+VYoboOpo6QiEY4iy9qtlu9mTEDDFjyogp2e4YAzs93xuKaUayuxOkTygm gYS6LEeMr1voAiSVJW4qSyqoLGHysAWvSWz5y+PdA0W5+z5K3I1v//RkVeIbko8TPw3scXXJ hYTS9Qd8bUMiTqXHssQI0giWiYau0uU8sNY0myBqIMJL9qGtZrDuSnSrsNV8PWI0JsgwzHPW RzYaaOg6T00NgzcpPeEIsVKLooQX6LdZGsan7vtD3biXVi3JuyoMPJQY8RL+FzZ/d7LrwomG DZtffDmRlQj+2/OVfJKvEUnWMLJJdATyVgbTEVjQVuZ6iznLTMzP2f778+1hZKVfPUTySmhq i0a6VgHjZl+Vt3TVS+PqjidG4NP4Ly8d3Lxh3B8vdJ38LvGPhEgzoZNfkRg8nUGjDiIGEO5I iYigI3Y/gwmzldnNEGYRMuwCgqGdzHyNyNcwqp37gUf3LfXQbzHo9yDGSIzZv/wRsJNK952b EvVe7u8/O6gdOAmsok+595EZ+dEKvdFnwQ7N4fC7/X6W1ViHyW3yszvdB8yvmRm32+MnwQzd Osw+zK376rl6aaw22jrRPs490TPGN9Z/u3sL0byZDGPLNEnOSFDAgm9lBs6wRIxsy8CVae1x ut5+KdefLjaA0WTXUKgXS8M0hqlUkfoktpSAPYgm4fW4/G084Nn2xIFXjicO7XgDZ3z0CfYv +ebuPyQ+Im/hOfiRI4kn/3wqsW3/G3jcbxP/TBzHpdi/D5t+k/iCvml98k7uO3hTJ8rHNv2e iZGtEeL1VDiJKcBmsWF/wJHlCPOFXDd3NNKbq3ZXRYZwQ9yDInFudLg+Mo+7iVnKbWQ2cveh B5kn0LPMB+gD1xfoC/cXHl+Ai6JCrjfHxrl7PJsjH0TYXFdhpNQViwzyDArUZtWGB0fGiPXW 0c5xgXEZY7LGBsdmz+CmOmdFborcGbgz8onnzxGvk+YN+I00D/0qf4wwrnxGyI94XBziwQn2 cYSeIC4nM9PCEDEnU5B8Efu1xBcsXFlICkMRUGUmb8GvkVx3Lp0aDLZ2Kvhnc8eQtSS9yBiN xlFri+Fe5tIkS7rMc/mDAjoRUFuengHjC+WKSB7747rW2KOPPP771xMv7W7DtW/SWZnb9eWO Oc/CZHyc+Cv2/3n6hPFTHolH18VuGn8YTzj5MZ586NXEkyf3J07dURx/GMf2Yvk3iY8S0Djx h7zeXqDi+uRnXB7QfRYqQuX4Kv2Npc5WV6t7afelxWtdTxV/isTNGY+7yG3Fq8vJ6sCaEGl3 4UZ3U4i4nLprJmKeyTzpIvMD8zPIQl+rnyxEN7nIBvdqP9npfN5FVmduCJIN8uoAeTv4Wh45 5jriJ4d8rznIjPJDLjLDPaWETCnGY0omlJMBJeOySJ3raj/p4YtlkYg/J0hQt26Z3brLMvK7 XBnOoMsVDB6SuzlkuVukQMOlBZlVjMm/NiN8faO92b7NzhTbdTux/znjLg/2dJBxesDbJ7M1 CJxQWVlw/TYQ/dt6Xk+5Y2ZFS8q5BjezE+bszLnOOBQAn0E1Z4A36Cf8Rt6JufpSFpMBpN2m f/uhdGnk2eXRRLsKIzGZfpnp4DDNMRDoLOPydMSAptth0F/pvNpjDX9c+pc1s3Y/P+nq449s fiXxNyx0877YY+SUlUvmJDIX1k4cOKgpHMZ1iQP3TL3zlhG7dk2a9MCyLes/GdV659Vrftex 6t17E3vqF+QfXrZ2/F0DmFtrp9cMnnh9/+zBhV1leMvY+wY1HJ4CfOgDKaWBJSGDLXFOL7fV K9OVB5WdypsKN4QZot7LMjZMRKSAduVkEyMgRVHVtxjWwTAsoyKiqKzAvEheRCIieJsuI5aF Jugtme0gU1/gOFnPyCoFtVmhq4KeHS4VVobKhE0WQtWWqjpKEdFIkDBkv7kDb6RrRdrf4zAH 0ei5aLX2pWHd1Wjnqs9XX/rod10qCchisVxKylJBLtsMx1w3lYBu7BZj2IyM6nSqj/EfFhyK boopK4fHFD0CGjQAZdp/b6BLarjE+F6SsWKyuWsNeeQ3r73WngC3/UnmwMVrn0xsJyy5r2sW YOt6Zh+50bDeTGgh/VTiX+l48r/07EhBqYmXBQ6xGHEcb/pOEkUwJZAgVsuWVMyTpl6ollLp M8yw1QTrqrUUe5V0IkvU+D8SXUYCRtpk6KLBjSs/x45GU+ZgiXHc1OtYt097Goah++zZxDep I9XaraiTrWIPwCgr9Sw0VyI/icxcTuCluTIr/8ThuTVkGPhlXiWVgwLy6Vw1WPdnqqtR8Tn6 XW3PHrl0qdGaWu4kONGC73oG35Vo6cT37KDljsRceA5dPyo08FGiK5iwTCaHRGOBkzytmwXC pO1N/opFBcMg6qpOL9+GnJuPkD9yh37+YVfasx5gUOOP+jXFHC5E+UyuXKz0UBqV28TbpE3K YeWsYgoqwxWYE5NIwFwLipxDFDmEcZBwDkI4CRPum6CMRGmKiKcQkaLdlB8bLuKV4iYRzjFg nuj5sYkE35X2T7FuDXLDOdKDa+Q2cYe5sxzHdZD1+0zUP6VRqJYz8ZYo3T1aSpn7vJ2elEK/ IrqaijQ56Mc1yCJ3JP9nr2TDtBAdQPHfpdMMoVk+NCv/5XMbQ+vGjcD1JbeP9O164494efes 7G5442tdR8CP+Ghl8+LFbIGxljCWdGPHMAuRC43WHSYT6/KbHC5WDUaV3uCGA9ZpWMFsMpci LSi9r6D3HUGmg9TrwL6KzwP6392y0Zh6GgBCxXXn6AfonRr9BwidRrZYmZGyYcRGKpxGggGV UWNnPle9Zmltbbjv7eX66pHVczqH6S2k27HF4dIM29De71eXB2ZWAAUm/5KYwW5I/A10iQ8o o4auQiMv26/vFSlPPXswZSFnFrszMeOWW6hN4Ex+xTaA1vGjLNxTX5efUZlBJFbKIGMtL9hf CLxufz3wrwweEyeSWMaBJI63IkkUNCSZBM0vK4LmUS2C5jbbeKvbbGccbrOLON1mL3F6VB9x +uUA4/DLGYzDo2byVo+axVv9suz3pz0B1ePJdZsdbrfZSXJBwCFNyLWCt3xArzSDLyHLEvJ7 PG43kp0Oh1XrYxbA6SB9kOde1X2vmmvWrbFh5q1ghC4Myff6pXuhX6C9/dZYanF/+77gzunp NeEzgIRL5TkjhGkcf51d22V85U09sl+TmeXffob+aXHbw2UldmBaewlDd5BoDDAvE7bToL09 NG3sztevTXyPi8duHot7j71/7K63B2NX4p2xm8ckXhu7EFcNTvzei5+5D8+6D+9KjKL7fYn7 7kuMwc8kxpAaPIv++zjYybt/9820WCdaqn8U/aLxX+Ue+zyv8NJ/mKOrqcIisOwAoen/qWrc J/RJDEX9fvlHdP/270b781DFvY62s/PRYNivgX01fh2tJ8+gW/ln0Do4X0diKIdFqIb+30DY 7VDXH+6ZSq8JdwB9zUdruTFoArQZDnuI/RztgLproQ0P5+thr4D+RrHPoVaoewLggXB9AOxX Q3+vwL2PwT09oL4v1DXBPhrqNuPXk49B+0dhPKuhDx83JtmVHs8hGNsDAI+jY4e2EtQ9A/DD eB3UjUGPQnsL9LfM2GHcfAxNgr0ertXDfT7yEbqejgfgzfR+gMey843/NUl/5diBD5JryB/A u1rJutntIMWrYTso1Arvi0OlAdJpeaepGiTkTHWw+S3L25pVe0r7zFpgfcXWYLfap9mfs3/p kBwTndi5xvkP11RXh3uVp6fnTc9X3t/7+vge9v8QKA4cCnya0SvTljky8+7MN7P6BNUQCW0J dWaHsgdlfxbuHr4mx2vMWC2qBI6mPwIeWTG6msat5S6oI1A3gBmKUPp6wjgyxkzLxhlj3GXG Yhpm0PXYlYZZJOMFaZhDHnxzGuah/eY0LKCj+Ik0LKIImZ6GJbSB3JmGZfYI40nDJnSDcDIN K2iqWJ2GVb5dfCwNm9EEy5jLtLjCsjcNAylqPdMwaHCtPA0zqFi7Kg2z0GZ2GuaQorWkYR7a L0/DArpBW5OGRWQHuZeCJVSr/ZSGZdJk7ZOGTainfevl/0RcYj+RhlVmnINJw2bU3R2HkWCW Yl1x327AHJ0R9/0GzBv1TxuwYNTvM2DRgH9nwBKdI/d7aRjmyPNuGoY58nyShmGOPN+kYZgj 78A0DHPkHZGGYY68M9IwzJH3xjQMc+TrnYZhjnxNaRjmyPe3NAxzlLUrDcMcBS1pGOYouDAN wxzlFRiwTN8r71YDNtF3ybvbgBWjfrsBmw041adG3yXvoAHbAbblvW7ADqPNxwbsNPr5woBd Rv2PBuyl9+ZjA/bTNvmpsWXQNvlZBpxlwFEDzjHaVxhwoQHXGnA3yhn5oygsGuNPw8az8idS WEnVzzJg413yb0TXoSWoGU1BU1ETmgRlEO2E/To03YDr0Dw0F/YF6VZBkKzzwOprNo5NUD/D aBGEmtlwf3eA+hv1Tf8feyq+PLIgGgVXZqOFl9vMh7pBUKae1xPFYOuBuqWhXkZtX7hjNpQj 4Z5pMIYFxl0job/5sLeiRXCcDK1a4XoTtKRXpsEzZsNZ63+MtuqKlsF/a1uFxhg9zr/8BnQE lXAMonzoaQaMsxWuzId9KvRYcEVf/9udv7SoAzz8cva8gVGKr8lw5xzj+bOgjvb8/x7XQail bzQDRrLAGBHFTRDOaZsF6V5HwzwE0XDj/iCKGM+rg+MwePZUA+dN0J7eNwV6pVi+0biT9tb9 v4wpNb/z4Ll0TM3Qdsn/2mqKQVe03Y3GqKZdfu6MNNV2M+ZlHrohPeqhxpXpBuU0wWiKLo+9 1bgyw6DQUXBcaIw6NQ8paqIz0M8YyQIDy5fw1gpjCUKrpjQNpihphoH7yQZlUVqbazzrSnqZ lO6ryRgbvXOO0SMd93R4/hyjxxT2g8aom4znTUrPRuoKHfX89Hw0Ge+Yum/J/2nveoOjuq77 e28VaQWRJVQHaFi0VwgtBoEkZGGBsNGukMBEAWEkXC2lhqe3T9pndvet33urtTxTez0Tz9ST xmTSGbd1Z4qbDx23aSYrqUMXSAc6tGlD0zrTunTG+Wen/VB/SInzoak/qb9z3t0/QsJxOv3Q D9Jy7r3v3nPP/3PefW+0ouJ/S0Z5VnrQZNu4HHm+dmUP6VL+HHMTzKFWqrLnyTZ0nWfayZpo IFybafm8y/O+tT1pEUNGqrsKzwNNk61iofdpG3Imx5amiKrGtM0Z67BFU7yfJCV/puWuMgeD 989JrpbU1M89olC1wgzncErOVu1qSevaUhOL8XN8VfWqy1GaYunWjolyTXUrutBamulVaVBt uCSl1aX9Da52QmZp2WYJ5j3Ls/5+yjBL+jDJeZeVMWKjpYyek9b2KVSrvM6+8qNDsA0Nqb/F XksxTpZzz4/GDO/0NamNbqsSWZT5z0vPpFkais05mVt+3UlV5EjzVTV6vfvuRO59+hmSxzRT yLGlEyti01Sew3zZsjn+m/xlDWc4tgXHwPNsW5fjzqvUE9/rJLuf756sGn42uTLKqtXTX02z R3TlBd7vS010DV6tRprPPcHWynKWzFe0KPPOcM2kdZ0t4UgelEO+FT3eX5a4TD3LMZTmulmW rZvveR7WBnEv7QFd+nQzVm2F7ebqlAZGknMphVEaowx7yOQrV7nAMeB7vLuC+X/LIc8R4+Oa NVxOodJP4n5/DHAUkUfjcczSHeAY2s/z/ChmJtBSbB7HnWAUn5M8O6k08VvHDVxLLJkf9596 yvN+nvgWzUqbV2P0k93Fqp4pV+Syn6d5dR74uQpPo1Lb/Hiu3o9qq6VfOap11M9fS9ZMV+b0 LFMxKzWRsjUuuVF2z8laOl25G/k8vY+xTLl25ivVyZQZZ1Zi2uH64cl8npHxuJa9yllIFjNr qFSzeDW/hLwDUgROc2X0pZ6WnslIymt5aBdrtdJSfkVeHRWrOZdrG1Uxnc+gOrimpLVdWUMe xJusfxYz1To7v8oXpjxl1J65/Oqts0RZtqwlTzqfxOdCxmKmpraV+VIlSbClrZq7iFNzRt5b wXZq4rZ67/54S5F0aaZfjit7Bb08+/8Se7P2HFquj1VMG7j+CTXHFif6yYo+vly10Z2WFdW3 v59VWRkf1cq7MoY+TqNqfJxg3Vd7rnz2onuOKU9ovjb+ec9gr2bu84Fzn72rlF0+rdKJJCHv Q3N8NsortaerX+z9Mj1Hnv8s+ayz1ilutR99a1VPrAbTXJ3HZY/p99l65peStmrl1RxW3u9X SmTKU6yHe0+ZAj2fxBT/SeARnOH7lQE8awm0+3G1D0+I/YBehd4SnFXGJGYv/781/fj44wHl UQDtekw5gGcBAqL+y93r/vd3xvJaz33Wq9wPJ+ez5oxumOJPxGTSFCftjO1hShy1nazt6J5l Z0Q2ZXSLEd3TfwFSDxETE3YqRzOuOJHBvv2HDvXuQ9PXLWKplDhjzSY9V5wxXdOZMxMxx9JT Z8zZXEp3ymQHeVLI2cGnTcclBn3dB/vEIyctw7Fde8bbzVi1izxxcpK7t8SkoyfMtO5cEvbM x0otHHPWcj3TMRPCyggPqGcnxGndExExeVKMz8x0Cz2TEGbKNfNJoHVXKEFfe9bRs8n52ilT jDh63srM0l4Lpt0nztjTIH3KMpJ2Snf3EnXHMixdTOi5TAI6wEwH+47aGc9Mk2zOvHB1WBBG smZEwnSt2cxe4dvFAJZuYTFtO6ZI5tJ6BuILI6k7ugE1cGEZLvTQMwJr86S/BZNnoaBpmK5r gx0ppIN+zkgKS5Ii5XMZU+QtL8lmSNt2gnbTGGJ7EMSAUd3ynJc3M55lAtvAIOfMdwu2tD1n Ojp87Tmm7qWxRBuMHPztEjPynumwCDO5VApDlhXs0zaYWJlEzvVYVdebT5m1lqBIdYmL6aSt DGM49iWQ1SG/kQMj34EJS5+1aT2fhM1F0kxlYRFbzFpzJiNwyOsiBXOItAnbZSwD6Ho2a8KM GcMEE9/cFhlLmM9DmbSZmhfQzUXspIhG2kqxeT2ZRK7kZ2DHtClyLkKKrWk+lyNhcwbZX8zY UBkUoZTnUZxAdceE3z2EBtzkwmQcnrhM67P6C1YGpE3P2OsbDdsTlptN6fPEgnZnzLyb1bMQ DSgJiOhZLhEm9Kxjp22m1p30vOxgT08+n+9Oy4DtNux0T9JLp3rSHv3/cz1p94JOinfT5Cfc kDdTmDV5y6nxyRPHThyNTZ4YPyXGj4nPnzg6empiVMSOnxkdPTl6arJpQ9OGySTMWrYamZh8 AkGhgccWXSPFWBkKZNJ5el7M2znaaVC0wc6cR35YIjg4RuFfpF8G6PqsY5oUid0ijm1JHWFg T1MaYae3QhiKzjyFkwnHmWRpxzQ8+HkGdqzKRS60Z01GYRdX9sE1iN7pnAfSENNGRtUotMst C4VArpiispmiTczpqZw+jQjTXURI7e5ucTbDMTtf1gI6ycqF8NaFmzUNC0VnteYCVsxwtNFe PZGwKCYQlQ5X5L007bBtObvvEyplpS1SCEwYL287l1w/SDkeedLOo6DmplOWmyQ+oOWbO41A hfxwVXZe+MErLbSSEdvjxExVOapez+VMl9mg7hmmk5EaOFJuRnaTdi6VQA7NWWbeL1er1Cc8 eNJEBUhUS1xFR4jFhdXwqj4mxXQp9czaZFnkygaZ95IQ+OjeICGcnYjhJvDIwf6B3WJg/8F9 vf29vY2NZ8cw2bt/f38/2oFHB8TAYwcOHTjUtOEBWfexyUhXPVI8zkM8qtr8kEeHcnpEm1eb cON/FgeAD/jYUF6b4GMQPSTSoS0ReCOwEPjLwE3AtcD1wJ+tv9Jff6WvrL/SX3+lv/5Kf/2V /vor/fVX+uuv9Ndf6a+/0l9/pb/+Sn/9lf76K/3/h6/0Vzz5V8c646+19v59e8wV7wT4rcAD aKY4wmuu69rq9teN1R2vewLtoRUcqAY/iMopzhmqPb72SbWo/lFA4bx48J61x5Xf5VWWd9E3 PVb/xDqU5sAW5R5gGRBQwmh7AOOAC4DLgCuAesajGRvwEuAm4Ke8Eg1sWfzKo9ESui9yt/Rs qo8vdf/y/G/w5dKvxf3+5FN+P3LCRxv00fb3+9Pdw36/a6/ft3b2Fajf0NR3K7Y5sFn5boB+ +TKLVtX+WmlWVSWsvBn4jFIEaIF6ORMNtC7tjPRduRmoU9SAFlBh0/DyrYC62LSpL7ZBW9bu Ka1KWPtP7Sf+ivaTpYc29V2JfU77sfINwE1AQPsxPu9r7ysvae/Rt6HRDgGuAG4C3gbcA9Rr 7+HzI3x+qP0QWD9QegBDgAuAK4CbgHuABu0HaFu079NvA3NL4yGApn0fbYv2Paj1PbTN2rsY vau9C9H+eXHgUN81HnT1yEG4Uw62bJOD1s19Je2fFj/aHS5p/7YkusJvxnq1d5QiQAOzd0D8 HUUATgMuArKAeozuYnRXKQC+DHgTUATUY89d7LmLPXcA3wHcVXoBUcBpQFD77iLYlLS3FyPD 4dhm7R+1v1W2wKj/oP0d99/RvsX932t/w/230behv6N9a7EtrMQ2Yl3Bnhb0Leh7sP4p7a+W draGl2ObtJswTxhtD2AIMA64ALgMqNduajsWE+FWELmh3AkqwFxUPuD+j5WvBpXos+Fo5Chi TFATGXwCIzRXxJWIFo28/vu4pCby2lcwoibyhd/GiJrICy9jRE0kNYcRNZHEsxhREzl3ASNq IuOTGKEpaX/4Fzt3hQfGL6ki1qzlYaU8rJSHlfJKnZanj/JRHcn2B4t79sBib0S7du8JF66r hW+qhTNq4atqwVQLL6qFl9XC42rhGbXQpRZCaqFNLUTVwg31IExRUKN/vuLyUHSrWrijFr6u Fly1EFELnWphp1oQ6kC0pLUvnniUu1HulmKUV+ifONLXDBnbYdF2hHU70v4m2rcBy3wVBZLY 4SP/ahv1O5b2DPnX3YN9duxJ7TY23oYbbis/AtTBQbcRRrdBhH47vRntEOAC4BbgHmAZUA/s HRD8MrfNaHsAQ4ALgJcA9wD1LM49gKbYUsRvsGA9UuhxutJu47MDn3atPbq9JdTS1fJk4HJI bW5Tx9uW27QBZTN9O6F1U3BTSW26+vOm//55k9IYa9Re0y4r2+GIL8v+8uJH28Ml9fcWIzfC sc+ov6u01SHq1ENKRO1Ef1Bx+fqAEgpS36+EtK+h71sMPR2mP5Ie2Ru+rj5Eu66GPwr9e/iD UEnD8D9CN8L/Kkp16mL4XzDztavhd0Kvhr/dUwpi5puRkoruumDUa6GD4a/fYdSXsfDGYvhF 6q6GfzN0PHwpxAumv/CMi6toc/hM5Fz4SdAbCU2Hoy5oXg0PhZ4JP+5jHaA9V8O9EKHLH+6B sLtDzLSjjQmeHSipyejehtcbphrGGx5r6GvY29DeEG7Y3rCt4eFga7Al+FDw08ENwWCwPlgX 1IJK8GH6SloXfbni4foW6ug7OapSx+MWjVqNv3uhaGpQUz6nFH8lMKaNTQyrY8VbhjI2LYr/ NdFRUjc8da74qY5htdg6poxNDhcPdo2VGpbPFAe6xooNp399akFVX4tjtqj9VklVJqdK6jJN vbKt2HqU/rsbddMrX9pG/SOvfCkeV7ZunhvaOtR6ZNOhYyNrNBdlW/M3WrauGG8vvj42MVX8 0+3xYh8NlrfHx4q/MyHOT11Tf6b+dHTkmvohdfGpa4Ej6s9Gz9B84MhIPD5WUp9mPEWoHwIP EfMh4wXbFEF4igi2+Xhv+Hid2A+8ndQBr7FR6WS8zsZGxqtTCW/B3Tk6srBzJ+NswdGTcdwt ohbnTidwOjsZZ3NBucM4dzYXCKd4hFFCIaC0hRhF/awSYpSQ+llGebqK0iNRXq2gvMqcAmoV J+TjNL1Xxml6Dzhdn/THHO7qUpcOx43zo2bH6MWOURNwsfjFueTWYmFaiAUjTguiGIhcnDaS 1OtmMd5hjhSNjhGxcPj8Gsvnaflwx8iCcn50cmrhfNQcWTwcPTzaoY/El46f7h9YwevVCq/+ 02sQO03E+onX8YE1lgdo+TjxGiBeA8TrePQ481I4xk9PLQSV4fjR836/pG3cgHi9uK09Pry5 JXuEg/dw+9YXt13HgeQtZWNXvPjpjuFiE4CW9sX2xWgJOUVLD2G6WS5tffFw+7br6ltyqQXT mzqGlS4v5+aUraPWiP/PxQ+mvBwZ3G+73Af9YG20GNVHXE9Rxop7JsaKQ0+dm1poaMDsRVKp OFie27hxtLR8y5/sxuQgTQYCFUSae5zmGhsl4mr/52r/iFNBu7GkRttUPNTFA8W2sUkNpWDy HHQ9f27qOo5LdHtw41DQVbtUt0yDxVbkX+shfcvg5eRI2sGTvb8LW9yyOSo/2INS9T/nw+IV CmVuZHN0cmVhbQplbmRvYmoKCjQ1IDAgb2JqCjIxOTUwCmVuZG9iagoKNDYgMCBvYmoKPDwv VHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9DQUFBQUErQXJpYWxNVAovRmxhZ3MgNAov Rm9udEJCb3hbLTY2NCAtMzI0IDIwMjcgMTAzN10vSXRhbGljQW5nbGUgMAovQXNjZW50IDkw NQovRGVzY2VudCAtMjExCi9DYXBIZWlnaHQgMTAzNwovU3RlbVYgODAKL0ZvbnRGaWxlMiA0 NCAwIFI+PgplbmRvYmoKCjQ3IDAgb2JqCjw8L0xlbmd0aCA1MjMvRmlsdGVyL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCnicXZRNj5swEIbv/AqO28MKPDaQlSKkbLKRcuiHmu0PIOBkkTaACDnk 39fvvG4r9ZDowczYzwwM2fawOwz9kv2Yx/bol/TcD93sb+N9bn168pd+SIykXd8u8Ur/22sz JVnIPT5ui78ehvO4XifZz3DvtsyP9GnTjSf/Jcm+z52f++GSPv3aHsP18T5Nn/7qhyXNk7pO O38O+3xtpm/N1Wea9Xzowu1+eTyHlH8B74/Jp6LXhirt2Pnb1LR+boaLT9Z5Xqfr/b5O/ND9 d69cMeV0bj+aOYSaEJrnhdSBRbkswFa5MmBH1vWCMS/gkuuaW3F9B16R38AvjHHgDdmCX5Ul B28ZX4J35D34Tdlp/J7rq8Amp3MFpn8JB0P/AvGG/qVy9Iezob/DWYb+JWo09K90z+j/Cqa/ 24DhL7nZgulvUa+hv1O3HWN0nf4lajfRH/sL/R18hP4OvZXoj3ihv2Afob/VXPpbzaW/Q+0S +w9Pob/Tfehfwlli/1G70N+hdqF/hWch7L/g2UnsvzrQ3+K52Nh/ONv4/qB2S3/BWZb+DvtY +gv8Lf0LnGXj+6O59Bdl+gtqtPQXPZf+Tpn+Bfwt/QV1Wfpb1G7pL+iPpb/gmbrYf3i66I9c R/8Kzo7+Bc5y0d/qQMXJwWhh9v+MbNre5zmMq34gdE4xof3g/35DpnFClv5+A0fHCssKZW5k c3RyZWFtCmVuZG9iagoKNDggMCBvYmoKPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUv QmFzZUZvbnQvQ0FBQUFBK0FyaWFsTVQKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciA2OAovV2lk dGhzWzc1MCA3MjIgNTU2IDU1NiA1NTYgMjIyIDMzMyA4MzMgNTU2IDI3NyA1MDAgMjc3IDI3 NyA1NTYgNzIyIDU1Ngo5NDMgNTU2IDY2NiA1MDAgNTAwIDYxMCA1NTYgNzIyIDUwMCA1MDAg MzMzIDU4MyA3MjIgMzMzIDU1NiA1NTYKMjc3IDY2NiA2MTAgMzMzIDU1NiA1NTYgNjY2IDIy MiA3MjIgMjIyIDUwMCA2NjYgNTU2IDI3NyA4MzMgNTU2CjcyMiA2NjYgMjc3IDcyMiAxOTAg NjY2IDUwMCAzMzMgMzMzIDI3NyA3NzcgNzc3IDY2NiA1NTYgMzU0IDU4Mwo1NTYgNjY2IDU4 MyA1NTYgNTU2IF0KL0ZvbnREZXNjcmlwdG9yIDQ2IDAgUgovVG9Vbmljb2RlIDQ3IDAgUgo+ PgplbmRvYmoKCjQ5IDAgb2JqCjw8L0xlbmd0aCA1MCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aDEgMTg2MDg+PgpzdHJlYW0KeJzte3t4HNWRb53unpekkUayrCf2tDyWLGv0sixL tiyskfXwQ7b8kEwkx8JqjVqawfPyPCTLSTCEcA2yAyL5wt1wITHYOBCIGfmFbAh2EtiEJGwe uzebhOxCdg1LAEPCBgibWLN1Tp8ZjWzDOnvvP/e7nnafrlOnTlWdX9Wp7p6xwsGICmlwG4jg cHqVQLZOEgDgxwAkyzkSll+f/87DSL8KoOscCgx7/3bN+XMAhmrsrxr2jA2dWv+FAwBpAew7 XKoyuPHlhzMAMqOoo86FjPD03Qbsv4H9hS5veM83hd4cgKw07Gd7/E5lr/gB2suSsZ/mVfYE LujvpP1y7Ms+xatOHH7yeexvAKj6fsAfCt9PrNMAq7PpeCCoBjJ3PFiP/VoA/WeQR/CgH9RP 9LQviBL8//zRnYV8dh6FAqkE8gBi/4bnG/Q67Y69Q8em/bF/Ef4FhU/xU/s8C+fgIJyAo3hM goVIMAhjcACP78CbMA6PwH3kJIRgLxxB+hnybSEA2zGTciEA34NqIsZ+Ck/C54gZ9JAFL8JL cBPcF7uXzIFUyIcWCMIZ8QfiP8beIe3EBwIUQitshdPiO/BLIgk36vJ0oVgF6MAEfwsvCRvQ 70yYC/WwDjphB/r0DfT1BXiZlOpaYq9AETigCy2PwT1wGH5I7hVUISIcEX+g2xZ7IIZWUJMR SqAd3CgVglF4ANfxLkkhc8h3yGtinvTg9HvTH8WO4MoXQS00QxtEcDXPw4/gV/Aa/IlsI0OC XegWA5JOGo7lxE6iz/OgBtbjsRG2QT98FvYhYg/BpHBYPDj9/PSHmI0iHhXodT004Pq3I1Yv wa9JJsknxWQRWUu6iJscIn8WDMIK4XbhiPChqBNL8agTD4unxH8SXxH/IK2V9kiv61NjpbGO mCu2J/b12LnYbxFTK5TCBtS5A24GBVc1CrfDHXAXRutBPB6Cr8OjcBqm4Aychb+HV+C38B58 SNJJDVlJGskQ8ZA95Bg5RZ4mPyE/F/oERXhEeEm0idvR9hEJpFZpsxSSfj4N08unD05PTv9d LD12PPb92NuxS4imFTEvRkQroAdUtHwn3AdfRYtPwFMQxeMsvAy/gd8hciY8LCSb5JKFZDGp IFWkjmwmW8h2MkzCZIx8ntxDJshXyYMkSk6gN8+RF8ivyRvk9+Q9RAZhFlKFDMEqLBDKhQqh UugUhoX9woTwpHBKeBaPnwr/IPxSeFl4TfiD8JGYKWbjsUAsEdeK68Udol/cI46Jt4pPIJ4/ El+VJIxfhlQqlUtfkB6VnpJ+Ir0lfaRL1d2j+7Lub3Sv6V7Tg96iv1G/We/Sf0U/pf+VQTRs MQwZbjXsM3zecNoIRpvxSTiOu2MSV5r0EXbAw/D35Dn4Z3JUzBaeIJuFb5D7SbqYB7vE/0V+ puuAu4VGIUo2Cjniv5MRMgJzxcfJH+GPcFqQhF8Su/QNcgiexZ10UNgl7JEyyKekx6VLJCz9 XBKFC3BUeIfa0WdL30BrI1jevGQVUsPgha8J2fAj4QhGYTd8F76mNwkTGPd7oURYC8vIOhob 4V14C3dHJmmCW3CfXCKHdWHhYbJXfENIg5vIJeEVslIXhiG9BW4nJ4RO8UfkAu68ZzFfOohL WEEG4BK8Th4hrwvbYKNwBxyWhnX/QP6J2EmnzoX5B9Kr4jpxSJgjPHNFIXoKTuJOeAk2iD+A HeRLuPtfEuywTvDDQ+K3ye/gJPmsNCy60Ms9gkTuwL3wJJwQ10qpsBpOiifhOfKY+Atih6ek PcRHvhxru9QH7+uPSsfESV2ddEPsh9O/IY+Sn8bOCn+A+tgPxW3Tw+RBKR/35Wdx9wYRoVR4 Auc/iBXjKBiRKsb9eA/m61ysbSbc5e1YuTbAzeQ93DF3IEp1pBQ6hQWwS2g2yHq84xgWATgc jqZVNzaubFixvH5Z7dKaJdVVlRXl9rLFpYtKihfaFhTJ1vnzbigsyM/LzZmbPScr05KRbk5L TTEZDXodBpFAeZutvV+OlvRHpRLb2rUVtG9TkKEkMfqjMrLaZ8tE5X4mJs+WdKDk0GWSDk3S kZAkFrkRGivK5TabHH2p1SZPke1bepD+YqutV45eZPRGRkslrGPGTlERzpDb8lytcpT0y23R 9hHXeFt/K+qbTE1psbWoKRXlMJmSimQqUtFcW2CS5K4ijBBy2xomBTCa0atoga21LZpva6Uu RMXiNmUwunlLT1trYVFRb0V5lLQ4bQNRsK2OZtiZCLQwM1F9S9TAzMhuuhw4IE+Wnx8/OGWB gX572qBtUNnRExWVXmoj0452W6O5ey/kzXRReVZLz/7k0UJxvC3PLdPu+Ph+OXpoS0/yaBFt e3tRB84Vitv7x9vR9EGKYl4VOkLdp0vRFqXa2iin/xY5arKttrnGb+nHgBSMR2HrWNHxggLH mdirUNAmj3f32IqiTYW2XqX1hslsGN86diLfIefPHqkon7RkamhOpmdwIs2cTKiJMUYxcUp1 bE3ASahHtnWYBlHZKaMnPTZcyHLaqMth3LkcxfDTS3BWdBDD4I6aWvrHLQ2UT+dHdcUWmzz+ PmDYbRffns1ROEdfbHkfKEmTI5FgOB6no3Z7tKyM5oWhBQOJPq5i/WUV5SNTQp0tYJHxgvDB 5h6c1ttQhZgXFdGoHphywAB2ordt6dH6MgwUHgdHlb03KvTTkfPxkbnb6Mht8ZHE9H4bpu9J 9kQ4N2osSfzLsOTMaXM1REnOJwyr2nhHl61jy/YeuW28n2Pb0T2rp40vT4xxKjqnpUcsFDgl FIpsFDNxR0KYdnrSolIx/tOzTB6cMhgxFRmHyO1RS/9are1NKSq6xklTsd/TWewyM427GW2w z+6vnNWf5V7auIgOSyVCR/f28fGUWWPtWHfGx9ttcvt4/7gyFbttwCZbbONnhEeFR8cDbf3x iE7Fzh4ojLYf7MVFuEhDBb1JUrx1eODdwADrJwXyDKnEJ0SDUH8cdNIUqTwpQoqBEqcI5Bv1 OjougEhaTpg+/Vye3fJB46XGTssfGzdeaoQmpC1/wWZJdVFmUWYxNgQk+Issnv+LQwd/Blk6 T98KWvHetBKfdfNItmN0jURKDMSaZjULJlJsXEfajZ8S9xv/LtMwbNhr3Jv5eOYzxmcy9VKq lC5kp2anC2JuniDk5dmA4F2AmNLSbGZLttlsmWPVG4RSAuZSSDGZkN9jNt1rIRaLqcrcZN5n /olZspg3mXea/WbJbJ4SPueoKDAJgikvrwdMWQQ/pmogVdAEm2Anug035ZsIWMwWyDXn3rQq z44fS6Olkdj3dlp+j8WnL2hvJFV99r0bLX/ALu3Y92oju/mINrD3PLbQZG/Uzov7dZX29M9Z nsdrnh2vhvRGhIz04ScIfbuXkqViXd3SGrxlGUTbnLpltSW2BXq9QWwlNaci6rEdX/iSfMep /fPWtg4cV8t26s5eemlg24Hg8vsvfVG44+DC2tXDJ74/vRyjtD32hlQnrcIn6GXwHceWT1eQ 4pTiVFtacXkDWU/0VcYVxk8VDRdJteVlqVJVaYlZzIDi+bZSuzjHnFJTUGq3l6eYs1NSzDkL rbkkd+sca4GhJKXGKqbm9mTkkJwp8j3H/CpZX1KXIc+HHostYBNssfmOzKxamG+Z758vzn9W 2IMP2yXY5tk7La/32Td+0HfRchEzZuMlpBCMpqaLl/ou7E/XIIHMrBUr6EmwyczKXYH/KDTQ 11es19sWlCyrraurr1tYj6gsorAYFlGochlW+rnZubaSOQhVujA3O2dpTV2daLn5mPPLJ7f8 D+VGsm393MqmseB9RU8v//czL4R68lfekPN0xo0lnxr62udXu5XtR/u/sKXjW/t77+7KSkuf t35J08Iatc/ytcdubg9sC0z/6dZNNTfXktczLKZ0+80rNgzs/CbN5Ucwl8fwXS4FHnJ0ZC0S 5bT2FEfa5rS7DXeZbkt7lBxNeZqk6nW6lBxpUcpy0GFqLjXqso1GnU7QGYWlBLIJAZPRKAhE n4KZ2wNGi1EwTpG5jkyhRybV+OAt+sm9RCCx1LP4tEqhtHzQF7z0PsWvsamRJiVNKWNSSiFm u/uwOJ00pmTl1hJ7b5G4dE5Obl09WUrI5mPRT2fk1G4hznOXDkkll57u/9XuLwn7/vxrzJlb MGeaMWfyYQGcPwNFsVcdJktmrVXGJmcKez3pmbUmfemCA3kH8qW8/DUFggFO5b+Qj0/45amj BfsLJKCyUFgAYhbJzJgHCy14QxIAXzo2IyGRLqmwoDxzIutQlpCVJcnWNEOuVUrNmhK+5CjM lo0ltnlyhiNXroUMS0Yg45UMKWPVwpJVNH8+wPzRcucCzZyLWSuq+mjNudS3+wJNGJotL9pp vgR39+F2Jbl6CXMGkyZrobafivRaYpAivq3EzdGS6Xe/PfLC8MMEvvLcv6b/5T3pbmffyemF Qje5a1f4HHFn3fG296d3HiNrvv72jzu3WvO/8tBesveGtLvuO8RuV8LP3j74yKsv7sxofN+Y b2SP14eD3z0387Ade0NH3/wFfHcmnIVXw6rpTnzvjn+KsP7O+qpAj0JSCFrx3I7F6BG83oL8 BniHHBKMgmZbB3UgaK87YIEqfE8GYbH+M1jNKXentBdoZaefadaKzHYK64lsVhoxcloED62o jJawNt/GaR3Sf8NpPdxAopw2wPPkx5zGd3l8w9FoE4wLpzmdIn1XdHA6FQaMAqfTYMg4yGmz /qTxh5xOhx0ZtyZQ2pfxa04T0Fl6OS3gC+HNnBahzjLIaQnSLA9wWof0UU7rId1ynNMGGLCc 57QR5mQu4LQJ2jKXcTpFUDL3cjoVlsx5OfEt1tLsNE6bxe3ZTZxOh8rcr6InRKKop+d+n9MS FOT+b0brGP9dTlP+JUbrKf55uZxGzPGmRmkD46/kNOWvYbSR8XdymvJ3MdpE45t3B6cxvvm3 cxrl8w9wGuOb/z85jXMLRE5jfAsKOY3xLVjKaYxvwSZOY3wL53Aa41u4gtMY38LvcRrjK9/J aYyv/G+cxvgWbeQ0xreUMDqFYlLax2nEpFRbSyrys0vv5DTWklIN2zSa4aVnOC3BDaUvMjod +cbS1zgt4dyLjLZQ/YsJp1H/4gxGz2H8xZym/HpGZ1OsFm/hNOKzWPNtLpOPcJrKazjnMP5D nKb8Jxidz/S8wGmq52eMLmTyv+M0lf+Q0fOofFkmp1G+bB6jrYy/jNOU38zohVRPWS+nUU/Z MKPLGP92TlP+vYyuoJWg7HFOS3HayPBP0FT+aUazdZX9jNOU/wql0zT5jziNfLuB0Swu9iJO Y1zsS6AbxiAAKgyBAk68yvA4nt3gYvRG8IMPzzCXkrEK+iGING0V5LuZhIwcD86vRKqV8ZX/ Q01VCc9k6MIRD0QSMiHkrcOrZm8JrMCjGio4VcO4zTjDg9etOGcYfQizWVtRXwjPIIxgO4hS QRxXUHId89mDPecVvjYkyWk6htEbD/aDzJOZmfSbSqo9lFgN9WY5tjKUol4qE8SREJ5DOG/x LM3Jmj5Oz4x8xWU+dyeNHWPIU1wHUY+XeboLedTqfz8mMnLp2t3oV5j5RzGUsU9lwlzrNoyX DJvZfBlKmL2N2G5C20MsNgrK03kqaqXRGGUzqbbKq/ik5YEf7QbZd7Uu7H+clMryj8qNMq+G E3bdPLsrWAT9MMC97mQjLpZhCnpTnvA9yEbcLJO7sI0wr7WoaFlH49HCPAkzlOO4BdEXGaUU nqtaxrkZ9oMsA2lO+pit5Pg7uS6F+UZneplG6rcL7XuZRg19mXmtMHtOHg1thHod4vFQ2Bq1 eWOJ+Lv5bgjwCKoMmxDLSm118Qgp3P8IsyYzC8lexSNPsaH9UabblZQNVNbPdGm243wN7TBH xMkzNXSFXBh1qgwVN1413U7OiTCkaUbN5LSf7ewgQ9TD5lNPaTy9fFbcgpPNH+FW3Xyl2r5U 2c6OozDEdruHc2dwdXN0/XwlbiYfYb2ZqIZYlnqYd1fPiXjtDSXWorLvXam+GR20buzi3ioc fyerijLfpXHMBpntYcbV5tMd5uYxdLF9F+A54seW7ugRjramYeZuoLBYadkhMwydfP1uFjUP kwmwvadlo4/N1FaSnN3uRGbRnb+HR8bLvKG5OcL3llZ3PAk/vKw3k73hy+5YocvW5+Q2BpiG CEN6cFZuqrAb+XFkaW47EyscYrktsxzYw7ANsbwLJ+qJFnXqu7bfw7xqaLspxLNspnpqo14W EQX2svma11Svk43OZJpmfZChFWC7ZCyxirhtH6uZdFxhSAS5DbqHNBTDbH7c47j2AMshL6ub cd8q2b0xjGMNeM+tQr30qGRSyRW2klUnL0q42F7yIOVFyscipLJeCHayHNAiXpmQ/L9rYZRl jCarJlnpxErfjffEdjxbMPMovQm59A7Qju0Gxm9DThe2NDfX4J2gDY+NjNsNZnzbomc3y6bQ VXJNTvC1faIhGuCYz+Totd3FZiITr8jxOA+w0TGUjyRsOhO1TcvnmftRcrXUKsdMHdX2r5vX zBDf08NMi5qoiXS39nJrdHeP8Fo6kLgbaTbDn4BMvHaOJqqTynecmsjpIKsfYb6fh3g+Xg2v +C6kiKlJWmZ28ZX2BvkdkGbgAKuMmtcDPDI+rvlqEVrEVjUbKa0iX5kVV1qO1zZaxRT2rKqg VQ9HO8RryMfZpuhvQ85MnR27IhYqf8pIfubSqrfCPAowZN38SedaYi7zXPQl1ba4XVpJBhnS 7qS7SDDpWbo8IR1MytuZe/cnI0W98zL98bzyz9I3yuK/i0Uz+Tk0Xh9nJP0oqz2hRhjiVL8r sR7Nr+Ts9vKKquGv7aoAz4+Zyjs7hz5pRTP5sY6t/crIxZ+96D1H5U9o2mq05z0ni6rvshgE L8N7RnOIPa3SJ5JBfh8aYc9Go5D8dPVfRz+uL8if/9z8nehqT3FXxlFDa+aJ1cl0XrmP4xFT LsN66K/ydgblKy3Mvt/P9kjlT7FhvPfENdD3k2bQ3gRK8Rm+FurxPUzGdgn2KvBNshbPaqDf nmyDDi5ZjaNLcKSW0/WwFE86qw6W4bsAPan2v+5e99+/M8bHqi5DL3E/7B4LqEOKU5Ufl7td qrzR7/OHkSW3+IMBf1AJu/0+OeBxVsqtSlj5L4SqqDK5y++JUE5IXufDeUtWrKiuwKamUm72 eOSt7mFXOCRvVUNqcEQdbA66Fc+6sOJxO+NaGxgPJYYjHiUoa4MNN6nBEDVTU7m8Ri7d6HYG /SH/UHixJqwJJcswfgXX3M16j8ndQWVQ9SrBXbJ/6BNXIgfVYXcorAbVQdntk8Mouq1L3qyE 5RK5e6O8aWioUlZ8g7LqCamjLhSrTGhCDPzDQSXgGktmqXJrUBl1+4bpXDfCXSFv9Q+g6k63 0+X3KKFyqj3odroVuUuJ+AZxKQjd8poWvy+seqlvwTE5pCCqCJx7SB5UQ+5hX7msrd+JUoob B73+oCq7Il7Fh+7LTpcSVJy4DOy4nSFch+KTcWyMrt+NYQjgAlWnGgr50RxdkIL6I06X7Oaq 6OIjPlUedYddDAav3z9IZ1Ma3Q6jI04ENRTnhUdVX9itorQTiUhwrFJmSPtH1KCC8Q8HVSXs xSE6wRnBHAhRYzSWapC5MBTxeJBkvqJ5rx+NuH2DkVCYLTUUHvOoyUjQ7A1RK2rQ6/YxiaB/ F6pV0H9nBA1pARx0K8N+Oj7qQsxll+oJICJ+edg9ojIBtg0U2YNwyF4VsfO5nSiuBAIqwuhz qmhEg9tNwZLVPbgYr+oZk3FtIcwdD9XhdXsYvGG+sULcnhNnDKhyJIQpxdBUd0eosxEnxV8e 8uOSUSMuKhymeYJLD6oY9zCmBoYphJCx9MSuVxlW9rp9qFoNO8s10HD6oDsU8Chj1ASd7VNH QwElgK6hyCC6GHaHqGIqHgj6vX6mrdIVDgcaqqpGR0crvTxhK51+b5Ur7PVUecP0/4hWeUM7 FbrwSsq8xgmjqge5KpvSual7Xfu6lubudZs65U3t8oZ1LW2dXW1y85qtbW0b2zq7zSnmlG4X whpHjUJMY4KO4grCDNGrbDG2GJrIdM0DY/KYP0JnOmm2Ic5sH2lpicnBchTji9vPh+LKcFBV aSZWyr04zaVgGvgH6DbCmeFZztDsHKXppGLgVIp0UHWGMc5DiOOMXzSE/mGVibAQJ+ZhaDB7 ByJhVI1u+nFHJS1oUSjuFCZyAorEZJpt8ojiiSgDmGFKCDMkeXalvM3HcnYsvgpcE69cmN6K HAqoTjcWnStXLiOKPpZtdK4yOOimOYFZGWRVupyygwxbtrsvc8rj9rrpgtAIkxv1B3eFtCRl +ciY/lEsqJEBjzvkonZQlwa3FxMV/cdQBcZkLXk5QrMNMTzWDc0sjlav3RE1xMxg3XOqQR9f QZD7zYRDLn/EM4h7aMStjmrl6orlUzmMpIoVYHCmxCXWiG6xwuoMz8SYLkzhXg9dXS1zOTGB 73uuCO0o4QYqsK2rGW8Cpctr6xfL9UuWV1TXVlebTNs6kFm9ZEltLbb1S+vl+rplK5atMKd8 zK77xM1Ie1XcPbYP8cU2wr8upi8gyV+7zB7ZxXp74eIVcrNHdiXNulJK43d8jEwSXzwkPiM+ KZ4Qz4iTyTKz+Nd/grj+E8T1nyCu/wRx/SeI6z9BXP8J4vpPENd/grj+E8T1nyCu/wRx/SeI 6z9BXP8J4v/hnyCu+VuJ5G8S/CzykY/7RiExPvPmqWX11d9itbFWsgV74VkycV4Lf+PQdM/2 MXlkxmN6x7n6WujINXwrkqDHWDZfTUoboev4LUfXf8UKEyNSgdQiOaRmabmU/HYuz+J3fOw3 P7NHrsF/Up3Ad1eyzCz+ZvAThVUG32W+zx7xsfrihjcZlSw3e+Rac+kaMfur9F1rntH/Fx/7 I56L4H64yqc5C/YJR+EpPM/h+S6eElRjuwnPnXiK4BCOHr93qWMKLzvZ5UTnlprb6HXDxhrW d6zVrilm7Wpq0K7VS6nckRNte2j/yImaBq1ftkTrLyyu2ddsEY4AQcO0zcC2Cs8mPPfhKaHx IyfmztOmmbLptMMnCgprMs4Jh1HiMM47zFw87EjB4axN+k0G4d3mevIWavs6a/exdidrm1hb xdoMPvomtc7ac6x9irVVrG1i7SbW+lnL5MlFPN7G4y083iRvOrKgnICVWMqJxUoc5cRhJWeI iaQer7XeN0VSHfW11kq5xVqD51J5jbUcr1Y8P1O21lqBZ1FZq7WeAP1LHiKAEXJzMTJZmUbH FHny6en95kv7zWCaIk3HyzZYm02kAc5K1Fwdng/gKR0vC1qfw9ky6wLIwhPHrX+umCI3Hbf+ h3XKSI5bP7JOCcQxx/on6wXrh9ZnrO9b11tfLHvCegalHjhunbJOSSh1qGxKeMKRYT1g3YrO XbDusXqsPpkNeYrw4ki1OnHS9rLt1h55ilrplJmVNVZUc9rahoOtZVOEnLY6rHdbl1awqTV0 6mnrEmvQWmll5so1c4s130rp5bR1ERpbwKy0WbeZTWZT/cRvDBOPGSaOGiZuNUw0GyZWGibq DBPLDBPVhokqw4TdMFFsmJhnyDZmGS3GdGOaMcVoNOqNklEwgjGb/rmRnf7xR7beQi96ibYS oy0CbQXtb2kEYhRgPUTniB1CR9dq0hE974SOATn6QZdtiqRs2R7V2VaTaFYHdHSvzosut3dM GWJbo/X2jqhh86d7Jgm5pxe5UeGuKQLdPVMkn7LuLKR/q3wGo5p/5xcL6TV25xd7eyFnpCmv KWtV5or21qs0/by1z3zy7LM+HZvHzmCUe04YrDcasNuF3QnanaDdvHnR+zu6eqLfnNcbraFE bF5vR/TLXfKOnjPkGHmyrfUM+Ra99PacEcvJsbatlC+Wt/b2dmBomBym/TEqd4xeUM74C2ii ctBk/AWTk4gmZ2NymHaaXI4MNiZny5Fnyc0n36JyZfSCcrmvwnwmNz/31SS5ybO2ttZJmy2u 6yyTOavpijYyEasVRYqsTAS3ipWJWInARNpnRCq4SGVCpJJZEsmMjFWTMctxGTO1ZL+mj7ra bm9z01zZ3DNphNW9LTu0a44lsIrF3Zy/6tHCs/Bz8S1ItfdGU2yro6m21dDUlGe3NJIqfVpU jywDnlR6ZVHerYVnJSCPMek0ZJv5UEVzRTMdwuylQ+n0z+r5UN6tK4sKz5LH+JAF2ZloI8nP cDiCH8hrc7cm/oX4J8KvYeiIlnV1RJu2bO+ZNBjaoo7+1l7kVcd5qaltU7HzGrMSmY2UKYoJ wQTPZOKCiMbpTeVkk5XUowu99hC6goaSEQyH4D8B2Kq4+gplbmRzdHJlYW0KZW5kb2JqCgo1 MCAwIG9iago3NzMyCmVuZG9iagoKNTEgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9G b250TmFtZS9FQUFBQUErQXJpYWwtSXRhbGljTVQKL0ZsYWdzIDY4Ci9Gb250QkJveFstNTE3 IC0zMjQgMTA4MCAxMDI0XS9JdGFsaWNBbmdsZSAtMzAKL0FzY2VudCA5MDUKL0Rlc2NlbnQg LTIxMQovQ2FwSGVpZ2h0IDEwMjQKL1N0ZW1WIDgwCi9Gb250RmlsZTIgNDkgMCBSPj4KZW5k b2JqCgo1MiAwIG9iago8PC9MZW5ndGggMjQwL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVh bQp4nF1Qy27DIBC88xV7TA8R2E3THiykKFUkH/pQ3X4AhrWLVAPC+OC/74LTVuoBNMPsjIbl 5/axdTbx1+h1hwkG60zE2S9RI/Q4WseqGozV6crKrScVGCdvt84Jp9YNvmkYfyNtTnGF3cn4 Hm8Yf4kGo3Uj7D7OHfFuCeELJ3QJBJMSDA6U86TCs5qQF9e+NSTbtO7J8jfwvgaEuvBqq6K9 wTkojVG5EVkjhITmcpEMnfmnHTZHP+hPFWmyokkhjg+ScL3hKuPbgu+PGR+297uSd3Xm5Pz1 n8aglxipbdlPqZkLWoe/Kww+ZFc537k7dGYKZW5kc3RyZWFtCmVuZG9iagoKNTMgMCBvYmoK PDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvRUFBQUFBK0FyaWFsLUl0 YWxpY01UCi9GaXJzdENoYXIgMAovTGFzdENoYXIgNAovV2lkdGhzWzc1MCA1NTYgNTU2IDUw MCA1NTYgXQovRm9udERlc2NyaXB0b3IgNTEgMCBSCi9Ub1VuaWNvZGUgNTIgMCBSCj4+CmVu ZG9iagoKNTQgMCBvYmoKPDwvTGVuZ3RoIDU1IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoMSAxOTkxNj4+CnN0cmVhbQp4nO18e3xU1bX/2mfPIw+GPHgFAsxJhkAgTwIIxFQmJBPA 8AgQMKHeJiczJ8nAJDPOIzEWC15rtUGLt6W29iHYFrVFy2SiNqAt1F/be7UPsK2t7c8K/rTv F7Vq21vN3O/e50wegNbe3/3j9/n8mJO199prr7322mutvfY5cxii4ZhOU2g/cXJ7e7TQdMYI n+8QsVxvX1R98LmmXODniezf6Ax19dz1uZtfIEr/ApE10hUY6PzFx99/hCgrD2P6unXN98iq 7Klo3432Vd0grB8dsKP9H2gv6O6J3jiXrU5D+3dopwWCXu1quhpo1msobD3ajaHt2QutaL+J ttqr9ejvfSbrh0TZc4nKY6FgJOqjBUmiaw6J/lBYD/1lUefraD9q6sBIqo8VEbPJ9v/nH+tH ABvJCZjLD1E+UfIlwCuAX41em3zTuodco7uT5/k0MD9iAlER3UOHaQFdYEvpKTpN19IDVEtN dIjW0Rk6TlNpgH2bLOSienqIipiTFGqgWcxK99JP6HoK08/pPBVTI73IciHHQyGaSauTv0bZ SHckT4Arg+roy3SSBdh2qgC+XillJZj5YPI0zaLi5HeTz6P1Wfo5W5AcovXAfkE5tIj20b9R Lu2mZ5IiShZQBz3I9rJfUwG10wHLcstgcg+C6jF6jjUC20QD1ufTH6MARn2ezWKnk+eSv6Sv WRjpkPSvdAc0TtBppZzXWY+QSgvpPbSZNPS+n37CprGl3J1clFybvBfUB+lVpUT5FrdDjxLa QG10F90Pa/yIXqHXWSZbwT7LjuF6lv3B+jx0a6QY3YS99VlY70F6mE6wpWypMkuZBWvNosW0 A30H6SjmH6azrJG1stPs6/yotXJ0TXJ6ckbyl8kkLaEWaHiYvo45XmOV4MEMvJBHLfMtUWvV W7dghT76DJ2lZ6HHi7D76/RXtgTXS8oHlH3J65IPJX8OXdLISatoK+2iIPVRP30OXn2KvkF/ Yn9X0sF5xvJN603WC8mPwrYLaS103wLu7ZB9AF5K0AiuH2GVOUzFKlaxzWwb62IH2T1shP2E /USxKQXKDcpveJx/m79gucpqTVZD0kyaj3lddB11wwMfgLU/ivU+RN+kp9kMtpCVYUU/wvg3 lKuVelyfV84oL/Lb+EHLm9YPjZ4f/e3o35ODZEeUrYMdYvQlWOGPbCZ0WMx2swh7GZrfrTzK p/Js7uIreC1v5q38Dn6I/wf/niVsOWb5qXWDVbMes2ujvaPPJhuTHySRFWzQaxGV0nJaifjp RDTtgX4hXGHaS7fQIH0E8fJROkLHsO5T9DQ9Rz+j38EDxAqgsx+z9yDqbmMfwXUve5h9nX2T Pc1eYm+ISynEVaxcpaxR6pQGpUu5Ddch5azyI+VXfC738n18P677+OP8JxayWCxJaxWu9dYD 1gdt37YX29fbO9K+8+bv31ryVutbL47S6JzR947eM/r10V8mdyYHoH8RlVE5NL0dWt6LGDyK 60uIxMfpW8jdP5a6vsoUZkXE5zEXoqEUXlvD1rENuDaxrbh24LqO7cKlsQ7WjWsf28/+ld3K PsjuYh+X1yextqPsi+xxXF9hJ3E9x86xX7DfsFcVBLHCEc1FyiKlQlmNldYp65QtyjZcXUoQ V0gJK33w0IPKsHJC+RGfxot4Gdf4Dfxe/mX+FP8h/5tFsZRaKiw1lp2WLsutljOWZy3PW/5u dVo91m7rfdanbPm25bYdtt22T9qO235le9NuszfZO+x77T+0J9OKkK3+Het+bFLKq7CdYRHr dMuNyjnsizwest7OdsBiNqWZB/hH+PetnewCV9lP2SD38z3Jz/MG5a88yHYqp1ghd1qreSfd SUl2THlJeU35pWUGa1Z+zYot/8a+ogR5nWKTefUHlhmWW62/IlJ+TNXKzey08k1+K781+VWq tt7HzlnvU54l1XJemUbnsKtvVz6BQd9T/MoBarEst/6d/LD7F603wt7XKHewJfyHlvvo59yl /JldYPcga3yXXWtZoLxPWc2OIeO+xebT79kNFGIfJzd7gv2MjRBjD/EH2UZlCrwVVxxsJQ67 7/IC9kOeQa1CR7ZQmcGalAvKDv6k7SxfgaP9LH2fbmKcVSJ2Up9R6sUOOKQsQk7zIJv8gFVR Hn0C+f610SdFxrY+bz2AOLufl9I2qqR/Ub5N1dgbP8fVQh+iKjqJGLyDKpVP0t7kfuZD3t+E /KnQCNtNFSwT2XIWdNuH82KmUohc2IZZ/4r8/wyyfiP7A/UzFTvrNBVbRM+dFg8yUzvy7wFc PvoXtD5DH7U9Zv0BbWGziCzq6H2I8hfofThzXsb8c6gG+u2i+y2l0FpFZr4BIz4zup7cuD5E 32YK3Qydr8E+b7KsR+a9J7kbK/TjjNqIM/Fp8ic/QXXw3bbkrckD1Ja8P3k9ddH25EPIv33J BF1Ft1tblZ3WEsty5Nin2TdwHv1vdgB5ez39FPmoiOXRb3B9GRpdY32CBi0/Ru5ck7wz+RzN gD0KYaEOnKKvUA/9AXZbz0/TstHNylCygYdwQp2jrckHk06WQd3JADLvk3TUbkXu2U/zrUfd bveaa95Tc3X16lUrr1qxfFnV0sqK8rLSkiWLixctLFrgKixQnfPnzc2fMztv1szp03JzsrOm OqZkZqSn2W1WC1cYlXpcDe1qfGF73LLQtX59mWi7NBC0CYT2uApSw2SeuNou2dTJnG5wdl7E 6TY43WOcLFutoZqyUtXjUuPfrXepI2zX1hbgd9W7WtX47yW+SeJ3S9wBvKAAA1RPXne9Gmft qife0Nc96Gmvh7ihzIw6V52eUVZKQxmZQDOBxWe5QkNs1jVMIsosT/WQQmkOKBWf46r3xGe7 6oUGcV7k0Xzxpq0tnvr8goLWstI4q/O6OuLkWhvPKpEsVCenidvq4nY5jeoXq6ED6lDp6cE7 R7Kpo71kis/l065viXOtVcyRU4J56+Ozbnolb7wJ4bl1LbdP7M3ng548vyqag4O3q/EjW1sm 9haIsrUVMuJKUUP7YAMmvhMmbNyuYi7lttaWOLsNE6piHWJNxup0l0dQ2ner8XTXWlf34O52 OGbOYJy2DRQk5sxxn0iepzkedbC5xVUQX5PvatXq5w5Np8FtA8Oz3ersyT1lpUPZOYZZh6Zm mcgUx0REH+uTmGQXWOO2MbsyoZFrA8IhrnpVaNLiwppWiUJfRYPeVWDDp5VhVNwHf/jj6XXt g9nVoGeL8XFrUbZLHXyd4H/X7383maKZFFtR9uskUBElY4GG/hQeLymJL1kiAsReB49Cx2tk e0VZad+IEneFslVUMB81wbZaa3UFjF9QINx7YMRNHWjE929tMdoqdeQnyF1R0hpX2kXP6VTP jB2iZ3+qZ2x4uwtx/Kh8/pgRT1s49peVPXOap7s6zma+Q7du9DdudzVu3dWiegbbTds2Nk9q Gf2rxvpMjBkdMHjcUgRLbXAh9LbtahEE/FmLGlwef/t6bDXoGJ9W18LzlVYDU/K5FIX4vX5M smi0TBGyLEU2Gf++EXsaAlhSmNoQz25fb5StGQUF73LQSPKCGCWr8WHmmuLVJZPbV09qT1Jv yiCHwpaFSmPzrsHBjEl9DUhWg4MNLrVhsH1QG0nu73Cp2a7BE7yFtwyGPO0p948kTx7Ijzfc 2YpFdLPqMhzrwjdWXHgyttOmIYU9oXwN94125VSCrJYR5WuPcsqwC+QxRrPTbNZT6FeIs8WU zvaw91FeSfYbNW/VbM5+rWbTWzW0Bnj2myiWVhbkFOQUoWA4Ed9U+ek33Vb6O+4WTpPxxKo8 +7vnPv1Ma1tWzetps9PkIf25l+c9Nem5TmiGB/GxJ1zU9oJRD+60aZwy6aPYVrO5ioEbj91y LjwZGESFsvEcVgvZ38WzNJfUdXwXCQsY9wlk4gx3z6MmrtBUNtfEOYXZEhO30Hz2GRO3Uh47 aeI2KmTfN3E7Pc9eM/E0Wqh8x8TT6UPKqyaeYd3JbzTxTAqnfc/Ep1BnutvEHbZH0x8w8al0 ffausbXvy37cxBll5awwcYXsOfUmzml1TqOJW8DzQRO30pScj5m4jXJyDpu4nQI5cRNPo2m5 c008nepyK0w8QzmWGzbxTFo9Y97YtxLLZuw0cQffNePDJj6VyvNehibMIqw+ZXaOxK3CI7Pn Sdwm6WUSt0v6aomnSXyDxNOFj2a3mjh8NOc6E4eP5sRMHD6ac6uJw0dzXjdx+Ch/monDR/kl Jg4f5W8ycfhobpGJw0dzG00cPpr7rInDR4WLTBw+KrzXxOGjwqSJw0eLhyWeIda1JEvimWIt S/IlPkXSDR2mSnylxLPFWpbUSXwa8NwlWyU+XfJ4JT5DyglKfKak75P4bDn2gMTzJY+h2zzJ 80WJOyX+mMQXSP6vS3yJxM9IvEziPxN4mqH/byVuzPUXgU+R9BIucbmWErnGLBE/VJJPzTSA Z00d990aeVGr9EVAM56SBb4Jz+i9gKjJpeI+OYgn05AsNdD9kkMFJYDx5cDqJV37v5RUMaaZ ivvXIGixMZ6IvLPuNedbSqtxVeI51MCqJLUWIwKot2FMF3SIylHbIC8CCFMfSh/m8OM+WJd9 m1H3S54gaBrkC+4uzBtAK3zJCqr/wWj1ovHVtFPOHBlbqdB0FUpVPqf4sZ4weiKATsyy+B/I fztp46OMMeMjmmDJTeh/Z7lfll4TPvGhr0fqvgc0odV/358qqMIafswalZoL+6toC56oKXUH NFShpxgvvgET821CuQVzd0q/Cg3FOB1SI1L3blNa+WV0MmIoiHmFTiHwDrwtly5jV/D1S626 xub1mzujTMZiVOoQAGXAtENYrkpILQVlp+SPSrqKpzphP2HJXrkmEaPLpJe65SjDLikra3g2 C8i5opfsS6FHWFpPlWsRvdpFdkxJT7VT3proccOPG6W+PtNHvdKSEcjUpNywXEmnuYZ+qasX pZAblRRNyvJJmWKH9Uo9hIfE3hQ83SZPBDugQ/rqBmCGHQLSdh1oeWXc6VKvXrPunBAR/VKH AGQLWT1yf0RNqV5pmQiuTrnL1Ak+9UrLaBNyhqFbyiKG17qknTQ51jfJ9xE5txFZqvSPT2Ix aTVd2uWdY2GRaSG/lOGdsCM6JPc7x4mxAy7130QLGzbqNTXtHaOJLBKTWU81M5FON8pd1yu9 1Sdl+s19aNjIoIXk2JRVjSjqk9m3b2xPCFuHzbnDYx7aMxZzF+8vww7vbo8Zq1srI8eI6+CY /kZcGnboNfP5ZIsbMeeT3jeiOyYtbEiKybUbczZJWUJiFHRtQl5pktm6V9rE2M/+SdFs5MgB qVlAjojIlQbMqOuWftTMecNmvhOri0jPxybtH6Gt2HEpHUU0qDIqDX+IdXtlrguMeThg5tEO QEBqN2CuOCZzrSGpX/Z0S2lBXEbO9Jq+6cEYw9bXgc8nZxgwbTQxn3TIsXtMXQ0LCQt0AW6S PCJSJuYKEevGGRA1e4KTcqhPxldskhdTkjWZ04MTpPmk/ULSJwOTOH3SQmFp25Rfy+U5HwV/ Ne4fKmADcZXLrDExIsvNrFMh+XsgvQJlVGYCoZdoRahNyjZ2nZEfw2NnZPnYyP/ZGfulJ1I5 cXyWzdglzdj1DYA63NsIfAuoYvc0yOwh6B5QtqMUdz/rcKJ75LeogtpMDsqQMH7uXHrCpOjd E3JByLTywFhmfnen7Liv/KaXjdhKZb8BGa+pOb3yXdD4XcHELJvSx9hPPRPOME3uBiOyek3p mtRCl2eqEWEizlvN2cTu7DPzf4fM3n7z5DLmeTvLpO7J+s0TV+wl/4QcODHLGzup04yWy9kr aK5LWEyflElTe/bS+XxmJgnLnR8byxgdpmcmnp2Xz8CTLWWcJZdGxaUz+809qsJymrwPH79L 0eQ5ocu8dPm5hfV3mGekcaYMXOILw0+T7wmNTKhJjULSsn4zi7wbn6tmLKbyeNeEeUXu8ElL G+excfqHJzwnlI5xhyfE7fh9yTtbKiCzhv+inD4uL3VeRmT8jd8VpHLeOGcQvMYddExaXMjv HluPodfE6O4xs6Rhf2NXhcz4GM+mk2PonVY0Hh8b5Nov9VzqLDTu7CITVmOcNF7p1d6LfBC+ yN7jksX6gvJezmeeJeK+w3hCSeWBd+P9lDxjT+rmeTr5XEzJu9SPhrWMFUTNs/xy+zjlMe0i W3f+U9qOW/nSGbzm/VuH2ZqokW6ehFGcPSkJ4vlJvHcSTyrFeBoUb5UXA1+JJ4NVoFaCUolL fGuygxpNzkr0LkXPchNfiWeIlXLUVbQCTxQChPR/7qz775+Mqb6Ki6w3dh42D4T0Ts2rq19U m7t1dVOwNxgFSa0LhkPBsBb1B3vVUMBbrtZrUe0fMFUIYer2YCAmKBF1Qy/GLV29urIMRVW5 WhsIqNv8Xd3RiLpNj+jhPt3X7O/RI+pmvV/dFuzRerfpXbGAFk5NUH1Rt2r2V+/UwxExaVX5 qiq1eJPfGw5Ggp3RxRfxT2STXeiRHU3bNzVfxPuQ2hzWfHqPFt6jBjvfcZ1qWO/yR6J6WPep /l41CtYd29UmLaouVJs3qVs6O8tVrden6oGI3t8NtvIxSbBQsCushboHJpJ0tT6s9ft7u8RY P5xRpm6Par0BfQA6hP2RYG+putPvjQbD6kYt7NN7ozDrsqrmbn8EugiVtY6ArkZTvuz0hyNR VQuFdM3UUbCLWizLWDjWuDHY68OKevX+SEgL6eFStRMz9Hf7vd2qP6r2axHVp0f8Xb26r1xV N0TVblAisY6IfkMMOgQG1A7dG+zR1WCvLuQJQ/QHwwFfRO0JQoFIzOvVI5HOWECqpnrDurRh BNKEIlhal79XC6g+Y/URtR/GUnvgBjXW69PDF1thERTyh3WvdETHwMU2gQPG1mcoDI16IbRX YOFgrKsbflH1G6N6b8Tfp2ORuvAqsFA4KFSFifqCgT7hic5YGKPDYkF7hOVS/oIOl/EYplur RWDroJAPW0KHXsS5qTgs51O9MHfMGwVTLCJGNunhkB6NaTJWmgJab9QPP/sNMyMiB9RgwKdG ogNwrbdbC2sYC2lRvzeidsQM/2g+LSQkRoNql1iHfqNXDwTEggOI0Q5/wB8dwMSxUABM/f5o t9oVDCIyoUuwZwBaX+f36XBkLGLESUcwuCciFerRurSb/L16xIiKsI4dEEUjaESoL+iNGUsU zFogEpRsPn8kFNAGDKKvTw9H/WKt5d3RaKi6oqK/v7+8xzRkOUKnojvaE6joiYp/FVjRE2mL CtchHsNiR5aLznc5sF8PiEiUQzZvad7QsKGutnnDls3qlgZ144Y6z+btHrV23TaPZ5Nnc7Mj w5Eh987YhhF4t4wCuA4WQzBfZsvKVfmxZFhLhN9AMCZGeoN9MhUYISvkwE89codpagDG6gW7 1hXWdWGwcrUVw7o1OCvYEdVgYXhvkjIik/Vj46q6X0agEfJwUifMMq4XrB0NdulGkArPjo2D E6JhP0IEoqGmuTsnBLCpFHbJmCnGBgPX1D4tEJMpRYtE9OjE0eXqDuxI7JSB1CqwJjMTIgg1 NRLSvX6EyKUrV2FFEeNdcqzm8/nFPsb2D8szoVSQw9K2MpdcpFTA3+M3I13yiX0ZiRo5WUSe JAb7kaBjHQF/pFvMA1mGuXsQktAfrgoNqEaYmhaaPJG0x4bO8cWJXYhkF5HTYNN49XCvuYKw qbdkjnQHY9isYb3PjwNFxMClyxd88KSOfWruRcE3tkaohQmi2OXjPhYL00ytOy8vVqo8NsCL /NahpwRhHi1aLRh2bK/FoVK8avnKxerKpavKKpdXVqan72gEsXLp0uXLUa5ctlJdedWK1StW OzLeZte942YUrQpTPbkP8bAclI+Z4rFAPCQOMAduPXbjFuTX8sYl1Zf68s9nfHHHP8WH+Ff5 KcAJfpI/fOXFypUXK1derFx5sUJXXqxcebFy5cXKlRcrV16sXHmxcuXFypUXK1derFx5sXLl xcqVFyv/T75YmfTtxziuSf7L9b100Rh90vcixp335WUGZIRPaFvmW5ZaGi3rLO9BuXrSDCIH v52UzXLPiNxjrL6bxdn9nOS+qAVXWJ55Qqe3l3B5fOzfm1OyAOIv8zmRPM1fGvZ4qtwjqEvK ZZ0oXlwlOxJz5lZ9lb+kPIxzwgnCucTMfNnzYmLtWhO5apWBDC8pqzpXm8FfpD8CFP4iP4c4 k6OGi8urLtQ6QGD8A5TFGDnpCP8ZxQEKuflPhxcsrDp8in8H/c/wp6GpGPZ0wpFTBYH/zr9C ueTkj/PHzJ7HhqfmVFFthN9FjE6jPAs4D7gAsFCQP0j7AAcBxwEWykLpBFQAtggKP8aPQc+j 4p+yo6wABAEHARZq5l8CfY8o+UN8NxVi7J38EM1AfYB/TNZfQD0H9edAn4/6frRFfdhsfxq1 6P+USb8X7ZmoP2nWnwA9H/U98ofkTv5xs93HY3Jc1KyP8EhivjO7dj76VUAlgAM7BOwQTHdI OBgl47fygJxpCHUV6h6jhrluThS4pI9uHp41u+oITHozTH8zLHczLHczWdC1N8Wz1+Ap43vB sxc8e8GzF1ap5BHMFxE/ZUCZDVABHHaPwO6CHkd5GnBW0j+I8m7AEdHi/bDjYmj1Yb47UexE kHUNr3ZXrXmCd8LUbt45PHte1cHxVnqGCETUU806S/DqslcfTp8iqPrwnHlGDa49tVO5l94P UGg6ygWA5YB6gIV7EwsqnCf5ZupJI/dU5z5lH99n2We1VNaz3FO8iprSCCGZy8uoBgyLnW01 bGV7eih9fzrPTlfTK9Pd6U3p1iDfxw9y7uQVfA3fwtu4dSR5OmGvXobKvc5WvezuzCOZ8czT mWczrXHbadtZ23nbBZtVtVXa3LYmW7stZNtvu9t2xJZ+t+1uu9KeGcrcn8mzM9XMykx3ZlOm 1WlnR2pv4x3ipwwoswEhwN0AC2zcBrrK3wdogzfaYIr3gU4oCa1swFng51Fb0coCXxb4skDN AjVL/v4mS/Y0AdoBIbPXNtaTGiP4L4gewCL0TgVV/HjgPMoLAgNci5YDLQdaDnCdVd6Ehtko VUATgEvaeQCiBmWqr9LsbwfYZP8FyZPqc4uxyptubdHpxSy+mB1ZzO5ezNw1a2qr3IUocnNz 21xtRW3FbUctQVewKFgcPGrZ4tpStKV4y1HLGteaojXFa45aKlwVRRXFFUctTpezyFnsPGo5 uPH4xlMbz2y0tG0Mbty3ka+E64YTJZVVsi4sEvVjidlzqlZm1b5HOY7ltKE8DDgH4JSF0gmo AKwBBAFW5bikPgLqI6A+QlsAbQArRj0iUgxKp9kn6Idln8BEvzKpn2PxDyeql22p3Yi02wY4 DOCQ/TD6H5bcBnZc0uMoz0v6FpP/iKQLLicgNU4kwV0y3e3CNtxFawBtgBDASmf4dXQOAOko nYAQ4DjAwnfhuo5fpzyC62HlYV7qdiyd4aSZM3F85OakZddmK1MQCw72kCw/KcsPy3KNLBe4 p17reONax9eudXzoWsciIEoxDjYHOyTLAndmrePRWseWWsfiWgekzaICcigzZGkTJfutLDfL stQ9vcDxtwLHnwscfypwfLbAcUOB4z0FYtxc7GGHMl2WmaJk98jyWlkudGc6Hd9yOq5zOlY6 HbUOdh/D7LRWlvNlmS9K9uqjWfVZlP4Ee5XqIYklahY7RxSSFUsmampRjSZq1qF6K1FzH6r/ TNR8zPkk+xuTRxt7I7HgFWftDPYa22AR7T+b9Z/YBjqG+gLqLtQPUA0rQv2FRM0tgv/zGP8p tD9HhWmC/35qkuMOsw2S/llz3GcSpR2Y9dOJ0gHM+ikqlbN+IlH6CqgfS5R+GNVHE6UBVAcT RULB3YmaJc7aHNZFCxTB66UiRWiy0ZxxPSQHUK8zBnsSpWJUvZhghNUlXEtRLRJaPslc1CSn cyZccpHzyCVFzCWXVDqfimQ9lWVJ5R1UKOu0hOsWSLE9WvSK8y81T4iF0+ssK3Gf8+Unsb6d aP4ftiFxzPnsCWGuhPNM6Qgretz5PdcTzm8uGGE7E87TpSNp6DhVOqKwx5xDMHIcvAp73Hm8 tMv5iEv2HnWhF64+XFPm/LRrl/PeIrQTzltKnxRqUA9WvBPdraXXODfWHHM2FI0wdLtrMJk7 w1ntCjtXg7xqhG0YPuZcumBEqFIJGccedy7BjAtdUpUdK08qK8jOYu5Se9TeYd9p32q/2r7M XmZX7fPsc+3T03LTstOmpk1Jy0hLS7OlWdKUNEqbPpI87y4Rv5+bbsuW/3WGRZQWiWcrolSM nxIqLE3B3olP441K4/a1LJ7bSI3Na+MrSxpH7Mlt8VUljfG0pve2DDH2kVa04sodI4yaWxCg gnRbvvjR9AlirOK2u/JFvfe2u1pbWWP8tJcaO9T4G9uxjoytu+JW19o8mtm3Jm9N7jU5qxvq L1O0m2XJ+CevZOInb178nsbtLfEvzWuNVwkkOa+1Mb5O/Nz6hHKDEvTUn1BComptOcFuUm7w bBN0dlN96xgbFSohsFGNqATbMBUKNipkw5Jto2RDmBZ66ocKCw2mp9gGwYTweUoydRmyFmAK yGoSFdiU+bRAylqgzBdsiAdDWNZEYVOIZUlhWVNICpsrmIaKisBSWiRYhlYWgWGoaKXsPjbe 7Soy1GmlIjlPEWuV8zA2zlNs8CAKTB4lDTwl/5Mffe0/wcyGtRd8XvGj93aXRwe0xw/0defF 93eo6pDvBfPX8AvbO7zdotb0+AsuvT7uc9WrQ5r3Mt1e0a256ofI62luGfK69fqE5tY8Lq2+ dfiBfXWNk+b68NhcdfsuI2yfEFYn5nqg8TLdjaL7ATFXo5irUcz1gPsBOVfjtrWssallKI3W ttZdb9TDSmYG9kN7fkHr2pnZoWvk5ri6IO8D+ScthGMrs6Q1PsW1Nu4AiK6y2rJa0YXdKbqm iv/WwOzK+8DVBfkn2UNmVzbIOa61VEJ5Hn/92F8kEokKiMVKUEZjeZIWxaYt2N4YbxA/wq6J 13ji7vb6VibcETM/dS3u7FM1Z2qUYM2+moM1h2uO11hjsVaQc08VnilU2gqDhfsKDxYeLjxe aBMd17c87q45XPjHQh5DNLEoPp56OWcMNf5EMxqLiA9hggjAmK4kVlLXUltIXtz1Mtyhl9E0 gAuwDLAdYKX/hfIHgJcBfwZY6FaUHwN8HjAsKLyMl3ny/PVixtYSkXTyeNVw5YqqVSOotU6j 3r7LqD2bjbqmtioPdWLNsozaLNyAMzqJ8hnATwG/AfwnwMqreJUUHjOitjVCkRIG9QmNqCgi JVFWAoQJc0cjJSUkQAQ4PADWEjY57olFYgRTwCGowCSpETEsJurU578Ac4A+HgplbmRzdHJl YW0KZW5kb2JqCgo1NSAwIG9iago4NTA0CmVuZG9iagoKNTYgMCBvYmoKPDwvVHlwZS9Gb250 RGVzY3JpcHRvci9Gb250TmFtZS9CQUFBQUErVGltZXNOZXdSb21hblBTTVQKL0ZsYWdzIDQK L0ZvbnRCQm94Wy01NjggLTMwNiAyMDI3IDEwMDZdL0l0YWxpY0FuZ2xlIDAKL0FzY2VudCA4 OTEKL0Rlc2NlbnQgLTIxNgovQ2FwSGVpZ2h0IDEwMDYKL1N0ZW1WIDgwCi9Gb250RmlsZTIg NTQgMCBSPj4KZW5kb2JqCgo1NyAwIG9iago8PC9MZW5ndGggMjIxL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nF2QQU/EIBCF7/yKOe4eNtCemyZmzSY96BqrP4DCtJLYgUzpof/e KVZNPEDyeO+DN+hr99hRyPqFo+sxwxjIMy5xZYcw4BRIVTX44PKhyu5mm5QWtt+WjHNHY2wa pV/FWzJvcHrwccCz0nf2yIEmOL1fe9H9mtInzkgZjGpb8DjKPU82PdsZdaEunRc75O0iyF/g bUsIddHVdxUXPS7JOmRLE6rGmBaa261VSP6fdxDD6D4sS7KSpDG1KdnjdKf2sX7agFuZpUmZ vVTYHw+Ev9+TYtqpsr4AfVltdQplbmRzdHJlYW0KZW5kb2JqCgo1OCAwIG9iago8PC9UeXBl L0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9CYXNlRm9udC9CQUFBQUErVGltZXNOZXdSb21hblBT TVQKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAxCi9XaWR0aHNbNzc3IDI1MCBdCi9Gb250RGVz Y3JpcHRvciA1NiAwIFIKL1RvVW5pY29kZSA1NyAwIFIKPj4KZW5kb2JqCgo1OSAwIG9iago8 PC9GMSA1OCAwIFIvRjIgNDggMCBSL0YzIDQzIDAgUi9GNCA1MyAwIFIKPj4KZW5kb2JqCgo2 MCAwIG9iago8PC9Gb250IDU5IDAgUgovUHJvY1NldFsvUERGL1RleHRdCj4+CmVuZG9iagoK MSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDM4IDAgUi9SZXNvdXJjZXMgNjAgMCBSL01l ZGlhQm94WzAgMCA3OTQgNTk1XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJH Qi9JIHRydWU+Pi9Db250ZW50cyAyIDAgUj4+CmVuZG9iagoKNCAwIG9iago8PC9UeXBlL1Bh Z2UvUGFyZW50IDM4IDAgUi9SZXNvdXJjZXMgNjAgMCBSL01lZGlhQm94WzAgMCA3OTQgNTk1 XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50 cyA1IDAgUj4+CmVuZG9iagoKNyAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDM4IDAgUi9S ZXNvdXJjZXMgNjAgMCBSL01lZGlhQm94WzAgMCA3OTQgNTk1XS9Hcm91cDw8L1MvVHJhbnNw YXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyA4IDAgUj4+CmVuZG9iagoK MTAgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAzOCAwIFIvUmVzb3VyY2VzIDYwIDAgUi9N ZWRpYUJveFswIDAgNzk0IDU5NV0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VS R0IvSSB0cnVlPj4vQ29udGVudHMgMTEgMCBSPj4KZW5kb2JqCgoxMyAwIG9iago8PC9UeXBl L1BhZ2UvUGFyZW50IDM4IDAgUi9SZXNvdXJjZXMgNjAgMCBSL01lZGlhQm94WzAgMCA3OTQg NTk1XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250 ZW50cyAxNCAwIFI+PgplbmRvYmoKCjE2IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMzgg MCBSL1Jlc291cmNlcyA2MCAwIFIvTWVkaWFCb3hbMCAwIDc5NCA1OTVdL0dyb3VwPDwvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDE3IDAgUj4+CmVu ZG9iagoKMTkgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAzOCAwIFIvUmVzb3VyY2VzIDYw IDAgUi9NZWRpYUJveFswIDAgNzk0IDU5NV0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9E ZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMjAgMCBSPj4KZW5kb2JqCgoyMiAwIG9iago8 PC9UeXBlL1BhZ2UvUGFyZW50IDM4IDAgUi9SZXNvdXJjZXMgNjAgMCBSL01lZGlhQm94WzAg MCA3OTQgNTk1XS9Bbm5vdHNbCjM3IDAgUiBdCi9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NT L0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAyMyAwIFI+PgplbmRvYmoKCjI1IDAgb2Jq Cjw8L1R5cGUvUGFnZS9QYXJlbnQgMzggMCBSL1Jlc291cmNlcyA2MCAwIFIvTWVkaWFCb3hb MCAwIDc5NCA1OTVdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1 ZT4+L0NvbnRlbnRzIDI2IDAgUj4+CmVuZG9iagoKMjggMCBvYmoKPDwvVHlwZS9QYWdlL1Bh cmVudCAzOCAwIFIvUmVzb3VyY2VzIDYwIDAgUi9NZWRpYUJveFswIDAgNzk0IDU5NV0vR3Jv dXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMjkg MCBSPj4KZW5kb2JqCgozMSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDM4IDAgUi9SZXNv dXJjZXMgNjAgMCBSL01lZGlhQm94WzAgMCA3OTQgNTk1XS9Hcm91cDw8L1MvVHJhbnNwYXJl bmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAzMiAwIFI+PgplbmRvYmoKCjM0 IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMzggMCBSL1Jlc291cmNlcyA2MCAwIFIvTWVk aWFCb3hbMCAwIDc5NCA1OTVdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdC L0kgdHJ1ZT4+L0NvbnRlbnRzIDM1IDAgUj4+CmVuZG9iagoKNjEgMCBvYmoKPDwvQ291bnQg MTIvRmlyc3QgNjIgMCBSL0xhc3QgNzMgMCBSCj4+CmVuZG9iagoKNjIgMCBvYmoKPDwvQ291 bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMT4KL0Rlc3RbMSAw IFIvWFlaIDAgNTk1IDBdL1BhcmVudCA2MSAwIFIvTmV4dCA2MyAwIFI+PgplbmRvYmoKCjYz IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAw MzI+Ci9EZXN0WzQgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgNjEgMCBSL1ByZXYgNjIgMCBS L05leHQgNjQgMCBSPj4KZW5kb2JqCgo2NCAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYw MDUzMDA2QzAwNjkwMDY0MDA2NTAwMjAwMDMzPgovRGVzdFs3IDAgUi9YWVogMCA1OTUgMF0v UGFyZW50IDYxIDAgUi9QcmV2IDYzIDAgUi9OZXh0IDY1IDAgUj4+CmVuZG9iagoKNjUgMCBv YmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzND4K L0Rlc3RbMTAgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgNjEgMCBSL1ByZXYgNjQgMCBSL05l eHQgNjYgMCBSPj4KZW5kb2JqCgo2NiAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUz MDA2QzAwNjkwMDY0MDA2NTAwMjAwMDM1PgovRGVzdFsxMyAwIFIvWFlaIDAgNTk1IDBdL1Bh cmVudCA2MSAwIFIvUHJldiA2NSAwIFIvTmV4dCA2NyAwIFI+PgplbmRvYmoKCjY3IDAgb2Jq Cjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzY+Ci9E ZXN0WzE2IDAgUi9YWVogMCA1OTUgMF0vUGFyZW50IDYxIDAgUi9QcmV2IDY2IDAgUi9OZXh0 IDY4IDAgUj4+CmVuZG9iagoKNjggMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAw NkMwMDY5MDA2NDAwNjUwMDIwMDAzNz4KL0Rlc3RbMTkgMCBSL1hZWiAwIDU5NSAwXS9QYXJl bnQgNjEgMCBSL1ByZXYgNjcgMCBSL05leHQgNjkgMCBSPj4KZW5kb2JqCgo2OSAwIG9iago8 PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2QzAwNjkwMDY0MDA2NTAwMjAwMDM4PgovRGVz dFsyMiAwIFIvWFlaIDAgNTk1IDBdL1BhcmVudCA2MSAwIFIvUHJldiA2OCAwIFIvTmV4dCA3 MCAwIFI+PgplbmRvYmoKCjcwIDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZD MDA2OTAwNjQwMDY1MDAyMDAwMzk+Ci9EZXN0WzI1IDAgUi9YWVogMCA1OTUgMF0vUGFyZW50 IDYxIDAgUi9QcmV2IDY5IDAgUi9OZXh0IDcxIDAgUj4+CmVuZG9iagoKNzEgMCBvYmoKPDwv Q291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMTAwMzA+Ci9E ZXN0WzI4IDAgUi9YWVogMCA1OTUgMF0vUGFyZW50IDYxIDAgUi9QcmV2IDcwIDAgUi9OZXh0 IDcyIDAgUj4+CmVuZG9iagoKNzIgMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAw NkMwMDY5MDA2NDAwNjUwMDIwMDAzMTAwMzE+Ci9EZXN0WzMxIDAgUi9YWVogMCA1OTUgMF0v UGFyZW50IDYxIDAgUi9QcmV2IDcxIDAgUi9OZXh0IDczIDAgUj4+CmVuZG9iagoKNzMgMCBv YmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMTAw MzI+Ci9EZXN0WzM0IDAgUi9YWVogMCA1OTUgMF0vUGFyZW50IDYxIDAgUi9QcmV2IDcyIDAg Uj4+CmVuZG9iagoKMzggMCBvYmoKPDwvVHlwZS9QYWdlcwovUmVzb3VyY2VzIDYwIDAgUgov TWVkaWFCb3hbIDAgMCA3OTQgNTk1IF0KL0tpZHNbIDEgMCBSIDQgMCBSIDcgMCBSIDEwIDAg UiAxMyAwIFIgMTYgMCBSIDE5IDAgUiAyMiAwIFIgMjUgMCBSIDI4IDAgUiAzMSAwIFIgMzQg MCBSIF0KL0NvdW50IDEyPj4KZW5kb2JqCgozNyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5 cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMTQ0LjYgMTAyLjMgMzQ2LjEgMTI0LjNdL0E8 PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3d3dy5leGFtcGxlLmNvbS8pPj4KPj4K ZW5kb2JqCgo3NCAwIG9iago8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMzggMCBSCi9PcGVuQWN0 aW9uWzEgMCBSIC9YWVogbnVsbCBudWxsIDBdCi9PdXRsaW5lcyA2MSAwIFIKPj4KZW5kb2Jq Cgo3NSAwIG9iago8PC9BdXRob3I8RkVGRjAwNkEwMDY1MDA2NjAwNjYwMDIwMDA2ODAwNkYw MDY0MDA2NzAwNjUwMDczPgovQ3JlYXRvcjxGRUZGMDA0OTAwNkQwMDcwMDA3MjAwNjUwMDcz MDA3Mz4KL1Byb2R1Y2VyPEZFRkYwMDRGMDA3MDAwNjUwMDZFMDA0RjAwNjYwMDY2MDA2OTAw NjMwMDY1MDAyRTAwNkYwMDcyMDA2NzAwMjAwMDMzMDAyRTAwMzE+Ci9DcmVhdGlvbkRhdGUo RDoyMDEwMTEwODE4MjI1MC0wOCcwMCcpPj4KZW5kb2JqCgp4cmVmCjAgNzYKMDAwMDAwMDAw MCA2NTUzNSBmIAowMDAwMDUxNTE2IDAwMDAwIG4gCjAwMDAwMDAwMTkgMDAwMDAgbiAKMDAw MDAwMDQ0MSAwMDAwMCBuIAowMDAwMDUxNjYwIDAwMDAwIG4gCjAwMDAwMDA0NjEgMDAwMDAg biAKMDAwMDAwMTA0NCAwMDAwMCBuIAowMDAwMDUxODA0IDAwMDAwIG4gCjAwMDAwMDEwNjQg MDAwMDAgbiAKMDAwMDAwMTg1NiAwMDAwMCBuIAowMDAwMDUxOTQ4IDAwMDAwIG4gCjAwMDAw MDE4NzYgMDAwMDAgbiAKMDAwMDAwMjcwOSAwMDAwMCBuIAowMDAwMDUyMDk0IDAwMDAwIG4g CjAwMDAwMDI3MzAgMDAwMDAgbiAKMDAwMDAwMzQ2NCAwMDAwMCBuIAowMDAwMDUyMjQwIDAw MDAwIG4gCjAwMDAwMDM0ODUgMDAwMDAgbiAKMDAwMDAwNDA3OCAwMDAwMCBuIAowMDAwMDUy Mzg2IDAwMDAwIG4gCjAwMDAwMDQwOTkgMDAwMDAgbiAKMDAwMDAwNTEwOCAwMDAwMCBuIAow MDAwMDUyNTMyIDAwMDAwIG4gCjAwMDAwMDUxMjkgMDAwMDAgbiAKMDAwMDAwNjMwOCAwMDAw MCBuIAowMDAwMDUyNjk2IDAwMDAwIG4gCjAwMDAwMDYzMzAgMDAwMDAgbiAKMDAwMDAwNjg5 MyAwMDAwMCBuIAowMDAwMDUyODQyIDAwMDAwIG4gCjAwMDAwMDY5MTQgMDAwMDAgbiAKMDAw MDAwNzM4MSAwMDAwMCBuIAowMDAwMDUyOTg4IDAwMDAwIG4gCjAwMDAwMDc0MDIgMDAwMDAg biAKMDAwMDAwODE0NiAwMDAwMCBuIAowMDAwMDUzMTM0IDAwMDAwIG4gCjAwMDAwMDgxNjcg MDAwMDAgbiAKMDAwMDAwODY0MiAwMDAwMCBuIAowMDAwMDU1MTA2IDAwMDAwIG4gCjAwMDAw NTQ5MzAgMDAwMDAgbiAKMDAwMDAwODY2MyAwMDAwMCBuIAowMDAwMDA5NjUxIDAwMDAwIG4g CjAwMDAwMDk2NzIgMDAwMDAgbiAKMDAwMDAwOTg2MyAwMDAwMCBuIAowMDAwMDEwMTYzIDAw MDAwIG4gCjAwMDAwMTAzMjggMDAwMDAgbiAKMDAwMDAzMjM2NSAwMDAwMCBuIAowMDAwMDMy Mzg4IDAwMDAwIG4gCjAwMDAwMzI1NzggMDAwMDAgbiAKMDAwMDAzMzE3MSAwMDAwMCBuIAow MDAwMDMzNTk4IDAwMDAwIG4gCjAwMDAwNDE0MTcgMDAwMDAgbiAKMDAwMDA0MTQzOSAwMDAw MCBuIAowMDAwMDQxNjM5IDAwMDAwIG4gCjAwMDAwNDE5NDkgMDAwMDAgbiAKMDAwMDA0MjEy NiAwMDAwMCBuIAowMDAwMDUwNzE3IDAwMDAwIG4gCjAwMDAwNTA3MzkgMDAwMDAgbiAKMDAw MDA1MDkzOSAwMDAwMCBuIAowMDAwMDUxMjMwIDAwMDAwIG4gCjAwMDAwNTEzOTggMDAwMDAg biAKMDAwMDA1MTQ2MSAwMDAwMCBuIAowMDAwMDUzMjgwIDAwMDAwIG4gCjAwMDAwNTMzMzcg MDAwMDAgbiAKMDAwMDA1MzQ1OCAwMDAwMCBuIAowMDAwMDUzNTkxIDAwMDAwIG4gCjAwMDAw NTM3MjQgMDAwMDAgbiAKMDAwMDA1Mzg1OCAwMDAwMCBuIAowMDAwMDUzOTkyIDAwMDAwIG4g CjAwMDAwNTQxMjYgMDAwMDAgbiAKMDAwMDA1NDI2MCAwMDAwMCBuIAowMDAwMDU0Mzk0IDAw MDAwIG4gCjAwMDAwNTQ1MjggMDAwMDAgbiAKMDAwMDA1NDY2NiAwMDAwMCBuIAowMDAwMDU0 ODA0IDAwMDAwIG4gCjAwMDAwNTUyNTAgMDAwMDAgbiAKMDAwMDA1NTM1MiAwMDAwMCBuIAp0 cmFpbGVyCjw8L1NpemUgNzYvUm9vdCA3NCAwIFIKL0luZm8gNzUgMCBSCi9JRCBbIDw4MDBE QTEzQkNEOUMyRTIzRjhDQTEyRTk0MjdCNzk5Mz4KPDgwMERBMTNCQ0Q5QzJFMjNGOENBMTJF OTQyN0I3OTkzPiBdCi9Eb2NDaGVja3N1bSAvRjdDMjNENDhCRjFDNDY5MUI2Q0I1RTNBNTcw NUZGRTkKPj4Kc3RhcnR4cmVmCjU1NjAxCiUlRU9GCg== --------------030907040904010606070906-- From Jeff.Hodges@KingsMountain.com Mon Nov 8 20:46:13 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FD93A6452 for ; Mon, 8 Nov 2010 20:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.343 X-Spam-Level: X-Spam-Status: No, score=-99.343 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-6JjxBAfrZS for ; Mon, 8 Nov 2010 20:46:12 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 634343A6869 for ; Mon, 8 Nov 2010 20:46:11 -0800 (PST) Received: (qmail 27349 invoked by uid 0); 9 Nov 2010 04:46:34 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 9 Nov 2010 04:46:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:X-Identified-User; b=bbxtJkTThG0oH/kOj7CjEXs+w+HNJnu/RqxTEZNbrYrHFCF4pjFUZFE7uIUN4J6JKxJyRQD/MtDywdkCTFRZfwWOOq2h1S4mdVLzSj6JdH1Y6KR2vjLs7lXVp1bi6r4d; Received: from dhcp-749c.meeting.ietf.org ([130.129.116.156]) by box514.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PFg6L-0002Sl-Fy for websec@ietf.org; Mon, 08 Nov 2010 21:46:34 -0700 Message-ID: <4CD8D225.5050300@KingsMountain.com> Date: Mon, 08 Nov 2010 20:46:29 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF WebSec WG Content-Type: multipart/mixed; boundary="------------040706050003080601060609" X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.116.156 authed with jeff.hodges+kingsmountain.com} Subject: [websec] hodges-ietf-79-websec-HSTS-Status X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 04:46:13 -0000 This is a multi-part message in MIME format. --------------040706050003080601060609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached preso for this afternoon. Also, if anyone feels it'd be needed/worthwhile, I could give this HSTS overview preso (or folks can just go read it).. http://www.thesecuritypractice.com/the_security_practice/presentations/Hodges-StrictTransportSecurity-STS-2009-12-10.pdf =JeffH --------------040706050003080601060609 Content-Type: application/pdf; name="hodges-ietf-79-websec-HSTS-Status.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="hodges-ietf-79-websec-HSTS-Status.pdf" JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nJWTTWvDMAyG7/4VOhfsyV+xDcXQj/SwWyGww9ht7cbYButl f3+S3Kbd2hxGQCi23sevrASNhW/1BQgajYdUvMkQS6T8sIOHGXwqC/wcXhTyBnwoLkqSv0PL SevoBc9J231V+5nA+SHCclC+UH3gsuEZ7jaEDjDs52jr8Kb6QW2v6qOJ/xGETC355KkDETgI LHhkhbZzdJWClzRgrNrPseOlJEtZYpG44OWlpKuq3bGupU0orLVU9G2Zavgt0pYez9mMOosX p4j6wkEjtwP7BrLi2br6NNzfatZlZzpwuZhw6tZl6db6IylU23Hk08MUx/tIt/abg40TRUlu EjGrjuywYRNH2kvcgs1T7IAdjfymx+Yq1auL1xc3P2U5dDRiF/Ppyzhji2AX7E0gdlXljtmm TMv2k9QY6AdwrjPlL3VTx+msybFDmRynNOBme4Ru4Qdie7eBCmVuZHN0cmVhbQplbmRvYmoK CjMgMCBvYmoKMzQzCmVuZG9iagoKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyL0Zs YXRlRGVjb2RlPj4Kc3RyZWFtCniclVPBTsMwDL3nK3xGaknsJG2kKtLabQdukypxQNxgIARI 7MLv4ziBhg0mTZUcx7Hfe7FT3Rr4VB+godEtQReo7cEFx/7hEW6v4F0ZSN/hSel0AG8qJXXi v0L2uRZ5oxcnnz6r/ZWAp48RxllR4Hyb0uYHuN4ytIV5P2gT5xe1mdXuJN+17qICsq0Fpz1b qUCwqeJuQBMbHLTTFBvDK6KsU7yfb/5Csj2TWiLmFyBi6vY8eZe6YdGzLdyEws0VDQ0aIwsg cW0WIdaL7STe6yDrSuwodioZk+xyTRa/jhzYVGFfwVZs24yTrNGFB08UZPyxAErMiHCDYm0C lCSUAAo48lX6IsVVmFl7KJX/NFk6RkHzszvqWL8IF2J0sRO7aMv0iL7ss0pRjI7Xc4Ml2106 WOJneDxYzFMLZWpY3Xwqs/vdBz7HXrIIfWldX+W7dNUg18lPJF/So48/9atqplKLY/R1r3K0 THo8aqRef0tbJslDr/6DHXwBhFLevQplbmRzdHJlYW0KZW5kb2JqCgo2IDAgb2JqCjM4MQpl bmRvYmoKCjggMCBvYmoKPDwvTGVuZ3RoIDkgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nJVVS2/bMAy++1foXCCeSMqWDRgCkjg57FYgwA7Dbms3DNuA9bK/P75sK+2arQig yBQfnz5SZGwh/G5+hRh2saWQR2qH0I0d758ewoe78LOBIL+nL02Ug/CjEaWs++/B9myL/BG3 jZ1+bR7v1Ln82MPh0tDI+knULp/DuzO7TuHyOEUol2/N6dLcv9Dv2u4tBpiJdbvYt8ksMCSx +DjhEWLZwRQPhZezbCGVHU0wxmPZ4WQrYlEd0TyWT5f3f4uSBg6SiBibBiGG1d4GloWphD2v jotQcQEJCA4ra19oinNUkWAkxSh446Cyzq8g+6Of4yLOKqZNUQ9hr4JUYJBV7eOp8jbjLGEP Wzi0Y5Xg2bDVQdkQXZWiKp1gXBgVjyu2CjseSi+iVzhVgmiMXIHXBCF7GZZrndl3es6BwnHB WAWe49l2oMyAZB5UjUAR0TVSHHQVnB7u6Ae9czEzdai+7dyoPVxFtdW0BgP/r1t3qR2fl4VC RjC8/J+8JCVQrBJywvE15wNymRKX5lam2PY3yxRiFkBxED0DhIOlAYTkbNdSUtCokffC9+/0 /ijAkykzdPJdkvNYPS1TXQzAdEHPSCyQJNq8JQHdxmJHXAi34l+RzcVIShOhF+QtcjDnjZzx P5ix/rIwE5UZIrsiL0sdoNdkFiQMCvU1My976zmUSqdUJEXbmY3UH2ppLeJ4FJaTvgGsHXHl wfb2SSKBO6RkcirGE7rcpINam49+aXsc6ORYDdNYLL9J8nvtoPKCnsRFOnvbgjVz6jpvAj3b r86WdymJ7yTxIIlfKauYIQdnpUOC4MXtXkm0J66L2xvzxKEEtLvoNS0364Bwlmse0lqQOFHn fWm9HS05IVHmd7nL/p1vThIE4kH8pkmCPOHoWcsQQEKS9R6c65aB6L1qX/dyHwC1bKtg64bW 6LwName0KTPbrKqHBlXj54TqFOupUHkCeR00eCbVQNX3pPHR6mKwnNxqnZDj8oBXHmxwrgNT CtM/zpuv+/AHdxTsgQplbmRzdHJlYW0KZW5kb2JqCgo5IDAgb2JqCjc2NAplbmRvYmoKCjEx IDAgb2JqCjw8L0xlbmd0aCAxMiAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic lVVNi9swEL37V+i8EFeakSwZjCB2kkNvC4YeSm/ttpS20L3073c0I9ly3LgsAWUkzcfTmydZ t0b9aX4rrU66ReV7bINyvSP79Yv68KR+NUal3+vXRqcN9bNJTp7tH0psigWa6NWQ3W/NyxMn Tz/KMM4N9uRvk9v8Wb27UWqr5pdBmzh/b65z87zzd617U4BJFZzuWisRoGyK+DhgiCcz6BBp uMYTDHBOI/ZpGXz8NL//V0IbqLZFJBicDwlBe4zBJ1IsdDRmCAgMgaqccNC97tO/sQyIbX3R wLMxYaO549kFLpEmY+UuG0FmYCpnScABdY4ujWaMGIoL8u6Nx8lo/g88QlWii1Dyc31JCpAd IWFmT7SR0T0gkNnAXpOytmxoXyXHzMO44sgHtlKKN6BbqIOC2a6+RvCEvCOAz2lEDgNvwmGf 0fq39hlJnLs+Z9qAUIUt3+6+SVPVW1y53bfcZ57cel7UcqrofPHNKuJ1WnGVHQbADcewrX6r hFCKLCzfhP7S68ewDlWg7V4FU9a/uz/2ZYNueqRCWe7y5a6wElKC692A55UywBxb0Si8c0BG E/bs5+bUYRlzjfJ6T7BE/6fJR5xB198zlonRUz6KlKveFOlz1Svsk0iOagUg+QOEtlvkD8k+ kL/RPuEDKDGUIDBCM2UtSksMy69jLOkulybxRRCGIZuYJEudMMX5mpaEWMtiK0ESv3QWciXN tqwYH/mJBH7+srXFADkgBZNQ4JAeE95KjgmavrBbchgGyAun15EPnXGN5cOwnA1Xl1Au6/b4 MEa74dOve8unb2ESzvQi8mfP9aVGv5ILFYzr0p90SS6yuqMxL/jy5HAvJemyAPHohciM0Tvc 3zGm7SqQcRGI4MXyqViyPqu/x37ijAplbmRzdHJlYW0KZW5kb2JqCgoxMiAwIG9iago2NzIK ZW5kb2JqCgoxNCAwIG9iago8PC9MZW5ndGggMTUgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nJVUTYvcMAy951f4vDCpLdmJAyEwmSSH3hYCPZTe2m0pbaF76d+vPmwnM7tN dxjwOLL0LD0/ydbO/Kl+G2tOtkbTdlhHE7pA++cv5sOD+VU5w7/nr5XlA/OzYqdW9j+M7ikW 6MNuGz39Vj09CDj/CGFcK+zI37Pb+tm8Wwjam/Wpt25Yv1fzWj2+8A91uCsALZdgm9prBBjP ER97dx5O0MM0QG/jcHK9XXiFhlf0w6f1/WuAPtLdHpHSEDykDOrjHFomxUNDa0oBQVKAeThh b0fr5f6JM+BvXoFskc/UFtjDqV9Uf/3CKOe6znDmf+wEoT2sASNmTt5aA7ZN3dzU4CRb22rW FiRD2eMo+wvvc+bObhUmX9zqs9NQStGy5ZCepCBMiqcrQELa3QHj0LCbAravkSSh5/+RFIFJ wiZLjUgCrv6AJGdbZgm5dxJLELPYSGbn/GzAaXpKLzEAQgDIWWAayOqzgQ4vZEosgbC3g4nJ nzgoiIn5FK1RcYtiCna3F+1rgnv8FLtHlcsgEw4sNs800g4OBQcdt+JdgoPob+SGFyarPO/2 7u6MU/qCKw1BQ83chh75CZIcbHr60GZdLTuBhAH6l8LaX2nxqiFVkiLecKj/3O+wAaaM5l1e TiLGwXVZ07h1jfvnZFLGiGp3w1lqsaXQ43RK7PiaX7SlJIeLcnbUIiCiv69FwLoshdIiGDeR 0VRmgY6cGuRBcK1P1btKULqLyglZtVMuOPcRoajUAzdTKCYAMc1qAi0dMhmlyyK5ks6d6txb uXQZMm5Mg8cz+LhhpOwuaapls17DA77poTsk1zXh7vnjQpdjCrmkKUitW2ZIYWvez4Bie8N0 yJSUCh7NX/hjxCsKZW5kc3RyZWFtCmVuZG9iagoKMTUgMCBvYmoKNjUxCmVuZG9iagoKMTcg MCBvYmoKPDwvTGVuZ3RoIDE4IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyV Uk1rwzAMvftX+FxIpg87icEYliY97FYI7DB227oxtsF62d+fLWVNaUdZMShy9J6enhKo0X6b Lwu2gpptG7jurA8+5/tne7+ynwZtOfsXA6VgP0wBtZK/W80zl/IFlkSrr2a3kubl5A79ZDhk vCuw6cnebHJrZ6ddBEzTmxknsz3D+9pfRXC+dtZDk6MwyLrCeIjYJ4QuQpcqLPwSu/Q43f3V xnVZ0TFncenCWbe+rNyWVThqcpyFmUSYxlRxhJ5cqlSfIw3Qlye6RBFvBeASdiVS1Booz8uk Aw2J44GUX9GoN9pIJBWRuFaS4hikPmK4aJY7/l3Zf81y29TNqdlWJggQlknVnxoQ96AjN+wu j8TXj0TnIzHqgohVFQZYyxTt8gUkJUTdKB4KikQ4Wu64GAOe6/PtQOO1+sbN3Fc2wOEEwEef SRcGtHTSX8EvK9raHxXAyZ0KZW5kc3RyZWFtCmVuZG9iagoKMTggMCBvYmoKMzQ0CmVuZG9i agoKMjAgMCBvYmoKPDwvTGVuZ3RoIDIxIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro MSAxOTkxNj4+CnN0cmVhbQp4nO18e3xU1bX/2mfPIw+GPHgFAsxJhkAgTwIIxFQmJBPA8AgQ MKHeJiczJ8nAJDPOIzEWC15rtUGLt6W29iHYFrVFy2SiNqAt1F/be7UPsK2t7c8K/rTvF7Vq 21vN3O/e50wegNbe3/3j9/n8mJO199prr7322mutvfY5cxii4ZhOU2g/cXJ7e7TQdMYIn+8Q sVxvX1R98LmmXODniezf6Ax19dz1uZtfIEr/ApE10hUY6PzFx99/hCgrD2P6unXN98iq7Klo 3432Vd0grB8dsKP9H2gv6O6J3jiXrU5D+3dopwWCXu1quhpo1msobD3ajaHt2QutaL+Jttqr 9ejvfSbrh0TZc4nKY6FgJOqjBUmiaw6J/lBYD/1lUefraD9q6sBIqo8VEbPJ9v/nH+tHABvJ CZjLD1E+UfIlwCuAX41em3zTuodco7uT5/k0MD9iAlER3UOHaQFdYEvpKTpN19IDVEtNdIjW 0Rk6TlNpgH2bLOSienqIipiTFGqgWcxK99JP6HoK08/pPBVTI73IciHHQyGaSauTv0bZSHck T4Arg+roy3SSBdh2qgC+XillJZj5YPI0zaLi5HeTz6P1Wfo5W5AcovXAfkE5tIj20b9RLu2m Z5IiShZQBz3I9rJfUwG10wHLcstgcg+C6jF6jjUC20QD1ufTH6MARn2ezWKnk+eSv6SvWRjp kPSvdAc0TtBppZzXWY+QSgvpPbSZNPS+n37CprGl3J1clFybvBfUB+lVpUT5FrdDjxLaQG10 F90Pa/yIXqHXWSZbwT7LjuF6lv3B+jx0a6QY3YS99VlY70F6mE6wpWypMkuZBWvNosW0A30H 6SjmH6azrJG1stPs6/yotXJ0TXJ6ckbyl8kkLaEWaHiYvo45XmOV4MEMvJBHLfMtUWvVW7dg hT76DJ2lZ6HHi7D76/RXtgTXS8oHlH3J65IPJX8OXdLISatoK+2iIPVRP30OXn2KvkF/Yn9X 0sF5xvJN603WC8mPwrYLaS103wLu7ZB9AF5K0AiuH2GVOUzFKlaxzWwb62IH2T1shP2E/USx KQXKDcpveJx/m79gucpqTVZD0kyaj3lddB11wwMfgLU/ivU+RN+kp9kMtpCVYUU/wvg3lKuV elyfV84oL/Lb+EHLm9YPjZ4f/e3o35ODZEeUrYMdYvQlWOGPbCZ0WMx2swh7GZrfrTzKp/Js 7uIreC1v5q38Dn6I/wf/niVsOWb5qXWDVbMes2ujvaPPJhuTHySRFWzQaxGV0nJaifjpRDTt gX4hXGHaS7fQIH0E8fJROkLHsO5T9DQ9Rz+j38EDxAqgsx+z9yDqbmMfwXUve5h9nX2TPc1e Ym+ISynEVaxcpaxR6pQGpUu5Ddch5azyI+VXfC738n18P677+OP8JxayWCxJaxWu9dYD1gdt 37YX29fbO9K+8+bv31ryVutbL47S6JzR947eM/r10V8mdyYHoH8RlVE5NL0dWt6LGDyK60uI xMfpW8jdP5a6vsoUZkXE5zEXoqEUXlvD1rENuDaxrbh24LqO7cKlsQ7WjWsf28/+ld3KPsju Yh+X1yextqPsi+xxXF9hJ3E9x86xX7DfsFcVBLHCEc1FyiKlQlmNldYp65QtyjZcXUoQV0gJ K33w0IPKsHJC+RGfxot4Gdf4Dfxe/mX+FP8h/5tFsZRaKiw1lp2WLsutljOWZy3PW/5udVo9 1m7rfdanbPm25bYdtt22T9qO235le9NuszfZO+x77T+0J9OKkK3+Het+bFLKq7CdYRHrdMuN yjnsizwest7OdsBiNqWZB/hH+PetnewCV9lP2SD38z3Jz/MG5a88yHYqp1ghd1qreSfdSUl2 THlJeU35pWUGa1Z+zYot/8a+ogR5nWKTefUHlhmWW62/IlJ+TNXKzey08k1+K781+VWqtt7H zlnvU54l1XJemUbnsKtvVz6BQd9T/MoBarEst/6d/LD7F603wt7XKHewJfyHlvvo59yl/Jld YPcga3yXXWtZoLxPWc2OIeO+xebT79kNFGIfJzd7gv2MjRBjD/EH2UZlCrwVVxxsJQ677/IC 9kOeQa1CR7ZQmcGalAvKDv6k7SxfgaP9LH2fbmKcVSJ2Up9R6sUOOKQsQk7zIJv8gFVRHn0C +f610SdFxrY+bz2AOLufl9I2qqR/Ub5N1dgbP8fVQh+iKjqJGLyDKpVP0t7kfuZD3t+E/KnQ CNtNFSwT2XIWdNuH82KmUohc2IZZ/4r8/wyyfiP7A/UzFTvrNBVbRM+dFg8yUzvy7wFcPvoX tD5DH7U9Zv0BbWGziCzq6H2I8hfofThzXsb8c6gG+u2i+y2l0FpFZr4BIz4zup7cuD5E32YK 3Qydr8E+b7KsR+a9J7kbK/TjjNqIM/Fp8ic/QXXw3bbkrckD1Ja8P3k9ddH25EPIv33JBF1F t1tblZ3WEsty5Nin2TdwHv1vdgB5ez39FPmoiOXRb3B9GRpdY32CBi0/Ru5ck7wz+RzNgD0K YaEOnKKvUA/9AXZbz0/TstHNylCygYdwQp2jrckHk06WQd3JADLvk3TUbkXu2U/zrUfdbvea a95Tc3X16lUrr1qxfFnV0sqK8rLSkiWLixctLFrgKixQnfPnzc2fMztv1szp03JzsrOmOqZk ZqSn2W1WC1cYlXpcDe1qfGF73LLQtX59mWi7NBC0CYT2uApSw2SeuNou2dTJnG5wdl7E6TY4 3WOcLFutoZqyUtXjUuPfrXepI2zX1hbgd9W7WtX47yW+SeJ3S9wBvKAAA1RPXne9Gmftqife 0Nc96Gmvh7ihzIw6V52eUVZKQxmZQDOBxWe5QkNs1jVMIsosT/WQQmkOKBWf46r3xGe76oUG cV7k0Xzxpq0tnvr8goLWstI4q/O6OuLkWhvPKpEsVCenidvq4nY5jeoXq6ED6lDp6cE7R7Kp o71kis/l065viXOtVcyRU4J56+Ozbnolb7wJ4bl1LbdP7M3ng548vyqag4O3q/EjW1sm9haI srUVMuJKUUP7YAMmvhMmbNyuYi7lttaWOLsNE6piHWJNxup0l0dQ2ner8XTXWlf34O52OGbO YJy2DRQk5sxxn0iepzkedbC5xVUQX5PvatXq5w5Np8FtA8Oz3ersyT1lpUPZOYZZh6ZmmcgU x0REH+uTmGQXWOO2MbsyoZFrA8IhrnpVaNLiwppWiUJfRYPeVWDDp5VhVNwHf/jj6XXtg9nV oGeL8XFrUbZLHXyd4H/X7383maKZFFtR9uskUBElY4GG/hQeLymJL1kiAsReB49Cx2tke0VZ ad+IEneFslVUMB81wbZaa3UFjF9QINx7YMRNHWjE929tMdoqdeQnyF1R0hpX2kXP6VTPjB2i Z3+qZ2x4uwtx/Kh8/pgRT1s49peVPXOap7s6zma+Q7du9DdudzVu3dWiegbbTds2Nk9qGf2r xvpMjBkdMHjcUgRLbXAh9LbtahEE/FmLGlwef/t6bDXoGJ9W18LzlVYDU/K5FIX4vX5Msmi0 TBGyLEU2Gf++EXsaAlhSmNoQz25fb5StGQUF73LQSPKCGCWr8WHmmuLVJZPbV09qT1JvyiCH wpaFSmPzrsHBjEl9DUhWg4MNLrVhsH1QG0nu73Cp2a7BE7yFtwyGPO0p948kTx7Ijzfc2YpF dLPqMhzrwjdWXHgyttOmIYU9oXwN94125VSCrJYR5WuPcsqwC+QxRrPTbNZT6FeIs8WUzvaw 91FeSfYbNW/VbM5+rWbTWzW0Bnj2myiWVhbkFOQUoWA4Ed9U+ek33Vb6O+4WTpPxxKo8+7vn Pv1Ma1tWzetps9PkIf25l+c9Nem5TmiGB/GxJ1zU9oJRD+60aZwy6aPYVrO5ioEbj91yLjwZ GESFsvEcVgvZ38WzNJfUdXwXCQsY9wlk4gx3z6MmrtBUNtfEOYXZEhO30Hz2GRO3Uh47aeI2 KmTfN3E7Pc9eM/E0Wqh8x8TT6UPKqyaeYd3JbzTxTAqnfc/Ep1BnutvEHbZH0x8w8al0ffau sbXvy37cxBll5awwcYXsOfUmzml1TqOJW8DzQRO30pScj5m4jXJyDpu4nQI5cRNPo2m5c008 nepyK0w8QzmWGzbxTFo9Y97YtxLLZuw0cQffNePDJj6VyvNehibMIqw+ZXaOxK3CI7PnSdwm 6WUSt0v6aomnSXyDxNOFj2a3mjh8NOc6E4eP5sRMHD6ac6uJw0dzXjdx+Ch/monDR/klJg4f 5W8ycfhobpGJw0dzG00cPpr7rInDR4WLTBw+KrzXxOGjwqSJw0eLhyWeIda1JEvimWItS/Il PkXSDR2mSnylxLPFWpbUSXwa8NwlWyU+XfJ4JT5DyglKfKak75P4bDn2gMTzJY+h2zzJ80WJ OyX+mMQXSP6vS3yJxM9IvEziPxN4mqH/byVuzPUXgU+R9BIucbmWErnGLBE/VJJPzTSAZ00d 990aeVGr9EVAM56SBb4Jz+i9gKjJpeI+OYgn05AsNdD9kkMFJYDx5cDqJV37v5RUMaaZivvX IGixMZ6IvLPuNedbSqtxVeI51MCqJLUWIwKot2FMF3SIylHbIC8CCFMfSh/m8OM+WJd9m1H3 S54gaBrkC+4uzBtAK3zJCqr/wWj1ovHVtFPOHBlbqdB0FUpVPqf4sZ4weiKATsyy+B/Ifztp 46OMMeMjmmDJTeh/Z7lfll4TPvGhr0fqvgc0odV/358qqMIafswalZoL+6toC56oKXUHNFSh pxgvvgET821CuQVzd0q/Cg3FOB1SI1L3blNa+WV0MmIoiHmFTiHwDrwtly5jV/D1S626xub1 mzujTMZiVOoQAGXAtENYrkpILQVlp+SPSrqKpzphP2HJXrkmEaPLpJe65SjDLikra3g2C8i5 opfsS6FHWFpPlWsRvdpFdkxJT7VT3proccOPG6W+PtNHvdKSEcjUpNywXEmnuYZ+qasXpZAb lRRNyvJJmWKH9Uo9hIfE3hQ83SZPBDugQ/rqBmCGHQLSdh1oeWXc6VKvXrPunBAR/VKHAGQL WT1yf0RNqV5pmQiuTrnL1Ak+9UrLaBNyhqFbyiKG17qknTQ51jfJ9xE5txFZqvSPT2IxaTVd 2uWdY2GRaSG/lOGdsCM6JPc7x4mxAy7130QLGzbqNTXtHaOJLBKTWU81M5FON8pd1yu91Sdl +s19aNjIoIXk2JRVjSjqk9m3b2xPCFuHzbnDYx7aMxZzF+8vww7vbo8Zq1srI8eI6+CY/kZc GnboNfP5ZIsbMeeT3jeiOyYtbEiKybUbczZJWUJiFHRtQl5pktm6V9rE2M/+SdFs5MgBqVlA jojIlQbMqOuWftTMecNmvhOri0jPxybtH6Gt2HEpHUU0qDIqDX+IdXtlrguMeThg5tEOQEBq N2CuOCZzrSGpX/Z0S2lBXEbO9Jq+6cEYw9bXgc8nZxgwbTQxn3TIsXtMXQ0LCQt0AW6SPCJS JuYKEevGGRA1e4KTcqhPxldskhdTkjWZ04MTpPmk/ULSJwOTOH3SQmFp25Rfy+U5HwV/Ne4f KmADcZXLrDExIsvNrFMh+XsgvQJlVGYCoZdoRahNyjZ2nZEfw2NnZPnYyP/ZGfulJ1I5cXyW zdglzdj1DYA63NsIfAuoYvc0yOwh6B5QtqMUdz/rcKJ75LeogtpMDsqQMH7uXHrCpOjdE3JB yLTywFhmfnen7Liv/KaXjdhKZb8BGa+pOb3yXdD4XcHELJvSx9hPPRPOME3uBiOyek3pmtRC l2eqEWEizlvN2cTu7DPzf4fM3n7z5DLmeTvLpO7J+s0TV+wl/4QcODHLGzup04yWy9kraK5L WEyflElTe/bS+XxmJgnLnR8byxgdpmcmnp2Xz8CTLWWcJZdGxaUz+809qsJymrwPH79L0eQ5 ocu8dPm5hfV3mGekcaYMXOILw0+T7wmNTKhJjULSsn4zi7wbn6tmLKbyeNeEeUXu8ElLG+ex cfqHJzwnlI5xhyfE7fh9yTtbKiCzhv+inD4uL3VeRmT8jd8VpHLeOGcQvMYddExaXMjvHluP odfE6O4xs6Rhf2NXhcz4GM+mk2PonVY0Hh8b5Nov9VzqLDTu7CITVmOcNF7p1d6LfBC+yN7j ksX6gvJezmeeJeK+w3hCSeWBd+P9lDxjT+rmeTr5XEzJu9SPhrWMFUTNs/xy+zjlMe0iW3f+ U9qOW/nSGbzm/VuH2ZqokW6ehFGcPSkJ4vlJvHcSTyrFeBoUb5UXA1+JJ4NVoFaCUolLfGuy gxpNzkr0LkXPchNfiWeIlXLUVbQCTxQChPR/7qz775+Mqb6Ki6w3dh42D4T0Ts2rq19Um7t1 dVOwNxgFSa0LhkPBsBb1B3vVUMBbrtZrUe0fMFUIYer2YCAmKBF1Qy/GLV29urIMRVW5WhsI qNv8Xd3RiLpNj+jhPt3X7O/RI+pmvV/dFuzRerfpXbGAFk5NUH1Rt2r2V+/UwxExaVX5qiq1 eJPfGw5Ggp3RxRfxT2STXeiRHU3bNzVfxPuQ2hzWfHqPFt6jBjvfcZ1qWO/yR6J6WPep/l41 CtYd29UmLaouVJs3qVs6O8tVrden6oGI3t8NtvIxSbBQsCushboHJpJ0tT6s9ft7u8RYP5xR pm6Par0BfQA6hP2RYG+putPvjQbD6kYt7NN7ozDrsqrmbn8EugiVtY6ArkZTvuz0hyNRVQuF dM3UUbCLWizLWDjWuDHY68OKevX+SEgL6eFStRMz9Hf7vd2qP6r2axHVp0f8Xb26r1xVN0TV blAisY6IfkMMOgQG1A7dG+zR1WCvLuQJQ/QHwwFfRO0JQoFIzOvVI5HOWECqpnrDurRhBNKE Ilhal79XC6g+Y/URtR/GUnvgBjXW69PDF1thERTyh3WvdETHwMU2gQPG1mcoDI16IbRXYOFg rKsbflH1G6N6b8Tfp2ORuvAqsFA4KFSFifqCgT7hic5YGKPDYkF7hOVS/oIOl/EYplurRWDr oJAPW0KHXsS5qTgs51O9MHfMGwVTLCJGNunhkB6NaTJWmgJab9QPP/sNMyMiB9RgwKdGogNw rbdbC2sYC2lRvzeidsQM/2g+LSQkRoNql1iHfqNXDwTEggOI0Q5/wB8dwMSxUABM/f5ot9oV DCIyoUuwZwBaX+f36XBkLGLESUcwuCciFerRurSb/L16xIiKsI4dEEUjaESoL+iNGUsUzFog EpRsPn8kFNAGDKKvTw9H/WKt5d3RaKi6oqK/v7+8xzRkOUKnojvaE6joiYp/FVjRE2mLCtch HsNiR5aLznc5sF8PiEiUQzZvad7QsKGutnnDls3qlgZ144Y6z+btHrV23TaPZ5Nnc7Mjw5Eh 987YhhF4t4wCuA4WQzBfZsvKVfmxZFhLhN9AMCZGeoN9MhUYISvkwE89codpagDG6gW71hXW dWGwcrUVw7o1OCvYEdVgYXhvkjIik/Vj46q6X0agEfJwUifMMq4XrB0NdulGkArPjo2DE6Jh P0IEoqGmuTsnBLCpFHbJmCnGBgPX1D4tEJMpRYtE9OjE0eXqDuxI7JSB1CqwJjMTIgg1NRLS vX6EyKUrV2FFEeNdcqzm8/nFPsb2D8szoVSQw9K2MpdcpFTA3+M3I13yiX0ZiRo5WUSeJAb7 kaBjHQF/pFvMA1mGuXsQktAfrgoNqEaYmhaaPJG0x4bO8cWJXYhkF5HTYNN49XCvuYKwqbdk jnQHY9isYb3PjwNFxMClyxd88KSOfWruRcE3tkaohQmi2OXjPhYL00ytOy8vVqo8NsCL/Nah pwRhHi1aLRh2bK/FoVK8avnKxerKpavKKpdXVqan72gEsXLp0uXLUa5ctlJdedWK1StWOzLe Zte942YUrQpTPbkP8bAclI+Z4rFAPCQOMAduPXbjFuTX8sYl1Zf68s9nfHHHP8WH+Ff5KcAJ fpI/fOXFypUXK1derFx5sUJXXqxcebFy5cXKlRcrV16sXHmxcuXFypUXK1derFx5sXLlxcqV Fyv/T75YmfTtxziuSf7L9b100Rh90vcixp335WUGZIRPaFvmW5ZaGi3rLO9BuXrSDCIHv52U zXLPiNxjrL6bxdn9nOS+qAVXWJ55Qqe3l3B5fOzfm1OyAOIv8zmRPM1fGvZ4qtwjqEvKZZ0o XlwlOxJz5lZ9lb+kPIxzwgnCucTMfNnzYmLtWhO5apWBDC8pqzpXm8FfpD8CFP4iP4c4k6OG i8urLtQ6QGD8A5TFGDnpCP8ZxQEKuflPhxcsrDp8in8H/c/wp6GpGPZ0wpFTBYH/zr9CueTk j/PHzJ7HhqfmVFFthN9FjE6jPAs4D7gAsFCQP0j7AAcBxwEWykLpBFQAtggKP8aPQc+j4p+y o6wABAEHARZq5l8CfY8o+UN8NxVi7J38EM1AfYB/TNZfQD0H9edAn4/6frRFfdhsfxq16P+U Sb8X7ZmoP2nWnwA9H/U98ofkTv5xs93HY3Jc1KyP8EhivjO7dj76VUAlgAM7BOwQTHdIOBgl 47fygJxpCHUV6h6jhrluThS4pI9uHp41u+oITHozTH8zLHczLHczWdC1N8Wz1+Ap43vBsxc8 e8GzF1ap5BHMFxE/ZUCZDVABHHaPwO6CHkd5GnBW0j+I8m7AEdHi/bDjYmj1Yb47UexEkHUN r3ZXrXmCd8LUbt45PHte1cHxVnqGCETUU806S/DqslcfTp8iqPrwnHlGDa49tVO5l94PUGg6 ygWA5YB6gIV7EwsqnCf5ZupJI/dU5z5lH99n2We1VNaz3FO8iprSCCGZy8uoBgyLnW01bGV7 eih9fzrPTlfTK9Pd6U3p1iDfxw9y7uQVfA3fwtu4dSR5OmGvXobKvc5WvezuzCOZ8czTmWcz rXHbadtZ23nbBZtVtVXa3LYmW7stZNtvu9t2xJZ+t+1uu9KeGcrcn8mzM9XMykx3ZlOm1Wln R2pv4x3ipwwoswEhwN0AC2zcBrrK3wdogzfaYIr3gU4oCa1swFng51Fb0coCXxb4skDNAjVL /v4mS/Y0AdoBIbPXNtaTGiP4L4gewCL0TgVV/HjgPMoLAgNci5YDLQdaDnCdVd6EhtkoVUAT gEvaeQCiBmWqr9LsbwfYZP8FyZPqc4uxyptubdHpxSy+mB1ZzO5ezNw1a2qr3IUocnNz21xt RW3FbUctQVewKFgcPGrZ4tpStKV4y1HLGteaojXFa45aKlwVRRXFFUctTpezyFnsPGo5uPH4 xlMbz2y0tG0Mbty3ka+E64YTJZVVsi4sEvVjidlzqlZm1b5HOY7ltKE8DDgH4JSF0gmoAKwB BAFW5bikPgLqI6A+QlsAbQArRj0iUgxKp9kn6Idln8BEvzKpn2PxDyeql22p3Yi02wY4DOCQ /TD6H5bcBnZc0uMoz0v6FpP/iKQLLicgNU4kwV0y3e3CNtxFawBtgBDASmf4dXQOAOkonYAQ 4DjAwnfhuo5fpzyC62HlYV7qdiyd4aSZM3F85OakZddmK1MQCw72kCw/KcsPy3KNLBe4p17r eONax9eudXzoWsciIEoxDjYHOyTLAndmrePRWseWWsfiWgekzaICcigzZGkTJfutLDfLstQ9 vcDxtwLHnwscfypwfLbAcUOB4z0FYtxc7GGHMl2WmaJk98jyWlkudGc6Hd9yOq5zOlY6HbUO dh/D7LRWlvNlmS9K9uqjWfVZlP4Ee5XqIYklahY7RxSSFUsmampRjSZq1qF6K1FzH6r/TNR8 zPkk+xuTRxt7I7HgFWftDPYa22AR7T+b9Z/YBjqG+gLqLtQPUA0rQv2FRM0tgv/zGP8ptD9H hWmC/35qkuMOsw2S/llz3GcSpR2Y9dOJ0gHM+ikqlbN+IlH6CqgfS5R+GNVHE6UBVAcTRULB 3YmaJc7aHNZFCxTB66UiRWiy0ZxxPSQHUK8zBnsSpWJUvZhghNUlXEtRLRJaPslc1CSncyZc cpHzyCVFzCWXVDqfimQ9lWVJ5R1UKOu0hOsWSLE9WvSK8y81T4iF0+ssK3Gf8+Unsb6daP4f tiFxzPnsCWGuhPNM6Qgretz5PdcTzm8uGGE7E87TpSNp6DhVOqKwx5xDMHIcvAp73Hm8tMv5 iEv2HnWhF64+XFPm/LRrl/PeIrQTzltKnxRqUA9WvBPdraXXODfWHHM2FI0wdLtrMJk7w1nt CjtXg7xqhG0YPuZcumBEqFIJGccedy7BjAtdUpUdK08qK8jOYu5Se9TeYd9p32q/2r7MXmZX 7fPsc+3T03LTstOmpk1Jy0hLS7OlWdKUNEqbPpI87y4Rv5+bbsuW/3WGRZQWiWcrolSMnxIq LE3B3olP441K4/a1LJ7bSI3Na+MrSxpH7Mlt8VUljfG0pve2DDH2kVa04sodI4yaWxCggnRb vvjR9AlirOK2u/JFvfe2u1pbWWP8tJcaO9T4G9uxjoytu+JW19o8mtm3Jm9N7jU5qxvqL1O0 m2XJ+CevZOInb178nsbtLfEvzWuNVwkkOa+1Mb5O/Nz6hHKDEvTUn1BComptOcFuUm7wbBN0 dlN96xgbFSohsFGNqATbMBUKNipkw5Jto2RDmBZ66ocKCw2mp9gGwYTweUoydRmyFmAKyGoS FdiU+bRAylqgzBdsiAdDWNZEYVOIZUlhWVNICpsrmIaKisBSWiRYhlYWgWGoaKXsPjbe7Soy 1GmlIjlPEWuV8zA2zlNs8CAKTB4lDTwl/5Mffe0/wcyGtRd8XvGj93aXRwe0xw/0defF93eo 6pDvBfPX8AvbO7zdotb0+AsuvT7uc9WrQ5r3Mt1e0a256ofI62luGfK69fqE5tY8Lq2+dfiB fXWNk+b68NhcdfsuI2yfEFYn5nqg8TLdjaL7ATFXo5irUcz1gPsBOVfjtrWssallKI3WttZd b9TDSmYG9kN7fkHr2pnZoWvk5ri6IO8D+ScthGMrs6Q1PsW1Nu4AiK6y2rJa0YXdKbqmiv/W wOzK+8DVBfkn2UNmVzbIOa61VEJ5Hn/92F8kEokKiMVKUEZjeZIWxaYt2N4YbxA/wq6J13ji 7vb6VibcETM/dS3u7FM1Z2qUYM2+moM1h2uO11hjsVaQc08VnilU2gqDhfsKDxYeLjxeaBMd 17c87q45XPjHQh5DNLEoPp56OWcMNf5EMxqLiA9hggjAmK4kVlLXUltIXtz1Mtyhl9E0gAuw DLAdYKX/hfIHgJcBfwZY6FaUHwN8HjAsKLyMl3ny/PVixtYSkXTyeNVw5YqqVSOotU6j3r7L qD2bjbqmtioPdWLNsozaLNyAMzqJ8hnATwG/AfwnwMqreJUUHjOitjVCkRIG9QmNqCgiJVFW AoQJc0cjJSUkQAQ4PADWEjY57olFYgRTwCGowCSpETEsJurU578Ac4A+HgplbmRzdHJlYW0K ZW5kb2JqCgoyMSAwIG9iago4NTA0CmVuZG9iagoKMjIgMCBvYmoKPDwvVHlwZS9Gb250RGVz Y3JpcHRvci9Gb250TmFtZS9CQUFBQUErVGltZXNOZXdSb21hblBTTVQKL0ZsYWdzIDQKL0Zv bnRCQm94Wy01NjggLTMwNiAyMDI3IDEwMDZdL0l0YWxpY0FuZ2xlIDAKL0FzY2VudCA4OTEK L0Rlc2NlbnQgLTIxNgovQ2FwSGVpZ2h0IDEwMDYKL1N0ZW1WIDgwCi9Gb250RmlsZTIgMjAg MCBSPj4KZW5kb2JqCgoyMyAwIG9iago8PC9MZW5ndGggMjIxL0ZpbHRlci9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nF2QQU/EIBCF7/yKOe4eNtCemyZmzSY96BqrP4DCtJLYgUzpof/eKVZN PEDyeO+DN+hr99hRyPqFo+sxwxjIMy5xZYcw4BRIVTX44PKhyu5mm5QWtt+WjHNHY2wapV/F WzJvcHrwccCz0nf2yIEmOL1fe9H9mtInzkgZjGpb8DjKPU82PdsZdaEunRc75O0iyF/gbUsI ddHVdxUXPS7JOmRLE6rGmBaa261VSP6fdxDD6D4sS7KSpDG1KdnjdKf2sX7agFuZpUmZvVTY Hw+Ev9+TYtqpsr4AfVltdQplbmRzdHJlYW0KZW5kb2JqCgoyNCAwIG9iago8PC9UeXBlL0Zv bnQvU3VidHlwZS9UcnVlVHlwZS9CYXNlRm9udC9CQUFBQUErVGltZXNOZXdSb21hblBTTVQK L0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAxCi9XaWR0aHNbNzc3IDI1MCBdCi9Gb250RGVzY3Jp cHRvciAyMiAwIFIKL1RvVW5pY29kZSAyMyAwIFIKPj4KZW5kb2JqCgoyNSAwIG9iago8PC9M ZW5ndGggMjYgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDM0NDU2Pj4Kc3RyZWFt Cnic1L15YBRF+j9cVd093dNz9RyZO0lPJjMJSSCBXASiGYSACOEGCRLJkAwkkPvgUFBYFRBR 0V0PvABPUJEAAQOyK8uyuh4suLquxyrsiueKsrvIrmJm3qdqJgfq7vf7+73vP2863f10dZ1P fZ6rqgkdbZ0RpEdrEIdCNY3hFsFvRfDzOkLYUrOsQ73nzx3vAX0aIU3eopbFjVc/mmVGSFIQ EroWN6xcdDp9+q8QMhxBqOzDuki4dvSYbBNCFdugjqI6SLgz+jMRnt+B5/S6xo4V6zwLv4bn 76FO0tBcE271BL9FaCpt8+bG8IqWOvlJHp5vhme1KdwYmfby8Vvh+XGEst9oaW7vuBdlxRC6 fgV939IWaXl45SNueL4fIbkX0jAc9EcPpIY+E44XNKKklXV6g9GkmC1WW5Ld4XS5Pd7klFTV l+ZPDwQzModkZecMHZabN3xEfkFhUfHIklGjSy+7vCyE/v/+IxxCLjjdwlPIxQeRE6HYp3B+ Ru/R+thn9D29ky8gc0/iRGgH2oXr0S70IjqKz0Gp3egg6ka/Qw40Dj2EVqFfoPVIg+ZByq1o BhwCpP8Cu2LdKBdtByxtR8ch79XoBnQI2bEz9jm6Ed3CvQmlbkEGlIbGoGmoGd2OJ8c60Xx0 ir8JFaPJqAm14DWxubE7YnfHHkdPoIPc72K9SIfcqAaO47GvhHdif0ZDocQ9aAs6he/W7kch aGUN5HwYtaEHuCoexxbHvoMe+NBy6AOPKtBxfIRkQ+0R9Cl24lXcWKjlsVhX7Bjk8qIqVIce QIdwIZ5AfML8WEXsOLJDGyug1i1oLzoARw/6JXoP64Vzscdj55AL5aCJMJ5u9Ht8hIv2ro2W UUYDl4agEnjTjH6FXkYnsR//mjQLemGEEBKui72FbGg4mg29fQpKfoL/RW6A40buJX587Apk BL7cRbmNfov+gt04F0/Fc8gQ0kwe4dqQBC0Oh6MW1QO/74faP8TZ+ADRkxPcY/wz/EVNcvR0 zAgzEkQPoofRr7EBRqridvwz/Db+iIwlC8iD5K/cL/id/B/EMIz6WtSIbkfPoH9hCx6Jp+Nr cB1ehdfju/AWfByfxJ+RMWQWWUq+5uq4Vu6X/BVwzOTb+ZuEdcJtms+ic6PHom9E/xUbEVuH pgMe1kLv70GPwMgOohPoXThOob9iAeuwEQ4V+/BsfD0cN+Db8aN4B96Ju6GVk/iv+HP8D/wN vkgQHBriIT6SBoeftJHl5BfkIXICjpPkS/It5+DSuGyukCvlKrlm6NV6bjMc+7m/8G7+BB8D Po8Q7hW2CjuEZ4SjwjmNXvyZhKTXv3+sN6v3wyiKbojeG90b7Y79BSXBHLqBC6moFHofhmMJ zPe9gLjd6E2sB965cRa+HE8GzizAS3ArXgGcvBk/gJ9gfX8OHwYu/Ql/DX02EC/r8zBSSK4g U+G4lkRIK9lM7ibd5G3yHSdyOs7EJXFZ3ASuiotwHdxK7l6ui3ud+4D7K3eB+x6OGC/zqXwa H+Sz+Qn8Ar6Tf4T/lP9UmC+8JnyskTWNmnWaHs3fxSLxcnGaOF2sEu8UD4hvSdWAzt+g/ej5 wTKPT3NruXJuP7qD5PMu8nvye8DzAlTLVRBAKtmBN5DVuJukCys0o8loPAWd44PA65fIVnKB jOYq8CQ8Ey0hw+O1aWz803Ar5X+DzvKHYWy/h5pXaPT4BvK1Ro/2YkRKoM3fcnl8Nvcaeo87 hUV+O3qfl7EDnyVPcdMABb/kLxfmIh/3EHqOa8Wr0X5SDhr7orQJcDwFPw16YRYegf/NxRBH pgCKirmP0E1oKXkHnQU53oDuw7X8YnQHyser0KfoSZCKIUKTJkuThF8h9fxGYsXdiPA7YXQl OB1zgg3djKu4BzRfk3dRJzrBy+hD7lno/QnyHFfBnxNm4DqQgNVoHWqNrUUrhbn8H/BixOE5 KMCfBu22ihvB++B+I2iV+aDTDoB0HwI9MIargBQnIGcy4GI2aIgH4Lgf9AQPCKoHGb8atNjv UbdmFulBiwUjBq2DEP9adAaaF3sSbYktRk2xu9FQ0AfrY6ugxh3oY3Qn2oFviV6PWlAKSM6H eLIwnpwQxseGko3kXTKT3Hvp/AK3A9iJvoDjOTQeXS68gDbyf0IzUVlsU+yPgO5M0LBb0EJ0 FToDo/wKWriSO4Lyo1PInth4rgXGewpNjz0VS8Uyqos1gPk9jJ4QBRQWs0NjxoTKLr+sdPSo kpHFhQX5I4bn5Q4bmpOdNSQzIxhI96f51NSUZK/H7XI67Ek2q8WsmIwGvU7WSqJG4DmCUU65 f3y12hWs7uKD/iuvHEqf/WFICA9KqO5SIWn8pXm61GqWTb00ZwhyLvpBzlA8Z6g/J1bUUlQ6 NEct96tdx8f51R48b/pcoG8f569Uu84yuoLRmxltANrngwJqubNunNqFq9XyrvHL6jaWV4+D 6vbo5LH+sRF5aA7aI+uA1AHV5fC37MGOyzEjiKN81B6CJAN0qsvtH1fe5fKPoz3o4gLl4dqu adPnlo/z+HyVQ3O68Nga/8Iu5L+iy5TNsqCxrJkuzdgukTWj1tPRoNvUPTlHNm7qUdDC6mx9 rb82PH9uFxeupG2Ys6HdcV2O6844Bx6hcsvYuesHv/VwG8ud9Sp93Lhxvdq1bfrcwW999FpZ CXVAWRIYX71xPDS9CZg4aaYKrZFbKud24VugSZWOhI4qPr6Iv5ymVC9Ru7T+K/x1G5dUw9S4 N3ahGSt9e93u0MHYaeQuVzfOmuv3dZV5/JXhcd49NrRxxsp9rpDquvTN0Jw9ijnO2D1GU4LQ GwYTkf53jGLZKTVpRj9nMe2RfyIAokutUaEnc/0wppH0EhmJNtaMhGzwU4mhVFctzEh9l3Zs 9UZlFE2n5buEgOJXN36DAAH+s19emhJOpGgCyjeIkhQn/VCD9310V3Z2V1YWhYg4FuYU+ng5 ey4cmrOsh/j9LYoKN2Afmga8DVeOygX2+3x0gm/rCaGF8NC1Zvrc+LOKFnr2olBudmUXqaZv jvS9SZpN36zpe9NfvNoPSO5mzm9SlxTs/zUpdmt53agubP8vryPx95Nm+idNnzdXLd9YneDt pFmXPMXfj+x/l6C6rGPnch6SoIiHY28BlPP7M9OHufouPgC/Ggbq2h5RAlSyFKyO71Kqr4xf K2Wf739ZqCd2jpZit4FiiW52jcq+9Hn0Jc+XdE+/kYMOgxGcNGvexo3yJe8AavEGJyZugHg0 a65PHduFZoNkBuC3J3ZkJD0rPV0hYNlYmgHwF09KPF6S0ZOgK+GHonNoznhQdBs3jver4zdW bwz3xNYs9KuKf+NBcpQc3dhSXt0HnJ7Yods8XeM3VQKv6vCooYhg5nwKCLxZEV3RTfAZjdhD toSsSODPcEgW+TMYuSSNcIZwh8Goa8HFG4ac2cqF0t7SKcr50oreUlQGtPI9XIbn+cw+cwAu GEza9yp35PuQgC4ilT8CxhU8PCTMg5jBhJLRzaGgmorHShBIEUzMSooJSY6gqsVad2qyomIV 8FaVMno+baqK1n+h6ixrqIy1M3ZlqIjziJJGEiRe4jUup9tJNDpZLxtkTpNkt9mtdk7j4Rw+ bDHCxSl5fdgum30oOxtnZ2fBz1pclW/2jXDYHXZLko0YiT/gG1FUXFRUWBDMCPp9j+Bvn5l3 Q2VH+5Tr7jp+S3QPLrnrieHlFfc1TNkVfV04lJQ8eWH0xLGnotGd4RG7ioaXf/7kJ//KSqFR 5C0w2Jf4y5EZ3RQanWvFCo/9fAE/FpzgRXwHr9GaJa2kNVjNWgPiJKzzakSIN2Vt5mYJS2mq FVtJmjmAEUxyKCm/qOAclT0VnUSngatTLBOOMaa0Zpf2nlGqzredQWVlZWfNJSXwi82WkhKk vLLeuPrY8DxU1UYHmZ9UVJQ/wiEG/WkaUZNkvuXRy+vLrrn28iuuGH2tLYUPbm+9ctRTGRPK qtt636LzdFXsM94L/c9ExTg5dIfWoM1yGdxZQwxZWSWGoqRiz6isiVlVhqqsJYb6rOq8jYZ1 Qx6wP+jeaUh60vV05gHXC5nHXCcy/5D0QaY0zo5THanO7JysghK+JGcif2XOHKkye5FUn71M v17/iv5bw7fZ5uICI+aV3PQCxwifzblgSPMQMsSbaywz3mncaowZha3G3cavjZzR6OUcPeTp kN15j83rFVF5hjzCy+mGhJUwCvjSe8g1ISUjhIJKUA3mBXcHheDwEsrE1BR/QV7JkRKyrQSX OALOtNz0FzUnNCRVU6YhmuEjKTfPnj+rAE8BZudLez/+GJWdLTtTdrb3DDA0F962wp3yFhjs KKGcxa1VqDWg0fjTgoUFRYAbehQWZDAmZ1xO8kfYAVlJSTa7wx/kNKKRAJlPAQZBSO3BJbsP T2i/snDpe4txfvmGG1cmdzmbTt664elpitaRdtjrWHisef6Ixvq6R4PJN80e/8wtU9ZOsRkN 7vSA3DT0sspWZ+ttk0Lhq4atOHfxlstG4g8yvUpmRe6V1ddMvWw5oMUK07hGeBOi6H2hFJsW m1y5rjxXyNXielD/kGGnQXIbMg1driMu3kX5k+lOLUiWDJze5JVxEsm2WXkOALnVhm0xa4h3 BHjwrO/GDJH7ho8sYMiUvakFm6Gtx5yuw/gQhMwXwCF0ZgMHs7NLQTMopWeVs2erAJylpVRu zwI+meDaFLNGK2okYL2itXiQWWPygCefnbV2Lc4Grrblm/2F+YUFxQOoTUrKT/Kb927danXf tGzyfM/IETPGnTjBPbCpdWnB+KstD8vjqxdu+n4R9CY99g+SJWyBka85iGTorj9YoKXdHQPE GhdGWG+QMYfsijbbJGvsAB+TkobSsMES0OOYKJVry6vFFnGNuFnkkaiK28Qu8Yh4UtSIh8gS 5MRFexbFxe/8GeUsVUxnzpdSsABpLgGM5OcrrwzPw8CEgIOCI1hIR2MuNtMR2OwAAaK4J5cu bMi5+eZ9+/dbszNTtm9VLo88Smo2YbEhevum3p9X5LipHhmDe8gS0gi6OQemjrRwpAJXEIL9 iLiFFsjg4ltud2ZPUc5UKZ+g3IqzgMtWXGUt9CWNIUNwz/79tJb1oNzpSo0N7TmI7MAJQ5Kj IMAXQpB3yMBzPbHToXSHq8AhmfVmGydgZPIKog1UaUAbAuUT0+IjoJWn2CkTHQVFBV32c3bS Yt9m77LH7Lyd2P6jpkqaMK1fU5VS4ToPJ9XiwC4zoAFb4oAwaoxiwKjRe7BBAiggqqHXouwq nA26y1xEJSnJ7DcXUCSA+lrffcORZc9N6u5cOu32UuFQ7z/urnr8od4FZPv662fesbr3BdBg 40CDZYAGM0Cs/utQlUWUXfoJmiulOZpKabGmXpIKlFGWUfZCZ7kyyTLJXu6cL8zXzlCqLFX2 Gc5GoVFbqzRaGu21zuU4SasRDNdws4RZ8jX6Bi4iROQGvezw8qLZq9PZ0kU6dmt6oCBPxEhU ADGcOPyUB3touosqHqCN6SgEWVJRGXRuuLugmPEl+6zSml11oaqKMuVsGUwfUyrguIS0M4WZ 2oXCQi2PqyqtSjEwASXZqLZBVqZGChk3xj1+62/fx/br/3bbqejZg3vXr9u775b1eyGgzbhj WfQvvcf/9jOcgg2vv/b6G7997VVoenzsM+4UYMEMFvjt0DMy4Q0BQ4FhnEEotBV6ryaz5Bm2 md7FpFaIaGts1d4jqW8Jf7R+4PrY+rHta8ffXB8nn06NpdpTU7PdpfZS9yR3S+rmVHEYSTcM s48ihYZJpNww3jbRe7U8x7DY8LHmU/t3+LxRwUmcUaeYkMerE81ITgKhc+ZjFDCbAopy0owV c8hcbV5j5s0dlvQXxRPiKTEm8qlimTgVuOlKKZhGUQ7oqTjbW9VaqpxVekvPMKGjp5kq5n6V 7CuMS12BhQLHAQDCgxjGjYwcu/GPnUveuqn63tx9veqzncue2HH9iu3rHtl08bGtmNs4fQwx fjeeWF5/9dcvvff6MeDZFdHp3BeApRSUhc6FqnU6wZajC9gm68ptGm2yKzlHF7Tl+Et0Rbar dONtc8S5ujrdd/I3ScZh/pyMy/2XZ0zO2JyzLUcs8hUNKcsZrxvvKx8yyzdrSL1Y46sZUp2z Jue9jM98X/m/zjA77JqkHrKnO9NrFTE1dIqK8lA1hPZr0BGQKhH1kNWhMYLXa5LL07x62Z6U H8iXA07nSQdWHCFHtWONg3d0mHAApaWmv2g6YTplipn4VFOZaaqJM7myczp8lJnZUxgzweQx fvaeuUB1GLV3VWfovZRqsFZU1eqg7hGzWhnAVhLnqgP0GcNicDAWF+3WjRjbsXqD04iXdb1/ rumN2w9f92Tk/W2/+mLLk6tX7dh13Yodc93TAyNq5xV33YZLP7gf4033r/l+yb9PrHiGy3rj yIuv/+al3wC/J4HspgC/kwCjH4ZqU5E3iczmqoQq7WxdhFsqNGsjOklBClZIhuVd4TvbBbc4 3DLKNdw7xlLhHuOdbpnvmuENWxrdYe8KzYqkC+SCU0F2bDI4HNPs1fYWO2f3mjYr2xSiKLzH K1OuPh3S4nusXl7nCBmo4Gozsgq6DNjgTqUmLxAsoPdQMhXnVJxqz1fSxVB6VsEgiBbHIZpd 0XtmCoh19oXW7Aoq1r3AUOpClPa2ljLvjGIVV1G0tmEHk2izgkC8zTbRR81DEfYFmRfBXXso 56uDn0e/xrY//xEb8fefyXtvqdnU+x6Zrh8559ZVO/Ecx2PdOBVzWI8zox9Gv1XU3Yfq8D3r xtY9STV/GUj7HuBkHn43dD2fZksbpb1KOy59TlokbZX2Du3N6U9an8k5yhm0DrfTkTcp522H 4CGzCVFGYNk5X5qvnS/P183XzzcskZZol8hLdEv0Swzdwe4MU0YwPSN9SFH6PLlSVxuszezw d6SvSf+5/JD+7sz7cu7Je1zeqX8s4/HMfcHfBu3JPbEPQ5aUknlSRkAv8241mMTrhiW7Kde9 qa4y11TXAtdu1wmXxuRKdTW7Trn4VNedLuJ6gcwGFCAqBwoOYaLgk5ggrGCC6azY7AX0Hkox mgswHjY/uSGZJHuTRN47TJfqxu50V8jqLHCBV7hXTM+CnM97S05m4Sz3CFoqCDNcPeLICFI2 Ys0IMkLBGKcjNd2UdgrhMjQVgOga3jeprRUgKWfbpjAHkc7r+eyzbUxlt8LUZmdXtbadoZLU dibuJSacRDBtoYyhKX5QGEGzYlGsCqdJM6gepM0UPVgYCpcUGzz6jH4PSvMb9NIQ2YMzM7Sy Jpv3oFQlmRrDbAVcqfgF7CLELtlr11LrCJa+rbXKWmyPi2BGMGMYyGcR85rA9RSDzHGyUQF2 pJC48QiW7TXdev2qFYWBn7+0ZeqYkVl3zVz9y3nmLn17/aoldnuu5+YX75tT/9LqE+/iy7xL 2yLjLvM7AyMmrp0yYWVmavaV1y92zpg/o9jvTbbK6fljVs2ft/XqZ2nEsAHgBqaYRZGrQ1VT tZu127Rd2iPaU9pzWhFpU7Ut2jXarYmk09qYVk7Vgi8m8oTTargbMNIIGl7WiAEB8Vv5bXwX f4Q/zWuO8Od4gniVPwlPPD9F6vMo2kpp3En1P5MpelKpamu1FuYncaD0N3R3d/N/O3HiYhIf vEg3IdE0kIazIA1udDw0QavHqd6x1rGOmdaZjmprteNB8iD3gOFx5XG3XjK45CWknlsidOpb DGsMT+r3aw/I+/V6u36d/iPCGdMWmJpNN4I+ZTp6Yh4KoWlMS29G28DzOYe0yGTSIcRbwN45 Qal4TdiUbkzzUP9Ul50KjjSgbaI3Kf2EiKkKIeJwT0EiqjsLl7bEssNBhGmcf7btfAJugDZz Sa5SBXHfGWrxAAOtfUokYfD65p2igivdk/z1c+9F/9X2+a27/py623XjvA1PP37zkjvwLY7n T+BkLD+Lydrd2z1LG37z5ttHf5bwFj8BLtnR6yGrwGmsZIfSo3zEfWo9x12wavie2LnQcJ2h YKWC71dOOk87Y05elWxGm90CbiPW2A2ywag3puuY76jD8Kub4qQC56a+o/Ock7Q4tzm7nEec vJMj+Un2hPto+ZH76OhzHc+XxiMzcB5BCqj/SMPdPu/RrjFrZUkWIe5XgmaN0YNNsiXhRdIg v5XKCguCEyEZcyUZk8zrH+38oHr7NEXuzlp6ZftTfPC+3eUtFSNW97aTdU2NY+5+vfcwoHt9 tJ73AU8s4AOcCD2hV4YqlymTFL5M7VJJqjpE708ekTQi+YrkFnWzKo1yjPJc5bjKUyldo5/v mO9ZIi3V1yuNjqWeI+qbtg+cH7jfTDljO5NyWo2pdj+frWQnFfKjlPH8Vco85WPd35Kjis5s BBvFlgXsXqMOGV3pJ2WsyCG5Wl4j83IHtuaTfEsAoSMYb8bbcBc+h/lUXIangjFwpU4oduK4 4morrVB6zzPlBMYIIEQ5l/CW4C1qtSZWB8DFthGqITLM3CCjvv7xUXfXbTi5pPPU9fPuHGZ+ ctmKZ57qaN8TrRd+uXH69E2x+x+LXrxt8qjei9zjx4+99sfXXv0T8Gt27FPeLBxBCljw/d0a 1aV4ATZ7iar7Vew0hCCnkQVOEwQeC3nNerJBt8H0ilHQijonKbdOTrrKNdYzyzo/Ccy4Z6m4 VFdjbUha6qr2rCTLNct015nWa+4X71Vecb5H3ta8rXvf5Han8IItxWBwtGtDPrDQoFm0ipZo N6ea2xm2jJCqgpQStDnl5dv6fO8L8Wgk7nhTbweNpD8YTqvChMluSVIoUzKCVoXyxKwAT0TN 7KVvblu2t+OKJW9uf2vlXQd3rlq1c+cNq66qIm9iHl/27IJ90dh70Wj0N7vufx4/HL3v63O4 Di/5qn4d1UKloBZE4E0K+jRUNFoYrXlBeFHzgviy9IpXnKiv1M8yLtXXGq+zXGe91XLY8rH7 Y885t/5F3fNW4lG8SrKSomh+FTuHRGCgBHctiKM7RVYkjeZVr9vm9bolr5vDRHJ7OUOK0kMe 3zfVjM092LnfkGITUEoPeSFkwkQvtzvehP5QfuEXyFqQOgWPDOnN+8vIAtJMbiQ8OUTSUSq+ c0+cYWABL9C4PrEKRz1FauWYqVtvHJZtXK0cw3FHvI+LIynI2gJJvmBxUWJhjS2OMLxRgyTC Ly9+X0wcgcce+HrHlut/9hA+aP33G29euPKpo4/OT9m1a0xpzZEbjn28aOnPH9poPfHuF7vm Pn348Q3h4cDJ4tinXJjFMhUhJUIWazpIp2aDYYNZowX/ALtDPj7FpNUGZVkK6qpUK1atIes0 a7WVt+IgmmQ5UEnHRRd9LoBaoUA4W0blImFRiwrNfV7u6N1iS83EJZlHK3/9s18fx9ucO1aN bb+B+8f3rp5Xl3xI7d9M7p9knvAm0iEHeic0fyu4M+Rr8WsrOSWespIT4gkreVF80Up2i7ut ZKu41UruFO+0khvEG6zkonTRRhqkBhuZJ82zEb2ktxGbVRIderAhnOlbI/ctMRoI1pcaUKkB RjYtlGttFm8U7wTHE1tH2kqNBn2pyWQMOdwFxk4sjpRKCQCN4+4kmLicrU/FnRiqCairz6aR UaiMrqyCZ0OdC7gyWwq/SHmFrmGgttbWVtya+MFVOMlPF2WKwd6IvkE0tv1azbomp7iAw7/o o/hjbzyxrnTakPGOa64eoIBTbXg7P4rXME9hQihD0GBe1KIAhwMcEQM8rwnkEbyVnCCEvCgg txa7pKvnsTWO+BIH6DHa1VLWW7bkCcLrK/SZ4eRHfT+S+x09uWt39D64g8rb4wgJaYASHao7 iAygCzKsSQU8l6KVt8knZSILhOgkSZBUUdRUrQGPn+jii89sSQPyoiq9asCqYZqh2tBi4EcD aqpagYdsUbrqAmUltUilJVW5bGU6vmjhg9MP18ePku+OHu3VCId6nyTzILDc11sBXJjAfU6m CK8wvLwfmsLwck46ZyNYwjZyWjxtJSfFk1ZyRDxiJV1il5U8Kj5qJXeLd1vJz8SfWUmL2GIl ESliIzOlmQm8mPQ6DtmesVKE6A0AHCNABkvPiDQhDwOMCCrF2Ggq1QNqMgyOy/V6AwWNoZMQ rhQBcDKQCp7JEoYZuu5OLUcpA8wZhdEgJSz8Ptt3vxQy/WhpbQX00KWo/CSbyES+OH8QffWv U7OvySkq5N7pI/h/A0xGTx8ywb5g5gBFZ/BFuKxlvuUv9oP7LxGBOv8jLytg9/yC+H1oXvye OSR+9wfi9+SU+N3pZvdQrkEpUIXNwm6B41TwNu4El60L8bnMhzsFvptgUSFxMzT3KP82UxFV Y+fP3bsGXLaqSup3VmUnfqgDOjyPzvaLR4VD342Hvj4K2v0zhrZrQkkaIUWSRBFxPN3ikLUp OiSx1SKvYikQZ3FXqbJqILLbwGsT+x360df0ySrdXblQVXH+THb/rgc4fxRttElfki9xPsqn f/8Il/39H7mbhUO7omXPRg27KNfyoCeHoCcimhoyCCSF54B1dJNd20Pa96k85nswfl6jYpLL YQ7o/TgOe3grHdgSn37aE9ATVZ8ozO8q69viKaRtE2s0md8Y9QiGXbu++ydtEwSOvwXa1KJJ oSw2+jtF3M8AaP4hFXwAQty6/hHLdIfnkhGfibfDQuYfjHYH98H3H5Ou3ml0pKN29dL13jC0 aReeQgbUEjIeM2AefonEazkDoqYOlAmv1RvaOY5QUzeVGTeOuE1Su/ZvaCpegBcQrgxuzfhG MN4uYw++mxo85jyVQtgHfQIftILaB9otumrJjBxuZeusoMg0or/IYikOc/s3Rc9OKjId5H72 z1v573ZtuidqiV7seX8X/gK//BBK+EUuZvuz0K9CBaPck+0h/zX2q/2LuAZ7o3ux/zr36pRN 7ttSHrDvdB92f2H/RL2gWi+zP2LfZedGDanVkIxDYPf94Dg5fapGzUyZalxgJEajNw1sO35z Gpu/um4+xWtIPYRLkA5MutnJfCInRk7FSZybc8CCjOxG+wPt5n7XyBwyE/Pm7H7X6HzCOWLr F1WJBQzqJcWNOhVsZiQvh4AzQxNfGEJg0y1m5i4FccFADNKyy74qPHP1tCJc9ELjge+x+NKd Z6+/7u+PPvseee2JjhV7d65avR3PVK5rmnzjOy1655ylWHrnFFYeiH4U/Uf00+i+517kCh48 cOyhTbt3013Ke2G+P0+sYGahtaFpPD/eP8e/yN+uvVmrqXd3Ci3adt1Nwk06TYZdyzkzslLs yVqt1ZKSlTVkCIpvN6ampJiR5AxqZgWCendOckoCjdkD+40w73R97IfCR+MvGuCz+J6u4tAt ROo7a0R6NRI/9o2IuzpBP6B2RDHlEaXvJcEdr7UvWnzLnVev+fWm6M/xZWtHXjVp/M8eib6P G68Njp03atY9m6K7hEOVByPXPpmfcXjN4j3Vw7kZZvuiionNQy5uE/Ujl46fsXI4ICn2aHQ6 HsV0ogVtCVXwQkAYzecL6wTBIQmCyPOEF6wIG3SEs+nBF9eJNMbWaUSv2bTZhm0Ohxt0f0CW N+twqq5MN1XH6VxW2y7fhL7FQeYtTFHKI+M+aUVlFSxwsJRYSvrDbXN+/npFim/FGiXFFJQU 2YO1RtGD4gv4ce2Pi1kwQX0pEaCxrjtal1aUWlzUnT/mvon852+88e31W4wT7+bnX9x2rKKW apH5ICV/A18qD0VDD9VwNXw718HzgYxCrsQ7lpsoTk4uTx2XPj5jJlcpzk++OvNWqzHTEEwn 6VxGoMhU4B8XKM+dp87xzw406JYYlhoX2SLOlbrrDNeZViud6e2BddxG3a2GjabblVvSbwrc bbjXdG9SSiDdaNAJPoCHB7QkKEsNDqSnQRqoMc/QO93YfdaOhipYxdNwNW6BoEsDctQVCgxN SbFzQspQrSfovkobREPwEPcIX9CCg5ZZFFOu4TUJnV5xBnwWpuIYrsCCQlRGI7Pz1IU2O+Lb i4ndRRrYW4tTCHNE6X50ekaQ7TP+YG2HdzDwAWfTg/OfNyz43ermp2dOmz862jC9fvEN//jF Y9+uEw6Zdu3s2l4yEr87d8116y4+/HL0n1vwn5Sm26++on1c+WK/I5xd/Fik+de19a+vNd52 x9prpubnL80cvX9Z54n2js9hDDfFPuNOs+9/f3kQuenqaJKjgKhWe4GJLgcMsdgKsq04XbLa 9dhq12mQbPZyOpRvDzgdbBnAgY84sGOKm/lUdBnAfc5NWtzb3F3umJt36wPa/g0kGrup2pPa 01peO8XVv4F0tm8FoLSXLfyDv5VQxAA/N68YDSYD0cS/B+A0Cq/3IINkjkMxK2stBCJgsBNb AxlBBkfHgJvPla3647WPTVV03Tpz0/Tpd4zufqj7ysaphe3k7t59tw+fMH3mnRtIycX3QIev i33Gp4LkKWwH5Vks6E3pQqFQLghlqV2pJDU1zZvvvcJL90U0o6x0k2SyfbK7SqoyzDVV2a91 L5EaDHWmJnuT+0jqu/r3HO+5/mr90vGl6yO2s+JShVxTri1PKDOFhMmmacIi4b3kb/jvFL2S ZOQ1BHnoooCc5DXqnOkndVjRhXTVujU6XteBzfkonwsQ8pNLAikT+pYyL10RoHJdNrCBwpYE fP74rlsKSVIQBL+czTGwIICHPtXdtmfh7tZQ9B+/PLyUFMy+a9mzT3QuexY83G/unHrnq+3R r6NvP4zvfXH2bcdfO/nS8fiakibIX4786KWDELG+ExqjMxQE+DP8Ge1fHB+rwh+FCypxSKpf 6/SoWo7zp3g1SV6djq5/+N0uRT4ZwJsD2wIkAHrLGNjMAtqq/c7AZrrNhqtCLkTy/QF8EmG6 AkfoNttU0I2u9EAPXrFvQKnB2CH+OV919nxV7xSm2toQ3Z0GOFXQ+MfM4tmSvm1Jvc0atOnN HmwxJPVtS1Kdn933SYXdwSLZQQtKg3Ypt494csmy+1JvePWRp/f551/e8ovuubWT147ig/dM WbBw7qHdB3ozyMMNC0bd83jvfWTvihXTHrir913g1ilQ8BfBS5BRe0jlQgZzwVL+RnIn2SLx z/JYizQC4bQC1hP8qhxfOaP2HTEL5tYLIYMp7ulSy54nYFUICURw6Q7hUnwLiu8Wt2YntmXZ 1ztldNQJc5YNkw8hXSH118nF7jFvzrrvr7kd/PWXr0p9bsKrC6h+vgkuxcz2bDqIBHCti0fG XeyCwvg9b3j8nhZ3wUMB0BYmIVXYKpwS+KlwOSdwqUKLsEaICTy44DLh4muAtCY2Ind+YcFW hI+AO04GLQjy/au/2dnx9V+2cNPGvHHqh9/UzfxwEuuFqK+Seb9GnBKqyVXylMVSnbZa2cBt Vl4RXtIcUc4pOkmoxHPINKVO16X8U/9Pwz+NWl7PG3gjp5O1As/rDUZJI4p6oCWNXqRrk6Le BgkEYgdeb4Mc2hRBkFI0nKaHtIS0SNJ/HgL/ghzCOogXdCGLXkURkZsxjT/Bn+K5zXG3O6Sb pj8intJzm/VYT58Vk3hCJDeKa0Qi/tz09p9glIBWF5zw6wRgghCAM+YsK3WfLTsDgRf8rheG Za9Wjq0f5sxOrLzQYHi9cuyY8dix9UL8DvyZ1KWbOakrZfq8ud28iZPEQ7FzCMX+TT25StzW WuXH+djP+TirjwtmaESO5L9B5n7wTO+D29/Ff98yHtQZ5Sk+HB1H5uF7Dy6//TbAwKrodFIN NlpBl4XkDBNGikWUFKUH5+9DW40S3ENmcavxWsQpnMpx3LPmhzexqeu9AK4l+wSAbTHiIDHT ZYR8jUi/TFIwPnXP7yvmHV67MuMyP8hbdPph/G9s/Oq93osnKzfe+8Ivo6lR9Qft6zNJpkK0 soKRRUt7IG/lMO2BCW3lrjUZU8FDftby0+1b/chMd06CGfl0ZVghvWtByNMuy7hu7eF5FSfA yzqN/3L44L0b5/3hYu97X4FHKkHrG8AR/TeN8vDrIbeomaOZp+VMhn8KFzTcbG65TCwa1eor kMA27rNk0K9PznXD3SKwBB9LCN0MKRqeF3hNsXYC+G+aofJceTnXKb/HfaQRn9RgvyYoBqQS zUhtmWGqoZKv1MwVK7Wr+ZXCFu1Lmj/wb2vOaD4X/6X5VkqyyDJEszwBwdVqJXjQSlJA1ABS NRx4ToJsEwRZ1sKDBGEY+ydNkk6HZMCiaa+QBtNlCvlVtg/h3mwArzGASACsSP9GmN7wF9+E RQOeIXNkWvs8Gbp4VEo5CuqTopKnsBQAl3RJUAQfUSrl2BU4Tr9tkLU5ySVaKTm5VNMT+3Bv cgnc3tqrstseXwmT5soq1FqFW1F2NpQ4iDSxI3t9JRzohr12evtwr1Kiid/Yk57d9ujihbMr qbWnTVk+4LFks0NrNlspu0CpC3udtPCXezzx7BDXM9NHNQgIA/Zj0byhGz/9eXQJfvHD6PYb hUPfH8Zd0WW9tST1uug1gAAN6JfnwSOykD0gvDacxQ+RyVXma8x3mDkznV5tqq9A8SbHZz+0 KzW9gNfotVaNR+uyCDziNTqtzihZFGTlbKJX8uiSjekoIGZJ2cYCVCiOkkYbx3ETNCGxQpqk G2uaYL7Kco1phmWpWCsttqzUXCd2SAc1h0wHLN9oLmozdeZMlGnIMGaaMiy5tpGo2LJcWifd z92nfwrvIDt0T+r3owOaQ8bfAWre1X7Gf2b61HJe853Wa+EEAdwmUdDKsqTT62XFbAafbtI+ AVnUntjE0CLZZFR/YxYlVTRbLNmCCFASjbJeHzAYbQbQj2aTKVuWbFAcCQRQg2wY9CTBooWX TGa90SCbZZ6zGPR6uhZCCNZYTCajEcm2C4oB0yW1NQbO0IOfCsnqVBk3yzfKRO4hs0PaqWbc bL4RAlP6pFMEXM1sBidA5v34gvXCIubRuCrOV1U5wZuBX7erF+hP+iGpJI74OjXdeqc6Eq7r K4Zlr1/NlOePboCI9UYArlEppSel6TmpK3Xm3G6DqlfJYQjCMZzG2MlulGdSLT2x0yw0Zkp1 UlfBTICsFDu5R6QRMyT4QAPns/08KXZ6j6jGUy0JvXyQVnTApNK6QWmc3Cvm0Rr3opHkULyl /sr7yzlYOXPs9D5Z5VW64l4Zly5a2VsHLCUoB04qUNYSJk7MSlKZqvLhfKujqNgKV7iA7s/g 8KToC4d2lvH5Ow9uLbzswO5o9ws7h/yJD/Y+eMb8Kmnqvf+142TRxffIqv3fnwB9UBP7VPhA eAsZkQfdGKp2m7BNsdk8Do+H5xXepnPoPPxOxwHjS0bO4XB6iJocMk+1TnWE3HOFudqrldnm BdZ5jgXOOe6rPbc5thDFlcJxlhSdNimoilh0r0nGyaYgi568NYn1oQrQOFVU4wzesKmCIElB vhE8/YCXhxiIFMc/pSgg4IWhGrwBF72Gxz/THT3w4onooR2/w8l/eh97Vn5+1++jfyKv4kb8 8NHoE38+Fd22/3d43q+i/4qewAXYsw/rfh79mPo6bvrtHMi5jK99vlDAKM1cItOvGQzmEq3d 4i2Q6IX0xL7YB3ecuEOOd0LaFF8ByoQLPH0W0oIvhOxwgaf3QvszhxUgFS4m/RCUqQ3KJahQ vhJNkOeAO1IpzdUuwotIvVSvXYGW4+VkpbRCu1xej9eTddyt4gZpo/ZhdL/2LvlZ9Kj8S/S8 uEd+Bf1Wfg/9Uf4SfSRfROflHBkJshPZ5UwUlIvlqQh0rhCy2AuEEHjeMqj/gFa2abUy4vpl FiwEksFwUBEVZS2HsJAL7kmaFAqFtGu0BEyrZ38IBJCAAHpCWpWEcJruiz+wTRQqeL1VbufZ M1UJOeuXQTOzCQPiBXEGqNzW/lVU+oMYKO0MlRg/F2341ZlAqjP7y4PRJgDhzYubZy0jG+gu PkHbQfPuAtvrRGl4cshk0Rmxpcg7L3WR1JjKg9j8dZ/FXWChljYto8BMn0EJK4m7KXGH9+/s Sw7G30N+JXGn70PtQASMV3mvUmfq5nsbvW3aFcaVplvkDab7DDtNPabPjJ+aFKNer5pNNtCW ZpNea/EQn9suayxmxaAXnFqt3eF2pTgcyJfGVj6dTtB5UkrQ+JCmSk1vSV+TzqWnOROLTv7R OwaWQAHjrjPOAaPKFp4gubQklymx+F6bAIY1/o1pPwOZYZVCphKTMspsGcWMYGtCH3wYcrtK zGmuEgucxpC3REmzwZkKZ1LCYmZXDlrIctgdVj83jGQE/X4zJMd37nzbycZjr1/36psVmbMn x84fnd109VDfpL/g7bfcO+W+x6J5wqGpv1v50NvJgfQpndFWPPzmTSN1Ym8nl1+8ckLdOjp3 V0brudMQByrIi34Vul9HskmWczSZRFbqNWVJZa5Jrs0p21KEAmuBpyxlnHWcZ6Z1pqfGWuOp TlmT8pbmj5ZPNJ/rv3AqQ0iaPjuphBTqJ5Lx+nmknryrf9/5kf1z1yee74kJ8wab26sTjRqb l9cho8OYj+h3hiasmEKmatMaE2/qMP/Ed4bJKZd8HRf/NI5+3fvDfXPUis2Jjy6KEt/DXfKR YU7WfbN/Gf26+c0bftv6aK/v2RXtT+5e1vlYtJ5Io6fgYVjcFr3pyTu+G8vtOn78Ny+/9fbL VNdsB62axr7TbQ3JQdNcfq70isSzz27t1qSCAn60NJ6/SlpmelL4zCTqETWML4S8Gq0tSKpU O1bt0+yEft62xs7ZDUFVxjL7kg3KylVJdN8KQJZddbZCAbV5Ia5ImRMM6MH55oQCZUsjbGXE zFcfrY1efOv30e9ajk7YtfrtA+AH7fkg+v1jd2DD59zU7/e+uH/hUWxL/MsOvhf6bgC5vDpU GDEvtZFJyiTbNco1Nl6nT6EW3+GM7wJYgpJbdWP4dTsNCRlwDV54ba1ivetbdWWbaomVVvYh E/H5GCr7/p0GGXJ3RcPdlV9FX4luwNcffqRq8vCbo7cKh4yWyIHGF6K9vc9yeNON829KMkBP 50FP9RA5pKA0dHMod5P7Ng9Z5V7lIQvdEQ9Zqg8byTz9LCMpMo4zEo9LEnmkZJjNyDDEhlNQ D9kd8vvSfKWpcmppWppa6vOloGtTmuRrHUvSlWtVMzYv8dP9SvrPVUAvnqdbqxCt9bJ9swul bCX9jDm+eAw/YMJwkG2ksmXi/t1xnsqhkYgcXUF9B6fYh6e/MPLx5e0POA+6/vXanzCad9Pc IjfpOY7r0y1LKkaNzn5i4aj6rZu32I+/98WT1Y92TLmquiF633G6+nIbwM7JYuGRoVSey8ZE ETTZSLSA7hc1z0HswebgWenhur45OF8a/86m71/bWM2+JL85P+k2fPu770brxen3fPvuPRSz vuh07iuwj268fp/Ji03UNj7uLcm0zTHtlrmQIWQiJjUzr0ChFwikLXaD05Khy9BnGIr0RYZC 4xazLtOSab3SXmmptFYm1VvqrfVJKzXLDCvN19muS7rFsNG8ybLJeqvtfnmH7rDygvmQ7Qv5 U9s3hl7lW1vMmwLOpF4BzxQsmctmtQYssg0eTHpwPQM62abTyVaLRa/XaTivy4S8ipfkel/0 Em8PKdtvsoYsIVsPmRXSlVlCFrLA8qKFWHrwFQdMOA2Ve2T6ymJSdaGQqs/TT9Vz0/QxPYGI /Yp9uSYYLCnr9qirwA2F8LyXhupgAGmk7lTOn3HRZZazbqdyllEQu5+N63RqDaXBERICiwkO ZmmpBD6mEXw7J/h2LyB97DOki32GB3l2ttiHB4pL5LTiEiM4FfuTQKfH9XclXdEB5w5CGWtG /HNdOAZMKv3Qwp92o210TumVDnNQ0EUbj36QnZaa/VF3tGFMet6qOQXRxTuVzHTPUlMyn9m7 pXPtqmVk6cXf7b6iku3BNoJuOghSE0DvhMo9Nk8Sqc7A10pWbOHS05HP4iABBNKNNY4UI+dL 0WgxDmYE0iH0V4maUU040rYmA2ckM63kCvYviVNldCH+ZQL9dzZ937iVssf4h5R9q3HjeL/H 6/a6vJxGH1QCScHUoBTgg/6A05DsQ3aT1QeZbVZVhKc0IeDDXp3Dh21muKRofT6UzsEFsXgv 8Ull308WW9TDhQGzJq4CCyzpIIJ2hziM0LU8UZNks/CUq2ZuMmm8M3py2zvRrd378LT3t2J8 d3C3b+GB5luOLveNXI/JXTecu5yUPYt7T7e1H8TXvvM2bu9e3POLvJY1FdNvnrph67Hov9eE i7GZas2DwNp1ID0ck02VFxAE8ERTynOlWMPLpDSX/nsBKpzbpe33xxeF2Fdc8S81SthHj+yD RzgPHj9+nKs8fvz7p5jUZ0TrcTeT+oKQlxeyRY3CkWyELRpBwOQ5nguI6Fntg1RVnf8Jice+ QvqvcHy4O9r+7rv49mj9PZqMe6Beuv+WBfUKKD+kx4TnUgQkse1k8lTIKBIuodE1g/7p3idV 8Zrjm+W+pHuPkj8Ih7775y7IuAiQtQyQlYx6QtU1ZEkyjHeEoQa1oI7kNejm5M3oAeEZ7gnD Qa7b8LLhJDqT/M9ks9GSbE5O5rI0meYsr5o6wTDHdnXSHFedsDT5esttlge4LcYHvDvw42SH +Y9GK1hUt2JT3DyhSwWZJeyj4YzMEsWEMO+xpug5TwqvVYKmq1CQfv7gTnUEVQlLrpTBwceg fZu4/s7OrqIxCKZfcQ/GTWJ3BgyVhYoi3330suhvPj4b/dODu/HYo3/GOaNfzD/6850fzW/8 ZN1jfyVk+NcXf42b/vAxnr3n9GtDt939aPTru16Ifr7xMHDn6eiH+CZ0HMloyn4ZYPKMhn7L EcRcKbjpMi6la6fwgDQjxVFT0QLUjG5E22ButukSeGH/SEmJf7Yx8MEGTAT9GCP+LcaB49Ou HlFSxB0/3npbsMIVpusb87h9OIPNcjCUhAQOC18RxK1V8WZM8BJN4vMQyg0c//TWSiHIbRh2 PA9KWr75JvoVjd4QEpdRXx1vCo0bgoLmIZagswQVgSdV5JyIJpgnWiY456KrzXMtVzuV+6X7 TfQP7tAFCUkSZJ1erzUYQb/bQIXTP7vjTOqJle4TkFOld73FTO+heUmSVqVrD2o8jnEKkpSS 5LQlJTkteq02JckCpMWsN5lUxWxTwFho9ZIzSTCZFfChhCS9wDkVk0kbD32I02IBay+5HQ63 MkaLpyMV6eGaBGcICXj6AZVCxOXqwbftSfjtbldFr9vZ2wtBkJPtKvzk+kPftmlinfZ/XoCg qw6lx/qowRc8qcsEdsIMdmKvRXb2xC7QtdxJXQFIzGILA4h+NoziS79GSNmnDwmhuCVp64+1 4GaJ2wc/pku/GD8Svf7lU+nukTJ2fPGHqX7v0E9+E216IfpahuiwRV8B96/svnv+ls592OuO fvnP27q5574bz1dtUiMTLj5GrYQWYrPxMN8y+iZ0Za6As1AmF5BzwXZW62+VbtVu1h/Rn9Pr VP00PeGJTiKyVqtKgg1mG2GsEsFGiKDFRPhclZGkjUg4QiQqrLrMkmkSXiNtluAZ45CBhDJL FhB8J9lKCKEpZlWYJpA8oVrYLBwRzgmC0EM27NNVwxS5qNqkex70dNK1S5gft+uss6z0B2vo cX7ZKFuRCZznv+/VWjC9STZQHV8lFmAgWyZkKxpgNFuNqGJBLI4zFpMxvb/7A149LDVtKN70 Uu9R4dDFP61pWbGCH8K+E7ofIY2J7iLiztCNiJigAY/EL9Ov0/9Oz2n1E/UTTdwQPmDIMc7l ruGXGVYY1xskHRGkEkORcSqZxI0TQ1KF4QqjfD/Zwt0r3ivt4J4SNRYCjnaeQGwgRJLeYMgT JCAl/QzTDPrvJ4hE/5SVzmAwGhXgL6m2rAGH5xDZgQx4+F5BBd4OD8l6rayG9DfqsO4QmYOM WAdvgMe6kNaEkWpqUbDSQ+Y8rwKv2Woc2bHPTKMLymcIYp2g8JkXBLS7/+FMFXhAZaX9EkEP t3L27I/WBga2K34JLtBFJMXeRiT2doLxeniXyRhviP17j1Gmqcw1MsTeOuArMeb4Sgw9QIKH NKKYkfuHQurQvnXhtla2rkxjifhM+cx+M8DffD9Ox9fk2V2FeAEWXojO2R2dC1P2j7uunPYg 9z2g/LWLhfzpiypF+SG4rAedzKFAyEmoCi6NK97diN8G77fxTPdeqGL6Ma5qD4FxpmVR7FNS AtaOQzMPIg6ska2EGqWQaiu5j8OE28rt5gi3DNGoCjQt5JO5zxD5DPfgnfvB8u67zkl9l/Nx EMcBXNW/GJBEV693bo7OdQlffmdjf+oFTvLGl8rLyRsXmEq/kTwS+wswj36UkdX312DotySg pd8CUpv4+2esnHh5dAoaO/BHY37wp8FCGkgSXkaPkKfRLXw7uoqUICuc6fA8Bp7XwzkOzvFw XgHnJB6hMvwy2gD3aYn39JwNZymkFdO/AwRlZ/LPojao93GgJ0Dai8Ic9Cj/EcqDcwfkDdMy kHYvfjn2KNznw/NNcK7TPM3qOwVt3CTMifVC+VX0hLo3QH0aTQmqAdoN9HbIdyW9Q/lHgJ4H 7dwG73yQpxHog3BmQPq9kGcR0E/DfM8Tb0cuyK+Fdu6HtEMJPhTBWxn/jdSR35O/c0u5f/F3 CROFr0S/2ClJ0t3aLG2PXCU/Jj+mG6lr0b2gn65/Sv+lIWioNhwwzjW+b5qoWJT7zSPMr1hc lqVWj/Ua6wO2B+1u+52Ouc4i529dftcK19/dqR6r51eeL71Ob8h7IlmXPCwlmPJC6pbU51O/ ZjMzBo0ErNAfghSUi66gUa7cC2kE0sZzUxBKvI+yK8dmVGZPHCtlxFKC5tC12J6geSTjjgQN hhffkKA1kP/eBC2iY/jxBC2hIKlL0Fq0kdyRoGX+KOdM0Dq0UHwvQevRIqk0QRs03dKjCdqI 5pvm9GPuRtPeBA2QU4YnaIJEpShBcyhXuSxB85CnIUELSK+0JmgN5F+doEW0ULk5QUvIqnyS oLWoXPk2QcskbL48QevQcOvW/r8OmG89maAN3Dwbl6CNaJijCnqCecp1veM2Rgt0Rhz3MVrD 0p9itMjS9zFaYvRvGK2lc+R4M0HDHDnfSNAwR873EzTMkfPzBA1z5JqQoGGOXNMTNMyRqz5B wxy5lidomCP36AQNc+QOJ2iYI/ffEjTMUequBA1zpJoSNMyR2pmgYY4yhjBapuPKuIXROjqW jLsYrWfp2xltZHS8ToWOJeMgo61AWzJeZrSN5XmX0Umsno8ZbWfp3zDaRctmYkZ7aJ7MeN+S aZ7MVEanMjqb0eksfzGjsxhdzuihVDIyZ1JaYv1P0KytzAWU1sfTlzKajSVzOZqFVkJsEkGL UBjVwF1FO+GcheoYXQGGoAnOjkQuFTRoM2oDml7DkF7PcqiQ0gDlhwE1jqWH/1/WlNvfMxXN hDcNqLM/TzukTYR7vL3hqASOPDQ0QY1gqWOgRAPcZ0CZxdCHDlZqBtTXDmcbWgbXWsjVBu/D kJO+WQxtNMBT2496O2pQTvUHeUehOazG9v4R0B6MhKuKMqGmeuhnG7xph3MR1DhkUF3/qeRA jgrgw8DTc4yjlF+1ULKRtb8U0mjN//e8ViGVjqgeetLBekR5o8IzzdORqHU2zIOKprHyKgqy 9irgOhXaXsR4Hob8tFwEaqVcXs5K0tqG/USf4vPbDO3SPrVA3pX/MVeE4YrmW856tbi/3foE aoeyeWlGCxO9nsLe1DHkhKE3Of19b2Nv6hlCZ8K1k/U6Pg9xNNEZGMt60sG43Me3NuiLCrnC CQzGkVTPeF/LkEWx1sTaGoyXmkRdYdY3WrKR1Uj7XQftN7Ia49xXWa/DrL2axGzE39Betyfm I8zGGC+3sn/+6xMob0nMYITxpp0hLz66vhkKJ/rfyVpTWQuDe9U385Q39Hk5q7tuEBpo3mZW V7ztvvQ4tzsSHKlJILX9R/k6oM4I40o93ON11yRSOhmnKaIGMN3MJLaNcbSBlac9pfPZmCjV 10INK78s0Wp9YqRx2aM1DHBhEZPhhkTqAF/rE9xtToyknuXvZE8Ds9rOUNrAevfTmOjTqe39 Y6HvGll9A3VQ3bA00dtwgv81TNupCSnt41kta3sxS42XpxJWn5jDOiZ3LQmMNMOVSvSyBLfj NQxo+TCbqzg6VMbDmsT469msNbA8LUz24mhsYiXjIxmM7vp+ZFHJX5GYmUbWG4rNZQnZiuud hv5+NLKnAfR2/MAStf9gfDWJNhayGjoZp2svwWYEtUJ6H2c72d/J7RvhIoZtlWFgBeNtO8Nd R78+ic867Xtc3jsSWiMuTe0JlA1oz/jbRjYjYXQdKx/vNa23hr0dQFq89VrGrRYmJSv7R9HX dhPTmfR9mHGiLdEGlaE4FztY+b4e99XewjDUyPRmX9+GMZvXAe9GgS3NhXrpMYzlGqxhhzHt 1Ag56pgsNQDVCFQTm6EIe2pHCxgG4jM+rD/n/7ctLGeIieeNDGplCmj6WWDvx8M5FpBH6amQ Si3AeLhOZunlkDITrhSbE8ASlMNRwVJnIQNEBvScxdDU/hNYU/vT43IS52hLgucDGP3fWbGB menTyH3zvJC9XQn5O/vbrOnXbXE8D9ijwdoyrjkG9GhcfusTOrM9IdOLWS2Rfp1IpbUy0RqV 7mUJXbqw3xrF2+z4L5zp053L+7VTJCFxkX5MtzH90ZGQ50UJPP4Uv/qkkHIsMqiWASn+cXu1 CQtIEbiQacZ4rxcmZqYpUfNPzVAGG9WlnIpr5B+j4sct9+k2qsXCzAcNQ6sNCW63J3TIf2qb cn82pAzo2ZU/motIwssY7HPFtXeY9aiFcbY+4en8b+ZcTWCxaZBu62uXapJaxun6QVakbZCP nNOfu20Qbgds93/nFO1dI6u/D1fNl9S3nM3/Ujabg/3QPv04kLMZ8sY91E7GcVp/Xf944v0a jO7GhEaN8z8uVS0JfAxo3ksx9N9GNICPiWzsP565Pt+L2pxIwkOLjybu79WwWW36wRy0/YDf AzW3M2+VeiS1CTu0jPlGy9Fg7+p/nv2++toS/l99Itb5KS/ux/MY59aAx1rD6vyxHPfNWPgH vF70f9TbAS7/uIVL7f2lPYokvNgOsD19NdD4ZAyKRwKZ4MMXoGKItVS4DoenoRAhFsCZh+gq wWw0KZEzj/0t+QI44nQxyoeTlipChRAL0JPW/n9m6/7vLWPfu9wfcK/fHs5a2RJZFK6JqDvV WXURtaK5qbkDktSxzW0tzW3hjvrmJrWloWaYOi7cEf4fMuXSytSZzQ2dNKVdndgE5YaXlOQN hcuIYeqYhgZ1Rv3iuo52dUakPdK2LFI7pq0+3DAjsrizIdzWV+0olqgmUkfNibS10wZGDBs5 Qs2sqK9pa25vXtQxhOUa/JIlVMxitx3qrLZwbaQx3LZUbV70X3uttkUW17d3RNoitWp9k9oB WWfPVKeFO9SgOqtCnbpo0TA13FSrRhraI8vrINuw/ppgvM2L28ItdSsHJ0XUcW3h5fVNi2nZ emDtUHVG80Koekp9TV1zQ7g9h9beVl9TH1ZnhjubamEMwKaRI8Y2N3VEGmnf2laq7WHgIDCp fpFaG2mvX9yUo8b5UgO5wvXwsrG5LaLWdTaGm6D7ak1duC1cA8OAh/qadhhHuEmFdyvp+OuB 5S0wwEhNpL29GZqjAwpD/Z01dWp9oio6+M6miLq8vqOOsaGxubmWlqY0dLsDOlIDTG3vS+tY HmnqqI9A7hogOttWDlMZp5uXRdrCMNcdbZFwRyO8ogVqOmG+22ljdPYibawLizobGoBkfYXm G5uhkfqm2s72DjbU9o6VDZHBnKBIbaetRNoa65tYjrbmpVBtGPpf0wkNxSewtj68uJm+X14H PFfrIg0twJFmdXH9sgjLwCAfVhuAHWpjBHjXVF8D2cMtLRFgY1NNBBqJs7ueMkuNrIDBNEYa VqowtnbATgOto7G+gbG3IyFE7Yn2aqDEwoja2Q6QYtyMtHbSznbWUP6ri5phyFAjDKqjg+IE ht4WgXnvAGjANLUDyxg84bExvDh8XX0TVB3pqMmJMw2K19a3tzSEV9ImaOmmyPL2lnALdA2y 1EIXO+rbacU0e0tbc2Mzq21YXUdHy6jc3OXLlw9rTAB2WE1zY25dR2NDbmMH/T9hchvbF4Tp wIfRxP9lgeWRBkiNsCJTps6aOH7i2DGzJk6dok4dr06eOLZ8ysxydcyEGeXlFeVTZhlkgzyr DtjaxzXKYjon0FEYQQfj6E+IGBsMBTId88KV6srmTlqyhqIN+MzkKA5LAAfDKMwviF8TZA8v botEKBKHqZVQrC4MMGheSMUISnZc0hmKzuUUThGYuAjldFukpgPmeRHwcaBfdAqbF0dYFjbF /eVgagC9Czs7oGroZjNI1KABZbT3dQqA3M+K/sIUbeqycENneCEgLNwOCBlcepg6u4lhdmXf KGBMCc0F8A6r7S2RmnpQOj8euQpcbGJoo2XDtbX1FBOAyjamkXNochvjLZPuH3Sqob6xng4I GmH5lje3LW2Pg5ThkSU2LweF2rmwob69jrYDdcXZ3QhAhf7DVLWsVOPgTXDo0oYYPyYuGhgc 1V6tnZF21gzovZpIW1NiBG2JfrPM7XXNnQ21IEPL6iPL4+rqR8On+WAmI6ABagdUXP8YoVtM sdZ0DMwxHVg40etFP10t63J/gYTcJyqCdsIdo2iG2TPHgBHIHFlQPEQtHj5yaF5BXp5WO3sS JOYNH15QANfi/GK1uKiwpLDEIP8HqfuvwkifchPdY3IIoWozC/KoU05DtJXY8P+0d70xbZxn /H3fc+0DSmy8FFg5fHaMLwtOQ+rSOUCCz6490lodJLAMZyxACFKWRkokQ5AmLblIi7Soa6g6 KWtTqWT9MFXrqp7tiR7QCSa2bmXdUm0Zk9J/SbcPy4eOph/W5ZP3e98zJKxE2sd98B2/53ne 5/m9f+71e+b8yOfDP/5juAC4KS4bVmO94jKIf0jkF21HpEtSTvqlNA/MSLPSz8sp/XJKn5RT +uWUfjmlX07pl1P65ZR+OaVfTumXU/rllH45pV9O6ZdT+v+HKf11n/zv2MOCv1Hsxn/VGV2X ExBZgXu0eVys8LvKDp/jYUfa0eXYA9m2rgf+HnyvVr4uzhn+3mMf/VFq0p9IRJwX966zsb32 XV5S3Mrvx/riFg8St1RHVoAiIBEVsgXoBgaBSWAKcAoe95wAzgDzwKciokt1+ece0S2op4Uq HDseEcVhuzjwbVEsfDNj6yf32Tr5uE1rt2kPt9ruHQlbb91ua28oYnBdWR1ZiNdKteRdiX/5 8iQkZb8mbkqJSi5LDxATYJKz5NElb6FJi0zNSw5CJSZRzKlaXJBovromEq9kRbZCvERl/2Sf 2BH2SWFTTWQq/gT7mLwOzAMS+xj7DXaDnGHXCSVuyBgwBcwDV4AVwMmuY/8I+4fsQ7A+IC1A DBgEpoB5YAVwsQ8gPex9/m1gIbkdAxh7H9LD3sNhvQfpZtdgXWPXMLQ/56NtkRlhhFtKhhoq GXUNJcNbG7HYn/K3t6kW+1vBH1Yvx3eyq8QEGDq7isavEj/QAwwBJwEnrGVYy8QAngUuAybg RJ1l1FlGnSXgHWCZ7AR0oAeQ2bt5dGOxK3ktocZr2R/Zb0kdJvUP7HdCv8PeEvr37DdCvw3t g15ib+V9KolXIU5QxwPtgW5B/D72q0KTVy3Ga9g8pkeFbAFiQDcwCEwCTjbPtuSPqF40MkeW ZAJmntwU+qfkZZnox1RdewxrzM+F1r4HFsSUf0pjunbxBRS50C48B4sL7fs/hMWF9t2zsLjQ jp+CxYV25BgsLrSDg7C40Lr7YEFY7KU3mraq0e6nqD/uZhOYpQnM0gRmaYI42ATfyW0HH9uL +eZmzNglPbytWTVmqfEmNfZT42VqjFLjNDXOUmM3NQ5RI0wNhRo+aujUmKO7MBUG1X+xrtim 11NjiRqvUSNLDY0aIWo0UcNPo7rFAvnHHxEqJVQhzs8r6D2dETfGGMCMBrCsAzjt5yGvAEVR 0kHyb7HJX/ZxvaXQHLPLO9ojJ+J72SIqLuJlWCQfAQ68QItYRotohH873Q0ZAwaBBWAFKAJO sLdg4JNCuiFbgBgwCJwBVgCnGM4KwMiJ0hBfFwNrKQ26m5fYInb+FO8AC+iNHsUT9uyVJhXq 9tFuX9HHoqSW353grZFrLFo9/Xn1vz+vJhXxCnaBTZJGvBDPlvRk/najatHn89qcGn+A/pj4 HFh1tI1oNAS9i2RF+VGiyFy3EoW9Ch3JKwdU/sNY2nZ1lm7itabV28rf1ZuKxWD+Q5lT/+q3 HDSv/gWeV6fVq8p59e0WS4bnTc2iULN+QZ1RdqmvLQnqWQQu5dXTXE2r31O61KcUERi1A4ey KOludb92UN2L9pLKYVXPos1pNaYcUnfbrEd5nWl1J4YQts1mDHabIjoN+kSD34ha9Ki+3XXR 1e/qdn3VFXFtdwVcqqvR1eDaLHtlj7xJvl+ulGXZKTtkJhN5M38EXJjfXLHZ6eHK6eDSIWwP 45KJey8IozIjTxDzS1KapXsTNG0ujJD0Yb/5r96gRSv3HTTvCyao6U2TdF/C3BVOW67ifjMa Tpuunm/15yi9kIHXZD+wKOnrt2iRu8418EcQzxBKa84908D1V849k8mQ+tpTsfqYt7Om7WvJ DcRQSd71MzL16+xG82K6t9/8WWPGjHCj2JhJmz/izyieoZ/RT1PJGXqLq0z/jNRJP0vt536p M5nJpC16QPCIn94CDyvmluDJPuLnPOKXfTbvks0LoT54TVyBV1FBQoIXqqgQPAflvFy2KZXM NTUJTh0uPQUnW+e/m7MUAicUEpxagywJzlKtwTlmp6AoCig+RVDog0QRFIU+KCgH7lBaSpTz a5TzoieJ3uEoNqf6+iqn+jo44f91G02Ew7TQkRkZ4M93HgqmRoEh8+lTR+tN47DfnxvJlB78 rA0dHjnK9fComQmOJs2RYNKf6xjYIDzAwx3BZI4MpPr6cwP6aDLfoXekgsPJTKGrpzW6rq/z a3219mzQWA9vrJX31RXdIBzl4S7eV5T3FeV9deldoi8i1nhPf04micxjA7YusKpKrNehhkAm Ues52SkWb0eg/nTDLC5IXiFV4Yx5fzBhVgM89FD8oTgP4ZzioU38Id6lUP3pjkDDLH2lFPLA XRNMkPDYeHac1Ke+k7T/stjgGhvnE27LcPZeG2IpUx9OZscISZvNvWkztu9gf87lgneIH5LZ vuqrqkpZxQXbuQPOdu6UpDUi9+3mvoqKEvGLr/94SYubMA02V6C6j+JDXUYyfek+hreCvtLT kmdxucT/PWQzOMAsDdPsahti2KT0Q0b8eFcxNl6ySvMwVtJ2LVTJrk7H2oY6eKv6D93byY0K ZW5kc3RyZWFtCmVuZG9iagoKMjYgMCBvYmoKMjA0NjQKZW5kb2JqCgoyNyAwIG9iago8PC9U eXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0NBQUFBQStBcmlhbE1UCi9GbGFncyA0Ci9G b250QkJveFstNjY0IC0zMjQgMjAyNyAxMDM3XS9JdGFsaWNBbmdsZSAwCi9Bc2NlbnQgOTA1 Ci9EZXNjZW50IC0yMTEKL0NhcEhlaWdodCAxMDM3Ci9TdGVtViA4MAovRm9udEZpbGUyIDI1 IDAgUj4+CmVuZG9iagoKMjggMCBvYmoKPDwvTGVuZ3RoIDUwNS9GaWx0ZXIvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJxdlE2P2jAQhu/5FTluD6vEYydhJRSJhUXi0A+V7Q8IiWEjLUkUwoF/ X7/zuq3UA+ixPZ48M2HItofdYeiX7Mc8tke/pOd+6GZ/G+9z69OTv/RDYiTt+naJK/1ur82U ZOHu8XFb/PUwnMf1Osl+hrPbMj/Sp003nvyXJPs+d37uh0v69Gt7DOvjfZo+/dUPS5ondZ12 /hzyfG2mb83VZ3rr+dCF4355PIcr/wLeH5NPRdeGKu3Y+dvUtH5uhotP1nlep+v9vk780P13 VjpeOZ3bj2YOoSaE5rlzdWBRrgRslUsDduQSXDBG40tl2YErxqzAK/Ie/ELW+A25Ar+SC/CW OS14x/0X8BtZ9/fkt8AmZ3wOpr9Vpr+Fv6G/24DpLxoDf8nNFkx/C39Dfwd/s2KM7tPfwcfQ 38HZ0L9AXYb+Dv0x9Leo0dDf6l36O7gJ/Uu4Cf0L1Cix/8gvsf8aH/sPH2H/Ld6L0L9ELRL9 dZ/9F9Qi9Bc4SOz/K5j+FTwl+uN9Cf0r1CL0L9SB/hXyW/oX8LTRH721sf/IY+lf4FmW/hUc LP0dnmtj/9EHS/8CNVr6O9RlY//RH0t/0X36i+ahf6FM/wL+lv5Oc9Jf8Ptx9BcOSJwEjApm +c8Ipu19nsP46cDr3GHi+sH//U+Yxgm39PMbE18BcgplbmRzdHJlYW0KZW5kb2JqCgoyOSAw IG9iago8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9CYXNlRm9udC9DQUFBQUErQXJp YWxNVAovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDY0Ci9XaWR0aHNbNzUwIDcyMiAzMzMgNTU2 IDI3NyAyNzcgMzMzIDU1NiA1NTYgNTU2IDU1NiA1NTYgNTAwIDIyMiA1MDAgNTU2CjU1NiA1 NTYgNTU2IDUwMCAyNzcgMzMzIDU4MyA3MjIgMzMzIDI3NyA2NjYgNjEwIDYxMCA1NTYgNTU2 IDY2NgoyMjIgNjY2IDU1NiA1NTYgODMzIDU1NiAyMjIgNjY2IDMzMyAzMzMgNTAwIDcyMiA3 NzcgNTAwIDcyMiA1NTYKNzIyIDY2NiA1NTYgMjc3IDUwMCA3NzcgMjc3IDI3NyA1NTYgNzIy IDI3NyAxOTAgOTQzIDY2NiA4MzMgMjc3CjI3NyBdCi9Gb250RGVzY3JpcHRvciAyNyAwIFIK L1RvVW5pY29kZSAyOCAwIFIKPj4KZW5kb2JqCgozMCAwIG9iago8PC9MZW5ndGggMzEgMCBS L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDE3ODA+PgpzdHJlYW0KeJztlMtvG1UUxr87 YztpoU0cTNNFFa5pgXRBiIvUFqkSVBVBlVIqNcYoUiQ6Ga7taeaVeaA6m8RsQGLDujxqtyCx aKVKXbBhwaJLump3LJAQWxaosGCRlm/G105UIvEPcC3f+Z1zvnvumfuYJEoV9mMLJqTtWWFF CLDdAsSU/VEiVzML4kd2hZbbaVY+uf+I9j3al9vK+vDX5T9nAeMY7ZNtOj7efn+M9grtY20v uXoZK/tpb9EedwPbqmCeaHzKruRZV8MyFjL7c3bStzw1/t3tn2jf4XRHwyBOKrjyhNKHWTwr BHl5eJZYyu3/2yoMdAGzW2pyF7n6r5er5Zeq5WrXxPamgccoNf++1i02uVq/AMXNQg8HgKp8 5eXJUyercvrQ5FjJfPXxH9d7vetiQhy4eePGzX7PmOn1+/3t3/r9fJXFkdnaYvrNBxNn/sIz 4/nE9xqPGrsLKW6yAu4z6xk0jhtrbG/ukjy9X0YB6JZWsrowOBqZwsBBncPAcM/fGo15UXw9 yjMzyil4imc0G1yFWc0m/a9pLpDf0FzkGTqnuUT/xQGzO4xlzQL7sK7ZQBkbmk1M4rPBquT6 LzRn+ruaDbyAHzSbmMLPgzdjV8XvmqkXBzUbmBbTmk2UxVzOJrvnxZuaBcZFXTPrESuaTTwn vJwL7I6ILc1Z/i81G5gS32o2qfmeKyMK+2ifEQ80C1SMCc3cA+OoZpP+muYC+W3NRRw2ljWX 6F+ftY/LE/Pzp+VS6ssLjh0FcSdOlBfL8749dzFU/lLHWw3cS6qVula049ihhopiJ/Blba5W 2/GedV1Z74RBK7LCtmPLBWUlaaTiRac1AC1Qo8i5wPOYZiRYCHw7YeJYJqM86+muDPUgTVQs m/+lk+/FqXLdfEo1FDWd2G4rvvO1luvY7TXlJMofDvFz5dk03lCM+anfiq2I8XeDyLMYGekW Un+DUzuy7uisTLqoBtF6miRKUj5UDQMydL6SfN3Ud/5dklxTvqeitaeroUiNQu8oTymfcisM letcWdtVEy+SjeP8+J7g9ZzHadISUvh8XoDDWIQAMTr8J1Dw+JQ4z7iNOV6qkD6fIzqMrFLp 4hI9LWZwYXHsXoq9fA16IuZ2aGVz15i9xt9eWp7IvD1p8ZuyR/sHfBU08wplbmRzdHJlYW0K ZW5kb2JqCgozMSAwIG9iago4NjUKZW5kb2JqCgozMiAwIG9iago8PC9UeXBlL0ZvbnREZXNj cmlwdG9yL0ZvbnROYW1lL0RBQUFBQStPcGVuU3ltYm9sCi9GbGFncyA0Ci9Gb250QkJveFst MTc5IC0zMTIgMTA4MiA5MTZdL0l0YWxpY0FuZ2xlIDAKL0FzY2VudCA3OTkKL0Rlc2NlbnQg LTIwMAovQ2FwSGVpZ2h0IDkxNgovU3RlbVYgODAKL0ZvbnRGaWxlMiAzMCAwIFI+PgplbmRv YmoKCjMzIDAgb2JqCjw8L0xlbmd0aCAyMjIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFt CnicXZBBa4QwEIXv+RVz3D0sUaE3EYplwUO7pbY/ICajDdRJGOPBf98xa1voIYGX977kTXTb PXXkk37lYHtMMHpyjEtY2SIMOHlSZQXO23SovNvZRKWF7bcl4dzRGOpa6TfxlsQbnB5dGPCs 9I0dsqcJTh9tL7pfY/zCGSlBoZoGHI5yz7OJL2ZGnalL58T2absI8hd43yJClXV5r2KDwyUa i2xoQlUXRQP19dooJPfPO4hhtJ+GJVlKsnpo79njdKf2sX7agF2ZpUmePVfYH/eEv98TQ9yp vL4BivRtowplbmRzdHJlYW0KZW5kb2JqCgozNCAwIG9iago8PC9UeXBlL0ZvbnQvU3VidHlw ZS9UcnVlVHlwZS9CYXNlRm9udC9EQUFBQUErT3BlblN5bWJvbAovRmlyc3RDaGFyIDAKL0xh c3RDaGFyIDEKL1dpZHRoc1s1MDAgNzk0IF0KL0ZvbnREZXNjcmlwdG9yIDMyIDAgUgovVG9V bmljb2RlIDMzIDAgUgo+PgplbmRvYmoKCjM1IDAgb2JqCjw8L0YxIDI0IDAgUi9GMiAyOSAw IFIvRjMgMzQgMCBSCj4+CmVuZG9iagoKMzYgMCBvYmoKPDwvRm9udCAzNSAwIFIKL1Byb2NT ZXRbL1BERi9UZXh0XQo+PgplbmRvYmoKCjEgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAx OSAwIFIvUmVzb3VyY2VzIDM2IDAgUi9NZWRpYUJveFswIDAgNzk0IDU5NV0vR3JvdXA8PC9T L1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMiAwIFI+Pgpl bmRvYmoKCjQgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAxOSAwIFIvUmVzb3VyY2VzIDM2 IDAgUi9NZWRpYUJveFswIDAgNzk0IDU5NV0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9E ZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgNSAwIFI+PgplbmRvYmoKCjcgMCBvYmoKPDwv VHlwZS9QYWdlL1BhcmVudCAxOSAwIFIvUmVzb3VyY2VzIDM2IDAgUi9NZWRpYUJveFswIDAg Nzk0IDU5NV0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4v Q29udGVudHMgOCAwIFI+PgplbmRvYmoKCjEwIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQg MTkgMCBSL1Jlc291cmNlcyAzNiAwIFIvTWVkaWFCb3hbMCAwIDc5NCA1OTVdL0dyb3VwPDwv Uy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDExIDAgUj4+ CmVuZG9iagoKMTMgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAxOSAwIFIvUmVzb3VyY2Vz IDM2IDAgUi9NZWRpYUJveFswIDAgNzk0IDU5NV0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9D Uy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMTQgMCBSPj4KZW5kb2JqCgoxNiAwIG9i ago8PC9UeXBlL1BhZ2UvUGFyZW50IDE5IDAgUi9SZXNvdXJjZXMgMzYgMCBSL01lZGlhQm94 WzAgMCA3OTQgNTk1XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRy dWU+Pi9Db250ZW50cyAxNyAwIFI+PgplbmRvYmoKCjM3IDAgb2JqCjw8L0NvdW50IDYvRmly c3QgMzggMCBSL0xhc3QgNDMgMCBSCj4+CmVuZG9iagoKMzggMCBvYmoKPDwvQ291bnQgMC9U aXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMT4KL0Rlc3RbMSAwIFIvWFla IDAgNTk1IDBdL1BhcmVudCAzNyAwIFIvTmV4dCAzOSAwIFI+PgplbmRvYmoKCjM5IDAgb2Jq Cjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzI+Ci9E ZXN0WzQgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgMzcgMCBSL1ByZXYgMzggMCBSL05leHQg NDAgMCBSPj4KZW5kb2JqCgo0MCAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2 QzAwNjkwMDY0MDA2NTAwMjAwMDMzPgovRGVzdFs3IDAgUi9YWVogMCA1OTUgMF0vUGFyZW50 IDM3IDAgUi9QcmV2IDM5IDAgUi9OZXh0IDQxIDAgUj4+CmVuZG9iagoKNDEgMCBvYmoKPDwv Q291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzND4KL0Rlc3Rb MTAgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgMzcgMCBSL1ByZXYgNDAgMCBSL05leHQgNDIg MCBSPj4KZW5kb2JqCgo0MiAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2QzAw NjkwMDY0MDA2NTAwMjAwMDM1PgovRGVzdFsxMyAwIFIvWFlaIDAgNTk1IDBdL1BhcmVudCAz NyAwIFIvUHJldiA0MSAwIFIvTmV4dCA0MyAwIFI+PgplbmRvYmoKCjQzIDAgb2JqCjw8L0Nv dW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzY+Ci9EZXN0WzE2 IDAgUi9YWVogMCA1OTUgMF0vUGFyZW50IDM3IDAgUi9QcmV2IDQyIDAgUj4+CmVuZG9iagoK MTkgMCBvYmoKPDwvVHlwZS9QYWdlcwovUmVzb3VyY2VzIDM2IDAgUgovTWVkaWFCb3hbIDAg MCA3OTQgNTk1IF0KL0tpZHNbIDEgMCBSIDQgMCBSIDcgMCBSIDEwIDAgUiAxMyAwIFIgMTYg MCBSIF0KL0NvdW50IDY+PgplbmRvYmoKCjQ0IDAgb2JqCjw8L1R5cGUvQ2F0YWxvZy9QYWdl cyAxOSAwIFIKL09wZW5BY3Rpb25bMSAwIFIgL1hZWiBudWxsIG51bGwgMF0KL091dGxpbmVz IDM3IDAgUgo+PgplbmRvYmoKCjQ1IDAgb2JqCjw8L0F1dGhvcjxGRUZGMDA2QTAwNjUwMDY2 MDA2NjAwMjAwMDY4MDA2RjAwNjQwMDY3MDA2NTAwNzM+Ci9DcmVhdG9yPEZFRkYwMDQ5MDA2 RDAwNzAwMDcyMDA2NTAwNzMwMDczPgovUHJvZHVjZXI8RkVGRjAwNEYwMDcwMDA2NTAwNkUw MDRGMDA2NjAwNjYwMDY5MDA2MzAwNjUwMDJFMDA2RjAwNzIwMDY3MDAyMDAwMzMwMDJFMDAz MT4KL0NyZWF0aW9uRGF0ZShEOjIwMTAxMTA4MjAzOTUzLTA4JzAwJyk+PgplbmRvYmoKCnhy ZWYKMCA0NgowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMzY0NzUgMDAwMDAgbiAKMDAwMDAw MDAxOSAwMDAwMCBuIAowMDAwMDAwNDMzIDAwMDAwIG4gCjAwMDAwMzY2MTkgMDAwMDAgbiAK MDAwMDAwMDQ1MyAwMDAwMCBuIAowMDAwMDAwOTA1IDAwMDAwIG4gCjAwMDAwMzY3NjMgMDAw MDAgbiAKMDAwMDAwMDkyNSAwMDAwMCBuIAowMDAwMDAxNzYwIDAwMDAwIG4gCjAwMDAwMzY5 MDcgMDAwMDAgbiAKMDAwMDAwMTc4MCAwMDAwMCBuIAowMDAwMDAyNTI1IDAwMDAwIG4gCjAw MDAwMzcwNTMgMDAwMDAgbiAKMDAwMDAwMjU0NiAwMDAwMCBuIAowMDAwMDAzMjcwIDAwMDAw IG4gCjAwMDAwMzcxOTkgMDAwMDAgbiAKMDAwMDAwMzI5MSAwMDAwMCBuIAowMDAwMDAzNzA4 IDAwMDAwIG4gCjAwMDAwMzgxNzggMDAwMDAgbiAKMDAwMDAwMzcyOSAwMDAwMCBuIAowMDAw MDEyMzIwIDAwMDAwIG4gCjAwMDAwMTIzNDIgMDAwMDAgbiAKMDAwMDAxMjU0MiAwMDAwMCBu IAowMDAwMDEyODMzIDAwMDAwIG4gCjAwMDAwMTMwMDEgMDAwMDAgbiAKMDAwMDAzMzU1MiAw MDAwMCBuIAowMDAwMDMzNTc1IDAwMDAwIG4gCjAwMDAwMzM3NjUgMDAwMDAgbiAKMDAwMDAz NDM0MCAwMDAwMCBuIAowMDAwMDM0NzUxIDAwMDAwIG4gCjAwMDAwMzU3MDIgMDAwMDAgbiAK MDAwMDAzNTcyMyAwMDAwMCBuIAowMDAwMDM1OTE0IDAwMDAwIG4gCjAwMDAwMzYyMDYgMDAw MDAgbiAKMDAwMDAzNjM2NyAwMDAwMCBuIAowMDAwMDM2NDIwIDAwMDAwIG4gCjAwMDAwMzcz NDUgMDAwMDAgbiAKMDAwMDAzNzQwMSAwMDAwMCBuIAowMDAwMDM3NTIyIDAwMDAwIG4gCjAw MDAwMzc2NTUgMDAwMDAgbiAKMDAwMDAzNzc4OCAwMDAwMCBuIAowMDAwMDM3OTIyIDAwMDAw IG4gCjAwMDAwMzgwNTYgMDAwMDAgbiAKMDAwMDAzODMxMSAwMDAwMCBuIAowMDAwMDM4NDEz IDAwMDAwIG4gCnRyYWlsZXIKPDwvU2l6ZSA0Ni9Sb290IDQ0IDAgUgovSW5mbyA0NSAwIFIK L0lEIFsgPDI0OUFBRTI1RUU5MUQ0RUUyRUUyMzUwQjY5OTQ0OTdFPgo8MjQ5QUFFMjVFRTkx RDRFRTJFRTIzNTBCNjk5NDQ5N0U+IF0KL0RvY0NoZWNrc3VtIC80OUJEQ0QwQjEyMzQ5MDc4 RjRCQjZFODA4REU0MDQyMgo+PgpzdGFydHhyZWYKMzg2NjIKJSVFT0YK --------------040706050003080601060609-- From RNATALE@mitre.org Mon Nov 8 21:27:36 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E74F3A68D3 for ; Mon, 8 Nov 2010 21:27:36 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1k0mGExjdVG for ; Mon, 8 Nov 2010 21:27:34 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 185A43A68D8 for ; Mon, 8 Nov 2010 21:27:34 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id oA95RvHF025191 for ; Tue, 9 Nov 2010 00:27:57 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id oA95RvSs025188; Tue, 9 Nov 2010 00:27:57 -0500 Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 9 Nov 2010 00:27:56 -0500 From: "Natale, Bob" To: =JeffH Date: Tue, 9 Nov 2010 00:27:56 -0500 Thread-Topic: [websec] new rev of requirements preso Thread-Index: Act/thPK05X3VcojQKKp5/VTG9+ujAACk/Cw Message-ID: <17969D855F28964C88D177D45B6CDF110500D097D4@IMCMBX2.MITRE.ORG> References: <4CD8B158.7070006@KingsMountain.com> In-Reply-To: <4CD8B158.7070006@KingsMountain.com> 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 Cc: IETF WebSec WG Subject: Re: [websec] new rev of requirements preso X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 05:27:36 -0000 Hi, After reviewing these slides and your position paper (http://w2spconf.com/2= 010/papers/p11.pdf), I'd like to request some basic clarifications: Given the phrase "Coherent Web Security Framework": - What do you mean by "coherent" ... i.e., what observable and measurable a= ttributes constitute coherence in this context? - What is the scope of "Web Security"? - What constitutes a "framework"? I realize that on the surface these might seem like dunce questions, but I = really cannot sync up the websec charter, your slides, and your paper ... s= ome hints to my confusion from the paper: - Is it "web security" or "web site security"? - "...working to address specific subsets of the overall problems space" ..= . scope? ... how does that fit with "coherent framework"? - "website security policy framework" ... ok, that might work, but might a = smaller scope that "Web Security Framework"? - "...deployed web browsers featuring more coherent security properties" ..= . browsers? ... coherent security properties? What happened to Web, web si= te, coherent framework? - "... set of robust standards coherent web security policy framework(s)" .= .. not sure what the wording in the beginning means ("robust standards cohe= rent")? ... now we're talking about security policy frameworks? ... and it = might be more than one framework? - "...a generalized web security policy framework" ... are "generalized" an= d "coherent" the same? ... are we back to one framework? ... and we've sett= led on "security policy" as the scope of interest? Again, I do apologize for the possible (probable?) sense of "dunce-ness" my= questions might suggest ... but, having tried, I can't put these pieces to= gether to produce a picture of a "coherent web security framework". Cheers, BobN -----Original Message----- From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of= =3DJeffH Sent: Monday, November 08, 2010 9:27 PM To: IETF WebSec WG Subject: [websec] new rev of requirements preso Please see attached. Pls upload to meeting materials when u get change Tobi= as. thanks, =3DJeffH From asteingruebl@paypal-inc.com Mon Nov 8 21:36:23 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA1B3A691B for ; Mon, 8 Nov 2010 21:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.883 X-Spam-Level: **** X-Spam-Status: No, score=4.883 tagged_above=-999 required=5 tests=[AWL=-10.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_MED=-4, URIBL_BLACK=20] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSnPVfIZqnrf for ; Mon, 8 Nov 2010 21:36:11 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 8276928C0EC for ; Mon, 8 Nov 2010 21:36:10 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=msN/pyIwCy7dA7oM1WbClcbZNiog6V/GxCSV19jwuAh7AR7UpE7Y3TXh 3lr1PfRKxS14veS9GGQmmT/wR1kK9wZXRLL5TLiYhW1vqI2wchsZXyrhS gIK07Cd2KzKFvOy; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1289280994; x=1320816994; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20"Natale,=20Bob"=20,=20=3DJ effH=20|CC:=20IETF=20WebSe c=20WG=20|Date:=20Mon,=208=20Nov=202010 =2022:36:32=20-0700|Subject:=20RE:=20[websec]=20new=20rev =20of=20requirements=20preso|Message-ID:=20<5EE049BA3C653 8409BBE6F1760F328ABEB184BD195@DEN-MEXMS-001.corp.ebay.com >|References:=20<4CD8B158.7070006@KingsMountain.com>=0D =0A=20<17969D855F28964C88D177D45B6CDF110500D097D4@IMCMBX2 .MITRE.ORG>|In-Reply-To:=20<17969D855F28964C88D177D45B6CD F110500D097D4@IMCMBX2.MITRE.ORG> |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=qRHAVu/H9CXux+/dzBzj/99n7D7aXe/EXPkv7GScu80=; b=U+apHGZkNHfKBwiwbn0V7qnu/zOn9S/zC2OAVpJPTu7EIf9X+CjOunkV iHM84PE/Ho4OFakj6C0Ch3P9+ZFv01zV3D85IkxBV1x2i2pCqmTmtC7Aq OvJK4v7izppkxo6; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.59,173,1288594800"; d="scan'208";a="72967752" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 08 Nov 2010 21:36:33 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Mon, 8 Nov 2010 22:36:33 -0700 From: "Steingruebl, Andy" To: "Natale, Bob" , =JeffH Date: Mon, 8 Nov 2010 22:36:32 -0700 Thread-Topic: [websec] new rev of requirements preso Thread-Index: Act/thPK05X3VcojQKKp5/VTG9+ujAACk/CwAAPBD0A= Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB184BD195@DEN-MEXMS-001.corp.ebay.com> References: <4CD8B158.7070006@KingsMountain.com> <17969D855F28964C88D177D45B6CDF110500D097D4@IMCMBX2.MITRE.ORG> In-Reply-To: <17969D855F28964C88D177D45B6CDF110500D097D4@IMCMBX2.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: t2I3t96M8yes65BZ+u0nAQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: IETF WebSec WG Subject: Re: [websec] new rev of requirements preso X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 05:36:23 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Natale, Bob > After reviewing these slides and your position paper > (http://w2spconf.com/2010/papers/p11.pdf), I'd like to request some basic > clarifications: I'll take the blame for at least 50% of your confusion :) =20 > - What do you mean by "coherent" ... i.e., what observable and measurable > attributes constitute coherence in this context? Singular, or at least well thought out and contained within multiple non-ov= erlapping policies would be a good start.=20 > - What is the scope of "Web Security"? If only there were a good working definition. WE generally mean to include= portions of the general web security model such as the same-origin-policy,= Cookie semantics, frame navigation policy, how HTTP/HTTPS interact with ea= ch other, etc. > - Is it "web security" or "web site security"? If we were unclear, apologies. Generally speaking we don't think of it was= "web site security" because they usually means things like Web-Server-Conf= iguration, and Application security such as preventing XSS for example. > - "... set of robust standards coherent web security policy framework(s)"= ... > not sure what the wording in the beginning means ("robust standards > coherent")? ... now we're talking about security policy frameworks? ... a= nd it > might be more than one framework? OK, here I'm just going to punt and say our language was probably a bit slo= ppy. I don't know that we have a perfect taxonomy or naming system to diff= erentiate between what we'd call a framework, and what we wouldn't. Given = that we're still formulating the whole space, I think defining much of this= is still work to be done. - Andy From dveditz@mozilla.com Sat Nov 20 22:29:04 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284B63A6A3D for ; Sat, 20 Nov 2010 22:29:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AX3wQmR27BO8 for ; Sat, 20 Nov 2010 22:29:03 -0800 (PST) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by core3.amsl.com (Postfix) with ESMTP id 7632C3A6A3C for ; Sat, 20 Nov 2010 22:29:03 -0800 (PST) Received: from priam.local (dsl-63-249-106-47.dhcp.cruzio.com [63.249.106.47]) (Authenticated sender: dveditz@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 2E6424AEF88 for ; Sat, 20 Nov 2010 22:29:56 -0800 (PST) Message-ID: <4CE8BC5C.7080404@mozilla.com> Date: Sat, 20 Nov 2010 22:29:48 -0800 From: Daniel Veditz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: websec@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2010 06:29:04 -0000 The HSTS spec needs to be more clear about how to handle multiple servers running on different ports on the same host. I think, by referring to host name matching only, that the intent of the spec is that a server running on any port can set HSTS behavior for every other port on that host. If this is correct it might be clearer to rename "HSTS Server" to "HSTS Host" and to somewhere in the spec mention explicitly that the port is ignored when matching host names. An alternate behavior would be that a server running on port X only specifies the behavior for that port, with a special case for the default ports 80/443 because they go unspecified. This would make sense from a security POV only if cookies were port-specific (with again a special case for the unspecified default ports), but I don't believe any browser implements cookies in that way. Handling HSTS in a port-specific manner also complicates the meaning of includeSubDomains. -Dan From ynir@checkpoint.com Mon Nov 22 02:31:28 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7143A6923 for ; Mon, 22 Nov 2010 02:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.709 X-Spam-Level: X-Spam-Status: No, score=-7.709 tagged_above=-999 required=5 tests=[AWL=2.890, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0Z1KuxwbJwi for ; Mon, 22 Nov 2010 02:31:28 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id C36EA3A6919 for ; Mon, 22 Nov 2010 02:31:27 -0800 (PST) X-CheckPoint: {4CEA4362-6-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oAMASgbj015444 for ; Mon, 22 Nov 2010 12:32:22 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 22 Nov 2010 12:29:42 +0200 From: Yoav Nir To: "'websec@ietf.org'" Date: Mon, 22 Nov 2010 12:29:41 +0200 Thread-Topic: Some questions about HSTS Thread-Index: AcuKMCvl2Kbio+VwTnaTxClZiBSGNQ== Message-ID: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> 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 Subject: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 10:31:29 -0000 Hi all I have just finished reading draft -02, and I have some questions. In sections 2.4.1.1, point #9 says: 9. UAs need to prevent users from clicking-through security warnings. Halting connection attempts in the face of secure transport exceptions is acceptable. What exactly are these secure transport exceptions? Expired certificates? = Mismatched FQDN? Revoked certificates? Unreachable CRL? Untrusted CA? Self-= signed? Point #9 seems to say contradictory things. On the one hand, it says that "= UAs need to prevent..." and I interpret "need" to mean "MUST", but on the = other hand, halting connections is just "acceptable". So is it MAY or MUST? Also, I don't understand why this change is needed. HSTS is supposed to sto= p a very specific attack vector - a user duped into using insecure HTTP ove= r the (presumably secure) HTTPS. Why is it necessary to all of a sudden cha= nge UA behavior? RFC 2818 specifically allows this: If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. As it is, HSTS cannot be used by servers with self-signed or corporate cert= ificates, for fear that user agents may not allow the user to browse. My second question regards the UA behavior when policy changes. Suppose a w= ebsite has had the HSTS header for a while. The UA has a cache entry with a= TTL of several more weeks. Now the UA connects to the server (over HTTPS) = and does not get an HSTS header at all. What now? If there was a header an= d it was merely changed, the spec says to update the cache entry. But if th= e header is missing altogether, does that mean that the UA should delete th= e cache entry? Yoav From kaie@kuix.de Mon Nov 22 08:27:54 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62E83A6A7E for ; Mon, 22 Nov 2010 08:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8IRSS-ODcC9 for ; Mon, 22 Nov 2010 08:27:53 -0800 (PST) Received: from s15277822.onlinehome-server.info (s15277822.onlinehome-server.info [87.106.189.147]) by core3.amsl.com (Postfix) with ESMTP id 82A8D3A6A3E for ; Mon, 22 Nov 2010 08:27:53 -0800 (PST) Received: from [192.168.2.11] (p4FF35C51.dip.t-dialin.net [79.243.92.81]) by s15277822.onlinehome-server.info (Postfix) with ESMTPSA id 1635F56E97E; Mon, 22 Nov 2010 17:28:48 +0100 (CET) Message-ID: <4CEA9A3F.90406@kuix.de> Date: Mon, 22 Nov 2010 17:28:47 +0100 From: Kai Engert User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b2pre Thunderbird/3.1.6 MIME-Version: 1.0 To: Daniel Veditz References: <4CE8BC5C.7080404@mozilla.com> In-Reply-To: <4CE8BC5C.7080404@mozilla.com> Content-Type: multipart/alternative; boundary="------------070008010102090804040202" Cc: websec@ietf.org Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 16:27:54 -0000 This is a multi-part message in MIME format. --------------070008010102090804040202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 21.11.2010 07:29, Daniel Veditz wrote: > The HSTS spec needs to be more clear about how to handle multiple > servers running on different ports on the same host. I think, by > referring to host name matching only, that the intent of the spec is > that a server running on any port can set HSTS behavior for every > other port on that host. This is correct in my understanding. > If this is correct it might be clearer to > rename "HSTS Server" to "HSTS Host" and to somewhere in the spec > mention explicitly that the port is ignored when matching host names. > > An alternate behavior would be that a server running on port X only > specifies the behavior for that port, with a special case for the > default ports 80/443 because they go unspecified. This would make > sense from a security POV only if cookies were port-specific (with > again a special case for the unspecified default ports), but I don't > believe any browser implements cookies in that way. Handling HSTS in > a port-specific manner also complicates the meaning of > includeSubDomains. About 4 months ago, when I reviewed the Firefox implementation, I asked similar questions on this list. It was said, the https-strictness should apply to whole hosts. The summary was: > * plain http is forbidden for all ports on a known HSTS host > (it's not possible to run any additional http services on a > known HSTS host, because HSTS-compliant browsers are expected to > never connect to it) > * a browser is expected to catch http://host:80 requests and > transfer them into https://host:443 > * http to any port other than 80 gets changed into https to the > same port number, e.g. the browser must change requests to > http://host:81 into requests for https://host:81 > Kai --------------070008010102090804040202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 21.11.2010 07:29, Daniel Veditz wrote: 
The HSTS spec needs to be more clear about how to handle multiple
servers running on different ports on the same host. I think, by
referring to host name matching only, that the intent of the spec is
that a server running on any port can set HSTS behavior for every
other port on that host.

This is correct in my understanding.

If this is correct it might be clearer to
rename "HSTS Server" to "HSTS Host" and to somewhere in the spec
mention explicitly that the port is ignored when matching host names.

An alternate behavior would be that a server running on port X only
specifies the behavior for that port, with a special case for the
default ports 80/443 because they go unspecified. This would make
sense from a security POV only if cookies were port-specific (with
again a special case for the unspecified default ports), but I don't
believe any browser implements cookies in that way. Handling HSTS in
a port-specific manner also complicates the meaning of
includeSubDomains.

About 4 months ago, when I reviewed the Firefox implementation, I asked similar questions on this list.
It was said, the https-strictness should apply to whole hosts.

The summary was:

  • plain http is forbidden for all ports on a known HSTS host
    (it's not possible to run any additional http services on a known HSTS host, because HSTS-compliant browsers are expected to never connect to it)
  • a browser is expected to catch http://host:80 requests and transfer them into https://host:443
  • http to any port other than 80 gets changed into https to the same port number, e.g. the browser must change requests to http://host:81 into requests for https://host:81

Kai

--------------070008010102090804040202-- From asteingruebl@paypal-inc.com Mon Nov 22 08:51:42 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EDD28C11A for ; Mon, 22 Nov 2010 08:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=8.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoE8lCsXnI90 for ; Mon, 22 Nov 2010 08:51:41 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 29CE43A6AA4 for ; Mon, 22 Nov 2010 08:51:40 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=XCOtoE8IRPuLnGeUDqAKLGcTbmyKYRyGkt4UKn+OfgEVEhddNv0Bxogn UIlQlYIcNvD/4OvnHvmT2AKL/mwa4/19dRnRpESoC3Tw+daig8kjoVkcV n/jHeWi0CYXkNqi; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1290444758; x=1321980758; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Daniel=20Veditz=20,=20"w ebsec@ietf.org"=20|Date:=20Mon,=2022=20N ov=202010=2009:52:34=20-0700|Subject:=20RE:=20[websec]=20 HSTS=20--=20what=20about=20ports?|Message-ID:=20<5EE049BA 3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.eba y.com>|References:=20<4CE8BC5C.7080404@mozilla.com> |In-Reply-To:=20<4CE8BC5C.7080404@mozilla.com> |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=A0E7ZiUEBDk70rwEx5EIdnkV+86QeZbb8PYxr+T9g5g=; b=eVIp4B4Sjg3ySUbokLjadXzQItYbxpviHnxckadBPwDgdMEA5/7tYGlr jx15MMHkX9fTm1DF2G89rmErMizKhXjLsYmoJGYSkwlzbYCPDsUsrSsR1 7KiaIQsIp1nFKTW; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.59,237,1288594800"; d="scan'208";a="65283" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 22 Nov 2010 08:52:37 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Mon, 22 Nov 2010 09:52:36 -0700 From: "Steingruebl, Andy" To: Daniel Veditz , "websec@ietf.org" Date: Mon, 22 Nov 2010 09:52:34 -0700 Thread-Topic: [websec] HSTS -- what about ports? Thread-Index: AcuJRYepmMXBKEKYSbaG6cbvWl9/GwBH+z1A Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> References: <4CE8BC5C.7080404@mozilla.com> In-Reply-To: <4CE8BC5C.7080404@mozilla.com> 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-CFilter: Scanned Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 16:51:42 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Daniel Veditz > Sent: Saturday, November 20, 2010 10:30 PM > To: websec@ietf.org > Subject: [websec] HSTS -- what about ports? >=20 > The HSTS spec needs to be more clear about how to handle multiple servers > running on different ports on the same host. I think, by referring to hos= t > name matching only, that the intent of the spec is that a server running = on > any port can set HSTS behavior for every other port on that host. If this= is > correct it might be clearer to rename "HSTS Server" to "HSTS Host" and to > somewhere in the spec mention explicitly that the port is ignored when > matching host names. Agreed. This is on Jeff's to-do list per a separate email conversation I ha= d with him yesterday. >=20 > An alternate behavior would be that a server running on port X only speci= fies > the behavior for that port, with a special case for the default ports 80/= 443 > because they go unspecified. This would make sense from a security POV > only if cookies were port-specific (with again a special case for the > unspecified default ports), but I don't believe any browser implements > cookies in that way. Handling HSTS in a port-specific manner also complic= ates > the meaning of includeSubDomains. You're correct. This topic just got re-started again yesterday, and I wrot= e a little something about it here: http://securityretentive.blogspot.com/2010/11/quick-clarification-on-hsts-h= ttp-strict.html Essentially cookie leakage is the problem, and since they aren't scoped to = ports, we must interpret HSTS for *all* ports.=20 From asteingruebl@paypal-inc.com Mon Nov 22 08:56:28 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B173A6AE1 for ; Mon, 22 Nov 2010 08:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.117 X-Spam-Level: X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=6.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngCbH9gERPiw for ; Mon, 22 Nov 2010 08:56:27 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id C1B673A6A3E for ; Mon, 22 Nov 2010 08:56:27 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=O/XxIaw/vM6WzvT5PXgzdHSn0/I8HpbnPK93+y3YKvMTPWkbiXCQEtoS 6SB6/QFZgP286hDQ9wtEK9fGZ2OAkFrHmOfN2Iai86IB0KhhXBi4YXu+e 9X73MKYK0Ph8nWD; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1290445044; x=1321981044; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Yoav=20Nir=20,=20"'webse c@ietf.org'"=20|Date:=20Mon,=2022=20Nov =202010=2009:57:21=20-0700|Subject:=20RE:=20Some=20questi ons=20about=20HSTS|Message-ID:=20<5EE049BA3C6538409BBE6F1 760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> |References:=20<006FEB08D9C6444AB014105C9AEB133F012E6FCD4 474@il-ex01.ad.checkpoint.com>|In-Reply-To:=20<006FEB08D9 C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint. com>|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=FdGKAsZY+WzjNFZEZEFQq1YjhcjIACJhwaDS2J5KKAE=; b=VU8LkjNKY1JYgKHi7s3Opirvi72LFeLGN2SO5Q2b8V++4NW64vNU6c/R FE2hzvdsZMBRxl0/yVWB2ySQyoMHzU7D+G/RZwlD0SNi4YurWBRJxnOa5 NPgSfwBhj2m4Bmt; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.59,237,1288594800"; d="scan'208";a="163122" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 22 Nov 2010 08:57:23 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Mon, 22 Nov 2010 09:57:23 -0700 From: "Steingruebl, Andy" To: Yoav Nir , "'websec@ietf.org'" Date: Mon, 22 Nov 2010 09:57:21 -0700 Thread-Topic: Some questions about HSTS Thread-Index: AcuKMCvl2Kbio+VwTnaTxClZiBSGNQANX9bQ Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> 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-CFilter: Scanned Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 16:56:29 -0000 > In sections 2.4.1.1, point #9 says: > 9. UAs need to prevent users from clicking-through security > warnings. Halting connection attempts in the face of secure > transport exceptions is acceptable. > What exactly are these secure transport exceptions? Expired certificates= ? > Mismatched FQDN? Revoked certificates? Unreachable CRL? Untrusted CA? > Self-signed? Anything that would currently pop a browser warning for a user currently. = Browsers differ slightly in how they handle OCSP, etc. In any case where a= browser has already made the policy decision it should show a certificate = "error", it must now abort. > Also, I don't understand why this change is needed. HSTS is supposed to s= top > a very specific attack vector - a user duped into using insecure HTTP ove= r the > (presumably secure) HTTPS.=20 >=20 > As it is, HSTS cannot be used by servers with self-signed or corporate > certificates, for fear that user agents may not allow the user to browse. That is correct. I personally believe, as do several of the contributors o= n this (and I hope I'm not speaking too much out of turn) that self-signed = certificate warnings are just a punt, and an easy way for a user to make a = bad security decision. If you want to support HTTPS, do it with a cert th= at your browser already trusts. Anything else is just a recipe for a MiTM = attack. If a host advertises HSTS, it is specifically opting into this sch= eme, whereby all certificate warnings will cause abort, with no chance to "= fool" the user into making the wrong decision. =20 > My second question regards the UA behavior when policy changes. Suppose > a website has had the HSTS header for a while. The UA has a cache entry w= ith > a TTL of several more weeks. Now the UA connects to the server (over > HTTPS) and does not get an HSTS header at all. What now? If there was a > header and it was merely changed, the spec says to update the cache entry= . > But if the header is missing altogether, does that mean that the UA shoul= d > delete the cache entry? I think we can make this clear, but until the client receives a new header,= it does not tinker with the cache. We do say the header should be present= in all /most server responses, but the behavior should be that the value p= ersists until set to something else. - Andy From marsh@extendedsubset.com Mon Nov 22 09:48:06 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9503A6A61 for ; Mon, 22 Nov 2010 09:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EG0OwATRujV for ; Mon, 22 Nov 2010 09:48:05 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 0007B3A69ED for ; Mon, 22 Nov 2010 09:48:04 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PKaVg-000GqN-PP; Mon, 22 Nov 2010 17:49:00 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id CC72A6019; Mon, 22 Nov 2010 17:48:58 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/6z04RIvcnZdHGGpt0clINXcY5s/LykV4= Message-ID: <4CEAAD0A.2070306@extendedsubset.com> Date: Mon, 22 Nov 2010 11:48:58 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Steingruebl, Andy" References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'websec@ietf.org'" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 17:48:06 -0000 On 11/22/2010 10:57 AM, Steingruebl, Andy wrote: >> In sections 2.4.1.1, point #9 says: 9. UAs need to prevent users >> from clicking-through security warnings. Halting connection >> attempts in the face of secure transport exceptions is acceptable. >> What exactly are these secure transport exceptions? Expired >> certificates? Mismatched FQDN? Revoked certificates? Unreachable >> CRL? Untrusted CA? Self-signed? > > Anything that would currently pop a browser warning for a user > currently. Browsers differ slightly in how they handle OCSP, etc. > In any case where a browser has already made the policy decision it > should show a certificate "error", it must now abort. I feel that it would be misguided for an RFC to specify MUST with regards to UA interaction with the user, however well intentioned it may be. It's the user's browser after all, not the IETF's, and not the web site's. If a user wants to install (or create) and use a program which exchanges valid protocol messages with interaction or screen content, that's his right, regardless of what some RFC says. I agree with the intent however. It seems like a case for a strongly-worded SHOULD. >> Also, I don't understand why this change is needed. HSTS is >> supposed to stop a very specific attack vector - a user duped into >> using insecure HTTP over the (presumably secure) HTTPS. >> >> As it is, HSTS cannot be used by servers with self-signed or >> corporate certificates, for fear that user agents may not allow the >> user to browse. > > That is correct. I personally believe, as do several of the > contributors on this (and I hope I'm not speaking too much out of > turn) that self-signed certificate warnings are just a punt, and an > easy way for a user to make a bad security decision. If you want to > support HTTPS, do it with a cert that your browser already trusts. Seems entirely reasonable to me that the user should have a way to add and remove trust of CAs and even self-signed server certs. The key distinction being that additions to the trusted set are made because of prior arrangement. It specifically needs to not happen subsequent to a failed server authentication. > Anything else is just a recipe for a MiTM attack. If a host > advertises HSTS, it is specifically opting into this scheme, whereby > all certificate warnings will cause abort, with no chance to "fool" > the user into making the wrong decision. HSTS should be thought of as a way for a site to communicate its policy to the user, via the UA: "I (the site) commit to always running an HTTPS service, so you can rewrite http: links and failures on port 443 may indicate an attack." It's not a way for a site to get the UA to force restrictions upon the user. Trying to enlist the user's software against their intentions is using the same failed logic behind DRM. - Marsh From dev.akhawe@gmail.com Mon Nov 22 09:52:30 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A2033A6A98 for ; Mon, 22 Nov 2010 09:52:30 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arr7caoFNpZD for ; Mon, 22 Nov 2010 09:52:29 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 5645A3A69F4 for ; Mon, 22 Nov 2010 09:52:29 -0800 (PST) Received: by wyb29 with SMTP id 29so7309454wyb.31 for ; Mon, 22 Nov 2010 09:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=hxuGr49UWyMKvIn5hPwnVoSBbd7iyZvMhYGQXbiiCbI=; b=kZKDQEKILNtTszT4bhLIQJTpSmoNfCMuxiYHxShiHlwBGHvpBYNp2wXraxDYsUn04G sRWWw9qCs0GKIv0bQBOHieQEzkPKPMNeC1B/sR33jMchSWjl1nPxtYaYmu8Oof7xKyiD mU5HD3RJ0IE82IY3Xf8jQPh0ihvniiBJ7tAqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=j2Apinz5EnenRCpDZDujESPoSdgzXY4EAOwqy/I/Vsd2EYjitJmBEd28ZFEpBvlynN 7scyv/+T4BToL02e4qN8d6MghGiFeU1Kh11BVLzyFzV8ugbPxrIvUA2K9RzHECVURXbc 2i3Ee8tkmX3cIDYGiRSF+3n0gqZ7Jb28oAYrA= Received: by 10.216.28.204 with SMTP id g54mr4290342wea.73.1290448403950; Mon, 22 Nov 2010 09:53:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.86.11 with HTTP; Mon, 22 Nov 2010 09:53:03 -0800 (PST) In-Reply-To: <4CEAAD0A.2070306@extendedsubset.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> <4CEAAD0A.2070306@extendedsubset.com> From: Devdatta Akhawe Date: Mon, 22 Nov 2010 09:53:03 -0800 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 17:52:30 -0000 > > HSTS should be thought of as a way for a site to communicate its policy to > the user, via the UA: "I (the site) commit to always running an HTTPS > service, so you can rewrite http: links and failures on port 443 may > indicate an attack." > > It's not a way for a site to get the UA to force restrictions upon the user. > Trying to enlist the user's software against their intentions is using the > same failed logic behind DRM. > The problem is that the average user has no understanding what the certificate means and just says 'please show me the content' (clicks yes) That said, this behavior of HSTS makes me uncomfortable too. Unfortunately, some browsers have already implemented this; hopefully other browsers will pause before implementing this behavior. -devdatta > - Marsh > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From asteingruebl@paypal-inc.com Mon Nov 22 10:00:04 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177693A6A4C for ; Mon, 22 Nov 2010 10:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.317 X-Spam-Level: X-Spam-Status: No, score=-4.317 tagged_above=-999 required=5 tests=[AWL=4.800, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpLYuxOJRofV for ; Mon, 22 Nov 2010 10:00:03 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id 082E23A6AE0 for ; Mon, 22 Nov 2010 10:00:02 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=GS6OpsLutQRJZ9OWKVp3qv9f9UQbVYcHwnNUMJ1UjiLW1wEi8ANOlAkR A7j7+C8l8q+SmqesPdFZzy9JHKGl72URQrXt80Z3mjoLi7yWpQ/vkr6XN 2+i/RQRPF9LDe9b; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1290448859; x=1321984859; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Marsh=20Ray=20|CC: =20Yoav=20Nir=20,=20"'websec@ietf.or g'"=20|Date:=20Mon,=2022=20Nov=202010=20 11:00:57=20-0700|Subject:=20RE:=20[websec]=20Some=20quest ions=20about=20HSTS|Message-ID:=20<5EE049BA3C6538409BBE6F 1760F328ABEB18842FAB@DEN-MEXMS-001.corp.ebay.com> |References:=20<006FEB08D9C6444AB014105C9AEB133F012E6FCD4 474@il-ex01.ad.checkpoint.com>=0D=0A=20<5EE049BA3C6538409 BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com>=0D =0A=20<4CEAAD0A.2070306@extendedsubset.com>|In-Reply-To: =20<4CEAAD0A.2070306@extendedsubset.com> |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=IVU0E6hhnaqhYep5Okb8yr3xAXUZkKG+pS5zxv+yt/U=; b=B2L2e5zl3hLYwxTDi+CnMIANAmnuPoxVQjzPzUhDZjn8cZsPU/1wlAft MIVcISfRzz6W+j/b89PTbm8BQHKRt8TFuUVcsGHPxGBIGV7e+NiHqVR4r AEE7Tz3RyqYYSoa; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.59,237,1288594800"; d="scan'208";a="165184" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 22 Nov 2010 10:00:58 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Mon, 22 Nov 2010 11:00:58 -0700 From: "Steingruebl, Andy" To: Marsh Ray Date: Mon, 22 Nov 2010 11:00:57 -0700 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuKbZLPdXSYx+FpR8Cya+Xeg2ZE/wAAVPuA Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB18842FAB@DEN-MEXMS-001.corp.ebay.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> <4CEAAD0A.2070306@extendedsubset.com> In-Reply-To: <4CEAAD0A.2070306@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: 9cN/dx1EY2QcPEs8z8Bz1g== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "'websec@ietf.org'" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 18:00:04 -0000 > -----Original Message----- > From: Marsh Ray [mailto:marsh@extendedsubset.com] >=20 > I feel that it would be misguided for an RFC to specify MUST with regards= to > UA interaction with the user, however well intentioned it may be. It's th= e > user's browser after all, not the IETF's, and not the web site's. If a us= er wants > to install (or create) and use a program which exchanges valid protocol > messages with interaction or screen content, that's his right, regardless= of > what some RFC says. I don't disagree. I do however feel that this should be exceptions, and ma= ybe in an "about:config" configuration, rather than the default or in plain= view in the UI. Yes, it is the user's computer. But if we didn't want to= make security decisions for them, then browsers wouldn't include phishing = filter, certificate warnings, etc. As it is, we are already making security= policy decisions for users in the browser, and here were are simply propos= ing another. - Andy From asteingruebl@paypal-inc.com Mon Nov 22 10:04:11 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232643A6AE0 for ; Mon, 22 Nov 2010 10:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.117 X-Spam-Level: X-Spam-Status: No, score=-5.117 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv++v-bfYPWt for ; Mon, 22 Nov 2010 10:04:08 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id DFC263A6A4C for ; Mon, 22 Nov 2010 10:04:07 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=WjR8/FCK8jA/yBP5QFwMH/o0IZTqXN5GboE2dXV3qaqjbqYd1vDg4Cnw IUulTIL5d89sr3LPXSn7CbEU/+LCqpIYCRnTQqSJLGkXmUJmA+xWpcYTo gOyJBhOWr7I8/OC; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1290449104; x=1321985104; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Marsh=20Ray=20|CC: =20Yoav=20Nir=20,=20"'websec@ietf.or g'"=20|Date:=20Mon,=2022=20Nov=202010=20 11:05:02=20-0700|Subject:=20RE:=20[websec]=20Some=20quest ions=20about=20HSTS|Message-ID:=20<5EE049BA3C6538409BBE6F 1760F328ABEB18842FB8@DEN-MEXMS-001.corp.ebay.com> |References:=20<006FEB08D9C6444AB014105C9AEB133F012E6FCD4 474@il-ex01.ad.checkpoint.com>=0D=0A=20<5EE049BA3C6538409 BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com>=0D =0A=20<4CEAAD0A.2070306@extendedsubset.com>|In-Reply-To: =20<4CEAAD0A.2070306@extendedsubset.com> |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=dapygaxdotd17kjK6QeYIWRhK5HD+3NAhMzIbA7z+HA=; b=jbCCfAlm15R401aspzzPOxLp4hE95Ul5jVy61NNUGRURhOM9aIeFDRK6 ytoUM2v7oy6dbs/EAMacVplL0Lfoc9vL6HSN8HBqFk4iBwYvYBY57alE2 kxpDyhi3S4ql+O4; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.59,237,1288594800"; d="scan'208";a="67449" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 22 Nov 2010 10:05:03 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Mon, 22 Nov 2010 11:05:03 -0700 From: "Steingruebl, Andy" To: Marsh Ray Date: Mon, 22 Nov 2010 11:05:02 -0700 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuKbZLPdXSYx+FpR8Cya+Xeg2ZE/wAAbf+A Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB18842FB8@DEN-MEXMS-001.corp.ebay.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> <4CEAAD0A.2070306@extendedsubset.com> In-Reply-To: <4CEAAD0A.2070306@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: 5OHOVn7P/SM7o1KckTUiMg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "'websec@ietf.org'" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 18:04:11 -0000 > -----Original Message----- > From: Marsh Ray [mailto:marsh@extendedsubset.com] =20 > It's not a way for a site to get the UA to force restrictions upon the us= er. > Trying to enlist the user's software against their intentions is using th= e same > failed logic behind DRM. Sorry, didn't reply to this specific point. Unlike DRM I fully support user= s being able to opt-out if they'd like. I'm looking to protect the amateur= rather than expert though. I don't know really though hos you think this= is defeating user-intent? The user in this case doesn't know whether the = site in question is really asking them to approve the exception, their brow= ser is. We're giving the browser more information to make that decision. = Only sites that opt-in to HSTS get this behavior in the first place, so whi= le the server-side does control the behavior (absent a user modifying their= UA) it is hard to see how we're defeating user choice here. A contract is = implied here, that a site will keep its certificates up to date, etc. What decision of the user do you really think we're thwarting? This site h= as told me previously its only going to use a cert my browser trusts, but = I'm getting a certificate warning, and I think I'll click through it anyway= .... ? - Andy From paul.hoffman@vpnc.org Mon Nov 22 10:10:22 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62773A6AE5 for ; Mon, 22 Nov 2010 10:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.162 X-Spam-Level: X-Spam-Status: No, score=-101.162 tagged_above=-999 required=5 tests=[AWL=0.884, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMOTFTHqlheO for ; Mon, 22 Nov 2010 10:10:22 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C1BB93A6AE4 for ; Mon, 22 Nov 2010 10:10:21 -0800 (PST) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAMIB6u9037177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Nov 2010 11:11:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB18842FAB@DEN-MEXMS-001.corp.ebay.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> <4CEAAD0A.2070306@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842FAB@DEN-MEXMS-001.corp.ebay.com> Date: Mon, 22 Nov 2010 10:11:05 -0800 To: "Steingruebl, Andy" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "'websec@ietf.org'" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 18:10:22 -0000 At 11:00 AM -0700 11/22/10, Steingruebl, Andy wrote: > > -----Original Message----- >> From: Marsh Ray [mailto:marsh@extendedsubset.com] >> >> I feel that it would be misguided for an RFC to specify MUST with regards to >> UA interaction with the user, however well intentioned it may be. It's the >> user's browser after all, not the IETF's, and not the web site's. If a user wants >> to install (or create) and use a program which exchanges valid protocol >> messages with interaction or screen content, that's his right, regardless of >> what some RFC says. > >I don't disagree. I do however feel that this should be exceptions, and maybe in an "about:config" configuration, rather than the default or in plain view in the UI. Yes, it is the user's computer. But if we didn't want to make security decisions for them, then browsers wouldn't include phishing filter, certificate warnings, etc. As it is, we are already making security policy decisions for users in the browser, and here were are simply proposing another. The "we" here, the IETF, generally does not make such decisions for users. We make protocols and recommendations to developers. The text in this document should be worded as such. --Paul Hoffman, Director --VPN Consortium From marsh@extendedsubset.com Mon Nov 22 10:10:36 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07E73A6AE4 for ; Mon, 22 Nov 2010 10:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uquprD-p+PFa for ; Mon, 22 Nov 2010 10:10:27 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id F02323A6AE7 for ; Mon, 22 Nov 2010 10:10:26 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PKarK-000AQL-SM; Mon, 22 Nov 2010 18:11:22 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 5B3DB6019; Mon, 22 Nov 2010 18:11:21 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/oI5YuA7XmVZZCrT04WwZFZZHO5cQfiRE= Message-ID: <4CEAB248.507@extendedsubset.com> Date: Mon, 22 Nov 2010 12:11:20 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Devdatta Akhawe References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> <4CEAAD0A.2070306@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 18:10:36 -0000 On 11/22/2010 11:53 AM, Devdatta Akhawe wrote: >> >> HSTS should be thought of as a way for a site to communicate its policy to >> the user, via the UA: "I (the site) commit to always running an HTTPS >> service, so you can rewrite http: links and failures on port 443 may >> indicate an attack." >> >> It's not a way for a site to get the UA to force restrictions upon the user. >> Trying to enlist the user's software against their intentions is using the >> same failed logic behind DRM. > > The problem is that the average user has no understanding what the > certificate means and just says 'please show me the content' (clicks > yes) Yep. It's a problem. Ultimately I don't think there's a technical solution to it. > That said, this behavior of HSTS makes me uncomfortable too. > Unfortunately, some browsers have already implemented this; hopefully > other browsers will pause before implementing this behavior. I don't think there's a huge risk if individual browsers implement heavy-handed security policy. Users will simply switch to a browser that lets them do what they want, or maybe they like a strict browser after all. The market can take care of that. The danger is when a documented protocol seems to guarantee something to work a certain way when in reality it doesn't, or is trivial to bypass. Mandated UI restrictions will hold up against product designers and users about as well as software DRM held out against a reverse engineer with a debugger. However, the imaginary restrictions will get documented in books as if they were fact. (Remember the little Javascript tricks that supposedly prevented the user from saving images from your site?) Then web designers and admins end up relying on them as a security property and hilarity ensues. - Marsh From marsh@extendedsubset.com Mon Nov 22 10:49:55 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FC13A6AED for ; Mon, 22 Nov 2010 10:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFXhsEDyoU8s for ; Mon, 22 Nov 2010 10:49:54 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 7E7513A6A2A for ; Mon, 22 Nov 2010 10:49:54 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PKbTW-000CvH-Ev; Mon, 22 Nov 2010 18:50:50 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 3636C6019; Mon, 22 Nov 2010 18:50:47 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX186lZQt49wk+QOzE2aYoR9BqZWNLa7sl6s= Message-ID: <4CEABB85.2030602@extendedsubset.com> Date: Mon, 22 Nov 2010 12:50:45 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Steingruebl, Andy" References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> <4CEAAD0A.2070306@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842FB8@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB18842FB8@DEN-MEXMS-001.corp.ebay.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'websec@ietf.org'" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 18:49:56 -0000 On 11/22/2010 12:05 PM, Steingruebl, Andy wrote: > > I don't disagree. I do however feel that this should be exceptions, > and maybe in an "about:config" configuration, rather than the > default or in plain view in the UI. Yeah, about:config could be a solution. But I feel it's important to be careful of scope creep in a spec, especially if we want it to be fully-implemented. > Yes, it is the user's computer. > But if we didn't want to make security decisions for them, then > browsers wouldn't include phishing filter, certificate warnings, > etc. As it is, we are already making security policy decisions for > users in the browser, and here were are simply proposing another. On 11/22/2010 12:11 PM, Paul Hoffman wrote: > > The "we" here, the IETF, generally does not make such decisions for > users. We make protocols and recommendations to developers. The text > in this document should be worded as such. Right, on one level we can think of this as an editorial issue on the scope of a protocol spec. On 11/22/2010 12:05 PM, Steingruebl, Andy wrote: > > Sorry, didn't reply to this specific point. Unlike DRM I fully > support users being able to opt-out if they'd like. I'm looking to > protect the amateur rather than expert though. I don't know really > though hos you think this is defeating user-intent? One user intends to access Ebay: "That auction ends in 5 minutes darnit!" But they're under MitM attack. Say they're at a hotel or airport that's trying to redirect them to a captive portal (yes this happened to me several times last week). We all know the difficulty in explaining to the user that because some crypto bits don't match up somewhere we think they could be the target of some Mission Impossible-style operation by an international crime syndicate designed to capture their Ebay password. Heck, even plenty of network developers still wouldn't believe that possibility (though I predict that will change). But that user's intent deserves to be defeated. Think about this more insidious case: I'm a web developer starting to work on a new secure web site. I get some pages up and start to test with SSL. What's the first thing I'm going to do? Create some self-signed certificates. Clearly I know that there's not a security threat here, possibly my client and server are both on the same dev box. But if my web browser doesn't let me make occasional exceptions, it's going to be less adopted by web developers, and they are a highly influential group of users. Presumably, many or most sites that will deploy HSTS will try it on their QA network first. I bet a lot of them are running self-signed. If HSTS strictly requires sites to reconfigure their test networks, I predict that will significantly reduce adoption. > The user in > this case doesn't know whether the site in question is really asking > them to approve the exception, their browser is. We're giving the > browser more information to make that decision. Only sites that > opt-in to HSTS get this behavior in the first place, so while the > server-side does control the behavior (absent a user modifying their > UA) it is hard to see how we're defeating user choice here. A > contract is implied here, that a site will keep its certificates up > to date, etc. > > What decision of the user do you really think we're thwarting? This > site has told me previously its only going to use a cert my browser > trusts, but I'm getting a certificate warning, and I think I'll > click through it anyway.... ? It's more the unintended consequences of scope creep in the IETF document. This proposal represents a great improvement at the protocol level. My sense is that probably it should quit while it's ahead, and not use "MUST" in regards to user interaction issues (a far distant layer). - Marsh From asteingruebl@paypal-inc.com Mon Nov 22 11:10:30 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6BF428C125 for ; Mon, 22 Nov 2010 11:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.688 X-Spam-Level: X-Spam-Status: No, score=-5.688 tagged_above=-999 required=5 tests=[AWL=3.429, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzTqD5NNFK2b for ; Mon, 22 Nov 2010 11:10:24 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id 7CC1B28C13D for ; Mon, 22 Nov 2010 11:10:23 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=maNkdGaBRUpNrAtnWqjql7nTtLx3dS7djsG55LYgducG99ofFvD3Dj3k +vccfv5bcr6qWpawa7is0plG1nUk54uGgFDljB77ISA0gHAckgwmAKYDf d/pTA/G22QlZQaQ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1290453080; x=1321989080; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Marsh=20Ray=20|CC: =20"'websec@ietf.org'"=20|Date:=20Mon, =2022=20Nov=202010=2012:11:18=20-0700|Subject:=20RE:=20[w ebsec]=20Some=20questions=20about=20HSTS|Message-ID:=20<5 EE049BA3C6538409BBE6F1760F328ABEB188430C0@DEN-MEXMS-001.c orp.ebay.com>|References:=20<006FEB08D9C6444AB014105C9AEB 133F012E6FCD4474@il-ex01.ad.checkpoint.com>=0D=0A=20<5EE0 49BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp .ebay.com>=0D=0A=20<4CEAAD0A.2070306@extendedsubset.com> =0D=0A=20<5EE049BA3C6538409BBE6F1760F328ABEB18842FB8@DEN- MEXMS-001.corp.ebay.com>=0D=0A=20<4CEABB85.2030602@extend edsubset.com>|In-Reply-To:=20<4CEABB85.2030602@extendedsu bset.com>|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=8QKGjCV8V+DsNkbB59CivJMe0b/SZVpD5+sCO0u1cGU=; b=iYeApybvPF1lYZa23pQLXrnoJi8yKejz1j5GJPwHq3x/LJPF9E+GM6q4 xmp1nwfXNtMawP7XgpgcApkYhXfozxIMX1pymTcJWC5E6oCgwwBglQb0D SY3uZd6RgZHi5EA; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.59,237,1288594800"; d="scan'208";a="167299" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 22 Nov 2010 11:11:19 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Mon, 22 Nov 2010 12:11:19 -0700 From: "Steingruebl, Andy" To: Marsh Ray Date: Mon, 22 Nov 2010 12:11:18 -0700 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuKdjFXylqn8FaUTFCWoZCEvJTMcwAAf2EQ Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB188430C0@DEN-MEXMS-001.corp.ebay.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> <4CEAAD0A.2070306@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842FB8@DEN-MEXMS-001.corp.ebay.com> <4CEABB85.2030602@extendedsubset.com> In-Reply-To: <4CEABB85.2030602@extendedsubset.com> 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-CFilter: Scanned Cc: "'websec@ietf.org'" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 19:10:30 -0000 > -----Original Message----- > From: Marsh Ray [mailto:marsh@extendedsubset.com] >=20 > One user intends to access Ebay: "That auction ends in 5 minutes darnit!"= But > they're under MitM attack. Say they're at a hotel or airport that's tryin= g to > redirect them to a captive portal (yes this happened to me several times = last > week). We all know the difficulty in explaining to the user that because = some > crypto bits don't match up somewhere we think they could be the target of > some Mission Impossible-style operation by an international crime syndica= te > designed to capture their Ebay password. Heck, even plenty of network > developers still wouldn't believe that possibility (though I predict that= will > change). If you don't think these scenarios are at all worth dealing with, then you = probably think HSTS is a stupid idea to begin with, right? If there are no= MiTM attackers, then HSTS doesn't make sense. If you think MiTM attackers= are a real possibility, now or in the future, then you probably care about= HSTS, and you probably want to avoid user's getting actively attacked them= . I understand that this seems like a science-fiction style attack to some fo= lks, but frankly so was network sniffing at one point... or middleware boxe= s spoofing DNS (earthlink) or ISPs spoofing DNS responses (many), etc. =20 > But that user's intent deserves to be defeated. > Think about this more insidious case: >=20 > I'm a web developer starting to work on a new secure web site. I get some > pages up and start to test with SSL. What's the first thing I'm going to = do? > Create some self-signed certificates. Clearly I know that there's not a s= ecurity > threat here, possibly my client and server are both on the same dev box. = But > if my web browser doesn't let me make occasional exceptions, it's going t= o > be less adopted by web developers, and they are a highly influential grou= p of > users. Don't set HSTS *or* put those certs into your trust-store. Both are possib= ilities. It isn't like there are no workarounds here. =20 If I can convince you for a moment that active MiTM attacks will/do happen,= what do you propose as a solution that is workable for the average user? > It's more the unintended consequences of scope creep in the IETF > document. This proposal represents a great improvement at the protocol > level. My sense is that probably it should quit while it's ahead, and not= use > "MUST" in regards to user interaction issues (a far distant layer). I will concede that strictly specifying UA behavior here may be a stretch. = That said, we've left a lot of attack surface over the years because we ha= ven't been clear in specifications about what we consider good design. I'l= l let Jeff and the other contributors take up this specific wording point w= hen they are able to chime in. - Andy From hallam@gmail.com Mon Nov 22 11:23:10 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FDEF28C0CE for ; Mon, 22 Nov 2010 11:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uonFmCtalkhZ for ; Mon, 22 Nov 2010 11:23:09 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 02B353A6A2A for ; Mon, 22 Nov 2010 11:23:08 -0800 (PST) Received: by gxk27 with SMTP id 27so4732364gxk.31 for ; Mon, 22 Nov 2010 11:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ibPVTm9Rh7M2Ahn6cBCOSNJElbZ88Dp5kkWPVJZ1inA=; b=G6UfWUdgkxK8DHX/6Mggzp8Kcud9RE14FUy//qB4E8JMpPGWm8EAJZmLtbp2SsOjJV Hk/HxS8RWrQmgvVez61NUDGz8VbmBz/rOMIv8e1IjPhKMMSD9gHBeNMG3wMmvTWxrgXa 25ENhFouboGOS2LN0qpF5ZdZMxrp9XbXbeZus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=b7I9W8QjlPupDRe0UMmabbDSdaRAZkuwYpPEUN0wd4t4yAqLXBFEHiHwPk9SvrUHUl K/RdQC57dpORpwOlq7Rc8oAkGyLepFPmtueONl3yizQ1lp+z2nADxodERz9L3Jr3C08a kSbtpWHOzEoDlj6deSZGroPHC3QTXqB5c+7bs= MIME-Version: 1.0 Received: by 10.101.69.3 with SMTP id w3mr4316806ank.32.1290453843692; Mon, 22 Nov 2010 11:24:03 -0800 (PST) Received: by 10.100.41.14 with HTTP; Mon, 22 Nov 2010 11:24:03 -0800 (PST) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> Date: Mon, 22 Nov 2010 14:24:03 -0500 Message-ID: From: Phillip Hallam-Baker To: "Steingruebl, Andy" Content-Type: multipart/alternative; boundary=0016368e24cbf3cdf70495a9326c Cc: "websec@ietf.org" Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 19:23:10 -0000 --0016368e24cbf3cdf70495a9326c Content-Type: text/plain; charset=ISO-8859-1 I think we should ask the question of what degree of fidelity we can expect to achieve trying to control layer 5 objects (ports) at layer 7. The HTTP approach is a hack. It is a necessary hack but it is still a hack. And as such we have to accept that we probably have to limit what we attempt to achieve. In the context of Web browser security there is a real possibility that port numbers represent a downgrade attack possibility. http://paypal.com/wlewohefoiwhefoihw looks a lot like: http://paypal.com:81/wlewohefoiwhefoihw The place where I might want to apply different security policy according to port numbers would be in the context of Web Services. That is a very different problem space and at this point I don't think anyone is proposing to apply HSTS there. So I think that HSTS should apply to all ports within the specified domains but that it should NOT apply to Web services at this point. On Mon, Nov 22, 2010 at 11:52 AM, Steingruebl, Andy < asteingruebl@paypal-inc.com> wrote: > > -----Original Message----- > > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > > Behalf Of Daniel Veditz > > Sent: Saturday, November 20, 2010 10:30 PM > > To: websec@ietf.org > > Subject: [websec] HSTS -- what about ports? > > > > The HSTS spec needs to be more clear about how to handle multiple servers > > running on different ports on the same host. I think, by referring to > host > > name matching only, that the intent of the spec is that a server running > on > > any port can set HSTS behavior for every other port on that host. If this > is > > correct it might be clearer to rename "HSTS Server" to "HSTS Host" and to > > somewhere in the spec mention explicitly that the port is ignored when > > matching host names. > > Agreed. This is on Jeff's to-do list per a separate email conversation I > had with him yesterday. > > > > > An alternate behavior would be that a server running on port X only > specifies > > the behavior for that port, with a special case for the default ports > 80/443 > > because they go unspecified. This would make sense from a security POV > > only if cookies were port-specific (with again a special case for the > > unspecified default ports), but I don't believe any browser implements > > cookies in that way. Handling HSTS in a port-specific manner also > complicates > > the meaning of includeSubDomains. > > You're correct. This topic just got re-started again yesterday, and I > wrote a little something about it here: > > > http://securityretentive.blogspot.com/2010/11/quick-clarification-on-hsts-http-strict.html > > Essentially cookie leakage is the problem, and since they aren't scoped to > ports, we must interpret HSTS for *all* ports. > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ --0016368e24cbf3cdf70495a9326c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we should ask the question of what degree of fidelity we can expect= to achieve trying to control layer 5 objects (ports) at layer 7.

<= /div>

The HTTP approach is a hack. It is a necessary hac= k but it is still a hack. And as such we have to accept that we probably ha= ve to limit what we attempt to achieve.=A0

In the context of Web browser security there is a real = possibility that port numbers represent a downgrade attack possibility.=A0<= /div>


looks a lot like:



The place where I might wa= nt to apply different security policy according to port numbers would be in= the context of Web Services.

That is a very different problem space and at this poin= t I don't think anyone is proposing to apply HSTS there.=A0
<= br>
So I think that HSTS should apply to all ports within the spe= cified domains but that it should NOT apply to Web services at this point.<= /div>


On Mon, Nov 22, 2010 at 11:52 AM, S= teingruebl, Andy <asteingruebl@paypal-inc.com> wrote:
> -----Original Message-----
> From: websec-bounces@ietf.o= rg [mailto:websec-bounces@ie= tf.org] On
> Behalf Of Daniel Veditz
> Sent: Saturday, November 20, 2010 10:30 PM
> To: websec@ietf.org
> Subject: [websec] HSTS -- what about ports?
>
> The HSTS spec needs to be more clear about how to handle multiple serv= ers
> running on different ports on the same host. I think, by referring to = host
> name matching only, that the intent of the spec is that a server runni= ng on
> any port can set HSTS behavior for every other port on that host. If t= his is
> correct it might be clearer to rename "HSTS Server" to "= ;HSTS Host" and to
> somewhere in the spec mention explicitly that the port is ignored when=
> matching host names.

Agreed. This is on Jeff's to-do list per a separate email convers= ation I had with him yesterday.

>
> An alternate behavior would be that a server running on port X only sp= ecifies
> the behavior for that port, with a special case for the default ports = 80/443
> because they go unspecified. This would make sense from a security POV=
> only if cookies were port-specific (with again a special case for the<= br> > unspecified default ports), but I don't believe any browser implem= ents
> cookies in that way. Handling HSTS in a port-specific manner also comp= licates
> the meaning of includeSubDomains.

You're correct. =A0This topic just got re-started again yesterday= , and I wrote a little something about it here:

http://securityretentive.blog= spot.com/2010/11/quick-clarification-on-hsts-http-strict.html

Essentially cookie leakage is the problem, and since they aren't scoped= to ports, we must interpret HSTS for *all* ports.
_________________________________________= ______
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec



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

--0016368e24cbf3cdf70495a9326c-- From ietf@adambarth.com Mon Nov 22 17:22:22 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C033A6B02 for ; Mon, 22 Nov 2010 17:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.006 X-Spam-Level: X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[AWL=-2.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiC82MJALqxB for ; Mon, 22 Nov 2010 17:22:21 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id E528C3A6ABA for ; Mon, 22 Nov 2010 17:22:20 -0800 (PST) Received: by qwb7 with SMTP id 7so3056518qwb.31 for ; Mon, 22 Nov 2010 17:23:17 -0800 (PST) Received: by 10.229.189.4 with SMTP id dc4mr5575992qcb.106.1290475397139; Mon, 22 Nov 2010 17:23:17 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id u2sm3264191qcq.19.2010.11.22.17.23.14 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Nov 2010 17:23:15 -0800 (PST) Received: by iwn40 with SMTP id 40so9259253iwn.31 for ; Mon, 22 Nov 2010 17:23:14 -0800 (PST) Received: by 10.231.35.202 with SMTP id q10mr7596301ibd.88.1290475394123; Mon, 22 Nov 2010 17:23:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.8.145 with HTTP; Mon, 22 Nov 2010 17:22:40 -0800 (PST) In-Reply-To: References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> From: Adam Barth Date: Mon, 22 Nov 2010 17:22:40 -0800 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: "websec@ietf.org" Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 01:22:23 -0000 On Mon, Nov 22, 2010 at 11:24 AM, Phillip Hallam-Baker wrote: > So I think that HSTS should apply to all ports within the specified domains > but that it should NOT apply to Web services at this point. What does it mean, concretely, for HSTS not to apply to web services? For example, is api.flickr.com a web service? Is graph.facebook.com? Adam From marsh@extendedsubset.com Mon Nov 22 18:16:37 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D912228C187 for ; Mon, 22 Nov 2010 18:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SjKvA-GwFr1 for ; Mon, 22 Nov 2010 18:16:36 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 6DC9928C100 for ; Mon, 22 Nov 2010 18:16:36 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PKiRo-0009ez-FP; Tue, 23 Nov 2010 02:17:32 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8A39A6019; Tue, 23 Nov 2010 02:17:31 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18esJ+6bZsBAdvvr1Z2T6XoN+jEyIZ/Kz0= Message-ID: <4CEB2435.8060808@extendedsubset.com> Date: Mon, 22 Nov 2010 20:17:25 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Adam Barth References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 02:16:38 -0000 On 11/22/2010 07:22 PM, Adam Barth wrote: > On Mon, Nov 22, 2010 at 11:24 AM, Phillip Hallam-Baker wrote: >> So I think that HSTS should apply to all ports within the specified domains >> but that it should NOT apply to Web services at this point. > > What does it mean, concretely, for HSTS not to apply to web services? > For example, is api.flickr.com a web service? Is graph.facebook.com? Good question. What's a "web" for that matter? Is there an RFC which defines this term? In http://tools.ietf.org/id/draft-hodges-strict-transport-sec-02.html the term "web" is used multiple times, sometimes capitalized like a proper noun, sometimes not. Perhaps the distinction Phillip is getting at is that some clients are purely programmatic, e.g., a software update system which periodically polls for new updates by exchanging XML messages over HTTP or HTTPS. Or an international exchange trading system for, say, IPv4 address space. Do these scenarios present different considerations than a user viewing plain HTML pages with Firefox? For example, are programmatic clients more likely to use nonstandard ports? My guess is that there are some significant differences, but the distinction is blurry in practice. After all, the server app is free to not return the HSTS header if it's not what he intends to convey to his clients, and client libraries are likely to have a means of overriding it if it causes trouble. They're usually started with an https: URL from program configuration, so perhaps we don't need to solve the problem of a user who may just type "examplebank.com" into the UA's address bar. Programmatic clients may not even implement the logic to follow redirects, which may cut down on that attack vector (maybe not - I haven't thought it through). - Marsh From ietf@adambarth.com Mon Nov 22 18:20:43 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064CD28C18F for ; Mon, 22 Nov 2010 18:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.962 X-Spam-Level: X-Spam-Status: No, score=-3.962 tagged_above=-999 required=5 tests=[AWL=-1.985, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtgGPkvjMT7D for ; Mon, 22 Nov 2010 18:20:42 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id DA40028C18E for ; Mon, 22 Nov 2010 18:20:41 -0800 (PST) Received: by qyk11 with SMTP id 11so812527qyk.10 for ; Mon, 22 Nov 2010 18:21:38 -0800 (PST) Received: by 10.229.184.207 with SMTP id cl15mr5026625qcb.190.1290478898122; Mon, 22 Nov 2010 18:21:38 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id s34sm3296392qcp.8.2010.11.22.18.21.36 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Nov 2010 18:21:37 -0800 (PST) Received: by iwn40 with SMTP id 40so9311178iwn.31 for ; Mon, 22 Nov 2010 18:21:36 -0800 (PST) Received: by 10.231.16.131 with SMTP id o3mr7674457iba.38.1290478895957; Mon, 22 Nov 2010 18:21:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.8.145 with HTTP; Mon, 22 Nov 2010 18:21:05 -0800 (PST) In-Reply-To: <4CEB2435.8060808@extendedsubset.com> References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> <4CEB2435.8060808@extendedsubset.com> From: Adam Barth Date: Mon, 22 Nov 2010 18:21:05 -0800 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 02:20:43 -0000 On Mon, Nov 22, 2010 at 6:17 PM, Marsh Ray wrote= : > On 11/22/2010 07:22 PM, Adam Barth wrote: >> On Mon, Nov 22, 2010 at 11:24 AM, Phillip Hallam-Baker >> =A0wrote: >>> So I think that HSTS should apply to all ports within the specified >>> domains >>> but that it should NOT apply to Web services at this point. >> >> What does it mean, concretely, for HSTS not to apply to web services? >> For example, is api.flickr.com a web service? =A0Is graph.facebook.com? > > Good question. > > What's a "web" for that matter? =A0Is there an RFC which defines this ter= m? > In http://tools.ietf.org/id/draft-hodges-strict-transport-sec-02.html > the term "web" is used multiple times, sometimes capitalized like a prope= r > noun, sometimes not. > > Perhaps the distinction Phillip is getting at is that some clients are > purely programmatic, e.g., a software update system which periodically po= lls > for new updates by exchanging XML messages over HTTP or HTTPS. Or an > international exchange trading system for, say, IPv4 address space. > > Do these scenarios present different considerations than a user viewing > plain HTML pages with Firefox? For example, are programmatic clients more > likely to use nonstandard ports? > > My guess is that there are some significant differences, but the distinct= ion > is blurry in practice. After all, the server app is free to not return th= e > HSTS header if it's not what he intends to convey to his clients, and cli= ent > libraries are likely to have a means of overriding it if it causes troubl= e. > > They're usually started with an https: URL from program configuration, so > perhaps we don't need to solve the problem of a user who may just type > "examplebank.com" into the UA's address bar. Programmatic clients may not > even implement the logic to follow redirects, which may cut down on that > attack vector (maybe not - I haven't thought it through). It seems like those User Agents can choose not to implement HSTS if they don't find it valuable. Adam From hallam@gmail.com Mon Nov 22 19:18:37 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D867528C0FD for ; Mon, 22 Nov 2010 19:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS1cjL2xJ7hF for ; Mon, 22 Nov 2010 19:18:36 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 73E4028C0E5 for ; Mon, 22 Nov 2010 19:18:36 -0800 (PST) Received: by gwj17 with SMTP id 17so466801gwj.31 for ; Mon, 22 Nov 2010 19:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=lNt2XbVH6XucYXojLbQ0Q+oZX/vJb9VDK9Vi3h1TqNI=; b=JBG5ngFW65Y8R7ECJNPCIi+PsNiYOJl//6ZS9CjEKQ4rr0dnDWba0kq5AxC2XPUjzk GFN65gh6nCu7rlsBdPOTfh5rNiSMVp0/y7hlaL2X01YSNnFe2RrEDVVR3Eok8fT8WNOb Ia3YKRc3Mn36e7it+h6nhp804g4FhaS1rowJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RLunk1BxPq3SA6w2wVF4VI8Bwy2YE09NUN5co7VBeZUCq7lL/aQwtEUYXM60GlfAUO 8e4EsAaNWqG9ymPmBPU7mkE8Xsj9owVBv9RB00kG7LQxgs8aYx5+/vXxMlNCqP++kgRv EXlHrzovCU2jSU06hh7rAhQx9pUXEEYrxt1Y8= MIME-Version: 1.0 Received: by 10.100.126.1 with SMTP id y1mr4641635anc.100.1290482371664; Mon, 22 Nov 2010 19:19:31 -0800 (PST) Received: by 10.100.41.14 with HTTP; Mon, 22 Nov 2010 19:19:31 -0800 (PST) In-Reply-To: References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> Date: Mon, 22 Nov 2010 22:19:31 -0500 Message-ID: From: Phillip Hallam-Baker To: Adam Barth Content-Type: multipart/alternative; boundary=0016e645b8485a1be10495afd7b1 Cc: "websec@ietf.org" Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 03:18:38 -0000 --0016e645b8485a1be10495afd7b1 Content-Type: text/plain; charset=ISO-8859-1 I am a little skeptical of the scope issues if we have a mixture of Web Services and Web browsers in a domain and some are meant to be always secure, others not. So I think that any domain that decides to deploy HSTS is going to have to accept that they are signing up for supporting the TLS options specified on everything. But I can't see this as being an approach I would like to rely on for Web Services security if there are hundreds of Web Services at a site. On Mon, Nov 22, 2010 at 8:22 PM, Adam Barth wrote: > On Mon, Nov 22, 2010 at 11:24 AM, Phillip Hallam-Baker > wrote: > > So I think that HSTS should apply to all ports within the specified > domains > > but that it should NOT apply to Web services at this point. > > What does it mean, concretely, for HSTS not to apply to web services? > For example, is api.flickr.com a web service? Is graph.facebook.com? > > Adam > -- Website: http://hallambaker.com/ --0016e645b8485a1be10495afd7b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am a little skeptical of the scope issues if we have a mixture of Web Ser= vices and Web browsers in a domain and some are meant to be always secure, = others not.

So I think that any domain that decides to d= eploy HSTS is going to have to accept that they are signing up for supporti= ng the TLS options specified on everything.


But I can't see this as being a= n approach I would like to rely on for Web Services security if there are h= undreds of Web Services at a site.


On Mon, Nov 22, 2010 at 8:22 PM, Adam Barth <ietf@adambarth.com> wrote:
=
On Mon, Nov 22, 2010 at 11:24 AM, Phillip Hallam-Baker &l= t;hallam@gmail.com> wrote:
> So I think that HSTS should apply to all ports within the specified do= mains
> but that it should NOT apply to Web services at this point.

What does it mean, concretely, for HSTS not to apply to web services?=
For example, is api.fli= ckr.com a web service? =A0Is graph.facebook.com?

Adam



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

--0016e645b8485a1be10495afd7b1-- From ietf@adambarth.com Mon Nov 22 19:24:14 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706C928C176 for ; Mon, 22 Nov 2010 19:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.92 X-Spam-Level: X-Spam-Status: No, score=-3.92 tagged_above=-999 required=5 tests=[AWL=-1.943, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcvJ1Iys27g0 for ; Mon, 22 Nov 2010 19:24:11 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 5ABF628C0E5 for ; Mon, 22 Nov 2010 19:24:11 -0800 (PST) Received: by gwj17 with SMTP id 17so468510gwj.31 for ; Mon, 22 Nov 2010 19:25:08 -0800 (PST) Received: by 10.100.211.8 with SMTP id j8mr4707930ang.127.1290482707467; Mon, 22 Nov 2010 19:25:07 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id 6sm6544899anx.32.2010.11.22.19.25.06 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Nov 2010 19:25:06 -0800 (PST) Received: by iwn40 with SMTP id 40so9365572iwn.31 for ; Mon, 22 Nov 2010 19:25:05 -0800 (PST) Received: by 10.231.12.11 with SMTP id v11mr7592380ibv.13.1290482705532; Mon, 22 Nov 2010 19:25:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.8.145 with HTTP; Mon, 22 Nov 2010 19:24:35 -0800 (PST) In-Reply-To: References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> From: Adam Barth Date: Mon, 22 Nov 2010 19:24:35 -0800 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 03:24:15 -0000 That seems like a choice that folks who host those web services can make when they decide whether or not to use HSTS. Adam On Mon, Nov 22, 2010 at 7:19 PM, Phillip Hallam-Baker wr= ote: > I am a little skeptical of the scope issues if we have a mixture of Web > Services and Web browsers in a domain and some are meant to be always > secure, others not. > > So I think that any domain that decides to deploy HSTS is going to have t= o > accept that they are signing up for supporting the TLS options specified = on > everything. > > But I can't see this as being an approach I would like to rely on for Web > Services security if there are hundreds of Web Services at a site. > > On Mon, Nov 22, 2010 at 8:22 PM, Adam Barth wrote: >> >> On Mon, Nov 22, 2010 at 11:24 AM, Phillip Hallam-Baker >> wrote: >> > So I think that HSTS should apply to all ports within the specified >> > domains >> > but that it should NOT apply to Web services at this point. >> >> What does it mean, concretely, for HSTS not to apply to web services? >> For example, is api.flickr.com a web service? =A0Is graph.facebook.com? >> >> Adam > > > > -- > Website: http://hallambaker.com/ > > From mnot@mnot.net Mon Nov 22 20:15:32 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7F828C0E5 for ; Mon, 22 Nov 2010 20:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.782 X-Spam-Level: X-Spam-Status: No, score=-104.782 tagged_above=-999 required=5 tests=[AWL=-2.183, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfyPeTxvr9b5 for ; Mon, 22 Nov 2010 20:15:31 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 641C728C12E for ; Mon, 22 Nov 2010 20:15:31 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5417622E256; Mon, 22 Nov 2010 23:16:18 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Tue, 23 Nov 2010 15:16:16 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> <4CEB2435.8060808@extendedsubset.com> To: Adam Barth X-Mailer: Apple Mail (2.1082) Cc: websec Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 04:15:32 -0000 On 23/11/2010, at 1:21 PM, Adam Barth wrote: > It seems like those User Agents can choose not to implement HSTS if > they don't find it valuable. Indeed; this includes most existing UAs ;) -- Mark Nottingham http://www.mnot.net/ From ynir@checkpoint.com Mon Nov 22 21:46:10 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351E93A6B0D for ; Mon, 22 Nov 2010 21:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.972 X-Spam-Level: X-Spam-Status: No, score=-7.972 tagged_above=-999 required=5 tests=[AWL=2.627, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fkVqilpZwWn for ; Mon, 22 Nov 2010 21:46:05 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 0D3803A6B0B for ; Mon, 22 Nov 2010 21:46:02 -0800 (PST) X-CheckPoint: {4CEB51F5-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oAN5kwYk005798; Tue, 23 Nov 2010 07:46:58 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 23 Nov 2010 07:46:58 +0200 From: Yoav Nir To: "Steingruebl, Andy" Date: Tue, 23 Nov 2010 07:46:54 +0200 Thread-Topic: Some questions about HSTS Thread-Index: AcuK0dd1cAHD4V66TjujzKRkKIOsrw== Message-ID: References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> 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 Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 05:46:10 -0000 Hi Andy. Taking both your answers together, suppose I have a web server with a corpo= rate or self-signed certificate, which is OK, as I expect all my users to a= pprove an exception (as it's called in Firefox). I turn on HSTS because I'm= worried about them being duped by a fake server using HTTP. To me, HSTS re= duces the attack surface by making them dupable only on the first ever conn= ect. Then, as it turns out, a certain browser breaks the connection when co= nnecting from outside the organization, because the CDP is not available. F= ine, I turn off HSTS, but because the cache is untouched, the users will ge= t intermittent connectivity problems for three more months. I agree with Marsh, that this is too much of scope creep. It makes sense fo= r a big website like paypal, amazon or gmail to want strict enforcement on = the client. But smaller websites don't have the IT department of such compa= nies, and often let their certificates expire. In their case, having HSTS o= n would cause a lot of trouble on certificate expiry day. The use case that I am interested in is not a big commercial website, but r= ather an SSL-VPN portal. These have two relevant properties: They come pre-= packaged, and they're SSL-only. It is up to the customer to get a certifica= te, or generate a self-signed one. I would have liked to have HSTS on by de= fault for such a product, but if that means that customers with self-signed= certificates or corporate certificates get long-lasting connectivity probl= ems, I can't justify that. Sure, I can have a configuration flag for whether or not we should have the= header, but administrators tend to configure those wrong just as much as u= sers tend to click through dangerous screens. What do the current implementations (Chrome, Firefox) do? Yoav On Nov 22, 2010, at 6:57 PM, Steingruebl, Andy wrote: >> In sections 2.4.1.1, point #9 says: >> 9. UAs need to prevent users from clicking-through security >> warnings. Halting connection attempts in the face of secure >> transport exceptions is acceptable. >> What exactly are these secure transport exceptions? Expired certificate= s? >> Mismatched FQDN? Revoked certificates? Unreachable CRL? Untrusted CA? >> Self-signed? >=20 > Anything that would currently pop a browser warning for a user currently.= Browsers differ slightly in how they handle OCSP, etc. In any case where= a browser has already made the policy decision it should show a certificat= e "error", it must now abort. >=20 >> Also, I don't understand why this change is needed. HSTS is supposed to = stop >> a very specific attack vector - a user duped into using insecure HTTP ov= er the >> (presumably secure) HTTPS.=20 >>=20 >> As it is, HSTS cannot be used by servers with self-signed or corporate >> certificates, for fear that user agents may not allow the user to browse= . >=20 > That is correct. I personally believe, as do several of the contributors= on this (and I hope I'm not speaking too much out of turn) that self-signe= d certificate warnings are just a punt, and an easy way for a user to make = a bad security decision. If you want to support HTTPS, do it with a cert = that your browser already trusts. Anything else is just a recipe for a MiT= M attack. If a host advertises HSTS, it is specifically opting into this s= cheme, whereby all certificate warnings will cause abort, with no chance to= "fool" the user into making the wrong decision. >=20 >> My second question regards the UA behavior when policy changes. Suppose >> a website has had the HSTS header for a while. The UA has a cache entry = with >> a TTL of several more weeks. Now the UA connects to the server (over >> HTTPS) and does not get an HSTS header at all. What now? If there was a >> header and it was merely changed, the spec says to update the cache entr= y. >> But if the header is missing altogether, does that mean that the UA shou= ld >> delete the cache entry? >=20 > I think we can make this clear, but until the client receives a new heade= r, it does not tinker with the cache. We do say the header should be prese= nt in all /most server responses, but the behavior should be that the value= persists until set to something else. >=20 > - Andy >=20 >=20 > Scanned by Check Point Total Security Gateway. From marsh@extendedsubset.com Mon Nov 22 21:56:17 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D582E3A6B1F for ; Mon, 22 Nov 2010 21:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnqH8H+uixiD for ; Mon, 22 Nov 2010 21:56:16 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id D4A6F3A6B1E for ; Mon, 22 Nov 2010 21:56:16 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PKlsP-0003a2-6N; Tue, 23 Nov 2010 05:57:13 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 514AE6019; Tue, 23 Nov 2010 05:57:11 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/OOUj/llmTpulRRrI8WrnWTvO6f2Uc5+M= Message-ID: <4CEB57B8.8020901@extendedsubset.com> Date: Mon, 22 Nov 2010 23:57:12 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 05:56:17 -0000 On 11/22/2010 09:19 PM, Phillip Hallam-Baker wrote: > > So I think that any domain that decides to deploy HSTS is going to have > to accept that they are signing up for supporting the TLS options > specified on everything. Where "everything" = "served from that hostname" > But I can't see this as being an approach I would like to rely on for > Web Services security if there are hundreds of Web Services at a site. The composite identifier scheme:host:port is already the key to the whole security model. There are no useful security boundaries within a hostname:port (except possibly GET vs. POST if everything is coded right). With HSTS, by definition, all content for that hostname is served over TCP port 443. So the port is now static, and just the specific DNS hostname is the key identifier for the site security. This is actually _more_ fine-grained than the security boundaries given by other parts of the system. In particular, the server of pretty much _any_ hostname *.example.com gets to jack around with the cookies sent to _every_ hostname *.example.com (and even to example.com itself). Top-level domains for which a registrar assigns domains with two dots in them (example.co.uk) have to be enumerated thoroughly in browser software. Any omissions may represent a security vulnerability. http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1 Not only are there no solid security boundaries within a given hostname, there really aren't any under a domain name either! All those "hundreds of Web Services" running at a site are effectively no more secure than the least secure of them all (with regards to cookies at least). It may only take an XSS weakness in one of them to compromise the security of all of them. Note that even plain HTTP connections can set cookies which are sent to the server with HTTPS requests. Such a site needs HSTS more than anyone! - Marsh From ietf@adambarth.com Mon Nov 22 22:06:03 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 694CC3A6B3E for ; Mon, 22 Nov 2010 22:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.879 X-Spam-Level: X-Spam-Status: No, score=-3.879 tagged_above=-999 required=5 tests=[AWL=-1.902, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9p9v--9WO9e for ; Mon, 22 Nov 2010 22:06:01 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id A824E3A6B3B for ; Mon, 22 Nov 2010 22:06:01 -0800 (PST) Received: by yxk30 with SMTP id 30so2009924yxk.31 for ; Mon, 22 Nov 2010 22:06:58 -0800 (PST) Received: by 10.100.55.10 with SMTP id d10mr4748468ana.179.1290492417312; Mon, 22 Nov 2010 22:06:57 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id d10sm6713630and.39.2010.11.22.22.06.55 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Nov 2010 22:06:56 -0800 (PST) Received: by iwn40 with SMTP id 40so9506683iwn.31 for ; Mon, 22 Nov 2010 22:06:54 -0800 (PST) Received: by 10.231.12.11 with SMTP id v11mr7757968ibv.13.1290492414845; Mon, 22 Nov 2010 22:06:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.8.145 with HTTP; Mon, 22 Nov 2010 22:06:24 -0800 (PST) In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> From: Adam Barth Date: Mon, 22 Nov 2010 22:06:24 -0800 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 06:06:03 -0000 On Mon, Nov 22, 2010 at 9:46 PM, Yoav Nir wrote: > Taking both your answers together, suppose I have a web server with a cor= porate or self-signed certificate, which is OK, as I expect all my users to= approve an exception (as it's called in Firefox). I turn on HSTS because I= 'm worried about them being duped by a fake server using HTTP. To me, HSTS = reduces the attack surface by making them dupable only on the first ever co= nnect. Then, as it turns out, a certain browser breaks the connection when = connecting from outside the organization, because the CDP is not available.= Fine, I turn off HSTS, but because the cache is untouched, the users will = get intermittent connectivity problems for three more months. I don't recommend using HSTS with self-signed certificates. In this scenario, I'd recommend the corporation install a root certificate in all machines owned by the corporation and then use that root certificate to issue whatever other certificates the corporation needs. > I agree with Marsh, that this is too much of scope creep. It makes sense = for a big website like paypal, amazon or gmail to want strict enforcement o= n the client. But smaller websites don't have the IT department of such com= panies, and often let their certificates expire. In their case, having HSTS= on would cause a lot of trouble on certificate expiry day. Folks are already in for a headache if they let their certificates expire. They'll get big nasty warnings in either case. The difference is only whether those warnings will let the user ignore them. If you don't think your organization is sufficiently competent to schedule a reminder to update its certificates, then I don't recommend using HSTS. > The use case that I am interested in is not a big commercial website, but= rather an SSL-VPN portal. These have two relevant properties: They come pr= e-packaged, and they're SSL-only. It is up to the customer to get a certifi= cate, or generate a self-signed one. I would have liked to have HSTS on by = default for such a product, but if that means that customers with self-sign= ed certificates or corporate certificates get long-lasting connectivity pro= blems, I can't justify that. Indeed. Please don't use HSTS with self-signed certificates. HSTS is a feature for well-maintained web sites that have a need for strong security. The reason we designed HSTS was to differentiate between sites that actually want strong security and sites that are using TLS but don't have strong security needs. If you don't need strong security, you don't need HSTS (and the additional careful administration it requires). > Sure, I can have a configuration flag for whether or not we should have t= he header, but administrators tend to configure those wrong just as much as= users tend to click through dangerous screens. I don't think user agents should offer such a configuration flag. > What do the current implementations (Chrome, Firefox) do? They do what the spec says. TLS errors on HSTS hosts are treated as fatal errors, much like the host's DNS name not resolving. There is no recourse except to reload the page. Adam > On Nov 22, 2010, at 6:57 PM, Steingruebl, Andy wrote: > >>> In sections 2.4.1.1, point #9 says: >>> =A0 9. =A0UAs need to prevent users from clicking-through security >>> =A0 =A0 =A0 warnings. =A0Halting connection attempts in the face of sec= ure >>> =A0 =A0 =A0 transport exceptions is acceptable. >>> What exactly are these secure transport exceptions? =A0Expired certific= ates? >>> Mismatched FQDN? Revoked certificates? Unreachable CRL? Untrusted CA? >>> Self-signed? >> >> Anything that would currently pop a browser warning for a user currently= . =A0Browsers differ slightly in how they handle OCSP, etc. =A0In any case = where a browser has already made the policy decision it should show a certi= ficate "error", it must now abort. >> >>> Also, I don't understand why this change is needed. HSTS is supposed to= stop >>> a very specific attack vector - a user duped into using insecure HTTP o= ver the >>> (presumably secure) HTTPS. >>> >>> As it is, HSTS cannot be used by servers with self-signed or corporate >>> certificates, for fear that user agents may not allow the user to brows= e. >> >> That is correct. =A0I personally believe, as do several of the contribut= ors on this (and I hope I'm not speaking too much out of turn) that self-si= gned certificate warnings are just a punt, and an easy way for a user to ma= ke a bad security decision. =A0If =A0you want to support HTTPS, do it with = a cert that your browser already trusts. =A0Anything else is just a recipe = for a MiTM attack. =A0If a host advertises HSTS, it is specifically opting = into this scheme, whereby all certificate warnings will cause abort, with n= o chance to "fool" the user into making the wrong decision. >> >>> My second question regards the UA behavior when policy changes. Suppose >>> a website has had the HSTS header for a while. The UA has a cache entry= with >>> a TTL of several more weeks. Now the UA connects to the server (over >>> HTTPS) and does not get an HSTS header at all. What now? =A0If there wa= s a >>> header and it was merely changed, the spec says to update the cache ent= ry. >>> But if the header is missing altogether, does that mean that the UA sho= uld >>> delete the cache entry? >> >> I think we can make this clear, but until the client receives a new head= er, it does not tinker with the cache. =A0We do say the header should be pr= esent in all /most server responses, but the behavior should be that the va= lue persists until set to something else. >> >> - Andy >> >> >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From ietf@adambarth.com Mon Nov 22 22:10:08 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4BA3A6B49 for ; Mon, 22 Nov 2010 22:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.841 X-Spam-Level: X-Spam-Status: No, score=-3.841 tagged_above=-999 required=5 tests=[AWL=-1.864, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nToy2FZQi2Rt for ; Mon, 22 Nov 2010 22:10:07 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DEDA93A6B46 for ; Mon, 22 Nov 2010 22:10:06 -0800 (PST) Received: by gyb13 with SMTP id 13so2081294gyb.31 for ; Mon, 22 Nov 2010 22:11:03 -0800 (PST) Received: by 10.150.191.8 with SMTP id o8mr10971499ybf.264.1290492662369; Mon, 22 Nov 2010 22:11:02 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id v39sm116345yba.19.2010.11.22.22.11.00 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Nov 2010 22:11:01 -0800 (PST) Received: by iwn40 with SMTP id 40so9510023iwn.31 for ; Mon, 22 Nov 2010 22:11:00 -0800 (PST) Received: by 10.231.16.131 with SMTP id o3mr7909851iba.38.1290492660166; Mon, 22 Nov 2010 22:11:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.8.145 with HTTP; Mon, 22 Nov 2010 22:10:30 -0800 (PST) In-Reply-To: <4CEB57B8.8020901@extendedsubset.com> References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> <4CEB57B8.8020901@extendedsubset.com> From: Adam Barth Date: Mon, 22 Nov 2010 22:10:30 -0800 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Cc: "websec@ietf.org" Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 06:10:08 -0000 On Mon, Nov 22, 2010 at 9:57 PM, Marsh Ray wrote: > With HSTS, by definition, all content for that hostname is served over TCP > port 443. So the port is now static, and just the specific DNS hostname is > the key identifier for the site security. That is not correct. You can serve content on a HSTS server on any port except port 80. > This is actually _more_ fine-grained than the security boundaries given by > other parts of the system. In particular, the server of pretty much _any_ > hostname *.example.com gets to jack around with the cookies sent to _every_ > hostname *.example.com (and even to example.com itself). This is a design flaw with cookies and is not reflective of how the rest of the web security model works. > All those "hundreds of Web Services" running at a site are effectively no > more secure than the least secure of them all (with regards to cookies at > least). It may only take an XSS weakness in one of them to compromise the > security of all of them. Note that even plain HTTP connections can set > cookies which are sent to the server with HTTPS requests. XSS can only affect user agents that process HTML and related technologies. If the user agents for these web services are more like a Python script issuing HTTP requests using OAuth token, I'm not sure your analysis applies. > Such a site needs HSTS more than anyone! That's not entirely clear to me. Adam From marsh@extendedsubset.com Mon Nov 22 23:21:56 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84C3528C1A8 for ; Mon, 22 Nov 2010 23:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxzHPaiNHVH0 for ; Mon, 22 Nov 2010 23:21:55 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 244E728C1A4 for ; Mon, 22 Nov 2010 23:21:55 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PKnDH-000BXV-Ib; Tue, 23 Nov 2010 07:22:51 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 4DCF76019; Tue, 23 Nov 2010 07:22:50 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+zE6lTRS9DisDJtCHuH9uMxNqJoEl08Eo= Message-ID: <4CEB6BCA.5000509@extendedsubset.com> Date: Tue, 23 Nov 2010 01:22:50 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Adam Barth References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> <4CEB57B8.8020901@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 07:21:56 -0000 On 11/23/2010 12:10 AM, Adam Barth wrote: > On Mon, Nov 22, 2010 at 9:57 PM, Marsh Ray > wrote: >> With HSTS, by definition, all content for that hostname is served >> over TCP port 443. So the port is now static, and just the specific >> DNS hostname is the key identifier for the site security. > > That is not correct. You can serve content on a HSTS server on any > port except port 80. Hmmm. I'd read this part: > All insecure ("http") connections to a HSTS Server are redirected by > the HSTS Server to be secure connections ("https"). It said "http" and I figured it meant "http:" the HTTP protocol specifier, not just port 80 in particular. *searches* I don't find the number "80" in the document. Is there some wording that makes that intent clear? But you're saying that if twitter.com went HSTS, even a browser which did consider twitter.com a "Known HSTS Server" should still be willing to load pages from http://twitter.com:31337/ ? Please correct me if I'm mistaken with any of this, but couldn't an attacker simply send the browser a 302 redirect to Location: http://twitter.com:31337/ and see all the twitter.com cookies in flight? (none of them are marked secure) An active attacker could also proxy the user's request to the real https://twitter.com/ and see the actual response. Isn't this the kind of thing HSTS is supposed to stop? >> This is actually _more_ fine-grained than the security boundaries >> given by other parts of the system. In particular, the server of >> pretty much _any_ hostname *.example.com gets to jack around with >> the cookies sent to _every_ hostname *.example.com (and even to >> example.com itself). > > This is a design flaw with cookies and is not reflective of how the > rest of the web security model works. Nevertheless, it's what we have for the foreseeable future. >> All those "hundreds of Web Services" running at a site are >> effectively no more secure than the least secure of them all (with >> regards to cookies at least). It may only take an XSS weakness in >> one of them to compromise the security of all of them. Note that >> even plain HTTP connections can set cookies which are sent to the >> server with HTTPS requests. > > XSS can only affect user agents that process HTML and related > technologies. If the user agents for these web services are more > like a Python script issuing HTTP requests using OAuth token, I'm not > sure your analysis applies. For example say that an attacker can convince a web service app to reflect back something the browser will interpret as script. He may be able to send the browser a redirect to that web service request URL. When the browser fetches the URL it's willing to supply any cached authentication credentials it has available, even a client cert. Now attacker has script running in the browser, though perhaps under a web service origin. Nevertheless, this script can generalize the document.domain to domain names that are suffixes of the web service hostname, set cookies at that level, and use iframes and xmlhttprequests to make nearly-arbitrary requests (with the credentials of the legitimate user). - Marsh From ietf@adambarth.com Tue Nov 23 00:05:56 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E80C28C1AC for ; Tue, 23 Nov 2010 00:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.803 X-Spam-Level: X-Spam-Status: No, score=-3.803 tagged_above=-999 required=5 tests=[AWL=-1.827, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNaqFfNmR+1L for ; Tue, 23 Nov 2010 00:05:55 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id EF15728C1A3 for ; Tue, 23 Nov 2010 00:05:54 -0800 (PST) Received: by gyb13 with SMTP id 13so2115508gyb.31 for ; Tue, 23 Nov 2010 00:06:51 -0800 (PST) Received: by 10.151.154.19 with SMTP id g19mr590709ybo.440.1290499611628; Tue, 23 Nov 2010 00:06:51 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id q5sm170853ybe.18.2010.11.23.00.06.50 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Nov 2010 00:06:51 -0800 (PST) Received: by iwn40 with SMTP id 40so9617921iwn.31 for ; Tue, 23 Nov 2010 00:06:49 -0800 (PST) Received: by 10.231.12.11 with SMTP id v11mr7877728ibv.13.1290499607815; Tue, 23 Nov 2010 00:06:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.8.145 with HTTP; Tue, 23 Nov 2010 00:06:17 -0800 (PST) In-Reply-To: <4CEB6BCA.5000509@extendedsubset.com> References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> <4CEB57B8.8020901@extendedsubset.com> <4CEB6BCA.5000509@extendedsubset.com> From: Adam Barth Date: Tue, 23 Nov 2010 00:06:17 -0800 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 08:05:56 -0000 On Mon, Nov 22, 2010 at 11:22 PM, Marsh Ray wrot= e: > On 11/23/2010 12:10 AM, Adam Barth wrote: >> On Mon, Nov 22, 2010 at 9:57 PM, Marsh Ray >> wrote: >>> >>> With HSTS, by definition, all content for that hostname is served >>> over TCP port 443. So the port is now static, and just the specific >>> DNS hostname is the key identifier for the site security. >> >> That is not correct. =A0You can serve content on a HSTS server on any >> port except port 80. > > Hmmm. I'd read this part: > >> All insecure ("http") connections to a HSTS Server are redirected by >> the HSTS Server to be secure connections ("https"). > > It said "http" and I figured it meant "http:" the HTTP protocol specifier= , > not just port 80 in particular. *searches* I don't find the number "80" i= n > the document. Is there some wording that makes that intent clear? Yeah, this is being discussed in another thread on this list. Andy posted a clarification on his blog recent: http://securityretentive.blogspot.com/2010/11/quick-clarification-on-hsts-h= ttp-strict.html > But you're saying that if twitter.com went HSTS, even a browser which did > consider twitter.com a "Known HSTS Server" should still be willing to loa= d > pages from http://twitter.com:31337/ ? Nope, but it would be willing to load https://twitter.com:31337/ (i.e., the "http" replaced with "https"). > Please correct me if I'm mistaken with any of this, but couldn't an attac= ker > simply send the browser a 302 redirect to Location: > http://twitter.com:31337/ and see all the twitter.com cookies in flight? > (none of them are marked secure) An active attacker could also proxy the > user's request to the real https://twitter.com/ and see the actual respon= se. > > Isn't this the kind of thing HSTS is supposed to stop? Indeed. >>> This is actually _more_ fine-grained than the security boundaries >>> given by other parts of the system. In particular, the server of >>> pretty much _any_ hostname *.example.com gets to jack around with >>> the cookies sent to _every_ hostname *.example.com (and even to >>> example.com itself). >> >> This is a design flaw with cookies and is not reflective of how the >> rest of the web security model works. > > Nevertheless, it's what we have for the foreseeable future. At least for folks who use cookies. >>> All those "hundreds of Web Services" running at a site are >>> effectively no more secure than the least secure of them all (with >>> regards to cookies at least). It may only take an XSS weakness in >>> one of them to compromise the security of all of them. Note that >>> even plain HTTP connections can set cookies which are sent to the >>> server with HTTPS requests. >> >> XSS can only affect user agents that process HTML and related >> technologies. =A0If the user agents for these web services are more >> like a Python script issuing HTTP requests using OAuth token, I'm not >> sure your analysis applies. > > For example say that an attacker can convince a web service app to reflec= t > back something the browser will interpret as script. He may be able to se= nd > the browser a redirect to that web service request URL. When the browser > fetches the URL it's willing to supply any cached authentication credenti= als > it has available, even a client cert. You're assuming a very specific authentication framework. Why would my Python script running on EC2 share credentials with any web browser? How would my script's OAuth access tokens be shared with a web browser even if they were running on the same machine? > Now attacker has script running in the > browser, though perhaps under a web service origin. Which is likely useless. > Nevertheless, this > script can generalize the document.domain to domain names that are suffix= es > of the web service hostname, set cookies at that level, and use iframes a= nd > xmlhttprequests to make nearly-arbitrary requests (with the credentials o= f > the legitimate user). You're assuming the web service host name has any concept of a "legitimate user." Adam From ynir@checkpoint.com Tue Nov 23 01:21:06 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497D23A6817 for ; Tue, 23 Nov 2010 01:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.191 X-Spam-Level: X-Spam-Status: No, score=-8.191 tagged_above=-999 required=5 tests=[AWL=2.408, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdGl0icmQCYW for ; Tue, 23 Nov 2010 01:21:05 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 983CB3A681B for ; Tue, 23 Nov 2010 01:21:04 -0800 (PST) X-CheckPoint: {4CEB8459-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oAN9LtnQ005038; Tue, 23 Nov 2010 11:21:55 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 23 Nov 2010 11:21:55 +0200 From: Yoav Nir To: Adam Barth Date: Tue, 23 Nov 2010 11:21:53 +0200 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuK797SbpmghwKZSmaeRoD4ZuuIPw== Message-ID: <8D7D477E-9A5C-43D0-A3E0-5F9A8C446A9A@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 09:21:06 -0000 On Nov 23, 2010, at 8:06 AM, Adam Barth wrote: >> Sure, I can have a configuration flag for whether or not we should have = the header, but administrators tend to configure those wrong just as much a= s users tend to click through dangerous screens. >=20 > I don't think user agents should offer such a configuration flag. Not for the UA. For the portal product. >=20 >> What do the current implementations (Chrome, Firefox) do? >=20 > They do what the spec says. TLS errors on HSTS hosts are treated as > fatal errors, much like the host's DNS name not resolving. There is > no recourse except to reload the page. I have just tested this with Firefox 4 (beta 8 - yesterday's nightly build)= and with Chrome (7.0.517.44 if that matters). I used a website where the c= ertificate has several problems: the CA is untrusted, and the CN does not m= atch the domain name. Clearly a cause for red screen / "I understand the ri= sks" message. With Chrome, I got the red screen on the first connect, and also on the sec= ond connect. But STS worked. I typed "http://" and got "https://" instead. With Firefox, I got the "I Understand the Risks" page both the first and se= cond time, and again STS worked. So the truth is that both Firefox and Chrome do what IMO is the right thing= , and ignore point #9.=20 I agree with those developers' choice, but I guess that debate is what mail= ing lists are for. Yoav= From marsh@extendedsubset.com Tue Nov 23 09:03:02 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B133A680C for ; Tue, 23 Nov 2010 09:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cruk9FTvvE4g for ; Tue, 23 Nov 2010 09:03:00 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id AEC1D3A6881 for ; Tue, 23 Nov 2010 09:03:00 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PKwHd-000NBf-CM; Tue, 23 Nov 2010 17:03:57 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 3245C6019; Tue, 23 Nov 2010 17:03:56 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX189cloo5KqUZe7ioSCJxxvY8Ao7sMSANf0= Message-ID: <4CEBF3FB.6070009@extendedsubset.com> Date: Tue, 23 Nov 2010 11:03:55 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Adam Barth References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> <4CEB57B8.8020901@extendedsubset.com> <4CEB6BCA.5000509@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 17:03:02 -0000 On 11/23/2010 02:06 AM, Adam Barth wrote: > On Mon, Nov 22, 2010 at 11:22 PM, Marsh Ray wrote: >> On 11/23/2010 12:10 AM, Adam Barth wrote: >>> >>> That is not correct. You can serve content on a HSTS server on any >>> port except port 80. OK, I think I get it now. I took that to include plain HTTP. > Yeah, this is being discussed in another thread on this list. Andy > posted a clarification on his blog recent: > > http://securityretentive.blogspot.com/2010/11/quick-clarification-on-hsts-http-strict.html > >> But you're saying that if twitter.com went HSTS, even a browser which did >> consider twitter.com a "Known HSTS Server" should still be willing to load >> pages from http://twitter.com:31337/ ? > > Nope, but it would be willing to load https://twitter.com:31337/ > (i.e., the "http" replaced with "https"). So what's the reasoning behind forbidding https://twitter.com:80/ ? (other than not wanting img src links to be able to send line noise to HTTP servers). >>> This is a design flaw with cookies and is not reflective of how the >>> rest of the web security model works. >> >> Nevertheless, it's what we have for the foreseeable future. > > At least for folks who use cookies. Is there a practical alternative to cookies for web session management? TLS session IDs? URL rewriting? >> For example say that an attacker can convince a web service app to reflect >> back something the browser will interpret as script. He may be able to send >> the browser a redirect to that web service request URL. When the browser >> fetches the URL it's willing to supply any cached authentication credentials >> it has available, even a client cert. > > You're assuming a very specific authentication framework. Why would > my Python script running on EC2 share credentials with any web > browser? How would my script's OAuth access tokens be shared with a > web browser even if they were running on the same machine? Hmm.. I didn't say anything about OAuth. Perhaps you are the one with the specific authentication framework in mind? :-) I bet the firewall and VPN guys on the list will back me up on this. For the great majority of customers I work with the overall goal is exactly that - to unify authentication to disparate systems to a single directory. Single sign on. Kerberos+LDAP, MS Active Directory. RADIUS, TACACS, etc. Out of the box, MSIE will transparently (i.e., without user intervention) do NTLM and Kerb auth if it thinks it's talking to the "intranet zone" (don't ask exactly what that means). In most of these schemes, little or no information about the actual request being authenticated is bound into the auth. Credentials forwarding attack. >> Now attacker has script running in the >> browser, though perhaps under a web service origin. > > Which is likely useless. Hmmm, I wouldn't count on it. >> Nevertheless, this >> script can generalize the document.domain to domain names that are suffixes >> of the web service hostname, set cookies at that level, and use iframes and >> xmlhttprequests to make nearly-arbitrary requests (with the credentials of >> the legitimate user). > > You're assuming the web service host name has any concept of a > "legitimate user." Not necessarily. It could be the user's credentials on "twitter.com" site that's hijacked by script echoed from "unauthenticatedwebservice.twitter.com". Still, I think there are quite a few web services out there which do have the concept of "legitimate user" and even authenticate against a common directory as other stuff worth attacking (the SSL VPN for example). Really though it's less about the Python script and more about whether or not the UA thinks it should authenticate using the user's stored credentials. - Marsh From asteingruebl@paypal-inc.com Tue Nov 23 09:49:01 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97AB83A693E for ; Tue, 23 Nov 2010 09:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqEStwtVd3Hp for ; Tue, 23 Nov 2010 09:48:59 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id 98FE63A68F5 for ; Tue, 23 Nov 2010 09:48:59 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=fr42OG7R4Us+udQEhE06dPHZ6i6/ggnndwlQeyik/Cfp5P4XfHJSeWSU sHci0eIWyaRvF1FZCxfmn9cGxY3G4sz3YGJX7knW2zLiqaIk196Q+7ZBD 3rnvvrZowB233jv; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1290534598; x=1322070598; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Yoav=20Nir=20,=20Adam=20 Barth=20|CC:=20"websec@ietf.org"=20|Date:=20Tue,=2023=20Nov=202010=2010:49:56 =20-0700|Subject:=20RE:=20[websec]=20Some=20questions=20a bout=20HSTS|Message-ID:=20<5EE049BA3C6538409BBE6F1760F328 ABEB188436D0@DEN-MEXMS-001.corp.ebay.com>|References:=20< 006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.c heckpoint.com>=0D=0A=20<5EE049BA3C6538409BBE6F1760F328ABE B18842ED6@DEN-MEXMS-001.corp.ebay.com>=0D=0A=20=0D=0A=20 =0D=0A=20<8D7D477E-9A5C-43D0-A3E0-5F9A8C446A9A@checkpoint .com>|In-Reply-To:=20<8D7D477E-9A5C-43D0-A3E0-5F9A8C446A9 A@checkpoint.com>|Content-Transfer-Encoding:=20quoted-pri ntable|MIME-Version:=201.0; bh=nEevJ8vjPHE9b5yFneeoqkWHjaQPniw8J42A9Ye39Lo=; b=o8eNJfjxG01qGxx8MWf34kVlgGT4WUXm7fKND/n8BoD32DOj6OvizTWs nK9rcgpxp/0fWB9OYbmwyAzoxTkjLNM72gwFnkokMc01mhb7RxqVADx8b ZQCjIldwgIVy5qe; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.59,243,1288594800"; d="scan'208";a="188547" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 23 Nov 2010 09:49:57 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Tue, 23 Nov 2010 10:49:57 -0700 From: "Steingruebl, Andy" To: Yoav Nir , Adam Barth Date: Tue, 23 Nov 2010 10:49:56 -0700 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuK797SbpmghwKZSmaeRoD4ZuuIPwARe3IQ Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB188436D0@DEN-MEXMS-001.corp.ebay.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> <8D7D477E-9A5C-43D0-A3E0-5F9A8C446A9A@checkpoint.com> In-Reply-To: <8D7D477E-9A5C-43D0-A3E0-5F9A8C446A9A@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: Q4yixP0hk9Rfh/JuMLsd0Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 17:49:01 -0000 > -----Original Message----- > From: Yoav Nir [mailto:ynir@checkpoint.com] >=20 > I have just tested this with Firefox 4 (beta 8 - yesterday's nightly buil= d) and > with Chrome (7.0.517.44 if that matters). I used a website where the > certificate has several problems: the CA is untrusted, and the CN does no= t > match the domain name. Clearly a cause for red screen / "I understand the > risks" message. >=20 > With Chrome, I got the red screen on the first connect, and also on the > second connect. But STS worked. I typed "http://" and got "https://" inst= ead. >=20 > With Firefox, I got the "I Understand the Risks" page both the first and > second time, and again STS worked. One area of confusion in the spec/implementations is what is means for a ce= rtificate to be "trusted" by the browser. We didn't deal explicitly with w= hat the browser should do when a user has previously clicked through a cert= ificate warning, and generated a permanent exception in the browser. Is th= at certificate now fully trusted, or not? We didn't get into that very muc= h in the spec, as this isn't a spec about how to validate certificates, it = only deals with what the browser should do in case the browser has already = decided to generate a certificate warning. > So the truth is that both Firefox and Chrome do what IMO is the right thi= ng, > and ignore point #9. There are considerable discussion yesterday about the right behavior, and w= hether this spec should specify browser behavior. One of the problems we'v= e discovered in looking at a bunch of existing specs, proposed ideas, etc. = is that in general most of the specifications are fairly silent on proper u= ser-agent behavior, and as Paul pointed out the IETF hasn't traditionally f= elt that putting those rules into these specs is a good idea. I understand that has been the history, and in our defense, there is a lot = of divergence of security behavior in these areas, no consistent set of app= ropriate practices, and we punt those decisions to private coalitions of th= e browser makers, CAs, etc. such as the CA Browser Forum. I'd much rather= have at least some of these discussions in this forum or at the W3C than i= n a private "standards" body, as I think we benefit from having more eyes o= n these specific problems. If these specific user-agent treatments don't belong here, but we would lik= e them to be standardized across user-agents, and the user-agent developers= are willing to cooperate (so far they have been pretty willing) then I'd l= ike to have a spec to point them to, rather than having to have those discu= ssions entirely in private. I'm open to community suggestions on how to a= chieve that, but simply saying that user-agent behavior doesn't belong here= isn't really a workable solution without a proposal of where they do belon= g. - Andy From ietf@adambarth.com Tue Nov 23 11:35:28 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D8B28C140 for ; Tue, 23 Nov 2010 11:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.82 X-Spam-Level: X-Spam-Status: No, score=-5.82 tagged_above=-999 required=5 tests=[AWL=-3.843, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJBZZY43jvVb for ; Tue, 23 Nov 2010 11:35:27 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 1E18428C146 for ; Tue, 23 Nov 2010 11:35:26 -0800 (PST) Received: by fxm9 with SMTP id 9so243010fxm.31 for ; Tue, 23 Nov 2010 11:36:24 -0800 (PST) Received: by 10.223.123.142 with SMTP id p14mr4823629far.122.1290540984674; Tue, 23 Nov 2010 11:36:24 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by mx.google.com with ESMTPS id k21sm1940315faa.1.2010.11.23.11.36.23 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Nov 2010 11:36:24 -0800 (PST) Received: by pvc21 with SMTP id 21so2509950pvc.31 for ; Tue, 23 Nov 2010 11:36:19 -0800 (PST) Received: by 10.231.167.146 with SMTP id q18mr8606182iby.163.1290540979139; Tue, 23 Nov 2010 11:36:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.8.145 with HTTP; Tue, 23 Nov 2010 11:35:48 -0800 (PST) In-Reply-To: <4CEBF3FB.6070009@extendedsubset.com> References: <4CE8BC5C.7080404@mozilla.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842EC9@DEN-MEXMS-001.corp.ebay.com> <4CEB57B8.8020901@extendedsubset.com> <4CEB6BCA.5000509@extendedsubset.com> <4CEBF3FB.6070009@extendedsubset.com> From: Adam Barth Date: Tue, 23 Nov 2010 11:35:48 -0800 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Cc: "websec@ietf.org" Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 19:35:28 -0000 On Tue, Nov 23, 2010 at 9:03 AM, Marsh Ray wrote: > So what's the reasoning behind forbidding https://twitter.com:80/ ? (other > than not wanting img src links to be able to send line noise to HTTP > servers). Actually, that probably works if you use that URL explicitly. I was focused on how the URL re-writing works. The reason we re-write http://example.com to https://example.com (notice the port switch from 80 to 443) is because that's the behavior most folks want in the common case. Adam From ietf@adambarth.com Tue Nov 23 11:38:30 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB8628C0E8 for ; Tue, 23 Nov 2010 11:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.767 X-Spam-Level: X-Spam-Status: No, score=-3.767 tagged_above=-999 required=5 tests=[AWL=-1.790, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9683FBKFH3u for ; Tue, 23 Nov 2010 11:38:30 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BCA583A6986 for ; Tue, 23 Nov 2010 11:38:29 -0800 (PST) Received: by fxm9 with SMTP id 9so245735fxm.31 for ; Tue, 23 Nov 2010 11:39:27 -0800 (PST) Received: by 10.223.126.68 with SMTP id b4mr7198560fas.55.1290541165230; Tue, 23 Nov 2010 11:39:25 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id e6sm1938675fav.8.2010.11.23.11.39.22 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Nov 2010 11:39:22 -0800 (PST) Received: by iwn40 with SMTP id 40so10341729iwn.31 for ; Tue, 23 Nov 2010 11:39:21 -0800 (PST) Received: by 10.231.12.11 with SMTP id v11mr8602142ibv.13.1290541161392; Tue, 23 Nov 2010 11:39:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.8.145 with HTTP; Tue, 23 Nov 2010 11:38:51 -0800 (PST) In-Reply-To: <8D7D477E-9A5C-43D0-A3E0-5F9A8C446A9A@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> <8D7D477E-9A5C-43D0-A3E0-5F9A8C446A9A@checkpoint.com> From: Adam Barth Date: Tue, 23 Nov 2010 11:38:51 -0800 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 19:38:30 -0000 On Tue, Nov 23, 2010 at 1:21 AM, Yoav Nir wrote: > On Nov 23, 2010, at 8:06 AM, Adam Barth wrote: >>> Sure, I can have a configuration flag for whether or not we should have= the header, but administrators tend to configure those wrong just as much = as users tend to click through dangerous screens. >> >> I don't think user agents should offer such a configuration flag. > > Not for the UA. For the portal product. > >>> What do the current implementations (Chrome, Firefox) do? >> >> They do what the spec says. =A0TLS errors on HSTS hosts are treated as >> fatal errors, much like the host's DNS name not resolving. =A0There is >> no recourse except to reload the page. > > I have just tested this with Firefox 4 (beta 8 - yesterday's nightly buil= d) and with Chrome (7.0.517.44 if that matters). I used a website where the= certificate has several problems: the CA is untrusted, and the CN does not= match the domain name. Clearly a cause for red screen / "I understand the = risks" message. > > With Chrome, I got the red screen on the first connect, and also on the s= econd connect. But STS worked. I typed "http://" and got "https://" instead= . > > With Firefox, I got the "I Understand the Risks" page both the first and = second time, and again STS worked. > > So the truth is that both Firefox and Chrome do what IMO is the right thi= ng, and ignore point #9. I suspect there's something fishy about your experimental setup. That's not the intended behavior for either browser. Adam From ynir@checkpoint.com Tue Nov 23 11:47:04 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBC0428C17D for ; Tue, 23 Nov 2010 11:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.376 X-Spam-Level: X-Spam-Status: No, score=-8.376 tagged_above=-999 required=5 tests=[AWL=2.223, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+yGpdYh6dm1 for ; Tue, 23 Nov 2010 11:47:04 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id C23013A6986 for ; Tue, 23 Nov 2010 11:47:03 -0800 (PST) X-CheckPoint: {4CEC170C-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oANJlwXO021725; Tue, 23 Nov 2010 21:47:59 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 23 Nov 2010 21:47:58 +0200 From: Yoav Nir To: "Steingruebl, Andy" Date: Tue, 23 Nov 2010 21:47:56 +0200 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuLR1Pl0lr9kwqASy+3+d/G1AijvA== Message-ID: <7F0C6F4B-56C3-464F-879E-CBBB779EAD97@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> <8D7D477E-9A5C-43D0-A3E0-5F9A8C446A9A@checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB188436D0@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB188436D0@DEN-MEXMS-001.corp.ebay.com> 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 Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 19:47:05 -0000 On Nov 23, 2010, at 7:49 PM, Steingruebl, Andy wrote: >> -----Original Message----- >> From: Yoav Nir [mailto:ynir@checkpoint.com] >>=20 >> I have just tested this with Firefox 4 (beta 8 - yesterday's nightly bui= ld) and >> with Chrome (7.0.517.44 if that matters). I used a website where the >> certificate has several problems: the CA is untrusted, and the CN does n= ot >> match the domain name. Clearly a cause for red screen / "I understand th= e >> risks" message. >>=20 >> With Chrome, I got the red screen on the first connect, and also on the >> second connect. But STS worked. I typed "http://" and got "https://" ins= tead. >>=20 >> With Firefox, I got the "I Understand the Risks" page both the first and >> second time, and again STS worked. >=20 > One area of confusion in the spec/implementations is what is means for a = certificate to be "trusted" by the browser. We didn't deal explicitly with= what the browser should do when a user has previously clicked through a ce= rtificate warning, and generated a permanent exception in the browser. Is = that certificate now fully trusted, or not? We didn't get into that very m= uch in the spec, as this isn't a spec about how to validate certificates, i= t only deals with what the browser should do in case the browser has alread= y decided to generate a certificate warning. I thought about that, so I was careful not to store a permanent exception i= n Firefox, and restarted it between connects. That's why I got the "I Under= stand the Risks" page again.= From ietf@adambarth.com Tue Nov 23 13:18:28 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5646128C153 for ; Tue, 23 Nov 2010 13:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.733 X-Spam-Level: X-Spam-Status: No, score=-3.733 tagged_above=-999 required=5 tests=[AWL=-1.756, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPF7nb5sdbWg for ; Tue, 23 Nov 2010 13:18:27 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 51EDA3A69A0 for ; Tue, 23 Nov 2010 13:18:27 -0800 (PST) Received: by fxm9 with SMTP id 9so338341fxm.31 for ; Tue, 23 Nov 2010 13:19:25 -0800 (PST) Received: by 10.223.54.132 with SMTP id q4mr1851726fag.117.1290547164831; Tue, 23 Nov 2010 13:19:24 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id r24sm1981393fax.3.2010.11.23.13.19.23 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Nov 2010 13:19:24 -0800 (PST) Received: by pzk12 with SMTP id 12so145310pzk.31 for ; Tue, 23 Nov 2010 13:19:22 -0800 (PST) Received: by 10.231.16.131 with SMTP id o3mr8844219iba.38.1290547161779; Tue, 23 Nov 2010 13:19:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.8.145 with HTTP; Tue, 23 Nov 2010 13:18:51 -0800 (PST) In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com> <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> <8D7D477E-9A5C-43D0-A3E0-5F9A8C446A9A@checkpoint.com> From: Adam Barth Date: Tue, 23 Nov 2010 13:18:51 -0800 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 21:18:28 -0000 On Tue, Nov 23, 2010 at 11:38 AM, Adam Barth wrote: > On Tue, Nov 23, 2010 at 1:21 AM, Yoav Nir wrote: >> On Nov 23, 2010, at 8:06 AM, Adam Barth wrote: >>>> Sure, I can have a configuration flag for whether or not we should hav= e the header, but administrators tend to configure those wrong just as much= as users tend to click through dangerous screens. >>> >>> I don't think user agents should offer such a configuration flag. >> >> Not for the UA. For the portal product. >> >>>> What do the current implementations (Chrome, Firefox) do? >>> >>> They do what the spec says. =A0TLS errors on HSTS hosts are treated as >>> fatal errors, much like the host's DNS name not resolving. =A0There is >>> no recourse except to reload the page. >> >> I have just tested this with Firefox 4 (beta 8 - yesterday's nightly bui= ld) and with Chrome (7.0.517.44 if that matters). I used a website where th= e certificate has several problems: the CA is untrusted, and the CN does no= t match the domain name. Clearly a cause for red screen / "I understand the= risks" message. >> >> With Chrome, I got the red screen on the first connect, and also on the = second connect. But STS worked. I typed "http://" and got "https://" instea= d. >> >> With Firefox, I got the "I Understand the Risks" page both the first and= second time, and again STS worked. >> >> So the truth is that both Firefox and Chrome do what IMO is the right th= ing, and ignore point #9. > > I suspect there's something fishy about your experimental setup. > That's not the intended behavior for either browser. I suspect the issue with your experiment is that we don't accept Strict-Transport-Security headers over "broken" TLS connections. This help prevent web sites from shooting themselves in the foot when they think their certificate is valid even though it isn't. To test this properly, you need to simulate a real attack scenario. First, receive the HSTS directive over a TLS connection with a valid certificate and then play man-in-the-middle and substitute the attacker's certificate. Adam From Jeff.Hodges@KingsMountain.com Tue Nov 23 15:57:38 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5FA3A69DB for ; Tue, 23 Nov 2010 15:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.776 X-Spam-Level: X-Spam-Status: No, score=-100.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBD-IPzd2YNo for ; Tue, 23 Nov 2010 15:57:37 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 516BD3A6987 for ; Tue, 23 Nov 2010 15:57:37 -0800 (PST) Received: (qmail 27517 invoked by uid 0); 23 Nov 2010 23:58:35 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 23 Nov 2010 23:58:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=TtggiXLkDDyUxEh9yLb8GqbcmyyqbYjIb7TkNNQuvN/KpfNcMGY+SGV3ehhvvxArK1cRtGh5onQEzp+sdFm5uIIu/liG/+781ORtCQ9x1JVC918DJ7mR6tPDIr1sUbll; Received: from [207.190.0.11] (helo=[10.98.17.12]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PL2kt-00058x-0H for websec@ietf.org; Tue, 23 Nov 2010 16:58:35 -0700 Message-ID: <4CEC552B.7030009@KingsMountain.com> Date: Tue, 23 Nov 2010 15:58:35 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 207.190.0.11 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] Testing HSTS browser impls (was: Some questions about HSTS) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 23:57:38 -0000 [ am out of the office this week. ] Adam noted: > > I suspect the issue with your experiment is that we don't accept > Strict-Transport-Security headers over "broken" TLS connections. This > help prevent web sites from shooting themselves in the foot when they > think their certificate is valid even though it isn't. yep. > To test this > properly, you need to simulate a real attack scenario. First, receive > the HSTS directive over a TLS connection with a valid certificate and > then play man-in-the-middle and substitute the attacker's certificate. Another approach is to use the "STS UI" Firefox add-on by Sid Stamm and add your test host before performing the experiment. I'm not aware of a similar extension (or other configuration thingee) for Chrome -- tho it does sport a HSTS Pre-loaded list . =JeffH From Jeff.Hodges@KingsMountain.com Tue Nov 23 16:17:45 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E4C3A69DE for ; Tue, 23 Nov 2010 16:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.776 X-Spam-Level: X-Spam-Status: No, score=-100.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaBTN-HN8KWG for ; Tue, 23 Nov 2010 16:17:44 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 666833A69DD for ; Tue, 23 Nov 2010 16:17:44 -0800 (PST) Received: (qmail 469 invoked by uid 0); 24 Nov 2010 00:18:43 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 24 Nov 2010 00:18:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=zknCZLwKmiz6B9RkximuKM7sYxxUZUsNSViA/if6IQCgHFuyYUB38CLuN4NdTIgyeV5ow0uyGm24nWneRSOpFj/R7VDaiPiZp4ka81hAZWNx8e6PA94LM2bjgBDRSEI1; Received: from [207.190.0.11] (helo=[10.98.17.12]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PL34M-00005z-DV for websec@ietf.org; Tue, 23 Nov 2010 17:18:42 -0700 Message-ID: <4CEC59E4.4060302@KingsMountain.com> Date: Tue, 23 Nov 2010 16:18:44 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 207.190.0.11 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] HSTS -- what about ports? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 00:17:45 -0000 dveditz offered.. > > The HSTS spec needs to be more clear about how to handle multiple > servers running on different ports on the same host. I think, by > referring to host name matching only, that the intent of the spec is > that a server running on any port can set HSTS behavior for every > other port on that host. If this is correct it might be clearer to > rename "HSTS Server" to "HSTS Host" and to somewhere in the spec > mention explicitly that the port is ignored when matching host names. good feedback, thanks. will address in next rev. =JeffH From Jeff.Hodges@KingsMountain.com Tue Nov 23 16:41:06 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E503A6927 for ; Tue, 23 Nov 2010 16:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.52 X-Spam-Level: X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcOV3yRlgnBz for ; Tue, 23 Nov 2010 16:41:05 -0800 (PST) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 263083A69E4 for ; Tue, 23 Nov 2010 16:41:05 -0800 (PST) Received: (qmail 12165 invoked by uid 0); 24 Nov 2010 00:42:03 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 24 Nov 2010 00:42:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Y+jlFpj3sSoYZKljJk1BB897h/S5V3NpukDPkknypDxM2ID26ZNzX/hh8Gjw+BpfhaVOuIFQxaW/0GE6I7DAgLrlkR7PtZzRI39RjCxYUhSZWxvdoNRHhhJLEVUPuNED; Received: from [207.190.0.11] (helo=[10.98.17.12]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PL3Qx-0005nx-0k for websec@ietf.org; Tue, 23 Nov 2010 17:42:03 -0700 Message-ID: <4CEC5F5B.8050307@KingsMountain.com> Date: Tue, 23 Nov 2010 16:42:03 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 207.190.0.11 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] failing insecure connections and user recourse (was: Some questions about HSTS) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 00:41:06 -0000 [ I'm outta the office this week; expect longer than usual delays ] Yoav Nir noted.. > > In sections 2.4.1.1, point #9 says: 9. UAs need to prevent users from > clicking-through security warnings. Halting connection attempts in the face > of secure transport exceptions is acceptable. > > ... > > Point #9 seems to say contradictory things. On the one hand, it says that > "UAs need to prevent..." and I interpret "need" to mean "MUST", but on the > other hand, halting connections is just "acceptable". So is it MAY or MUST? section 2.4.1.1, comprises core functional requirements for addressing the threats noted in an earlier section of the Overview -- its non-normative expository material. The relevant normative language in the present spec (draft-hodges-strict-transport-sec-02) is.. 7.3. Errors in Secure Transport Establishment When connecting to a Known HSTS Server, the UA MUST terminate the connection with no user recourse if there are any errors (e.g. certificate errors), whether "warning" or "fatal" or any other error level, with the underlying secure transport. Paul Hoffman notes.. > > ...the IETF, generally does not make such decisions for users. We make > protocols and recommendations to developers. The text in this document > should be worded as such. Agreed. I propose moving the "with no user recourse" phrase (no more, no less), in the language quoted above, to section "10. UA Implementation Advice", and appropriately elaborate on it there (and in security considerations). =JeffH From ynir@checkpoint.com Tue Nov 23 23:55:19 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E45A3A6989 for ; Tue, 23 Nov 2010 23:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.535 X-Spam-Level: X-Spam-Status: No, score=-8.535 tagged_above=-999 required=5 tests=[AWL=2.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJNJXS4aFosJ for ; Tue, 23 Nov 2010 23:55:18 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 91EF43A6993 for ; Tue, 23 Nov 2010 23:55:17 -0800 (PST) X-CheckPoint: {4CECC1B4-1-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oAO7uEPO014161; Wed, 24 Nov 2010 09:56:15 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 24 Nov 2010 09:56:14 +0200 From: Yoav Nir To: "'=JeffH'" , IETF WebSec WG Date: Wed, 24 Nov 2010 09:56:14 +0200 Thread-Topic: [websec] Testing HSTS browser impls (was: Some questions about HSTS) Thread-Index: AcuLalqyEFu8jEBQToicPBCO7SJwvwAQiffw Message-ID: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4479@il-ex01.ad.checkpoint.com> References: <4CEC552B.7030009@KingsMountain.com> In-Reply-To: <4CEC552B.7030009@KingsMountain.com> 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 Subject: Re: [websec] Testing HSTS browser impls (was: Some questions about HSTS) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 07:55:19 -0000 Hi Jeff At first I thought that might be the case, but I closed and restarted the b= rowser, and still the browser went directly to port 443. This happened both= in Chrome and in Firefox. Yoav -----Original Message----- From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of= =3DJeffH Sent: 24 November 2010 01:59 To: IETF WebSec WG Subject: Re: [websec] Testing HSTS browser impls (was: Some questions about= HSTS) [ am out of the office this week. ] Adam noted: > > I suspect the issue with your experiment is that we don't accept > Strict-Transport-Security headers over "broken" TLS connections. This > help prevent web sites from shooting themselves in the foot when they > think their certificate is valid even though it isn't. yep. From ietf@adambarth.com Fri Nov 26 23:28:14 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC5A3A6B51 for ; Fri, 26 Nov 2010 23:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-1.649, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTMVTioztx81 for ; Fri, 26 Nov 2010 23:28:13 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 72C7E3A6990 for ; Fri, 26 Nov 2010 23:28:13 -0800 (PST) Received: by yxk30 with SMTP id 30so1398058yxk.31 for ; Fri, 26 Nov 2010 23:29:18 -0800 (PST) Received: by 10.150.53.12 with SMTP id b12mr6598657yba.20.1290842958340; Fri, 26 Nov 2010 23:29:18 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id q8sm3130223ybk.12.2010.11.26.23.29.16 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Nov 2010 23:29:16 -0800 (PST) Received: by iwn40 with SMTP id 40so3417371iwn.31 for ; Fri, 26 Nov 2010 23:29:15 -0800 (PST) Received: by 10.231.169.135 with SMTP id z7mr2591916iby.28.1290842955721; Fri, 26 Nov 2010 23:29:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.12.77 with HTTP; Fri, 26 Nov 2010 23:28:43 -0800 (PST) From: Adam Barth Date: Fri, 26 Nov 2010 23:28:43 -0800 Message-ID: To: websec Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] draft-abarth-origin-09 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 07:28:14 -0000 I've uploaded a new version of draft-abarth-origin: http://www.ietf.org/id/draft-abarth-origin-09.txt Notable changes: 1) The document now includes (a boring) introduction. 2) Numerous editorial improvements. Kind regards, Adam From thassloc@adobe.com Mon Nov 29 15:07:36 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69F6028C10D for ; Mon, 29 Nov 2010 15:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGmbsWfWcQ5d for ; Mon, 29 Nov 2010 15:07:35 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by core3.amsl.com (Postfix) with ESMTP id 3D96A28C102 for ; Mon, 29 Nov 2010 15:07:32 -0800 (PST) Received: from source ([192.150.8.22]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKTPQyelrfX/DKVavbfrmUjkFQQNmC6ngM@postini.com; Mon, 29 Nov 2010 15:08:45 PST Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oATN8eVV026681; Mon, 29 Nov 2010 15:08:40 -0800 (PST) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oATN8bto017971; Mon, 29 Nov 2010 15:08:38 -0800 (PST) Received: from excas02.corp.adobe.com (10.8.188.212) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 29 Nov 2010 15:06:36 -0800 Received: from nambx07.corp.adobe.com ([10.8.189.232]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Mon, 29 Nov 2010 15:06:36 -0800 From: Travis Hassloch To: Marsh Ray , Devdatta Akhawe Date: Mon, 29 Nov 2010 15:06:32 -0800 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuKcLQ0n82PrjTIRoy/mzdBgq3blQFqVuqd Message-ID: In-Reply-To: <4CEAB248.507@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 23:07:36 -0000 On 11/22/10 10:11 AM, "Marsh Ray" wrote: > On 11/22/2010 11:53 AM, Devdatta Akhawe wrote: >>>=20 >>> HSTS should be thought of as a way for a site to communicate its policy= to >>> the user, via the UA: "I (the site) commit to always running an HTTPS >>> service, so you can rewrite http: links and failures on port 443 may >>> indicate an attack." >>>=20 >>> It's not a way for a site to get the UA to force restrictions upon the = user. >>> Trying to enlist the user's software against their intentions is using = the >>> same failed logic behind DRM. >>=20 >> The problem is that the average user has no understanding what the >> certificate means and just says 'please show me the content' (clicks >> yes) >=20 > Yep. It's a problem. Ultimately I don't think there's a technical > solution to it. Actually, I see HSTS as dealing almost entirely with UI-level issues. My programmatic clients don't type URLs into address bars, forget to add https://, click through SSL warnings, etc. What would it gain them? BTW, the talk of web services and bots reminds me of elevator controllers: During one period (1983--84) in the deliberations of ANSI X3J11 (the C standardization committee) this was the canonical example of a really stupid, memory-limited computation environment. "You can't require `printf(3)' to be part of the default runtime library --- what if you're targeting an elevator controller?" Elevator controllers became important rhetorical weapons on both sides of several holy wars. > I don't think there's a huge risk if individual browsers implement > heavy-handed security policy. Users will simply switch to a browser that > lets them do what they want, or maybe they like a strict browser after > all. The market can take care of that. >=20 > The danger is when a documented protocol seems to guarantee something to > work a certain way when in reality it doesn't, or is trivial to bypass. > Mandated UI restrictions will hold up against product designers and > users about as well as software DRM held out against a reverse engineer > with a debugger. >=20 > However, the imaginary restrictions will get documented in books as if > they were fact. (Remember the little Javascript tricks that supposedly > prevented the user from saving images from your site?) Then web > designers and admins end up relying on them as a security property and > hilarity ensues. I recall reading Northcutt's NIDS book a while back, and seeing sections stating that certain packets would never be seen because an RFC said that clients MUST NOT generate them. IMHO, there isn't a single "MUST" in an RFC that's reliable in that sense. If it were impossible to do otherwise, it wouldn't need to be specified in an RFC. Relying upon RFCs to constrain bad actors is akin to saying your bank doesn't need walls since theft is illegal. That all having been said, the baby-duck model (impressioning on a pubkey the first time you see it) causes big problems with active attackers the first time, or when you have to update the cert - those are indistinguishable from a MITM. Knowing that the cert was updated is not enough; you need an out-of-band channel to know that the new cert is the right one. That's what the key indirection in SSL is there for - in that case, you only have to have an out-of-band update when a CA cert's pubkey i= s changed. If you're not worried about Mallory, you don't need HSTS. If you are, you need real key management. IMHO. Thanks! --=20 Travis Hassloch Flash Player Security Engineer From ietf@adambarth.com Mon Nov 29 15:15:16 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E79528C167 for ; Mon, 29 Nov 2010 15:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-2.710, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve8GY1m6zKp0 for ; Mon, 29 Nov 2010 15:15:15 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 3393F28C102 for ; Mon, 29 Nov 2010 15:15:15 -0800 (PST) Received: by qwg5 with SMTP id 5so3916307qwg.31 for ; Mon, 29 Nov 2010 15:16:25 -0800 (PST) Received: by 10.224.176.197 with SMTP id bf5mr5747811qab.248.1291072583386; Mon, 29 Nov 2010 15:16:23 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id l14sm3564089qck.41.2010.11.29.15.16.21 (version=SSLv3 cipher=RC4-MD5); Mon, 29 Nov 2010 15:16:21 -0800 (PST) Received: by iwn40 with SMTP id 40so6564607iwn.31 for ; Mon, 29 Nov 2010 15:16:20 -0800 (PST) Received: by 10.231.37.1 with SMTP id v1mr6282649ibd.103.1291072580627; Mon, 29 Nov 2010 15:16:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.12.77 with HTTP; Mon, 29 Nov 2010 15:15:50 -0800 (PST) In-Reply-To: References: <4CEAB248.507@extendedsubset.com> From: Adam Barth Date: Mon, 29 Nov 2010 15:15:50 -0800 Message-ID: To: Travis Hassloch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 23:15:16 -0000 On Mon, Nov 29, 2010 at 3:06 PM, Travis Hassloch wrote= : > My programmatic clients don't type URLs into address bars, forget to add > https://, click through SSL warnings, etc. =A0What would it gain them? Don't they? What does --no-check-certificate do then? http://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTLS_00= 29-Options.html > That all having been said, the baby-duck model (impressioning on a pubkey > the first time you see it) causes big problems with active attackers the > first time, or when you have to update the cert - those are > indistinguishable from a MITM. =A0Knowing that the cert was updated is no= t > enough; you need an out-of-band channel to know that the new cert is the > right one. =A0That's what the key indirection in SSL is there for - in th= at > case, you only have to have an out-of-band update when a CA cert's pubkey= is > changed. =A0If you're not worried about Mallory, you don't need HSTS. =A0= If you > are, you need real key management. =A0IMHO. Unfortunately, the world isn't quite so black-and-white. As a practical matter, HSTS does improve security against Mallory. For example, now that I've visited PayPal once with this laptop, I'm better off when I check my account balance in a coffee shop. Adam From thassloc@adobe.com Mon Nov 29 16:48:10 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E6628C0E0 for ; Mon, 29 Nov 2010 16:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.372 X-Spam-Level: X-Spam-Status: No, score=-105.372 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNjmcl0MMPOI for ; Mon, 29 Nov 2010 16:48:09 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by core3.amsl.com (Postfix) with ESMTP id E8F3F3A6C52 for ; Mon, 29 Nov 2010 16:48:08 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKTPRKDOgw104v5ee2gdBEAEr+dbRzM6N3@postini.com; Mon, 29 Nov 2010 16:49:19 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oAU0mu3f020973; Mon, 29 Nov 2010 16:48:56 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oAU0nFtm014006; Mon, 29 Nov 2010 16:49:15 -0800 (PST) Received: from nambx07.corp.adobe.com ([10.8.189.232]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Mon, 29 Nov 2010 16:49:15 -0800 From: Travis Hassloch To: Adam Barth Date: Mon, 29 Nov 2010 16:49:13 -0800 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuQG3QwvLgGTGqJRnGKdAZralmrkQADPPuR Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 00:48:10 -0000 On 11/29/10 3:15 PM, "Adam Barth" wrote: > On Mon, Nov 29, 2010 at 3:06 PM, Travis Hassloch wro= te: >> My programmatic clients don't type URLs into address bars, forget to add >> https://, click through SSL warnings, etc. =A0What would it gain them? >=20 > Don't they? What does --no-check-certificate do then? >=20 > http://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTLS_= 0029- > Options.html I meant "what would (HSTS) gain (a properly-designed programmatic client)" The problem HSTS addresses seems to be user interaction and click-through insecurity. I would hope that its proponents are not trying to prevent programmers from shooting themselves in the foot, if they try hard enough t= o do so. That is, as others have pointed out, an impossible task. >> That all having been said, the baby-duck model (impressioning on a pubke= y >> the first time you see it) causes big problems with active attackers the >> first time, or when you have to update the cert - those are >> indistinguishable from a MITM. =A0Knowing that the cert was updated is n= ot >> enough; you need an out-of-band channel to know that the new cert is the >> right one. =A0That's what the key indirection in SSL is there for - in t= hat >> case, you only have to have an out-of-band update when a CA cert's pubke= y is >> changed. =A0If you're not worried about Mallory, you don't need HSTS. = =A0If you >> are, you need real key management. =A0IMHO. >=20 > Unfortunately, the world isn't quite so black-and-white. As a > practical matter, HSTS does improve security against Mallory. For > example, now that I've visited PayPal once with this laptop, I'm > better off when I check my account balance in a coffee shop. I think you misparsed my sentence. I'm saying that if you're worried about Mallory, then self-signed certs aren't really a strong defense. Thanks! --=20 Travis Hassloch Flash Player Security Engineer From ietf@adambarth.com Mon Nov 29 17:07:32 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CEF828C15F for ; Mon, 29 Nov 2010 17:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=-2.629, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUMrD9XiHu5k for ; Mon, 29 Nov 2010 17:07:31 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 00EF328C154 for ; Mon, 29 Nov 2010 17:07:30 -0800 (PST) Received: by qyk34 with SMTP id 34so573616qyk.10 for ; Mon, 29 Nov 2010 17:08:41 -0800 (PST) Received: by 10.224.2.199 with SMTP id 7mr5892105qak.203.1291079321070; Mon, 29 Nov 2010 17:08:41 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id t17sm3628865qcp.26.2010.11.29.17.08.38 (version=SSLv3 cipher=RC4-MD5); Mon, 29 Nov 2010 17:08:40 -0800 (PST) Received: by iwn40 with SMTP id 40so6676079iwn.31 for ; Mon, 29 Nov 2010 17:08:37 -0800 (PST) Received: by 10.231.160.78 with SMTP id m14mr6404266ibx.128.1291079317658; Mon, 29 Nov 2010 17:08:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.12.77 with HTTP; Mon, 29 Nov 2010 17:08:07 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Mon, 29 Nov 2010 17:08:07 -0800 Message-ID: To: Travis Hassloch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 01:07:32 -0000 On Mon, Nov 29, 2010 at 4:49 PM, Travis Hassloch wrote= : > On 11/29/10 3:15 PM, "Adam Barth" wrote: >> On Mon, Nov 29, 2010 at 3:06 PM, Travis Hassloch wr= ote: >>> My programmatic clients don't type URLs into address bars, forget to ad= d >>> https://, click through SSL warnings, etc. =A0What would it gain them? >> >> Don't they? =A0What does --no-check-certificate do then? >> >> http://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTLS= _0029- >> Options.html > > I meant "what would (HSTS) gain (a properly-designed programmatic client)= " Are you saying that wget isn't properly designed? I'm not sure I follow your point. > The problem HSTS addresses seems to be user interaction and click-through > insecurity. =A0I would hope that its proponents are not trying to prevent > programmers from shooting themselves in the foot, if they try hard enough= to > do so. =A0That is, as others have pointed out, an impossible task. I'm not sure there is a clear distinction between users and programmers. I write code, but I also use software. When passing --no-check-certificate to wget, am I a user or a programmer? Adam From thassloc@adobe.com Mon Nov 29 17:34:44 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BEE93A6C53 for ; Mon, 29 Nov 2010 17:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.144 X-Spam-Level: X-Spam-Status: No, score=-104.144 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fHKsU9IEJk5 for ; Mon, 29 Nov 2010 17:34:40 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by core3.amsl.com (Postfix) with ESMTP id D61E33A6C58 for ; Mon, 29 Nov 2010 17:34:34 -0800 (PST) Received: from source ([192.150.8.22]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKTPRU8Atg0SLv8Pt8mETG7ddoQYqFOGzF@postini.com; Mon, 29 Nov 2010 17:35:47 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oAU1ZhVV007997; Mon, 29 Nov 2010 17:35:43 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id oAU1ZeWj001735; Mon, 29 Nov 2010 17:35:40 -0800 (PST) Received: from excas03.corp.adobe.com (10.8.189.123) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 29 Nov 2010 17:35:39 -0800 Received: from nambx07.corp.adobe.com ([10.8.189.232]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Mon, 29 Nov 2010 17:35:39 -0800 From: Travis Hassloch To: Adam Barth Date: Mon, 29 Nov 2010 17:35:29 -0800 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuQLuSuaSG4P1WSTi2Bf/n2tQEPEw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 01:34:45 -0000 I'm pointing out that hsts does not seem to offer much to userless =20 agents. It helps to remember that Paypal eats fraud losses, unlike many other =20 use cases where the user is protecting (or not) his own interests. =20 Ross Anderson makes some arguments that this is a good thing, but it =20 may seem big-brotheresque sometimes when they try to protect the =20 session from the user themselves. Sent from my iPhone On Nov 29, 2010, at 5:08 PM, "Adam Barth" wrote: > On Mon, Nov 29, 2010 at 4:49 PM, Travis Hassloch =20 > wrote: >> On 11/29/10 3:15 PM, "Adam Barth" wrote: >>> On Mon, Nov 29, 2010 at 3:06 PM, Travis Hassloch =20 >>> wrote: >>>> My programmatic clients don't type URLs into address bars, forget =20 >>>> to add >>>> https://, click through SSL warnings, etc. What would it gain =20 >>>> them? >>> >>> Don't they? What does --no-check-certificate do then? >>> >>> http://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTL= S_0029- >>> Options.html >> >> I meant "what would (HSTS) gain (a properly-designed programmatic =20 >> client)" > > Are you saying that wget isn't properly designed? I'm not sure I > follow your point. > >> The problem HSTS addresses seems to be user interaction and click-=20 >> through >> insecurity. I would hope that its proponents are not trying to =20 >> prevent >> programmers from shooting themselves in the foot, if they try hard =20 >> enough to >> do so. That is, as others have pointed out, an impossible task. > > I'm not sure there is a clear distinction between users and > programmers. I write code, but I also use software. When passing > --no-check-certificate to wget, am I a user or a programmer? > > Adam From marsh@extendedsubset.com Mon Nov 29 18:24:29 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC29528C111 for ; Mon, 29 Nov 2010 18:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrKkvI7GigWC for ; Mon, 29 Nov 2010 18:24:27 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A77473A6C53 for ; Mon, 29 Nov 2010 18:24:27 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PNFuS-000CMK-Q0; Tue, 30 Nov 2010 02:25:36 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id BCA766018; Tue, 30 Nov 2010 02:25:34 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18fHwprb4+91QSqQD3JfvLp3g1T7hM0Mzg= Message-ID: <4CF4609E.6090201@extendedsubset.com> Date: Mon, 29 Nov 2010 20:25:34 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Adam Barth References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 02:24:29 -0000 On 11/29/2010 07:08 PM, Adam Barth wrote: > > I'm not sure there is a clear distinction between users and > programmers. I write code, but I also use software. When passing > --no-check-certificate to wget, am I a user or a programmer? You are intentionally being difficult and choosing the most ambiguous example rather than one representative of the false dichotomy presumed in the earlier discussion! I.e., you're being a programmer. Wget is a user agent, since a user can invoke it from the command line. It's also used in shell scripts, so it's like an https client library too. I think the point is that some apps which act as https clients are written by programmers and deployed by admins. These apps are not user agents in the conventional sense, they are more generally client applications which happen to be using https as a transport protocol. If they were correctly coded, they can be presumed to not bypass certificate warnings of their own initiative. Hopefully, the programmer and the admin can be relied upon in the security model in a way that the general user, as we have learned, can not. This class of applications often has different characteristics than the classic user agent in its usage of https. There is great diversity within the set of non-UA https clients as well. What can we say about how they might interact with the changes proposed for HSTS? - Marsh From dev.akhawe@gmail.com Mon Nov 29 18:31:25 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9102C3A6C53 for ; Mon, 29 Nov 2010 18:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-Tvk5Bze1nX for ; Mon, 29 Nov 2010 18:31:24 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E899828C111 for ; Mon, 29 Nov 2010 18:31:23 -0800 (PST) Received: by wwa36 with SMTP id 36so5382950wwa.13 for ; Mon, 29 Nov 2010 18:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=xnxeFVbDuk54GKdNt6txljU45TlstbsDj1CIlUVkorE=; b=LfTc8TekMUDpnvwcQlQeZOol/AnYkgxYit0QecZ6P5inn1fmO0NefZD73rKJlbufWc DELP2n8GcKFNhQ+rBkp4mkuHgXkl4bFbayUSgjXPfkRnajQu093t6Y84V+hX/ptUisRe XIsuBm5rHUCXSOHUutk/RYozwuvOGkwwtzASY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Wmg7aNoD+Ruyht7L+St5qlO3gWU2BZ4Lsk51K7tz4nN7H5Zkdiyv91rzqI5sThUseg i6198HIYzBux5ZOcjSrJ78c+RqdQR1MCfrWMf6cdajxDgFxC7+06DglmG1YhYCozfKbd NHIT0AXl7iQp2XjwEjExvyxFBMvuUvbebA3eo= Received: by 10.227.137.138 with SMTP id w10mr6939279wbt.19.1291084353788; Mon, 29 Nov 2010 18:32:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.86.11 with HTTP; Mon, 29 Nov 2010 18:32:13 -0800 (PST) In-Reply-To: <4CF4609E.6090201@extendedsubset.com> References: <4CF4609E.6090201@extendedsubset.com> From: Devdatta Akhawe Date: Mon, 29 Nov 2010 18:32:13 -0800 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 02:31:25 -0000 > to be using https as a transport protocol. If they were correctly coded, > they can be presumed to not bypass certificate warnings of their own > initiative. Hopefully, the programmer and the admin can be relied upon in > the security model in a way that the general user, as we have learned, can > not. I have been thinking of this while reading this discussion - and the way I have been phrasing it in my mind is - when does the decision to over-ride the ceritificate warning take place? In the case of the browsers, it takes place when the user is trying to get things done - at which point he will probably just click on 'go away' (this is one of the reasons, in addition to being conditioned to do this). This is the behavior that HSTS is trying to protect against. I think for User Agents for which you have to make the choice to ignore certificate warnings at compile time or in the config file etc, HSTS should not apply. In a way, this also works for a 'ignore HSTS' setting in about:config for Firefox. I am not sure if this makes sense to anyone else. cheers devdatta > > This class of applications often has different characteristics than the > classic user agent in its usage of https. There is great diversity within > the set of non-UA https clients as well. What can we say about how they > might interact with the changes proposed for HSTS? > > - Marsh > From marsh@extendedsubset.com Mon Nov 29 20:12:30 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A93628C125 for ; Mon, 29 Nov 2010 20:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuCpAmbKvhPz for ; Mon, 29 Nov 2010 20:12:29 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 741CA28C110 for ; Mon, 29 Nov 2010 20:12:29 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PNHb0-000GRf-NX; Tue, 30 Nov 2010 04:13:38 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 964136018; Tue, 30 Nov 2010 04:13:36 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+jVekTzHzA2mgmBvTlrKaC6mNNBzoafnc= Message-ID: <4CF479F0.5070505@extendedsubset.com> Date: Mon, 29 Nov 2010 22:13:36 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Devdatta Akhawe References: <4CF4609E.6090201@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 04:12:30 -0000 On 11/29/2010 08:32 PM, Devdatta Akhawe wrote: > > I have been thinking of this while reading this discussion - and the > way I have been phrasing it in my mind is - > when does the decision to over-ride the ceritificate warning take place? > > In the case of the browsers, it takes place when the user is trying to > get things done - at which point he will probably just > click on 'go away' (this is one of the reasons, in addition to being > conditioned to do this). This is the behavior that HSTS is trying to > protect against. > > I think for User Agents for which you have to make the choice to > ignore certificate warnings at compile time or in the config file etc, > HSTS should not apply. In a way, this also works for a 'ignore HSTS' > setting in about:config for Firefox. > > I am not sure if this makes sense to anyone else. Yes, I think you've got it. A configuration choice ("accept this certificate for this site") that's clearly allowed by the security model paradoxically becomes an insecure thing to allow at the moment the user encounters the need to do it! It's a user interaction designer's nightmare scenario really. Consider the following scene playing out in office buildings worldwide: "Hi! I'm your software and I have good news and bad news for you." "The bad news: There's a problem. That thing you asked me to do, I just can't do it. "But good news! I can fix that easily for you. But... "Bad news! I won't fix it for you. I was told not to by my programmers. They said for me to tell you that this was for your own good. 'It wouldn't be secure' they said. For me to conveniently fix your problem right now would simply be an invitation for 'a man in the middle attack'. "Look outside. Do you see a white van with ladders on it? A guy with a reel-to-reel tape recorder dressed as a telephone repairman? No? Well, remain vigilant. They could show up at any time. "Too bad. You know, if you had just asked me to install that certificate at any time _before_ you tried to pull up that web page, then that would have been secure and I would have certainly allowed it. "At this point though, the only secure way you can access that site is for you to somehow go back in time and make it so that you'd never tried to open that web page in the first place. "But you just had to click on that link, didn't you? Really it's the site admin's fault. Blame him, not me. "Hey! What are you-- [Cut to shot of computer flying out of 10th floor office window] - Marsh From ietf@adambarth.com Mon Nov 29 20:33:48 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C10C28C16F for ; Mon, 29 Nov 2010 20:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.039 X-Spam-Level: X-Spam-Status: No, score=-4.039 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDcQfmLSstPJ for ; Mon, 29 Nov 2010 20:33:43 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 9FB3328C110 for ; Mon, 29 Nov 2010 20:33:43 -0800 (PST) Received: by yxk8 with SMTP id 8so256610yxk.31 for ; Mon, 29 Nov 2010 20:34:54 -0800 (PST) Received: by 10.90.92.13 with SMTP id p13mr9304704agb.154.1291091694189; Mon, 29 Nov 2010 20:34:54 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id t1sm5618416ano.23.2010.11.29.20.34.52 (version=SSLv3 cipher=RC4-MD5); Mon, 29 Nov 2010 20:34:53 -0800 (PST) Received: by iwn40 with SMTP id 40so6873580iwn.31 for ; Mon, 29 Nov 2010 20:34:51 -0800 (PST) Received: by 10.231.37.1 with SMTP id v1mr6628757ibd.103.1291091691788; Mon, 29 Nov 2010 20:34:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.12.77 with HTTP; Mon, 29 Nov 2010 20:34:21 -0800 (PST) In-Reply-To: <4CF479F0.5070505@extendedsubset.com> References: <4CF4609E.6090201@extendedsubset.com> <4CF479F0.5070505@extendedsubset.com> From: Adam Barth Date: Mon, 29 Nov 2010 20:34:21 -0800 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 04:33:49 -0000 On Mon, Nov 29, 2010 at 8:13 PM, Marsh Ray wrote= : > On 11/29/2010 08:32 PM, Devdatta Akhawe wrote: >> >> I have been thinking of this while reading this discussion - and the >> way I have been phrasing it in my mind is - >> when does the decision to over-ride the ceritificate warning take place? >> >> In the case of the browsers, it takes place when the user is trying to >> get things done - at which point he will probably just >> click on 'go away' (this is one of the reasons, in addition to being >> conditioned to do this). This is the behavior that HSTS is trying to >> protect against. >> >> I think for User Agents for which you have to make the choice to >> ignore certificate warnings at compile time or in the config file etc, >> HSTS should not apply. In a way, this also works for a 'ignore HSTS' >> setting in about:config for Firefox. >> >> I am not sure if this makes sense to anyone else. > > Yes, I think you've got it. > > A configuration choice ("accept this certificate for this site") that's > clearly allowed by the security model paradoxically becomes an insecure > thing to allow at the moment the user encounters the need to do it! > > It's a user interaction designer's nightmare scenario really. > > Consider the following scene playing out in office buildings worldwide: > > "Hi! I'm your software and I have good news and bad news for you." > > "The bad news: There's a problem. That thing you asked me to do, I just > can't do it. > > "But good news! I can fix that easily for you. But... > > "Bad news! I won't fix it for you. I was told not to by my programmers. T= hey > said for me to tell you that this was for your own good. 'It wouldn't be > secure' they said. For me to conveniently fix your problem right now woul= d > simply be an invitation for 'a man in the middle attack'. > > "Look outside. Do you see a white van with ladders on it? A guy with a > reel-to-reel tape recorder dressed as a telephone repairman? No? =A0Well, > remain vigilant. They could show up at any time. > > "Too bad. You know, if you had just asked me to install that certificate = at > any time _before_ you tried to pull up that web page, then that would hav= e > been secure and I would have certainly allowed it. > > "At this point though, the only secure way you can access that site is fo= r > you to somehow go back in time and make it so that you'd never tried to o= pen > that web page in the first place. > > "But you just had to click on that link, didn't you? Really it's the site > admin's fault. Blame him, not me. > > "Hey! What are you-- > > [Cut to shot of computer flying out of 10th floor office window] In reality, these errors are extremely rare, several orders of magnitude less common than the certificate errors we encounter today because we require the user agent to receive the HSTS instruction over a connection with a valid certificate first. Instead of using the UI you suppose above, we just show the same sort of UI we normally show when we have a fatal network error, for example when the server refuses the TCP connection. Adam From asteingruebl@paypal-inc.com Tue Nov 30 07:59:37 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7376728C0DD for ; Tue, 30 Nov 2010 07:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.717 X-Spam-Level: X-Spam-Status: No, score=-6.717 tagged_above=-999 required=5 tests=[AWL=2.400, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwdkXSoWoxsZ for ; Tue, 30 Nov 2010 07:59:36 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id 5D5AE3A6C82 for ; Tue, 30 Nov 2010 07:59:36 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=WWxZF1+Y3J424RgwmTBAXuMSg4MyWBqebB3HpbjG+m2lt+AI9flYYoE3 DGEn8++5spsDaRNOjNezoiESYfqynjfVKvAIdjgT8Gxi1KGwHOHiJZIgA AfTF4PdI0dYwsBQ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1291132849; x=1322668849; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Devdatta=20Akhawe=20, =20Marsh=20Ray=0D=0A=09|CC:=20" websec@ietf.org"=20|Date:=20Tue,=2030=20 Nov=202010=2008:58:57=20-0700|Subject:=20RE:=20[websec] =20Some=20questions=20about=20HSTS|Message-ID:=20<5EE049B A3C6538409BBE6F1760F328ABEB189088D2@DEN-MEXMS-001.corp.eb ay.com>|References:=20=0D=0A=09=0D=0A=09=0D=0A=09<4CF4609E.6090201@e xtendedsubset.com>=0D=0A=20|In-Reply-To:=20 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=OWl93PqR3XjrKZDT0K5plKSDX+7OCGqmU/J4baaTn7Y=; b=crWYSRprODshFvaM2VBfNSIWT8PX3nXAb5XOlF32PrLGQhDw4yLnydPM 6BeCGspuu9xNTncgDDhqzKGnWFrH8o7hV6wjH0yz3H2u+HFTbwVtqr7vi 3sOYf+SmOhCcXZV; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.59,280,1288594800"; d="scan'208";a="298427" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 30 Nov 2010 08:00:47 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Tue, 30 Nov 2010 08:59:55 -0700 From: "Steingruebl, Andy" To: Devdatta Akhawe , Marsh Ray Date: Tue, 30 Nov 2010 08:58:57 -0700 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuQNuFc0F/naY6YQs+v4p4+xILLnwAcETHg Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB189088D2@DEN-MEXMS-001.corp.ebay.com> References: <4CF4609E.6090201@extendedsubset.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: +bjTRFUTtIsKjYptymd0Tg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 15:59:37 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Devdatta Akhawe >=20 > I have been thinking of this while reading this discussion - and the way = I have > been phrasing it in my mind is - when does the decision to over-ride the > ceritificate warning take place? >=20 > In the case of the browsers, it takes place when the user is trying to ge= t > things done - at which point he will probably just click on 'go away' (th= is is one > of the reasons, in addition to being conditioned to do this). This is the > behavior that HSTS is trying to protect against. In the case of programmatic clients, it is much easier to only offer HTTPS = connections in the first place, and not have a listener on port-80. It is = generally only in the web-browser case that a user types in something that = is a hostname, or a word, and expects the browser somehow to do the right t= hing, convert that via DNS suffix appending to a proper hostname, to tack a= protocol/scheme onto it, and then make an HTTP connection. In an HTTP lib= rary case, I think it is much more common to pass a full set of instruction= s to the client library of precisely what to do, and we avoid most of these= problems. - Andy From marsh@extendedsubset.com Tue Nov 30 08:33:09 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884D628C0F9 for ; Tue, 30 Nov 2010 08:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuI8gVhneRhF for ; Tue, 30 Nov 2010 08:33:08 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 1D19E28C0D9 for ; Tue, 30 Nov 2010 08:33:08 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PNT9m-000Ima-FA; Tue, 30 Nov 2010 16:34:18 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D5FA26018; Tue, 30 Nov 2010 16:34:14 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18bWENaauNFR1iBNGLmBryQWWJrNE3P/ZQ= Message-ID: <4CF52786.7060907@extendedsubset.com> Date: Tue, 30 Nov 2010 10:34:14 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Adam Barth References: <4CF4609E.6090201@extendedsubset.com> <4CF479F0.5070505@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 16:33:09 -0000 On 11/29/2010 10:34 PM, Adam Barth wrote: > On Mon, Nov 29, 2010 at 8:13 PM, Marsh Ray wrote: >> >> [Cut to shot of computer flying out of 10th floor office window] > > In reality, these errors are extremely rare, several orders of > magnitude less common than the certificate errors we encounter today > because we require the user agent to receive the HSTS instruction over > a connection with a valid certificate first. Instead of using the UI > you suppose above, To be clear: I wrote that with the the generic problem in mind - it wasn't meant to be specific to HSTS. I was describing how a user might perceive the problem that we might empathize a bit, not trying to accurately depict an actual UI. > we just show the same sort of UI we normally show > when we have a fatal network error, for example when the server > refuses the TCP connection. So here's a scenario you've probably considered, but I'd be interested in how it would work out. I was in a hotel a few weeks back and I plugged into the room ethernet. I opened my web browser to the start page, about:blank. I pulled up a web page by typing "https://....". I think it was probably my bank's site. I get a certificate mismatch error. Of course, I didn't accept the certificate. Figuring what's going on, I try to open http://google.com/ instead. It comes back with a redirect to the hotel's captive portal where I have to enter some registration code or other. So what would have happened if my bank had been using HSTS? Nothing different right? I went to https://my-bank-dot-com directly. What if _also_ google.com had configured HSTS? Wouldn't I have gotten the same cert error there, too? What if all the sites I remember the URLs for had configured HSTS? Would this hotel's network just be broken for me? (Arguably it's broken already.) What if I gave in and accepted the cert error, then this heinous middle box presented the hotel chain's home page under somebody else's domain name, and the hotel admin just read about HSTS and turned it on? What if Telco-del-Qwertystan accidentally routes 20% of all Internet traffic through their McMantec ThoughtPolice(TM) SSL intercepting firewall, which they conveniently equipped with their trusted root CA and this box proxies or constructs responses which turns on HSTS for one year. Maybe this firewall can even do this with plain http requests, too? All by accident, of course. Or maybe somebody at some sub-sub-CA of a commonly trusted root accidentally trips on the way to the secure storage vault and hits the button on their phone that posts the private key to pastebin http://www.google.com/search?q="begin+rsa+private+key"+site%3Apastebin.com and somebody else makes a viral facebook app that has the helpful side effect of turning on HSTS for every non-ssl site anyone visits? Or what if some TLD operator, who is also a trusted CA, decided it would be good for their certificate business if they pre-loaded HSTS on every not-yet-registered domain name via a wildcard DNS result? http://en.wikipedia.org/wiki/Site_Finder Or somebody gets a valid certificate signed for "*\0example.com" and... Currently, https://www.amazon.com/ returns a redirect to the plain http: version. (For the record, I think that's not so great.) What if there's some query string which reflects back in the headers without perfect escaping? What if a disgruntled elf uses this to inject an HSTS header...and replicates it over a popular social networking site? During peak holiday e-shopping?! It seems like before HSTS a CA-gone-bad could compromise https: sites via an active attack, or decrypt captured traffic if DHE were not in use. This capability would hopefully end soon after their tomfoolery was discovered by removing it from the trusted store or revoking it. With HSTS, however, it seems that the potential exists for a long-lasting DoS on sites which serve plain http. - Marsh From asteingruebl@paypal-inc.com Tue Nov 30 09:27:10 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4055028C147 for ; Tue, 30 Nov 2010 09:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.935 X-Spam-Level: X-Spam-Status: No, score=-6.935 tagged_above=-999 required=5 tests=[AWL=2.182, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRXgGr+-ivKF for ; Tue, 30 Nov 2010 09:27:08 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id 90ADA28C13F for ; Tue, 30 Nov 2010 09:27:08 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=bd/jaT5onGL58/CEG98rSQqU2xz6zFw7gDjNwKnkSY1sFjLPm6eoWV9B /NIVVvyxZ0TAFOfffgFkt07Hk2NHqdu7uf5Y6ZyyRZ55WBRbj7IoWoJ64 xDRdReuEPXzhaBz; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1291138101; x=1322674101; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Marsh=20Ray=20,=20A dam=20Barth=20|CC:=20"websec@ietf.org "=20|Date:=20Tue,=2030=20Nov=202010=2010 :28:16=20-0700|Subject:=20RE:=20[websec]=20Some=20questio ns=20about=20HSTS|Message-ID:=20<5EE049BA3C6538409BBE6F17 60F328ABEB18908979@DEN-MEXMS-001.corp.ebay.com> |References:=20=0D=0A=09=0D=0A=09=0D=0A=09<4CF4609E.6090201@extended subset.com>=0D=0A=09=0D=0A=09<4CF479F0.5070505@exten dedsubset.com>=0D=0A=09=0D=0A=20<4CF52786.7060907@ex tendedsubset.com>|In-Reply-To:=20<4CF52786.7060907@extend edsubset.com>|Content-Transfer-Encoding:=20quoted-printab le|MIME-Version:=201.0; bh=acNBl1/V4rmSgWu75TcraoYKLDQbrg8GACNdDH02Cs0=; b=CXD+ixnHiwHNpuGiDrLWh8W+2vh+ADtd0JmJIXhoGkWcHaFPx2gBAiSY qOeUWpu8ehK+3uLQlfDe0CUrnYvzMR0oWGBA6cRbIQJ8T+5VdRfUEBW1/ LmnJGVSlEhtuWAL; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.59,281,1288594800"; d="scan'208";a="300672" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 30 Nov 2010 09:28:19 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Tue, 30 Nov 2010 10:28:18 -0700 From: "Steingruebl, Andy" To: Marsh Ray , Adam Barth Date: Tue, 30 Nov 2010 10:28:16 -0700 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuQrHR8y3wa9vUxQHKuSPTJFzrjqgABpFKQ Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB18908979@DEN-MEXMS-001.corp.ebay.com> References: <4CF4609E.6090201@extendedsubset.com> <4CF479F0.5070505@extendedsubset.com> <4CF52786.7060907@extendedsubset.com> In-Reply-To: <4CF52786.7060907@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: PWlLmn666OqdS5vcxtRrwA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 17:27:10 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Marsh Ray >=20 >=20 > What if all the sites I remember the URLs for had configured HSTS? Would > this hotel's network just be broken for me? (Arguably it's broken already= .) Then this lousy architectural hack that middleboxes do to spoof traffic wou= ld break. We need another standards compliant way for them to do this, rat= her than just hacking using the tools they have available. My current pet= -idea is a DHCP extension field that tells the client that it will need to = authenticate, and where to go to do that. Then the client can get that val= ue from the DHCP server, and it has a well-established way to know how to g= et the user on the network. > What if I gave in and accepted the cert error, then this heinous middle b= ox > presented the hotel chain's home page under somebody else's domain > name, and the hotel admin just read about HSTS and turned it on? Yep, that would be bad. But, essentially, damned if you do, damned if you = don't. We got lots of complaints that HSTS completely eliminated a user's = ability to choose to accept a self-signed cert. We also want to prevent Mi= TM attacks. We went with the TOFU approach because we don't currently have= a reliable OOB bootstrapping method. We're hoping that wider DNSSEC deplo= yment gives us more options in that area. > What if Telco-del-Qwertystan accidentally routes 20% of all Internet traf= fic > through their McMantec ThoughtPolice(TM) SSL intercepting firewall, which > they conveniently equipped with their trusted root CA and this box proxie= s > or constructs responses which turns on HSTS for one year. Maybe this > firewall can even do this with plain http requests, too? All by accident,= of > course. Well, in this case a user will still get a certificate warning for every si= te they visit unless they install this CA as a root in their browser. Acce= pting that cert for https://www.foo.com won't make the browser trust that c= ert for *, just for that one site. > Or maybe somebody at some sub-sub-CA of a commonly trusted root > accidentally trips on the way to the secure storage vault and hits the bu= tton > on their phone that posts the private key to pastebin > http://www.google.com/search?q=3D"begin+rsa+private+key"+site%3Apaste > bin.com > and somebody else makes a viral facebook app that has the helpful side > effect of turning on HSTS for every non-ssl site anyone visits? So, you want us to design a protocol that protects against all the things t= hat can go wrong with a key compromise? Really, or are you just throwing o= ut science fiction here? > Or what if some TLD operator, who is also a trusted CA, decided it would = be > good for their certificate business if they pre-loaded HSTS on every not-= yet- > registered domain name via a wildcard DNS result? > http://en.wikipedia.org/wiki/Site_Finder This isn't a technology/protocol issue, this is a policy issue, and it isn'= t going to be solved purely with technology. > It seems like before HSTS a CA-gone-bad could compromise https: sites via > an active attack, or decrypt captured traffic if DHE were not in use. Thi= s > capability would hopefully end soon after their tomfoolery was discovered > by removing it from the trusted store or revoking it. With HSTS, however,= it > seems that the potential exists for a long-lasting DoS on sites which ser= ve > plain http. Just like a rogue ISP, DNS provider, etc. can publish really long TTL recor= ds for things. I really don't know what you're proposing here to solve the= problem we'd like to solve. Are you saying we should give up on trying to= solve it? - Andy From dev.akhawe@gmail.com Tue Nov 30 10:18:29 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B88528C153 for ; Tue, 30 Nov 2010 10:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j6lowBSt0ps for ; Tue, 30 Nov 2010 10:18:28 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 681673A6C15 for ; Tue, 30 Nov 2010 10:18:28 -0800 (PST) Received: by wwa36 with SMTP id 36so6233635wwa.13 for ; Tue, 30 Nov 2010 10:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=akQilUub1TPLqB6O8seUKTT0WHxkCRjC/fx4mFSpc6Y=; b=PBvHz9Ho0if7ORms7gffQrE+5YHds1xv1MIeDJEXryLod2Vj7WWQosfh0mfhNlaKA7 UnooPRM4YnxHujBW2WlrvGrJeDd9VR1Mfr2xdI4UABUS3HynLaUhJnDKM4OL+9QNQeEU 9wkqtUCJ+qfC2fwOjGwePj0XDGX+9Hzx3GqVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=kjEjcbH4rm41/WPeGpaZfHhTvcMzpxBSl2Mkz+Y2xlc2+SvR/GFDsEk8VzK+vTKV48 WfYQkzRH1SRNtQ21RunoIsJ0ADP0yzfeMmE09Psl4IYpNo+/QecL2ad2h9XUOs0DxMol ALROEIJQwjtLGG3ZiXUumcfvSbvh+A0Z87kho= Received: by 10.216.158.132 with SMTP id q4mr2056354wek.103.1291141179842; Tue, 30 Nov 2010 10:19:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.86.11 with HTTP; Tue, 30 Nov 2010 10:19:18 -0800 (PST) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB189088D2@DEN-MEXMS-001.corp.ebay.com> References: <4CF4609E.6090201@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB189088D2@DEN-MEXMS-001.corp.ebay.com> From: Devdatta Akhawe Date: Tue, 30 Nov 2010 10:19:18 -0800 Message-ID: To: "Steingruebl, Andy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 18:18:29 -0000 > > In the case of programmatic clients, This is what I was trying to address in my email - instead of making a distinction between programmatic clients and non programmatic clients (where do you put wget ?), I was saying that we should make the distinction based on 'when can the decision to overwrite cert wanings take place?' In the case of browsers, the current problem is that this decision is made by the user when he wants to get things done, which HSTS is rightly trying to solve. even for programmatic clients, the decision to over ride cert errors is taken by a human somewhere , probably via a config file or call parameter. -devdatta > > - Andy > From thassloc@adobe.com Tue Nov 30 10:52:46 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DC33A6C19 for ; Tue, 30 Nov 2010 10:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.072 X-Spam-Level: X-Spam-Status: No, score=-105.072 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVE0EbQykL9x for ; Tue, 30 Nov 2010 10:52:45 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by core3.amsl.com (Postfix) with ESMTP id 698C53A6C15 for ; Tue, 30 Nov 2010 10:52:45 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKTPVIQx5IZJSq9Oph/zzlTwhKMlBUruE0@postini.com; Tue, 30 Nov 2010 10:53:57 PST Received: from inner-relay-4.eur.adobe.com ([192.150.8.237]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oAUIrY3f011460; Tue, 30 Nov 2010 10:53:35 -0800 (PST) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id oAUIrpWj000994; Tue, 30 Nov 2010 10:53:51 -0800 (PST) Received: from nambx07.corp.adobe.com ([10.8.189.232]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Tue, 30 Nov 2010 10:53:50 -0800 From: Travis Hassloch To: Marsh Ray , Adam Barth Date: Tue, 30 Nov 2010 10:53:49 -0800 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuQrHH+uHlAllyKQb+idhRZIadxtAAE3pw6 Message-ID: In-Reply-To: <4CF52786.7060907@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 18:52:46 -0000 On 11/30/10 8:34 AM, "Marsh Ray" wrote: > I was in a hotel a few weeks back and I plugged into the room ethernet. > I opened my web browser to the start page, about:blank. I pulled up a > web page by typing "https://....". I think it was probably my bank's site= . > I get a certificate mismatch error. Of course, I didn't accept the > certificate. > Figuring what's going on, I try to open http://google.com/ instead. It > comes back with a redirect to the hotel's captive portal where I have to > enter some registration code or other. I was actually thinking the same thing last night and intending to ask this very same question. It's even worse if you've installed one of the extensions that force you to the HTTPS link by default; I tried google.com and a few others before finding a common site that didn't have rules in the firefox extension. > What if I gave in and accepted the cert error, then this heinous middle > box presented the hotel chain's home page under somebody else's domain > name... > Or what if some TLD operator, who is also a trusted CA, decided it would > be good for their certificate business if they pre-loaded HSTS on every > not-yet-registered domain name via a wildcard DNS result? > http://en.wikipedia.org/wiki/Site_Finder I've honestly wondered, from time to time, whether these sorts of things were breaking any laws. It's at least misrepresentation; pretending ownership of a domain name, possibly a trademark, and representing one's ow= n web content as belonging to someone else. I saw a web site the other day where the provider had helpfully put up a page saying the web site was experiencing technical difficulties. However, it wasn't so helpful to the mirroring scripts, which decided the site no longer had so many gigabytes of information on it, and proceeded to erase the local copy, and create a new copy, with new last-modified timestamps, newer than the actual site. I personally wouldn't mind too much if HSTS made such things simply stop working, though would be concerned if HSTS made such things into an inadvertent DoS tool. Also, if the domain name changed hands, it might be unusable for some users until/unless the new admin paid the "root CA tax" (since it prevents self-signed, and those users would be unable to access a plain HTTP site to obtain a non-canonical root CA cert). Thanks! --=20 Travis Hassloch Flash Player Security Engineer From asteingruebl@paypal-inc.com Tue Nov 30 11:01:54 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE4528C127 for ; Tue, 30 Nov 2010 11:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.117 X-Spam-Level: X-Spam-Status: No, score=-7.117 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w2JYutdi0fw for ; Tue, 30 Nov 2010 11:01:53 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 36FF028C129 for ; Tue, 30 Nov 2010 11:01:53 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=YUAGifF9r3ZwtwYmb4eYBRGdLkjP2WMPwCMqOdXzgEAYc7Okc1R6GVvq nxtKW0sJ4cf1htTnk94BQ1mJtU2nYN4nZVj+9yAO+9mQn8YHeOd/I8y5N wcFwULQI+FwIAoR; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1291143785; x=1322679785; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Travis=20Hassloch=20,=20M arsh=20Ray=0D=0A=09,=20Adam=20B arth=20|CC:=20"websec@ietf.org"=20|Date:=20Tue,=2030=20Nov=202010=2012:03:03 =20-0700|Subject:=20RE:=20[websec]=20Some=20questions=20a bout=20HSTS|Message-ID:=20<5EE049BA3C6538409BBE6F1760F328 ABEB189E56C9@DEN-MEXMS-001.corp.ebay.com>|References:=20< 4CF52786.7060907@extendedsubset.com>=0D=0A=20|In-Reply-To:=20|Content-Transfer-Encoding:=20quoted-print able|MIME-Version:=201.0; bh=5HdrV39AqI7c1jvcLti+LHnEqxn5RvdequxycIBvAuE=; b=T6sKYyjNDocv8+4R4cNEEoIYc6wpSk0CN4lfYctVanDxSB/XLYyoSHEW G7RNAnNpB3kn1h2CljIWMAyV3pQ4Zhl9T9AfgUU9dceZG8KyXNWfVj20Q lpZJM0DdnJ1rQEH; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.59,281,1288594800"; d="scan'208";a="207663" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 30 Nov 2010 11:03:04 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Tue, 30 Nov 2010 12:03:04 -0700 From: "Steingruebl, Andy" To: Travis Hassloch , Marsh Ray , Adam Barth Date: Tue, 30 Nov 2010 12:03:03 -0700 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuQrHH+uHlAllyKQb+idhRZIadxtAAE3pw6AABC20A= Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB189E56C9@DEN-MEXMS-001.corp.ebay.com> References: <4CF52786.7060907@extendedsubset.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: 82me1K4Z6XUcnL0MiAew3w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 19:01:54 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Travis Hassloch > I've honestly wondered, from time to time, whether these sorts of things > were breaking any laws. It's at least misrepresentation; pretending > ownership of a domain name, possibly a trademark, and representing one's > own web content as belonging to someone else. Most of them (middleboxes) just redirect to their URL, rather than hosting = content on the intercepted domain. That said, Kaminsky found bugs in the on= es that ISPs were using for typo-monetization that did allow XSS of the spo= ofed domain, which was a seriously scary situation... IANAL, but reputable sources tell me that while these redirects may in fact= be a violation of some sort, actually making a case of it wouldn't be easy= , nor cheap, nor very likely to succeed. - Andy From marsh@extendedsubset.com Tue Nov 30 13:09:30 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C678E3A6C34 for ; Tue, 30 Nov 2010 13:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvjRzES7L3+m for ; Tue, 30 Nov 2010 13:09:29 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 3667D3A6C16 for ; Tue, 30 Nov 2010 13:09:28 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PNXTE-000Gsd-80; Tue, 30 Nov 2010 21:10:40 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 67CD36018; Tue, 30 Nov 2010 21:10:38 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/hshg/0xukN89JN31au2s6xrxe+VNbXr4= Message-ID: <4CF5684F.9050201@extendedsubset.com> Date: Tue, 30 Nov 2010 15:10:39 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Steingruebl, Andy" References: <4CF4609E.6090201@extendedsubset.com> <4CF479F0.5070505@extendedsubset.com> <4CF52786.7060907@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB18908979@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB18908979@DEN-MEXMS-001.corp.ebay.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 21:09:31 -0000 On 11/30/2010 11:28 AM, Steingruebl, Andy wrote: >> -----Original Message----- From: websec-bounces@ietf.org >> [mailto:websec-bounces@ietf.org] On Behalf Of Marsh Ray >> >> >> What if all the sites I remember the URLs for had configured HSTS? >> Would this hotel's network just be broken for me? (Arguably it's >> broken already.) > > Then this lousy architectural hack that middleboxes do to spoof > traffic would break. We need another standards compliant way for > them to do this, rather than just hacking using the tools they have > available. My current pet-idea is a DHCP extension field that tells > the client that it will need to authenticate, and where to go to do > that. Then the client can get that value from the DHCP server, and > it has a well-established way to know how to get the user on the > network. I think there is a 'set proxy' option in DHCP, though I don't know how many clients would follow it. Windows broadcasts around for "WPAD" to try to discover a proxy. Of course, spoofing responses either of these messages is usually enough to gain the attacker MitM capability against that computer for as long as he remains connected. >> What if I gave in and accepted the cert error, then this heinous >> middle box presented the hotel chain's home page under somebody >> else's domain name, and the hotel admin just read about HSTS and >> turned it on? > > Yep, that would be bad. But, essentially, damned if you do, damned > if you don't. Option C? > We got lots of complaints that HSTS completely > eliminated a user's ability to choose to accept a self-signed cert. Uh, yeah, that's kind of the point. > We also want to prevent MiTM attacks. We went with the TOFU approach > because we don't currently have a reliable OOB bootstrapping method. Well the header is only accepted from a properly cert-authenticated server. That's way better than TOFU. > We're hoping that wider DNSSEC deployment gives us more options in > that area. Almost like what you want is a distributed table. Perhaps you could just replicate something like a digest of the hostname with a signature by the server's cert. > Well, in this case a user will still get a certificate warning for > every site they visit unless they install this CA as a root in their I'm using 'Qwertystan' as a placeholder for any number of trusted root CAs that come with my browser and OS. > browser. Accepting that cert for https://www.foo.com won't make the > browser trust that cert for *, just for that one site. > >> and somebody else makes a viral facebook app that has the helpful >> side effect of turning on HSTS for every non-ssl site anyone >> visits? > > So, you want us to design a protocol that protects against all the > things that can go wrong with a key compromise? No, but we should try our very best to understand them. > Really, or are you > just throwing out science fiction here? I really don't know. The conclusion I've come to recently is that sometimes the most outlandish-sounding threats will eventually become real possibilities, if the fundamental technology will allow it. Imagine going back just 15 years and predicting the inevitability of Zeus and Stuxnet. You'd likely be considered a crank. Actually, I think all of the things I mentioned have to some extent already happened, though not in such a worst-case combination. I have no hard evidence for the uncontrolled root CA key is >> result? http://en.wikipedia.org/wiki/Site_Finder > > This isn't a technology/protocol issue, this is a policy issue, and > it isn't going to be solved purely with technology. Yeah fair enough. But since we're actively changing the technology, it seems like we're obligated to think about the policy implications at this point. >> It seems like before HSTS a CA-gone-bad could compromise https: >> sites via an active attack, or decrypt captured traffic if DHE were >> not in use. This capability would hopefully end soon after their >> tomfoolery was discovered by removing it from the trusted store or >> revoking it. With HSTS, however, it seems that the potential exists >> for a long-lasting DoS on sites which serve plain http. > > Just like a rogue ISP, DNS provider, etc. can publish really long TTL > records for things. Seems like a good analogy, but don't those tend to get cleared out with a reboot? > I really don't know what you're proposing here > to solve the problem we'd like to solve. Are you saying we should > give up on trying to solve it? No, I'm just brainstorming and asking questions, intentionally without regard to whether or not it reflects well or poorly on any particular idea. While it's true that a rogue CA can create all sorts of mischief, I am starting to think that HSTS may represent a categorical increase in the severity of certain attacks. An attacker who can exploit a header injection via URL and cause the client to request an image from a chosen https URL can disable that client's ability to access the corresponding http site (and subdomains) for "max-max-age". An attacker who can exploit a header injection via URL and cause the client to request an image from a chosen https URL can disable that client's ability to access the corresponding http site (and subdomains) for "max-max-age". An attacker who can impersonate a legitimate https site to the browser can disable http access to that site and its subdomains. DoS on a scale never before seen could be possible if an attacker had access to a trusted root key or is able to obtain an overly-broad wildcard (e.g., *\0...). For example, a client could be made to request https://com/ and if the attacker could reply with an accepted cert, he could set HSTS on all .com websites, for max-max-age. This could be repeated with a few other TLDs, effectively removing the client's ability to connect to the non-https web. The target URL https://./ may need consideration as well. An attacker who can cause the client to request any one url from an HSTS site and view the response can determine if the user had contact with that server at any time during the previous max-age. This allows external attackers to probe laptops and mobile devices for information about the internal corporate network. A user who is willing to accept a self-signed certificate (perhaps they are anticipating it from their personal router or an unimportant website) may perhaps be tricked into accepting an overly-broad wildcard cert ("*" or "*.com") with their request redirected to a phony top-level domain. The browser may not faithfully show all the details of the requested host, or the user may not understand that the effects of accepting this cert could extend beyond the site he thought he'd requested. The HSTS flag, particularly with the subdomains option, has the potential to spill over to unintended systems. Often many components of a system share an https client facility. For example, if microsoft.com (or their hosting provider) accidentally set HSTS with subdomains for a period of time, it could conceivably prevent machines from contacting update servers. I think the update process may rely on plain http for the initial connection. Does HSTS have any interactions with non-transparent http proxies? Should a browser be willing to talk plain http with a proxy for which the dns name matches a known HSTS domain? Just some thoughts. - Marsh From asteingruebl@paypal-inc.com Tue Nov 30 13:42:32 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840013A6C95 for ; Tue, 30 Nov 2010 13:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.271 X-Spam-Level: X-Spam-Status: No, score=-7.271 tagged_above=-999 required=5 tests=[AWL=1.846, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It6q1AkVLBGb for ; Tue, 30 Nov 2010 13:42:30 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id D550E3A6C43 for ; Tue, 30 Nov 2010 13:42:29 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=mee81Zv9K/bOtxzeI/+aptcRVWXuWBOmxk78Uz4OAiKOABvNDysYQkZs ywSskYkjisBrdDQYRO+OFti6kp//qozEfLCW1oSzRj8ZKJuB+up8YW5QM vEn872laJgcK0mD; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1291153422; x=1322689422; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Marsh=20Ray=20|CC: =20Adam=20Barth=20,=20"websec@ietf.or g"=20|Date:=20Tue,=2030=20Nov=202010=201 4:43:40=20-0700|Subject:=20RE:=20[websec]=20Some=20questi ons=20about=20HSTS|Message-ID:=20<5EE049BA3C6538409BBE6F1 760F328ABEB189E58BB@DEN-MEXMS-001.corp.ebay.com> |References:=20=0D=0A=09=0D=0A=09=0D=0A=09<4CF4609E.6090201@extended subset.com>=0D=0A=09=0D=0A=09<4CF479F0.5070505@exten dedsubset.com>=0D=0A=09=0D=0A=20<4CF52786.7060907@ex tendedsubset.com>=0D=0A=20<5EE049BA3C6538409BBE6F1760F328 ABEB18908979@DEN-MEXMS-001.corp.ebay.com>=0D=0A=20<4CF568 4F.9050201@extendedsubset.com>|In-Reply-To:=20<4CF5684F.9 050201@extendedsubset.com>|Content-Transfer-Encoding:=20q uoted-printable|MIME-Version:=201.0; bh=T2M0XZKm+W9qe/fni0hq+u6VXfQctL+hHN2zqjjI8qs=; b=d2J1NR6koFIyJeV0lyX+PpgfFK86puex69huILq0sfrmg4IvO1WDhzf3 GAon2qTgNpnznrHz7dCPcSDXIdes89uY6S27hNppTRzwFjpW6cdk0qyCv oDa6J9cSDpejMhZ; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.59,281,1288594800"; d="scan'208";a="307736" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 30 Nov 2010 13:43:42 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Tue, 30 Nov 2010 14:43:41 -0700 From: "Steingruebl, Andy" To: Marsh Ray Date: Tue, 30 Nov 2010 14:43:40 -0700 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuQ0wzmqy092f7kSFq+ah9tcFhhYwAA5HNw Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB189E58BB@DEN-MEXMS-001.corp.ebay.com> References: <4CF4609E.6090201@extendedsubset.com> <4CF479F0.5070505@extendedsubset.com> <4CF52786.7060907@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB18908979@DEN-MEXMS-001.corp.ebay.com> <4CF5684F.9050201@extendedsubset.com> In-Reply-To: <4CF5684F.9050201@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: MRmXPCgrOsXDsYv2otgUEw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 21:42:32 -0000 > -----Original Message----- > From: Marsh Ray [mailto:marsh@extendedsubset.com] > Sent: Tuesday, November 30, 2010 1:11 PM > To: Steingruebl, Andy > Cc: Adam Barth; websec@ietf.org > Subject: Re: [websec] Some questions about HSTS >=20 > I think there is a 'set proxy' option in DHCP, though I don't know how ma= ny > clients would follow it. Windows broadcasts around for "WPAD" to try to > discover a proxy. Of course, spoofing responses either of these messages = is > usually enough to gain the attacker MitM capability against that computer= for > as long as he remains connected. Yeah, I didn't know how well this was supported. And, even there, you end = up relying on HTTP-407 for proxy authentication if you want to do this inli= ne, and that mechanism can't use forms, etc. So, you're still kind of hose= d essentially if you go this route. > I really don't know. The conclusion I've come to recently is that sometim= es > the most outlandish-sounding threats will eventually become real > possibilities, if the fundamental technology will allow it. Imagine going= back > just 15 years and predicting the inevitability of Zeus and Stuxnet. You'd= likely > be considered a crank. I agree with this, which is why HSTS in the first place. We are still tryi= ng to measure how much malicious MiTM is happening in the real world. We h= ave existence proofs from real access points, etc. but we don't have percen= tage data, etc. Hoping to get more of that. But, given the number of weak= access points out there, easily compromised via things like CSRF, its real= ly a question of when, not if, these attacks happen at scale. > An attacker who can exploit a header injection via URL and cause the clie= nt to > request an image from a chosen https URL can disable that client's abilit= y to > access the corresponding http site (and subdomains) for "max-max-age". Yep. In the same way that a site that is vulnerable to XSS cannot protect = itself against CSRF. There are some layers here. HSTS doesn't protect aga= inst malware on the client either, and it isn't designed to. =20 > An attacker who can cause the client to request any one url from an HSTS = site > and view the response can determine if the user had contact with that ser= ver > at any time during the previous max-age. This allows external attackers t= o > probe laptops and mobile devices for information about the internal > corporate network. I suppose, but again this kind of low-grade information leak isn't that val= uable, and if the connection were HTTP you could tell by watching the size = of responses whether the client had visited because it might have things ca= ched. =20 > Does HSTS have any interactions with non-transparent http proxies? > Should a browser be willing to talk plain http with a proxy for which the= dns > name matches a known HSTS domain? It uses a proxy as normal. It doesn't start doing HSTS until after CONNECT= goes through the proxy. =20 From paul.hoffman@vpnc.org Tue Nov 30 14:34:55 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092623A6C25 for ; Tue, 30 Nov 2010 14:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.322 X-Spam-Level: X-Spam-Status: No, score=-101.322 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQflrxgEdFAT for ; Tue, 30 Nov 2010 14:34:54 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 35C4F3A6C35 for ; Tue, 30 Nov 2010 14:34:54 -0800 (PST) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAUMa4Bo070680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Nov 2010 15:36:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 30 Nov 2010 14:36:02 -0800 To: websec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [websec] Another way to look at announcing strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 22:34:55 -0000 Greetings again. As I mentioned briefly in my presentation in Beijing, there are some assumptions that various people in this discussion make that don't jibe with the assumptions that others make. The HSTS draft is based on one set of assumptions, but many of the commenters come from a different set of assumptions, and the two sides are talking past each other. I have just submitted the following: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Specifying That a Server Supports TLS > Author(s) : P. Hoffman > Filename : draft-hoffman-server-has-tls-00.txt > Pages : 7 > Date : 2010-11-30 > >A server that hosts applications that can be run with or without TLS >may want to communicate with clients whether the server is hosting an >application only using TLS or also hosting the application without >TLS. Doing so tells clients that try using TLS but fail to set up a >TLS session whether or not they should even try to set up an insecure >session with the server. This document describes the use cases for >this type of communication and a secure method for communicating that >information. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-00.txt Section 2 is explicitly meant to cover all the assumptions that I have seen so far, and the semantics of the protocol is meant to allow everyone to state what they are doing. If people agree that the assumptions and semantics in my draft cover all the desired cases, I would be happy to share them with the HSTS draft. Note again that I am *not* proposing that the DNS-based solution be taken instead of the in-band solution for HTTP that the HSTS draft proposes. I think that both have good reasons for existing at the same time. I also hope that the two could have the same semantics so that if a company who wants to announce that it supports secure-only HTTP, it can do so both in the DNS (before someone has connected for the first time) and in HTTP (for those users who do not yet have DNSSEC enabled). --Paul Hoffman, Director --VPN Consortium From Jeff.Hodges@KingsMountain.com Tue Nov 30 18:39:46 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8EB3A6C21 for ; Tue, 30 Nov 2010 18:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.758 X-Spam-Level: X-Spam-Status: No, score=-100.758 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_DUL=0.877, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buTWgeT+7snU for ; Tue, 30 Nov 2010 18:39:45 -0800 (PST) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 486A63A6C42 for ; Tue, 30 Nov 2010 18:39:45 -0800 (PST) Received: (qmail 30760 invoked by uid 0); 1 Dec 2010 02:40:57 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 1 Dec 2010 02:40:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=f5NgbIPEgT6yTk9aUmrBJ8H4c71K/BYlmNxYsBGGY1chnIA7fxaZTXUtj55ltWB0JnPqD5x6Q9jsPUQIwVYp374j0oP1F8w8upK5z8fsrANwdkCx/IbO7il/ijW7eBS/; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PNccr-0001zO-Jb for websec@ietf.org; Tue, 30 Nov 2010 19:40:57 -0700 Message-ID: <4CF5B5B7.50604@KingsMountain.com> Date: Tue, 30 Nov 2010 18:40:55 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] Another way to look at announcing strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 02:39:46 -0000 > Greetings again. As I mentioned briefly in my presentation in Beijing, there > are some assumptions that various people in this discussion make that don't > jibe with the assumptions that others make. The HSTS draft is based on one > set of assumptions, but many of the commenters come from a different set of > assumptions, and the two sides are talking past each other. > > I have just submitted the following: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Specifying That a Server Supports TLS >> Author(s) : P. Hoffman >> Filename : draft-hoffman-server-has-tls-00.txt >> Pages : 7 >> Date : 2010-11-30 >> >> A server that hosts applications that can be run with or without TLS may >> want to communicate with clients whether the server is hosting an >> application only using TLS or also hosting the application without TLS. >> Doing so tells clients that try using TLS but fail to set up a TLS session >> whether or not they should even try to set up an insecure session with the >> server. This document describes the use cases for this type of >> communication and a secure method for communicating that information. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-00.txt Interesting, thanks for writing & posting this. > Section 2 is explicitly meant to cover all the assumptions that I have seen > so far, and the semantics of the protocol is meant to allow everyone to > state what they are doing. If people agree that the assumptions and > semantics in my draft cover all the desired cases, I would be happy to share > them with the HSTS draft. Without commenting on the specifics of the proposed RR name and contents and syntax, that section 2 does look overall useful, I'll see how it might be leveraged in -strict-transport-sec. > Note again that I am *not* proposing that the DNS-based solution be taken > instead of the in-band solution for HTTP that the HSTS draft proposes. I > think that both have good reasons for existing at the same time. agreed. > I also hope > that the two could have the same semantics so that if a company who wants to > announce that it supports secure-only HTTP, it can do so both in the DNS > (before someone has connected for the first time) and in HTTP (for those > users who do not yet have DNSSEC enabled). Yes, acknowledging and facilitating such deployment overlaps (both on server and client sides) will be important -- not the least because they'll be long-lasting. =JeffH From duerst@it.aoyama.ac.jp Tue Nov 30 23:10:39 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA4D3A6D14 for ; Tue, 30 Nov 2010 23:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.202 X-Spam-Level: X-Spam-Status: No, score=-100.202 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIuX1kRj+v07 for ; Tue, 30 Nov 2010 23:10:36 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by core3.amsl.com (Postfix) with ESMTP id 21B4A28C0E6 for ; Tue, 30 Nov 2010 22:52:23 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id oB16rN2t027909 for ; Wed, 1 Dec 2010 15:53:23 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5b7e_3ec8_b051af9e_fd17_11df_9e0b_001d096c5782; Wed, 01 Dec 2010 15:53:22 +0900 Received: from [IPv6:::1] ([133.2.210.1]:47307) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 1 Dec 2010 15:53:21 +0900 Message-ID: <4CF5F0DA.5090602@it.aoyama.ac.jp> Date: Wed, 01 Dec 2010 15:53:14 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Marsh Ray References: <4CF4609E.6090201@extendedsubset.com> <4CF479F0.5070505@extendedsubset.com> <4CF52786.7060907@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB18908979@DEN-MEXMS-001.corp.ebay.com> <4CF5684F.9050201@extendedsubset.com> In-Reply-To: <4CF5684F.9050201@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 07:10:39 -0000 On 2010/12/01 6:10, Marsh Ray wrote: > On 11/30/2010 11:28 AM, Steingruebl, Andy wrote: >>> -----Original Message----- From: websec-bounces@ietf.org >>> [mailto:websec-bounces@ietf.org] On Behalf Of Marsh Ray >>> >>> >>> What if all the sites I remember the URLs for had configured HSTS? >>> Would this hotel's network just be broken for me? (Arguably it's >>> broken already.) >> >> Then this lousy architectural hack that middleboxes do to spoof >> traffic would break. We need another standards compliant way for >> them to do this, rather than just hacking using the tools they have >> available. My current pet-idea is a DHCP extension field that tells >> the client that it will need to authenticate, and where to go to do >> that. Then the client can get that value from the DHCP server, and >> it has a well-established way to know how to get the user on the >> network. > > I think there is a 'set proxy' option in DHCP, though I don't know how > many clients would follow it. Windows broadcasts around for "WPAD" to > try to discover a proxy. Of course, spoofing responses either of these > messages is usually enough to gain the attacker MitM capability against > that computer for as long as he remains connected. There is also a proposal to solve the "hotel problem" on the HTTP level: http://tools.ietf.org/html/draft-nottingham-http-portal-01 Regards, Martin. >>> What if I gave in and accepted the cert error, then this heinous >>> middle box presented the hotel chain's home page under somebody >>> else's domain name, and the hotel admin just read about HSTS and >>> turned it on? >> >> Yep, that would be bad. But, essentially, damned if you do, damned >> if you don't. > > Option C? > >> We got lots of complaints that HSTS completely >> eliminated a user's ability to choose to accept a self-signed cert. > > Uh, yeah, that's kind of the point. > >> We also want to prevent MiTM attacks. We went with the TOFU approach >> because we don't currently have a reliable OOB bootstrapping method. > > Well the header is only accepted from a properly cert-authenticated > server. That's way better than TOFU. > >> We're hoping that wider DNSSEC deployment gives us more options in >> that area. > > Almost like what you want is a distributed table. Perhaps you could just > replicate something like a digest of the hostname with a signature by > the server's cert. > >> Well, in this case a user will still get a certificate warning for >> every site they visit unless they install this CA as a root in their > > I'm using 'Qwertystan' as a placeholder for any number of trusted root > CAs that come with my browser and OS. > >> browser. Accepting that cert for https://www.foo.com won't make the >> browser trust that cert for *, just for that one site. >> >>> and somebody else makes a viral facebook app that has the helpful >>> side effect of turning on HSTS for every non-ssl site anyone >>> visits? >> >> So, you want us to design a protocol that protects against all the >> things that can go wrong with a key compromise? > > No, but we should try our very best to understand them. > >> Really, or are you >> just throwing out science fiction here? > > I really don't know. The conclusion I've come to recently is that > sometimes the most outlandish-sounding threats will eventually become > real possibilities, if the fundamental technology will allow it. Imagine > going back just 15 years and predicting the inevitability of Zeus and > Stuxnet. You'd likely be considered a crank. > > Actually, I think all of the things I mentioned have to some extent > already happened, though not in such a worst-case combination. I have no > hard evidence for the uncontrolled root CA key is > >>> result? http://en.wikipedia.org/wiki/Site_Finder >> >> This isn't a technology/protocol issue, this is a policy issue, and >> it isn't going to be solved purely with technology. > > Yeah fair enough. But since we're actively changing the technology, it > seems like we're obligated to think about the policy implications at > this point. > >>> It seems like before HSTS a CA-gone-bad could compromise https: >>> sites via an active attack, or decrypt captured traffic if DHE were >>> not in use. This capability would hopefully end soon after their >>> tomfoolery was discovered by removing it from the trusted store or >>> revoking it. With HSTS, however, it seems that the potential exists >>> for a long-lasting DoS on sites which serve plain http. >> >> Just like a rogue ISP, DNS provider, etc. can publish really long TTL >> records for things. > > Seems like a good analogy, but don't those tend to get cleared out with > a reboot? > >> I really don't know what you're proposing here >> to solve the problem we'd like to solve. Are you saying we should >> give up on trying to solve it? > > No, I'm just brainstorming and asking questions, intentionally without > regard to whether or not it reflects well or poorly on any particular idea. > > While it's true that a rogue CA can create all sorts of mischief, I am > starting to think that HSTS may represent a categorical increase in the > severity of certain attacks. > > An attacker who can exploit a header injection via URL and cause the > client to request an image from a chosen https URL can disable that > client's ability to access the corresponding http site (and subdomains) > for "max-max-age". > > An attacker who can exploit a header injection via URL and cause the > client to request an image from a chosen https URL can disable that > client's ability to access the corresponding http site (and subdomains) > for "max-max-age". > > An attacker who can impersonate a legitimate https site to the browser > can disable http access to that site and its subdomains. DoS on a scale > never before seen could be possible if an attacker had access to a > trusted root key or is able to obtain an overly-broad wildcard (e.g., > *\0...). For example, a client could be made to request https://com/ and > if the attacker could reply with an accepted cert, he could set HSTS on > all .com websites, for max-max-age. This could be repeated with a few > other TLDs, effectively removing the client's ability to connect to the > non-https web. The target URL https://./ may need consideration as well. > > An attacker who can cause the client to request any one url from an HSTS > site and view the response can determine if the user had contact with > that server at any time during the previous max-age. This allows > external attackers to probe laptops and mobile devices for information > about the internal corporate network. > > A user who is willing to accept a self-signed certificate (perhaps they > are anticipating it from their personal router or an unimportant > website) may perhaps be tricked into accepting an overly-broad wildcard > cert ("*" or "*.com") with their request redirected to a phony top-level > domain. The browser may not faithfully show all the details of the > requested host, or the user may not understand that the effects of > accepting this cert could extend beyond the site he thought he'd requested. > > The HSTS flag, particularly with the subdomains option, has the > potential to spill over to unintended systems. Often many components of > a system share an https client facility. For example, if microsoft.com > (or their hosting provider) accidentally set HSTS with subdomains for a > period of time, it could conceivably prevent machines from contacting > update servers. I think the update process may rely on plain http for > the initial connection. > > Does HSTS have any interactions with non-transparent http proxies? > Should a browser be willing to talk plain http with a proxy for which > the dns name matches a known HSTS domain? > > Just some thoughts. > > - Marsh > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > -- #-# Martin J. Dόrst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp