From nobody Fri Jul 1 03:47:40 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747DB12D56D; Fri, 1 Jul 2016 03:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrW3UfHxxemk; Fri, 1 Jul 2016 03:47:30 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 723B012D548; Fri, 1 Jul 2016 03:47:27 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id u61AlOBL098691; Fri, 1 Jul 2016 19:47:24 +0900 (JST) Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw2.nict.go.jp with ESMTP id u61AlOfP098687; Fri, 1 Jul 2016 19:47:24 +0900 (JST) Received: from VAIO (unknown [133.243.30.149]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id 5B77E6708; Fri, 1 Jul 2016 19:47:24 +0900 (JST) From: "Takeshi Takahashi" To: "'Julien Laganier'" References: <000901d14157$7052a680$50f7f380$@nict.go.jp> In-Reply-To: Date: Fri, 1 Jul 2016 19:47:24 +0900 Message-ID: <014b01d1d385$f3b39a00$db1ace00$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFfvRTvbwkjdx5jlulKrWATyyVqRgFkX6qJoNxtjqA= Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.7 at zenith2 X-Virus-Status: Clean Archived-At: Cc: draft-ietf-hip-rfc5203-bis.all@ietf.org, 'The IESG' , hip-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-hip-rfc5203-bis-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 10:47:33 -0000 Hello Julien, Thank you for your detailed explanation. I thought I have replied to your email before, but I haven't yet; I am = sorry for that. I have also checked the updates you've made based on the gen-art review = (and the related comments you've posted to the mailing list), and found = no further comments. I think this draft is ready. Best regards, Take > -----Original Message----- > From: Julien Laganier [mailto:julien.ietf@gmail.com] > Sent: Monday, February 1, 2016 2:52 AM > To: Takeshi Takahashi > Cc: The IESG; hip-chairs@tools.ietf.org; secdir@ietf.org; > draft-ietf-hip-rfc5203-bis.all@ietf.org > Subject: Re: [secdir] Secdir review of draft-ietf-hip-rfc5203-bis-09 >=20 > [resending with corrected typo in the recipient list. apologies for = the > noise] >=20 > Takahashi san, >=20 > Thank you for reviewing the document, and my apologies for the belated = reply. > Please find my answers to your comments/questions inlined > below: >=20 > On Mon, Dec 28, 2015 at 2:06 AM, Takeshi Takahashi > wrote: >=20 > [...] >=20 > > [overall feeling on this draft] > > > > ready, and good to proceed > > > > [overview] > > > > This draft updates RFC 5203 to cope with HIPv2 (RFC 7401). > > RFC 5203 specifies a registration mechanism for HIPv1 (RFC 5201). > > Likewiise, this draft specifies the mechanism for HIPv2. > > > > [questions] > > > > Below are simply clarification questions, and these do not block the > > further process of this document. > > I am not that familiar with HIP, so it would be helpful if you could > > provide me some comments on them to deepen my understanding. > > > > 1. "If the requester has one or more suitable certificates, the host > > SHOULD include them (or just the most suitable one)"(in section 3.3) > > > > I wonder whether it would be better to let the requester send only = the > > most suitable certificate. > > The requester may send multiple certificates, but it would be = helpful > > if the requester sends only the most suitable certificate, I guess. > > (It is easy to process from the standpoint of the receiver, isn't = it?) > > Would you explain why the draft encourages to send multiple > > certificates rather than sending only the most suitable certificate? >=20 > As the draft currently states, the suitability of certificates is = likely > to be application-specific, i.e., dependent on the specific service = for > which the requester seeks registration -- "How the suitability is = determined > and how the certificates are obtained is out of scope for this = document." >=20 > For example there may not be a strict ordering of certificates w.r.t. > suitability to register, i.e., given two certificates A and B, there = isn't > necessarily one that is more suitable than the other. >=20 > For example, a requester for a service may have certificates issued by = two > ISPs, such as a fixed wireline broadband ISP, and a mobile service = provider. > These may have brokered roaming agreements with various other parties = to > optimize topological closeness of the service registrar w.r.t. the > requester's current access network. If the requester always include = both > certificates in its requests, this would avoid having to specify and > implement complex certificate selection logic on the requester. >=20 > > 2. "it SHOULD send the registration request without the CERT = parameter > > to test whether the registrar accepts the request based on the = host's > > identity." (in Section 3.3) > > > > In this situation, if a malicious party knows the identity of the > > reqester, the party can get the access right. > > Is the identity protected so that no malicious party can get it? >=20 > The Host Identity is the public component of a public-private key = pair, and > since completion of the HIP exchange's mutual peer authentication = requires > knowledge of the private component of the key pair, an attacker = knowing the > public component would not be able to be granted any service = registration > based on that knowledge. >=20 > > 3. "Other documents will define specific values for registration = types. > > See > > Section 7 for more information" (Section 4.3) > > > > I looked at Section 7 to understaind the types and values of Reg = Type, > > but I guess the section does not define any on them. > > Are the types and values completely the same as the ones defined by > > RFC 5203? >=20 > The registration types are defined by the documents defining the = service > for which registration is being sought, and recorded in the relevant = IANA > registry. This document does not change the list of services currently = being > registered with IANA: >=20 > = p-parameters-11> >=20 > > 4. "Insufficient resource" and "Invalid certificate" (in the table = in > > Section 7) When a requester sends requests without sending CERT > > parameters, the requester expects to be authenticated based on its > > identity. > > But sometimes it fails. > > In this case, which of the failor type will be used? "Insufficient > > resources"? or "Invalid certificate"? or none of them? >=20 > As the draft currently states: >=20 > If the requester was not in the allowed list and the registrar > requires the requester to authenticate, the registrar MUST check > whether the packet also contains a CERT parameter. If the packet > does not contain a CERT parameter, the registrar MUST reject the > registrations requiring authentication with Failure Type 0 > (Registration requires additional credentials). >=20 > "Registration requires additional credentials" is allocated in the = relevant > IANA registry: >=20 > = p-parameters-13> >=20 > Thanks again for the review. With best regards, >=20 > --julien >=20 > On Mon, Dec 28, 2015 at 2:06 AM, Takeshi Takahashi > wrote: > > Hello, > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the = IESG. > > These comments were written primarily for the benefit of the = security > > area directors. > > Document editors and WG chairs should treat these comments just like > > any other last call comments. > > > > [overall feeling on this draft] > > > > ready, and good to proceed > > > > [overview] > > > > This draft updates RFC 5203 to cope with HIPv2 (RFC 7401). > > RFC 5203 specifies a registration mechanism for HIPv1 (RFC 5201). > > Likewiise, this draft specifies the mechanism for HIPv2. > > > > [questions] > > > > Below are simply clarification questions, and these do not block the > > further process of this document. > > I am not that familiar with HIP, so it would be helpful if you could > > provide me some comments on them to deepen my understanding. > > > > 1. "If the requester has one or more suitable certificates, the host > > SHOULD include them (or just the most suitable one)"(in section 3.3) > > > > I wonder whether it would be better to let the requester send only = the > > most suitable certificate. > > The requester may send multiple certificates, but it would be = helpful > > if the requester sends only the most suitable certificate, I guess. > > (It is easy to process from the standpoint of the receiver, isn't = it?) > > Would you explain why the draft encourages to send multiple > > certificates rather than sending only the most suitable certificate? > > > > 2. "it SHOULD send the registration request without the CERT = parameter > > to test whether the registrar accepts the request based on the = host's > > identity." (in Section 3.3) > > > > In this situation, if a malicious party knows the identity of the > > reqester, the party can get the access right. > > Is the identity protected so that no malicious party can get it? > > > > 3. "Other documents will define specific values for registration = types. > > See > > Section 7 for more information" (Section 4.3) > > > > I looked at Section 7 to understaind the types and values of Reg = Type, > > but I guess the section does not define any on them. > > Are the types and values completely the same as the ones defined by > > RFC 5203? > > > > 4. "Insufficient resource" and "Invalid certificate" (in the table = in > > Section 7) When a requester sends requests without sending CERT > > parameters, the requester expects to be authenticated based on its > > identity. > > But sometimes it fails. > > In this case, which of the failor type will be used? "Insufficient > > resources"? or "Invalid certificate"? or none of them? > > > > Thank you for your kind contributions. > > Take > > > > > > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Mon Jul 4 20:19:05 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8580C12D0B8; Mon, 4 Jul 2016 20:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNtMfPP_0L3P; Mon, 4 Jul 2016 20:19:03 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110CE12D0DD; Mon, 4 Jul 2016 20:19:03 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id r2so213767737oih.2; Mon, 04 Jul 2016 20:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=Vftd3XDVh3dnH1IPixq7Jsr1de0jR+otI2EuNJvXagg=; b=nIvPEAS0doPhIiQTUgLPbxJgI4AEJX3rH33z2/CSCyWbRZR1wHtKtHM+ceo6v2CirQ UjMahY+TKcmPtNn+P1OTAgkqqzgm6OkcKHwqy1YGhrlgseliANgRhIqBW5xLM+wd6p/h RhKbq3L0G0rr3JMghv89S57kbU1DVgPujJHV7lZjlurJf75OxLLh87i8d93mh91Piv5w O2pXYWCzf8D/wCBZAgHP9ysRkbhGVYxhFZhnQr/oDim3yA8ZeFOZOJiPlbzUt3QxX67V l8JBEfJarWDIw26reQB6QRie0wbHVmKqsFq0u1Hfbw8rQ+QV2qOMYVmca9HLuOt47trl P6GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Vftd3XDVh3dnH1IPixq7Jsr1de0jR+otI2EuNJvXagg=; b=ZvxvlyiAfbHTTUvq5pmlFkJpdvynk9aUja1RDE28iK5Ax0cNmDBqYntz77mZQ1VuP3 4+cj5VyQkOuhQNxFXUim+HtB/gXZ1BuOEjb/04ReMtZWAKEYQKQCsHXxtImkp0LH0n0/ 43C8plRfX8vP5bRmPEq/YcDy70qE2y7WQlse0DrI2VqaF2Fej8PIoILA5qOYNWB/F1XU +bmgkz3dScTfKrwVbvW7RdUHNvVXPzHjrzMKy75nLVBmuWG/NKxr04a0BqrNzX5gDveN 0mZkZLLA7Y/8Ze1mZw76tJYSG2So+S0Gz/TxlexkKkhXVdp4LBIb+jjplz4CWHEGA0dn OXYg== X-Gm-Message-State: ALyK8tI2XaR0E8l8tn/FCnxsLwegvN+pogS5KNtStbyRjjlhbwYj5cTPg9eMJ7pPoirqSKxC9LX8viD3+JPvsg== X-Received: by 10.202.229.66 with SMTP id c63mr8785521oih.81.1467688742369; Mon, 04 Jul 2016 20:19:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.242 with HTTP; Mon, 4 Jul 2016 20:18:47 -0700 (PDT) From: Donald Eastlake Date: Mon, 4 Jul 2016 23:18:47 -0400 Message-ID: To: "iesg@ietf.org" , draft-pd-dispatch-msrp-websocket.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "secdir@ietf.org" Subject: [secdir] SECDIR Review of draft-pd-dispatch-msrp-websocket-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 03:19:04 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies a new WebSocket sub-protocol as a reliable transport mechanism between MSRP (Message Session Relay Protocol) clients and relays. It depends on the use of secure WebSocket connections (TLS) and existing authentication mechanisms. I am not particularly familiar with WebSockets or MSRP but the Security Considerations section looks adequate to me. There are a lot of example message flows in this document that i don't really know enough to evaluate. Nits: It is peculiar that Sections 10, Section 11, and Appendix A have only a single subsection aa their entire content. In the case of Sections 10 and 11, I think the 10.1 and 11.1 headers should just be eliminated. In the case of Appendix A, probably the A.1 heading should be moved up to the A level. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Tue Jul 5 14:05:49 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C94128E18; Tue, 5 Jul 2016 14:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0zL7M7pyODN; Tue, 5 Jul 2016 14:05:43 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E235F127078; Tue, 5 Jul 2016 14:05:39 -0700 (PDT) X-AuditID: 12074422-dc7ff70000001e14-17-577c2122ea6f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 0A.D4.07700.2212C775; Tue, 5 Jul 2016 17:05:38 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u65L5bkW024086; Tue, 5 Jul 2016 17:05:38 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u65L5aCm003404; Tue, 5 Jul 2016 17:05:37 -0400 From: Tom Yu To: iesg@ietf.org, secdir@ietf.org, draft-pal-eidr-urn-2016.all@ietf.org Date: Tue, 05 Jul 2016 17:05:35 -0400 Message-ID: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUixG6nrqukWBNucGSJrsX8rb/ZLGb8mchs 8WHhQxYHZo8lS34yBTBGcdmkpOZklqUW6dslcGU0/tzHWHCBo2Lq5ifMDYzN7F2MnBwSAiYS ZxceYOxi5OIQEmhjkvi+dR4ThLOBUWLl8f/MEM5rRok7X36ygbSwCUhLHL+8iwnEFhHwkDi7 YCMziC0MNOrOuytgY1kEVCWuz3gBVs8roCux/MpNsBoeAU6J3sNTWSHighInZz5hAbGZBbQk bvx7yTSBkWcWktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE31cjNL9FJTSjcxgkPG RWkH48R/XocYBTgYlXh4JzyvDhdiTSwrrsw9xCjJwaQkysvyDSjEl5SfUpmRWJwRX1Sak1p8 iFGCg1lJhNdftiZciDclsbIqtSgfJiXNwaIkzhsUeSxMSCA9sSQ1OzW1ILUIJivDwaEkwcut ANQoWJSanlqRlplTgpBm4uAEGc4DNFwKpIa3uCAxtzgzHSJ/ilFRSpyXGSQhAJLIKM2D6wXH tBDjvleM4kCvCPOagVTxANMBXPcroMFMQIN/ulSDDC5JREhJNTD6Ge9cYM/24sjB7V+kRVMm 76840ifLVVHHorDp04LGzff0zD9UHeneFSu0dAKLWqFTleyyisM7Hl40j9Ludud/u09KgzFu y0y5S+0r067auoczanFM9XoecfnA0xcxxzSrq1feS0iqn+Kh/Pm24cYwx3weaSOuFB+OMNGV +9lrXWLObi7c91WJpTgj0VCLuag4EQBa7hUXxAIAAA== Archived-At: Subject: [secdir] secdir review of draft-pal-eidr-urn-2016-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 21:05:44 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: ready The security considerations section of this document seems reasonable. The following sentence seems unnecessarily specific, but it was also present in RFC 7302 and doesn't seem harmful to retain. "Note, however, that failure to conform to the syntactic and lexical equivalence rules in this specification when using an EIDR Identifier as a criteria for accessing restricted resources can result in granting unauthorized access to these resources." It appears to me that it would require a confluence of multiple serious implementation and/or configuration flaws for the above concerns to be relevant, e.g., a default-allow policy combined with differing lookup procedures for authorization versus content retrieval. From nobody Tue Jul 5 17:32:15 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6012912D0C8 for ; Tue, 5 Jul 2016 17:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT5ZKHJ7pbqB for ; Tue, 5 Jul 2016 17:32:11 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F174128E19 for ; Tue, 5 Jul 2016 17:32:11 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id f189so252094870oig.3 for ; Tue, 05 Jul 2016 17:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lmo2bBzRLyn6W1WR1Wml/EYW72tPryPS7p2ucdcTosY=; b=Hs6u4dTAeEbCy/YUmAkNK5nHkw3FIEmFEGezkSMs+2Ea1AMZ4+lRaE1DaVmeZJmQdK 2E/2qh9ZWJ18gdazpX6Ohe8mewIQI6iyfco0r7M9hBQITRHKb8mzbGtUqy6muWlajAjc TNVHvXwYL14VwREcTFOmPxdKghRH/l0oVmkUQwbZwKox3aCi+8KPLrvY+XRsSkFxCNdP 6uGMarAoUSvyCs1BATriZiiggLB+MLjBuX9DIKwcmNxnjFCcwEPxs0kJRnJewQuTJG3T rU6XDg8CjtIN+NtGy3b1YoyCIf6tCt3lr2sHj+qfqMgBFcYbhPcKfavoq0q1KzbdeSdi Gcdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lmo2bBzRLyn6W1WR1Wml/EYW72tPryPS7p2ucdcTosY=; b=ADUVW1I5Pd4iq/k8Qlvm0O2mbmirwqr5RTZAlFgN6DEZjfOHWPx4QK9LFL7FMqkew5 gVe38JQ6r2GysWdNmm1q/DjUZwlQMPoMjC5270mTDFAsX0SLHORiqIhihSGzBOwHFI/c QPjan7IDPe9JNhF9I43CniuCTnZ0e7mony9gAX3UbO9nhFI040rvAfDNKGJMxkxdq9OV 8Id/27Js8j1/qaX9MRUPqF1V70YyvmOp9qPC1aWO2XIKME56768QpcmFhZzJftlb8Nok R60UhWIbVMBJDCtf5rhDcRBOJuIGX1yrDrmNQcHD/VmeZvEYr5ZxOigdWyW0Uv37ELdP bLyw== X-Gm-Message-State: ALyK8tJ5z3v66A0tG5zO4HIl6RKNiWfSYVtnDSdqxe2plpo2xNx2UfLKZ+VFj/hp0b5w6PUPksg/EJlY+f7AfQ== X-Received: by 10.157.47.103 with SMTP id h94mr9451066otb.170.1467765130807; Tue, 05 Jul 2016 17:32:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.242 with HTTP; Tue, 5 Jul 2016 17:31:56 -0700 (PDT) In-Reply-To: References: <5729944D.4040403@oracle.com> <5770C231.9060301@oracle.com> <577347DF.2060202@oracle.com> From: Donald Eastlake Date: Tue, 5 Jul 2016 20:31:56 -0400 Message-ID: To: Shawn M Emery Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-trill-irb.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-trill-irb-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 00:32:13 -0000 Hi Shawn, A version -14 has been uploaded with the intent that it resolve your comments. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Jun 29, 2016 at 2:23 PM, Donald Eastlake wrote: > Hi Shawn, > > On Wed, Jun 29, 2016 at 12:00 AM, Shawn M Emery wrote: >> On 06/28/16 08:56 PM, Donald Eastlake wrote: >>> >>> Hi Shawan, >>> >>> Thanks for our comments. >>> >>> On Mon, Jun 27, 2016 at 2:05 AM, Shawn M Emery >>> wrote: >>>> >>>> I have reviewed this document as part of the security directorate's >>>> ongoing effort to review all IETF documents being processed by the IESG. >>>> These comments were written primarily for the benefit of the security >>>> area directors. Document editors and WG chairs should treat these >>>> comments just like any other last call comments. >>>> >>>> This draft specifies layer 3 (inter-subnet) gateway messaging of the >>>> TRILL (Transparent Interconnection of Lots of Links) protocol. >>>> >>>> The security considerations section does exist and refers to Intermediate >>>> System to Intermediate System (IS-IS) authentication (RFC 5310) for >>>> securing >>>> information advertised by Routing Bridges. For generic TRILL security >>>> the >>>> draft refers to RFC 6325. For sensitive data, it prescribes end-to-end >>>> security, but does not reference or provide details on how this is done >>>> in >>>> a layer 3 deployment. >>> >>> Would you think it helpful if it gave IPsec and/or TLS as examples of >>> protocols that might be used for end-to-end security? >> >> Yes, whatever is commonly used in TRILL and if there are ones that shouldn't >> be used then I would suggest writing text describing why not. > > End stations attached to a TRILL campus think they are on the same > local link unless they use or listen for special link control or TRILL > IS-IS PDUs. So I would say it is no business of TRILL's to say what > end-to-end security protocol they should or shouldn't use. The > Security Considerations section is just pointing out the general > recommendation that end-to-end security is a good idea to supplement > any security of more limited transit scope, particularly for sensitive > information. > >>>> General comments: >>>> >>>> None. >>>> >>>> Editorial comments: >>>> >>>> Does TRILL and FGL need to be expanded in the Abstract and Introduction >>>> section, respectively? >>>> I think it would be helpful to describe the "Inner.VLAN" syntax used >>>> throughout the document. >>> >>> The payload of a TRILL Data packet looks like an Ethernet frame with a >>> VLAN tag which is the inner.VLAN. This could be added to the >>> definitions in Section 2. >> >> Thanks for clarifying. >> >>> ... >>>> >>>> s/optimal pair-wise forwarding path/optimal pair-wise forwarding paths/ >>> >>> I don't see that in version -13. >> >> The text was part of a new-line. Let's try: >> >> s/wise forwarding path/wise forwarding paths/ > > Ah, sorry, found it now. OK. > > Thanks, > Donald (document Shepherd) > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > >> Shawn. >> -- From nobody Tue Jul 5 22:45:34 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C1E12B05E for ; Tue, 5 Jul 2016 22:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzXYDmzCoHAh for ; Tue, 5 Jul 2016 22:45:32 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4001212B03D for ; Tue, 5 Jul 2016 22:45:32 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u665jSeP020844 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jul 2016 05:45:28 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u665jRYh028353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jul 2016 05:45:27 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u665jPB1023264; Wed, 6 Jul 2016 05:45:26 GMT Received: from [10.159.78.203] (/10.159.78.203) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Jul 2016 05:45:25 +0000 To: Donald Eastlake References: <5729944D.4040403@oracle.com> <5770C231.9060301@oracle.com> <577347DF.2060202@oracle.com> From: Shawn M Emery Message-ID: <577C9B7B.1030209@oracle.com> Date: Tue, 5 Jul 2016 23:47:39 -0600 User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: draft-ietf-trill-irb.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-trill-irb-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 05:45:34 -0000 Hi Donald, The updates clarifying elements of the security considerations section looks great. All the other updates looks good as well, with a few nits below: s/TENANT- GWMAC-LABEL/TENANT-GWMAC-LABEL/ s/for the updating/for the updates/ s/that tenant how/that tenant on how/ Thanks, Shawn. -- On 07/ 5/16 06:31 PM, Donald Eastlake wrote: > Hi Shawn, > > A version -14 has been uploaded with the intent that it resolve your comments. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Wed, Jun 29, 2016 at 2:23 PM, Donald Eastlake wrote: >> Hi Shawn, >> >> On Wed, Jun 29, 2016 at 12:00 AM, Shawn M Emery wrote: >>> On 06/28/16 08:56 PM, Donald Eastlake wrote: >>>> Hi Shawan, >>>> >>>> Thanks for our comments. >>>> >>>> On Mon, Jun 27, 2016 at 2:05 AM, Shawn M Emery >>>> wrote: >>>>> I have reviewed this document as part of the security directorate's >>>>> ongoing effort to review all IETF documents being processed by the IESG. >>>>> These comments were written primarily for the benefit of the security >>>>> area directors. Document editors and WG chairs should treat these >>>>> comments just like any other last call comments. >>>>> >>>>> This draft specifies layer 3 (inter-subnet) gateway messaging of the >>>>> TRILL (Transparent Interconnection of Lots of Links) protocol. >>>>> >>>>> The security considerations section does exist and refers to Intermediate >>>>> System to Intermediate System (IS-IS) authentication (RFC 5310) for >>>>> securing >>>>> information advertised by Routing Bridges. For generic TRILL security >>>>> the >>>>> draft refers to RFC 6325. For sensitive data, it prescribes end-to-end >>>>> security, but does not reference or provide details on how this is done >>>>> in >>>>> a layer 3 deployment. >>>> Would you think it helpful if it gave IPsec and/or TLS as examples of >>>> protocols that might be used for end-to-end security? >>> Yes, whatever is commonly used in TRILL and if there are ones that shouldn't >>> be used then I would suggest writing text describing why not. >> End stations attached to a TRILL campus think they are on the same >> local link unless they use or listen for special link control or TRILL >> IS-IS PDUs. So I would say it is no business of TRILL's to say what >> end-to-end security protocol they should or shouldn't use. The >> Security Considerations section is just pointing out the general >> recommendation that end-to-end security is a good idea to supplement >> any security of more limited transit scope, particularly for sensitive >> information. >> >>>>> General comments: >>>>> >>>>> None. >>>>> >>>>> Editorial comments: >>>>> >>>>> Does TRILL and FGL need to be expanded in the Abstract and Introduction >>>>> section, respectively? >>>>> I think it would be helpful to describe the "Inner.VLAN" syntax used >>>>> throughout the document. >>>> The payload of a TRILL Data packet looks like an Ethernet frame with a >>>> VLAN tag which is the inner.VLAN. This could be added to the >>>> definitions in Section 2. >>> Thanks for clarifying. >>> >>>> ... >>>>> s/optimal pair-wise forwarding path/optimal pair-wise forwarding paths/ >>>> I don't see that in version -13. >>> The text was part of a new-line. Let's try: >>> >>> s/wise forwarding path/wise forwarding paths/ >> Ah, sorry, found it now. OK. >> >> Thanks, >> Donald (document Shepherd) >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >>> Shawn. >>> -- From nobody Wed Jul 6 06:59:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5A412D516; Wed, 6 Jul 2016 06:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcPbnA3jNiK8; Wed, 6 Jul 2016 06:59:32 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04D812D179; Wed, 6 Jul 2016 06:59:31 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id h129so155350649lfh.1; Wed, 06 Jul 2016 06:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=8jyqZZ86M4cVA5NSoihzWivuaIuPIdhKnDqftpHz9IE=; b=mr18NM4pi6HXOFhb7TDmjJZGpfSJ7OeUG/fQ5TOgP5AeylxNi/+kkTlihOAeNhLxtW gDIdFTm+lbOI5UALgREXdEG+7twkpU1bsaFFchuuWDW7XYMwxVCmN5akiE2z4l7awh89 7v5TbIHy/sMsIlQqTimg0KhmYpyr3zP0oaAHLjG4JdKILGSWgvNaeTHY6pEnExdMVbDm GDGpGpTPqJKVjK4Gf0W+JjWHVCvAlcYAkkKFCUm5gEeX9lagWu9G2/2QAnyIK6e5JHq3 4bZvKXrCe26Tng/2aoXn+lGFMboVV9XE0c1+g7tNGvPuau73J+i/nIo4wHImBlMj6bSe txNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8jyqZZ86M4cVA5NSoihzWivuaIuPIdhKnDqftpHz9IE=; b=Ln7z23gREnZP3hYN4oWcFDSrYlOPUbf7gxgjLwNCkfin8aban9WL8aiCtYXK4MM7/S rfv9LBlr62MWTP2djq/GbgerkH3vQLvXLfwle3I1adbvWY8dz39LLKQFlA9MbLNVZh1H Mqqz8Sdxl1QCSz+cqWzyMo9FRDSfOUwyuHele7OjhX0v+z0t86eWKHjnsYN1gx2uX90M eVRErwCSPbiqj8I5VzpgDK0YE0ZFVuDXLerAynmBs7POHNcFNv4lTLEhbcsFEUM8W9K9 6LR4FAqxQ7SYtdPFG/93nIf1DFB3mVWN456Jcp5QkGjDgakPcyWYR/n8rqlIuE0JpKXP OJ1Q== X-Gm-Message-State: ALyK8tIuPk2EHGSBdeZj3B17jvvxUIYA7S1wtm0VuatqHBgXpWuHLkpC9+slT8Ck3MJpNg== X-Received: by 10.46.9.215 with SMTP id 206mr5962207ljj.63.1467813570140; Wed, 06 Jul 2016 06:59:30 -0700 (PDT) Received: from [10.0.0.100] (088156132194.dynamic-ww-04.vectranet.pl. [88.156.132.194]) by smtp.googlemail.com with ESMTPSA id l79sm4145052lfi.40.2016.07.06.06.59.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jul 2016 06:59:28 -0700 (PDT) To: Yaron Sheffer , IETF Security Directorate , The IESG , draft-ietf-dhc-topo-conf.all@tools.ietf.org, "Bernie Volz (volz)" References: <5751B895.1070400@gmail.com> <5751D4E6.6000709@gmail.com> <575344A7.30002@gmail.com> <504107ae-7f75-3ba7-afbd-7ed1f104f0b4@gmail.com> From: Tomek Mrugalski X-Enigmail-Draft-Status: N1110 Message-ID: <577D0EBC.2070800@gmail.com> Date: Wed, 6 Jul 2016 15:59:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <504107ae-7f75-3ba7-afbd-7ed1f104f0b4@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-dhc-topo-conf-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 13:59:34 -0000 Hi Yaron, I have not heard back from you whether the proposed text is satisfactory for you. If I don't hear anything back, I'll upload the text as -09 on Friday (which is the submission deadline). One other thing pointed out was that the reference to RFC7610 (DHCPv6 guard) was indirect (topo-conf referenced rfc3315bis that references 7610), so I will add a direct reference: Many attacks based on rogue DHCPv6 servers can be mitigated by deploying DHCPv6-Shield mechanism described in RFC7610. Tomek On 22.06.2016 13:38, Tomek Mrugalski wrote: > Hi Yaron, > > Thanks again for your review. I came up with a proposed text for the > security considerations text. There's not much left from the original > text, so here's the whole proposed section: > > 10. Security Considerations > > This document explains existing practice with respect to the use of > Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host > Configuration Protocol Version 6 [RFC3315]. The security > considerations for these protocols are described in their > specifications and in related documents that extend these protocols.= > > The mechanisms described in this document could possibly be exploite= d > by an attacker to misrepresent its point of attachment in the > network. This would cause the server to assign addresses, prefixes > and other configuration options, which can be considered a leak of > information. In particular, this could be used a preliminary stage > of attack, when the DHCP server leaks information about available > services in networks that attacker does not have access to. > > There are several ways how such an attack can be prevented. First, > it seems to be a common practice to filter out DHCP traffic coming i= n > from outside of the network and one that is directed to clients > outside of the network. Second, the DHCP servers can be configured > to not respond to traffic that is coming from unknown (i.e. those > subnets the server is not configured to serve) subnets. Third, some= > relays provide the ability to reject messages that do not fit > expected characteristics. For example CMTS (Cable Modem Termination= > System) acting as a DHCP relay detects if the MAC address specified > in chaddr in incoming DHCP messages matches the MAC address of the > cable modem it came from and can alter its behavior accordingly. > Also, relay agents and servers that are connected to clients directl= y > can reject traffic that looks as if it has passed a relay (this coul= d > indicate the client is attempting to spoof a relay, possibly to > inject forged relay options). > > There are a number of general DHCP recommendations that should be > considered in all DHCP deployments. While not strictly related to > the mechanisms described in this document, they may be useful in > certain deployment scenarios. [RFC7819] and [RFC7824] provide an > analysis of privacy problems in DHCPv4 and DHCPv6, respectively. If= > those are of concern, [RFC7844] offers mitigation steps. > > Current DHCPv4 and DHCPv6 standards lack strong cryptographic > protection. There is an ongoing effort in DHC working group to > address this. [I-D.ietf-dhc-sedhcpv6] attempts to provide mechanism= > for strong authentication and encryption between DHCPv6 clients and > servers. [I-D.volz-dhc-relay-server-security] attempts to improve > security of exchanges between DHCP relay agents and servers. > > Finally, there is an ongoing effort to update DHCPv6 specification, > that is currently 13 years old. Sections 23 (Security > Considerations) and 24 (Privacy Considerations) of > [I-D.ietf-dhc-rfc3315bis] contain more recent analysis of the > security and privacy considerations. > > If you prefer to see the whole document, the unpublished -09 is > available here: > https://github.com/tomaszmrugalski/ietf-topo-conf/blob/master/draft-iet= f-dhc-topo-conf-09.txt > > Let me know if the text addresses your comments. > > Thanks again for your thorough review. > > Tomek > From nobody Wed Jul 6 15:24:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3FC12D74C for ; Wed, 6 Jul 2016 15:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUe4f3T6V3Bi for ; Wed, 6 Jul 2016 15:24:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC7512D775 for ; Wed, 6 Jul 2016 15:24:41 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u66MObkN007770 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 7 Jul 2016 01:24:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u66MOa5G029597; Thu, 7 Jul 2016 01:24:36 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22397.34084.669354.335889@fireball.acr.fi> Date: Thu, 7 Jul 2016 01:24:36 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 22:24:45 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Ben Laurie is next in the rotation. For telechat 2016-07-07 Reviewer LC end Draft Dan Harkins T 2016-07-07 draft-ietf-calext-availability-03 Chris Inacio T 2016-07-01 draft-ietf-trill-arp-optimization-06 Leif Johansson T 2016-07-01 draft-ietf-trill-tree-selection-05 Yaron Sheffer TR2016-07-01 draft-ietf-trill-channel-tunnel-10 Takeshi Takahashi TR2015-12-28 draft-ietf-hip-rfc5203-bis-10 Hannes Tschofenig T 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Tina TSOU TR2015-12-28 draft-ietf-hip-rfc5205-bis-09 Paul Wouters T 2016-06-17 draft-ietf-dnsop-dnssec-roadblock-avoidance-04 For telechat 2016-08-04 Tobias Gondrom T 2016-07-11 draft-sweet-rfc2910bis-08 Warren Kumari T 2016-07-29 draft-sweet-rfc2911bis-09 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Phillip Hallam-Baker 2016-07-21 draft-hardy-pdf-mime-02 Steve Hanna 2016-07-18 draft-holmberg-dispatch-rfc7315-updates-07 Jeffrey Hutzelman 2016-07-04 draft-ietf-sipcore-dns-dual-stack-06 Simon Josefsson 2016-07-13 draft-ietf-6lo-ethertype-request-01 Benjamin Kaduk 2016-07-11 draft-ietf-dnsop-maintain-ds-03 Charlie Kaufman 2016-07-08 draft-ietf-ice-dualstack-fairness-03 Scott Kelly 2016-07-08 draft-ietf-mmusic-mux-exclusive-08 Stephen Kent 2016-07-12 draft-ietf-nfsv4-scsi-layout-06 Watson Ladd 2016-07-20 draft-ietf-kitten-aes-cts-hmac-sha2-10 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-14 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-05 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 -- kivinen@iki.fi From nobody Wed Jul 6 18:39:50 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC2612D507; Wed, 6 Jul 2016 18:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-M6LfBwUHN1; Wed, 6 Jul 2016 18:39:43 -0700 (PDT) Received: from smtp11.infineon.com (smtp11.infineon.com [217.10.52.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FC1126579; Wed, 6 Jul 2016 18:39:42 -0700 (PDT) X-SBRS: None Received: from unknown (HELO mucxv002.muc.infineon.com) ([172.23.11.17]) by smtp11.infineon.com with ESMTP/TLS/AES256-GCM-SHA384; 07 Jul 2016 03:39:41 +0200 Received: from MUCSE609.infineon.com (unknown [172.23.7.110]) by mucxv002.muc.infineon.com (Postfix) with ESMTPS; Thu, 7 Jul 2016 03:39:40 +0200 (CEST) Received: from KLUSE612.infineon.com (172.28.156.138) by MUCSE609.infineon.com (172.23.7.110) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 7 Jul 2016 03:39:40 +0200 Received: from KLUSE610.infineon.com (172.28.156.137) by KLUSE612.infineon.com (172.28.156.138) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 7 Jul 2016 03:39:39 +0200 Received: from KLUSE610.infineon.com ([172.28.148.8]) by KLUSE610.infineon.com ([172.28.148.8]) with mapi id 15.00.1156.000; Thu, 7 Jul 2016 03:39:39 +0200 From: To: , , Thread-Topic: secdir review for draft-holmberg-dispatch-rfc7315-updates-07 Thread-Index: AQHR1+8cuqB1sCfCAE+GA8aRMX4gMaAMMLsw Date: Thu, 7 Jul 2016 01:39:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.23.8.247] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22436.004 x-tm-as-result: No--33.902700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [secdir] secdir review for draft-holmberg-dispatch-rfc7315-updates-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 01:39:45 -0000 SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncw0Kb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBi ZWluZyBwcm9jZXNzZWQgYnkgdGhlDQpJRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVu IHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQpzZWN1cml0eSBhcmVhIGRpcmVjdG9y cy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQNCnRoZXNlIGNv bW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpUaGlzIGRv Y3VtZW50IHVwZGF0ZXMgUkZDIDczMTUgYnkgY2hhbmdpbmcgcmVzdHJpY3Rpb25zIG9uIHdoZXJl DQpjZXJ0YWluIFNJUCBwcml2YXRlIGhlYWRlciBleHRlbnNpb25zIG1heSBiZSBpbmNsdWRlZCwg aW4gb3JkZXIgdG8NCmFkZHJlc3MgbmV3IDNHUFAgdXNlIGNhc2VzLg0KDQpUaGlzIGRvY3VtZW50 IGlzIFJlYWR5IHdpdGggbml0cy4NCg0KSSBrbm93IGxpdHRsZSBhYm91dCBTSVAgb3IgM0dQUC4g SSBkbyBrbm93IHNlY3VyaXR5LCB0aG91Z2guDQoNCkFmdGVyIHJlYWRpbmcgdGhpcyBkb2N1bWVu dCBhbmQgYWxzbyByZWFkaW5nIHRoZSBTZWN1cml0eQ0KQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBv ZiBSRkMgNzMxNSwgSSBiZWxpZXZlIHRoYXQgdGhpcyBkb2N1bWVudA0KaXMgT0sgZnJvbSBhIHNl Y3VyaXR5IHN0YW5kcG9pbnQuIEZldyBuZXcgc2VjdXJpdHkgaXNzdWVzIGFyZQ0KcmFpc2VkIGJ5 IHRoaXMgZG9jdW1lbnQgYW5kIHRob3NlIHRoYXQgYXJpc2UgYXJlIHByb3Blcmx5DQpkb2N1bWVu dGVkIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIHRoaXMNCmRvY3Vt ZW50LiBIb3dldmVyLCB0aGVyZSBhcmUgYSBmZXcgdHlwb3MgaW4gdGhlIFNlY3VyaXR5DQpDb25z aWRlcmF0aW9ucyBzZWN0aW9uLg0KDQoqIFRoZSBzZWNvbmQgc2VudGVuY2Ugb2YgdGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24NCiAgIGVuZHMgd2l0aCAidGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGFuZCBhc3N1bXB0aW9ucyAoZS5nLg0KICAgcmVnYXJkaW5nIG9ubHkgc2Vu ZGluZyBpbmZvcm1hdGlvbiB0byB0cnVzdGVkIGVudGl0aWVzKSBhbHNvDQogICB0byB0aG9zZSBt ZXNzYWdlcy4iIFRoaXMgY2xhdXNlIGlzIG1pc3NpbmcgYSB2ZXJiLiBNYXliZSB0aGUNCiAgIHdv cmQgImFwcGx5IiBzaG91bGQgYXBwZWFyIGJlZm9yZSAidG8gdGhvc2UgbWVzc2FnZXMiLiBBbHNv LA0KICAgZ3JlYXRlciBjbGFyaXR5IGNvdWxkIGJlIGFjaGlldmVkIGJ5IGNoYW5naW5nICJ0aGUg c2VjdXJpdHkNCiAgIGNvbnNpZGVyYXRpb25zIGFuZCBhc3N1bXB0aW9ucyIgaW4gdGhhdCBzZW50 ZW5jZSBmcmFnbWVudCB0bw0KICAgInRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgYXNz dW1wdGlvbnMgZGVzY3JpYmVkIGluDQogICBSRkMgNzMxNSIuDQoNCiogSW4gdGhlIHRoaXJkIHNl bnRlbmNlIG9mIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLA0KICAgImRpc2Fs bG93IiBzaG91bGQgYmUgImRpc2FsbG93cyIgYW5kICJtZXNzYWdlIiBzaG91bGQgYmUNCiAgICJt ZXNzYWdlcyIuDQoNCiogSW4gdGhlIGZvdXJ0aCBzZW50ZW5jZSBvZiB0aGUgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgc2VjdGlvbiwNCiAgICJpZiBhIGhlYWRlciBmaWVsZCBvY2N1ciIgc2hvdWxk IGJlICJpZiBhIGhlYWRlciBmaWVsZCBvY2N1cnMiLg0KDQpXaXRoIHRoZXNlIG1pbm9yIGNoYW5n ZXMsIEkgdGhpbmsgdGhlIGRvY3VtZW50IHdpbGwgYmUgcmVhZHkNCnRvIGdvIGZyb20gYSBzZWN1 cml0eSBzdGFuZHBvaW50Lg0KDQpUaGFua3MsDQoNClN0ZXZlDQoNCg== From nobody Wed Jul 6 21:12:18 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0A712D1D8; Wed, 6 Jul 2016 21:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdA61mMF7y2t; Wed, 6 Jul 2016 21:12:11 -0700 (PDT) Received: from SNT004-OMC2S40.hotmail.com (snt004-omc2s40.hotmail.com [65.54.61.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77CAA12D0C3; Wed, 6 Jul 2016 21:12:11 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com ([65.55.90.71]) by SNT004-OMC2S40.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 6 Jul 2016 21:12:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=paz6pom1ktsbO1qEcI4p1jUkHi0WKKaW4wAl8ffGYtI=; b=Z36XzDYUYAesHBaTKINL01xRCEQwYbF+/swxjNK+XtatxoubR7vWBhJvThv+TI+wMdI4k+zbbN4dUYbYW4a0x7pHa+ZG2OJ9j9Gm+YAN0tzGmFuZGO51sQRumZEnZdSeXT/QGSeFh6lwCk2asPDTe2kR0q0v9q//eVyr1JWHNcHvYQrTs+ChRsMfMN5TnsHfZpXLtXsUM0LiT/HYkgqq+2K1ZB6wsWAOA0DuBYBw6Cl+JvSED5tBnnFm0ftHB6Q+7WXr0ItJrhSKfd0EhtDDGAw0kAueYToNfK1uRH7Ws6RI62RpU3hLRz5QEZn8kE64OBKJRCzGYLiEjEmmleeLOw== Received: from SN1NAM01FT043.eop-nam01.prod.protection.outlook.com (10.152.64.52) by SN1NAM01HT193.eop-nam01.prod.protection.outlook.com (10.152.65.173) with Microsoft SMTP Server (TLS) id 15.1.523.9; Thu, 7 Jul 2016 04:12:09 +0000 Received: from CY1PR17MB0425.namprd17.prod.outlook.com (10.152.64.57) by SN1NAM01FT043.mail.protection.outlook.com (10.152.65.216) with Microsoft SMTP Server (TLS) id 15.1.523.9 via Frontend Transport; Thu, 7 Jul 2016 04:12:09 +0000 Received: from CY1PR17MB0425.namprd17.prod.outlook.com ([10.163.253.19]) by CY1PR17MB0425.namprd17.prod.outlook.com ([10.163.253.19]) with mapi id 15.01.0528.024; Thu, 7 Jul 2016 04:12:09 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , 'The IESG' , "draft-ietf-ice-dualstack-fairness.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-ice-dualstack-fairness-03 Thread-Index: AQHR2AUWk4ql4+jlVEO1OZzBN30rgA== Date: Thu, 7 Jul 2016 04:12:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 25.152.64.57) smtp.mailfrom=outlook.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=outlook.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 25.152.64.57 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [4WfPlo6q0GyfRk+rxRLBbSWd/sDdA1X3] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:25.152.64.57; IPV:NLI; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM01HT193; H:CY1PR17MB0425.namprd17.prod.outlook.com; FPR:; SPF:None; CAT:NONE; LANG:en; CAT:NONE; x-ms-office365-filtering-correlation-id: d8fb2e61-a43f-4fba-1b29-08d3a61cdd8b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(5061506196)(5061507196)(1603103041)(1601125047); SRVR:SN1NAM01HT193; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SN1NAM01HT193; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT193; x-forefront-prvs: 0996D1900D Content-Type: multipart/alternative; boundary="_000_CY1PR17MB042523AE29B615686A832F68DF3B0CY1PR17MB0425namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 04:12:09.4227 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT193 X-OriginalArrivalTime: 07 Jul 2016 04:12:11.0024 (UTC) FILETIME=[BBF44900:01D1D805] Archived-At: Subject: [secdir] Secdir review of draft-ietf-ice-dualstack-fairness-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 04:12:14 -0000 --_000_CY1PR17MB042523AE29B615686A832F68DF3B0CY1PR17MB0425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. I don't believe this proposal raises any security concerns. It has a short = Security Considerations section containing information relevant to ICE but = not to this proposed modification. This document proposes a modification to RFC5245bis (which specifies a prot= ocol for NAT traversal). When trying to establish a connection through a NA= T, there are a number of different techniques that can be used, some of whi= ch will work and some of which will not work depending on the characteristi= cs of the NAT and other aspects of the environment. RFC5245 specifies an en= umeration of such techniques and specifies an order in which they should be= attempted. Apparently, there are problems in real world deployments where there are a = large number of possible NAT traversal techniques and checking them in the = order prescribed by RFC5245bis results in long delays and sometimes connect= ion failures based on timeouts. This document proposes changing the order i= n order to get better performance and reliability. It makes no other change= s to the protocol. Detailed review: I'm not an ICE expert, so some of these comments may be completely misguide= d. Take them for whatever they may be worth. I don't think "fairness" is the right term in this context. The goal is not= a fair division of resources between different clients or even any sort of= balance between use of IPv4 and IPv6. If many different connectivity mecha= nisms worked, the preferred mechanism would be (I assume) the one computed = using the formula in RFC5245bis. The problem is that checking all of the me= chanisms in order to too time consuming, and there is a desire to check (an= d settle on) techniques more likely to work ahead of techniques less likely= to work but more optimal if they do (in particular, checking some IPv4 bas= ed techniques before all of the IPv6 based techniques have been tried). Section 5 says: > ICE [I-D.ietf-ice-rfc5245bis] section 4.1.2.2 has guidelines for how > the type preference and local preference value should be chosen. > Instead of having a static local preference value for IPv4 and IPv6 > addresses, it is possible to choose this value dynamically in such a > way that IPv4 and IPv6 address candidate priorities end up > intermingled within the same candidate type. It is also possible to > assign lower priorities to IP addresses derived from unreliable > interfaces using the local preference value. This specification says what is possible, but it does not (as far as I coul= d see) specify any particular means of accomplishing it. If the intent of t= his RFC is to encourage people to experiment with different priority techni= ques, that's fair but the document should say so. If the intent is to encou= rage people to copy the design in ICE_dualstack_imp, then it's formula for = priority should be specified here in sufficient detail to implement it. Section 1 para 1 line 5: All interfaces and address types are known to the = application. Perhaps this was intended to say all interfaces and address ty= pes known by the application to be unreliable... Section 1 last paragraph and Section 5 third to last paragraph say: > The introduced fairness might be better, but not > worse than what exists today This is probably not true. There are probably unusual cases where this reor= dering will result in slightly increased connection times. I suspect what i= s meant is that "In almost all cases this change will result in connection = times at least as fast as those using the previous system, and in many case= s the benefit will be substantial." Typos: Section 1 para 1 line 5: arguable -> arguably Section 1 para 1 line 7: know -> known Section 1 para 2 line 7: describes -> describe Page 4 last para line 7: "too excessive" -> "not optimal" Section 7 end of third to last paragraph: missing "." [https://cid-ee6944db1998bb09.users.storage.live.com/users/0xee6944db1998bb= 09/myprofile/expressionprofile/profilephoto:UserTileMedium,UserTileStatic,U= serTileSmall/MeControlMediumUserTile?ck=3D1&ex=3D24&fofoff=3D1&sc=3D1467864= 372864] Reply all Sent from Outlook --_000_CY1PR17MB042523AE29B615686A832F68DF3B0CY1PR17MB0425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

I don't believe this proposal raises any security = concerns. It has a short Security Considerations section containing informa= tion relevant to ICE but not to this proposed modification.

This document proposes a modification to RFC5245bis (which specifies a prot= ocol for NAT traversal). When trying to establish a connection through a NA= T, there are a number of different techniques that can be used, some of whi= ch will work and some of which will not work depending on the characteristics of the NAT and other aspects of = the environment. RFC5245 specifies an enumeration of such techniques and sp= ecifies an order in which they should be attempted.

Apparently, there are problems in real world deployments where there are a = large number of possible NAT traversal techniques and checking them in the = order prescribed by RFC5245bis results in long delays and sometimes connect= ion failures based on timeouts. This document proposes changing the order in order to get better performan= ce and reliability. It makes no other changes to the protocol.

Detailed review:

I'm not an ICE expert, so some of these comments may be completely misguide= d. Take them for whatever they may be worth.

I don't think "fairness" is the right term in this context. The g= oal is not a fair division of resources between different clients or even a= ny sort of balance between use of IPv4 and IPv6. If many different connecti= vity mechanisms worked, the preferred mechanism would be (I assume) the one computed using the formula in RFC5245bis. The = problem is that checking all of the mechanisms in order to too time consumi= ng, and there is a desire to check (and settle on) techniques more likely t= o work ahead of techniques less likely to work but more optimal if they do (in particular, checking some I= Pv4 based techniques before all of the IPv6 based techniques have been trie= d).

Section 5 says:
> ICE [I-D.ietf-ice-rfc5245bis] section 4.1.2.2 has guidelines for how > the type preference and local preference value should be chosen.
> Instead of having a static local preference value for IPv4 and IPv6 > addresses, it is possible to choose this value dynamically in such a > way that IPv4 and IPv6 address candidate priorities end up
> intermingled within the same candidate type. It is also possible to > assign lower priorities to IP addresses derived from unreliable
> interfaces using the local preference value.

This specification says what is possible, but it does not (as far as I coul= d see) specify any particular means of accomplishing it. If the intent of t= his RFC is to encourage people to experiment with different priority techni= ques, that's fair but the document should say so. If the intent is to encourage people to copy the design in = ICE_dualstack_imp, then it's formula for priority should be specified here = in sufficient detail to implement it.

Section 1 para 1 line 5: All interfaces and address types are known to the = application. Perhaps this was intended to say all interfaces and address ty= pes known by the application to be unreliable...

Section 1 last paragraph and Section 5 third to last paragraph say:

> The introduced fairness might be better, but not
> worse than what exists today

This is probably not true. There are probably unusual cases where this reor= dering will result in slightly increased connection times. I suspect what i= s meant is that "In almost all cases this change will result in connec= tion times at least as fast as those using the previous system, and in many cases the benefit will be substanti= al."

Typos:

Section 1 para 1 line 5: arguable -> arguably
Section 1 para 1 line 7: know -> known
Section 1 para 2 line 7: describes -> describe
Page 4 last para line 7: "too excessive" -> "not optimal&= quot;
Section 7 end of third to last paragraph: missing "."


Sent from Outlook=

--_000_CY1PR17MB042523AE29B615686A832F68DF3B0CY1PR17MB0425namp_-- From nobody Thu Jul 7 19:56:44 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B8112B01C; Thu, 7 Jul 2016 19:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq7edB_brUup; Thu, 7 Jul 2016 19:56:41 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4048912B00D; Thu, 7 Jul 2016 19:56:41 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id f7so29529740vkb.3; Thu, 07 Jul 2016 19:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=vgHEgm/XxHa5yEU+4uWnuUqbUhDF69xVXbZNXs6WFPI=; b=lliooCLLwm4rBw/pqD9xGX6WrpDCZEx7vjq4d5vFvR6mRGdtAtGRzz4Z++BsWixcpW QYBoVXJdm2GPipbNI6GVNInwfR1HV/5MkzJ2MyneOYOtiDtjQXs0JU9FsZYVrf2kOCFl qqdu/iQ2xrmvcn/IfXXsp8nI7eZ3z9oWgIqzLHQ5syTHLpDvwtV7Jvc+18vKxbn9JFsR SBmhiqKNEUz8HLH/8EvdIgu0peQC42Z7wbKlhiXC8ESiJlWQLiAq1RwBPoOZLCAtlbtV LacdQU5MQk5vqHUoS7WXIIW+W0Yzs4lX5pguyVAQmYy7ioqmP1VEvSIud4n0EH63+vln wSPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vgHEgm/XxHa5yEU+4uWnuUqbUhDF69xVXbZNXs6WFPI=; b=TKecv9O8X9Unt/wgx+uy0iKxhrUnA6WkCkBmU6a+5J5t4Xw5Tj6IYMFYfqMCjnleOf aqKvn1H1+IDpC9BFCLc0uDHquKR9VgxwLFYGXAujMOd6+NDXUvfx5md6+nfJo677X+bq nEP01B06chubKyGuAoX2/mfvJzk9V6gRPDqTSYzYyanUChPfnUjzOqh344wQkYpc6Npx IJxCy15OYI4+IUOVKT4qLWQgg8EhkFvno/vqSrEsuVZR2ylBSL2yqbsvMiSFpL/LjuDu Pbt65wZOrl+F/kVED+yIYau8KrOKm5O/sXkba1H15ug/hGLtgCr4otOxz/YDKA1V+8qM Mz7A== X-Gm-Message-State: ALyK8tJbJeVnGEJA6U5VnkIxjTUfIj+G0dnOWgdgIWh+5qIc7Civ7SIz4z8rm4urSBDEWUF6BGxrD+58UEna5w== X-Received: by 10.159.33.201 with SMTP id 67mr1763358uac.90.1467946600260; Thu, 07 Jul 2016 19:56:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Thu, 7 Jul 2016 19:56:39 -0700 (PDT) From: Watson Ladd Date: Thu, 7 Jul 2016 19:56:39 -0700 Message-ID: To: draft-ietf-kitten-aes-cts-hmac-sha2.all@tools.ietf.org, "" , secdir@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Secdir review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 02:56:43 -0000 Dear all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I am not terribly happy with the state of this document: I don't think it is ready. Beyond the use of the verb "inputted", there are a number of forward references or discussion of bit representation of AES keys. I believe everyone knows what a bunch of 16 bytes as an AES key is, which makes me wonder why this is called out specifically. The use of 32768 as a default iteration count is buried below a layer of indirection. random-to-key is nowhere defined, despite RFC 3961 mandating it be defined. I think here it is supposed to be the identity. The cipher state is a forward reference. PBKDF2 on a human provided password with an iteration count of 32,768 is John The Ripper's breakfast. The security considerations section discusses the seriously pase rainbow table instead of GPUs for password cracking. A 16 byte random value is not a nonce. A nonce is only used once. The data maintaned in the RFC 3961 state is described as a "formal initialization vector". Formal meaning what? Well, it is known to an attacker ahead of the next encryption, and thus unsuited for use in CBC based modes, but never fear: we will make the first block of the plaintext random instead of using a properly random IV. This was chosen for "alignment with other Kerberos ciphers". This does not strike me as a terribly sound idea: it is not clear what the chaining value is doing, which suggests it has been asked to serve roles not clear to the auditor. It is an ugly solution to a self-inflicted calamity. Labels and contexts must not contain null bytes if we want to guarantee injectivity. This is not discussed anywhere I can see, and is essential to prevent keys being the same. I also question not using HKDF to derive keys: so long as we use only 1 key derivation mechanism with contexts ever, we can be reasonably sure that we haven't screwed up and created related keys. Using multiple KDFs is a great way to screw up, and passwords are the same across services, and are going to go through similar derivation mechanisms. The security consideration section states that truncated SHA384 to 192 bits has a security level of 192 bits. Why not truncate SHA256? Of course this security level is really the PRF distinguishing probability as a function of the number of evaluations: the actual security of the scheme is weaker due to including a collision term. What is this security level, if not numerology rooted in keysize? Sincerely, Watson From nobody Fri Jul 8 08:38:49 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143C312D0C9 for ; Fri, 8 Jul 2016 08:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOXi9LqDPa1S for ; Fri, 8 Jul 2016 08:38:45 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E9D12D096 for ; Fri, 8 Jul 2016 08:38:45 -0700 (PDT) Received: from [10.32.60.87] (142-254-101-201.dsl.dynamic.fusionbroadband.com [142.254.101.201]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u68FcgNR059172 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jul 2016 08:38:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-201.dsl.dynamic.fusionbroadband.com [142.254.101.201] claimed to be [10.32.60.87] From: "Paul Hoffman" To: "Watson Ladd" Date: Fri, 08 Jul 2016 08:38:42 -0700 Message-ID: In-Reply-To: References: MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: secdir@ietf.org Subject: Re: [secdir] Secdir review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:38:47 -0000 Which document is this a review of? --Paul Hoffman From nobody Fri Jul 8 09:00:04 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C12012D784 for ; Fri, 8 Jul 2016 09:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRYhIvhoqnAJ for ; Fri, 8 Jul 2016 09:00:00 -0700 (PDT) Received: from mail-vk0-x241.google.com (mail-vk0-x241.google.com [IPv6:2607:f8b0:400c:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521A612D1EA for ; Fri, 8 Jul 2016 09:00:00 -0700 (PDT) Received: by mail-vk0-x241.google.com with SMTP id v6so11131339vkb.1 for ; Fri, 08 Jul 2016 09:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7Y2U20Bz5GnZ8xk2NXWhlwgOaM+bMH1VOlRV8YivW+g=; b=tWklxByomk761+03+0E86EArSGWEyWcIXjhgnmSxx5oiSqTvHnLg6fhJdNBY0A4Fd1 goG1mN01nGe7etfRyXWkuhBEVIw0oqA0vVkcaGOOhQbHGOxFiM016kDX5L0NoVRs8SIf NsrfdBSVMIMcx+2DBP6OUIWtWqcu8iHyggkn4IwUb8OPU2aXuQffljL/dxtZCe1P6Ceb R0BPfNVuItc1Z4hRRVr+pMaVOZik+/1E4ND9UpNXj+qolmUbnBRu1I75J4KfhIbbQd6i 2W9jm9H46tN7X45fplhzrhysz4zWkeV7XUEJ3VvnscRvWXoWBD4SMH+h6z8fQc9jSEbg Phzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7Y2U20Bz5GnZ8xk2NXWhlwgOaM+bMH1VOlRV8YivW+g=; b=YZy7YhWh2DuQI771JcheOJaTbxpzVXES+mi0fSIF+IL21brTeCazDnYv6w7fu2KN3X 1hlk/b+tJdKAYPLDaoOSnIl6er2vh1cA91hFSpfVp4vCOHGqsRVFvr01AvrovZFKOnBd cAXD/nG+uJiFL7aAp307ECTIQzt67VFGCxGTU6NaffD5DsmW8LdAqHHR+ItNaPyEKI2z S5ed0KqA/77oIMg0a9/D5405mwiHWsQ5r5XgtqoaZcRT6gd0/upztFvL29DsUlGYF4Wm puTPvm2Dhwq8iKjSVH7SmDt+VHdwUewZG50YHW+iWmHNBegHCTKIhPgpXXJWCDcbfwwG yjvg== X-Gm-Message-State: ALyK8tIe++0QtxdpiP7JtkvwVMMp7MEIIHGnIvkUcZW/QNKaH0SuERaWBJ1W0QlESgkyPKTzN53NknNBCFy+iQ== MIME-Version: 1.0 X-Received: by 10.176.65.40 with SMTP id j37mr2467614uad.117.1467993599277; Fri, 08 Jul 2016 08:59:59 -0700 (PDT) Received: by 10.159.39.194 with HTTP; Fri, 8 Jul 2016 08:59:59 -0700 (PDT) Received: by 10.159.39.194 with HTTP; Fri, 8 Jul 2016 08:59:59 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jul 2016 08:59:59 -0700 Message-ID: From: Watson Ladd To: Paul Hoffman Content-Type: multipart/alternative; boundary=94eb2c122a9a04856f053721e52d Archived-At: Cc: secdir@ietf.org Subject: Re: [secdir] Secdir review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 16:00:02 -0000 --94eb2c122a9a04856f053721e52d Content-Type: text/plain; charset=UTF-8 draft-ietf-kitten-aes-cts-hmac-sha2 On Jul 8, 2016 8:38 AM, "Paul Hoffman" wrote: > > Which document is this a review of? > > --Paul Hoffman --94eb2c122a9a04856f053721e52d Content-Type: text/html; charset=UTF-8

draft-ietf-kitten-aes-cts-hmac-sha2
On Jul 8, 2016 8:38 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
>
> Which document is this a review of?
>
> --Paul Hoffman

--94eb2c122a9a04856f053721e52d-- From nobody Fri Jul 8 11:17:57 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED3712D81D; Fri, 8 Jul 2016 11:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm5il-8FjcAh; Fri, 8 Jul 2016 11:17:43 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1842212D77A; Fri, 8 Jul 2016 11:17:40 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id 82so43148788qko.3; Fri, 08 Jul 2016 11:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=YUve2rhySpQKVs4Dt1r4LU+UkXp/02gVSKr+kys0r88=; b=NWn6WpdMDDnoXvrmk1hgUjZPLTxax7FcN6OmjU4CVL9C5Sd5a/6ns4cTnzIptfy75K gU+IAmw19gvNhEOXrxI1rxcn1bCKuPcCBLINONDg2YiJJH3/FrsrTe23/h+j7jug8tYv uiBKgbThtKAQhld8jX8AKr3fKvo+hMgKNMP3i3RW7f+V+gJNwaFO2WXOBYsc5k+lX4iP 398WsVlKyGD98+0UD+ds+/wm/92F6n3/16jaojtOoxoioTlVsE2WsHpZskGPkZtQBumY TiuTPSvWlFaXei0+Ps8eMc5FR8fiEseJsBKRPvaqrNSm0CVGRnHVF8IF2a81fGIA3m/L NEoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=YUve2rhySpQKVs4Dt1r4LU+UkXp/02gVSKr+kys0r88=; b=brW59DDMx4S0O7fI4Axd1by+AmILscbSUy5gRoD4EmJoP+j1sIAbfQilgM6pKDLX+i xyMxcPAL/eM9b3IVHdw1eom8FHKSxD8J07msyEiDiN1t1bw77GZ829i8CKr7xCp+3+iS mmFlgtlEjqlMKlLnjVWT//OLewUFj2ifvXJq3BivVRlfPJn2G/2o5f+pZtheqjSI559J zZ+NYmCdvPEhG92XghKmyuDMrTfEpz7YjDTh9MgcgcFpx03eFij4y79n4lj9TlaLImoP pu+Ddci7/xGi7DSy2QSt4s6Diwqz5PK20ORtIKSLhB+Huw46kHaCu6u7BqvHuOnz0c+O vP2w== X-Gm-Message-State: ALyK8tIL9JfS+Fs0/8Mp3K2d0mYCqUIPJv3FuJzSYnYk4/ahzs0+Coc0AnaPf1C+j50+aonuVjl0czP1wMWxZA== X-Received: by 10.55.5.144 with SMTP id 138mr9487123qkf.196.1468001859216; Fri, 08 Jul 2016 11:17:39 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.16.106 with HTTP; Fri, 8 Jul 2016 11:17:38 -0700 (PDT) From: Phillip Hallam-Baker Date: Fri, 8 Jul 2016 14:17:38 -0400 X-Google-Sender-Auth: i2CsJdUjw-FW_DusJPI79mOQk_I Message-ID: To: draft-hardy-pdf-mime.all@tools.ietf.org, "secdir@ietf.org" , "iesg@ietf.org" , IETF Discussion Mailing List Content-Type: multipart/alternative; boundary=001a114c86ae592ac7053723d165 Archived-At: Subject: [secdir] SecDir Review of https://tools.ietf.org/html/draft-hardy-pdf-mime-02#page-8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:17:45 -0000 --001a114c86ae592ac7053723d165 Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The point of the draft is to create a MIME type for application/pdf. Which is long overdue. Which is why I would like to see some more comments in the security section. PDF is a document format that has a scripting language capability. And so this is something that needs to be discussed in quite a bit of detail. It is not apparent from reading the document if the scripting language is one that is safe or of the screaming heebijebies variety. In particular, I would like to know more about the extend of the ability to 'open files' on a machine. Is this read only or write capability? Is it possible to create a file that contains code? The document implies but this is an area where I would like to know exactly what is going on. In particular, the term 'privilege escalation' needs to be addressed. Obviously, the risk from reading other files is lower than the ability to create files which in turn is less serious than the ability to execute files. But even read access to certain files can have unexpected effects, particularly when the scripting language affords opportunities for a covert channel. For example, a file reads the root file system, pulls up the user's SSH private key file and exfiltrates it as the file name as an external link. Attacker has now root access to the machine. One of the reasons for tagging languages that contain scripting capabilities and in particular the ability to access other data files in a locale is so that malware filters can mitigate risk. This should be called out as one of the purposes of creating the identifier. Given the 'shoot yourself in the foot' opportunity that all scripting and macro type capabilities create, I would like to see MIME types allow a distinction to be made between documents that use these capabilities and those that do not. This would greatly assist in the use of end to end secure mail (OpenPGP, S/MIME) infrastructures as it allows a policy to make statements of the form 'you can send me encrypted Word, PDF, etc. but not if they contain Macros' PDF also has a signature capability which is relevant. If the Macros are signed by a trustworthy party, they are less of a concern than random Macros. --001a114c86ae592ac7053723d165 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


The point of the draft is to cr= eate a MIME type for application/pdf. Which is long overdue. Which is why I= would like to see some more comments in the security section.
<= br>
PDF is a document format that has a scripting language capa= bility. And so this is something that needs to be discussed in quite a bit = of detail. It is not apparent from reading the document if the scripting la= nguage is one that is safe or of the screaming heebijebies variety.<= /font>

In particular, I would like to know more about the exte= nd of the ability to 'open files' on a machine. Is this read only o= r write capability? Is it possible to create a file that contains code? The= document implies but this is an area where I would like to know exactly wh= at is going on.
=
In particular, the term 'pri= vilege escalation' needs to be addressed.

=
O= bviously, the risk from reading other files is lower than the ability to cr= eate files which in turn is less serious than the ability to execute files.= But even read access to certain files can have unexpected effects, particu= larly when the scripting language affords opportunities for a covert channe= l.=C2=A0

For example, a file reads the root file= system, pulls up the user's SSH private key file and exfiltrates it as= the file name as an external link. Attacker has now root access to the mac= hine.

One of the reasons for tagging languages t= hat contain scripting capabilities and in particular the ability to access = other data files in a locale is so that malware filters can mitigate risk. = This should be called out as one of the purposes of creating the identifier= .=C2=A0

Given the 'shoot yourself in the fo= ot' opportunity that all scripting and macro type capabilities create, = I would like to see MIME types allow a distinction to be made between docum= ents that use these capabilities and those that do not. This would greatly = assist in the use of end to end secure mail (OpenPGP, S/MIME) infrastructur= es as it allows a policy to make statements of the form 'you can send m= e encrypted Word, PDF, etc. but not if they contain Macros'
=
PDF also has a signature capability which is relevant. If t= he Macros are signed by a trustworthy party, they are less of a concern tha= n random Macros.


--001a114c86ae592ac7053723d165-- From nobody Fri Jul 8 11:27:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19ABB12D678; Fri, 8 Jul 2016 11:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODBep5tPqunY; Fri, 8 Jul 2016 11:27:08 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E48612D828; Fri, 8 Jul 2016 11:27:03 -0700 (PDT) X-AuditID: 12074425-207ff7000000206a-de-577ff075c429 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E8.79.08298.570FF775; Fri, 8 Jul 2016 14:27:02 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u68IR0Op023490; Fri, 8 Jul 2016 14:27:00 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u68IQumo015142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Jul 2016 14:26:59 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u68IQuUm012924; Fri, 8 Jul 2016 14:26:56 -0400 (EDT) Date: Fri, 8 Jul 2016 14:26:56 -0400 (EDT) From: Benjamin Kaduk To: Watson Ladd In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrFv2oT7cYNlTMYvX1+ayW8z4M5HZ 4sPChywWPZ0n2RxYPHbOusvusWTJTyaPL5c/swUwR3HZpKTmZJalFunbJXBlfNnxk7XggH3F vKfbWBoYpxl3MXJySAiYSMw78puli5GLQ0igjUni7N6tjBDOBkaJhcf7mCGcg0wSk78sYe9i 5ABy6iWerJIC6WYR0JJY/qCLHcRmE1CRmPlmIxuILSKgLjFh+SYWEJtZoFzi4YnpYK3CAv4S X49GgIQ5BQIl5rUeB2vlFXCQ2DZ7ESOILSQQIPGnqw9sjKiAjsTq/VNYIGoEJU7OfAI1Emjt 9G0sExgFZiFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83s0QvNaV0EyMoWNld VHcwzvnrdYhRgINRiYc34kJ9uBBrYllxZe4hRkkOJiVR3n3PgEJ8SfkplRmJxRnxRaU5qcWH GCU4mJVEeAXfAOV4UxIrq1KL8mFS0hwsSuK8jAwMDEIC6YklqdmpqQWpRTBZGQ4OJQle5vdA jYJFqempFWmZOSUIaSYOTpDhPEDD34HU8BYXJOYWZ6ZD5E8xKkqJ834ASQiAJDJK8+B6wclk N5PqK0ZxoFeEea++A6riASYiuO5XQIOZgAYbBIANLklESEk1MCr/XPZS4Of+CS4pkax+uu5+ cd+7Fr8Me/A3v3+poBPr4cOyjSyVpY2zjP2U2+4tcdqzsUz1h9Dq/qyVfx6tdX436Wjyh7ly F3fkikzMXKgw2bpJZN+ftvyWK8vb4mxWPlEqr3FpFb3i6BozUX26Rl7KyvVXXRe8FN2vdre7 6s27g+xWZ3ZOFFZiKc5INNRiLipOBAC3ScaSAQMAAA== Archived-At: Cc: draft-ietf-kitten-aes-cts-hmac-sha2.all@tools.ietf.org, "" , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-kitten-aes-cts-hmac-sha2-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:27:13 -0000 [putting the draft name in the subject line, though I am just guessing about the -10 part] On Thu, 7 Jul 2016, Watson Ladd wrote: > Dear all, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I am not terribly happy with the state of this document: I don't think > it is ready. Beyond the use of the verb "inputted", there are a number > of forward references or discussion of bit representation of AES keys. > I believe everyone knows what a bunch of 16 bytes as an AES key is, > which makes me wonder why this is called out specifically. The use of It's called out specifically because this document is (for better or for worse) mirroring some parts of the structure of RFC 3962. It would probably be fine to remove it, but neither does it seem like it really matters. > 32768 as a default iteration count is buried below a layer of > indirection. I've lost you on that one (the indented algorithm has the default inline), but I'm sure the authors would be happy to look at wording suggestions. > random-to-key is nowhere defined, despite RFC 3961 mandating it be > defined. I think here it is supposed to be the identity. The cipher > state is a forward reference. Section 5 has: random-to-key function: identity function That there is such a function is part of the Kerberos background knowledge that the reader is assumed to have, and the details of it are not relevant in the earlier occurrences; it's just a sigil for the type change from bit string to protocol key. > PBKDF2 on a human provided password with an iteration count of 32,768 > is John The Ripper's breakfast. The security considerations section > discusses the seriously pase rainbow table instead of GPUs for > password cracking. Do you recommend a different number? Myself, I think that the iteration count is not terribly important, and that switching to a PAKE-based preauthentication scheme that does not expose the password-derived key on the wire should be a higher priority than mucking around in individual encryption type specifications. The current state of password-derived keys for Kerberos is kind of lousy, but this document is mostly just intended to be an incremental improvement in the hash function; we have draft-mccallum-kitten-krb-spake-preauth-00 in the works to provide the long-term fix. Do you think that GPUs possess some magical property that excludes them from being covered by "password guess attempts"? Yes, they are faster, but ... computers are always getting faster. > A 16 byte random value is not a nonce. A nonce is only used once. The ... huh? I assume you are referring to Section 5, "[t]he plaintext is prepended with a 16-octet random nonce generated by the message originator, known as a confounder.", and am not sure what word you would rather be used to describe the confounder. > data maintaned in the RFC 3961 state is described as a "formal > initialization vector". Formal meaning what? Well, it is known to an > attacker ahead of the next encryption, and thus unsuited for use in > CBC based modes, but never fear: we will make the first block of the > plaintext random instead of using a properly random IV. This was > chosen for "alignment with other Kerberos ciphers". This does not > strike me as a terribly sound idea: it is not clear what the chaining > value is doing, which suggests it has been asked to serve roles not > clear to the auditor. It is an ugly solution to a self-inflicted > calamity. Fortunately, the RFC 3961 cipher state is mostly unused in practice. Nevertheless, it is part of the protocol, and an RFC 3961 enctype has to specify *something* for it. You seem to be mixing several comments/objections together in that paragraph; hopefully I can separate them all. With regard to "formal", are you suggesting to just remove the word? I do not think that doing so would cause harm to the document. Then there's something about chaining from one encryption to another, though I'm not sure I am really following your point. I wasn't around at the time, but I assume in the early days of kerberos someone thought it would be clever to extend CBC chaining across encryption flows. It wasn't, but we haven't gotten rid of that part of the protocol yet, so we do (basically) the same thing that every other enctype does. Finally, there's a concern about using a random IV versus a random confounder as the first block of plaintext. This was extensively discussed by the WG (the original proposal was even to use a random IV), https://www.ietf.org/mail-archive/web/kitten/current/msg04348.html is perhaps a useful entrypoint to the archive. Basically, the belief is that there is no difference in confidentiality and integrity protection between the two, and so there is a tradeoff between an extra block to en/decrypt and exposing the RNG output to passive observers. This is the direction the WG landed in, though if you want to re-raise the issue during IETF last-call, that's your prerogative. But if you do, please provide a clear argument instead of vague allusions to alleged best-practice. > Labels and contexts must not contain null bytes if we want to > guarantee injectivity. This is not discussed anywhere I can see, and That's a fair point, and it should probably be mentioned. Unfortunately, the label is going to include the kerberos key usage number, which starts with a few nul bytes [see the test vectors]. Kerberos key usage numbers are maintained in a registry (not yet under IANA control) and are encoded as unsigned 32-bit integers. > is essential to prevent keys being the same. I also question not using > HKDF to derive keys: so long as we use only 1 key derivation mechanism > with contexts ever, we can be reasonably sure that we haven't screwed > up and created related keys. Using multiple KDFs is a great way to > screw up, and passwords are the same across services, and are going to > go through similar derivation mechanisms. That argument seemes to apply to any protocol wishing to perform key derivation. I am not aware of any IETF consensus document that indicates we should prefer one over the other, and do not see why this document is an appropriate forum in which to have such a debate. Is there something particular this document that would make HKDF more appropriate for it than SP800-108? Do note that there are multiple implementations of the protocol in -10 that are ready to ship, so to me there is an extra barrier to making a breaking change at this stage of the document lifecycle. > The security consideration section states that truncated SHA384 to > 192 bits has a security level of 192 bits. Why not truncate SHA256? Of At risk of being trite, box-ticking auditors want to see SHA384. > course this security level is really the PRF distinguishing > probability as a function of the number of evaluations: the actual > security of the scheme is weaker due to including a collision term. > What is this security level, if not numerology rooted in keysize? To some extent, it is just numerology, yes, but the main intent of that statement is to remind people to ignore the "256" in "aes256" and use the "192" in "sha384-192" for their numerology. Other considerations will weaken things slightly, but if we did our job correctly, only slightly. If you have suggestions for ways to phrase that sentiment that do not have the failings you identify, we would be happy to see them. See also, uh, https://www.ietf.org/mail-archive/web/kitten/current/msg04275.html or thereabouts; there is supposedly some Suite B preference for sha384 at the 192-bit level of security, and this document is intended to support a Suite B profile for Kerberos. -Ben From nobody Fri Jul 8 11:51:51 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DCB12D5F4; Fri, 8 Jul 2016 11:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKxpc_UpAj7i; Fri, 8 Jul 2016 11:51:29 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C362A12D59E; Fri, 8 Jul 2016 11:51:29 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bLas0-000Ouf-VK; Fri, 08 Jul 2016 14:51:24 -0400 Date: Fri, 08 Jul 2016 14:51:19 -0400 From: John C Klensin To: Phillip Hallam-Baker Message-ID: <646056D5A75C4C2DCF5CE7FF@JcK-HP8200> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: draft-hardy-pdf-mime.all@tools.ietf.org, IETF Discussion Mailing List , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir Review of https://tools.ietf.org/html/draft-hardy-pdf-mime-02#page-8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:51:31 -0000 Hi. One comment about the introduction to this review that I think may be important enough to justify at least rethinking the review. A few comments below apply to the document more generally. --On Friday, July 08, 2016 14:17 -0400 Phillip Hallam-Baker wrote: > I have reviewed this document as part of the security > directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written > primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just > like any other last call comments. > > > The point of the draft is to create a MIME type for > application/pdf. Which is long overdue. Independent of any other comments here, application/pdf was described and registered as a Media Type (MIME type) in RFF 3778 over a dozen years ago, in May 2004. The new I-D explicitly says that it updates the definition provided by RFC 3778 and Obsoletes that document (it doesn't include it among its references, which seems odd to me). > Which is why I would like to see some more comments in the > security section. > > PDF is a document format that has a scripting language > capability. And so this is something that needs to be > discussed in quite a bit of detail. It is not apparent from > reading the document if the scripting language is one that is > safe or of the screaming heebijebies variety. Curiously, 3778 contains a rather extensive discussion on that point. I have no idea whether it is still current, but "obsoleting" 3778 in a way that loses, rather than including or updating, significant information would be, at best, unfortunate. Appendix A says "The Security Considerations were updated to match current status", but discarding all of the information about scripting seems like much more than that. It is also my understanding that some of the subsets do not allow embedded scripting. If that is correct, it should certainly be mentioned. Given that at least one of the authors of the current I-D is also an author of 3778, the omission of the discussion about scripting cannot be a surprise. Other that some words about new features being added in a way that causes old viewers to "fail gracefully", it is not clear how the current ISO version of PDf compares to the Adobe version defined in 3772. If the difference is significant, then a new media type, not reuse of an old one, is required. Even if it is not that significant, it appears to me (as a co-author of RFC 6838) that there is a strong case to be made for parameters that identify versions and/or specific subsets to help applications to identify viewers or processors that will not fail. The authors may have good reasons to not include either parameter, but it seems to me that the I-D should then explain why not. thanks, john From nobody Fri Jul 8 11:57:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23BD12D620; Fri, 8 Jul 2016 11:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbEn9EvMCCc7; Fri, 8 Jul 2016 11:57:34 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF5812D59E; Fri, 8 Jul 2016 11:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4454; q=dns/txt; s=iport; t=1468004254; x=1469213854; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KpUdb+BLHtNLpnYYJICcPzyYl476vLfQqzndjwmjeww=; b=fmlX1zUNvzb2sLJJX88qcqzadeAM4Wq8oxr1NeFn7JRRxJCBgdsxdXdy R8KTLtDf9oO1+JyIhhcKCcWoW5kQ9JYbPcR2KRLxDdfCeheoKWwDOqYNQ vEfle4DZgiUOMvdxK764PD3nUvavRtPXjkViU/F/TcrHmSr8oSiKZ3luE A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQAr939X/5hdJa1bgz5WfAasd4wVg?= =?us-ascii?q?XskhXQCgSg4FAEBAQEBAQFlJ4RMAQEFOjoRBAIBCBEEAQEBHgkHIREUCQgCBAE?= =?us-ascii?q?SCIgOAxcOuW8NhBsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYp0gkOBUBEBBkKFL?= =?us-ascii?q?wWYYDQBhguGL4INgXGNQoZagUCHcwEeNoIJHIFMbgGHfDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,331,1464652800"; d="scan'208";a="294607502" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2016 18:57:33 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u68IvXIL017312 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jul 2016 18:57:33 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 8 Jul 2016 13:57:32 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Fri, 8 Jul 2016 13:57:32 -0500 From: "Bernie Volz (volz)" To: Suresh Krishnan , Tomek Mrugalski , Yaron Sheffer , "IETF Security Directorate" , The IESG , "draft-ietf-dhc-topo-conf.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-dhc-topo-conf-08 Thread-Index: AQHRvqYM69lblI6d7UyJqU61VCq4X6APF5Xw Date: Fri, 8 Jul 2016 18:57:32 +0000 Message-ID: References: <5751B895.1070400@gmail.com> <5751D4E6.6000709@gmail.com> <575344A7.30002@gmail.com> <504107ae-7f75-3ba7-afbd-7ed1f104f0b4@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-dhc-topo-conf-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:57:37 -0000 Hi Suresh: In case you missed it (perhaps Tomek sent you email), but Tomek did publish= the 09 with the revised security considerations text ... So if you can mov= e this document forward, would be great! - Bernie -----Original Message----- From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]=20 Sent: Wednesday, June 29, 2016 7:55 PM To: Tomek Mrugalski ; Yaron Sheffer ; IETF Security Directorate ; The IESG ; draft-ietf-dhc-topo-conf.all@tools.ietf.org Subject: Re: SecDir review of draft-ietf-dhc-topo-conf-08 Hi Yaron, Any thoughts on this new text? Does this address your concerns? Thanks Suresh On 06/22/2016 07:37 AM, Tomek Mrugalski wrote: > Hi Yaron, > > Thanks again for your review. I came up with a proposed text for the > security considerations text. There's not much left from the original > text, so here's the whole proposed section: > > 10. Security Considerations > > This document explains existing practice with respect to the use of > Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host > Configuration Protocol Version 6 [RFC3315]. The security > considerations for these protocols are described in their > specifications and in related documents that extend these protocols. > > The mechanisms described in this document could possibly be exploited > by an attacker to misrepresent its point of attachment in the > network. This would cause the server to assign addresses, prefixes > and other configuration options, which can be considered a leak of > information. In particular, this could be used a preliminary stage > of attack, when the DHCP server leaks information about available > services in networks that attacker does not have access to. > > There are several ways how such an attack can be prevented. First, > it seems to be a common practice to filter out DHCP traffic coming in > from outside of the network and one that is directed to clients > outside of the network. Second, the DHCP servers can be configured > to not respond to traffic that is coming from unknown (i.e. those > subnets the server is not configured to serve) subnets. Third, some > relays provide the ability to reject messages that do not fit > expected characteristics. For example CMTS (Cable Modem Termination > System) acting as a DHCP relay detects if the MAC address specified > in chaddr in incoming DHCP messages matches the MAC address of the > cable modem it came from and can alter its behavior accordingly. > Also, relay agents and servers that are connected to clients directly > can reject traffic that looks as if it has passed a relay (this could > indicate the client is attempting to spoof a relay, possibly to > inject forged relay options). > > There are a number of general DHCP recommendations that should be > considered in all DHCP deployments. While not strictly related to > the mechanisms described in this document, they may be useful in > certain deployment scenarios. [RFC7819] and [RFC7824] provide an > analysis of privacy problems in DHCPv4 and DHCPv6, respectively. If > those are of concern, [RFC7844] offers mitigation steps. > > Current DHCPv4 and DHCPv6 standards lack strong cryptographic > protection. There is an ongoing effort in DHC working group to > address this. [I-D.ietf-dhc-sedhcpv6] attempts to provide mechanism > for strong authentication and encryption between DHCPv6 clients and > servers. [I-D.volz-dhc-relay-server-security] attempts to improve > security of exchanges between DHCP relay agents and servers. > > Finally, there is an ongoing effort to update DHCPv6 specification, > that is currently 13 years old. Sections 23 (Security > Considerations) and 24 (Privacy Considerations) of > [I-D.ietf-dhc-rfc3315bis] contain more recent analysis of the > security and privacy considerations. > > If you prefer to see the whole document, the unpublished -09 is > available here: > https://github.com/tomaszmrugalski/ietf-topo-conf/blob/master/draft-ietf-= dhc-topo-conf-09.txt > > Let me know if the text addresses your comments. > > Thanks again for your thorough review. > > Tomek > > From nobody Fri Jul 8 12:41:37 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D131127058; Fri, 8 Jul 2016 12:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuHmV08n_39C; Fri, 8 Jul 2016 12:41:27 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EDFE12D0BD; Fri, 8 Jul 2016 12:41:27 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-ed-578001a36fbd Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 36.A9.03614.3A100875; Fri, 8 Jul 2016 21:40:19 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0294.000; Fri, 8 Jul 2016 15:41:25 -0400 From: Suresh Krishnan To: "yaronf.ietf@gmail.com" , "iesg@ietf.org" , "volz@cisco.com" , "tomasz.mrugalski@gmail.com" , "secdir@ietf.org" , "draft-ietf-dhc-topo-conf.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-dhc-topo-conf-08 Thread-Index: AQHRvboHXmaXobDEYkKp6QMo3tFpbKAPXMMA///JNcM= Date: Fri, 8 Jul 2016 19:41:24 +0000 Message-ID: References: <5751B895.1070400@gmail.com> <5751D4E6.6000709@gmail.com> <575344A7.30002@gmail.com> <504107ae-7f75-3ba7-afbd-7ed1f104f0b4@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E87B771635882B4BA20096B589152EF643D59BFFeusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyuXRPlO5ixoZwg1m3tCz2dp9itpjxZyKz xYeFD1ks9l9bwGSxfIamxar7M9gd2Dym/N7I6rFz1l12jyVLfjJ5fLn8mS2AJYrLJiU1J7Ms tUjfLoErY+PK62wFl9Iq9i75z9jAuDKsi5GTQ0LAROLPxhnMELaYxIV769m6GLk4hASOMkrM O/CeCcJZxiix72QPI0gVG1DHhp2fwRIiAnuYJK7d/wfkcHAIC1hKPJ6QB1IjImAl0Xd6CjuM Pf3bASYQm0VARWL/o0Vgc3gFfCW+zv7IDLFgApPEq4ndrCAJTgFXifl7V4I1MAKd9P3UGjCb WUBc4taT+UwQpwpILNlzHupsUYmXj/+xQtTkS5za9o4NYoGgxMmZT1gmMArPQtI+C0nZLCRl EHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxQU5uupHhJkZgjB2TYHPcwbi31/MQ owAHoxIPr8Kr+nAh1sSy4srcQ4wSHMxKIrwf/gGFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8+q/ VAwXEkhPLEnNTk0tSC2CyTJxcEo1MGqnZjO4rFXc/umWvLHZPe77y5n2vvraV6CzedWNs613 71r+CLie9lSmbtX97LU/g8QV43qOn2VS1bpcYVT1LeadLwub/7TOLxfdp+6XEWd3r5vec1dO rHqnTud2zXvRFkvPKadrz+m/vtKl8HZjOnvqMcaWOfd9FQzl5/7yC5jyokUt6ftjAyWW4oxE Qy3mouJEAA/A65utAgAA Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-dhc-topo-conf-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:41:31 -0000 --_000_E87B771635882B4BA20096B589152EF643D59BFFeusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bernie, Yep. I saw the 09 draft got published this afternoon and I will be moving i= t along the process. Thanks Suresh -----Original Message----- From: Bernie Volz (volz) [volz@cisco.com] Received: Friday, 08 Jul 2016, 2:57PM To: Suresh Krishnan [suresh.krishnan@ericsson.com]; Tomek Mrugalski [tomasz= .mrugalski@gmail.com]; Yaron Sheffer [yaronf.ietf@gmail.com]; IETF Security= Directorate [secdir@ietf.org]; The IESG [iesg@ietf.org]; draft-ietf-dhc-to= po-conf.all@tools.ietf.org [draft-ietf-dhc-topo-conf.all@tools.ietf.org] Subject: RE: SecDir review of draft-ietf-dhc-topo-conf-08 Hi Suresh: In case you missed it (perhaps Tomek sent you email), but Tomek did publish= the 09 with the revised security considerations text ... So if you can mov= e this document forward, would be great! - Bernie -----Original Message----- From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] Sent: Wednesday, June 29, 2016 7:55 PM To: Tomek Mrugalski ; Yaron Sheffer ; IETF Security Directorate ; The IESG ; draft-ietf-dhc-topo-conf.all@tools.ietf.org Subject: Re: SecDir review of draft-ietf-dhc-topo-conf-08 Hi Yaron, Any thoughts on this new text? Does this address your concerns? Thanks Suresh On 06/22/2016 07:37 AM, Tomek Mrugalski wrote: > Hi Yaron, > > Thanks again for your review. I came up with a proposed text for the > security considerations text. There's not much left from the original > text, so here's the whole proposed section: > > 10. Security Considerations > > This document explains existing practice with respect to the use of > Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host > Configuration Protocol Version 6 [RFC3315]. The security > considerations for these protocols are described in their > specifications and in related documents that extend these protocols. > > The mechanisms described in this document could possibly be exploited > by an attacker to misrepresent its point of attachment in the > network. This would cause the server to assign addresses, prefixes > and other configuration options, which can be considered a leak of > information. In particular, this could be used a preliminary stage > of attack, when the DHCP server leaks information about available > services in networks that attacker does not have access to. > > There are several ways how such an attack can be prevented. First, > it seems to be a common practice to filter out DHCP traffic coming in > from outside of the network and one that is directed to clients > outside of the network. Second, the DHCP servers can be configured > to not respond to traffic that is coming from unknown (i.e. those > subnets the server is not configured to serve) subnets. Third, some > relays provide the ability to reject messages that do not fit > expected characteristics. For example CMTS (Cable Modem Termination > System) acting as a DHCP relay detects if the MAC address specified > in chaddr in incoming DHCP messages matches the MAC address of the > cable modem it came from and can alter its behavior accordingly. > Also, relay agents and servers that are connected to clients directly > can reject traffic that looks as if it has passed a relay (this could > indicate the client is attempting to spoof a relay, possibly to > inject forged relay options). > > There are a number of general DHCP recommendations that should be > considered in all DHCP deployments. While not strictly related to > the mechanisms described in this document, they may be useful in > certain deployment scenarios. [RFC7819] and [RFC7824] provide an > analysis of privacy problems in DHCPv4 and DHCPv6, respectively. If > those are of concern, [RFC7844] offers mitigation steps. > > Current DHCPv4 and DHCPv6 standards lack strong cryptographic > protection. There is an ongoing effort in DHC working group to > address this. [I-D.ietf-dhc-sedhcpv6] attempts to provide mechanism > for strong authentication and encryption between DHCPv6 clients and > servers. [I-D.volz-dhc-relay-server-security] attempts to improve > security of exchanges between DHCP relay agents and servers. > > Finally, there is an ongoing effort to update DHCPv6 specification, > that is currently 13 years old. Sections 23 (Security > Considerations) and 24 (Privacy Considerations) of > [I-D.ietf-dhc-rfc3315bis] contain more recent analysis of the > security and privacy considerations. > > If you prefer to see the whole document, the unpublished -09 is > available here: > https://github.com/tomaszmrugalski/ietf-topo-conf/blob/master/draft-ietf-= dhc-topo-conf-09.txt > > Let me know if the text addresses your comments. > > Thanks again for your thorough review. > > Tomek > > --_000_E87B771635882B4BA20096B589152EF643D59BFFeusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Bernie,
Yep. I saw the 09 draft got published this afternoon and I will be moving i= t along the process.

Thanks
Suresh

-----Original Message-----
From: Bernie Volz (volz) [volz@cisco.com]
Received: Friday, 08 Jul 2016, 2:57PM
To: Suresh Krishnan [suresh.krishnan@ericsson.com]; Tomek Mrugalski = [tomasz.mrugalski@gmail.com]; Yaron Sheffer [yaronf.ietf@gmail.com]; IETF S= ecurity Directorate [secdir@ietf.org]; The IESG [iesg@ietf.org]; draft-ietf= -dhc-topo-conf.all@tools.ietf.org [draft-ietf-dhc-topo-conf.all@tools.ietf.org]
Subject: RE: SecDir review of draft-ietf-dhc-topo-conf-08

Hi Suresh:

In case you missed it (perhaps Tomek sent you email), but Tomek did publish= the 09 with the revised security considerations text ... So if you can mov= e this document forward, would be great!

- Bernie

-----Original Message-----
From: Suresh Krishnan [mail= to:suresh.krishnan@ericsson.com]
Sent: Wednesday, June 29, 2016 7:55 PM
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>; Yaron Sheffer <y= aronf.ietf@gmail.com>; IETF Security Directorate <secdir@ietf.org>= ; The IESG <iesg@ietf.org>; draft-ietf-dhc-topo-conf.all@tools.ietf.o= rg
Subject: Re: SecDir review of draft-ietf-dhc-topo-conf-08

Hi Yaron,
   Any thoughts on this new text? Does this address your concerns= ?

Thanks
Suresh

On 06/22/2016 07:37 AM, Tomek Mrugalski wrote:
> Hi Yaron,
>
> Thanks again for your review. I came up with a proposed text for the > security considerations text. There's not much left from the original<= br> > text, so here's the whole proposed section:
>
> 10.  Security Considerations
>
>     This document explains existing practice with = respect to the use of
>     Dynamic Host Configuration Protocol [RFC2131] = and Dynamic Host
>     Configuration Protocol Version 6 [RFC3315].&nb= sp; The security
>     considerations for these protocols are describ= ed in their
>     specifications and in related documents that e= xtend these protocols.
>
>     The mechanisms described in this document coul= d possibly be exploited
>     by an attacker to misrepresent its point of at= tachment in the
>     network.  This would cause the server to = assign addresses, prefixes
>     and other configuration options, which can be = considered a leak of
>     information.  In particular, this could b= e used a preliminary stage
>     of attack, when the DHCP server leaks informat= ion about available
>     services in networks that attacker does not ha= ve access to.
>
>     There are several ways how such an attack can = be prevented.  First,
>     it seems to be a common practice to filter out= DHCP traffic coming in
>     from outside of the network and one that is di= rected to clients
>     outside of the network.  Second, the DHCP= servers can be configured
>     to not respond to traffic that is coming from = unknown (i.e. those
>     subnets the server is not configured to serve)= subnets.  Third, some
>     relays provide the ability to reject messages = that do not fit
>     expected characteristics.  For example CM= TS (Cable Modem Termination
>     System) acting as a DHCP relay detects if the = MAC address specified
>     in chaddr in incoming DHCP messages matches th= e MAC address of the
>     cable modem it came from and can alter its beh= avior accordingly.
>     Also, relay agents and servers that are connec= ted to clients directly
>     can reject traffic that looks as if it has pas= sed a relay (this could
>     indicate the client is attempting to spoof a r= elay, possibly to
>     inject forged relay options).
>
>     There are a number of general DHCP recommendat= ions that should be
>     considered in all DHCP deployments.  Whil= e not strictly related to
>     the mechanisms described in this document, the= y may be useful in
>     certain deployment scenarios.  [RFC7819] = and [RFC7824] provide an
>     analysis of privacy problems in DHCPv4 and DHC= Pv6, respectively.  If
>     those are of concern, [RFC7844] offers mitigat= ion steps.
>
>     Current DHCPv4 and DHCPv6 standards lack stron= g cryptographic
>     protection.  There is an ongoing effort i= n DHC working group to
>     address this.  [I-D.ietf-dhc-sedhcpv6] at= tempts to provide mechanism
>     for strong authentication and encryption betwe= en DHCPv6 clients and
>     servers.  [I-D.volz-dhc-relay-server-secu= rity] attempts to improve
>     security of exchanges between DHCP relay agent= s and servers.
>
>     Finally, there is an ongoing effort to update = DHCPv6 specification,
>     that is currently 13 years old.  Sections= 23 (Security
>     Considerations) and 24 (Privacy Considerations= ) of
>     [I-D.ietf-dhc-rfc3315bis] contain more recent = analysis of the
>     security and privacy considerations.
>
> If you prefer to see the whole document, the unpublished -09 is
> available here:
> https://github.com/tomaszmrugalski/ietf-topo-conf/blob/master/draft-ietf-dh= c-topo-conf-09.txt
>
> Let me know if the text addresses your comments.
>
> Thanks again for your thorough review.
>
> Tomek
>
>

 --_000_E87B771635882B4BA20096B589152EF643D59BFFeusaamb107erics_-- From nobody Fri Jul 8 12:59:46 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3BC12B04F for ; Fri, 8 Jul 2016 12:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNWH_OoMhMZd for ; Fri, 8 Jul 2016 12:59:44 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081DC12B019 for ; Fri, 8 Jul 2016 12:59:43 -0700 (PDT) Received: from [10.32.60.87] (142-254-101-201.dsl.dynamic.fusionbroadband.com [142.254.101.201]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u68Jxg39071752 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Jul 2016 12:59:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-201.dsl.dynamic.fusionbroadband.com [142.254.101.201] claimed to be [10.32.60.87] From: "Paul Hoffman" To: secdir Date: Fri, 08 Jul 2016 12:59:41 -0700 Message-ID: <2E8E7C18-FC83-4040-9DA2-E24CA7DE571A@vpnc.org> References: <093274DA-857D-46FA-94D8-3110D8D41E85@icann.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: [secdir] Fwd: [96attendees] Invitation to "Upcoming ZSK and KSK Changes to the Root Zone" on Tuesday, 19 June, in Berlin X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:59:46 -0000 Greetings. These security-related presentations are happening during our SecDir lunch because the IAB thought that the Tuesday lunch slot was best (maybe because there is no ISOC lunch talk this time). For SecDir, I'll do a 10-minute-or-less overview of what is being presented and can answer any questions. FWIW, if you were at RIPE 72, these are almost exactly the same presentations, so you aren't missing anything. --Paul Hoffman Forwarded message: > From: Matt Larson > To: 96attendees@ietf.org <96attendees@ietf.org> > Subject: [96attendees] Invitation to "Upcoming ZSK and KSK Changes to > the Root Zone" on Tuesday, 19 June, in Berlin > Date: Fri, 8 Jul 2016 19:45:03 +0000 > > Dear IETF colleagues, > > I'd like to invite anyone interested in DNSSEC in the root zone to a > session on "Upcoming ZSK and KSK Changes to the Root Zone" on Tuesday, > 19 June, from 1230-1345 in the Bellevue Room in the InterContinental > Hotel. ICANN and Verisign, as IANA Functions Operator and Root Zone > Manager, respectively, are cooperating on two projects that are > changing aspects of DNSSEC operation in the root zone: the root zone > ZSK is increasing in size from 1024 bits to 2048 > bits > and the root zone KSK will be > changing. Duane > Wessels from Verisign and I will talk about the plans and answer any > questions. > > Because of the critical nature of the root zone and the significance > of these changes, Verisign and ICANN are making a number of > presentations to increase awareness. We approached the IAB about a > presentation in Berlin and they suggested this lunchtime slot. We'd > like to thank the IAB and the Secretariat for graciously offering a > room. > > Thanks and see you in Berlin, > > Matt > -- > Matt Larson > VP of Research > Office of the CTO, ICANN > From nobody Fri Jul 8 13:39:13 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D741F12D523; Fri, 8 Jul 2016 13:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0S2hffqADY8; Fri, 8 Jul 2016 13:39:09 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F48C12D119; Fri, 8 Jul 2016 13:39:08 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-48-578004afa65f Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 78.5C.09012.FA400875; Fri, 8 Jul 2016 21:53:19 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0294.000; Fri, 8 Jul 2016 16:39:05 -0400 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-metadata-19.txt Thread-Index: AQHR2VfZzKtSkmbskEiZlmBanQ1qwKAO/abA Date: Fri, 8 Jul 2016 20:39:04 +0000 Message-ID: References: <20160708203203.32205.90541.idtracker@ietfa.amsl.com> In-Reply-To: <20160708203203.32205.90541.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUyuXRPrO56loZwgycfxSymn/nLaHH0sYTF /M7T7BZPZ/9htbj66jOLxfPd9hYz/kxktnhx/SOzxcL1a5ktXp1aw2jRsDPf4vvFDmaL3qYl zBYfFj5ksZi+9xq7xfsL51gcBDzOHlnA6DHl90ZWjy9PXjJ5rO2+yuaxc9Zddo/HPWfYPFqO vGX1WD7tKKPHkiU/mTxaPi5k9Zi18wmLx5fLn9kCeKK4bFJSczLLUov07RK4MmYdzyg4KFdx 8dEJtgbGW+JdjJwcEgImEs23jzJC2GISF+6tZ+ti5OIQEjjKKHHvdRsLSEJIYBmjxMLtlSA2 m4CWxOOvf5m6GDk4RASUJX4ecgSpZxZYyCrxfdIBdpAaYQF7iYcnzrGC2CICDhKftpyGso0k 5vf8YwPpZRFQkbi60BkkzCvgK/Hpay8jxCpHiR27/oKVcwo4SbzYvJoZxGYEuu37qTVMIDaz gLjErSfzmSBuFpBYsuc8M4QtKvHy8T9WCFtRYl//dHaIeh2JBbs/sUHY2hLLFr5mhtgrKHFy 5hOWCYxis5CMnYWkZRaSlllIWhYwsqxi5CgtLsjJTTcy2MQITAXHJNh0dzDen+55iFGAg1GJ h1fhVX24EGtiWXFl7iFGCQ5mJRFebt6GcCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Yo8Uw4UE 0hNLUrNTUwtSi2CyTBycUg2MAXNCMj9zGj3bdjJw33VHsTsRzhHT9DNabkrpa5V8W7pC94LT 8SvWs+uPGM1IMJd+l8zYW+HvPpmFf7XJ5AkXVrT0vVT3LfHIcg59aLmuSMdafVtoWnOyxUZz vpQK4/qD1+Mnd1qXKpv9OOBU5xZuaPfxh2NdbNR2xau7H3+oySsMf/XZcZISS3FGoqEWc1Fx IgB2pOvhAQMAAA== Archived-At: Cc: Gunter Van De Velde , "ops-dir@ietf.org" , Ben Campbell , Alissa Cooper , "gen-art@ietf.org" , "secdir@ietf.org" , "ops-ads@tools.ietf.org" , joel jaeggli , Meral Shirazipour , Kathleen Moriarty , Mirja Kuehlewind , The IESG , Benoit Claise , Sheng Jiang Subject: Re: [secdir] [CDNi] I-D Action: draft-ietf-cdni-metadata-19.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 20:39:12 -0000 Hi All, (As and author) I am still working through the last of the IESG comments,= but I wanted to post an update before the draft deadline. This update should address all of the opsdir, secdir, and genart comments= , as well as all of the DISCUSSes and most of the non-DISCUSS comments. Still todo are: - Address the general cleanup comments from Stephen Farrell and Ben Campb= ell, including link loop prevention - Close on comments from Alissa Cooper Two changes in the updated version for which I think we need to feedback = from the WG: 1. I removed the Auth Type registry. After thinking about it some more= , my rationale is this: we changed all metadata objects to have a ptype, an= d the Auth object is a metadata object, so it has to have a ptype, and sinc= e there's already a registry for ptypes, the Auth Type registry is just a d= uplicate registry where we say that the already registered metadata object = is an Auth object. This seems really redundant since the spec will be the = same in both registries. (Note: This was not the case before we switched t= o the ptype registry.) So, I think removing the Auth Type registry is simp= ler and cleaner, unless anyone disagrees? 2. I was cleaning up the "versioning" text and realized that the ptype = of structural metadata is not necessarily explicitly listed in the json res= ponses, unless they are linked. The example in 6.10 uses links, but embedd= ing would also be valid? I think we could either make links mandatory for = structural metadata, or require that all structural metadata always be vers= ioned together, though I'm open to other thoughts on this. thanx! -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, July 08, 2016 4:32 PM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-19.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Content Delivery Networks Interconnectio= n > of the IETF. >=20 > Title : CDN Interconnection Metadata > Authors : Ben Niven-Jenkins > Rob Murray > Matt Caulfield > Kevin J. Ma > Filename : draft-ietf-cdni-metadata-19.txt > Pages : 63 > Date : 2016-07-08 >=20 > Abstract: > The Content Delivery Networks Interconnection (CDNI) metadata > interface enables interconnected Content Delivery Networks (CDNs) to > exchange content distribution metadata in order to enable content > acquisition and delivery. The CDNI metadata associated with a piece > of content provides a downstream CDN with sufficient information for > the downstream CDN to service content requests on behalf of an > upstream CDN. This document describes both a base set of CDNI > metadata and the protocol for exchanging that metadata. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cdni-metadata-19 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-metadata-19 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Sat Jul 9 09:03:02 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C16412D58C; Sat, 9 Jul 2016 09:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMVy2DP1V4q4; Sat, 9 Jul 2016 09:02:58 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BAF912B005; Sat, 9 Jul 2016 09:02:58 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id o63so7593115vkg.1; Sat, 09 Jul 2016 09:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rF6oJI/heBrhegk8RLeQlqDWRnvOaFtAkBjJVgnSwKg=; b=uZVTysD2zc8qsSHWE7IELEf/Jr38D+nZZU3Glgsrc/W4gyXLC0A3kvJQQ52wmTaeI7 LZ91I3KCmon6PPwfyICanukWV+QDVY+3Z+/fTkhpdP6Qo21vFay3aCQb4BhwZmyC+GLs 2YBm37IXzw6a0LheY+IzO+ueodnRmrdT77aJvb9vcLRpCUY6dbtu92eNawfzprgC++gF MZUJY5LbT+isoZoH/kG3Fvx7Pp14dWDdqZ4fs70f3tL53zmOSO/J4pfskyWBqzdeZmsN 8AxBJkwq8iv/KUH+5NHmS5UMnIBdAYYHxPy0bMSj7Jfj9H94pRNmcdZl3wk4MXfFM69o dbsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rF6oJI/heBrhegk8RLeQlqDWRnvOaFtAkBjJVgnSwKg=; b=GfXIQ+pSGfbVjUKDU7TE3QHVl40xdDG5g0WT/Pvgz7dChG3sa0AszQ4Ytahg9DlBsy 3T1aH0D7v1/uPsnHIxgSLdSKGTW1hZOtKoxXZihABIXI3gn7vDvlDMf6BRQSfA9SrD4C yAviUcnIvI5BdX3T6UytmZhTC5VOgtHtwHSr/8/nzt7JLXPpROFJkjGUdEuJvpBHf8+A Z93U4ss1cxOvkjIrW3fpGFqElEs2pebAd1EOrXFf5R0WWFaFxJgFcW/8kz7OKGMk5W4m zwbliVtOoXIcWfXKIupN1+9XtJGbt6rfl+inbos4ONrAv+Kn7tZlHhU5ujyuoEN8PAkN Ax8Q== X-Gm-Message-State: ALyK8tKQHxkjLJo+r7oQSHVu6w/UU7qA5DMt9LYJJwoAAysb2RjWTX7cVApSxEfWmYE8XGBNziolHB9gFl4XGw== X-Received: by 10.159.33.201 with SMTP id 67mr5502223uac.90.1468080176928; Sat, 09 Jul 2016 09:02:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Sat, 9 Jul 2016 09:02:56 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Sat, 9 Jul 2016 09:02:56 -0700 Message-ID: To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-kitten-aes-cts-hmac-sha2.all@tools.ietf.org, "" , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-kitten-aes-cts-hmac-sha2-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 16:03:01 -0000 On Fri, Jul 8, 2016 at 11:26 AM, Benjamin Kaduk wrote: > [putting the draft name in the subject line, though I am just guessing > about the -10 part] > > On Thu, 7 Jul 2016, Watson Ladd wrote: > >> Dear all, >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> I am not terribly happy with the state of this document: I don't think >> it is ready. Beyond the use of the verb "inputted", there are a number >> of forward references or discussion of bit representation of AES keys. >> I believe everyone knows what a bunch of 16 bytes as an AES key is, >> which makes me wonder why this is called out specifically. The use of > > It's called out specifically because this document is (for better or for > worse) mirroring some parts of the structure of RFC 3962. It would > probably be fine to remove it, but neither does it seem like it really > matters. > >> 32768 as a default iteration count is buried below a layer of >> indirection. > > I've lost you on that one (the indented algorithm has the default inline), > but I'm sure the authors would be happy to look at wording suggestions. The code shows the parameter is an iteration count, but the text doesn't indicate this clearly. > >> random-to-key is nowhere defined, despite RFC 3961 mandating it be >> defined. I think here it is supposed to be the identity. The cipher >> state is a forward reference. > > Section 5 has: > random-to-key function: identity function > > That there is such a function is part of the Kerberos background knowledge > that the reader is assumed to have, and the details of it are not relevant > in the earlier occurrences; it's just a sigil for the type change from bit > string to protocol key. > >> PBKDF2 on a human provided password with an iteration count of 32,768 >> is John The Ripper's breakfast. The security considerations section >> discusses the seriously pase rainbow table instead of GPUs for >> password cracking. > > Do you recommend a different number? Myself, I think that the iteration > count is not terribly important, and that switching to a PAKE-based > preauthentication scheme that does not expose the password-derived key on > the wire should be a higher priority than mucking around in individual > encryption type specifications. The current state of password-derived > keys for Kerberos is kind of lousy, but this document is mostly just > intended to be an incremental improvement in the hash function; we have > draft-mccallum-kitten-krb-spake-preauth-00 in the works to provide the > long-term fix. I think using scrypt is a much better idea to reduce the number of guesses. > > Do you think that GPUs possess some magical property that excludes them > from being covered by "password guess attempts"? Yes, they are faster, > but ... computers are always getting faster. How about some actual thought about how many guesses GPUs actually produce, today, and how large password dictionaries can be that informs the correct number? There is lots of evidence of the form "we dumped 10 million passwords, and this is how many the world could crack", and the decisions about defaults need to take this into account. It's not enough to say "oh, people can guess passwords". > >> A 16 byte random value is not a nonce. A nonce is only used once. The > > ... huh? I assume you are referring to Section 5, "[t]he plaintext > is prepended with a 16-octet random nonce generated by the message > originator, known as a confounder.", and am not sure what word you would > rather be used to describe the confounder. > >> data maintaned in the RFC 3961 state is described as a "formal >> initialization vector". Formal meaning what? Well, it is known to an >> attacker ahead of the next encryption, and thus unsuited for use in >> CBC based modes, but never fear: we will make the first block of the >> plaintext random instead of using a properly random IV. This was >> chosen for "alignment with other Kerberos ciphers". This does not >> strike me as a terribly sound idea: it is not clear what the chaining >> value is doing, which suggests it has been asked to serve roles not >> clear to the auditor. It is an ugly solution to a self-inflicted >> calamity. > > Fortunately, the RFC 3961 cipher state is mostly unused in practice. > Nevertheless, it is part of the protocol, and an RFC 3961 enctype has to > specify *something* for it. How about a 0 byte string? > > You seem to be mixing several comments/objections together in that > paragraph; hopefully I can separate them all. > > With regard to "formal", are you suggesting to just remove the word? I do > not think that doing so would cause harm to the document. > > Then there's something about chaining from one encryption to another, > though I'm not sure I am really following your point. I wasn't around at > the time, but I assume in the early days of kerberos someone thought it > would be clever to extend CBC chaining across encryption flows. It > wasn't, but we haven't gotten rid of that part of the protocol yet, so we > do (basically) the same thing that every other enctype does. This document defines a new way to encrypt, no? It can change this detail. Nothing says you can't make it a useless argument. > > Finally, there's a concern about using a random IV versus a random > confounder as the first block of plaintext. This was extensively > discussed by the WG (the original proposal was even to use a random IV), > https://www.ietf.org/mail-archive/web/kitten/current/msg04348.html is > perhaps a useful entrypoint to the archive. Basically, the belief is that > there is no difference in confidentiality and integrity protection between > the two, and so there is a tradeoff between an extra block to en/decrypt > and exposing the RNG output to passive observers. This is the direction > the WG landed in, though if you want to re-raise the issue during IETF > last-call, that's your prerogative. But if you do, please provide a clear > argument instead of vague allusions to alleged best-practice. So you believe that AES is indistinguishable from random, but don't believe in random number generators? That's a pretty interesting pair of beliefs to hold. Of course the excuse offered is that the RNG might be corrupted: but the random data is exposed to clients, who can go ahead and mount the attack. The fact is that right now understanding why the protocol is secure requires looking at the details of CTS. If the IV had been properly chosen as random, this wouldn't be required; it would be enough to know that CTS is a secure IV based mode. This is a much better state of affairs. Encrypt the chained value and use the result as an IV, and drop the random data used as a "nonce", and it's just as efficient in block cipher calls, and doesn't depend on details of CTS, and doesn't expose random data. > >> Labels and contexts must not contain null bytes if we want to >> guarantee injectivity. This is not discussed anywhere I can see, and > > That's a fair point, and it should probably be mentioned. Unfortunately, > the label is going to include the kerberos key usage number, which starts > with a few nul bytes [see the test vectors]. Kerberos key usage numbers > are maintained in a registry (not yet under IANA control) and are encoded > as unsigned 32-bit integers. Yeah, so we need to make sure the encoding is injective. There will be some ugly details involved in figuring out if this is the case. Maybe length-prefixing each part? > >> is essential to prevent keys being the same. I also question not using >> HKDF to derive keys: so long as we use only 1 key derivation mechanism >> with contexts ever, we can be reasonably sure that we haven't screwed >> up and created related keys. Using multiple KDFs is a great way to >> screw up, and passwords are the same across services, and are going to >> go through similar derivation mechanisms. > > That argument seemes to apply to any protocol wishing to perform key > derivation. I am not aware of any IETF consensus document that indicates > we should prefer one over the other, and do not see why this document is > an appropriate forum in which to have such a debate. Is there something > particular this document that would make HKDF more appropriate for it than > SP800-108? Do note that there are multiple implementations of the > protocol in -10 that are ready to ship, so to me there is an extra barrier > to making a breaking change at this stage of the document lifecycle. We should just use HDKF everywhere instead of yet another "concatenate this here, put that there" scheme. The problem is that any system where the user uses the same password needs to have its scheme compared to this one, and I am not volunteering. > >> The security consideration section states that truncated SHA384 to >> 192 bits has a security level of 192 bits. Why not truncate SHA256? Of > > At risk of being trite, box-ticking auditors want to see SHA384. > >> course this security level is really the PRF distinguishing >> probability as a function of the number of evaluations: the actual >> security of the scheme is weaker due to including a collision term. >> What is this security level, if not numerology rooted in keysize? > > To some extent, it is just numerology, yes, but the main intent of that > statement is to remind people to ignore the "256" in "aes256" and use the > "192" in "sha384-192" for their numerology. Other considerations will > weaken things slightly, but if we did our job correctly, only slightly. > If you have suggestions for ways to phrase that sentiment that do not have > the failings you identify, we would be happy to see them. > > See also, uh, > https://www.ietf.org/mail-archive/web/kitten/current/msg04275.html or > thereabouts; there is supposedly some Suite B preference for sha384 at the > 192-bit level of security, and this document is intended to support a > Suite B profile for Kerberos. The collision resistance of the hash function is irrelevant to HMAC security, but whatever: the DOD wants it. > > -Ben -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun Jul 10 13:16:55 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE73A12D0D9; Sun, 10 Jul 2016 13:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.685 X-Spam-Level: X-Spam-Status: No, score=-14.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, URI_HEX=1.122, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clsyg8ZO8oQ6; Sun, 10 Jul 2016 13:16:44 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE0712D0D3; Sun, 10 Jul 2016 13:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13391; q=dns/txt; s=iport; t=1468181803; x=1469391403; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J1hdhNqjCDmzkHQf24gCHcw8SA7NyOW4HkgQNS0ZX4A=; b=bPg/8WrFOcPojRKqz76056tAXNQ7jvdCHdKdH9ACJMFvJMadC1XuEiAA WthT+Bu/MI52WuOFD1JChp9eMAi/32L/CWuB+tAzllk4Z8RR1btK2lRsz hUzSi9C6s3ETWRJ19r3U6lDTqYHGt7sInXnEaK6zJ6YyMbBnRjV+tRH0I 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiBwAfrIJX/5NdJa1XBoF3eU5WfKdij?= =?us-ascii?q?DGFBIF6H4UvRQMCAoEfOBQBAQEBAQEBZSeEXQEEAQ4ZPgYOBQsCAQg/BzIUEQI?= =?us-ascii?q?EDgWIFgMPCA65fgMVhBABAQEBAQEBAQEBAQEBAQEBAQEBAQEchieBeAiCTYQtB?= =?us-ascii?q?oM6gi8FjAeNEQGGDIJ6hUuPLIgdFYdcAR42ggkcgUxuAQGHK4FDAQEB?= X-IronPort-AV: E=Sophos;i="5.28,343,1464652800"; d="scan'208,217";a="295944906" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2016 20:16:42 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u6AKGgDd002739 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 10 Jul 2016 20:16:42 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 10 Jul 2016 16:16:41 -0400 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1210.000; Sun, 10 Jul 2016 16:16:41 -0400 From: "Pal Martinsen (palmarti)" To: Charlie Kaufman Thread-Topic: Secdir review of draft-ietf-ice-dualstack-fairness-03 Thread-Index: AQHR2AUWk4ql4+jlVEO1OZzBN30rgKASH+d7 Date: Sun, 10 Jul 2016 20:16:41 +0000 Message-ID: <68B1A3ED-519C-4BE4-8319-59857846E2F4@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_68B1A3ED519C4BE4831959857846E2F4ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ice-dualstack-fairness.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ice-dualstack-fairness-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 20:16:47 -0000 --_000_68B1A3ED519C4BE4831959857846E2F4ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the thorough review. Due to paternity leave there will be a slig= ht delay fixing the issues. Will attend to this early August. P?l-Erik Sent from my iPhone On 07 Jul 2016, at 06:39, Charlie Kaufman > wrote: I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. I don't believe this proposal raises any security concerns. It has a short = Security Considerations section containing information relevant to ICE but = not to this proposed modification. This document proposes a modification to RFC5245bis (which specifies a prot= ocol for NAT traversal). When trying to establish a connection through a NA= T, there are a number of different techniques that can be used, some of whi= ch will work and some of which will not work depending on the characteristi= cs of the NAT and other aspects of the environment. RFC5245 specifies an en= umeration of such techniques and specifies an order in which they should be= attempted. Apparently, there are problems in real world deployments where there are a = large number of possible NAT traversal techniques and checking them in the = order prescribed by RFC5245bis results in long delays and sometimes connect= ion failures based on timeouts. This document proposes changing the order i= n order to get better performance and reliability. It makes no other change= s to the protocol. Detailed review: I'm not an ICE expert, so some of these comments may be completely misguide= d. Take them for whatever they may be worth. I don't think "fairness" is the right term in this context. The goal is not= a fair division of resources between different clients or even any sort of= balance between use of IPv4 and IPv6. If many different connectivity mecha= nisms worked, the preferred mechanism would be (I assume) the one computed = using the formula in RFC5245bis. The problem is that checking all of the me= chanisms in order to too time consuming, and there is a desire to check (an= d settle on) techniques more likely to work ahead of techniques less likely= to work but more optimal if they do (in particular, checking some IPv4 bas= ed techniques before all of the IPv6 based techniques have been tried). Section 5 says: > ICE [I-D.ietf-ice-rfc5245bis] section 4.1.2.2 has guidelines for how > the type preference and local preference value should be chosen. > Instead of having a static local preference value for IPv4 and IPv6 > addresses, it is possible to choose this value dynamically in such a > way that IPv4 and IPv6 address candidate priorities end up > intermingled within the same candidate type. It is also possible to > assign lower priorities to IP addresses derived from unreliable > interfaces using the local preference value. This specification says what is possible, but it does not (as far as I coul= d see) specify any particular means of accomplishing it. If the intent of t= his RFC is to encourage people to experiment with different priority techni= ques, that's fair but the document should say so. If the intent is to encou= rage people to copy the design in ICE_dualstack_imp, then it's formula for = priority should be specified here in sufficient detail to implement it. Section 1 para 1 line 5: All interfaces and address types are known to the = application. Perhaps this was intended to say all interfaces and address ty= pes known by the application to be unreliable... Section 1 last paragraph and Section 5 third to last paragraph say: > The introduced fairness might be better, but not > worse than what exists today This is probably not true. There are probably unusual cases where this reor= dering will result in slightly increased connection times. I suspect what i= s meant is that "In almost all cases this change will result in connection = times at least as fast as those using the previous system, and in many case= s the benefit will be substantial." Typos: Section 1 para 1 line 5: arguable -> arguably Section 1 para 1 line 7: know -> known Section 1 para 2 line 7: describes -> describe Page 4 last para line 7: "too excessive" -> "not optimal" Section 7 end of third to last paragraph: missing "." [https://cid-ee6944db1998bb09.users.storage.live.com/users/0xee6944db1998bb= 09/myprofile/expressionprofile/profilephoto:UserTileMedium,UserTileStatic,U= serTileSmall/MeControlMediumUserTile?ck=3D1&ex=3D24&fofoff=3D1&sc=3D1467864= 372864] Reply all Sent from Outlook --_000_68B1A3ED519C4BE4831959857846E2F4ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks for the thorough review. Due to paternity leave there will be a= slight delay fixing the issues. Will attend to this early August.

Pål-Erik
Sent from my iPhone

On 07 Jul 2016, at 06:39, Charlie Kaufman <charliekaufman@outlook.com> wrote:

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

I don't believe this proposal raises any security = concerns. It has a short Security Considerations section containing informa= tion relevant to ICE but not to this proposed modification.

This document proposes a modification to RFC5245bis (which specifies a prot= ocol for NAT traversal). When trying to establish a connection through a NA= T, there are a number of different techniques that can be used, some of whi= ch will work and some of which will not work depending on the characteristics of the NAT and other aspects of = the environment. RFC5245 specifies an enumeration of such techniques and sp= ecifies an order in which they should be attempted.

Apparently, there are problems in real world deployments where there are a = large number of possible NAT traversal techniques and checking them in the = order prescribed by RFC5245bis results in long delays and sometimes connect= ion failures based on timeouts. This document proposes changing the order in order to get better performan= ce and reliability. It makes no other changes to the protocol.

Detailed review:

I'm not an ICE expert, so some of these comments may be completely misguide= d. Take them for whatever they may be worth.

I don't think "fairness" is the right term in this context. The g= oal is not a fair division of resources between different clients or even a= ny sort of balance between use of IPv4 and IPv6. If many different connecti= vity mechanisms worked, the preferred mechanism would be (I assume) the one computed using the formula in RFC5245bis. The = problem is that checking all of the mechanisms in order to too time consumi= ng, and there is a desire to check (and settle on) techniques more likely t= o work ahead of techniques less likely to work but more optimal if they do (in particular, checking some I= Pv4 based techniques before all of the IPv6 based techniques have been trie= d).

Section 5 says:
> ICE [I-D.ietf-ice-rfc5245bis] section 4.1.2.2 has guidelines for how > the type preference and local preference value should be chosen.
> Instead of having a static local preference value for IPv4 and IPv6 > addresses, it is possible to choose this value dynamically in such a > way that IPv4 and IPv6 address candidate priorities end up
> intermingled within the same candidate type. It is also possible to > assign lower priorities to IP addresses derived from unreliable
> interfaces using the local preference value.

This specification says what is possible, but it does not (as far as I coul= d see) specify any particular means of accomplishing it. If the intent of t= his RFC is to encourage people to experiment with different priority techni= ques, that's fair but the document should say so. If the intent is to encourage people to copy the design in = ICE_dualstack_imp, then it's formula for priority should be specified here = in sufficient detail to implement it.

Section 1 para 1 line 5: All interfaces and address types are known to the = application. Perhaps this was intended to say all interfaces and address ty= pes known by the application to be unreliable...

Section 1 last paragraph and Section 5 third to last paragraph say:

> The introduced fairness might be better, but not
> worse than what exists today

This is probably not true. There are probably unusual cases where this reor= dering will result in slightly increased connection times. I suspect what i= s meant is that "In almost all cases this change will result in connec= tion times at least as fast as those using the previous system, and in many cases the benefit will be substanti= al."

Typos:

Section 1 para 1 line 5: arguable -> arguably
Section 1 para 1 line 7: know -> known
Section 1 para 2 line 7: describes -> describe
Page 4 last para line 7: "too excessive" -> "not optimal&= quot;
Section 7 end of third to last paragraph: missing "."


Sent from Outlook=

--_000_68B1A3ED519C4BE4831959857846E2F4ciscocom_-- From nobody Mon Jul 11 10:17:48 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC28E12D54D; Mon, 11 Jul 2016 08:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1468250034; bh=mpBGFxCKS3yKf6zRMyKoA2/UGU5Dq7lHuLKOMDj9lN8=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=s/iG681mXGk/zxq+oFx3WgcycAxVCIFOwo/i39zVk/Ph2rBpVo69lXNYoU3kp07sJ V9AQvEpTy/CNWvt6I+wcjXbwnJd2t5c0jln5+ztlwW9ch0wwLisduOoX+ZFjpywtlh ytU+fnBTTJXuIGp7s4EzrlbnoNh+mELIab2j+D80= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3155512D86F for ; Thu, 7 Jul 2016 12:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ouyz05ztc6Vq for ; Thu, 7 Jul 2016 12:43:47 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B2C12D86C for ; Thu, 7 Jul 2016 12:43:47 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id f189so37501011oig.3 for ; Thu, 07 Jul 2016 12:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=eYJFHq935NhWrutdK+VrdNjUobgwa2AlHha8t4mUfB8=; b=T9kj02E4z6cABMWyHA4WX0cyRmsf7LeayWH6L6kkOIlcG52BNQYqsodc8TC6/IZGzF wOlgwbsOcUS2a8ptJi/Z+EGmBID7GO/kAw8UzJy5BaOQAqCzBy8OShboDxwplKIx3aQr pwbb/U9lwrOt3NOu6Stxq1l2nOyNinM0dKqHrbuM6NVT+E5yzsQLO/BkO8T5SITJ50xq cCtN5QHaefApbrvcNUoar7eG3fWYrRnCY1Ct59/RcF0vlo4kn2Ls2zeWLmnl2TilZ0Bo ieKvXxIQobwOnXlqW15Dhs0me6BUn5EzeJV8lZ7xQYnPgP0mg1C+TlLwnWmRD5nAaOtl QO+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eYJFHq935NhWrutdK+VrdNjUobgwa2AlHha8t4mUfB8=; b=jcMCXde/ghurORVd2hvtsmJ2dKFpsUjHRoflNbZjLJJTHxxdktGksQf2dqhfmgWzwS /FXvuwibv9UNHH6rAdgd8lsAIdKY/3mlc1Swxm/hLAwGZpFzoZOP+WCdRPOhClGkttHF FUACrqc0cft4YaJ8G28fE2kb98Hsdid6TRGV4SmQ00UERdAnMEThFOGDlVqvFbgin3Pn jv18ZAJVV8VPE7G9xjYeNS1PO/fRBDsXt0VHQ4fCtHvkXEiMDszpn3i1y4mtfStSegCZ /67Wpa2DGxDppGp6jnwqSzk/MVflE/FGhquw2MFEU1ophr0eOl26SEvlWu/9Z/OZ89yS OAUw== X-Gm-Message-State: ALyK8tLIEnct7r6oV9gHmAG80aB6mWPfbv4dV/m0KeCnE86ztGt0/edkgXkBJimUGudSW1C3+w9yDU4y6fJ2CMb+ X-Received: by 10.202.183.139 with SMTP id h133mr1108718oif.6.1467920626021; Thu, 07 Jul 2016 12:43:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.146 with HTTP; Thu, 7 Jul 2016 12:43:26 -0700 (PDT) From: Walter Pienciak Date: Thu, 7 Jul 2016 13:43:26 -0600 Message-ID: To: new-work@ietf.org Content-Type: multipart/mixed; boundary=001a113cd22a7a2050053710e70a Archived-At: X-Mailman-Approved-At: Mon, 11 Jul 2016 08:13:53 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 11 Jul 2016 10:17:46 -0700 Subject: [secdir] [new-work] IEEE-SA NesCom and RevCom recommendations from June 2016 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 15:13:55 -0000 --001a113cd22a7a2050053710e70a Content-Type: multipart/alternative; boundary=001a113cd22a7a204b053710e708 --001a113cd22a7a204b053710e708 Content-Type: text/plain; charset=UTF-8 Hi, Attached is a list of new work project recommendations by IEEE-SA RevCom and NesCom during their June 2016 meetings in Berlin, Germany. All recommendations were subsequently approved by the IEEE-SA Standards Board (SASB). https://standards.ieee.org/about/sasb/revcom/index.html https://standards.ieee.org/about/sasb/nescom/index.html If you have any questions, I can pass them on to the correct liaisons. Walter Walter Pienciak Senior Manager, Strategic Programs, IEEE Standards Association w.pienciak@ieee.org +1 303 527 0934 --001a113cd22a7a204b053710e708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Attached is a list of new work project rec= ommendations by IEEE-SA RevCom and NesCom during their June 2016 meetings i= n Berlin, Germany.=C2=A0 All recommendations were subsequently approved by = the IEEE-SA Standards Board (SASB).

https://standards.ieee.org/about/sasb/r= evcom/index.html
https://standards.ieee.org/about/sasb/nescom/index.html

Walter

--001a113cd22a7a204b053710e708-- --001a113cd22a7a2050053710e70a Content-Type: application/pdf; name="2016-06-29_NesCom-recommendations.pdf" Content-Disposition: attachment; filename="2016-06-29_NesCom-recommendations.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iqcpz0o20 JVBERi0xLjMKJeLjz9MKMSAwIG9iajw8L1Byb2R1Y2VyKGh0bWxkb2MgMS44LjI3IENvcHlyaWdo dCAxOTk3LTIwMDYgRWFzeSBTb2Z0d2FyZSBQcm9kdWN0cywgQWxsIFJpZ2h0cyBSZXNlcnZlZC4p L0NyZWF0aW9uRGF0ZShEOjIwMTYwNjI5MDgxMjMyKzA0MDApPj5lbmRvYmoKMiAwIG9iajw8L1R5 cGUvRW5jb2RpbmcvRGlmZmVyZW5jZXNbIDMyL3NwYWNlL2V4Y2xhbS9xdW90ZWRibC9udW1iZXJz aWduL2RvbGxhci9wZXJjZW50L2FtcGVyc2FuZC9xdW90ZXNpbmdsZS9wYXJlbmxlZnQvcGFyZW5y aWdodC9hc3Rlcmlzay9wbHVzL2NvbW1hL2h5cGhlbi9wZXJpb2Qvc2xhc2gvemVyby9vbmUvdHdv L3RocmVlL2ZvdXIvZml2ZS9zaXgvc2V2ZW4vZWlnaHQvbmluZS9jb2xvbi9zZW1pY29sb24vbGVz cy9lcXVhbC9ncmVhdGVyL3F1ZXN0aW9uL2F0L0EvQi9DL0QvRS9GL0cvSC9JL0ovSy9ML00vTi9P L1AvUS9SL1MvVC9VL1YvVy9YL1kvWi9icmFja2V0bGVmdC9iYWNrc2xhc2gvYnJhY2tldHJpZ2h0 L2FzY2lpY2lyY3VtL3VuZGVyc2NvcmUvZ3JhdmUvYS9iL2MvZC9lL2YvZy9oL2kvai9rL2wvbS9u L28vcC9xL3Ivcy90L3Uvdi93L3gveS96L2JyYWNlbGVmdC9iYXIvYnJhY2VyaWdodC9hc2NpaXRp bGRlIDE2MC9zcGFjZS9leGNsYW1kb3duL2NlbnQvc3RlcmxpbmcvY3VycmVuY3kveWVuL2Jyb2tl bmJhci9zZWN0aW9uL2RpZXJlc2lzL2NvcHlyaWdodC9vcmRmZW1pbmluZS9ndWlsbGVtb3RsZWZ0 L2xvZ2ljYWxub3QvbWludXMvcmVnaXN0ZXJlZC9tYWNyb24vZGVncmVlL3BsdXNtaW51cy90d29z dXBlcmlvci90aHJlZXN1cGVyaW9yL2FjdXRlL211L3BhcmFncmFwaC9wZXJpb2RjZW50ZXJlZC9j ZWRpbGxhL29uZXN1cGVyaW9yL29yZG1hc2N1bGluZS9ndWlsbGVtb3RyaWdodC9vbmVxdWFydGVy L29uZWhhbGYvdGhyZWVxdWFydGVycy9xdWVzdGlvbmRvd24vQWdyYXZlL0FhY3V0ZS9BY2lyY3Vt ZmxleC9BdGlsZGUvQWRpZXJlc2lzL0FyaW5nL0FFL0NjZWRpbGxhL0VncmF2ZS9FYWN1dGUvRWNp cmN1bWZsZXgvRWRpZXJlc2lzL0lncmF2ZS9JYWN1dGUvSWNpcmN1bWZsZXgvSWRpZXJlc2lzL0V0 aC9OdGlsZGUvT2dyYXZlL09hY3V0ZS9PY2lyY3VtZmxleC9PdGlsZGUvT2RpZXJlc2lzL211bHRp cGx5L09zbGFzaC9VZ3JhdmUvVWFjdXRlL1VjaXJjdW1mbGV4L1VkaWVyZXNpcy9ZYWN1dGUvVGhv cm4vZ2VybWFuZGJscy9hZ3JhdmUvYWFjdXRlL2FjaXJjdW1mbGV4L2F0aWxkZS9hZGllcmVzaXMv YXJpbmcvYWUvY2NlZGlsbGEvZWdyYXZlL2VhY3V0ZS9lY2lyY3VtZmxleC9lZGllcmVzaXMvaWdy YXZlL2lhY3V0ZS9pY2lyY3VtZmxleC9pZGllcmVzaXMvZXRoL250aWxkZS9vZ3JhdmUvb2FjdXRl L29jaXJjdW1mbGV4L290aWxkZS9vZGllcmVzaXMvZGl2aWRlL29zbGFzaC91Z3JhdmUvdWFjdXRl L3VjaXJjdW1mbGV4L3VkaWVyZXNpcy95YWN1dGUvdGhvcm4veWRpZXJlc2lzXT4+ZW5kb2JqCjMg MCBvYmo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9Db3VyaWVyL0VuY29kaW5n IDIgMCBSPj5lbmRvYmoKNCAwIG9iajw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250 L1RpbWVzLVJvbWFuL0VuY29kaW5nIDIgMCBSPj5lbmRvYmoKNSAwIG9iajw8L1R5cGUvRm9udC9T dWJ0eXBlL1R5cGUxL0Jhc2VGb250L1RpbWVzLUJvbGQvRW5jb2RpbmcgMiAwIFI+PmVuZG9iago2 IDAgb2JqPDwvVHlwZS9Gb250L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvVGltZXMtSXRhbGljL0Vu Y29kaW5nIDIgMCBSPj5lbmRvYmoKNyAwIG9iajw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5cGUxL0Jh c2VGb250L1RpbWVzLUJvbGRJdGFsaWMvRW5jb2RpbmcgMiAwIFI+PmVuZG9iago4IDAgb2JqPDwv VHlwZS9Gb250L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvSGVsdmV0aWNhL0VuY29kaW5nIDIgMCBS Pj5lbmRvYmoKOSAwIG9iajw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL0NvbG9yU3BhY2Uv RGV2aWNlR3JheS9XaWR0aCAxMDAvSGVpZ2h0IDMwL0JpdHNQZXJDb21wb25lbnQgMS9JbWFnZU1h c2sgdHJ1ZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE0NyAgICAgICA+PnN0cmVhbQp4AXXQ MQ7DIAwF0G9lYKmUZK9U9QbtCXKuTnA0H4UjeGRAcSED2EOYeALzbVTnEq1xSLQcd5CXcsYDxNg0 r5q4AR0cDNJiAJo4CQ2xBuUolRAHCuEYyIR1gHeElvPsoZ9EWCbeBgxzLaM/0GqWVuOedqGuHaWr 0StnUzeCG86NLfscTsvX/ptF/ZmTc+xV/mn+1fRlbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqPDwv VHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvTWFzayA5IDAgUi9Db2xvclNwYWNlL0RldmljZUdy YXkvRmlsdGVyL0ZsYXRlRGVjb2RlL1dpZHRoIDEwMC9IZWlnaHQgMzAvQml0c1BlckNvbXBvbmVu dCA4L0xlbmd0aCA4MDYgICAgICAgPj5zdHJlYW0KeAG9Va2SpDAQbtkyNi42GodEIpE8AGbdWGws cgQPgEQiccjRa9fvQ2zu64SfwM5dXV3tXFcBodPpr//j/f+mntyrIR+GeHkxiCUi81qMmrK64PIC Mi3LMj3AnOYTTR/ev5848zxCbIHcSTTV19DbkLd3qlOmnxScYwsIWSTESJ3jhIGlmrwvhZXwdaLO UT9g6zaqU95nHGACBhZnar1vE05Qi2wWCU+W6sBodFcTQSDvbXOw/RKOPMOAKSkG5JjmiJG4QYcf jsecSC+aWM8pSDT/wNBKq0gHhmYNpvAPPwyvcnsROT0WAK98I8EfCsRhpQtGvvHD1wUnzwmMsYIB Fyq5R90y9TE02plik7hg7PywHzHS0G75OIxcFTU0lVIK/PBfRmJpBr0pu2B894PpLzBGo/oKEDZD rEod8pV3ykqxb+W052ODjtbFnD/DOMeqI/XWAKL1n2XmTfYxGnhStwqc7xgUc65Zddh04j2qBAmX DGuU1Va7gScvsGpF+g7B6WvJqfA52XqWbmuRoOoJBrYkcxSmZ+jB4HhkJhgiJiTtgaYwgtF5vAvp 0uLD4P+Wye+3WGFnJYlGzHlkAIpTjBU6tEcHmyuI1cvjfp/adhxkNGYwMcT5knNxIZ4WjEsPEkbJ FqsVYm3z2fIYhkxWus8uN6LEDlY/zXnWD32gu4zJiFEMwpMHrBWj6scgNgzCA1U85wH3TdLDGFCj QSUFuvjxb3UlmgrbS83yDZbJt8v3Pvgjxu978Fy7wVpnJ8lCG7zXfXa06QVjx47H4DMyGdbbK86S Q8HGR2TNZKRHOgRqKJJTV4z9VpJ0xXyU87yAjefIebPLSa2t5FRfkjKKbJeljXvBoHhTSUBhauxB 8SUSA/h6fxyzHfI83SBZjva24cr3ghHURZ0IeVq7gblsGDtsekd5jPWuzeqez6WzBAtRZXGxGiwf YKQ9GHYQmNAGiVhyD8Lkkq2rMUAmdz88mRVjEmVwKCzi9YQ3h/uc9n+ZVyx3VCXy8rfSfkdFnRgf BG236hStA+8nVg/DMnJcjTC8jNo4zx/vL0OAYhlCP06/AM7H8UplbmRzdHJlYW0KZW5kb2JqCjEx IDAgb2JqPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvQ29sb3JTcGFjZS9EZXZpY2VHcmF5 L1dpZHRoIDMwMS9IZWlnaHQgMjQvQml0c1BlckNvbXBvbmVudCAxL0ltYWdlTWFzayB0cnVlL0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzk0ICAgICAgID4+c3RyZWFtCngBjZNBbsJADEX/ZFDI ClhmUTU5AgeoNKgn4QioBwCjHKzZ9RocIctZoLjfTqGBTfsFE8/PG2M7QfUfyh0qtNC+cbjjmpNq f/LtuFS9MMxnmE5S0lA985sbUklNY9ShZZhlolBGs/+iigdKmICyXGB4z/VENQapdjrUySmrfgQC DuESsC2wWaq8hP4VQ1mix2GFWkJeX9JYsLwt+oANg6ioIQvszUVboJJolAaBA2YjGIUFf8NFVqZ5 YZicaVWaDxLfHfE6d2eUVWC5TCeUfhWgqrAbUfGu5+OVJj/UCUUU1nEW1BUCW6ZIRStW7tSlYI2k YFR0ikk/vCWn/GkPdri1Y3W1CVcssGOu452a5rWcUS+4YokDqfcnKs4okDKxjTvlUx1/KN7jPHtS 2+kxPFZvZ1kXRUqyBZPYIyW+skyqtYUU8tqimcTjZ2o1I35DTvW2Ya4wTFR7826zF/PbHZc3Tjw3 bGGFgx/dl4vKX0n+U9JXl3RI3aeyaZpxSOfrWstjyo3mb2LrCMVlbmRzdHJlYW0KZW5kb2JqCjEy IDAgb2JqPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvTWFzayAxMSAwIFIvQ29sb3JTcGFj ZVsvSW5kZXhlZC9EZXZpY2VSR0IgMTU4PDMwNzVBRjM0NzlCMzNBN0JCMjNEODJCQjQwODRCRTQx ODFCNzQzODhDMTQ0N0NBQjQ5OERDNTRBODNCMzRBODdCQTRCN0ZBQjRDODBBQzREOEFCQzUyOTJD ODUzODdCMzUzOENCQjU0ODNBQjU1OEFCNTU4OENCNzVBOEVCQTVCODZBQjVCOTRDMzVDOTlDQjVE ODlBRDVEOTJCRDYwOEZCNzYzOEJBQjYzOTdDMzY0OTRCQjY1OTFCNDY1OUFDNDY2ODlBNjY2OTlD QzY4OTdCRTZBQTJEMDZCOEVBQjZCOTRBRDZDOTNCNDZEOEJBNTZEOUNDNTZFOTlCRTcyOTRCMjcy QTVEMDczOURDMTc0OEVBNDc1OTNBQzc1OUJCQzc2QUFENTc3OUFCNjc5OUJCNzc5QTdDRjdCOTVB QTdCOUVCQjdDQUNEMzdEOTNBNDdFQTFCRDdGQTVDNTgyOTdBQTgzOURCMzgzQTZDMzg0QUVEMzg1 OTZBNTg1QTNCQzg1QUNDRDg3OTlBNzg3OUNBRTg3QjJENjg5OTZBMThDOURBQzhEOUFBNDhEQTJC NDhEQUNDNThEQUZDQzhEQjdEQjhFOTc5RThFQTdCRDhFQjFDRDhGQTFBRjhGQjZENjkzQTlCQjkz QjZENDk0OUNBRDk0OURBNDk0QTVCNDk1QkNERDk3QjFDNzk3QkFENjk5OTk5OTk5QUJCQTlBOUVB MjlBQTNBQTlDQTlCMzlDQjVDQjlDQkFENDlDQkZERDlEQTFBNTlGQzJERUEwQURCOEExQjNDMkEz QjBCQkEzQzZFM0E1QTVBNUE1QURCNUE1QzREREFCQUZCM0FCQjNCQUFDQkRDQ0FEQURBREFEQzdE REFFQjJCNkFFQ0RFNkFGQzRENkIxQkFDMkIyQ0NFMkIzQjdCQUI0QzlEQ0I1QjVCNUI2QzdENkI3 QkJCRkI3QzRDRkI4RDJFOEJBQkVDMkJDQzVDQ0JEQkRCREJEQ0FENUJFQzNDNkJFQ0ZEREJGRDVF NkMzQzdDQkMzQ0JEMkMzRDhFQkM1QzVDNUM1RDJEREM1RDZFNUNCRERFQkNDQ0NDQ0NERDJENUNE REFFNUQwRTJGMEQzRDdEQkQzRENFM0Q1RTJFREQ2RDZENkQ4RENFMERDRTlGNERERTFFNERFREVE RURFRTdFRUUyRTZFQUU1RTlFREU2RTZFNkU2RUZGNkU4RURGMEVFRjJGNkVGRUZFRkY0RjdGQkY1 RjZGN0ZGRkZGRj5dL0ZpbHRlci9GbGF0ZURlY29kZS9XaWR0aCAzMDEvSGVpZ2h0IDI0L0JpdHNQ ZXJDb21wb25lbnQgOC9MZW5ndGggMzE5NiAgICAgID4+c3RyZWFtCngB7Vj9XxNHGg+bmG4tIK2I lxoFDaUItT3Qqmd9o5hai2K5omDqFTjr1jsD10K3p+029nTFjbYs7NIM6TD7t973mdmXBKlt7+eb zyeZfeb5Pi/znZednSD4f/n9DCxOTcyLIEAVFkgbsTCxLIInibQOZFQ27/Tn8/2f/dLQFKleVE9N TTR62Rb6QswK0pkRfzBqFIZ69mu2L9KF9vlUqtPlAaqw7Hb5k+g5lTrtialEuuvHSS5qqll7zNG2 mM+fp/q3C6wavGyPfyHmOMWtst8V7Dn31DNnq+1oPj8PBrfVNXvobmnZZTKBKiytJnsSPbe09Np8 KpGKNgutJaRVg0p7iDZgOp9LojlQKMFi3K5tq4obX4hpo3QuOjxG/5EHSrtc3UI0+n6yyoNtdc3O uzVtV9kXVPX0UjkCsjRN26OkEZClaTt6lPRp3M0uTXt5bLr8LpAXXRHMaNprVjLtmkM0STAoViLK mzSJ8CLMCrLRtL7fcpE4a3pav/TuwHNk9WvakM1EbTtdk3VQSKdfA1moektl0zQtG8swnU6fnVWS L2aAmDagMi0n5gOIE4a1yrLp9ABGCpic420ZseZAoQTDYuU3ZpbE/MrUmUekdHrn7xuZbTIQvrt1 GRbS6ZNyXW+ja/YwmMl0gixUAwtVxlGwejOZTHHJrSlpDgjDlqp4WyLEuOUJ0Q276nyhK5PJ5rtr MD0OTdsZuYdfGyyszEDTvSJZnMPj0RVybfNgk6RM9yLttmuDg1cF7OC9CbM2qse+4qSR6A1YfiHX UiNic5Q8HlWxNkbbMpn28D0gNW1n6jJUocAwDApcWETTtUFE6eg+L1YGlS64f5AcPaGk7w8WFleQ WptyNZjN5oisbHbYiih/ls1mJ+NdYQ4IM55SKus1IC4DIXyrbLpTkKjY/JF6yOqPkRF8dktZf4ip BDcoXfgRWQellM2eR0yEK5Bsc4XRCeOINapR9B8bJtkmGkx4PQcfQYzAjrMZorPfwGOkyFOPNsNY +VVOobJYcZt7yTHKlTr1nEreX8a/jdUxSiLKlxh7JFRQ0iViANiQrNN4KapCLm/F9NxGn5/bvIHQ v6ex4h7j84PgQO/stBiS2D9ysT2bfQtMUhr6ENFzriqol3pfDv/ZcYffh3Bs5B0IX3mCwlExPRjq ffvpedwRyDI3chEc0O4bFYxGzpzIZg9b2PeOQzhFiHdd8REG4tT7CHYIkWGqD5D3D7GfQqMPDAD1 litDlV2BLumniofxb7OrBag6OvvsB8BDR9n0DVCH/lMPAIQEYLYL6yj4s64TWaj6J2bmbt+eA5/P dF0/qiQsk9u63jUxBdVtuWhU2qOA6GfkVA0Er0/By7ThPEUjqnldz+MNC5+dY4a9V9eHbX4fqgvT 5iVUIOu4rh+btnyoJh1B4UBdkewaMBBKRuVv8Nwwrz/S9SHzS2REbRJhEcLig7r+vmHdQ5PJVvA/ Vlq6ouvtNhcQRqZNoNot9gSC4VJmp0qWD+Gm49VhOjBddpeVDqn1TZcrSO0yWEXbWZU1eCSy8oos tFO5y1T2SnJq0kAJ/S6YlEX8fFA27Z1Rh1I4zWFfQzxi/lHs85jhcPRvuMKvoYMl01+H2bjNkF/R rosCCZzIQkZVPqcwdcI4HP9LLn/an+9bQJ5hQR+KlgfV37FpJYglhn587DDen88tMPjJzVoexVog ftpL5upPEMq+JMshZrEXEI0ITxQMlas8JLId3EJCvodtThOlFHKMGQtkOLNgSgWbFWUfFpqz0TOG OM6a//gX1dw+T7s+MPmyy7lfxbtmAxyEA1BcYmQ/bNPw7TccESCX8YrH3KrPxb/gIiSrtISZQrkQ BoygGf/d3/OAO1ayCazBAvwjAG1aDYg6JkTXl1wIoGl4hmgiADzpE3Mw4RMnhyKy6jL8L2F4Cjts Yjcg3z4xOIs1DmXeItrzRlWpaGNRZFH1xgCVTx3J8QElhWQp4VhCluDut+e64FhORSIrR+kFwaNr 6ELsc7yCdR+RNUQzBJnRaAYbi+geCgQMKXUnIJ3spMSwGVLvnVkX9IIOi+yCJ8DGIbyOGhE/SPTV FQHC0JlhWqaoJ12AKDXBHDucPRgOhIcSZbwiKUjIkvMLCT4DTaacozCGQGPUsMEPqHMWhpH2OHnO WrKcOu2G2I/UEYy29KjUXOuftPXl4ZowRNaafM3gbRW+NCgX6IbsGnb7IdkBbN4wuAbDbDs2dCIr NKZcYgxm33nCZLNXE64I0X9v+QmsddPltQQhOHZ9KoWfQVLiB2Rls++odYz99xkQmCmbeDWE4Yks gqv3jOEjmSzxQkjTgzH1S5o1kTUUn7NI13DOgkF4zqJTUVIEZ14/+fQFXrHkdAMvlraBT2+RJI8j RBZ0QxVJFi01ZIY3HXH1+ik6A2wlK8KA0Pp377QBl/0QZqrQKzUqN7BpNSL4d+ckutuj00BE+iSd a/bHK0L22hWjcHJgRIbfQpbbQFZb2d9KVnIopYGXRR5K4w8KOpTSrGksaMvQ4S5YxANeLxLjC0g7 8TZ8EPuUZGUyQxYrZDJ9FAAHPtq8M5k3phf8fgiYWVEAHDj3y9knMfDuWjdycBkf1x8hWlSGaeFG CFAbBH7l80PQfsWOIiKRTrHcqUxG7rVzczPquI19Cai3p00vDz2RhYM1Zhb12nDX6R8LVSblz6jU pArxcNbfjVmAir6PEBKFPneSQyk+ZTpjHhUgWATCJm4JinkNzG5gUB3AHP4BFgvSZxG5oHHAYlfR toSjCvBFh+P/Exwu8uk0kUUp0GhIDLxCO+6uFApX64z9BCH+mhvFhw59vw60wZvzNEGYDM+csbqO zN0piqhi/dXB91EHzSz4wZ6Ffyw1/M8iPCqEDwoyQSF1LjXeBFnI+vUFBk+UmlSBrH71bYjqZHwo JV1yKIVZrhqdGUKyCHF5Ff07k06/rMjqrHhEVh8op06DOvhMyLoDiwoT4DEk6wtsuhAwKHD2miSL hgAYcl6sLqfTdOamTsrdnyLr6fQ+bJ+W/SFa7ccJouyhwcXmRjGdr8EP7kfW0ukds85TaP7tiQ3w vCBpMly4TiM/NKUnQRZshpE1hUVXIF0Gt+jY2yaRRalJFchKbh125rpl4YJuHTryUrgiBG4UduSU 9DTetNrQ+FmtBp3Wi2VImFvfCLqguMfJXPtY3mRIsjQNs3wdbYd+WsFthYaZhf/DrD6I6vVvCb9L krUBORdibMLcqwd34DIiCzcO2okyfcFSiIu+RIhFIMqrcHydCUKUbIZ7iev1X+D+TzBFqoeZFHB0 gB5LDf+n2TrlcuDbWoBbh467j2WvAUfAjqoUxqw6OkSpSTMiq6WlFcswuc9qsRvvs3Y7jfdZt6LJ J76mWyVZXhnDIC3KR/+BatpBlc3hc8Sq011Xr+nzo0qH/xG7HoYj4JC/jCs1SZZoxLB+KHOd+HsT oyFn9B0IOCLSMywP2IcaEBN47ujA3z7DYZ+hpqIhNx6nekHd1BF/Sk3hJ11xnKROhjRaoKvvJBEF jqjvkiyIkIJcKvUKjpOoomJUH0SP0C24lxLpbHT5J+rXw5vS1jEcd0WtjUBl5zBV2gev4t+odqZS Z9G1iVSqBzl7u0i3p5UavcfSes8Iqh7rbirVqsjyYJJKvaowq9IAAPCjyMJ17kuzci8Xh/BYrrxM cInwvf3qed80YtVOS+GlCwaOPvXrUtCOGDanns06TIXfdwoSuiSlVkoDOs6/V173wJG4olJbVirh 2+Wy5XNUxqwshul6VTMUZg3L9Z1INbsQf9IKz57s7ek5MlbCZ4oIuHujeLa04Li3enuOlIyFm8WS 6bh2mZTMMcvYErj7cW/PiZJhGKbDmPNeb8+FUvkfxQ+MiguAfOE1Y2ruDUSARfQyRMxyKAi/grSr 1c8jBOern79N+Rj4RBLc/wrCiVKZzv7Cq7wHTcnAlUINPcMBjT1U4W8WPwGEPZwcOYusHNLh9FpF 3DfHZoFD7guUWl2awRXzvJoAxPdXqfg+QzCmhFXfq3FR9xpUcj3gDwk5lmXZ6jZccM918AXDWdXG 9aHnuy4JDL6ADCsycFwf1xRC1FeBq/oExBbEmHqBKKcRJoyQXNZRkuEkQ9pIlHuOjRwkgnsIHT6j Vy4EB59UlKoUbBcnajoaNocHBFGrjushDeiinimnhEdqyizq+v9SIwg+RNQCoZTUI32coC1pT1yT QdwuBTJL9PT0HCaxaAaGUmMOjc/o39ZgTZHC8FE6YfKRU2n8fLz/AjSC5j1lbmRzdHJlYW0KZW5k b2JqCjEzIDAgb2JqPDwvRGVzdHMgMTQgMCBSPj5lbmRvYmoKMTQgMCBvYmo8PC9LaWRzWzE1IDAg Ul0+PmVuZG9iagoxNSAwIG9iajw8L0xpbWl0c1soMjAxNjA2MjkwODEyMzItMTM4MzYtdjVhczlr ZWYpKDIwMTYwNjI5MDgxMjMyLTEzODM2LXY1YXM5a2VmKV0vTmFtZXNbKDIwMTYwNjI5MDgxMjMy LTEzODM2LXY1YXM5a2VmKTE2IDAgUl0+PmVuZG9iagoxNiAwIG9iajw8L0RbMTggMCBSL1hZWiAw IDc1MiAwXT4+ZW5kb2JqCjE3IDAgb2JqPDwvVHlwZS9QYWdlcy9Db3VudCA1L0tpZHNbMTggMCBS CjIwIDAgUgoyMiAwIFIKMjQgMCBSCjI2IDAgUgpdPj5lbmRvYmoKMTggMCBvYmo8PC9UeXBlL1Bh Z2UvUGFyZW50IDE3IDAgUi9Db250ZW50cyAxOSAwIFIvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXS9Gb250PDwv RjAgMyAwIFIvRjQgNCAwIFIvRjUgNSAwIFIvRjYgNiAwIFIvRjcgNyAwIFIvRjggOCAwIFI+Pi9Y T2JqZWN0PDwvSTEyIDEyIDAgUi9JMTAgMTAgMCBSPj4+Pj4+ZW5kb2JqCjE5IDAgb2JqPDwvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTIxICAgICAgPj5zdHJlYW0KeAG9Vk1T4zgQvfMr+rQF VYljO18Ot+AkwFYNZEiKC8zB2J2gHdsykhw2/36fbOeDYqhhdmq3QoJst1ut914/6eXEIxcfj7zA /sXZyQv5/b5jb7rku06XXFwMPc/x7NPOtefTRNJXxAU9Z1iH9Z0e9UYegodu4AyaQLcOvFieuE4f 6fY/ak2dWY88l5YrJBgEA6cfBLRM7Fwu7sanN6xDmdEdxzLLOE8iI2Suz5Z/IRciDj9Vrv4+V9vv Ic/p9XQ6bS/GtDAR3lWJpguJf3TDr0f3MEMmjGGmx2bCx7MfTkltrBppHxbjxQVFRaHkJkoJVfE5 dd32n2Xe9l1v8M0WeLy0ppyHcZrSRhrWVOZRLjJZ2lHKWlOO2wlJ88zqVWh2mhzvlvRFJmIlEDof 3zVAvAd10ADRHVAb3wYJGrOSuohiJsBB05Rjo2QuYlpsteFM00LGgs22c7lVksZxzCneyNiwonmU c/pp4Oejvt/2RqNhJ5SKvHd41DjuaKFFwTFWFVf00kyqLDJ0WYqkrnTJ2tBcyZiTUjGtkHIh8nXK 7fHfQtN1jgJXdaUKq5mJJxR8WxiM7Uo0tQllKLGGgsqMvHNbT9vd0TkTa5vWq1AJ06jUIKjvdJ1e iwKn2yLPdyD8Hu74xxdvniDWhvkI8nbDntOsfNjwcZjzraLPaVyJiSk7ohdy7JPIaRVtpGqhQ2RR SM0J0lP0pE2EZw8Ww5S33x7PanI+FgPWe9CC7Yq6F+SKLuWGVS6VtmwVUkHPNE42Qku1pUsly+Lz xHvBaPQB3TWhlr0pin9KhX4Gi3QRaRB1xy+lUIwmN7pi+Eqsn9v3MjXRmmmCR7GhsFQKAQDm6n4S okuXKsp1JrSGLViFGETZodV3KHPIu9bsjuopJinsHHWJO172UvgMLb+EM6rIshI9VjvXvsN20tc0 4Q2nsiqqZuQXsB65EOUHaO9mqMC8ixIh6RY009RaTM6GpnkcFbpMm8osZF/gaaCk8pXO7H9A5xoN qQ1UBv2n70CasyWQ0bJ/UPjMGQJSdHv9ys9gsr1W7wLzoLfvxMN203h59awToh1C33d8upGOP0IP n7/Bb/EdvTZdrawIoTk46BUDN6gX7TMXBaciZ92ie1g5pxjshdaqtLgwqowNXAZeZAs/GMEl56yi tEXW5JCwBRIUZsPAMjKRcWn1WjvjcZPUtP9rjjqzo62l9oUKJ/8DOVmc/AYn4OP/d/gca6Eiede8 B/+YsBbrvAUtwEjSWsFHCFYbeuUJexy/wCwNY9ON+TeBO5xfqlF18Njtt28slubyFf1WbbXgeL09 NP+rMPHzmiNVre8zJ5l52B06/k83Umuuje/RoprlyR54frehfyQWW5DnAoMPBPOmfya8ErmoDm+2 Y6y3087bQ6HiUhi6UBx9Z6Vp/IT9CDsmDnj3UVwB2PXtRRLXTQGXTrERItSCe2sNrS4Ch1fPHib7 3a4TBD0YwO5IeVpBN12efD35B8zyMlFlbmRzdHJlYW0KZW5kb2JqCjIwIDAgb2JqPDwvVHlwZS9Q YWdlL1BhcmVudCAxNyAwIFIvQ29udGVudHMgMjEgMCBSL01lZGlhQm94WzAgMCA2MTIgNzkyXS9S ZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYvVGV4dF0vRm9udDw8L0Y0IDQgMCBSL0Y1IDUgMCBSL0Y2 IDYgMCBSL0Y3IDcgMCBSL0Y4IDggMCBSPj4vWE9iamVjdDw8Pj4+Pj4+ZW5kb2JqCjIxIDAgb2Jq PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4OTEgICAgICAgPj5zdHJlYW0KeAG1VtFy2joQ fecr9jF35hpsCIbkzSHQ6UyS0pjpfRbyAmptyZHkJvx9V5INZDppkrnNAB5jW+vdc3bP0UMvgZg+ CSRT9+VV72rVi/sxXTwc9BYGi3NIYlhtYJTCZHgOq8I/QJf42bUwVot1Y4WSMH9oRF2htLDRqqJF FOob42AVjKb/tv/+WX3vDRaTNmQMUTKkiGf3yFVFawvmQl1CVtda/USoVCE2AgtYZvdh6bhdGlE6 7keL508WpXEp3ONDg8Ya92jcH7tSuoMvJT2W0q79PJ/PIUOtTM04ApMFzEvkVispOOR7Y7EykCsu 0O4Hn/ZaQcY5lrSiQosalkxiGd73O3RdslSnR+5seTEeRsnFxWQwUxqSUFIH8AGN3FIeTBeQ18ip fu5RgYXSFbPwqRFFyHRFtcJSK45FoxE2FDIXcltilD0JA58lJbgJmWqqZiHWlPCX2tK5q8RABJSG FlsCviHGLl0+0SGNhdi6sAk9Fgp/QuMRuhWGlWIrPdmZe6FH/B286kCUT5lJwAODjbSihGGcTF7j kNIM9HsK50XTotRx1YFoqMaqEtYivp2mZDpJXyPHwX2H9lHpH9SgecW0hRtkWhIFvrAvshQS4Yat lWZWafEBME3fB9NSPVIL+C6XqLf7Q2fnj8Ly3ZbSfztIs9Gkn8T9l7o49KlDye4QcpoZ7nVCbeCW pssB0gI1E5o3wsKVRvYD9d9vpr+F0kozaSphvNg4FE8F8O3AjdPRC80VMCMlmykaSU4YOeA20TWr aofWLTJDM+kG74NQGixORCsM2DJNz/+Yr+P40OX70ySByHbsh74jtIyog5jNdkwzTgJFFiK4cQ9m qEpBavBNrGlenJ67sqkfTpTNg9y5xgGkD8Li6B7+7JmFPJefF+fKdwzhU7VtffRWf+ZDngDeukQa x5M0Sl6SoPC209Ak0UunP0l6Cc+uO2r+E9Spq0avnRqRs5atoQRO3+zFr2u2H7NjA51Y9B0+Ogv3 PP0J1aOpe1Un5a4b57KdqN9kd4Pb7A7+l7hP42E/+cq90h23Nwfb62L7rrtRnJXB9JA2BTV1KJkz ZKRUnfib6EqLYtt6YzgvDjchM3vJd7SfUI1x3GzIzyHfMTfP72RABhQhmOQ1cqycow/jYRwi0U4u cVu18WjUn07PIRr73dXQ3Z2vel97vwBIo/rgZW5kc3RyZWFtCmVuZG9iagoyMiAwIG9iajw8L1R5 cGUvUGFnZS9QYXJlbnQgMTcgMCBSL0NvbnRlbnRzIDIzIDAgUi9NZWRpYUJveFswIDAgNjEyIDc5 Ml0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGL1RleHRdL0ZvbnQ8PC9GNCA0IDAgUi9GNSA1IDAg Ui9GNiA2IDAgUi9GNyA3IDAgUi9GOCA4IDAgUj4+L1hPYmplY3Q8PD4+Pj4+PmVuZG9iagoyMyAw IG9iajw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTAzNCAgICAgID4+c3RyZWFtCngBxVbb kuI2EH3nK/opxVTtgG2utW9czA6pYYuMXZWHkAchN0YZWyKyPAx8fVoy4GJ32dramSQ1DBch0a3T p0+fvxs+ePTngz+0D543xnHDa3m0eHnSKbRnPfA9iDfQ6cPADyBO3AZa4s3l0Atafr+4i/9qtGfd 00YP7t2+ZmSYTJhOYKM0jISGuTSoN4yjWxlrxZI1bYHfhcYMiwJGnNuX6FAYzOljjjKhf/MRZuIV E7CbF2otMvzqjJA2i0vsyZZJiRmM6cheJGYL5Q6MAr8V9GDxcKxSHpxSvr+ce0KuchuWGaHkRxjt dlq9IEjcw3L0BKU0IoMpcszXqCHwAg9WzR4ICRv2ovQHwlTtdqrA5AOBq5GXBcIfvzKJR8H/XN25 LFs9C/P5ycHcr9EjpOOkOQ/DECYq35UEGkSKCzSH9kJwrSglixOheoa4sDtzYQxiFeB2HemqQdcG WPqDILgPPL/fntBP+RUk368ig1gzWeyUNrDUyiiuMlfMWOQIEcpCGEFwEWyZ4A7DwmLDYKxFklIJ HxVnGYw0MviMZq/08z3lrrVICfQyP6dxrsxbCvNGqCO1MXumEX65EDKUqZCIWsj0bdAPPM+7gfdC JcRbAte1gmudJNFUbhs0NFuCNSPEJEctC5iWVTKuY4iXhUhdI7Rn/z2CYYbcaJWzVKIR3JGXKEDt KszhwuCaslN8wUztbIP/DH27g841hN/oYiLcUjNO2VSawyR8mWUkDDG31C94oE4mrXt+OFql6Hrw 6eFYNez7oVnrKTG7avRlMPB71ze5sP5TKZIqc7NFIFGzlyH+HV1rgdqAXY+2ArPE8WOzoRpQB0qr o/T1MmOSaVgwe4plJ6l+L27cuE3/TbcJv7oDUdxQJSdC81IYGCs7VB4te+qrVyHf62K1OLt331Ho OalWYfThWvLOch0j30rXsWOlnq1KK02FoupRM/+EZHc8z291b8B7mV1fsj4sjMirmI5GqjCOHKfc iRdustp8UHP7can2duhUc/j/grZKws78UKJOawmZy6LMiNFECUXwc6O0I3btXNy7K/tSj71g0L2l vdftFpEpoWZSNL4oBwpqWEZh7QJ11izDV7EmJ1IJSiXLjBYKt/3sYWj4PbAjEVaVBenLJGOk5BuB yerOzUL7c1QMJ9q1gD3aiFMtsswS5Umk79y4P87vm0WIyjUB4tK3BPkx7P2h32v51nT0vmU6agDO U8KZi/CVk52j0ZtSFWgiWi5TEdbkHxDl2UcUMM93Gdpx4naGE+j7QzJZrnrWTUUmIa/r91bNeEHw r5pTQa0r1uSwEneHs3M9OZPa4tzD9POyQ2f+VbPSnpEX963Z7nU6reGwS1ZtaK2aG3Rh3Pit8Q8K N4cfZW5kc3RyZWFtCmVuZG9iagoyNCAwIG9iajw8L1R5cGUvUGFnZS9QYXJlbnQgMTcgMCBSL0Nv bnRlbnRzIDI1IDAgUi9NZWRpYUJveFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzPDwvUHJvY1NldFsv UERGL1RleHRdL0ZvbnQ8PC9GNCA0IDAgUi9GNSA1IDAgUi9GNiA2IDAgUi9GNyA3IDAgUi9GOCA4 IDAgUj4+L1hPYmplY3Q8PD4+Pj4+PmVuZG9iagoyNSAwIG9iajw8L0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGggOTMyICAgICAgID4+c3RyZWFtCngBvVZNb9pAEL3zK+ZUpVIItsNXeyNgWqRWoYDS Sy/LeoCt7F26Xieiv74zazBOEG1StREBGcfMzrx57838aIQQ0CuEsM9/MmvcLBrBVYduVh92Da1x F8IAFiu47kIvjGCR0ANBQLfkxSSOY5iaB7QgdAKxRrvewdxIhW7XWlih85WxGdr87eI7BadfHT98 8M4+eADNqE2xL6bDTu8qjK7eBc0oCDutobEQ8q9b4/bxWZ/HxdzRqcImsMDcwdAkCHQcfFI/CpU0 JxkfjAmMVO6sWhZOGX1Zpnvp853hukiFU3oNT3NtUkLlIU0KbK1ao06KDML3ECfKGatE6mMsUG60 kvSNH0PJh/hqW+Pe03xnKA0lRTnzU+9hsN1ac4+g8QGmgxkU2qkURigxWxKkURAFZeU1lKgLFUrd 6z9j9IGgKGGJcyeWqco3XG/ZtFrVMBRbsVSpcjt42KgUKZuEkviAJhNrjU5JD2Rhl0JLzOEJLmWi /7/k9hkunKlzvjGWqKGsLJSDr8ptCAWialWtolLMas8ZqDhzgk9+CXu6GEvXFIMTqVgyQyGJFU86 f2TRX7b+KEV/9UiPdHZJBq/CO9woSWy2JAZipElNTYkzQbzyzd4SHJ59cBBPTsTNMuUcoq/oWSIN u1HvTCMOcb0U/ZkKtYPbe7T3JnVijTC1xpVKYehHQ4hT+mrVinTEyoD5LneY5bDcsUbSw216eF5Y CjAgpeWncNe68c+EFvUOIjyxH4/qlEoh2ZL+PwtNxZG8HRzJOFLsCTAsKGP6B+HhHeJcxSWm/15F zJQ9W8hoct8bt0Gi9L3KGXGGdu+me6/+7SCoM4/osy0cWcXB9yeaTb/s5CDPCxoD8kXc6j6LW2Tr ktzT7i5hUFAx1IWSPqW58z2y6Z9lHkrDR0NDYuCckBtukpf9nEjEjBwRDmRqL4SfPZsHDiNpa0gK 8CbDk+mMpT9f1yfozs3KPQiL8KaSSazXSiNaNvaqi38l607Uf/dY10cLm8xvW5N4SG8a+geFspfm h4ywlkeT54NmbTC3UrXCptxJGiuqxg7lVf7tIjGy4J74Xn17+2ptaI1PJ2vU7nU7jzGofKVeddWH OvpNuDNSLNmHd69WxYvIlBW8rfgtpRLskTOkA0zN1pvYjSECcxHHlc1fndnbona431ZOjPIQ34vl RpkMyewl3G5R+1lgpElfDa3WmPbdkBfazvX1Vb/fps2zzzuV3yziReNL4xc5KGLOZW5kc3RyZWFt CmVuZG9iagoyNiAwIG9iajw8L1R5cGUvUGFnZS9QYXJlbnQgMTcgMCBSL0NvbnRlbnRzIDI3IDAg Ui9NZWRpYUJveFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGL1RleHRdL0Zv bnQ8PC9GNCA0IDAgUi9GNSA1IDAgUi9GNiA2IDAgUi9GNyA3IDAgUi9GOCA4IDAgUj4+L1hPYmpl Y3Q8PD4+Pj4+PmVuZG9iagoyNyAwIG9iajw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggOTE2 ICAgICAgID4+c3RyZWFtCngB1VZNb9s4EL37V8xpkRxsS/6KuzfXUboBNljXVpNLLiw1kdhKpEtS LvzvOyQlq04rIFgE7S5syLIsa968mfdmvgxiiOgVQ7x0b14N3qaDaDSni6eDzmF8s4A4gvQJpgu4 iieQZnRDFNElfnGbJAncyqw2Vh9htd+XgjMrlDSwU1ygPY436itq2B2NxcpAInMhEbWQ+WX6icLR c7qDDzdvwg0jGE5mFO5iEy8WS3f7+GbW/Ei/eSgXW+SqqlBmmMFGM24FR3hSGu5VaVmOsGM5MJnB rlDaElaLWtd7hxG2IsNhWmhV5wWkaCyh8v9NZDb8YBCSErnVlFIJyZda7CmOdTgctCY8sxT4bzQG bMEkoaOE7gPWq16snqI/HV9aHRA2q60PawsEjQdhHDj1BAyMJehMZ1BLK0q4Ro7VR6JzEk2iwF9/ uQgjVYzoa4pEJapdAj64p+QOmak1uouncqVrKvYQHtgBicUK3qFEHf7y/e2O0ZVk5dEIE4D0F5Ke 19ZxMosDNz/Ucddm6mqXoq6EVKXKjx6oqw3coS1UZjxTLrTKh1YNr0UuLNVnreQBNRXXwxnf/KfI DxpwnCXEJiXViqP5eo0HLJVvL/gDwt0d8S/nd7FY9NB7jUbkEt7V1PKhxZvWbqLtUB+cclqduiq0 CEgUVB2v6vD0/we3u6/C8iJHpl9O4Hp6NYono74m7TWbW+nUReZDwr1jsg4NaZ2wSMd/ibwYtn60 FprXwsJbjewztSs8XvxDnds4B5mWebw8p/k7t2nN7jcYSG8Pp5pJ47yi0V5n5/7szNM7K1jPienl KPY29hNfP/lBa+rGO8EWyYeDZQUn2GEluKIJxC21bABJZbLiSRCpz7H9El8Y37Qj7GTBG5/urG+I nZJ1siMns1qRo7GPNCptSDMk9lvS6bYBf3a2EpwS9DPmHgvB65I5A+dF49+t1bnJW5Yid5rweexp HofB0pjOy2UaL6I3o77O6TzugTqldKN5xbn7EBI6iIk8CK2kG35Ogw+r++TxkibfSvNCWOogmozn OqRkn+0crybDn7WMTzKeBAztvOy84Kxn/lWmtxnlHnSyKkvVLG6/LOdX6qsto8XoeUM1y4QhMVWV sBZ9KV/mTPFiPh1Nz2k/lb5rri4umTnFD+YfdNpO0TuVYdmsup31dDU8zZNXbCRa5mO3rc+n09Fy OaPda+mWwLlLKEkH7wffAICkpCFlbmRzdHJlYW0KZW5kb2JqCjI4IDAgb2JqPDwvQ291bnQgMS9G aXJzdCAyOSAwIFIvTGFzdCAyOSAwIFI+PmVuZG9iagoyOSAwIG9iajw8L1BhcmVudCAyOCAwIFIv VGl0bGUoMjAxNjA2MjkwODEyMzItMTM4MzYtdjVhczlrZWYpL0Rlc3RbMTggMCBSL1hZWiAwIDc1 MiAwXT4+ZW5kb2JqCjMwIDAgb2JqPDwvVHlwZS9DYXRhbG9nL1BhZ2VzIDE3IDAgUi9OYW1lcyAx MyAwIFIvUGFnZUxheW91dC9TaW5nbGVQYWdlL091dGxpbmVzIDI4IDAgUi9QYWdlTW9kZS9Vc2VO b25lL1BhZ2VMYWJlbHM8PC9OdW1zWzA8PC9TL0QvU3QgMS9QKCk+PjA8PC9TL0QvU3QgMS9QKCk+ Pl0+Pj4+ZW5kb2JqCnhyZWYKMCAzMSAKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAwMDE1IDAw MDAwIG4gCjAwMDAwMDAxNTkgMDAwMDAgbiAKMDAwMDAwMTQ4MCAwMDAwMCBuIAowMDAwMDAxNTU0 IDAwMDAwIG4gCjAwMDAwMDE2MzIgMDAwMDAgbiAKMDAwMDAwMTcwOSAwMDAwMCBuIAowMDAwMDAx Nzg4IDAwMDAwIG4gCjAwMDAwMDE4NzEgMDAwMDAgbiAKMDAwMDAwMTk0NyAwMDAwMCBuIAowMDAw MDAyMjY5IDAwMDAwIG4gCjAwMDAwMDMyNDcgMDAwMDAgbiAKMDAwMDAwMzgxNyAwMDAwMCBuIAow MDAwMDA4MTU1IDAwMDAwIG4gCjAwMDAwMDgxODcgMDAwMDAgbiAKMDAwMDAwODIxOSAwMDAwMCBu IAowMDAwMDA4MzU0IDAwMDAwIG4gCjAwMDAwMDgzOTUgMDAwMDAgbiAKMDAwMDAwODQ3NSAwMDAw MCBuIAowMDAwMDA4NzA3IDAwMDAwIG4gCjAwMDAwMDk5MDEgMDAwMDAgbiAKMDAwMDAxMDA4MSAw MDAwMCBuIAowMDAwMDExMDQ1IDAwMDAwIG4gCjAwMDAwMTEyMjUgMDAwMDAgbiAKMDAwMDAxMjMz MiAwMDAwMCBuIAowMDAwMDEyNTEyIDAwMDAwIG4gCjAwMDAwMTM1MTcgMDAwMDAgbiAKMDAwMDAx MzY5NyAwMDAwMCBuIAowMDAwMDE0Njg2IDAwMDAwIG4gCjAwMDAwMTQ3MzggMDAwMDAgbiAKMDAw MDAxNDgzMyAwMDAwMCBuIAp0cmFpbGVyCjw8L1NpemUgMzEvUm9vdCAzMCAwIFIvSW5mbyAxIDAg Ui9JRFs8YTBiN2I3NDQ3NTc3YWY1NzdmNDdmZjZlNjA1NTU5MjQ+PGEwYjdiNzQ0NzU3N2FmNTc3 ZjQ3ZmY2ZTYwNTU1OTI0Pl0+PgpzdGFydHhyZWYKMTUwMDQKJSVFT0YK --001a113cd22a7a2050053710e70a Content-Type: application/pdf; name="2016-06-29_RevCom-recommendations.pdf" Content-Disposition: attachment; filename="2016-06-29_RevCom-recommendations.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iqcpz5041 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDIzIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDMvS2lkc1sgMyAwIFIgMTEg MCBSIDIwIDAgUl0gPj4NCmVuZG9iag0KMyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAg Ui9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBSPj4vRm9udDw8L0YxIDcgMCBSL0Yy IDkgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlh Qm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDQgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1Ry YW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAwPj4NCmVuZG9i ag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzMDQzPj4NCnN0cmVhbQ0K eJzNW19z2zYSf/eMvwMfxd4JIv4RZKbTGUlW2mSanBv70gc7D4xE25qzRIWik+amH767AEkRkkBR sq9zzZCSqcXuYnexv12A9QaX3o8/Dt6N31x4wU8/eaOLsffl/CykjCgvgH9SESW9fkAC/Z9UzFNc ECa96eL8bPBmkdyn0rvIvN/Oz7zJu7E3GObF/C6ZFsh3WBTJ9CGdeTeD62z1aXD9fZUOLpP7+TIp 5tmyFDi6Bk6vqReTOPSu787PqBZNvTAmUSg8JULCIu8aBAZEcPiVyIDBXYTcy+/3Pf3w8/nZTc/z P3nXb8/PJiAAhWzxDeOYMKb53vQ+pF/H2cLvUwbDJPw5he+8ly3gGe+l8EfQW870RwK/g/p+P+ot 1w4RjDESSluESx0RgurUpmUxavFWy3tapo6RMhBERt2kyECReGvSLAABtEdD1xgekpZJtDp8lBVF tmj3OfPifQ7n6EphHO6hf71Wd0qgB883RrXRckKFm5aiPB56TMHEpQg8hhbI0/Ozux/KCX9BAlgP VBMFMZIR+ABKoSl//8FbAm1jadHN0ip5g3AcRrdHNXWlLCJSeEIQFYkTwv+NH/UmEEUTv6/0Fwyp K1/0Cr8vIYrR9Us/7M0wwpN8tvbgtyFc63WGj6Zzvy96SYH3OQ7JfKUHeJoXMG1aDhLAcdNjISVR bE0P1YcrhOnoiTX+NlP683kCJYnV6fZ8oWkrSYQ8XQuBrtE3iTdU6hfwWYYOSvEJuDHs/er3WS9Z gsPSispcz9CcS0ao/BsdxmVI+Mmm0qglADem4DrveTOHyIn46T67nKM71tPE5+Xi+wY+Sr6Xa+n9 W9+4KEBfRfVN1q7GH/99NXzOHETEQaPnRL8lXKfCZo5jp+U4TkEfzMchO8myD35sYh8Tk471Vxj/ /wCD0cpyCr9wvLHqUVwbuabSxte3sP72IuuGQRgDWjTn+L9OdBqQTjbqS+X3mEh1uhavkz8AwF7V Jdkhl8radfUjWq8iZVwdv1AmjBgJ+N/oUR5BCcxPteVLZsJYEvmM0FrrakIDU112EJ0d07LOLm+k wrT8/nlZL8Da9RlLwRK+L/HxrTaGsn01bSgjEoabmhbLM5jmxK+u/fUqDQJdtW9G3/T6TtoQujaL FCADl8JVkeDncpbk+DmDdbDGRTDKEjR9Pmul+pBCQv06x4SQgle+eWMfa0EYaJqjeVGY4kPoy7vt oY/NqLFxI5De+s6anEF4hrbiO21G0+KiYfFtMwO+BZueDlSYZqhN1cYJnJ6paDNn80ZjQbjNqlUf 2aIPgyRY8rhxiFNQ5Qib1PjtaoQVebJC+620T7QpvyaPr/AHHuD9LU7maVkZn0EwBc6GjimBJXBT 1CcXaUQxfTdJW40QbnV2jmUAHWvt5Juy33jE8HlE7b9W4VLo+Zhqlvee/H4IAM8xcZS9yMIvraF/ K6m4Jnqsx8JjXRnwLaYzrLey4sGUDNDm599MkwO9T0pcFuESMoOyp9BqErWdGSjBpnPXKjKGVR51 YRm5Q00qhe2iYfJ+8rtjFtDMU7FF3Soy3nascxahaNknsPrhoLNlwOZxyfIS0k4ELgrgYnARCigy GroWMQQu2LTJwJk4uSQstEiZltPHEkLoawDXWC/B3Gs8uoArT+4KzJMXpW4k8O3SyW05BoUEVZbk 29548Os7DMdbf4fHPktxSJ/QUDZ5dBPOmdgW/mYymWD5fJEncL/DvQIPJoPIIHH7C5oWWDq5T4VZ Q0CARGgT6Dkz3eA8ura5IoSnNjVrSlgO0vZ9guijFTiwqSe5AigvR2kzpkWOKq6yRx9W+hxvBc5u iTMb5mmCiQeu9zo1FN8Q3PL/AIF7b48TxW1JrtBiLCJK2bTDpxnI0Ipk3kf4lNqYaWbKVtEb5ZjT 5jjbe79UeYkGuHdlJsFJtCXFZScuFFHUpr2FNAz58eMIQPoKu9J1kS5aLAC1EjbmnSwgOMBb3E03 AeUc27LsOEP35ZUd0CApBAJg3gLaA7MWQ2z62sMCY52WLK91LTB9WAJHKBCSR/zQUIsIMsOgwb8m M0wAJmAy4xL8rkNRxxISbdRLp4XerjWOde8Mh1SvuqZC7cmStuR8CoWt6sSFubmIWKE7q6JpirGQ LWBaGAPG2HrnQpsrW7qyKG6ShDazVy5ahUvbInU5kELJorZ0HF6CSggHH/4FXz66imcGjQFXbjG6 EK9tIImKvTjEpi3A3V1r09cy5U7F70IvEQnsExtFf7uPWgpbARaTrUj422fw1hMG7z5g4hVZR2Ci nAhqSz0amZikJIxtJh3FS7kjfg82IQ458xyFrnBL+A6OcReMwWKvl3gTe8QBTNneNdnnSakIq9bs KfhDARdxoTX5OEsbMGRsk77DRT3TsJPoycNch9OpqZh9SGC6mB5nWDbDNGHFwySpVvEWZw/U450A 2FgdkIHbAt0ekpgJLdpRrgt8io7pG/hL117tNVTi4zzHA7gnX26l4pHfjzdAsRk/s4qTkrg2fLuv EFgrJNp1EBpquIC/TZI06VJH5SvvdV6mTf3UuwSw0iihmeCz1eGUygNOWGxr0Z5BZOfUxPWhYxee O52dkydVhMYvhSNNZgdwpEl6CEeatEfiiEuMhSMQ1CHvhiOd+0MBcaBkdxxp6RJ5HGxqKzeO/HcA jmpiiP4Zj7zFnlXjSOKgNW5DNyUejyGCou0tJh3FC7kj3mAIVQcbnHZgcFSvga6sW1WtaUFfKW3a svoMTUo+ondpTWFchSSOnSnM2T1TaNassU6IgdWhtuQ4FyFmncimbaZ8vjfjG4qqHTL5vHu3BtVf FHdTjwcUOzuLdk9+xzMm3LRdPvgGQ5eAngCRm981MhSZ3mPdml7VRpQNHT/ov5DjmyRGmewOHR+B nAAuBhcxmxShvjb1SYXvuhwR+ybhsBbXmwmW0PZcE3dNYrh9xjuhGAu6Ig6H5jJ6KcSxmLUjjkV6 AHEs2uMQxymmiTicS7RrF8RhtLOzGMfd366Iw1q6Sw49KnUiDod4/gwuwmpogItjb+NyLPBA2yVt wScAD0OzWky6Ak+4I94JPM7aWGDr1OChD/FYbE7xigRPaWYanwCcJsVDirbLlyYremgvvaWzgEWw cC93Ecd49NIUg1KUkXJoU4XFEJ60HKZHoHsfvkOpu4YVx3pTU6Br8MRpf8cslOvXkFbpdH6nT4+m 5n06s0LXjW0Y915feaLekF/u9emRSQUUmAjcc+d4hshtJk5g4LoKsWgvnbQKz1gs2qqoqPuBIs31 ezqb6oJWwP8z0OCKGKzRgWgPTBW4PtIc8b4y1SHnRBxVLnHDffQkoy3ar7WTkrIEutLOXN6jhXUh knrX3zDENJCti3SmlyboflmO0i2a2R5b1cojyzE653PdXrtebGQxxf7f0qs9AXXek2GQwINO0MZE VxjCeFT8hWDIYtYOQxbpARiyaI+DIaeYJgzhlg108zUMiRYY6tylMqEb4M4wFLphiOF5kDoEQ18O whA/FoYswafCkMXkKBiyRj6r/5ng+elDivXsMi3qraP99fGB5ERDzL0bZ3QCjQYuiCrf49bcTsI3 mlfJ6EDixSpalkwbudeR3CNKYmrr7wSNSGLXbtHaPZ4oC3kjuq865f1/Hj4Ew86bWacdaMSVaa0Y +Bvni3MdDa+cb57IiHCbk7MDhG6BsT1St8Bc1BM+IJtBq8BkN+GYdyBFbAl3nb0wXTc0adsTSuct GhrhZyeeUVdYoQDPgr0QrFjM2mHFIj0AKxbtcbDiFNOEFRQD2mtYkXEM9a8bVjq3ohiwtDOq8MCN KlTEm5dBnKiSDy7gp71wQo+AE6oN3pR4Apzo6sdi0hVOOJ5kWyP/X+CE4hlz9TKLbi2wuLyr91qm SVEf5WLhvB9K9rUOnZHE2WRIHepNBZ14AUjNqE37ZlloC61X5qOqxI3ikz/A2CutGL6ct66RQ2ff Stu70uzGFM63MyL8H2Ociu6uis57CZTxji/ScdY5NQYxbiS+UGpsMjuQGpukh1Jjk/bI1OgSY6XG IEK7dqm4eef2CLpWForW3PgXG9VoTg0KZW5kc3RyZWFtDQplbmRvYmoNCjUgMCBvYmoNCjw8L1R5 cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDEyNDUvSGVpZ2h0IDExOC9Db2xvclNwYWNl L0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvU01hc2sgNiAw IFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMzQ4MT4+DQpzdHJlYW0NCnic7J0JfBtXgYdV oIUeoJ70pGoLLMvCIsp9T3pSdpcVC704VWDZXVgW0QJpoYd6pGeaqFfS5lSvJHacRInjxLfl245j R76P2I58Oz7lK/GRFO8bPWn05s2bkeScdv7f7/vll8jSaOQj9uf35r3ZWQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAIApOAAAAAAAAAADg1GH62g/niT+Kz6/H5Z0xeJfpG7F4t8Bvct4Tg/eavqXnjyN+m/Un Yr/zUx1/FlLi/LnARcRf6GgPeRPnfbw3U3+p469kb9H6a95bqf+p429Mtwn9r5C3c/63yu8q/o/A O4i/1fF3pu8J/d+I/8L6e95/Vfw/gf9G/IOODtP3hf4x5L9z3s9rY31A4A84/yTwP7T+mfeHWv/C +6N4vHNxHN4Vp3dTH4zbe47Ne+fuWcQfx+H79PwJ7/tj9gOKP43i2Yaew/ozlR/U90P6nhtyccSf RzxP3/P1vUDoL2Q/rO9H9DXre6HdyIv0vVjfS/S8b/Gl+l5m6Ef1vVzfK/T85eIr9b1K36sNvUbf j+n5q8XXRtMSs9eF/EtUr4/ZG47Nj59cPyH2z1o/HtVf/knrDULve0DxeqqdeL/idcRfUP+oaPk5 q0P2Z45rI/7h2p/+4WOKP/m/axR/TPz91dR7qf97FfGekFfe87sr7w571++uuOu3Ie/87eWy/yP7 I9mP/ui/ZX8Y8rIf/tdl/xHyUuIPfqN4iY34n9SL/536a9nv//qikL+66N9kL6T+6y+JZuq/EO8j foT4Par9w8Q7FH9xwXcZb//5+Yq3/fy8234W8lbZc2/9qewtsh+S/cmHbg75QeJNP6aes4h6r6x0 79kh7zn7O7IfYP323dT3K36LeBf1fdRvKt5JPIv4DdYfUU3fiLMUTn0HnRnev+EUuVHsAwZuis8/ JcRjYsQ/UzcL/EuSxi0hFytu1bjN9CCnJ+JD1O0ad5j+ypos+zfqzogPpzDukn2Eujvio6mMabKP UdNDOokZjJmmxxWzQj5BzGbMMT2p6A35FDE34pI8xnzZp6kFEZ8pZCySfZZaHPG5EsZS2eepe0K+ QCxj3Gtaqlgu+yK1IuQy4r6Iy32MlSaXYpXsS9TqkC8TayK+UstYZ3pVsT7ka8SGiCsaGZtMK1n3 m15XbJZ9g9oSchWxNeLqA4x+0xrFNtm11PaQ64gdEdd3MnbJulm7TW9y9pje4uw1va3xnYO87/bx bujn3TjAu2lQYIKOiUNiN+uYRBzm3aLjVmpA4DZDPRHPErrd0B2y79Mz2cj3E3eK/YBiSsSzRZ5D 3MX7Qc7dsh8Sea5iasTzRJ5PTIt4gdoPM34kXaVZ7YWMFxEzIl7MeEnIYeqlxMyIlzF+VO3l1CzZ K9ReyXiVYrbs1WqvYfwYa87wtYwWtdcxXu9VeYPajzN+gpgb8ZOM/6D2U2r/UTFv+NNq/4nxM2o/ q/afFfOHP6fWyvh5tTcyfkF2KGTB0BfVfonxy2q/wvhV1sKhr6n9OuM31H6T8VusRUPfVvsdjZLI RSJvkh3kvFnkLcUCbxV5m8jbY/a7IQfi9Y45+T2x/Zx3KBb1cX6XWnhQ6O0FvZy35feEzOu5Na9b Nrf7FtmuW7yyN3s7b86RvYmY3UFdlNVOlTKJbbIZbd+R9X8n3f9tYtqBbxFTW4nf3E1s+cYuYvPX U4j7v75z/9eIyU1fJe5o/Apxe+OXtzd82UOs/9I22S9urSN+YUutbFLtjUk1N26u+fzm6s8nVlsT q6wJsp/bVEn8540+4mc3EPd95l1ixWfeqfgn4tvlnya+tfcfiW8Syz7lJu75h/Wyn1xXSvzE2hLZ NcUfJ64uvmF10Q2riq5fVXj9G4XXv1543esF160ssKzMt6zIv5b4Wh7xY6/mEq95hei9+mVizlUv BXVlX0lcnnUFcVnW5csyL3+RmPHRpbKXvZBOvPT5NOIlzxFTL3k29eJnd1/8zO6LiE/vupC4JIVo foq48yNPEpM//ETQx3dcQHRuP5/4GNFzHvFR2XMf3XbuIyE/9PBW6gf/Rtwi+9ct5/w1SfahpLNl N5/9oOwHiIsTie8n/oWYQHwf8c+cm0L+adNZAjee9YCsIE/kfjlVMQWPo/OxTLVZijI9Pcr0eZQp yjS2Mk1CmaJMUaYoU5QpyvRMLNNPokxRplDX+VimJ33M9CGUKcoUZYoxU5QpyhRlijJFmaJMz6gy 3YEyhSfX+VimJ33MFGWKMkWZYswUZYoyRZmiTFGmKFOUKcoUnkDnY5lizBRlijKd52WKMVOUKcoU ZRpPmX4TZYoyDZfpIpQpyhRlumCdj2WKMVOUKcoUZYoyRZmiTFGmKFOUqR9lijJFmS4g52OZYswU ZYoyZUSZokxRpihTlCnKFGWKMkWZwnkvyhRlijKd12WKMVOUKcoUZYoyRZmiTFGmx6VMd6JM4SkV ZYoyRZnO6zLFmCnKFGV6ssuUi1OU6cku00KUKcoUZYoyRZkuSFGmKFOU6bwuU4yZokxRpihTlCnK FGWKMkWZnvKqgscuyhRlijKd12WKMVOU6Twt02GUKcoUs3lRpvGUacc8KtNPo0xRpnAuokxRpijT eV2mGDNFmaJMUaYoU5TpaVqmt6NMT2mZPpzd8PtdNShTOH9EmaJMUabzukwxZooyRZmekDK9FmWK MkWZokznbZm+UNQyGyRame5CmcLTSZQpyhRlOq/LFGOmKFOUKcoUZYoyPYPKVEKZGpapfXvlbJiR yZkvvJGnV6YXnagy3YIyhXN1wZXpX1CmKNMzqkwxZooyRZmiTM+wMsUKSCjTSJm2oUyVMv3SmkKS orMMNX2jH385G2UK548LrkwxZooyPbPKFGOmKFOUKcr0tC7Tr6BMUaZzLdObUaaxlemnVuTW9I3N athU02WwAhLKFJ5+LrgyxZgpyvTMKlOMmaJMUaYoU5QpyhRlemrLdN8pLNPUln7aoUUdw4/kNC4t at3d3EdveTi7Id4yzfcPaAs3/8CAUqZ5BwR3iBGlTG9+PWfOB1m0IkupkjkfxNt88FQnGBQad5lK K7I52Q7l37pSrHVZmlKjzO05Ir1U6/J0pUyl13N1fYOaR7S6suIqU9vbpc7MBm/rgKKroMW+eZ/5 iV00Sy3PZ0qri2TXEItVrlUsUWTL1LLMK63bo3L9HuvKImGZWl8vkdx7JXe5ol6ZSm/tU7Su2quU qfmFAultX9BKom1zrTOvLWJ+m/ROlfROdYxlal1XKW2olTbUsVpe3ycsU2lTQ9hGKUFrk/nVSmGZ WtbWSZubFR25Xc6S3qAHifb0DimpxbKuIZYytW5qce7p97SOebsmqK7KIUf+QctbLXMrU/P6A9KO LtlkYrei+c02gzK1JHQ6SobcTePenkmqe/+Ec9+I1dMrLFPzu932gmFX3bi3d0rR6RuzZQ+ZN/QY jJlatvY7ykbdLYe9vdPeg7Ku+gnH3jHLtv7Yy9S6e9hRPu5unfQenJHtm3E1HnZUTFhTA0qWWpKH pewRVnKLXpla00ck7yinJSWglKmUOxaTebKW1FHSodYs8vfxiPnj5p0jellqSRt1VB92t097B45Q XS1Tf6w+fF36qF6Zfj5nbFHBeMhCWb0yvalw/KaikDfmjqFMUaYoU5QpyvTMLNPPnroyTazroZ21 uqKdZCn9e1HHELf8kbpMUw3KNN8/qI04kqXKmOkxZikt05vfOKYsPQtZupCNr0y5j6yva5jN0lg/ H1r6lCyN4yHhLI35If0xjplKqwr8w4cMDuUqbCFZ6gl/+cdC4PAMO2bq6xkV30c0Zur1D3H3tG2q FJap6vX6A8qYKQnSGM/TXXXQ8lqZQZmal+8RPtDTNCQcM43lSb0dY9a36rkydRbH9O71j06TSjW/ XissU+vGFm/nhNFTdx2aQ5k6ivqFR7Ol9QrHTM1vtZMaNXoVY0csid1smTpKA4Gp9/TuH5h+jxSr tkytyf0kRY1e78HpUJzql6mUGfANHzE624mjcn5uGnTW8F8m5BbhmKl527D4fPpmlDFTg2fU4qw/ bNo67O3nz5OUqTZIrdlj2nuyeHpmInHKZClJV+6eP9gzISxT1YsaOIIxU5QpyjTWMi1AmaJMUabH oUyXlR4g34BGpmYezW0if7LflUYmZx7JaaQXnMZVpgVtoiz1DyizeY8pS8OzeY8pS1dmKbN553wQ ZOnpbRxlqvnI9p22Were2xbLbF775oroz946YHpoB/kzxqeWH3JgUJnNa3nRq3e38ICpqky1WeoP HDY/m6stU9Uz+oeV2bzSW77YT5VgT27SK1N7yn7hQwKTR4SzeWN8RvJwKaGJLdMYs5RC4tS6YT9X pqRJA1NHoz5WZzZvo0GZ+gamhIdyVY9oZ/Oa32z3DRqlIkXa1aeMmbpqBReGcDh9Y9xsXnthIOqj ZmnSFo3olamrwegXMpGzzR6JnqVMmdr36Fb5HLO0jmbpDHe7lDfOzea1l8f0igIzf7+v4hBXptos JXe7cNeItkzZ++hlKcoUZYoyRZmiTI93mbajTEmZ3p/RMBts0tX7OpRvRuzCR+Tvq8rb6C22TWUx lqluloavMz2WLFWuMz22LM1WrjOd80GQpae9sZap5iOrylJveEJ7lM+H+LPUXeaPN0udGXVRrzM1 O3cGDvM/6ApOeM5ZGixTx646vbs5djdorzPVZinBVdKuvc5U9YyhLA2VaeynSrEl1QnL1NMk+D+K Yl1fpS3T2J+RlGloQm+wTOPKUvnhU0e5MVNf/+FYHqh/nam4TM3rWvUO5R+b0V5nSlo1ltNQpvKS Po3l/kyWymUaY5NGni5lUFum7tbJGB9OJ/FGz9JwmXq6dMNc8o6SJrWkxHf+cpZu0c/SrfE1qcLn c8bYMtVm6WxwaFV7nSl7B4MsRZmiTM+0Mv0SyhRlijI9wWV6f6bcpLX942t8Hew3o4Tano5R1Q9C D+c01vSNkThd5C6mZXqpYZnqZamyAlL+sWUpLdOb3/DO+SDBLA2tgDTngyBL54MxlanmI2uUpYHD 0+SWiC0hnek1Spb6hyb4h7T0abUn7NHLUnIEb0u/Vnvi3qgrIDmSq7ij+bpH7JsrpFUFtrdLXQUt NFo9tT2mh7YbZym5p7d1UJkM7KnrVVZAYmfwchXsPTCkXQGJ3Ch8iuBFpqoyVR0qkqU52iz1Bya9 bQGir1c8jCVH4ovFXJmal5Vy92H/6Szo1K6AxD/vyJSzsMtZ2O3rE/SCPdWvXGeqzVJf32FvxzjR PypuHHfdsHKdqbTlAP/Uo9P2zC5pm5/o3NNPD+LrnzRcAUlQpvacXuGzUywb2tkyNb/Zxt0hMPWe syIgpfQSHSVD3p5QCSorIHna+PeMp+2wLWtQSu23Fwy7m0NfIGyWWpIOas/E2zttLxyR0odc9ROB aX4+sH/8qDmhjy1TW25A+Ip8w0dcjYed1Yc8nVPKcWiW2vL5ueiCLA2WKXsC3Mk4aw+TLCVxKnz2 yAlPHCURqjzWVjROspTEKXe3SJZulefuCt4t/UdIq0r5466WqcDM3/lnOfQee53p4w3iTqdTedky ZQ9lnKUoU5QpynThlenNKFOUaaRMK09mmT6Q1TgbbNI0zQ+lv0yuejS3ibsxrjLVzdLw2rzCNZHe rmi7fW0+8ba1ebJrqLnEW1eHXZWrrM17yyqv8FvtTa9n37RS10VBL3x4i7I2r/Ag7rJWaUWW9Box U0/r0l2nurlgLEYvU+6jb5yl3FuFa/OS5FQ9hBlI1VublzsHeVR0rmvzeltV1wySqDQ7U9i1ec2P p5A4deys1q7Ny1UqaVLh2rzmp9JVXy8Vndz5a9fmdRXzaRM6PXkqr5ctU19v5OdwOUuZtXn591Ke 3xRanjfPvLTQtYc/DYIjo5VbAcmWVK86+Wr1B6t9VLs2L5eu8n3Ca/M6stu5Z3TXDCpr82qzVNrc rKzNKyU1CwdDzStraZk6S/kxR4u7iVub15Hf664PRFubly9Tz4FIyPsGprgJvXZvH7s2r7STfxX2 3AFubV4p5aBvcFpZm5e7pJQ0Kbc2ryWp19N+2JY9pCzP6+3lJxW7mw+xa/OaNx0kHcqfCZ3KGy5T 7R1IA0qZAW5tXnvJGLmdrs0rZfMDwfLkXk2W2gpUeeg+oDpbX+CIcG1e7sh0eJRTm6Xm5BElS7XX k7rbplWLIKWPkg7l7hOZyuvRzVLyKDqVVylTdlxVzlKszTsvyjQLZYoyxZgpynQel+nmBvmX0sIm HZmaucqV/ZV1RdpvYQ+rrjNNNyhTvSxVdo0RZumS7Pq4do3Ry9J4d40RHsSZVo1dYxaQUcrUP6Qa a4s7SzVlapil4jLlPwPTtVka636mXJbKk3Vj3jXGKEuZMrVvqWTvpr3OVFq3hytTZ06L8GttNjKV N1SmJEUjJyBnaWTXGP69FMlSuUxNS/K0ZeptG+HW5nVXRUbl/COT0oYa7iHaXWNIh6qOGclSuUz5 Z+wYU3aNcRbxQcftGmNeWa0dNrWnd9C1eZ2l/ADiMewaEylT81rVx8JR2O9uVL1Ad+MYu2uMlMy/ CuvWbuNdY7j7u2rHjHeN0Q6V+sePaHeNkdL50PMNzSi7xtiL+cFK0p7WXUPGu8bEmKXuA5G4808c tabzjzJ7hmPKUs2uMdosVZrUksq/Iv/Ee9rVkKQCfraAb+Ro1CwluNun2V1jBFmKMj0xZXoZyhRl ehqUqSBORVmKMkWZnrgyTQo26cjUkeV7BIMXiXU9dNeYok7BkoPKdabBXWN0y1Q3S8P7mYqzNKc+ rv1M9bI03v1MhQcJZSnKdOFoVKbeZtWPxPL0bGY/05iyVF2m0bJUUKb8Z2B67Zz3M/W28CusOpKr YyxTTZYOCPcz9dRFpoD6ekZNj+zyHlB91buK/dx+ps6cZuHXGiU8lTdTJ0tDZcq/l1RZGhoz1R6c 28+UHfp0lXWbnuV/C2fb2siVqWGWlnEPD2dpuThLNfuZ2tM14610Hi/J0hI+1tz1w+Y36o+xTO3Z qhm81s3t9hzVEwWmjrL7mUrJ3dxp+AanLZs6DcqUu39g6j1pd79BmTr28JXnKBsR7meqHQ8NzeN9 56Cngx9vdVZNRN3PVMoSZalmP1N21q6radKUqFlZunBMO2DKnw/N0qRYs9RRyb/JUXVYuHGMdirv hSkjUbOU8IPSCaVMxVmKMj2Ny/RKlCnKFGWKMp2fZfq5dSV1A/LvVEenjqyt7BJ+h1pWeuCr64tv e7eMXQSJhZQp/cummi69MtXJ0kE5S4NlqpOlDec+ui32Mr1lVa7wDEmWxlWmwoNEshRlunDULVOd LN0YX5YyZRpDlvJlyn8G0iw1LlOdMVP3XsFvnPzDh+ybK7jZvNoy1clSVZman0pTnWr2fpKl5E/2 RrlVQ1kaKlM2S8lbA5Oqy1HJP8NTeTN1slQuU/69JGep16QuU29bgLubdU2FkqXcDF7p3RrTM0Xe dlWYuMp6mCwtEWdpcD9TuqUp93Su8oOmpTRLy8VZqi5Ty1p+8Shv57jppSqSpfZ0wf/DpBmdpX3h OJ1LmbIzeOUFjl7fb3nXz7/TkjqUMrVuEcyOJribxsNxypepcNleb8+ULWtAWKbuZv5aVCltULOf qVymnnY+sqSMIZql2otPzYn9wv1MY8rSTewMXtUngK1gjGSpt0/1Oez2T8WRpUnGWTpMs9Tdxr8b hXvHELVzfRcVjGuzlNQrF7ChVXm3G2YpyhRlegaU6Y1smeajTFGmKNMTWKb3JleTGqXfblxl4ou8 KHdu2bdGp0lng2vzbqoJ/ea8pm/0C2/kactUL0s/8uROWqZ6WXreo54YyjSJlumtulmaGFeZCg+i ylKU6cJRXKb6Wbox+pJH4bdaX0xVypTLUu2SR/R2tky5z8Dgkkf0zvJKR77uQOghMYyZSm/kCT+r g2cy4y5vtzyXrlemgiz9azJXptwMXuur+aaHd0lrS7jnsizLZcuUzVL/8GH7Nn7qrKehL1qWZnMP ceb65RV61WXqzOP/f5PeqTI9nU+zlJ3BK28HE1yb11WmGg30j0yani1my1Scpc/vIU3qH+FH6KSE RjlLg2XqyOH/L1W2NGXLdFZDMEurzCtrDXaHcdcPS1v9sZVpJE7Na1XD1q6qYbo2L/dEjqIBOUvD Zert1l0Q2NszKaX0cmVqz9Nd69g/dsS5b9T8bjdbptoLS80bern9TKnOSn7CKr281LKNnyQgz+/V 7GeqLVOjLN0kmMFLCK6ANOisVb1P/BNH5QV7Y8/SJOMsHRZeWGreOSLMUmc9X+vyMKhotJTczt1T XpVXs2Yvn6UoU5QpynRBlOkilCnKNKYyrT5xZfpSeeRHo3VV3UqfUjY39H79rdJfp9SMBG+/c6tv Wal/NnidqSO9PrGO/21/Td9YUUfo50ZSqb/Yto8r04J2wQ8kpFVJltIyFWZp2/ChvAMDQfsFtsqy ZXrranGW5rb0KQqXP70voZQtU+FB/EPjpE0MdOU2nOrCgnMz3izdGOMGMZankpUxUy5L9WDHTGO5 /2wkS6OMmboKjGbMkjgNrnckKFNxlqrLlJ3BSw5F1+Y1L0nnnsW+tZrJ0lRuEq9wbV7bpkpRlmZF yVJ1mTrz/Nzd5Cxdkk/LlJ3B62kaDC+CxI94WlZWsGXKZSk5CHdL5Jj7h01L9waVy5QkKneHSJYy Zerr04SJq4qWqXDAlMXlGzSvaoi9TO1Zqv/Sbbu76dq87BAqgXRoKEuDZWrd0mm8fSqJU/Nb7WyZ KsvzCglMvWfLGlTKVJul3H6mTJbyK9M6q8ZJlkoZ/KeTp2OK289UWKZRsnQTP4PX0zlNW1XK4T8H LDsDXJnyp8plaZJOlm6hWTqszVJuP1ODLHU2TJpEWSrcMoZO5Y2SpShTlCnKFGWKMj3BZXrTgi7T G9/aUzcY+dVoSfcIUfkn6dM7Eivowrwdo6HvXEqWzsrLIo0VdQ4naMo0oaa7YyTynTQ4oTdSpoXt gp0gSJaan9pJy1SYpbHAjpnqZWlUHk+vYcdM53YQ7A4zn403SwX7VmhRrZIUR5YmzDVLo4yZOnZU Gh/KVdCiLVNRlu5gy9T8ZCp7B3dFR3gdJNWWMfKb9nWaHtltkKWW5XnczjJ0Ki+fpeH9TEVZeiCU pUyZCrL07WCWLsm3Jammy9p37hduGSO/KaVZztJwmepFKAdpUvMr+8JZulcnSyu0Zert4EcA5SwN l6ktuS1KEnZOxD5m6mlVZZ2yNq+jkB9tNK8/wJUpt2Avh29wmi1T89sdrpoo7zelTPWzlC9TQZZW jsurIWmyVL6wVL2lqbBMo2Ypt4OMvXScZql5G/+Mjn0TdIfTOLI0SSdLg2WqfY+x+5nGkqUmbZZ6 Ateljwqm8qaMRM9SlCnKFGWKMkWZokznWqY/SVH9GPZSuWolipKugGVFPilT9sa7mCylJNb1cGOm I5Mzq9SHCm0cEyxT/SxNoWWa79ed32UMO5v3OGRpsEzndhBk6Tz3BGdpbAOs7HWmvi7Bj6AcgcPT ca2AZHk2VXidqYJ2Nq9OlkbK1J7kY+/gzG6S1hYHLWFHUWfpQCrJ0nCZarJU3jXGsZsfpvQ09Amy NFym3J2DWZrDlalBlrIzeAm2pHrp3WqqP6D60d3TNBTK0mCZRs3SwOQR27b9ytq8Splqs9T8aqW2 TPmjTR01uSrZMjWvrHWWHDSIU3tGl36ZRuLUvEZ9CfDApLS9I2inNkttaT2mN5rZMjWtarV7+/xj M7M6uJvGudm8UspBg2HTwNR7dDavYZaqylQ3SzWL9LpbDvNZKirTqFnKzeAlWUruQPVPqD4inq7p UJYmHo8s3TLsC4hGS0VlapClTk2WEv9YzT+pp2cmpixFmaJMUaYLt0xj3MwUZYoynXOZZrRFvjNy o6WEJwpaSZnS5Xkpd23zLdvjV/5Z3Dn8WO7+kSnVzyEJtarR0t37+y57IV1ZAUkvSy9ckkLLVHjx aSyw15netuZYsjRynencDoIsnf/OMUuNljzSW7xXvOSR0Z4ykSWPOONfm9fybJozo54krfbT2F3e zq2ApJ+loTL1anaVMsD6WoFSpqIsTRNO5WVXQ4pkabBMuXuGs1RVpqIlj8pNS/LMS4u47UcNkC87 VbL02eJYRkut7hp21xi9LJUSmuS9Y5gyNb9Wxd1HXvJIzlJVmZpeqiZxak/v0G4oQ/D1HzZcASlU ptwMXmPcjaPBLOXLlMap3tWmoQFT9QpIloQu935+RJhizx+Ws7SHz1Lrjj5hmWqz1OYdJllq3cl/ Zob2jolWplJWgHsgl6XalZQMiGRp4pB2Exln7WG6cUyMWert538DYEkdFZapNkulgnGDLCVqp/Ky Q6jkrWfpZSnKFGWKMl04ZcrHKcr05JfprWdYmS7ObVGuJ11fzV9b2jk6ua6q64GsxuVlbcv3UP1r fZ2J9b1rfJ3FnQHuO9fI5Mzqinbl73aP76NLM0iWKmWqn6W7aJkeS5YqZXrMWZqALD3jPY2ylMvG YJYmxl2m+vuZmp073eX8yGlkS9NwmQqy9CElS3dYns+M68skuEjvbiqfpeH9TLVTeVUnIGdpplKm /PEjWRoqU/MLBdr2JE1KtCfzhWiMtKGGyVJVXzgLOk3PlXKLHXG7xtAy1c1SpkztqfzHxV07FM5S vkz19jOdjWxpypZpHVem3AxeY4KL9DbrlSnRli4YwA0ufyTeNcaS2K1doZduaepp49PMlj2kztJQ mQpW4k0fonvHaF9CaO8YwzKVMgP8AbNG5MtORTN4o0IX6aVKXv6xTJYOxZKlnm7NSrx545EsZcrU 081/EVmzx4yz9MKUEe22Mgo0S1GmKNMFX6bWM6ZMY1+eF2WKMj3RZfr9bVXKRabsCkhaSJZurhd8 f1dYXRF6eE3f2JfWFFz+YibJUrZM9bL0oqd30TLV29j0aW/j096Gp3Nkl7Bm11PZtXlvWyNebvTJ zFriE8QMzhri4xk1N63MZtfmFX9Hbukj9SqbVk10arRvLDnVSQWPi6dLlnKfge6yA3Q/0+NYpqbF 2/zD/CKc3H6m4iwNl6ljJ798rjHBLU3DWareQUbZz5SoncobOYFQlmbqZukTOWyZOtL4tZ68bQHT U3KWehrju6SdbmlqkKW2rU3cQxzZ7VyZGmVpuEx9ffzeKPa0dtPySuMyddfxs77DWapbpubV/AlH xbq53bhM7V5+6m84S8Vlan6H32vG2zNFstRRGuBud9WNm9zdsuoy9Y9rfu0QbFKit5ePOLoaknGZ 6mZpsEw9nYKxaQPolqahLNWsiRTKUmq4TA2yVPsmV/OUKkvDZeqfUA3pBqb/HipW/SwlalflVZCz NLyfKcoUZYoyRZmiTFGmx7dMb3yrLMMvB+Po1JH11fz26ArXvpZ39zbdxVJW7+ugE3oTanuuWJ51 xbJMkqVcmRpkKS1TYZY+42284PEdFzh3nO/cfv5jRM95xEc9ervG6GXp2Q9tPvtB2Q8QFycS30/U 3zVGeBASpOEdZDae9YCsSSt2jVkgirL0/lOcpcGHJM6tTK2uTL0y9baoIsLXPRLJ0gf1snS7UqY+ 9SUArsJWZ1ZTxOwm7wH+S9u8JEOYpeans9gy9dSLr8ZlsjRTJ0uzlTK1rirTDpU60ptNT+Walxay N/oDk868Nmc+sV2Ru7zUd3AimKVFOlkq2M+UPLv55XK2TKVN2ixtDG5pGipTZ7FgVq15RXVwKaRK y7o688pqYZk6S/gBUyZLtXEql6k9S/XfvrfrkLNsgHHQ3cBPOnUU9pMsNa9vtbzrF5aplMx/K5F2 yllq3dqtV6b+MdXHyL1/gmSpdTv/cgLT75k39HBlKqXyv1vwtE/S/UyJ9kL+/GeZXU25LLVsHyQa Z6l5i+rzmZySs+YQJ3d5aWibmFizdMg4S62Z/BFIb5qTR7gylfL5CdLutunI/F51lir7mVI9PeK5 CqEsRZmiTFGmKFOU6ZlXpl88WWvzbmmSf/yrG5zQGzO9dkX+3R7+WifKmnCTPpbbdKUrW85SUZnq Zukzu2mZirM0t/HDJEtjLtPb1uplaVJcZSo8CJOlKNOFL7fcUChL79fLUjqWelKydE5lSrc6tTy7 mytTqyuLmyrsqe02PbiNLVOdLJXL1PJ8Bvsm//Ahbj9T7Zams/I2MZWmR3Zps1Rat4fuZ0rL1PxM tnAqr5ylTiVL+SnE4SzNtrxcTP7OXpRKkTvxhQLTU7n2HaoBWXflQboIkrKfKbelKcWyopyWKZel rrIeukKvtKGOe4i8Qczze5gs5QeCw1laLiU0eZoD2pcsz+ANbxzjLO71j05LSc3aFZC4K0zJP00v 1xiXqa9flSeSp53dz1R2JT+c6jkwbnp9v7SjKzB11FHUry1Tj58fbrNs7DCt9suP9R/SXmeq3c/U URogWUrUXl7qbp4Ibh8TKlNSqdqhUiltMHjNqZyl5k0H/eOCVaGcVePsbF5zYr+zaoI0JglS4yy1 l6jmPMtbw6j3M9VuaTqrbBMTNUvDcWqQpcLLS+XkZJqUVCo3VCq/hPxxvctOuSzVm8obyVKUKcoU ZYoyRZmiTE9YmS7Olee5kTJNF62Ia9HJ0sT6XrqJzB/T6696KZtkqV6ZFnaIsrR96GKSpcEy1c3S J5JjL1O9LD1HztI4ylR4EHWWokwXuPzPY0qW3i/IUlJ2wb1r+7Rr50orsoVZKj8kuGeu4CErs4VZ qjzEP6SZdhutTJUhUfIXZ0a97c1ix45K99427apH9s3lwSzdppel8mq64UV6uRm87vIObj9TovXV fO4p3BWdwSzdpZOlkTK1bdw3q8HrHzI5M5Qy1d7BGDpUSuRm8NqTG0NZypSpPZmPsuAOMoIslS8j DW9p6q7WzGLdWK+UqX1Xa1wnLHf0a1VsltLbff2HnSW99vQOomtfv/aKTnfdsJylVFGZWt7kpzdz +5lSvV38jOJgloZm3vrHZlxVAUfRgC2tx1k+pF2S1zc4ZVp9gKjcQuLUWRGQUnodJUOeNv7gBEti t2ldB8lSaTf/npSfcfyI0zfq9I256sa1Sw95e6eYvWPkMrV5dVe09h6cJvqGIucsZQyTSjXIUk+n qpTlrWHU+5kSyY3cw5VtYuacpebtASVLpVzB5cCkQ0lsEl3NU4FpPiq9/UcMVkOiSyFFncqrylKU 6ako00tRpijTU1CmWJsXZXp6lallZf492/ksTWsdqO0fH5k6ctuGsqteygmqW6bCLC0kWfpsKi1T nSxtkrM05jK9fS3/AzDlnL8mxVWmwoNoshRlupDlfx5js1QzxdcAJUuFy94K0RstNXpItDFTbqau Hr7uQLhJI2UqeLpwlnIzeO1J+9j9TJUy5bciJWH7sHGWRsrUU8+/q8NZGirTWF6Xgruyl67Na36h gHuT5dXS4DpIqjK1ruG72NM0KGfpM9osHVGy1LKSf5R/ZMr8UjktU2dhV+wnTJrU+nYDu5+pkqVR Hjh11LK+MZKlojJ15KsORfKT28+U6qrks86W2k2M8SXY0g9yWWqMPIOXNCl1fadzXxzrC5FKtWzp Y7c0pWXqqte9XpJDL0ud1RPyDN4kzTfH5GFVlgbLlNzI3S24TcxgrFm6eYjcyJ9Y7ph82Wm4TF37 dXfY0UIq1ZI2GjVLuTJ1t/P/ZfFZijJFmS6YMs1DmeqWqXbAFGWKMj3JZcpdZ/qb1Lo/ZatGDZbv 8dMmvX3j3qtf9l79cg7RoEyLdLL0EpKlwTLVWfJokJTpM7mNsvLaR43CFZCUMtXL0iez6mQzqbXC FZBueGanUqbCg0SWPFJZza6AJK96hDJdEHIffV/X8Nyy1Py3LTRLY7z/7HHJUk2Zkt6MehASztaX stVZus0gSy3PpXO3m5/Yze5nqpQpt3spwfpqPilTTZaWMlkaKlPzM1lc1TJZKpdpDO+e4KubnHGk 7Vd2jeFm8Pp6x+navNoy5S5NlbeJeaZQztI2TZYG9zPVGzAlt8hZ+vye2LPU13fI+nY9t5+pt0O8 qYrqJKeO2na2mV6uVmWppky5GbyO/IPsfqZKmdp28yfsqhp27o1p7XRH0aB8wWnMWeobnDa/0xnJ 0mCZumpjWiuYNKl1Rz+7nylbpo6ymPKWZqljr2YjVJKlG/q5GbzyRaNck4bLlBvGJf+UB1ITB2PM UpKx/InRLI2/TP0T78kL8BpuaapkqUk9ldd/SPUqBFmKMj2ZZaozoRdlijI9Xcq0CGWKMj0hZWq8 AtLayi4SpMTvbiq/5pXca17xBsvUa1CmRR2CaVRylj6XSsu0oH2OG8QQlDFTvSyNhZvfyFHGTOd8 EG69VpTp/FX7wWWz1D8UPQ1CjwpfWxr7Z9HxyVJ1mbry9xsfwb23zfxYMl2blytTwdMFs9SZqS67 7hFuP1OlTB0ptdwR5G1itFm6tpTuZ8qVKTeVV52lGbPR8PqHSZCan89nd43hZvC6Sjvp2rzaMvU0 8v81Wdf6SJnyz0KzNFym2gFTgm1rUyxZSsrX0xyweVq4XWOozuLewKTgYsnImXSOW9/dryzPy8dp OEstbv5TwprQyu5nqpSpeQ1/T//ojC21WztfV3WfsRlbWq+yPC/JUr1dTUOveuo9Z8VIaBGkde1c mUq7+7XXmbK4mw/JqyFptjRly9Sytd/dYnQO/vGjFs8AyVJnFT+6SrOUm8Hrbp1Udo3h1K7WK+98 mqCTpYl8lnr7+PdtJEuZMiU3aq8zZXE1T4VWQzLMUnvFISVL2TJdVKD6j06cpShTlCnKFGWKMj0j yrTh1Jbpk0UHuP1MyT9dZW2jwSa9I6H8Y6/mEkNl+opRmepl6aXPpdEyFa6JFCPKbN7b1x1jloZm 8875IHyWokznrdJrmWqz2Cwl/5RdYWA2VclS5RZdV4ZUslS5RWMOq3V5eiwrIJkf3W57s8iZUefe 66crIHlqu8k/7Yl7w0Ea2TWGzVJpVb60qoCV7mdqeS6dvdHyfAa7nylbpuYnU6U1xSHXylqWZpse TrEszZHWlvx/e3cX01YdxnG80US90aqJt+vY9MZEqzHRxMScxAuXmBgujVfeekei8WKa2Az0Yi6m vmylYBjb3MDBgE3GpMjWAn0BCiljggVkhU5gvBe6hezO5/Bv//1zXoCug53T8yPfC5Il3H/2nP/z bNZL8Q29apk6PSHpdD/L6QnbvvFxlkq1Ual2QKMzg05vH1t/JO7mZTJ1VkWlszHpXCa2BElTpo6T fdJvw7nOD9t/iBBL6Rfp/C25C3LOmiF+0pTJtLQpTkkXRqS6TOw7XkdlTKofler/EYpLv2ey/xyz nRhgG5AUV2PEmanUMEE+dQ8u+JNpcijlisyVBWYcNaOKqzF6MrV7R6WmhFwza0pxz1SUqdQyLXc5 yXJenLJ5xmyecWfDVFlwwRVdInKy2DtTZ2NScTWGydRRlyz13XUNrLQk7vtnN6jasbRrcLW0Y95+ Linu5lXLlHI0zJb1rrr/ThNR/XNyrtha6fWlzHpe1T1TtUzZEqRPgynXUNo/94C9LXWP3iuLrjuv LvENSIRTqWNF7q9VFtvQ62xbljpXpc4Uy3FlmV+NUeT4Y4UcKmZvWiaW2pvl73jF+DYkkaVOX0ry r8kFqHVKflvKWSrIlHJcS5UN3XePbxBRqZaZB6TO0vA95XpegaWO9jWpO82zt6Y0WUq9cWOdcMqi 37VZCplCppCpaWWqh1PIFDI1jkwrwgnmrNPDMyOLmf83HllMu/un2e+fd8YPnOyidilTXZYeb2cy LYil2XemRwpkafad6UP/EQ2WQqbFU512mo+LM+1wNUbZTrt5t3Yx1x7cM1V/zau4Z8pfmApd0ZOp uJuXQCrUxt6Zst28uVQyZVdjZJDyhJmpuJuX3TOVO9YpsFQp00wVVEBIe2bKd/PKyR/x8kJsAxK/ ZyrKNFuv3HFWX66t90xtJ3gDu5GpkN4905s7zkw1r8ZoylTczSs0bqvkTWx/z5R/zZstkT1mqn01 RlOm2f6TqxVT3zOdUcl0lt8zzcUuxYjp3zPNxTQqpvM1r3bZezHKVF/zKu6Z6sl0S02sVY2at01H ppn0QAqZ7rFMX4RMIVPIFDI1gEzffqwyZVdj6CcykyoP3aYi2fUmX1wfc5zqPkCJMv1lO5nqs9TH ZFoIS/kGpCM1yjUmu/953+vnG5Ae+o8QS7EBqajLV6Z5shQyhUwh00cpU92Zqclk2mgMme6IU8gU MoVMIVPIdF9kKrPUYjLtndU4RN4Yv/taTfhYcPLjyzd3L9PqwSTJVGg5mFz2Dky99L2PydQbTZBM WT3TSz1T2nUnqEVFfDfvO54bXbcXN1vQaDJTQNk89daPPr6bN/DvPM+fT+6uOHbzFnvGn5lq4RQy tZZMhyBTfZliZgqZQqaQKWRalDLNG6cml6m1ZqZvnu1XvC0dWUyXVAbd0ek76xv0T1tmpps43X5m qr5nSizlMuXvTPnVmBe+a6Oe/5a6aq+gWp8rl8vraswzXzexnv6KuiR39NJTcvldjRGqz6S8F4Or MRbJ+DJVz0zVLIVMIVPLytScM1PIFDKFTB+FTF+FTPORqc4xU8PK1Goz0/2U6dhjl+lHzblzpeRQ Z21viTdYHpqk30mmDk83ZAqZWjLjyxQzU8gUMsXMFDKFTCFTyBQyhUyLR6Y/Dd5hLP2k9dahqlBJ VZBk+mFj7PWayEFPT06mpyBTyNRSGV+mmJlaU6YxyBQzU8gUMoVMIVPIFDItSplWRBKfdcQPV4cP VYe4TKmDlT1cpg7IFDK1XMaXKWamkClkipkpZAqZQqaQKWQKmRaPTF/+NXyY2kamnuKX6ZOQKVJm RpliZgqZWkamZzAzhUwhU8gUMoVMIVOrybQHMoVMrZrpZIqZKWTKWGoBmWJmCplCphaXaQAyhUwh 08JlOmEmmVZCppCpZcPMFDKFTA0sU8xMIVPIFDKFTCFTyLQAmb4LmUKmyEwZXKbqDUiYmVpBpjvt 5rWITM00M9XBKWQKmUKmkOm+y3SXx0whU8gUMoVMkcGCTCFTyNSoMsXMFDI1mEyfhUwhU8gUMi1U pnP7JNNrkClkikwXZAqZQqZGlSlmppApZAqZQqaQaXHJ9APIVCVTGaeQKWSKTPDOFDKFTC0sU8xM IVPIFDKFTCFTyDRfmf4JmUKmyKRBppApZGpUmWJmCplCpkUq01cgU8gUMoVMIVPIFG0JM1PIFDI1 sEwxM4VMIVPIFDKFTItLpnu7AakdMjWNTJ+ATJFGBpdpnvdMv9wXmR6FTCFTzEwxM7WkTNshU8gU MoVMDSrT9yBTyNTA/Q9aygdKDQplbmRzdHJlYW0NCmVuZG9iag0KNiAwIG9iag0KPDwvVHlwZS9Y T2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTI0NS9IZWlnaHQgMTE4L0NvbG9yU3BhY2UvRGV2 aWNlR3JheS9NYXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFs c2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxNzI+Pg0Kc3RyZWFtDQp4nO3WAQ0AAAgDoOhG vzH0G6QgAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACoNAAAlLieIwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvLPmDeRNDQplbmRzdHJlYW0N CmVuZG9iag0KNyAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMS9C YXNlRm9udC9BQkNERUUrVmVyZGFuYSxCb2xkL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250 RGVzY3JpcHRvciA4IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIyL1dpZHRocyAxMzIgMCBS Pj4NCmVuZG9iag0KOCAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNE RUUrVmVyZGFuYSxCb2xkL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDEwMDUvRGVzY2Vu dCAtMjA3L0NhcEhlaWdodCA3NjUvQXZnV2lkdGggNTY4L01heFdpZHRoIDIyNTcvRm9udFdlaWdo dCA3MDAvWEhlaWdodCAyNTAvU3RlbVYgNTYvRm9udEJCb3hbIC01NTAgLTIwNyAxNzA3IDc2NV0g L0ZvbnRGaWxlMiAxMzMgMCBSPj4NCmVuZG9iag0KOSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5 cGUvVHJ1ZVR5cGUvTmFtZS9GMi9CYXNlRm9udC9BQkNERUUrVmVyZGFuYS9FbmNvZGluZy9XaW5B bnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgMTAgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAx MjQvV2lkdGhzIDEzNyAwIFI+Pg0KZW5kb2JqDQoxMCAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3Jp cHRvci9Gb250TmFtZS9BQkNERUUrVmVyZGFuYS9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2Vu dCAxMDA1L0Rlc2NlbnQgLTIwNy9DYXBIZWlnaHQgNzY1L0F2Z1dpZHRoIDUwOC9NYXhXaWR0aCAy MDA2L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUwL0ZvbnRCQm94WyAtNTYwIC0y MDcgMTQ0NyA3NjVdIC9Gb250RmlsZTIgMTM1IDAgUj4+DQplbmRvYmoNCjExIDAgb2JqDQo8PC9U eXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA3IDAgUi9GMiA5IDAg Ui9GMyAxMyAwIFIvRjQgMTUgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9J bWFnZUldID4+L01lZGlhQm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDEyIDAgUi9Hcm91cDw8 L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBh cmVudHMgMT4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDI5ODA+Pg0Kc3RyZWFtDQp4nK1abW/byBH+bsD/gR+pIqL2lUsekgC2rMv5kDSG7UuL2vmgyJQc 1CJdiU7rQ398Z4akxKW11Co1DnJ09nBmd3bmmWdmOTpZld/n01kZvH07OinL6ew+uwtuRtfF49fR 9fNjNrqYLr7n0/J7kb9/H5yejYPT6+Oj0a88SKM0Dq7nx0c8YPAfD+I0SmIVGBVHIgmul8dHLFIS /hppJuCnimWwWuz67eWH46Ob8HLwNbj+/fhoAgbQSKPXmCi29d6E2Y9xsRwMOQ8Dx1OcJ1Ei7Kcu sxk8I8NiCc/KMIP/YWF+R/9MBzqEXQ6GSZivHTqFEFGsbZ0u+yqGHXJbVqQBWPmd7D3lmeNJzVSk Ez8rmpko7fhGMHIMj13PyDjq2UQw+TQORo64OC3Kslj2h4YI0l1xIfHEVRUXAYZB8KHXf6mIePuh m/BiOlDhojo5x9a4RHdYTzldx03E4rZsMGQRg19dz27C/zofEyoS9mOMnhBOd4NW0b+m0a+y4zQt ZcfMjlMKRhd4Pp/G52cB66Qn5xE+uCM/WQz51LgU4jEBrzL4CPhEcmDCbwMZPo/gxxn8ZjWdlxi1 +F2iBGYIir7cg9hhVDAZKW0bvQ3Ho4+fBkMV3g6C8wEkw8SVcBrOKLWfnkxgZQEs4Gw1HcThHL7B Ak14VWIKQzbHkMsyXMHnrpZEmWIVwF8mJXy9z1bwM89K+vMwDk+W8GQGj6pwCUJZjn/5xRUBtR/j VEayORraTXb3fcA1WUerJ7NZhsG6Xgdj0F/kaBuXVTwMCLgUub9ZLP5L1ststX4DG2oE7p8HSbim nAb9MpxNB0MTPuBXWv1HdMMz7mC1DmqFsJfdi5eGRTK1F+/aqDQQ6nLHRskCWl3Al2wJ66xc1rul oD4sPIh+xyaUMDWYwVMaPqj6A6jD2ByBMwT95jN8HnENK4SGEv1CLipyV1UwiCqWhd6s4r5ZFccx graHStEBS7dKTRDQKl0CKtcmRjFa0cEl7Dju2XGsQZut7Bend1iU2qLO8gqxYTprPLmoz/8Sz+WL M6lFHEnjNkPVYeMDHpkAiAaLYsYYD1bZ8dH8LzvcKr1PSqZIDDZ1aM9xqZberiaBhXQLpLwGUtZA JXc5TzA6k9bzQ6doHHHblBgM9cYOgvcIPmNEGkytCsfxV230Vv6ArSFDjGUQ8friBLAaou0c4BeA aILZ7APAjuIOFEfZRpw8gCUR0MW26BbOz4nO5XOwXqyW8JMSogUD+6AG+AJvsvaamMXsPkd8BguL ZwJhx7kAiVKxrcB5horD2i1Rp1qlEWstWQytYlXW6Y4ASNiP7LUfBfNFDZxXz/BjXWbL+v/P85JK 4LzWOXPxKamSiKd+S5cQOEzasrfhxWeMjHN07d8xcG6B5gOO3Q6gpmFEOQ4dyDuQZy/vKiEj7ele JQxVv7bsuFjVdZmcRiWNwPVpCWukCuukdgyaoMRt+gWYaF+Q0mmK8OqhMvYtJzqBiBWvVE4sZf3l xBLdU04s2cPKidNMu5zoROHqqZ6Ai9PUXU+M91EBpUgT73qSuOuJ1qnNzLGgqBrkVVVQzJaEq504 D7XBD+h5qrGyWEaJmRMOIjNHqJc7of4yg9SYQfTIVvRAgwjfcd0N95uVRIhnWTBH2lhh9sdsWudb TqFWo1QvTmtoVjcU9Gdw2lLQj9OW6B6ctmTPP8GerrBIjiF9YGVllmNCocMaVjz7Z51mC8QVG6XP 86qw4dku6yJq1zJd0e/iLntwUvYUQdhrDzIRUWJsWQgAXCqc/pcMGzM8pjXYFz21VGkdpR2/cVxn BJpEz+EqYyKT+p2NwsXGfhtTAAWdfW3alkf6dHzfH3uS3FTpKQs8hfIeu626q5tlj1ibnzBB6qZM tc6Jd1vQy4zal+IJyw6kxsmCphoVYcoW1RyqF4OxKkPFsxbWizlpD+bwFHX5tEKsRws06Jy/Vm1p K9tTW9qi+2pLW/bA2uIyY9UWHNtpr16Fc7crce4FSeFbTrjwrVMKoEGZTnWJ4aO37Yp5UVA4NRT+ RSWhps6ydRt+wXgg2B5dQuGgb1djRJWqzPw/Ex1S1ik4iFWwZCLO/872zRsUtO6Ama3i0qjL13Ow UHUW9XBla/jq6RtG87psZyyKnDw+YvY/VLVvWuJSaghf49qfENMf641UgMLrKQejz1DRn75Uc6KS JidnYydV5kjRrU24abVGIUv2r9RGULJWkDilxW+mS5gfTyWsEVcMX1xMWCD7cq7iZdx69+sK+gqz K/le6lS+XFjJNBLmlfDKUtaPV5boHryyZA/DK6eZNl4padCvXnjl3bcoQVzAG73iHiDkAnvAzWBe C0lz9gueJHx0BjQpDadzTK6SMuaM850XQi6ggl0Ly0g1xoeWdYLE+gpj4pTwCYHqJzDqw2ZMW6yp 5DcCOKtFgWK+1VARvSKvkactdkpdfUkD3uf9fEVC68hTiysTgFXZveXMLr6c0L1DW0n/ERr3EcpE ezIU3tMWSWiwlHylZLWU9SerJbonWS3Zw5LVaaadrDi2T8y2cU16krWH7Ulo9pg/uRDel0oS+qFY 70zWNN6RrLBlGt15JqvR2MS1jTTJupta4GQJwhyphe+gsssrzu/wTqNpFOabb3ZBx+JdpfGYcrdE Q7MSFfyNrnlJjpj9vrQFNi+bMPgD53XYT9eGcrTwGe3+IBi4x3Z7elcDxAvT7Xmf8y4b8gGjr222 Pxh6SKuELoJ51WgherQwHenXqsqWsj2J3hbdl+ht2QMT3WXGSnToIphfVRbS7UoBXYTwr8NC+Sa6 MEmUNCd9QQ3+9sKDNTfI3S7ijNqMA7oIegPCsnUbUkU+uTpFUlyV5/G4njAgf+60Es30AiPmJzqK bF02t5l0ZVtd5aIw9O0Qjeugag32ZDVmmWrq6OQBO4JsVq42U50ZjosmOabzagG2mpp/VRbV4kGQ JtIBkpJ/oXmK/sfN5G1ziV1f+24m/sN4AwFB7QPQ6Zrdx0jbrNU6x0YxwwbVa2dVB4bgj12YtoFp n+uqi6g606Cnine3VD2DPyFsLf05oHvSCViR8UPJHkYrgByr15qSWMr68c0S3YNvluxh+OY008Y3 IWSUaC8iI3qYpQDQSI0/viW++MbTpOEYFb41uMbqaUkkHPhmDsY3y9YtXmYqwLcR6CcIOh1jbScq o11UZncU7Z7Eq2oQHzevwvyo70upRXma9nT2cWyvtWpWctC/GLzkcF2PQhPQpE49OL3MHjZvynwj ZvXQMB1SbTdIk/+gN+iv6xKH483otp6TnOcEy+uy3i/9uXpHJhhscNERuomJ4tRao2s7IuWRlpbo uEBoQ7+T71ez78g6O6/nbKdQxouYKWC5mjuX9DK2U+/YNhyRw0OnZL6TFK6TSKtXwjRLWT+mWaJ7 MM2SPQzTnGbamMaxeiZemCa9XyjCGybuDXCyh1ZzySOT7OrNODPS5Toeo5dbj1Ydl/s9FYF34K0H bur3YYbV2ydi0H0zBVMZ4DPZcXvneDWF6yiVto3bcPIJTZyO0BqvZ6gGPrLihM5slkjGLV2Hvtti E0dAo9+yKREhgrn2ld7LV1Nm++gPvr+smmR1eR3iO2UdWZdeINNGdWQvqrcGixx3t7mrom20dnGW /aD0neGVl8Od3FC6tJVvYOAp3/C1bvfcPXa169jTlI6qpfstY6f8vU/MSBYTavt4SHKGlNaS3e7d eRkHO9eeBjTN6i3Zq8ds1qpYVBf/rKu2z5tMSgId137hoqRG6u61Vpwhxx3H/TFovSiTZ3TZ4byD ZUi/rcdbVwtY4f+kV5ZctEMwvFBwLvUlAnpfKHDow/3e/pTeFwrADQx7rTJoKesvg5bonjJoyR5W Br3MCIhEwW3ZmwR2/Q5fYM7WbxBIEZ3fIXMs3gwq+oaY/Y566tnTOgtuw3/cF0DuuAH0/up8j4vj e1zOZbWrc8oiDri3maionursfc9hcEquesvz/wBfGJTUDQplbmRzdHJlYW0NCmVuZG9iag0KMTMg MCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjMvQmFzZUZvbnQvVGlt ZXMjMjBOZXcjMjBSb21hbi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3Ig MTQgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAzMi9XaWR0aHMgMTM4IDAgUj4+DQplbmRvYmoN CjE0IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1RpbWVzIzIwTmV3IzIw Um9tYW4vRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgODkxL0Rlc2NlbnQgLTIxNi9DYXBI ZWlnaHQgNjkzL0F2Z1dpZHRoIDQwMS9NYXhXaWR0aCAyNTY4L0ZvbnRXZWlnaHQgNDAwL1hIZWln aHQgMjUwL0xlYWRpbmcgNDIvU3RlbVYgNDAvRm9udEJCb3hbIC01NjggLTIxNiAyMDAwIDY5M10g Pj4NCmVuZG9iag0KMTUgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5cGUwL0Jhc2VGb250 L0FCQ0RFRStWZXJkYW5hL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDE2IDAg Ui9Ub1VuaWNvZGUgMTM0IDAgUj4+DQplbmRvYmoNCjE2IDAgb2JqDQpbIDE3IDAgUl0gDQplbmRv YmoNCjE3IDAgb2JqDQo8PC9CYXNlRm9udC9BQkNERUUrVmVyZGFuYS9TdWJ0eXBlL0NJREZvbnRU eXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZv IDE4IDAgUi9Gb250RGVzY3JpcHRvciAxOSAwIFIvVyAxMzYgMCBSPj4NCmVuZG9iag0KMTggMCBv YmoNCjw8L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+ Pg0KZW5kb2JqDQoxOSAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNE RUUrVmVyZGFuYS9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCAxMDA1L0Rlc2NlbnQgLTIw Ny9DYXBIZWlnaHQgNzY1L0F2Z1dpZHRoIDUwOC9NYXhXaWR0aCAyMDA2L0ZvbnRXZWlnaHQgNDAw L1hIZWlnaHQgMjUwL1N0ZW1WIDUwL0ZvbnRCQm94WyAtNTYwIC0yMDcgMTQ0NyA3NjVdIC9Gb250 RmlsZTIgMTM1IDAgUj4+DQplbmRvYmoNCjIwIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIg MCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA3IDAgUi9GMiA5IDAgUi9GMyAxMyAwIFI+Pi9Qcm9j U2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA2MTIg NzkyXSAvQ29udGVudHMgMjEgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9D Uy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAyPj4NCmVuZG9iag0KMjEgMCBvYmoN Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjMxND4+DQpzdHJlYW0NCnicvVptb9s4Ev4e IP9BnxbSYU2Lr5IOuwskttvLot0NEl8OuKQfVId2giZSTpZbFLgffzOU5IiOKdN3xaGwI0vDGZIz 88wzVMdnVf24zBd18Msv47O6zhcP+j64Hc/Ll0/j+fcXPb7MV49FXj+WxW+/BefTSXA+Pz0Zv6NB RjIVzJenJzSI4R8NVEZSJYJEKMLSYP58ehITweEpkTGDb6F4UK323b16f3pyG15Fn4L576cnMzCA Rjq9SUKUrfc21F8n5XM0ojQMHKMoTUnK7FFXegFjeFg+w1geavgRh8W9+ZNHMoRVRqM0LNYOnYwx oqSt02VfKFghtWVZFoCV3429TaEdI2UsiEz9rMg4IdnO3rDYbAxVrjFckYFFBLOPk2DsiIvzsq7L 5+HQYEG2Ly44elw0cRFgGATvB/cvY4T2B92Gl3kkwlXjOcfSKMftsEY5t44mJFZ92WAUkxhuzRe3 4b+dw5ggzB4WmxHcud2glQ3PafyO72ya5HzHzB4vBeNL9M/HycU0iHfSk1KCA/fkZ6wgn7othXic 4I5K2NoEPoRGifmh4DOGzxQ+Vb6sMXKHpVFS4E3MIQ4Xb1fJ9kyLKU6EtKd1F17O0P48Gsnw6i6K Rgy0URlezGazIFLhtMrhewkyMLEkfB/xcPMYURXew5UOcAb4sKzgUoRznHMOT4ovUQqKRHi1ecF8 38BX1YzY77x2z1TGCe/c8BFVgjEe1tEoaa5WUWPg9U5Z4I6VS5zeh+3df+FEza97F24lgmSpbXHk kk1NaFmyF4BtaairNeQrbBG6rPymK5yG2YaqnWmB01kv4aqsnuEhjHBY4ZISKW0rrv3iUhKe2bLG 2j3MxWy8BlApK/Sly55gAPjcbe9N6NNe6O86rtkhDyVsQIlSCMi9GsKghMBinmFRGpYmGt+bACwL l7OUBG22sr86gyAmmS3qrHMQL8nOHM8uYUro+as/4eJm5ixnivDEbcbA9HYPJG4klPyYqKDSpyfL v+zZRe6LQkoafNtWgwPeEQPe4RkW+tY7s5sLcMU1fC7+hA34w7VrnBln9McOTkAOTIBhPfXQoQZ0 QOGiaQ+UET9TBwzjM8IgZ/0AlqqEyB0THcACU2DhxQQQdlfTPt+xOCUJtzV5gjxlCPLWSAeWX9dI xQxgYFYhXiGoI3h0kK7Ca/2CZKADs8/RSIVPiGg6uCjWG3j0ZAidvjd1SIQTyEuAIW3A521p2nGH zDJMqmae199hwLrWmO1rZxqyGAPKGvg63T4KTwEmGOir4J6pCZ+xJtRY6XqFY8cod7JjHnOSJLbh HCvM69oZ6CCgU7YY/AWub1zqIFjSHXVOsE8oSagtawrgQwWWys0KbD3gkjn8lFg1D1kXUGpi7rb+ JqUSX7yRqSLCK9PTHTLrVpkwrNQ/pixYyobLgiV6oCxYsseVBaeZflmQEAKiLQvgtSxzl4bM21Uy 65igT2mgsRtWJTQ5Ww5xaVIA06Hhqftg1RNRgeUkqa3doqw/TZGzNvHewBxNHJxVtpS1Rogw3w8a ZwMwZoDw6Qm5kotbAqFDX36Fn7p6gCud38P1IXjD6pe0E7dZ4Rq5oDGyXhugamw1DLZAM8EEbZvw 3izMrJ3MkXFJmLTNDftygMpJmiEN9dEywOUktBmUDiStiy+khKf26COSuz/sQHL3RQ8ld1/2yOT2 McOg+2TUlr1NYdW/fscWY/0zhnEM+/YrBkb5c1tuKN7BUMfChkHcVbYC5e/Cfz6UxQoG3EWfnB0A dBHSPUkLgfC0RLbENI5j6kYgyt1xgccNSeYPOsIXzUSSEZHsgSC5B4LUsRBkae8g6BqD+u9wdX4X BQA/4IZjm2YV1g8m2ae6gQFscI3/rG7uojBnWYeRCm8YGtbExStbGwYqAa0J8IG9PIz3gup68xnM NNPoGTfs9s1p3n53UeAcQtkWh0NgoCUQkiEz8tGifOmGgF6FJT+IbljKhhHJEj2ASJbscYjkZaZF JEv2/4lIzkn2EUnwBJ3vhUje/BUnkEl/fEoHghN6MUlfTzwl4+YA85IqkYynVTTKwnyJe1QbDsN9 20yOxwh97c3B6F04GU8xWs+6gzzxP/R+jlZExEgxesZvOwR7h91gYZhKC0n5Fn9Q8Y05LdcVPEQr 8MiILXK7JRvEKQ7gQbPXLWVZs6Uf8mK1yVc6cB1YU87xAKI/vtm0Ye96c2meSk/qxWJfIOLQGAj+ g4DIUjYMRJboASCyZI8DIqeZfo7zxMTbtu9J3TnOqLezoPGJ/TkIG6C5XEh8U7UvxyXbk+MUlmFe jXnmetq8nehZ2eY67rE5IgcekobTloPMDBQDP/hvTnt2WhQkKiZ9ba4BEN62XH/DLqhhKD26MpzB 0KPwzuvGHrQ1JbKMa8N/MLY3TxjRxmh7iNSuVOfrTTt5jYmgixoLDY5etqdUJkFwwCxv3znctyM2 z+07ibpEroTb1yBX5Tx24XjGbs3YfUSTEHC9JXu2KDFlN+stJC4ChL0rvdSVLsD+IgJSp4NLmFgJ AjQsUNTV5WFjxoV7Pm8Dd4CHc1AWezEnNnAmzGNJ5I/iSpayAxDVFz0EUX3ZIyHKZcaCKGiMYj8a wqQvRDFok5g/DWEDR94sSUnaeXr7ZpH33yzy7mK3T5Lda0bq3zBBiWXMtmo1TP/AfqgDqwaBEKvo sWA11UucWQNJW3AyMOViAYJDoyvtubne+QlBkSq82b0Nnrm+INKsNW7kAbxjENsi6zqrb48IzfXi 4ZUZr1oAneqv20Us9LojcK/rxUZzrQOjwfDpBhJrPJ9/csWxihErrEm4FoxCEPOW7KxBKSRuphC0 a3ad3nD8bwE7KpyISRPcWEv2Q/nNJQ0NAVRAr4VwIbAvsGRvyifE1xpr4sp04XehAm9iDxO3Hrgx x/mLoKt/XWk7183av0HQHnA2tKO0fwbRvYuYGK9hHC8226A1oX5emcPEL4iXhi2gxV6cyGa6uatI MSkIkGDL8jBUJANQwc17Jx8tA30PgxZKDB39HVMULGXDRcESPVAULNnjioLTTL8oMAb9hvTjrd5N BoMnWeJdFPjAgT3N0o5R7tHyH7b2+pENCmVuZHN0cmVhbQ0KZW5kb2JqDQoyMiAwIG9iag0KPDwv QXV0aG9yKHNodWFuZ3l1KSAvQ3JlYXRvcij+/wBNAGkAYwByAG8AcwBvAGYAdACuACAAVwBvAHIA ZAAgADIAMAAxADApIC9DcmVhdGlvbkRhdGUoRDoyMDE2MDcwNTE0NDQ1OC0wNCcwMCcpIC9Nb2RE YXRlKEQ6MjAxNjA3MDUxNDQ0NTgtMDQnMDAnKSAvUHJvZHVjZXIo/v8ATQBpAGMAcgBvAHMAbwBm AHQArgAgAFcAbwByAGQAIAAyADAAMQAwKSA+Pg0KZW5kb2JqDQoyOSAwIG9iag0KPDwvVHlwZS9P YmpTdG0vTiAxMDgvRmlyc3QgODc0L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTMxMT4+DQpz dHJlYW0NCnic5ZlPaxxnDIfvgXwHHdtLZ6T3P4RAaBwaQoyJDT0UU9b21F6y3jWbMSTfvj+tXrdb 6h5Gx+YSzc68ekav9Oysw0ihkcJINVFg4pApCHEtFAJJqBQiSW0UcDliIS43plAoRiFcji3gDKUY CZdTyxSZcsQFoTKOFAOVJFhNdcSShPtgSaY2YkmhlrGkEo+MNQ0xR0ojMXOmhHI4V0I6iwAeEIvg XihTsC4hFqzLxFGwriBWrAMvYRMJvFQj4RacUXgGL9dKGbyCYjN4pQllcCoKzOBUbCCD01AUbi0j tpAbYtLtkDA2URgRN0UpKKtSQaMENynoVMA+SkIEFKVJZFwviEgq4CXUXcBLOIlSJWvnwcs1UAWv oE4cSkHLq3YebcRkMAF0DjytS2czjkzYShjRDJ0Oj+glxsOoQ+cjHAhbC4JN6YQCN2oREUU3HaUk 9B4RRTXwEmbfwNN+NfAyJsyjzhtUHkEqqIRHoAo42oZQMUYeAatNJ6hm6OhQSRxHXYwJa308NkiB 68wYNut4mOEH65wxdtFBoN6I6nEAS3BXHCR1TNQBHKCpzCAn0XSQU1U9QM4wlKFHzGgMC8g6XBiD g6bKgHwoFa2PFZtj7D22g1WQZ8QOoBUOtDDVSKtjgdOc1TQIJbgzo0NJ1AEkBdEvB4xCH4DNjJ6C mrEFzAoRTiA5F90RRpUbTrx6NZxp9kifhvPh3fr2cT8NbzbzD+9PTk420zxP+7tpdfP71Wr/08P2 9kcaLr49TMP5vH+8nrHgfvjwG42XNJzdUlDK69cvX/wTevZcCi9PCctT4vIUWZ6Slqfk5SlleUpd ntIco/SM3zF/doyGHdKwwxp2OMAOCdhhATs0YIcH4vBAHB6IwwNxeCCep4fDA3F4IA4PxOGBODwI Dg+C5/fA4UFweNC3gx/gxT9vi3LEkRMcOdGRkxw52ZFTHDnVkdM8M3WJ4DGBPSqwxwX2yMAeG9ij A3t8YI8Q7DFCPEaI69ngMUI8RojHCPEYIR4jxGOEeIwQjxHBY0TwGBFcPxceI4LHiOAxojcP/29e /Eu7KEccOcGREx05yZGTHTnFkVMdOc0zU5cIHhPYowJ7XGCPDOyxgT06sMcH9gjBHiPEY4S4ng0e I8RjhHiMEI8R4jFCPEaIxwjxGBH+w4jwlLTaz89vSxfoy4VDYAtiIViIFpKFbKHnVQvtEKJRolGi UaJRolGiUaJRolGiUaJRklGSUZJRklGSUZJRklGSUZJRklGyUbJRslGyUbKlZ0vPlp4tPVt6sfRi 6cXSi6UXK6IYpRilGKUYpRilGqUapRqlGqUapRqlGqUapRqlGqUZpRmlGaUZpRmlGaUZpRmlGaUZ RV8VWJQeQ4+xx9Rj7rH0WHvsHO4c+1vm8H7AYudx53Hncedx53HncedJ50nnSedJ50nnSedJ53V1 9X2Axc7rLrPJfEn9y3Ak/8V+mj7tdvPwabeZPq4eyG6hX5Jpe7hKdjN7Whjm6Orp9HX+MH2j0NHv wNru5mk41X9Otjd/f7jA0qvd1+F8up6HX6bVzbS3Y815On6/3ay30/ndSivUE2+2IKzm9W7bP+/n 9R8rHBw+/brbf77a7T4Pb3fXj/eo6XDmy900zfY9/7i63u+OPv98h3+PPr9drza726MT55v1zXS0 1u6DZbf71X1/DdL3evp4/wV/mtJT1/Udih7I4SXKXw3/15MlPPeA+d88WS5Jt/wdP16sAd/tM+bl iz8Bpy61Rg0KZW5kc3RyZWFtDQplbmRvYmoNCjEzMiAwIG9iag0KWyAzNDIgMCAwIDAgMCAwIDAg MCA1NDMgNTQzIDAgMCAwIDQ4MCAzNjEgNjg5IDcxMSA3MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3 MTEgNzExIDcxMSA0MDIgMCAwIDAgMCAwIDAgNzc2IDc2MiA3MjQgODMwIDY4MyAwIDAgMCA1NDYg NTU1IDAgMCAwIDg0NyA4NTAgNzMzIDg1MCA3ODIgNzEwIDAgMCA3NjQgMTEyOCAwIDAgMCA1NDMg MCA1NDMgMCAwIDAgNjY4IDY5OSA1ODggNjk5IDY2NCA0MjIgMCAwIDM0MiAwIDAgMzQyIDEwNTgg NzEyIDY4NyA2OTkgNjk5IDQ5NyA1OTMgNDU2IDcxMiA2NTAgOTc5IDAgNjUxIDU5N10gDQplbmRv YmoNCjEzMyAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxODg4Mi9MZW5ndGgx IDUzMTA4Pj4NCnN0cmVhbQ0KeJzsfQl8VNXZ93PuOvvc2SeZTO5MJgvJJEz2HTIkBAgBE0iABIhJ SJCAIFFwYTOpokjAWsAFhbbauhVbnYhKsIixtWq1VtFal6rVultQq6hUyMz3nDuTANq+3+97v9cf 74/Ofzj/e8+559x7tv9znjMTZoAAgA2Jg8bJTXVTw988HALYdwzAsX7q5NopkM4ewLgOcyVPbWxo EksMlRjPxnjp1KY51e+mfpiO8W6MXz+juWnaupTf5wBoMM7+uqEpkL/q9cs3AZBX8HrH3MkzW1b/ Y/0KAIMHgH+ra0Vn77SV/0wCWHE35tnTdclqz1zveVj+MrxOPj+vd8mKtbWfpAKsbMb8jy7pXNUL DlADPHQC7yctWb7mPLjnpY8A1loBMi/p6V5x2cZu+yEAjELr3T2LO7vfXH3+D/FeCzGhuAcTTI2a BRi/HuOpPStWXzaxNbkHgCkFUGUvX9nV2VO22g7w860AYu+Kzst6hTShGvMPYX7PBZ0rFp/zyf5O gD34fO1bvStXrY5cBi9ifV6n13svWtz75ro38PkXYwVYNdC+5cV7LzrhfaTdWPkluFRA8avlTcfo 8altjz9+/JaRHfq7VTswrxoYiALLqbTh2dhPpXj9Qv3dyp1ORTtNYffBJGCVOAMSBGEOnvD8o9EU bgtzAHhQ8bfwBXjLtOiRvRVeZHkVMFoVx/Icx3C3gRAJgmcB7VFacGaTxwP09SshOdwKT6u05F4P kJ/Sa1wXf4i2FIgqViV8hhLYUniG2wt3wb8A1wqPYbjz1DT2ZbiAeRf28RthHR+CXj5ENHjcj2Er hmYMt2O4GsNuDF0YevAZb/+r+1MIxeAUnHCQfxqWCLfj8VI4eFodzoV13IWQNRoXb4CDwhMYnoUl /BvRI470Qf4+WDF2zyRwqkWo/lZbjsWOT5yazrfAXH4n7OEehBY8zucboYXtBP/odeyjW08536O6 FPbwezFcruTfQ8uw32D5R6GdvQP8eO02HK9k8c+Qo9y/CJK5J6D537U/jjjiiCOOOP73gd1HiNWa lalEnE4kAzkFsVVZSzKMMh5N6FrkmfQGvQHdqLRUWgRoGZ0gCTqt4t1ZszPVgqAjmkxZUrzJOOKI 43sBAUWkoINjqgioQBUJ415Fg6xRWAtaZB3okPWgj4yAAQzIRjAiSwqbwIRsBnPkBFjAgmwFG7JN YTvYkR3giBynUkdOgETkRHAhuxROgqTIN+AGN3IyJCPL4EH2KOwFb+SfkAIpyD7wIadCGnIapCOn Ix+DDMhAHgfjkDMhEzkL/Mh+5K8hG7KRcyAHeTyMRw5ALnIu5EW+gjyF8yEfuQAKkAuhELkIiiNf QrHCJVCCXAqlyGVQhlwOFZGjUAGVyJUwAXmCwhNhInIVVEW+wF3bJORJCldDNXIN1CBPhsmRz6EW piBPganIUxWeBtOQ66Au8g+YDtOR62EG8gyYiTxT4XPgnMhn0AANyI0wC3kWzEaejfwpNEETcjM0 I8+BOchzYR7yPGiJfAItCrdCK/J8mI+8ABYiL4S2yGFoU/hcOBe5HdqRO6ADuRMWRf4OixTugi7k buhGXgyLkc+DJZGPYQn0IPcovBSWIi+DZcjnw/mRj2A5rEBeofAFcAHySliJ3Au9kQ/hQrgI+SKF V8Eq5NWwGvliuDjyAVwClyBfCpchX6bwGliDvBbWRt6HdbAOeT1sQN6g8OVwOXIf9EXeg37oR/4B XIF8BVyJfKXCG2Fj5F24Cq5CvhquRt4E1yBfo/Bm2Bx5BwZgAHkLbEHeCtciXws/RP4h8t/gOrgO +UfwI+RtsA15O+xA3oH8NlwP1yPfADcg3wg3It8EO5F3ws2Rt+BmhW+BXci7FN4Nu5F/DD+J/BV+ ovBP4VbkWxW+DW5D/hn8PPIm/BxuR75d4TvgTuQ7Fb4L7oq8AXfDL5B/ofAeuAf5HoV/Cb+MvA6/ gnuR74X7kO+DEHJI4UEYjPwF7of7kffCA8gPwIPID8JDyA8hvwb7YB/yEOxH3g8PIz8Mv0b+NfKr cAAOID8CjyAfhEeRH4Vh5GF4LPIKPKbwb+A3yL+Fx5Efh98h/w75ZdxpP4H8JDyJ/BQ8hfx7eBr5 aXgm8md4Bv6A/AeFn4Vnkf8IzyE/B89HXoLnFT4Eh5BfgBeQX4QXkf8EL0UwKPxneBn5ZYVfgVeQ X4XXIi/Ca/AX5L/A68ivK/wGvIH8JrwZeQH+Cm8hv6Xw2/A35L8p/A68EzkE78J7yO/B+8jvwwfI Hyj8IXwYeR4+go+QP4a/I/9d4cNwGPkIHIk8B5/AJ8ifwmfIn8E/kP8BnyN/jvxH+AK+QD4KR5G/ hK+Qv4Kvkb9GfhaOwTHkf8I/kb+B48jH4UTkD3ACRpBHIIwcVjgCEWTqXAF7QK1VA8tyvGLxeXrg WOEkuOhSoBIFUYhlUIn0hTFRS1OAlhEEHv8BfVOKVSvleExQg8CfmaUrjjjOfmh0GqpdQYko2uU5 8SRi2lWrRLUIVKP0nL4wpqJv7Ee1K6K2xZh2tbQcL/CiqAZROEPNiiOOsx5anRY4jhOVCJUmCJzq JMa0i3KNZdCoqXZVMe0KQMuocClW8fRDPOB0tJwg8iqVBlTiGWpWHHGc9dAZdKhdPqoxUVlbOZV6 DDGfF880inYxg1ajRUdbjYkG+K+1q4trN444vjfoDXrUrnCKdkVe/R3tahCoVkW7ulHtak5qly7F 6ph2DbScoBLUah2oVWeoWXHEcdbDIBlwmytENUY9YdSu5iRi+1UtQhPLoNfqNDoa00o0BWgZXJU1 aiGmXVpOVAkaXJfj2o0jju8LRslItatWIqPa1Y4hpl2dFgUby2DQ6bV6+rH/KdrVoHY1Me1KinbV ogbXZY36zLQqjjjOfkhm6aR2qScMKkH7Xe3qULD0GmYw6g06A43pzLQI/dNtXJfVWq0Y0y4tp1KL Wo2Emj5DzYojjrMeJosJBEGMaiymXd1JxN5r0uvpe1rRDJKBahdjeguMaZe60SLd/YJgpuVUGpVO awJtXLtxxPE9wWw1U+1qlYiyTKpFnX4MMe0aDHqjLpbBZDTqjQY9JtL/CaUBWkZxo1VR7Vr0WF6t VelxXdZpz1Cz4ojjrIfFZgFRVJ2mXb1hDLH3mowGg6SnGTCfWZIMktGAiTYY1a4etavHvCh10WrQ U+2qDTpLXLtxxPG9weqwUu3qlIiWSk0jGr6jXdSqyRDLYDGZjCaJatdBU4CWUbbAMe3aaDmNTm3Q W0GvO0PNiiOOsx42p+3b2lUZjGMY1a5kjGoX81nNZqNZMmIi/b9mUe0ajDqjQR3Vrt2I5TU6jdFg A+paxxFHHN8H7Al2UKnUUY3pqIS1KqM0hthnPCaTZDbGMtgsFslikjAxgaYALUO3wEY1/cQIVA4J Na/VaySDPa7dOOL43uBIdFDtGpSInkpNq5K+o12z2WSRYhnsFqvJasaYOZGmAC1jpFtgTVS7TlpO a9BI6FMbDWekUXHE8R8Ap8uJ2tWcol2d2nQSsc94LGaTVYplcFitZqvFhNp1wah2JZPBJMW0m2CS TCadQWtCn1qKazeOOL4nuJJdoFYrfyJFXV8kvcZyErH3iW02q90cy5DocFgdNgsmJtMUoGXM6Eab tfTTXlC7aTm9pLPgumyWzkij4ojjPwBurxs0Gp1JiUgSkkFjtY0h9j6xw25zWmMZXAkJtgSHDZ1n L01RvriRutEWHf3ECDSyzWq1Gkx6myUJLKYz0aY44vhPgCfVA1qt8idS9C0pJKPO7hhD7L2mBKfD ZacZcPFNdrkcrgQHutv0m81MQMvY7Ba7zUDfdQZtisNut0sWo8Mmg81yhpoVRxxnPbxp3pPaNVO/ WNI5vqPdxASnyxHLICclOZMSMZaQRlOAlrE7LA57TLs+J5aTrEanzQM26xlqVhxxnPVIy0oDvd5o VyJWKjWzPvEkjNFc7iSXTD8RsqKr7JNll+xOBEiiXzdqVb4jPiHRnpgg0XeuQJ+RmJCYaLabEnFd dtrPTKviiOPsR1YgCwwG5aNa3NbStdVqdCePIbZf9XqSfe5YhnGpqXKqNxnd7QBNAVomyZ3gTsIF GJdeQ3ay2+22JViSXZm4Nz5DzYojjrMe4wvHgyRZXEokgUrNbvJ4xxDbr6b6vOn0m7wTcLnNzshI yUj14gJcSFOAlpE9Lo9sUX5wRMrzejweh8vmTc7BvfEZaVQccfwHIL80H0wmq1uJuKjUnOaU1DHE 9qsZ6alZKTRDEkAgy5/mz0gFSC+lKUDLeH1un9dG37kCU1Fqis+XkOxI9eYBXZ7jiCOO7wlM7Ce3 rMDSM4JrKxFg7KfBCMPA2C+IjYL+SljsS53p3ziDZDJbrDa7w5mQ6EqKGgJITUvPGIfH7ByA3Lz8 gsKiYoCyckyZCEHkybVTpk6rA5gB0NA4a3ZT85y581pa58PCtv/hBrL/vWIc/AhA+cUy+m2ZKZAJ 5VAL06EJ5sECaIPzYClcCmvhVvhVJKLkHAc5MAnqYCbMVXJ0Yo7lsCaaI/LOv311Rbq+80ts/wLB 8ubSkuKiwoL8vNzA+Jxsf1bmuIz0tFRfitcjJ7uTXIkJTofdZrWYTZLRoNdpNWqVKPAcyxDIJiFn Tctgguh3oTvVmhOLJ54eD7Fp0ufeEJhPy+T6VqGkb8Xd34onj8XPCYE1NMVXM5neeBCmvB8CS4hY Q0CfQiwz8UmxQrXdy3y1S0MJNd0dHVhisk/yhKZ8FohVRbn3oFZT46tZrMnJhkGNFk+1eIZ5ewfJ lIlEOWGm1JYPMqDS52SHzP4Qk1ZLw7JQcEsHnvgm453wiuXklaHI8NZTLwEWGz2zRM9ISKgJicpz PUtDwc4QbPEMZg8PbB2SYFGHX9ft6+5ciD3XiXUcBDattqeZ9mMtDR09nhCHN1fIhSme2h7PgI92 R21PB7JvMpb6l+mYrK5p2eQddoXMeKwNmfyhqZhj6tp3XexArXOph0YHBjZ5QrfOajn1qpdya2ur Eys8UOvDG+LNapdVY1OcgZzsaJtiHdDdsYw+c1knrWftMs/AlsVKXbcqdVCy1vbgwHT+33INDNR2 +2q7O7uro3evCQWblQM0z29RGohdN7k1lhTLgFc45UrH5FZvtLPrZ7fU0Ir5Oie7osM+ltIRS8GE 2tGLHlqDOrxByNPlCcHsFh9mLaW0uBQGukqVyeNtJViq8WSpEJ8m+TwDX0KIdPiOHD49pTOWIqRJ XwI9neKb0jEwMMXnmTLQMdA5FOlf5PNIvoHB+vqB3toOfGpjC5Yaijy8xRWasrU1JHX0kHLsezoD psxuqXJ5Ta2j0cbRKOCUwomlVZqDvYD/6mIH7GVobvF6sKPmtLS6sJ9a6HkznkePdCLhxC3FMY51 G+2jxaVj3VMTO/V66ezcMhSERRgJ9c9qicY9sMh1PwQDfhyPDnplePSKbQ690j96Zax4hw+f8oBi pGwhVfrYP6Nkt9T2lIeI/b+4vDh6PWSpaWFdTGv0jHGx9EzjR6VXhhx+PB/nH8BBeN4XkvwhvmXY VdnqkUxoAejoNfnqZ81v8dQOjM2CaEqspXQe4FT3dfYMxKREJz2agupBH7lm1mCQXNM0v2W/hFb6 muaW+xnC1HRUtw6m4rWW/R40rUoqM5ZKYx4ag3o6Ae9nVMol1/4gQL9ylVMSlHjXEAElTTWaRqBr iImmSUoaIgeC6uYPP0iVP3jfJOPwBbv/rJOKg6+Sl7eb5Gcx/AHDMxiexvB7DI9h+MWuVHk3hlt2 eeSbd42Td213yf/YaZPv2pkg37QzS75xZ5p8A54Hd5KdmN34Obl+e4K8Y7tf3rbdK8N2Qh+0cLtW KjYekA8EDrCBXxPYL+1njFjnB4nnWN8xRvra83Xwa7bvSyId9RxlPJ80fsIEDlcdbjjM5r7U+xKz 9/5x8v17TXJgb9XejlBvqPdP/HvvpsrvYAi8Sx+w9zfYEPqgyAN48kLfePkQhuf7PPJzfSZ5GMOj GK47GDnIGB8hkUfI4H0mufc+It3tuZvZsjlXHtgckDf3FcjXbHTKmzBcvbFOvmqjSb5yY7m8EW+z cs+te0J7PtvDBW8j0kLPwuBC9gu84xV9TvkHfdPlfjxejk/cgKGxr6Ovt4+VjF7ZbsuSRcErJziz ZI71yhZzlpydY8zyG8ZlGtMzDKlpxhSfweM1JssGdFr06Lvo0YXRoyejN0omnU5v0Kk1Wp0gqnTo 7OjQE9JJxn4jExT6BSbI9rOMEaqgAfqAM0IAT4PulRh5FJ6DCKhcFSrZWK6S2TKVDKUqubGAhMz1 UN9cHbIQPDZVhwr89UMqmB3K99eH1I0LWgYJ+WErpoaYa3B4mkPcNTiLmtH+z1/QMkQS6OWrlOUA z4ZI/1XXXusaO2tt9btD3fVNLaFed2son578yN0KfsSq1atWrfL/Gwyq6dO7Z1cPfsTRxaIz9JFv 8uDHHykLR+hj32QSK3rqPfAUbzoWi/47BeC/WElf/Z3HKYXQTAhW+gdF/CGQR/k016sLfPQYUX6X NfLG6Hm4O/Llf8+Z+y5UsfD/AnKIyfz/fS65jlxN+kkzuZSsIBeTpSRIukgr8pUYWwn3KpnugI+I hyQQ+nN2PmIiIhwnacRNLIQDDcYPY56jSs4fK3yUlMMXTPRXbLdgeBT+BO/CEQgTAxzE1xJ87YHb 6K8wkWSSQcrINPgE7457cbgFBmE/5nkKy/wF3ofPiIrMJ5eQAXI9o2emMvMxn5PUkM3MTOY4lwoi uZQxkyXsw+QoEYiNpMLD8Ad4jQ1FPiS3wltsDrMXLkOv/kVSSILsHWwWKzOHmDvwSQxdIET6TSEs Hqz7BIYDGgLPvvGsQnm5XpPXlIZEMNc3/Twcp0fop1sNBp5BWoGzhZZOD9pZlmHEP/LwBvcC+0YD 384zfIOatAXa3h15FwIj+YGqvFzCelmC92NWjA8/PJ7sCi8n1/OHjr/OpX4TICq8513sk5xOsCr3 LA76BBFvyhJ4zsh2sL0sgnsORElcKfaJnBhQB9UMPuBIAQaoKgiYy8roM3zKi9NV/q1yEINgHdnL zKSB7pQeC3eze/EJNqgMZjeQeqZeaBDbSbu4kqxkVgp4Z9LH9Al9okEE4lIZ6TJqHOYetEtH6XMK oIq2o4140xmTZC7x2gxEFBib1exIJg52b3jT8P79w2TNrB1VlfV1Eytvagx3v01eJy58vf62u27/ +kvDb95+T/jj9Zc8NpXW506sz87R+kxGQxa0TLY2so2WDqaD7bB0WHuZXrbX0ms1mIFzYSAcpx2G hxzSV6fVR2JEb9FEUlJsLipkMsaTjCKv3czu3D8c3tS4s2JiXX1l1Y5ZZM3wfqYy/F449W331OFL 1xP7PbeTlEvX769zvx1OxdpcwAjsUjYd+z8pKJGXGQk66G6TCfANPHY1PhACR/B5OIbs0hGeOc4I xIPl9mGeHLIZy7mCJuZVAs8DaSDtZCXpIzyhw0OLZRIc+pzwAE7nzbTt68IHuCeV0S4OGnG7S37L sFYccPrEociHQYNaKgEnJTpbGWxtAM1VVSAvdxM/3r9pw+Nq4iXckyc+CD/L2gXrsbvFFqxtb+Rt Psh/Cg60WrXBvFqmVjPdMN2+mlmtWWdYZ1e5dpWbp5sZs+jdVSTUCoyQ4FRqA2nJm0FHdFhbU3RG tR3Bf3m5bcTKiAbiS0nPSGeKCs0lE0lBvt1hN/NSui9FMEn2gvxiPjh52vQP99x1uG569eTp0w/f fs+H0+uqwxuWrVu3bPmaNcuZjw6EX27v7OpetIj4DvyGJHctWrS4e1H47QPE8N574c/CX3/8MdaC oB3mDvMvgRGKgjL/iz6BCIJOMLC7ifFug84wwPLM3cBWsStRDIG2o/nSkTJJ0VcVrXO0j03eovxi rGUJnnGHTyST8vAT0zZmFxZypJ4UEI61fGGyJTRWHg/Qdu9Hmz+d/wTcsCWYa1ivl0oYk9Xk1aeZ CvWFpqmmuaZFttU2DTBGo/Zmi8gk3UI6oCOpF3qTuCTqaNiVEUpiVJv77cRu3ypL0uhwSV9hpcxl OG5tSh1xytY0twRdRkbrlBmXM8D4nRXO6c4F/ALn+fz5zj6Hvq2V9rg/kxQVp2IbigppH4s+U3Fq gYezWQUcCdHLTz++8mqin7XmvCvXLXxmnmcqsW1Bs5h+7bYFQxnMj7/qfK3h4nvnnLdyRgWplyf+ /eVrw5uar02ird2Ks8PHfwZBuDHYq7Q2QEmrZfNdWnO+XzteShnvyy/XlhsLxxfmF06o007Jr50w i7RqZyXMruwmy7TdCZ2ll5C12tWlrokTknd3yETOzc2+WVYXinq96WZ1QvpAeYPcLjNynmNznlw+ gdOxbHV0auHMMjvKjgQCbQGcYNgdVeYyZOwlaruw3X5cEaKt9KWkZpgKknGuFUf7AVXtJ6ZTo2M9 g9MxWsyWTLihvPKmuc3v/Gx/+OumjLmfdpVfE0jLrszLG6iYPeecy7Kys8f7Mpaln/v6krTZJHHb tX+qnd14y+UFFzEPZ/W2LX1oUlVNeSqZWjjD4kmYWjNpqlFiiUZjtlRNyCmRzLpJE0iNd0JeZt7W c9f/1mUQs1BxzZETaO8PoQ+hh4uCMzNFIujt+oA4XZyibxWb9cvF8/RrxYv1Wl2jvkPfq2f1giAK aqLfRdeJPp7leVYU2AZNu4bRiGodt0VDiFEWAihOpcsKsHfyqe3B3lK6Kh9t0CbpjTZumLS1ER+d 8iY0SgXIfPsz4W0jAWY/2fTMyBPhBjIvfAdZQBLZjhM3Mokj7+McuB3nQBbW1w+9wXO0yvCrXKoc VY6+gK1QVegKTJPYOtUk03RHi6opa6lqjUpKTk7clZ5yS7ogCxqN4WYhwZOyRQ5qTSWydbNH1ljR guSgL6BRqoszHofYfyQwNsJ0/VOGl0SHFu3zt4c2OpbYEFvUvCQTPmte08JPb9779TlZC17oqdrh T/EF0op3Tpx/x8RszjcyRW5PXffYlAXnkWOrn5w6o46UpJC64mnudDlYU1jv8NpkIzst/M4XDBvI KnmQrthXY7un8UcgDSbAsmB9rrpAk1saVNdoJpU2JjUnN/rmpHYnL8pbpVltWC2tcl2UtKrE7BYC uz12e+Iuj2AWK3YLCe4iu12XuZl+rId2uqroNJuJw2Muw1Zjm7HFtCMU8ymcZj6j89Xki7Z5tLXk 1I6wCjYrTaSGdVrzjFkvXXf1Gw0LOuaft4iUvVJ3b2K66wezh/9sn3lP17wbgk3d4TI5LSstdVFh dsc4Ji8zaUa2t5EcX/V07fRz6urnEumRx0nuxb3rrXz4L3rvgbvHl43LLn88vDWlrbGuLSnJZjVq xvvW/TRLdifj7NiN9tCPs0OAmcFcdD7IFlyS6C6SvYUXGMJCPbOAYbKYKqaBaWdWMusYgUG3Cd1X XJujCsdJ2oZzAOfrSH6bMlWPbBomuFjh8PL+kXPDzcyBEZa7jvvF8XncA8SNK2BX5E1+Jv8FJMF4 tE3DwTlspjWzwDkhb5JzZl4zade0mtpdrdnn5jWXNVctE7u0i02LbV2u8/PXG1bbVieszXcKTKAo NzuY3ZTdXrQo+6LsviJVkS4xm2M9uy04cmyCe8BOzbWc4Cqx26FILwU2J2THxrE6fbMklQ7IaqJW HCplOHEWm8rK8MxPbVXVEbRcbdR82135Ffn1+Wx+RRGHtazI3pjJZWZ7TOayNhoUA27lvCl0NIsK i0uK6CHVGzXfaKFI1KYbSHSQHROJRRn5DCUlKgp+Zvi+8Gt3HJ45o+7K265YS6YRkVhJ2cZrdt8Y 7rq4M7VedqfXzEjqrB0/Tp7W673c76+94TLPXDk1m9z6xInJlRU/WdD7q0lC5UOXDf7t2XuW3Vku VDzFjJsx32wylfgqqr06n7147sjl06bnGrOljJW1PessVsdEqpKeyDtoHT5VVNIRrClLqUytzJye Updalzlfmm9ut7UnznedW35++WpmDb/BuHbc+nKz1VO625G92yF46DdU7xISrOlqtTsdVVKVv9mt 9OaoNqgnTC3CqDYYUeCoNk7ag5KoWGingTfqaIwJY7TPaM7CYj6rY9Gy8BOHpv/SNS55Zcc5NxZX zNDPu2Fl881VTV1kJjFsefmcBQvDPwhkumdkZUz1yhlZab720pxlbpat/HX44AWXXmoWSZrBk5GV s6k9vyjTX/HYjk9JDoom/NWmtT/2e5JcXk/PtCntSS67Q6fNpP2D+xpmHu4JqY/uDhrJqwwvvMqL AjzfgPsjxTyjt1cVcxPpi5lHfT4amNfI5uM/pt4fQ3+RUkhGnYm4btwbnC0w9Cd0GPIDTFBrWO4K nhdKhFKxXpgsLhCaxRXCIvFy4UIRHREVw+7oRWMLGjXhRIFfi04SyxOG5QRRpdaoeQ3wPANDkb8G zRqphPcigVFHQCfrCE8l2oaOZBtOZ1QoPSiVpjNbPRNm8htgA8+1tZK2TdLI8PCwwqphvPxAlXqm moG2Vq8XNzKoZi0jJIdXLRl5ZUl4A5NOHvbv20dywi/yh06sYOwjH9Od1UG0JkPYShukQgHMD1bU W1uYZttSptvWq+vVX+RTWczZ10OylMx0JN+XzCQni+4dKjZnh2i/3JxtNIppG2CoKDm7T3ywUPpq JB+3IcpEOqL0MbU0F8Zch6iVxe4+1Rkgp7sNltOj/NC8GS0v/mzkEqb6gbtmz2m6qGf7PWFrWiBr w4WplQv60wo955ZU5/xkbnPSz7ZWVOaQp5bvKa0u5Q85M/3b2pbfMV7lfog8lzbdLLHh3wkmR93I C1NnWvRM+FomIaGJeltLUEsXoG9ZAFfvB39k415ca21D0aNpKPKb4By1riQwEUnldrp9bDqXqQqo A26fr5Vp5eZpWpPmpl7MrlUbA5Yqy0pLn4WzWBK36ThPTm5OR05vDpeTk74NLJacoSIoaihqL2I9 G4R9hdhJbdJX+cry26YQdhC6Vn4/j07VqauQnS5E6bgyKRZJUJYdu2KCiotLCkzUTxHY9jvDHyxe vHLZ4k4i7zn3pmDNiszspDnFJf11s7ZPrKhrqJxwY92UzeV5za5xpeeV1vW7F3V2kpSDg8SzpGu5 zWQJWMM3Oas9nuyCirIDV289UFwSyEp1VzvDuxOyJZsdtYCzRJiAs8SAXnhlMKvVPMe1mFmmv4RZ oxfs21WsY7to3KCBtZh1SJbloNwosw6cEsm4C2yTjrYdiSlu1J7QWcCNGY6x8RYmHNy2Inzi/pEv mKSHiGr+LYPhVeevrli3vrNzc/+EpYuYD54P72upLuQPTSg9N/zYSzsOVbhtJxYmeCt/T0cTa8l9 gbXUwtRgonpbrhAUOoReoV8I0V+BJfw2htVsIyq6yBglW4mKoz/KIaj7yIM6OnWpI4drydjExfp6 YxaCvrgvjj/DFY3UMVeNrGP28YfCb4UjGH6k7BRRSu8oTy4Lpqi5HQKrYXcQlfY2TR9uiG4DlrCs Xifrc/VB9C85ugwpm6ORo/nKvmMkX9kZFZioh+UzFbDvnNh59Cjbc/QoUbGPEVX42Ikq+pysyEfs E/gcJ+QHk1oZYtvhYNGgbxcsDofG1tdPt4mJfaN+nuLvRC36kdP8nFN8O9oy9okptXV/3LnkodrU 3J5ZSy90OoTwPcxL5MFF91RU1RoNZLxZLs3Pu3gBM4uYo/0svIy10MGD+4HF3qxGuXBBZZvi0vq1 LKh1GqNWUidpZG06m80FNAFthaZC26Cu06zVblQPaK9X36TZpbUWa1o1fUwfz2nooCQZzCV8vw43 eJR4RsOqA1wV18H1chxHMzgxmdMCx4pqVtSqeaYPHjKAAe1EZHgf7vL4K8QH9Tjl/Kgu6hpQhxyt p2JK83L9aFPRHffj3g2dcWUfiht04eXwFeHD4a8x3EgOkgZyDjnIvjeyhtl0wsUfGrExf4+1WIUt VsOBYF0DExSZ65h+ER0rO8OA8H/Y+w6wJq+24ec8IxOyCHskYSaEkYQtKmE5EAQBrYsqkiCRkRgC CIoIIuBs60BqXdW2Vm2tq26rHfraOlrbaq11tnZo1VprrYuH/5wnAXH0+97r+v//e6/vuuqRk/us +9z3fc65x3kegoglZw0Eg1lToJHBwwFg4WwOwEmCRRABLA3QgzwwHlhADTysAGfrIaHsGdgOPh9S vQMKDeMD3MEAPoN8n8cwoIY7Ug1ZKLDzgJS/pxoPZCfi0ewhODQ5ODQ5+AR2A25hOzEuDeyyWTwk d6SezwY43oScVBa7lbmHGAWNBVYw2aoCDNcwY3HoBZ1t9GpwFJeB8QT9CIdGYSMxHB7giV2XWcUw AuUz9xO6EErFVvEtwEI1sBv4bNeFPK4XN5RLcEnFQopwJYJgoO8ihEYgKCkIeEPtFshotzu97ydE mEKOiZn8CTe6l7fAKqZL6A76VboEdICJoBgso4n42P66qFmDBjfG6pL66XQtGRkt+C/0croArAUG 2Ol1elynPG13fcu+Pn1jo/vGH2qatTcxMT4Bs2ssai5cMREmg9rAM09ULKwiCc+FbDbXYyHcWOL6 PlgGUldwW4mhfscwhUyhV+Ce7Abu+3LRHegYI8cSaS5GGzw+QGpGhvYI6ClzNXdA8qjv1v5Gz8Cn LPh4yOhxdGVaeF/ruJSKCQ3qIAXx0HAgeeRoGm4rrTZx15ykMRIPik7xCJSPQhRPpF9g5O6ORWOl +gxVuEobFGVTTw2fqq2KZstk3ouzA0CAj4eKu5AX6RUZGklEkq4LKZWrKkhFqFw8ZmSrgEoeqoqW k2FEvW5XbFIsENaH7YxhdPBd5B1HPr42kiQkFTiCvr9ZERe7jogSd7t7IYGONRSLcNL0nMUZQxpq VRa34PiZrTVbEvv0oeit9Nzu5bwFzM9ZKvpi0QgfPn3PWZoYG/PySBfwKnjBvrJwK/xFNzhsz0jG 9siwWn2uk8hLFCbqJ8oSjRUN98zxKhMVezWI+GJRo1AmjJKlyiplhMyVsyhJnC1uEBNisZS9yJUQ Si0yYBECrN5H5iMVChVytNgcSYMULvZd+2LDiCjyRgE8cFEO/Q9jBSY46oRR/FOOCtQfAeLevgwJ IuJDStLnVo+dFqoMgh6lmp60hW7Cm5s/yMsvenUByY3PcRexabNELhvyKBb377xAnfTT6VZNefOL dKhhyrt+pIqp69AT2bcb8++aoRdAzcCZATPKjyuIk+3q+l4/AAJ8D2+PWNDHOx1keA+LMnKruVUu U9xrtE4sHMpK7KUmfYkk6Popghb5knK2hm1hE2w2fxHhIlfXe4nr5V7MludCVBgWg3yRn9A+RxcC jvsAu0Mi7lY6pFqq7iOOUWeI09WjxcPVpWKjeqrYpoZKB7mcbLW7Gmf0D+O/ACmmYO6F3Mjelwfd wQKJvJnAJ4IreIqK6bn0wd30jSmhNSCkLcAaGJaQl5O/N3ffm6AKBC0CMpNqNP2wTTMuLCR+dH3u 0hc2rgVfn6NvJOuAcVyxk0ASG6Md6CIN8O538rUvADtBTa8fVOgsEfYLSUzyEst94j9EthP58yQT N8/U8zGouzEKJwi7Gy6EHjjBuOHIgnKISGQ91WrmQocRA19HpVC51HjKQlGIW1QXziZHsnCKpFhN cBRFNhI4EQKUeCrIxK2gHmf5Y/5ECpZCVGKVBKvA7q/DHw7cTqPQ1TA0Pyyy8zKd23kZLAIloIQ6 +SCSOvnwGukGEaZAQg4hKwtG6n0RvQTF4fLhOrMInCMU1GFVLIKl4AnjGA4ECMAEMoFeMF5A2K+l oL3DkhzWYzfG77q0DZoY6P5cQqaGkMMMmkQHM5NsHBsfJ/TuvnFEvkAUNxRPJgdzsrgpvAH8cXgO OZIzlpvPM+OFpIkziWvkFfNrOQ1cC6+aPxdvJudym3lt/NfwxeRr3MW8O+AhJXfGcVKGi8hIXE72 x7VkAqcfV8eL5TtBS35Jz/XTxeFymPG6S1xUYqw8F9KAI0Jg22l9P1ffOG4ozBpwgPOdGqFkLCQg OewGFgWdOi4lAb6UPwinokBfCoqeGgFGURNAOQWXgBI5giRHDrofLMJTDjO0CMw6uMDMhXOINtMv 0H/Sj2BuBq/8CCTo6cAttCjEZ49i4cJ0kQD9oE1yj55CLGZJYTAYpHeljkMv4Dgg4A47oIdBpubx k5+oXrGmK/K1Fnca8OX0ClBET2Evv/UgDeI6DHFNYHAp9BLyOBsjIK4D0IB1I4Ju6Y0ePDHo/lxB TOg0QBwrIK4pt6h9t5AFGdH1PbmTnIkJMQ1WrB8o9KDCPD0GU4N9RlGjfEopk7DUpzrIqrKEO4Pf ZTK1W4jeWRgXEhKwTi1yXufmppEBTXPkHl2kDgiVMiWuVLKbPfdq7Q9yCpCW1CFjiPxJtbjbJMYI QG+j4c4Uob1A9yqxgXFPXY9D/nMHbwiLTXDycNenxZpDfUcEx1jTVp+pMBqAclXH4lGfhSkSAGgE UUBMvwaCrrFcBeLkmIAwqdQlbI5bf4mH++FlU5fDsIrLKhiYJAZCoWr/Z50k5H5D1zWqP5SiCMYo 8frAdJDu+4KwWNhANXiypO0CERfz7iDcOOKZ2D4Zy53fzNntx/CEXBXEVpLDVUHGjo08fnTzJ3Hc BYntd3396e++e3GBXkivAyV5704+9RM9v3hmVJk2ZID2pXl4MrRYW5XB8Sxp59mUXPo4/Wv7Gplv 5zEB7224yiPh6kwmm7AQrE0foCGSuImeWm89kU5mcjK5mZ5p3kNkY2SlsmlyQbAc+rlSuPlRGCpA B8QVVoiQ46gRAZHIfamTKCkQBDK3ZbAyMNB3KeYmwgJFgQ2BRGCkCgSqxquA10zWXiVyxtB9AnoS dwM5NIx2V9u9YarnCsx+y4nuPO2OQM89F2P/8T8W/TF61ATTi2Nuzqj8KD/KNVGtmpD88murFqaV B/pHu0UN3+03YPDgC0tWXBkyMEWnpI9LNO5uvjtXrHlb5ioNc6WPKyPhCo3uukzehCvkgsmx/npl Bi/Da7KIkIc6I20Et6IE81gqEAG/dspNLMWbsT3+3jM5exWQBfvmS7qB1gmRXqBCGy/AHxc/ph26 tb1IJ2/SHQVrJh2/mzco7aNCY2MagO5lcH7AggXW6dqKqsxBoC9weul89pA8tQJceOiPh4gEW1a8 uSQI0olW6hHZgrliPliFPi8QV/Oi8L68VDyLyuKlCjJFo6kxvOHeJlYpd7x0vLsNr+XaBDapFPzu 4+PkuU4iwjgiTh6niFPJoTgcssPJjct1a8b2+UX6AR/QLNzry7gczBPbbpPbfZ4Uvbyubp9ZHGR3 zshHj45wdm+3nu6vrDszk95Ed4DhQAXVlJReRkyylLRwwG/N83Ij6YvaMKABnsANpNO/0o+GT7aW 1cAdqIZRahPLD1pCvT4QxsodroDPEawTC53R3wTwEnrJvKBl4YidmoXjnM3OuDPcNTcSkNcIjQmM JKH0ExKSGK8R2G/HfQGj1MQBMVFwF6FlIJq8PbLCJg0BbvRdumPZsu8u5DTpKCe2JLOce+fRK4T5 juzECT4XSnk1VFk+jmfpWr2CWmkPpAgYQwkBuQJrplZgQARwkMMdz7Vwie5H9UlJ3c8R0fNDXAKl UMKjm8E0smg1ECPdvAFiljCYffUS9MJyswMRY78RInTiHc97mfGws30c+zQ8oUrsRX0y6Ub4uPoo Pda5veW9022HNyd4iZdI7C7DSQF3iVQkFAr8mmUb3EEzLnZuFmzAcBEO/4WqsFBNaE6oJbQ7yO9E j0AZFcNcUNu1DBRZj8vd65kKk7v2aiTv0O0ciWRwSoxBiegs2DDRvEFTdmzCjv10O1sizkgNH0H4 PLqCa3MrAwMVao9HV8iiaYNzi8aPKTl7vDMI1+ZZYb3MwR0lgdy5Qe0YAFxdXPuKLa4kEDlzlriI BEJnAA+ch8ZjvAcu4jc773a379G7DsqZOzwFQ5n9LoohOxatuSslodsFYmlWutaYiKgcv6Vsx3E8 PK1VHuQvD2BIGpLz9VfMyTpPBcOThWJLaOtcO7giBVTKQqiTg7yhugqE8zGho93W9Y4bY2Njop9z D0YF0/vpczDtB+nAHwSDZDo9ICBQLh8dHT0sSBHir5CPStCOwrXwIHwIkoArcAf96YOdZ9W1pUUt SpW/T2hI28SxrSrmt8OgFaENVH8oJaSjkvTqNDxNmCbPFea6GIUGF+jy+HDd28UiJ6HfUpYb31sK CfcXeHObnXYr7MYEyiupx5hIEanMhUu3sHrsiZ34/sPTB+0oGd8yAIkNGpQvr9LzLbXQoATmKpFB mXslY2iOKogOo7qqoEU5Rl9/YzG0KEcFnHVIn9IG8qaD1kR9CNKnWfIx8lK5RVQnZyNdKhEiZQq8 n1CnSMSMOu2hUyF+SpnGPatMR75tOvEno0zHNQ5yBgW9tCltwHkDBzxWqMG6R1891qfMziPOkBMx CRa/EzhZnHCoe5DtcocON7lEKOQL0Z+7lUZKgRO7mbvbpTsggxQmdartQWrAM4eFOCN3L/bPqk5D sqvZnOGikRBOHI7Uo1NEFr1ZnIp+EwFg46DNqYMy0mBNepEucrDHwMgqUMuv9a4KYMuQaVVAZ5eS wyxRDLWHlxLGTznQJUTGFgZR63xFbESqC7q0YQvWEW4K5Uwv8UyFF5uJo3hMHKWz6ADb7nJLekVS arvFRaFUAWO1HE+dYHTk2L32LQ3/o+dPOvtdr13q7kwXso4+Qv/efidD4T0wOX7BsEnFffOVs+Nf XQz9I970n5NlOcdNL9TEGuIa9AvagGHTqXh/oHQJ93JXREaogsRcV6Fy/fQ130T50lfi0jVhylBX vqsoaBWyBV3XiCnUG5g3lqEP41HeFC7kW/g4X+TMXsfnCb293SGvAvRYEfMV+gKOs6iZxzGzEZtR UdAEMPeLUfbLRcZIoCvsILvrh8yB2O7v9jwMiiKm9Gl68cvjixfDQGcY/R4uFAxM8xkj8eMJxRtO 4M534ME9cIe2Jo4MCFB58OC8r3ddprhkEdRX/fUqHsuLlekyxqXMpYFd58LGXSmuULwEbm1mY9vV FnLp3O2XHZ12T9WutRy+QjC66+yhR6yguHSH4a3KPZ+CSXypS1Z6hCUalEzLzD59Ev+u86vhk4OC /P0VhA+kxA9qTldICQsr0wdupqBZ9cQHUiNh5Adjv1Ym9muBsZ8BlOI2MBUnmYBMwRXCkBJmKMwU 4jBcQ+8NcSI52RwcI0SwP3SqxVGOtwbQi2Fwg/SKELECR4hIudLZdAmdC+oBCQBZ9HAFWfToEUGi 3R0OLdZ6SJkTtlU/mYuzSE/cjVThwWQCSMI1ZCI3ijcYZON6cgg3lTcGH06O5ebxynADWcYt5NXj FrKea+X54PwWJ+CEGCE5JFvKxu/AdW6B4dUw8CJlBJOoyaCBYlVxKvmPY1AhzmHY9IQHg6Vg3rAR IAMuEsiZEJTVHYLaI1B0kYK4K5jMPLCCOUD88RGL3ug/ez39Bt3042W6HvrWdQdvgaQr+xGv+J+d fMjvA4KFfhDPflBDu0Oe2dh8fRKHyqBGEqOoYoKCFRSLIjeC3dDUt6K3tN5g72DjDCN8gk15EEGE moonJlFT8SqijrKx+DjiIACuEQstFI5R9heuhBTpjePcSG42l7ndRW952PURehzXa60KDjIZ5yDH zg4TSeJvAgxYO1+m67bSQ0AdmI+ffgDAG+QYSHs+1HyVkHYuVq0fTrA53hw1J5GTziGDOXGcWZx2 zlrONs4hzinOjxwup83+tpkPnomnsifhRnYdXsVms4mlSPhL4WJhBMmBbLJFbDlzyRPJvNWE9hSU eFRkZM+jhQL0PlrB5Nb6TxSKGCYSBQqy8uFlPKfzCPGoczee+zNeBdg/dM5j3gmVOdJgrK5X+ghw HSkI6EEp+AyKuI4IJKYR98i55GFqLsublfRE2srWsg9xPDjDHWk25xhK3HTuXp4fr4ZP8KudQpjU 4DzUkWwwddiTwF0wUfCLsK/wbeFvKIl8mBQvWie6Ku4jfll8ReIv2STpcklzeUXKh8kk3ftP+if9 k/5J/6R/0v+OBO3tAGJoz2/06rDuX6YG0KHROWAcGvsGB0xgkVi5Ayah51fjgCkINztgFoSXO2A2 ltiDhwudtLcdsDPIxHY4YAEWCsMlAgMkAecS4H0dMIn54WEMTMF6Hj7aAZOYF57BwCxYz8JtDpjE 3HADA7NhPQef44BJzAN6wAhGv0XhhF4RZ2AS88cXMjD6mxwGfLsDBpiA8HDAEA+x1QET2IvEAgcM cRJrHDAF4X0OmAXh6w6YjVX34OFiPiTpgJ3xDlLugAVYPmsXA/MQ72wfBwx5ZzsxMB/WS9h9HDCk mR3KwE6INvZYBwzpYWcysADWi9jTHTCJydkVDCxi8Ix1wAiPvb8LkiF7pQOGMmTbeZQy9Gx3wIie NxjYFdZL2V86YBILZH/EwG5M/7sOGPX/iYE9UX+O1AHD/hy7HLzRmnLiHTBcU46SgX2ZNZ3jgNGa 2tdOxvTPdcCofwoDB6I15ZQ5YBLz4dh5DGf6tzlg1H8Kgjm95MzpJWdOL/o5veh36tXfqVd/p17y d3LIf71cp9Fq5FmmIqu50lxsk6earRaztdBmMldEyJPLyuS5pokltkp5rrHSaK02GiJGGK2GwopC ualSXii3WQsNxvJCa6ncXCy3lRh7IZpoNVdZUHWRudxSWGEyVkb0NPbpRpJiLjOgQiWcTh4ToYmS K3s6qRydwlGnrEIbRF8jTy202ozWUeYqeXlhrbyq0ghnhZQUmyts8sJKucVoLTfZbEaDfEItQ0/6 8Mxk2GplChar2VBVZJObKuQ1Jaaikl5j4aepoqisygCH2sxyg6nSUgYnKKwwwFEm2KEI9jJW2CLk 3XObK8pq5UqTSm4sn4AGPUZV0d35uRQx3Q2miolyq7HSZjUVIVH3mh0O78GVyBCgNMFZbMZytC5W E5zVYK6pKDMX9p4U0lxop9RolUN2zXAqmFfZLFU2ucFYbSoyoj4lxjLLUwyV2GyWPpGRNTU1EeXd oo+AaxZpq7WYJ1oLLSW1kWiKykhsBGbErJgBK8Qq4I8cGwrLE2GNEbPB8tOtNqwKOEP46jMtxbBs eKZ2AIPH9lS9FtNgsZicaCP2E58QB2C+BVsPe+tgPWqTY1mYCSuCI8xYJfwphhjkWCqErJiFyQth jQlCFVgEbEnGymCSY7mwbiJWAtsqmZIRfqJ5qxnaIp6hzsT0s/OFcBpgezn8tGKlsA7Ni1pKYO3z KZrIlKsgTd29i+BnOSyjGUzM/BHPGdnnGUpSYEsZLHe3VDq4k2MxEIMGi2K+K+NZTKqnMIX3YMpi ZGSnvoaRHuLLxvQexVAtZ3ithZ9VjJzsvNplUszMbmOkg8oWZlw5bLUxOAywbgIztls+6dhwLBOu hH2stVeLhaHYAGcpYjCaGL5qmLmKYP78ee1l1LcI8lPFrI2B6WuGuYFpt8AWOweIe4NjLpMDQ5ED l5HJ0T55mm/UXsZASjhKBT/R+k/omel5VFU8g/nfl9Fj7AYG00RYZ2V2iY2hu6hnVz+fd/vsz9KV 2EsCiBM7LzZmvu7zYnV8swqSnRlKH3FuZvb88zm1y7nwCZkamXU1O3I7V3a4CpYsTC5nqK1muDH2 4EE9y5hz8l+tUAkjOQs8BZEw1TApgpHok7s+wnHOIiFcy3A4keHRAjHUwtpuLiqxv9dvpufqt0xY XwKhaogB9ah6psdAZqZK5sTYGO6e1XlXIa+l2F2I5Spsebp9BDPy6dpBMC+DI4qf25rj4LEK7h/7 Dqn9Lzl7hipSRvYnE8lUMpaMJ/VkP3IImfAMhvy/1e5DEHVAC0vPtqAdbIH8PiuJTObcmyDs+EKh rirsq7/5JW8CQ16xCANdXfZvVWL+dKQb5vi2JQJ56WSvuAD9eY1oaEVAWaGtAo6FfmVm/iA55pab nSXHfOBcXcyMvfKecfHQNjx/nF+vEaDnE2B4mbmoDBMwuZTBAxzYoJcIvWd7SeT4DEa+GkYSs4k5 xFxiHobeSruPPYBNMiBnShwMEPMZLDYHNgc+92IMwxzf/+b+oqbJfTSLG9oyqOUvZ8DGVze5D4FV A3EAtHwNl0WpBQTuRWGaQhZPzQIkaIrDAbk6TzNME9arxmeN3wwfrC+TsuEGqmRMhJE5eP1R0ih6 ISOlhxJnnPvS990pxd9Lp216+eWscOOC0tVNEq2miRyvaSIyVxM4wHFexEbxuZyusSuOHuwe7QtJ sWjVGhWLGE7yXfxTzZZaK3I15coilVybkBD3lFMaofXT+Ng7uz7XXdUqNDLUTrh4PG7PNZtt8uQq W4nZarLVavzcnTVxmngd/Bel1ehGuztrdbAYAyvhv9GaWkZWEAnLBR+ep3XRiFGB48J7obCyBPps NjiNSCNAlWwXdq7RUG6uMHQTxvs7wgI0CjthXr3bDUZ5nmliBfIEc1KTNU3AX+Pcs4AAUBjRBIQY rOfhTQBgO2vrTxdsS094O/od7dn7QTGDaw4+lK38V/rk304O+OXreR+XZuZOuPMq/nHWmcFlkYH9 jQdOBOzkD9rZUHU+ff+GlwQ5h4LUt1f/7BwgO5kc+GDCq597pr+5KEP26vFtkf4fZ4RPM3/r6pc4 L0GUcH6/6k5xYjjQddEhg956vwy0Ln+4Z2tRQ9P9sasbm2ct2Hx71+K1n8e/lTPLPaR16HnNXazf ncP3+zV+0HKjLGFdRPTd7RHv8eonvDKleHlHpXPLe7c/+UO+O1syv+ho2Le6dM+bezPaE3PyPE4U D6vd8G7rkRH9VzXltFVQW2I+nBq4P7e436tDj6mnR1U0D2SdXPlFRgte0YK9cbD1Yh763gCwtvGB pvEvjQsUp28Q6aThsThw61IUmyA0jWtQLSAbl2kal84QjfnC8pvJujJg2HTp1qwFXUdft/7P77cm IfYhNrdv3zbxyf53i65f1GuEiEYXALpISkPAD40vqhCQbqT0mO+Jaswy5r3fz34ydNmwtIi1aUW3 NHzULCTRt4y19Do6BNoRUzdump4RfPvEvqG2NSNDbKFV21o6N2YunoJlXf3sV49zpkOCNdP+wFMP f9Z67F7esY9W7R9hvlWUtj4Nu9l+ZNkpn138VZ7Oi7856/euqv63G29VvvPShYQF/Tom7Ysv/7Lt vYDOi1dPm7ivtO2nL2N7o//4a9p9kSSC+lXVviilVDl5Z/xLl9jOnxaUHN8/I7m0+O29O/cuiP7s NiGaVvfnl5dSLk6lL19+h7578ZTzNsvphT9k74hfMy38637fRfMnxOGrGicFzL47tuilzaP3Jnwz ft7wZq+oPxM7Vjc5rRk3d1vYztffPLrxrHzHAY3nLLnUOXRf7p3kSy9qflioNLV+aPn+j3UbT8xI sVYLoI6pgzpmgkPHFILP+zO6UNj7HFFQz/wHTzVSOAlQx8TpdNEaXQJSOFpNVE9R0zjz/wttzszG gVuXzMrOye3uTvxN9/9W9+zXzH6Ybn07r3Tl7Gws4OAHX/v22zJKH/9H5StNwT+1S7C8b32aBH1P +O7d/1fK/KVfP4r3urL7/g/XvyokDqz+6nRV1tgB62+8eOvL701jvCqvbfOZTx5Xpa02jIr06yio +NdGj4Qm4yfr9m2savO81rpUGrytIbj6ja/jE5p/2BZ8yuO++uqXn7qNzlfcXjq/tUVF3xkc9tPc e2RS/fHj7QtbnCcT339BO6XEdH2zK+n8gnRe/d1vhrw75la11bcmoH52zCc+BVtziCEDy9nrhrd1 sGa81fhu/tAzjacfHEg5qP1guPOrp/IGSzS//vhm27QXP6kbLW3lbI8zrf5VFziP8+v9r6V7Lj06 fu0NV4fuuadp/PP5uufxKY6fQlUe8da9Nm5hy/D3Zu85/OoW2wJm+XyF6NTDg8yewegN3wDSQ+M2 4/nHPg11kJH9NImahNVxq2NaohxhepG17Kkw3VJqQrWRjsuNysjUPLjxImCVZlA3hQCQfTV9NPHd ZQ3eEva3cT+D0Gjthcn21IFitI+SmLnRxfl3WmxOqT6TunHX4ZQHgcboTVWbJ2sWtO+Y+cB6hT4e 93MfS8cwuWDP5O2f3jl1Zc4vSkvlqRuXP5p68/cR0aNnNP0q+sZKXJMMvX7eed7UtGynwqrOiuXs 8yfUoz2cEzaP7zzbRW7A1555sGDt3v0fTspP1I67ElZx9PesUJ/bftVTW9473Hp6S+iNd44JDl5Z 1fDL5780W/ObPCpCj6xcst3L70Pzou8mvPXhkNJ3P73Rb+EPWyM31tUkTJyETW1aQYguFC0ZHJxy YYn/h638L6Rrx52r1Flj/bqOqA4F5mYXD/rU13f9oeAEU87Qddc/YpVFWL1/V5wtDxw0o9FVP23V MVt8RjbUPiug9pll1z6iSfxXsw9iQRvF36XLRtZNXPO0DvrP+DqxUPnEarSa6Og4pHoSYPE/4Ovk m8qNlbbCcsu/6+uci6t4+N6RlIzJHkdODOqfd/DBRumeMN1eSXbukZk3+kd9O1i7ULnjFcMlWU7z no+GnGyg7v1W9cHcf719apPJUjwlpPiXHTt/m7X7+M0NnZI3+KP8VZGf678dQXpXv19uKM/I/+78 7xcOrJr5rxkXGzLxuMV/HlzJGeFXMvD4twerx0bW7wgit48YM8mnqGvGtL43T5FBWQk1NnbBR2PP tMSFVX0quOaXwJ1WTa8oq6i7dL3/S0tXThaMC832mDBet/LLmUPV/mNL0udeiGwW5Wy9/77X/LKb Qa+53Dsq+maW4E5TdWXs4SV1a46NZ12nNrdE7by3eExzcvPIWYsrNsvCBh0zL0+9NOmXhuAFpXZ9 0wSUUCKBz9M4nP8d3o6IxXVEFq6A+aLUXorS/MvQpKW7ozcOaXlp3/Jr7yQmpx7+QuPZM0CKk05+ PCyPCWNTseQnPaFn3KjnKKjFWWLtR9Ny9ooXvF7IBoJ5lvT5v1Xm70/iUuFdu4blzfK5kfDKzrUj +Bfm7Uj0PvnwnXWf7twyTOFt5pimlxJr/AfcKNtePs1/14Cvmv+YL/yAPSf2w1+nX7UUpK9a+OWx E+cXHLx8IPT4tOufbtKdat19tOiT2JMeigPVFxKXbfOuXKloO7N9uyR/3p3lHxkzlimDl4+fI0z8 l4txyqC9n787s0/25gkjL2iuXk3w/WH27bMJjfddFPMMM4pYZPvtZXhq5NQBbXu68G+N9zMunCVs i7ZRFU7HVpxTFk4b9Lv7crEiHvdpfYd1qF2360f94bx++9fPvvBLcdz8O/7ty49trskf1ue0NW1r wF2ooDZABbWw2z1iLQ63P9P6z7lHzygCpKPioTcUA1WTTsvoqCh7UYuKmsZt/xPuUYgmyF70q0g1 WdDFeVpeujw9b2ifuOR4XXhsfHxyeMKABJ02SBNg58nnSZ7C8xBT8jyjFV20/7fqbUkjT57iMazu 2yU3Xus813ryoeAll2sb4pSSajorZ2P10tBFAy+tH2HCf1w8PWvWdw2Tf6vCvtubWvbQ/M7kW+qT 0xaeWOy+4vVDe+7/Nf184eVwjd/y4PDqpJ8GtC/YdGZ23Jljv/3x+ZiPH5Vcum146bVfPpbcX/tB 86PTc09Q/faD6pwQ4l7zTreW+eM/KFCF9f38zc6O0TG+2W4H48/4FSb1i902QupasyRR9ADbvOj7 griNIXuLwgZJG4f/UHZtvXrJ/DbB9LXYmzWB7I5QC7ErNPDlZRcOrfEfciBzFKsm35q6ub/h/KJm zsgd9NXWwdzYbdvuRa2fnrmmtkE3SiVY+f6fl/quTLo+ILG3O/VYISiXtB3AE389u3hP/QDhg6N3 pq/oOvmEp/RcjfF/4ynZKi1Fhf9PPKVuTLbnK+sn/D/WwedpK+zmO4++/7Kt+DPVD6N3H8eapruP PRQ4SrL37b9Kv2ml5x99v1rm7X/3r8ufbd+dDLzi3h0U1255cCxqnXLeLv4Om4ty57aqy6Hc7+dm X+xIWrozWtJ4TXTe99wew+dDcxIz53R6ng/adKq99dqQT368dT/ZvQD8+kJbfXXdj2a6Vf7OouXz lh0Y57XaVRN4ac30wld8VaqPB7/cJ3Xm7JsXTs08nx0Wk/hzcjLYgDnxb58e7H0iZf7UzX+Ezy9Q Xf5gfsMrrtXbxz+UhmwwS4pSlCP7zEmcq7+y89CxhS/4DBhR+tLRhVkjKOyzexp9+tCLnm37/xTd Ou91Uem3fdjtmkvBP+zlNkrO+fX5Il3bRL4GNdZSHABNY+t/MGR7IpB8fNW1uvEwsk6OZeMSWqfe 92hw3sclvlag6d3qCrVGz0BSC7f6lMZbsftcnDfd66iPXfXzwZ3OG8Ys0xT3GuKkHakZsTpsRui/ /3Tr9eAZgf/Gszz5U5qJbALYsNLvedY5htc+2e919eI7D7sI/M/GEt23p7WH69bd/2aloH2O6MSi T99K2TRb9eIIXdO8zPNLlPzkrJF7Pr+TduSvDxaOb846lDhlnHyi64iGujN/5I/MmGt2ycp8u7m6 /ViNbew38dc/c84fd+xQRk2aomoN/93dVx482JzzcUXMBplJtt93y9KO9tuGFs65vMXvxW/csiY7 cO3/WQ17Z6OVoz1/tsBigdM75/05NPekIH9r8SnLivc/mg5tYr0lP+3BtSe2uWU23UrBCzZO+/nc zCLW52a940TXl0zh6Xttm+TuCTJas8kxWkzzmXM4XGk5w29pv+nNFua1Yq0GkxZGTT/2e/PtheJ6 faHyge4Lm5jkDZqYpBGxxGbYxMQDFOKge3JEryJRKm52aHJcEGsggZwWuREDv4xAO+EyrIb8wBrV wMACWL0aGhmbmkRhJEWHTeZ75gq8eOEZuOz6uw8v+E7drHyCVj6Bkkjtm2NXT7zKYvK+LNNXKKNs c9B51yX+xK8S6TJXLP2/860yN+PgfHjLxu+MjPYxrbyrS6ZMfP2rUOLajZhYw63f123ZYbVohsVx A40pGms+vhNp52Et3qKzLOn4kv8b1srm8+578VODb+7ZA2aOv0Mb18ZcDDdqbeYRfGpSusnm90Q9 KYnkPa+DVO3ZvkWs/v2xRsx834bT75o0Pud8tQ2ecvTLJEuTG9n7oqWZgirFG5R2zKozk02LPrd4 8mbDX+wL9stNnxLH8Zib+16n2AWnuVPzqpduDBO2+3brzaRu38+XeoTubytTCOjaOXlRtf6ZDInV cld0uZxEKub6bnDn5WxqtLhSuZ6Zw/asfwUDAwDMjqQhDQplbmRzdHJlYW0NCmVuZG9iag0KMTM0 IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIyND4+DQpzdHJlYW0NCnicXZDB asMwDIbvfgod20Nx0l1DYGsZ5LBuLNsDOLaSGRbZKM4hbz/ZCx1MYIP8/5/4LX3prh35BPqNg+0x wejJMS5hZYsw4ORJ1RU4b9PeldvOJiotcL8tCeeOxqCaBvS7iEviDQ6PLgx4VPqVHbKnCQ6fl176 fo3xG2ekBJVqW3A4yqAXE29mRtAFO3VOdJ+2kzB/jo8tIpxLX/+GscHhEo1FNjShaiqpFppnqVYh uX/6Tg2j/TKc3U+1uM9V/VDc+3vm8vfuoezKLHnKDkqQHMET3tcUQ8xUPj8JSW8rDQplbmRzdHJl YW0NCmVuZG9iag0KMTM1IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI0MzYx L0xlbmd0aDEgNjg2MjA+Pg0Kc3RyZWFtDQp4nOx9C3gU1fn3O5ednd2d2dnZe3azu7O72U2ym2Rz 2yQLSXYhCeQCBEigCRATbgooEoRSBCq0ykVUBFGLl1pvlVathosIiIp36qUVba2ttaKi1dYordZa Jdn/eyYQ9fv7/57ne77wfF+eZ3/J/ObMey57zpnzO+85s5ssUABgR2Khp76taeJCR7UM8Nl2AMe6 ifUNEyDMHAH49G5M5Z04tbVNW2msxuun8bpqYtuM8SdzPgjj9Wm8vn5Se1vjD+sLdgMYsgGYR1rb YqWXTL+lFID6AON7ZtZP7lj5j3VLAYyvA2hOzF86t3fXf379GMCWKzDN3vmrViqT7hxHA1x7Cq93 nd97wdK7f7N0GsDWKgD68AVzV/SCA3T4etdjeaYLLrr0/D2y8zWAHVsAmj9etGDp6qqPTiUBrAcB Vry4aOHcBX+c04mNoy7C9BWL0CDl8nfhNWlPzqKlK1df0l5Aym4E4H934cJLLs6/KR/j3sX6ctUX LZs/d8NDO28F+PNqAG3v0rmre7koswLzH8P8ysVzly68ec8P9gP8LQdAN7l32YqV6VbAtJ+uJPG9 lyzs5Xs/SQFc/Rm+xmkgfa3R+J7uXhfplqr/BW4eCO69rD6fnI/teProV5sGdhp28ovwUgc0DAHz 8YbB6QBCAcYvN+xUS/om9hEL8zBMAEa9psEEMZiJAT19esjCytR20ACvuVlThkWGhs7M7bCa3s0D beBYRsOyNHsHcOkUKLNJD5OMk9sUBdCgWDjvYCc8zxuoBxSgfkbi2C7NcdJSoPgzVaJfHjqYMBVk 7odffLOSmpdhBTkzd8JDeOwkYe5qeIX+EHbi9U14HmDuTL+jscOVGjtlx/MdeOzGYzIejwzZ4WY8 1uCxnLmTmnW2bCznX996rdXg0qyDY5obYQUXwbMEx9ib4BhXjtcMHGPOgyuZu6BAbcVKtD+GaU7j eRKsYF+FY2oZ29G2GjaxH2P4DdhLytR+CHM0a6FejV8Ll2G9PznTpvu++frsb2ARexoOsVFYjOeL 2KdhCfZLPQlrTHCILoUH1XRH4AkMP6I9BoeInX0Dlqj5MB2zRM1/MZMLtRi3B9PWYDtn4rmahNly 6Bp6bWoNZPB/DRxTN/2/rkMGGWSQQQb/P4B5mKKys4uNQNZgFAVGSqIowzBwyUOiSo2mrKDNKK3U Q2GOURTBWFrgKS3KhmxKXRWJIhqzRcN+MO6XDSZRjMiyQW+S9LKafWRhGPESM8hgNIIoFgECfMGn gQc+PYh7Kj2yXmUDGJAFEJBFENMDqEYjsgQSskllGWRkM5jTp8ECFmQr2JBtKtvBjuwAR/orcIIT OQtcyC5wI7tVxlkg/SV4wIPsBS+yDxRkRWU/+NP/gQAEkIMQRM6BEHIIwshh5C8gF3KR8yAPOR/y kSMQRY4i/xt3MAXIhVCIXARFyDEoRi6GkvTnUKJyKZQil0EZcjmUI8ehIv0vqFC5EiqRq6AKOQEJ 5DEwNv0ZjIVq5GqoQa5RuRZqkZOQTH+KO8JxyONUHg/jkeugDrke6tP/hAaYgDwBJiJPVLkRGpGb oCn9D2iGZuQWmIQ8CSYjT1Z5CkxJn4JWaEWeCtOQp8F05OnIn0AbtCG3QzvyDJiBPBO+h/w96Eh/ DB0qd0In8iyYhTwb5iDPga70R7hPInwenIfcDd3IPdCDPBfmpf8O81SeD/ORF8AC5IWwEPl8uCD9 N7gAFiEvUnkxLEZeAkuQL4QL0x/CRbAUeanKF8PFyMtgGXIv9KY/gOVwCfIlKq+AFcgrYSXy9+H7 6b/CKliF/ANYjbxa5UvhUuQ1sCb9PqyFtcjr4IfIP1T5MrgMeT2sT78HG2AD8o/gx8g/hsuRL1f5 CrgifRI2wkbkTbAJeTNsQd6i8pVwZfpd2Apbka+Cq5CvhmuQr4FtyNuQ34Fr4Vrk7bAdeQfsQL4O diLvRH4brofrkW+AG5BvhBuRfwK7kHfBTekTuH8ifDPcgnyLyrfCrcg/hdvSb8FtKv8Mbke+XeU7 4A7kO+Gu9F/gLrgb+W6Vfw73IN+j8m7YnX4TfgG/RP6lyvfCfcj3qXw/3J/+M/wKHkB+AB5EfhD6 kPtU3gN70rhzh73I+2A/8n54CPkhOIB8APlP8DA8jHwQDiEfgsPIh+ER5EeQ/whH4Ajyo/Ao8mPw OPLjcBT5KDyRfh2eUPlJeBL5KXga+Wl4BvkZ5D/As/As8nPwHPIxOIb8a3ge+Xl4If0avAAvIr+o 8kvwEvJv4LfIv4WX07+Hl1U+DseRX4FXkF+FV5F/B79P46Hya/AH5D+o/Dq8jvxH+FP6VfgTvIH8 BvwZ+c8qvwlvIv8F/pJ+Bd6CE8gnVH4b3kF+R+V34d30cTgJ7yG/B+8jvw9/Rf6ryh/AB+mX4UP4 EPlv8Hfkv6v8EXyE3A/96d/Cx/Ax8idwCvkU/AP5H/BP5H8i/wY+hU+RP4PPkP8FnyN/Dv9G/jfy S/AFfIH8H/gP8pfwFfJXcDr9IpyGAeQBGEQeVDkNaWTAeRSYIzqdDhhGo8FrLbAsaBkNw2qHwRIz AK/leS3H85iO0/E6LWAUr55ZwCTAETD4CxyjI2EWfzgtx2lAM+J+STviJWaQwSiE3qBHybJD2kVp 8qyG1XytXbST5+NEqdxZ7WpRszxatAbU7pA4MSHqXKtlUPsGVfMcq+W0KN6MdjPI4NzAYDCc1S5P tKv7b9rVkShep9Oixx32uzzxxAbci53VLvdt7WpQu6hxbUa7GWRwjiCIAmpXwwER6Vnt8sP4hnZ5 rU6HCbR6nZ4n2tXx4rB20SvzPMvzqnbVfFoN8cta7TnQLj/iJWaQwSiEKIooWXW/q8NtK+hQddzX 2uWGtKsj2sUDNa41qNrFfbJO1IGOAyL7IZ1/S7tYiAHX1efAS2a0m0EGCKNkRO1yRIB6ol0D0a5u GNzQm3d6vd6g4w161C4yrpX16H31kh70Z7SLm2Beo9MxwDOimo/HtTVm4dXokYVuxEvMIINRCEmS iHaJdzTgthUE1K5WPwy0C0C0azDodAIKG3jRIOiIdg2qdoccq444ZlW7OkbS6Ye0qyMqPgd+Vz/i JWaQwSiESTaRd3iIwgSiXZHTct/WrgjqEy1BrxMETKATBVEPBr1eMMgGMAxpV6/n9XpOr8f9skYi +Tgd7osz2s0gg3MHWZZRu1qyhxRw2wpG9Jj815/A44c+gScIgmjQiyIm0BlF1K4g6AVBFkDg1e0n rqgNes5g0IBeI+Oi2qDVaQ16I3rnc7A7zXwCL4MMEGaz+ax2RaJdSctrv61dCYh2RSNq0YgJ9BIG QRQMomAe1i6uqA0GVbsGjVnNh9o1SGjOaDeDDM4NLBYL+ZAUef5jxG0rmNBj4uL4LHRDfxwoiqIk GCQjrwODySihdkXBKFpEII+aMR5X1IJBKwgcGDgzycfrtYLBZDDoz8GTJWHES8wgg1EIq9VKPjVF FCYNa1ccxhntGo1GSRRMEtGuLJkENAiS0WoE45B21SW0VhA5EDiLSDSv5zG9IBjOgXbFES8xgwxG IWw2G9Euef4jgV4PMq/n9V9rF+0yEO1KJtSiCdMJZpMsgmQUJaMNtatXHx2JokEUtaKqXauqeQNq VybaHfknSxntZpABwm63k09NEYWZiHbNRLvGYaDdDOo7SbJRlGVMIFhU7UpGk2SXQDqjXaPBKPJG IwciZzOKRqPOoDOKZlxZnwPtjvzfn2aQwSiEw+Eg2iXPf2SiXQvRrjQMVJ4Fo0wmk1kSzUS7okU2 G9FglE0OE5iGtItLaKORN0ocGDm7RDQv6CSjBc3nQLvSiJeYQQajEE6n82vtGgxgRY9p+Fq7aLcC 0a5sQS2a9QYQrWaLEWSTZDY5UbsG9bEv7oYlIy+p2nWomhd1ZD9sFM/BU+GMdjPIAOF2u8mnpsiz WysIAtj1gl6Qh4F2O0aZLRabbLJZMZ3ksNpMYDHLVrPbAhZBfexrktEN62VZCyatSzZhPqNBNtnR O5+Dp8LyiJeYQQajEB6Ph2iXPP+xgSiC0yAaRPMw0O4E9Wm03Szb7ZjA5LQ7ZDSYbVaPFayi+uhI Nku4oDabdSDrskk+QTKYZacsS+fgyZJ5xEvMIINRCEVRcKksknWoAyQJXIIkSNZhoN0F6hOtLKs5 y4npzG5nlgUNVoddsQN5XIXxFqtstRisVh1YdD6rxWo1yqLV4rJY5HOwwrWOeIkZZDAK4ff7yaem iMKcRLtuol3bMNDuBvWJVpbN4soi2s3OclnRYHU6/A5wDGnXapNtVsFm0+F+WbFZbTbUrs3qtlrP hXZtI15iBhmMQoRCIVwqS2QP6QZZBq8oi7JzGGj3YlRWlsvjsHmyTTLYfNkeO7iyHO6sUBZkyer2 0+6wOOyiw6HH/XKOw+5wmCySw+612y3nYHfqHPESM8hgFCISiaC7lckbQT6wWCAgWSSLexhoD4C6 K1bcTr9itoAj6PNnocHl80Q84LGo7yFlueyuLMnlFiBLyHdnuVxmu+zOCmRl2dXokYV7xEvMIINR iKKiIjCZzGQd6gebDcIyLn89w0B7GKN8ihL0uHKCmM6VG8jJBsWXHfAVKqDY1CVstsfpcZs8HgHX 3IWebI/H6jR73GG323kOVrieES8xgwxGIUpLS8FstjowmIO7WMg3O8wOZRhoJ1+fFAgEcxVPbtjm gOxIKNcLwYAvFCgJQAC3vBjv9bl8XrNPkcArlShen8/msirefK/XpUaPLJQRLzGDDEYhKioqcKls y8JgLm5rocCaZc0KDAPt5Cu4QqFwJOCL5DuywFuUF/VDOOTPC8VDQLa8GK8EsgOKJRCQQJHiAX8g 4Mi2BZQCRclWo0cWgREvMYMMRiHGjBkDVquD7CEj4HJBzOayuULDcAHEMCovL78w5C8scLpAKYkW BdGQE8lL5EGeS30PKZjjzQlac0IS7perQsGcnCyvIxSIBQJeNXpkERrxEjPIYBSirq4OnE6XD4Ml 4PVCpdPr9EaH4QWoBLIrjpVHcstLPV4IVZXG8yBWlF9SNL4Iirzqc+i8SDCS54xEzJBnHhfJj0Q8 QVckrzIvL6hGjyyiI15iBhmMQrS0tKC79ZJ1aCVua6HGHXAHioeB9hqMKisrHxOLjqnyBSCSrBpb COVlRZVlzWVQFlCXsIWx3FihKxazQYGtKVYUiym53lhBTUFB7jlY4RaPeIkZZDAK0dbWBh6PnzxM roZwGOq9YW84Pgy0k6+OTiTGpMqLU7WBMBRNqB1XCmMSZTWJ6QlIhNXn0KXl0fIST3ncCSXOafHS 8vJg1B8vqS8pKVCjRxbxES8xgwxGIebMmQOKkhPBYB1EItDij/gjY4aB9haMSiZTE8fEJzbkRqBs SkNjJaSSibrk7CQkI0CyViaKE5VKYowTKpydY6oSidzinDEVLRUVxWr0yGLMiJeYQQajEAsWLIBg MLcIg01QWAjTcwpzClPDKASYjlH1DRMmJxNTWiKFUNXe0loNE+prm+rnN0BDIWASqK4tr60O1ibd MNY9N1lTWxstz02OnT52bFyNHlmkRrzEDDIYnaDVL0onn/FnSIhy4cHBGSOeaZqk+TYwkmGHvgjF IIBRMslmi9VmdzizXO5sz9B7sDmhcG5efiRaUAix4pLSMohXVFYlxoyFmlpVfzghTGxsam6ZBFNa p06b3tY+Y+b3OjpnzZ7TBd0j2kBG5T3/p9lY2AXkHSkFQzSew5CPPr8GmmEqdMBs6ILFsAbWwe3w K8WSTgNpdRjyIIppxsEknPRmYZq5cOHXadLv/o8/89PzT9w23On/W6RsM9orK0pjRYUF4ZDPajHL oqBh6QKljwk1BBuCcxdtVRoWKVuD9T31hQUt0zsa6t1+f2dhgYLmeqWP6lEa+iasWuTc2kAS9Jmj fXSogRxL+lJX9WAgWO/3+zHG8nXMwfTRq78RpSzuS83tg6uUPQVHt1590ATzeqLCguCCuXM6+pi5 +Fp7ACuzqL2D1IkcPYuUPhZzq+RGy5kqkrhFPcjBesz1nXY06+o6NvuPuvvMeG7ok6N9EzHFxDUn 3czWBudihVxu3bpZ6bt9Wsc3Y/2EOzs7nd/qhgnBCT1bt04IKhO29mydezC9YV5QMQW37mlp2drb 0KP0wdSOPgrth69y9024urPP1LOIGoNNJu2YML0j6fbLWIrfT9p71cEUzMOLvg3TOoauFZjn3gup WLSzj+4hMUfPxthmkJgNZ2OGs/cE1b6u62DcNBbc0hZsmTarQ2nY2nOmwmcsVUNXe2gYvydIbZm2 J0VtaZvVcciEI29Le8demqLresZ37snBuI5DCg4U1UoTKzGSC4VcQAuF3bGX5tX07kMpgA1qLKsa 1Ov5BylQbfxZGwXzD9JDNtNZG402dsiWUm0E2Bi6rr3jm7XGg9Qd4BC0p4+mvHvzSytMe5W9qb1T 9/bu3bD39r19e1/ee2Kv/ujeU3tpHGup3occzgpfPSXN9M2kW2d0z6CXtVM/a3+wnZ7W5mCnt9nZ tuk2trlpOjuhqZKd2FTKNuLRFE+w1clStiZZw9Ym/Wxd0sOOT05nx+GRwiMZL2VLyxawZfFyNl7e zpbHvezL5SfKT5UzB9Mf79sfaqw4mD6xb78piOePU+J+nVSx39XIrtq3aR9W69S+fWqKL1Ppfbqc in3WRvbKLRa296Le1bR061u30amf2rMqUrfa3RWpnzgwdKPDXbFpo8UnXSFtlLZJ10rbfVf4tvmu jW3bsHHDlmt3bN+4ffP2LVLqxzpThXSJ7xI6tVwnVEhLKeUYpTxHJZ/95FlaeSb1DA3zKJhnmken 5t4+l5ZmU4VWmS2whtioNcFGrBY232pjfVYv61fqWMVazf7a1cC63BNZt6uadVlLWRums2B1zVYX K+PRa6VS1nF1FZIx4gOOEp9q8QlPtvj0R1t8Ojw0R1p87KMtPuZQi48+3OKjDrT44OEW31NPRnxH H4/4Hk3NPOL3HT7k9z18wO978qmnxcePPiEeefQx4dDhR4QDDx8UTEc2HKFThzYcoqUDyQOtB9Yf YKUDMQwuw+DjB357IH2A1+sqWUGkce5iaJoCeqqGOkilqT5zC7S0j++zUHhuG79HVxpt6VswffzG a67x9N2II7dvg6fzII9pUKd91LbOPr6l7UwQ1LdYVqxcsSL6HehjGvq4hkVz+7hg/QpyYSQXRpwt jA19EglLwfoo1WdtWNRnxdB/K2TFWURXnIkceiGV4Pvf9ZqkLiuRo1HOy1k1pzTH2XVsF/Mm+UeQ 6b+m3x5cPbhgsJO5nnynNtwI96JEnoXfDE/2R+BJ9bwK9sJReOFbjuBHcD3cAy/Cn+CTYdsuuA3u g75vpduuWu+GX8IDsA8Ow1No2wI70PpzuP8b6ZbBZrgWbkFv9Sp19hOQT9FWaqgGH4JAH6dWUNvA BQVQD3NgBVwGm7Bex6hJaKtB21S0XgKr4Tq0HoJj3+G8amAmesUlcDE65EPwhGqLoLUdFqCV2Iaw HH3rlXAH7IZHsF5rsGY74ObvKO9HtJ/2w0p4D3M+T91AP4st2g0bOSv5rz+a46RX2S61byH9NsDg gvS/cEUwj/6MvpPeAQ/SS9BT08TtaslXODF4sj7M0SyQI/bSmy+pVFLsl/1yCInCVF9u0MBX5Awb yBKIpoJIDL4WyT035WRwNGtnaHhJR0EXKwgCPYONMl2ag+k395tM9AwMfLRfktTAl/tFUQ28vt9g GIpK6XU6eoak8WloTaxLHUMnB6InuyDZXxZLlhRTTJCxBONlNOO6N/u1F1/UHP/q12zll7FXcTb+ BXOcYTmrWpNwykZzHKOlJF1KRzMFQKZwtkAb6y/rivVjcdVlseqh4sgPw0aviP4CD8468ChdRw7S HyvSb3MWzSkwgBMa4O3UMp2UJVULxbZiT7ywtqbVNdHTWn9ptmFJqCe5VrOKXyut8qwJ9db2JnUa notwlVbe7rFGrJW2ZL4Q8YQri/lifYpP6ZuEcdbW7DrPBGWSf1zhuOppfKc4O7RYcz5/odTj8SYF u0cJZjHEF4w1OyqZe7PEAl2tJhin7cmg3ssXiLVMDKxVnDWWFBosiidWxbrC4KW83gar6KJcLost vGKC6XPstS5yyGZHQjYnErH+WD8GIZnsT+K5PxpDI/6WFHd1UV1UeTgY4GxWu6OiwkKpX0SPF2Wl FZTNymmpYC7HBQM58fKKyoqKynB4KFBWaiexmJpCa0U4zjiXd8xZ2Xr5vIVPDgZ8tb7snPt+2vUw dWFpNbXm8/dWnFr/8mB/eTC4KH7x3Hi89I65v3rN6VFWnUetMBopmmJ3dy9d29mysjW4eQCoV6SS SO7FDdftm00/0NNzaung9hPbln/6zJxNJbE2X+N1y+ouLS2ufnBTwbKCklnK4I15PeVVW4vxVj80 uICRcCzYYGaqTkfptFlUljaPydO0Uo1Mo6ZV2011a5dRy7TrqdX0am691qylKGENS/EkN0gCTs0z JEEdjD52i930WX80iv1YjUOHDMMuKhimZZO5ssxGuom2Wc0Ou93BSO/tefrpPe9N25msbmmqrb55 8uCCF6gTVCH+nHhB3/T4+rWDr9993+DJDWufayA7iZ2DC+h+tZ5LUgmO4Sw2xmYJU2EmbAnbJlIp JmWZaJvKTLX0MD2WS2EV3cv0WlZZbWaKFb4PlDnJUixrOJj+bD+pMAmkJFJpgw8EojK4zmH6PPq/ 1t1Ea4NxcrPM8XI6NxzOjZfZzXQ/VnzyLWNrm5prkjunYUPo6sFXB5UX9A3Prd1AZd93N5W3dv3j TfoXBhWs+Svg1hxmB1AbiVSQuZ9i2/n79ZKW0qZEqlhMiTTcp99AUVREc582hbXE1z85gEdXF6jB 6pNYFb8clP1xv1wm+zWHB966Z+At2n8PTmrVJHA77R94S+2jbXQS52QG4qmwi4pQUToOCboBGrF9 nfQCnACfYQSaZmayON/RLlz0xbrKYmD6rDRGmqujghY6Ofj+dQ9QnoHl9LWk32+iSxgd/T6WqaSs 1HgJl4+SphVaNd3QTb7kko5hh2FF+0kl435GN7Cd7qVLHiJ5B5A+UuujHKBnUjwUUgfTH6T0pL9j VBLHMM5c/Thj4cwZlMuojz75BFNT6XcGX2bmqPNTRSrEUKCh7FSIqoImqKdmUhdQP6A2UXrKTDMx rA0ZhaQSkIx1YR0293dtPooNoZg5A2W/op/nrF8c0daTvemV6bfZazWf4H0IwuZUoIJKGMqFseax znJvA9VkqBdazC3Oeq9ga9LR/iZGL+EYOUCmZckPuKhT52Ig48ZN5mBwkii4LSSFfCHarc7fbj+H CVMWkpIzkdHFCSQttysHx1YUR1fXmTO2mbSaDDC/QuThV8w4KcTLwzjIcGYZmk9QKDilsNd+NfjF 4Gf//pLSUcK/B/8TzMrKCV7afd7anECWPcd/6YLz1tEfDi4bvJJaR22lrqHWDq4//dC0N27edWLK 5ClTWps/3nbrK21Tpk/Bm0HZ8b5Xa14DCbak4poJHCcwRqaR4iXZJ9Ma2idRkiQY1cYYRUHgZhgV OsksY3oZhhGIV8KZ9kTKQBrI2EkDGdIhHtJIxktyMRzxVIxJFDlkUgITO7vG6SpDeSVKY12xMhTY QGmyLEbuPBnW/nipOlXi8GarT/+Jqhh8Prk9VBRnb6GKdzHvb7FZsyaP+/JJvNd3YAt2oKdR0MtM m+rr8dEahpPtjE3OkcdqqsS4MelJehO+Fk2j2GBs9bR6m3zdTBfbpZmtmyl3Z53n7sru9nR7lzAL uIXyPNsyby+9Ul7vWp+93hvC1nywn1SaJuM0SUIgmaRCPpZdLKUkTkqp4yElYOskydBsoWlfM8X7 aN5vV2cRuzoR2lnSIXbSNVkkg91OSrLbldsCUsAXoLEjb/KbPseeIKT2Tb85oXYJuiDsqJJiJKoL u4bMPWRYkDFBZqIyskhXfQj++tkdp02LX519dNtNV87+3UL9xP5l71FsNJK7uOXCk/MZ//FZ+zsP v7F+5eWp8a8Ex7z56Iyd42tXNy1+ph37cTeqYR32Yw0cTG0zGDQxl8EWyzeEY/nV1Ya4tSRQHms2 NFjrAnWxmVSnptMwI7bEcH5sSfVqw6rYyvjaalf5mPox9Ngx2L9UoVxIFxbmN/t0JbQk+kRaFOVm nT7or1SHUiVLBkUlR3qh0ltk9zNF3jG4qGdc6pAR1GFye1JK+pK0cHOt6f0u0/vRqOxImPpjMdI/ /eqqpitpTpBTbCCR6CLisZ/xp8GAOjETsVQOiwjXPqXfENRQ5xFJkTw2u501Ftc217W8cOm6U5Ol Ge9fmNxWUFRYVli4oXnWhF0PFeVH59V2v9ZN+nTpPXWNzQ/+oHgd/VL0xxecf29yQt3Y4PGq5kh+ wZJpUxd7fY571q+pmOZyWetrjwfH5hUUb5m97pDTyJfhrDMZx+s+XPXpQYQTKT8rWsUcsVysF3tF TnCSlgtiI95LgdPqxCZKQ1YyWcSs0TBahuGT+lY9jTOmT6K1Aqv6L7JSPJj+NGUkyVhFrxO5Vo7C qfVkykAGHqUnSaizy0aK7FFLSVqKkjgfl0TvGSZa5mh1onJ+Y6JSbxenVouLnVWtGugyJ8pU/Sa6 YsQ9mhOxaPVAqboiojabBtijUeLrVTdFlcllfpli9715dKCSPn7wzcH5A49Tdw12UXe9zzSevoS+ faCH+IdHcAxuxL6JwE9SNXrexUf5Gj4u19hb+Hp5Ft+ev4Rfwwsej6uJTLLoCkL+5hDnpSW9D/tE b2zm9EpAafVQHrIgLiIt8NhJCzxG0nCPOv94rH5QPDpQI+BnBVKBr4DW3RIdGmVyggwytYH9sa9H WaxrgLjELup/Hl84pmS/zS+fHVbsxknjG5+7fM07U4zT/7xk4sbygsJ4rPyGOR13jWU2DIyLzvJf emDS1A7qj4seGzehpSzn1fKmvNLo6tbJS5SwzynQ6QcHV7JsfnnlA2d81W5NPwSgEm5IVXGiXUyE ykrKKptC40vqKrupmeJUZap/of/7JUYXk9/ksVgczR5GouPouFwFMXPQD2YdequPv3Zb6tgA9Q4D 6S+J9BHcmpASvgQd8+uIuyOJdbuqyEpI1SCqkPQP3mXiscwJ7BVcFifUngHSLWE6Xm6urMghfWAL km4B7dke0X6nN9s9+Ps/Xry/YWbXjK4Oyn5o7NR8ffbysX9Ig639rgu7d0zq6HyhMlnUWzPjusk0 PS5RdGFyxz3Uu+8Ovl1f10aZn3iWKv3B8vV68XHJPfjpe2XxYLzm8DVdawoVa17Enu+77eF4Qf4e HFu4C2RvwLHFQWuqVEfp6RyqkWqhO+hLUVYUUAoug8iGrFnD0LzE+/i1NMMATbMSWVCwZFWDQ9yc IGN9QE7E1FHev/koDnJcXKDPYm8YOO81+qXTfcxX7D+/MmoCD+J6ZU36L+ytmk8hC/KgkuIPQRgF K2Knhg6eCeScDQTPBgLk5qwiocJoua0sUJ5bXlZvGxeoz20om2qbnTXLPcvXHuiOdhZ0l7SXtVf2 8POM88zzsnqCPbmrjKvMaws2mT0c/cvwPTE6bNfHWMYz0UTHG3EgKGChLBaI6cV8P9jDyhkR/HTo nit+UR0X5KaLYqmf+0mVug8i9/7kkDKQ5LLY8n51vYLboK669o6Ut7PgygI6v6CUicfyYxXBhuDM 4ILgTWHOpQSZsIfsoNRtVFcnjhN1DlEHi7odipPNUM4ZL4azMDO8kbKreyl1yOSe3U2xtw6+evKf g29vv3z1Csr6+7co/WVrrr6+/+cbLrtj2vTQVePnT/JNWxXr/S92vjw+iirft86pvXrvdKc7naXT 2ZNOSEzSCYGEFCGQhIBhMYEEmiSSsESQsAoBjeMGOu7OdRn3Zbzq3FFEVNDckVEv4zI67rs44jKK go7DMAykq+85v6pqAjozvnvfP+/zhuo+nO6uOnXO7/yW72+pRLtWPnHVtQ+h238TZ449s+X5iYJ6 45r7/vDWL/qfqRZqt+O2s4Y3LmleXuiekNRwZWztwlXjk/OyTrtvYOv264msrY5/AriQytpFao3E pXCFXG1ubTgybkbujPCUcfO5bl/UPyd1EG3OdbjSy1s8hS0eId3QQBGXTIRNDoCMZYO0OXVoqFO5 OBQAKBjg6LeB66lwGdIFslUDhr8UtI4pWlgUuBNKx12tqyBKOgZEy50QrYRcEcXEXdXZtUA7tLty YY6SPjD5w+Oe6D29C/+tdX4nKn5nxa6p7QtfUMeXrqi/+t+r1JIVDaffMQ2xbMMz2tODa7ZYrESg kPzl+LKcyrqRCz9FGVOmzNWO33PzSGVJ/s67uzeWBL1FBd5CBqMuIjYtXBSiB7lqMurAvNDBSyJT IiCGrpTgTArsa2O1BswlZqGCGIYK3PIN+ceqKP343TR0hJm/oAH+BvZBGCuiZvJnCOgMgfoYqozK aECC41EpQyPIjAqjgljWgGtUcbDUcDqoZ8TfcHwRdxd9s/Y7YiN30NEDDMMvIjpAJNb32UfIkMS6 HgV8J5gdEYSP9qYLU0Usy4qEt5I7echFssJuJf6Yh+eFLcJaEbOVikrtpqJSzVmmqMqgwiqyIrBo iEe85LAiYsRZ3srkMDVMA9PFDBCPS2SYs63kJ4UP81X8TL6d7+c38yLfZyEWiABAsiAf1TLR2vqa GhrJoYuKEosa3bNnj/6fRLQOjRxGQ9lsiCXaJwkhftHr18a2XPs8zkDSFu24dgzdrvXyr45uxO/H cgk9nyNrD5O1e8lkKpBNdfNWrzXf2o47vMMpgttVXJlBoYaHMmxGhpheKbEllaKU7HUXOxLWwpEJ eHdX/Ds1ja7ZkUdxPf2W4l8x18uAU0BY/3PTznyx0zAw3wH4IJ1Pd9KL6E8q4GBmdcQRUSM4o9gj 2unlZA9GIa5FOu/p6kiUKCOJ1H7R4UjnAAxHOn+C4WjnMdjAFZXgU8G/WHnU/HCQAhT6j8iVrr3I 54OAVkyrTvhmLCBEBm4k31Jp0lURnEQ/8uEzms54/ubYt2j33XdNnzN9RdcND2qP5BSUXrL4a8RE zy4tzR+uaiq79EzteSRccG9kfCV6YdUD1Q3j+Vf9eeGtiwb+rUQKvoi5qum+VJs2Jykjozv2866B 3BRH7K3UnPw+iofWxj/jp/FfEzy0Su3gkU0WPMkoVfZ4c71V3imeBdJ8Zb59gXNBQQ/b6xnEGxyD nqTk5EClGxcV5VUKSjKzmsAbRBFOaXF98apiPtNr9VDKWtMoPa3LwrryIVSq1QOF5E0pkivoOCfn Bwz6Sea7uoKfVt3ZXHdVx13aX8/sWbHszG5ku2fjN9c6Nn932epHm6bObJ8y7cllVx1baV/hL/Il pS7o7Ua5T+9CWX29Sya0fLV0UcvM1s+uv3V/0/SmM88kMkr5dAfhUzuTzoyo2TXuFvdyvMzGJROG 9BGG3MAgh5dRgM0EQDC74vsToGYn6BvKHQbXEY8LuG1d0BEsDarEP+R8/3fYLOMEmx08wWVRU8Xp WltnKu6EhiZaT2efHQ9ft+T4S9o2tO49hDpvfOD3Q5vm773siSeuerNz1Sr8xxe1xxbUE16pr+7W nn3roW+nlucfv7CopukLyheERtythEYW5urH5QgjOAUsUOHNAfwuID6CWSWCJI6RkMSstTlsSJA9 CFaNzFWjxKoRrBqZq0bmqknnS1g17cCq0QrrKcJVG61NSNNq8N4BBMObu3U0zL45+ifWQd/8q9u1 ZdtjbxvzHybzl5mbd5C50ql76UQwFlFEYkWJYdssFH7tir+hBmD/+iwOC8I8Ak/of7SBfzA38Gtj A5UxSwmTtRwOl4Mno2sGiLHRZRD554ZjDrw1tmkv+zgf0hZuj1WQyYN8fsLfReQzh3lBnSgiWRDs 6UKSPWSP2FvQZPtse7/Qb1lsX2dfl+bIiqjZKDvbyjqdvkorTq9klQ0yynJmyc7QrrimJtGJh1Yw HHC20+DsIyZnf/o9zj5mqtHjajao0fV5jjw1Dwe8spteLYOIy1Z6lrwsVw80JRg1fDBcQdZZqvNr RamLfICYHRF9zpB7J0NZlwo9YAvGRb+oqgbreteQ9tHWB7V9S5YOojvRimEk3+QObqiZ+tCqY9qH qAwJPU81a6vx3LPHz+3p6UXZz6B+dGtdy1f+0wPBQu0p7ZD2kfZUXgZa+aDOD/xE4Of9O9iIRPkh GdYtOSUsSbxCEDovydhD8Oke04wc22mYmsM7DWJ9rvMAI5mkUnPgXDdQzAHkSgJSbSQiodpm2ViJ 9RAM8JqZYBk10ykGO/EwFG9yEW/yFXToeLQD7MR/TzLCJz4x9bX1tYTAq8N6ZJMyVQVpK/iJe2Mp e/fiP+7F78by+Vdju3AzocelBKy8CfToV7NlrlxgFbYcSbaVimTpUjwsj7uM6Bt46eyu+D7gE9bk E9LRYKI0P/0YROBWJuZ3uNwZI+/PIb4UK6eMHooQPBYJeSkmezO285ln8IxnnrmRu/PGG493k/kU x7/CBwA7rFY9A2gLwu4KLyuKlkpWTkpye0AFG7txzOTYQybHHjI59j2qi+l+wE5g2IlzfA4fEvqT qfedYE0avKUQ+KDucZ/iblP+wwe+eb7sjipL4cb6hSsDqQ7tvzBCFz77hsu6255RlF+wbgbbf5uh aTaQmfPM+scwyxGdCLhD5wJGdIgEzv2v9OIBQy8KY60BcZEgogvqkIYwN4zO2Yu/4F899pHB7UfI nKyoRV3QoaDxeDxfpazCPewqvkcZxoPsMD+oWNrlDqXLwvax69j1BEQqmJUFzGAOICen0qlxADyJ yuAauTM48k+0yCwiOlCxEB6hBQc2UKseJsOUFXWm7vXrfgnsEESHmAAM5YetsepCYnfYg/ZZdgJg QQogUsBzwO1JovP/XAMfMDXwIUMD28YQjUZcxn500VybLjYU6xI/c2clN8DhaCfp7ujjULST4GSq sNYw0TVEqIgXTnU1QiH+yF7tzA1a/25kR1eg81ESz47ewC4/FiNw+Bm2zrCg/HhqgVBYVa1iUKwU p4qzxV5xtShuEJADYSGIvEKl0CjMFc5CPcIwGhQsVsQJuAu1C9RQSQTmc5KAsEh9B2PRh81FH9OX mAT66VRFtV+dOkZR6eopD+gP2pruCKU/MXmqBWM4CwP1MYRMcRIH1OdM6nMJ6nNwMmdSnzOpz+n4 W4CfYGrcWPt3CvVjEOcx6U+JvGY1cbGIu6GTmCiu8X+JTdqNKvBFu/nKYzSZrHJ7CHpbG/+Yf4// lvEx2cyv1SyO4QjVLG4f4xNSrCnueWgeP1fstsy3zXd1J831Ob00P+Kni5FhSRvkTV6cWunFoUpZ 8ZP1wVz9XtZcKktdC0PF7TdV3LdqJei4tbmOXERDg/W5bAYwaobXAcbQAckJhwDuC/ziWKbnYGgS Jmr2wBgSdgP8luz26hDuZBSc5GR0W1hRzvAZC3oXdy48fuetWryrq7dn4XzE//yOeJM2+vEnWgxJ +/Yhkc/r0/bt2qV92Nu/ZNnixShz92MotPTMZctjvSgLTdT+S9unvU+chGpGR7/c9YQvnUyQ+UAt m+CpS2/1tKbPsp/h6HeIKZWM6BSxKMr+SoWVJUcoGMIubyZTRlziQYYby2NHVQtwlxnf+9a0m1+Y uOGA4X6tCjlC9SGcInpk0ISySWs5wVYysJVsspVsspVsDkc6n8FWySsyT7aDh42o8UETWkUPjnG5 ID48Njho4mPu+qmTZr52x9696GeXPNHcHn25qrps86Jn/33j9cSx4hyL7580c2aM2MiSspoHts5c kxNMjf0qXFo2YHgQNxo0PK7OlVA6KkETUE36VEezpzm9C3U4Oj2r0HLco/RbzkPrLS6MHiFnO8VA JQaNSluhXcUIY95fCeCDkloNsS4vwdI2St10ShFbGiWHDaTWBlFym81Jc7xAXaBzCitDOsPD8PZ/ hjIS4CIBN/5kgIsTRC0nWLU0HK2pKU2QtVanK/i4EJYcivn30GyRniVO+LRJp7ggN2pxza59uRfd uXVn8+wFd13ZW1IZ3jDry+cWXX5aSRjPim3nX80uqbj5nDvfrUZ3q4uz0n2xl0MlRSupBr2E+KaY YN8ywtBMqaHkSkxtN46ammtpzw+r9kGbDK0XoIsHXDhir4JMdqrkCRZKBf6cYE5pjVTlHJ8UCVYV TZemOluSpgan5zcWzcftqe3B9pKzUpak9geXhHtKNycPBgcz1xWtK7nEnS2rdme1RBtiIl2BAi5d CIVyKyEkR/zgUIE3AAogQHWFldI24PIyoYDMmOqESojqAFlZV+4oHyzH8sBpZuLJyAkYCQEdLvtq aOjTO981r2CZa2nBJteGgktdlxTc4LqpQKGBTrI3phiYSYMcimK4RBYq3wx9UoidcyLqmZzM49kt s968/k4tfrF9NSq4YNdLvYtbHzpz71Oo9s+3ErRkb9e+uub23/RsUr+ec+996P55D0xUm2snHl20 5LK1ixcFPAFP0Yt3P/lNbfGB5u6LlkUH0uwF3uIdRnE2dwgiYGvVFMRFBJaVHHJQbpNZZgHCgHc8 xEYcURUwGwvaeBokO6BagHclg3EP7DQ49rvvcWwcwmi8mSw6HNaLkAygqVctcIdiX++NfU1mEjr2 ER/aTme2g1iOQjKzdOZ3amq2O9tfx9bJM9gZ8jlJ5/ikNBvrJRuZ6gmO8QCOmrrugOoCewo4xYhp 0xhVOpyojLGpG4KOYDCoBlmHx7or/oG+LCukZ60JB8IK41ip90WHsprK0woRejKYVa8EIJ2zfjAK oCco62tPShiR3SZYcEx4lnzkC5tmz3z50stfaZrdtDeUX3zDwFnXl+SH9uKOu/40a8a06c1zvrif 3Ty6edPlNZMbJjfUXLeSvYzQyoxjCszl6pIm1EzUFMeLwjzhEoEVPISavMjN4y7hWM7DYlZCjZDo WIu2YIHh8XoWsSyWpjLTaf0kyxH3dYIRmxSYsyWHhMjLwobZCNvO9rObWYHtE2lskqwvSmSB7mZU hwV6WJI2EiRCQqiCRiJj+7Wjsf1voNfR6wTzlpL3fj6DzHshgdxXUOTLPK8+0MQuZTexrA1ZMMdh npesFh9KYf18ipRiKWQLpULLRFzDlnOVUq1coUywtOJGrlGaIU9RWi3tqItwZxc/T+yU25V+NID7 uQF+QO6n+JlbK22R1yhbLOOsHnJX0SPwhM8RC5hZhpZhGRkTdibKWcACocZEplJoZRqFIWa9IDBr CPCtt3fbh+2csNTmPETUAOQ4fTVRyMbTBCd5IYKJaPaHvMi6yUu8Qjv3I+232svvaRteRDWokph1 VE1pwL1xvJigpCLureMZ3H4yq0YDgVqYp9Ub1qMhESscrwQ4r1LMZSvV8kyuQZnPdnPz+XnyLGWe ZRm7klvGL5V7lKWWzdxaxWeha5M9kkh8WGKpeI8giDwnIsUiYInmsGxIwMk4D1fhJszLUopUKNVI zRKPJVHhKJK1MclMHlPFNDGzyM4vsUmykCIUCjVCs9AtCMIS4jFGy+mbYPHSUrL/OgmMzJf5IiSI yhiIALs/PqZh9Jk2oPW8g0WN/xRdg35OPNvMmAP3x27GX+AvY3fjKJn7eYQCEkSBOtUqVpQEKUnK k6qkaVKHtETaIEnSIxgTL5MlWoqgYBrPIusSRQ7LayEatFwBBU1YkiYkDZ8R8rTUBh6M+rfuIZ4t TQh4iVMgHd/AXjN6DTdndAm7fRe3fPsjx68ls/hG24j/KtDw/lQ1k5+DkTCHMD/DCFDIJoAqIL5A wHD89pmu4CHdWSzV0XNFaSK3YQS/8F9jR7Gk3Yu6tI3iLVf97QJyr1+Sez0C94qqMjdHRCy9F2hR m1468xhA2yBEfgyv4VvVpXt5oNbshso79jiwMcOj0tqKUhPEJ+ag50DwI7Gj5P73knlsvEo47yqK MJfFP+bSuY1k4yvQcrXTqnDZKYo3mwu7qUIrhrYE2k777IyFxcvtPemrSjYrQ57B9M3FCpYK6spc qgu7XJlSWxpKS/PXZ3KnTZYUJDnSUborPwIChs1gLDadItrREScOMOkWRoD1uROxG12FQ/GB4YxS pGTocqgxEsBXEnQ/1ivLghnUuSbiiAQj9RF2HDUK9FrAHzZ6yTiJXjIu1ULd4WrAHBA0sUj0PAsE ySwACSzgHViS6cAWcLQsYDosF4/JKBiu0ueJzzRpFwNgZkQP6/WqUQp0IXtHAQDxnCJGRF2v/cyp /sFKFNY1pnSUS38ypb2gdGjODa+t7F+CMu4pKSoYrJv+WK9S/Ur/hofU+oYnO75snN237pzF95zj qnP7gs/dPHxrSUmmlK6e4fc583OfcuTkl467doWWTpSQJ8nX297TO5PwwG7CA1cTPkxiMpFbLazE EcdEb1lmI57qaPWqmfPcS93D0uY0q10WfA0uzooyVEGxSB59K4V2j1kJ50kdWwn3rWmPD6sW2EC7 WVuwEzbLvJyhxSqFsHNXZwWz6rOwPVW26tFKcC8keroMUQg5YKVCB2aaOs4nG+hDpl0+olrAVAv0 SjDYYJ53xb95DAz2ttDJ3i3ZrYRrogsO2TgKo2tOstkijdPR3XHreWnRpdcsXN02pemBJd1XTrVu H2nbsWrvZ09fdN2c+5pnrW255WFcffkfZrS1leRVCp7YG5Pnaq9onz/3+6bxsfNz0l6iSGd5/I/s n7lzmBDzqDrDkd2WjcMoy16UnOOfgCL2CckRfwtqUxrtbcmT/Z2o3b4c9duH0Fp7ktPpqbdyoVCg npUd2RAHyoYCtISTt88k9D51HND3imwfcLUvVQZ+lyUgMEiADJBYBpIR/+0oUEq+OCuRywgbvbGp oSjkhgw842TGZIV0poWiPfbPi+7v3vRCc8ssVPLXnt0zlY7H592x+9F7ajaUFjZ7lWkl5U3NzR9c h9xofFX+q1Oa337lhXcz/N5SF+HNFYQ3pxi8idXc2kBZ2vjMtkBDWnPmfGGZMOiU3Qi7eP9kO4ek jAZecXn+jq6x6bomSzXY84iaDSoHQCzjHIMYi4B8iqF0DqkloGscerkf0PFanU+Nsk6oI0pNlfx0 JIlG78N0NAlGkyCqJsGZEhS6ScDJkkRHki4OnRR2GRsoBs4sL2dMVqwn5AbFkZ2FXWbFuM9VwbrG EJybMjJ7+9Lnvpo9tfHR3vnbWkdGZmxsum37tutn3bN+2umoErmu3Hf6jFm5+ejTY3H8k6zABy/8 9vdN1BIMxD/nergtjJ/4yc+p+Xlc2FbGTbTVZkzhWm2tGV22WckDth7fRttQhh3VBoOOtDovrZj+ Qq9Hs1jEegcR0hDo+xAwYgqlsg16ASYzkYJrBBpeFaJOdH2IDSIgDgJIjlLdQEY3kM0N/OkGsrnh dzemF7svTnjAhEi67FJNXKG7ZGHwgCFcHDqRmfQSymXqkRq311C2XM/o85OqKq/qWPPH05TuvSu1 A9pzKHx4/18eR9ddf8MjVpy69KbTysoWFL9UUIVKkJfwaIN29M9FP7trx0U6amPdQgah2W/VpQHg rACEDCRPjWc9T3ADV+9lLPZJkou3SQytWJAdsp3wnFU3NGBiQOQswBUWBCYm4HAxdtXmrLYnUx61 Z9KR7XCNPaHd7OPoneyUQ8Ea2t10HDvNABm1uXQs+6UpY3mqvLw8pndKjXxPfQXE/SHPS2yTIb1e PdeVHakgBoryGetWgn15m1aiudojI8PDe5+s7y/iF8lJZ12ed9voZPap23J/+6ZVohKrdXJTCB9l M2WoVC2pS5pUVF48oaxRbk2aUdRQ3Fq2AEX5ruQBtIIfSN7CD2a6snh3yFugZnCi6c3RjppKFyWK FpW1jZvsFR0CEkI55UBktyniblPEaUfVOSTACH6Q79k/Qr4D35ft8mB5fTkOA+uFYVfCqX7IwPmp bOfSkfygLP2wf36oafbDmbRP2otPG2tNaLnUD8ODg3pBb0K8c51M6OTsxqniXn2quGuadrjz/jnK uOf6es7Lzs5ov3kjkf5pk59Y2HthC7FHrT9Rb95x0U1zfjGsfaodSfHtcUfGFeaf3bikcQrxz8Sr X53R1JZfUDb6Fu7NSn9l78jT9YSvdxPG7SZaNxlVqEmsN9m73ss6bVJDEmdHyCb9oIY9CsYGm74w DkB20kCto6oLtoEbsw0UzxkdzUAIWSa+2wnbQjFaJZgwYGjDdb/GH/T3+LHzJBmSxshQwGZiBFui HN0GJ9tMjGAzvXkbRDPo3WwwhI2m9iFyR6NtEMjb5hubvYPNO0lNg+YJ07hbvQ7xQtmuEzWgJmRI 9nLdI25/yqLWmffNHBmZP7L40V/jLTO35hUVzpg4+msCDl5qmfPeS1QTP0RgwYX8+1D1dLeahBox IU81ZgXiFQ/LSL4WCFoMtOrhYGHGA2KgSTigAhdAUL+LeoYhZrPPTGoaBDGyOCZBeJMgvL4tkMuM 6+HGbVJiudFPdQp8GgYPuB4S44hoCZY+oHHhG29YR0Z4/zPHcrkoxTa/IXz0EOEjC3NMbSzA76D3 ZVZGDlsQpeOgrQSV2sosquUMy3I8hOiDJyhATpXkndiisIqEeYUXiQspWXCPMkhLesF8FABvMLZM +nCMxMI6WFg/y9GJGwXjgbGL3n/Koo+MzdtC53OdC3jOWPtf9cAV6QAX8Jdav88FNLFH0L2eGqk3 a5337Bn6i5/bQ4MCNAyyOpSNdDYg/jD30FFNHRoZwcGDsb+hL9dpPxU8owFcGhul9c6EZOfAcy3n qvkYIYnu3LWGtOiYDnjUSMgFhhFC5hpRYmORNZGmNJxUw14gWBqi0A4627gT2woL+tx4rgketjln ZARiR1QXiD6iz8PoObWVzWELk3KSChszG/MeLxIfy0W5wfQ0yddQkMWl88iZJqklKFhSVqKWzCoZ LOH//uRLqIr30QmXAFZAkPZBkpFzPQBeBKL77YL1lMFJacaSvgMFgag7HIbFACxAvc5cS5rxtBnc 0wH3dMA9HQEn0ILexwn3IZ9f0x1NZx492wk2wUl1GR3eaSo10jkO7EA6cTVEb+UMBuA2AbhNAG4T gNsEAmnmpqQlYohpcHKayXhp5u6kJax3mkKHSNOdXL2j2umd0nqDTtV5vpN1lkYPn8KBzpM/08j0 iVMMxUTjNLWEPWtj5fTBxegpCoq4ma5T9JVXNzW61hJ9Izavr2N2221tLKd3Z95MFdhDi9fcnr9m 5KxdD+EtzZcUhIvb6nx1GbEI3jL94oJwmCo1LrqlZU5Pe0/7R88xplUhnJSMCk+1Kvz/0Kr4xlgV PX1qmhDNDAv/ge7wKSaEZmwKgBtPGBMwI7pJ+fvGBLjyJCuiy1bCvPxvjck/syXeH2FLgOzElFBM /zG3mlDcwviIBg5MtFc6Kz0Tk1vtjc5GT2uy5KiXOW89q1jNnLXVJL2VBsyBZNbUFNWg6ajp0f9B lyLjIbdd8fdMe33I9DiPmK79MbVOd+1THCnBlPqUVSmcmwPoBhR3A5XdqUIyPGCiP2wC0EsA1C9Q cJBCR6dPzJEWsrX0N9Je7P8HFQMnwl9RNCZHm6gop+hptfbFVwe1L5Hv4FfI//QDN9x0/wM3Xv9L PE77RnsW1SIXOeq0Z7Rv3n399Xdfe/dtGivR+rirCUWpP5ql5pbjGm955hTc4m3I7HAvdZ8nbUlT zDgJn6EKssXqMWlKOkeAi404iUHMV06E9vSCJfepJbLfp+qRfxgwsf7YgEkio5GInBja6EdFTr4f OvkHsZME854aOzm9qeGRvnlXtIyMtD458MLHT1921ex7Wmetbbl1O67d9vHp02fnFWjF/N/W17dr v9e+fuG5aTWxrTmBN8DT6ANPg+6FqIYnsnWBsrQJmTPY1sC0tOmZNDbAYxfnV+0csmY08LLLo3v/ P1rT/NgYwTG1U48//tMYAZTbSgLEBNzfiwzY6SiS9I/iA6eYgFMDBCjb9c88hpF5/9H324NzGxt2 LO76aTNxEU7fOO3uBy69bs49Wh8OtLYQmGK/+sPWllkF+WWjT+GN2WkfPv3s602GBmfXEGjnZkZU D2NzEgxG8JeD6PUpioOXpbGV3t+qBUAdxqN6Bj3YKgLhRFiuCOwlAoeKAdnkUDkBYgx2NjmUlhro cW85h7KnrJhRKmBP0vmbHq7alvTDKI1yJTGAtK4RiPQ9Y8euUYraqubd1ToyMvjLztOKi9mrFXlm 3egfuegvulp5ka7+7Phn7NvcRqYCzVXnCVhO9eKU1Dy5KKdcrs1pkGfkLOKjyXNDHaVnlK/iVyT3 ZPaV9pd7hvhh17rMTQXrwpehbbaLA1sLfoZ+nmph7P5CLoM9P4uoEcoTWVl5k3QPWIVwHHF8J7Fy yE6ZK0yJUQiUKwSaFaZGQCf7IUrih5ItP5gc4qIeeRQ8UbvJ23aIwEJEIJUJ+UWwoGaqNFGMZNSH eAzdk1A5R02Vc1TNB76+0oiud0eGI7wIaluEILkYgO28pBLC4SeC4pAvD4cTWYlwIkhDGngSCOKI J1f2RSrzE0lxk5MTkUWfnhj3JbNvx97f8vtpSud7fVsuz8tbUfCTyHWbayaM/9VZfS81Ks0vL156 ZbhoUeVPwhc2NaGGm56dmP36lLZZHQ1ZWX7Zb8+/4eypQ2Wl1adlPx9paTt9anZ2stWvZLRMJ3s9 KX4Ax/jbmFRmh9pg5QN8mGctTnGSzaLwqam+elZuSx9Ox3bm8nTJ5gRudcIGOQFlO2GbnAFFEmkY R6QhWBeUyEEox5AFk73FBHuLaRD0gDFocblugkUfVMptSzs5kqPzd6nzSHlUT3ZVVOiPJeoh2QiN 3tB6Q2/oRJ65Asci5572yx3DwyPoIm2L5E+e2TauL1lR7O5dL+I5t6HJ2lO3aez8xeGC3FSZcv3D BEPMIzKfjFJVj0VIEYdEFvNemXc18AqSfjjceuQHlOkhNV1Xpt9Da9hQowdMGHFErRjj9tt1faoj tb/v9Utm2amUgN1GCNaks2TaVImSFgydBENIJlAjnb+AJpG2+k7J8pwUm9VJD6au1sBpEYPoY5L6 rgpu3kj3g8u3PzviDKR2zGn5VevIltZZb7+C34xd1L4pXFwwYyLbQGhcRyvgCY0F5gp1ch5XKFRx NcI0rkUQCvkaXuVn8z08LwTon14JsJgtYPLZ8Uw1O51pYtejISwZaXweSxjRMvk9ao7srLYyacwA M8RwzBU0jc+ySWw/u57l2DQonbtAJCIaJRYlqlf3jc3ikxdN5BqpbG5Yq/1Prf53qAsRTjh+Nxcd 3cpuIrPpYBgy1ShjZb7bzUiEuEYp3ncnqs3gYarD6laAwWw6W4yKcCGby+XxOVLYUokm8o2olZ+H 5nOd/DzLSnwm1ycNyH3KWZZN6Fy8hlsnbZbXKkOWDCtdvhgQeIGRnTKWzfS9IrQnMveEAPQR5lKB ZQKg4fKAga60O+319lV2lhEohgekaVb6CFAXC9BSf675QqMMtRw0mJHkPjnNT8xJGIXNVH8SIVGS UKV9+KD2sfbJr7T3nn0J+W5GGU9TUrHRUUqu29le+qbyVEv2+nxCMwvzsXq5bElFHtYjpsr5bL5Y y0xElWwlVylUihPlOmUG04oa2UauUWgUW+WZShdqZ7v4drFLbresQj3scr5HXCUvsWQ7MCPV4zKp DavSuXiQMHVAsShALAipsAGO5xDmicAI3BC3npKKI30kYBsiRLNwnAJsk0XYRiCTvII+JEIf1Vdt 3TZOwBziQNNzF9AwSLQcij/CtBJAf9w7+sOFAKFEHUAF4s4/SKD0b95HO7VZB9FEVPuB1oJ+pc3F JbhM60L3xt6j1KkjmI5Kgshcrk7moOJ2ltAjDAqCzIp8Cuvjp6EWdj4zD21iZSxSnuADHMu1MNM4 zLCY47EVL0MIYZblEkuikjAdZIFnrpAdMmK5JG4q18+tJ3S5QHJ+qq8HlsOYkRxDDvYYZR1JuiTE 1j3/ijbld2ge6uKix0T0Gpc/+ixbS+ceJejoEzJ3melQJ3ilCWxEms5OlRayZ0g90jA7KCmiyE4i TIqlSWOqF660BC31lm7LKsuwhccXQRXDpz9UxRA9Ub7AfjI6hH8au5BdGluDb/8pG7n1klHqY6Mh bSMugBhSKoG6fBu5GUIWJtgGj0ceTPzRHVcFLnjwQVqLoP8Vl1ruXPwBucqvWtEZmGF4+NNRuJSi J8Z8kJI7dzSN/RTX3qH/1aygcfQxV+gHGiDHr3EqOWbhIXwj3ok/YnvZp7klxIDeJ0SEt0SX+JV0 oXQ/HO/oh9yhlCkPWGott1gZ6z22Yts626u2V+2p9g8dlzoLnS86X3Sd5+5035tUm3SjJ8NzOzn2 e/3k6NKP5IW+VN8D/m7/31IuDPSn5qRemnppWmbaWelXZ7RkfBfclbk689vQ51lnZadnb8pJyrkr l8ltIEf0/4HjnH8d/zr+dfzr+Nfx//vBQL22MJ7YeFFgGIkpYpxMTvxl0hbH95O2JH4LaaviX5O2 Oj5A2hr4dQK0E+PbSVsHZzbCOZ3xd0jbBf0FcM5C+CZKWhfjiJ9HWme8h7QPx7cxOaT/Mmmr4kdI Ww3fjId+TfxZWjIMv86L06df58P3nfBNF7ljDhmZ9h8mbS4Z+WvSOhmFtC7oV5MRcpmHyTd5cJc8 ODOfnElbF7TV0E4g5+eTtRwhbR3pFzIO7Q3SuqBNJ+MUEprcQtpqJoO0jdBvJtcWMnNIW0zG30/a h0lbAjMpgTmUkKuOMKWw3lImj3xTyhRBW0LQTSlTDv3qeAdpa+LXknYCGbmUrJH2F0L7MLm2nIy5 n7QuaOmcy2G25TDbCphtBcy2AvaugsyQts3Q0hlGyBxuIS2lSYT8+g5pm+F7/df5ZJwIuePzpH2Y nFkFq6iCVVSRMWlbFT9A2k4yhyrY3ypy/n5CEYe2j7ROwhvVZA60nx4nbiS5ahtp88i9qsmqaVtO 7lVNxjlM2ur4E6RtjBOuYqbFyd6T+dB2enwcaedAvx3G6YjPIO186HdC2wXtQmijhHrVZM4DzHiY 83iY83igfA3MrQZ2vwbmVkPmtp20OYQONbCP/13dlUA1lTTrmxWQRWRRVJYIgqAYbgIIYRGRRUD2 AKMsakgCREISkwCiqBARUBHHZUAcBUTFcRAloqIwyOKuiCuKu47+jguoIC7oDLy+TcDoMO+fc957 /5xHTupWV1dXVdet/m534BAG8IvRUEjnQHl0fwOgWLU4QQtO0IITsIz9ETtmwQnm2QlacIIWnKAF JxDzSUDnQIrZcYJ2nIGFKkAtQFTOIBsYpUPqCXt9gL4zsIDROSCrzmAspi8H1BWMPQkoVj+usH5c YeW4grv/HvvPtsCCK7TgCi24gvy0A4p5d4XePUHe3gAaCfQ9gfwN4gUrygvmygtIPiPewEsHoFiF eINRHYgP4KWILzjbuACqASrWF65fX5gNXzA2F9AZUB4NLPtCX7OBrw5AMV+zgbwDCYS1FwgixPhQ SLEaC4aawVAzGGqGQEkIlIRASSiMMxTGGQp6uwCNgnw04Jmwlwl7mXAW4fB+hcO5hMM7Hg7ycxdQ bEbfAXk7oFi03wFJOzIXWPAHVBvyoyDvCXmf/leAhkKKaUYCzVpAMcuRQBPjPSGPWY6COYkClYzx s4D9KGDhGaB+kA+FPJafaGBnJqCYx2hgB+M9Ie8NfEXDsdHQezQcGw1jiEbCII9FEgNjiAH67wGd BakPWFMxUD8G6GN8GOSx2OSwVuUQz+UQz+UQz+UQz+UQz+UQaeUQz+WwruRwdnKI53K43uUQz+UQ z+UQzxGEiqcOfS8AHRn8YgYcOGfTFTwe8CsUPAFIkxQ8UUmHBKorR8GTleQq2CpR8GqIFlKi4DVx /kilgtdCJuN6sW+HIBKALw28GeRJgNfG20KeDOUekFeB8iDIq0J+PuTVgCUOXqjgcYgW/pqCxyNa hCQFT0A4BF8FT1TSISEGhGUKnqwkV0FShng1xJBQqeA18VsI5xS8FhJGZkF+hFL86lhs5MOQ11CS a2E8+RTktbHYyG2Q1wW8Dvkx5PWU9PXhHAf40UrysXDsO8iPh74GbBop6Zgo8RMxfRUC5KdCfhTG qyrFrKpkX0NJrqGIfy+FjtJQSgCPLRZKhHFSiodQLBKKWVKeUECluPP5lFBefIJUQgnlSrjiFC6H GsEVc1gCFoUnobAoUjGLw01iiRMpwjiKNIGrZCheLEwWYWK2MEnEEvC4EupQp9OgkVBufDKfJcba EuCRYk9FbSmWQ3pWASwpsJpK8WCJpVzxXGEyJYmVRkmWcIEzEECcUCClsCQUEVecxJNKuRxKbBoM wyvc3x30imFDJBZyktlSCk9ASU3gsROUxoIrT8DmJ3PAUKmQwuFJRHzggCXggFE8oMAGWlyBlEoZ 9C0U8NMoljwrCjcpFhv0xZRgUHnYiKA6hyeIp4i5EqmYx8YyrOQdDB+y5QwDsOQBL1JuEnY7xDzg lSNMFfCFLGWnIGbWQKRcMQVMVwhcAZosFSVLKRxuCo/NxXQSuHzRNxNKkEpFTjY2qamp1KTBdFPB rbKRpomE8WKWKCHNBnMhsQEPBiEiBhDBQviIAEkDrVgkDaeJcOE/ZX8O3l/6mYgUXAXg8cMCMg5h K0FOqCc0gPcxQi1hH7IXoQDwQBEaeFOQAISHsIGeEJGAdxwYS0E8oDURpCwg4QFOgFBBjzuwzwfX UCCLRxJAnwS2uODKBdopgHKAZgRscWAcLKDBg3oYJ4U2OaA/CcaXCGSYX6wnAUiHjygetpNBTIPa bHBNAm3MAw/6pw4z0ulPkWCxxgNLfOh9sF+imCMFbPOoIC+2gLMcxp4VkGEZGYg1FeYKsyOFVubC GClwZmngmgyzMjCzgQzEQS9SmAusLYLjkkCvFNrgAFksHDuYDS/wiPYHeR8YK1bqEcHIOMALG1rk wfhToS82oMP7HWhjumyQg2R4JzhQVwgoB/aLYHbSYJQC2Iv54ikssBW2uJBiVfHtvLF+PuQswSgr cMXuduyQp+GiEvzJ8t/P0RfrHGgpHsjEsCakMG72UA0PP/cB73+Oy1kpA9hMBuYihf4GVwdmf2Cu HCBJhTMXwgoffqYDeWZ9lVMuvK9CBR2Y1QCfDFoiSCkw2hQ4G+6QHUyTD1fFf3eHEmDmRKDabcAr Fb6oMKNfVzdVsapsAJ8GZxgP5ygCFtKAdHAWEkQZkTDM4Q21H0GE4n6FWNyvMAmiEtGYSCPOJs4i ugLKANosMDcsaxiSuQMNMZi1AI5CBr8MCgG70MXDfJvEgAbctSC4/v6Bb8QCOycEGY0ovimLcAT7 XZ7SPgwBp187cFLD8VlSARgL9gz+YT4UZHRoUAAFMQS++qFHJTo0zhGAyPDjjJVG4IauOATPF7L5 iBaketAOTmENj+2LFC1txdUC20cgRMJqwhrCWkIeaOGRXuQT6DLBUWBLFcER1kErUoU1hb0xcQgC PYCfMfNQ2ZhIstrkbJ/sD5o4FXypbMxsIJqFx+Fo6qgamTRFi4AfR0JQFnnEFDKOiJM54HHEUiYa glorSQzLjDMMwVEHewWBdYZVC3ZPsfqajr3QCUrGiHpnr9UumKquUtRXXPHw12e7ZqQXUF+XynRo qIy4AJUR/EsJ2H92GEGtGHU3uD96+4XGwdFGIBQRbQpqRSaEE9V1TT2EojQxtvWhWLKtKDQGw+Gb TRKVZowaDijrD7t9ok1ATbB+gq7Bl/5QoVBKcU+WJgjFPGkaajxGE3VAHengx5aG0iPHaNLooGkP hOAnEk2DuQJGyLr4cCZNFx2FNVR1R3zHkiSAzYQUuNFGtTChiq5KKJeTJBRwBgMb8VeBmaETBgIb p9zP4VKYvHgBtkUJ9nBHZThTVHPoBuJwJIQgw41EgHwEXobDITVpy27EVHsxfrLbR7vda27vm9r4 2aT4jNei11e8n13PO5HoHxrbU4Q/EdDuy7eZOJ3b0GpWo+5TsyL5nlf9z+u1gk+ZT+ku/U3TzOSK +8RPsUWXxnrt3uRnUnSx2sb0hN/UdOEtfWPnPIY24169VU+c81Qcvb9vkk/5YT4uZ9vn2oPsFbLe 6NLMrFX5Vd1HN++85FgevGrMpJzAeyg4fPec7nXNPJ7dyWfsodq9P0Q9MGJZ7IbFcdu2SDSzD3Sf fEs5FqSzjn3B+hbda+yrOr8C52CmQWtcSNrPlTlnI6aXyIJzBSS5fdPSifWhca5FgS1TltsKsmaR rxRf9svGC7KRXY05D5h47D8H78z8hGZ+QHVBOo3MiRroCLIqKF0SSYVAQDPLMCmOmLkVzSzM0I66 LHrNExebhSzXOxiQ339hh/g/X2+ykUgTstbFJXfUlenv2R0PZqAjsRh1cbh+IgklgAtqhAm0iKOJ ei1GrSmIKOpA1+2TgVtDPKk7PdlvUHWseySRCJZRttLSIWAVsbRi/3I/i+7WXwKlZXMmSScnV2f/ UeG/eTES8Pz8S4O7vFNaZelv8R6nz+e0fGS2NJfURwjfsD33eiKvCs5ubTM8ql4yVnPzzdvGlVbL XneWS/atv8/Id92y8BfHpKu5B8z+ePD8Bk9tQ2593yOkzu7th/RebR0q6aVVwaaZiZaLahzXP1TR PBeTcLE+wz0x7qe6mrp8u/PdBO30Je+uPpz5YGnfo0f7+t4/aNOsFt3Y+DjoiGNZ+tTrrnfs1GMd 8CWZC81Wv49mr6+KrGPcXJAXnjXO9p3zllKZRtn8tdXWNTt2X6i4TTnSgI5dRdHTnPxLaI/7w3no 442WvJwm0a9v91S0ZswUp2gBjFkCMCZWgTEs3KXpEAtHKq8jEsCZf3BVY4DDABjjQKfboXQGBjg0 1HaoiWau/D+JTRMWDihdYkBQcOigOuEv1P8t9tSjqz97iX9iJhavDkLMGo9fN3KVz53h+FayQWbx tEAHYd4ylGm5tBrV1X+Yua7w+u+O454c633ccY1FaCi9diM5INp7b+e8N1d/5UWNk7yoNlxHvGjl WcqZa2O8JUZwpsKAIeOe3PNLRXLu2Bc5hXoW1SssUnZdd2RkPa62aDPonfL86rnRkWETugvX5WRb 9fX4Wj9d+5HotuzixYKN2ZqLCL9e7tOYad9/86jbvXyvEcve35xdGfUmRWyUarZstf1Jw5iDwYTZ s5JU9oTnbiFnlGdWhgW2Z9741DCzkXY8XLOojemrg7781+7c9Hknl0Tq5agecuCVvqRPzFN92Xtd r/bh7xdf7NJXYM9HNPPd8NjzZRU7LiZJzo6n/zh/Y3b4gdW1p4vk0nx4+4xGYqseLGSVDIgbRmZE A3R0xvDL3hNTMCG6os4oo9Sh1D7bVnF+ZIv535wfRYk8TGqjOHVLbDyYoPCoQIT6DEaIwxFdUCfU cbCN4rOt//JACg1yxUqWpN8sKIg+loSVFbqaXX2jhDNT2j0qjp6e+Wki125/ctUiNL/gyMpP4id9 Fx1+cxJtCaFo1S46dK6n7cmaZ5YiSVvno+alr7oi7CIzZC+1b4oJL3QCO+5p5i31DNJgJf8h2KZy r3VKpIEmo2rBH7f7iT/jd7Z/yt9ZV9+0MMyZNv+JteBCV8Bkw27jlKXZB07n3JBP7tzXotX4pGTF s0vPssRhMgPB5LPFPxwaZ9wk3HQntrxpdmLluU7XjY8P2lQsSWXEL0SWyrYTtO+zf/C1mHn/B9Om HPXLejvn35XQxdOM+89anZoYGhTnc87IaO8pCwYvOHBPRzOZTxWP75pwO2miT0am/oz0khapo18Q QJ/tAH1WDaCP9kL1oqBGxLxi1B0vkzlL4su+xaB/Zq8zDYDPNJSG2tk5YNDDAM1/YK8TxkviSqSs JNHf3evcdRB8PnB2pt8ig7OtPtOZjZ8q9Gqt6XU6QaFnV3ZOt73lS9toeWQD56FJcFZt8+wrK0gf XycfX3vmp7b9PFHc4klxz47UvF517OKrn//Q2aU+19TK5tKMWxHE8SmHkzhJfmF37nXdbyhZeSbj wQp/vMPmd43FqhHGCbMu3mpMibZZdsSceCgiaqEhuz8j3eVVG9E8gJEqVYlpjm7PdrBOPqf1wpih lp7St50vWPKwY/r6wuJFWvMnBxnELqAXX10ZOMU0OsFr7X2bLO3gg72Hx63jvzL/UffjBe2bq7R6 ZCmSaad/WFLWsoDcQarKtq35uDkqyz1rzqrNgioTa58W4TaPhwufrbDITxzAGxnOEmRk4nCIo/r/ Y7ejTVZTnCz0cdgWBlECSuGzQLfCY3YVs7PX/7LtxT5nd4/Tl9GxQwP08EQN4xHgLJkMTiEeiPvX O6E/baOGAajNAaNozenBdaPyd7BUcFp5Iq91ryVh9W5qpKn9R0OYqww7GRtqdkao38874jz+yud9 e87VyEMmjBeq8pYnEspMvTv5h5LSTY96X8t6u27kcZU105peLn8uivEq2Xi1pfVefuOjhskX0zvO 7ae35Ry7wD457YrBhIaU+85bq8dLiifkth86pBOW17Otmeu31dJi24I1I53P6HIX+9RdqlzpFFQV O+c++vw5w+jx6u7bjMxe3Ql5nAw2mVjQvRXvYbPUO7e2H3+L2+t3/zZBuqmaJNBo2X7XkpXu0zVm 26gJjnjDnH3kUwX0o/+acZrpWr939f1ncQ7rekwLtrVUpYaFON0Qex40ew8A6mcAUBsHt0ekMhRu j1T/ue3Rn4AAwyhHsBuyB9BEo9ljGGU70KRhTTSz+j+xPZqEmg80jQUePBH2ia4n04vixQx0crT3 tJ1qi9p7TLWf6eFNM0fNBuZk+PWcpjKxSVGYXDH2CfC/hbc3xKkHCxrHZcabyy1iq3Vnt6K1jTqO v2dy7VROTjs4MeG9CrFRpbCnpmupcay1963Zu0Lsaq7xOyOdD63cMct1lCrVPtHrabNLHj4Ov9eA 99Kvc5L1K5fUqF3XRUWzv8vSvnxg6sfVRk9fWB367VIxOXaPOKzZ+fQlt6OPquZo8/+1++aJ5mSH +p5VjzKfWbaP7+re3yXbeeMmoaxEP+uz66eKR0foZ0vxnLdP+8dZLFJlrtHHd6+clOIrW7TndSV9 8emb/NFBptzC2ABvm36zA6s6ykX1hAu32+mkU1O+n3GkuM06m19zQZe+bN3p5fvH2NB/j6szqvIK /1j5aWr8ynirTVlXI3eYKW+nvgDCs8L3H17ndT3lPZ6bEPhhy5ol936kfrVTGhYx/ic7JalExGb9 r+yUBi1Jhwfrr/Z/5Mbh0ErTLXX+Bpfju+133SGRskwiul8XlZ9RXWdTfdFtUVt2eqrJvZdjDtan P+4t6h7h5VOpV8ez7p4eHxvW/WrFpFEbGR2tt3ICcz8smGW2dJL+DNWSBk0aUdZuf0RjG3Jt7c+L WacO57pvnz7t7pxdk350ul1PjtErPzjSvynfZW13bNHHuM62t4aWVfQ752lqv3w2TfD2/3RNYvqb Vb4p8jmigbw/s1S/1q7XMt/EL5a0Y/W7zFnPNTeo3pzjvN44UY23t9EnPVzmNh9x9NhGbnFrt2kI kqi5/lE7r+dMh0Mzh1UacN1V1BJVpZvZdH0nbVw950bB1SVuk6O8mWouFwm9bnORltVMFk1G/BEg ViEeh0Mzc/7BI9tXB8kvH3WVZp7Gnk6K26ZGoGkof44G/H5pqdO0UOVefYAaQwOJNFDqeO02055g DntNE5FyyPfSpXNaxtponNIQDdocNKLUOmPy3/+VzQ6LjIl/45dMlG+QiSjDIeWkDwRBeQLd+kyW U7nLx+dNM8IjH7w07z6pWt6+S37St4N0wWyJ/vhrJGLR+RX6RVo/5B6JXD5m057k0w+6JpzHmR5z eTKt+vABTnnta1sfdLnus3dZ271t0Rb79ZPnPR7RnXg2/NxPvJbrr6/sXrcktGFaX6juoxV1XukJ u+5mGDYgKxqmH0Bd91WEfr+uxCT+rSimKQ+5zNUOeLL9nk+FXo1JWcTewssnru8vWH3gTMg2hBka 2xd1fJz5jP0ftkThd9vPN5ZX0nNn8BLZ7rb3tJzX6Km+c4o9tr6vOOtTUVfqjs3vTqSf8W82Lz6b qtK1/9Fe+Xz2atb5Ze712+6U69x4kX005XHsDhneBJXhx3+5S2SaDK8BRKr/8XL89hH51YNbRVGO pTGogXItqn/54BcHfA71kGgjwRMVRR2xxyvd1t4u8k+luJEbvh8h4qKfGkRTw3fHvP+OMW7MN/iE lYip08I1ZosWdR72fC2dR9XhdlTun89BCinH2yvy7v5qk5W3YOvt0Ku58dOsA17t+ayDb+VteT6S PT/3RPh+/3fqk74315mX4NVWsqnH/5bN812HbyUVvsWtIrl1fe6+Mu/7joslu1ZxLzffNREQ3Byq WkfPyUgVTWCnmb49k+P/pnv+O2qd19miW9+LZnwmLH+8t+OV+8nelUz28kk7eH59l9/z197bN6ku e6d+iuToZu+ytWnLLPrsW310tnreWTC6MtJh1kMLlZBjLR6Je8fWPug4b8GXsDZv0I/zXLpMcsXB jOVetrPz/qHLH0Z9TDpSGrLVpd8g2I3+U0THOdOFW67VzWrzzdLo24kg/wWlSkcfDQplbmRzdHJl YW0NCmVuZG9iag0KMTM2IDAgb2JqDQpbIDBbIDEwMDBdICAzWyAzNTJdICA5WyA3MjddICAxMVsg NDU0IDQ1NF0gIDE0WyA4MTggMzY0IDQ1NCAzNjQgNDU0IDYzNiA2MzYgNjM2IDYzNiA2MzYgNjM2 IDYzNiA2MzYgNjM2IDYzNiA0NTRdICAzMlsgODE4XSAgMzZbIDY4NCA2ODYgNjk4IDc3MSA2MzIg NTc1IDc3NSA3NTEgNDIxIDQ1NV0gIDQ3WyA1NTcgODQzIDc0OCA3ODcgNjAzXSAgNTNbIDY5NSA2 ODQgNjE2IDczMiA2ODQgOTg5IDY4NV0gIDYxWyA2ODUgNDU0XSAgNjRbIDQ1NF0gIDY4WyA2MDEg NjIzIDUyMSA2MjMgNTk2IDM1MiA2MjMgNjMzIDI3NF0gIDc4WyA1OTIgMjc0IDk3MyA2MzMgNjA3 IDYyMyA2MjMgNDI3IDUyMSAzOTQgNjMzIDU5MiA4MTggNTkyIDU5MiA1MjVdICA5NVsgNDU0XSAg MTc3WyA2MzZdIF0gDQplbmRvYmoNCjEzNyAwIG9iag0KWyAzNTIgMCAwIDAgMCAwIDcyNyAwIDQ1 NCA0NTQgMCA4MTggMzY0IDQ1NCAzNjQgNDU0IDYzNiA2MzYgNjM2IDYzNiA2MzYgNjM2IDYzNiA2 MzYgNjM2IDYzNiA0NTQgMCAwIDgxOCAwIDAgMCA2ODQgNjg2IDY5OCA3NzEgNjMyIDU3NSA3NzUg NzUxIDQyMSA0NTUgMCA1NTcgODQzIDc0OCA3ODcgNjAzIDAgNjk1IDY4NCA2MTYgNzMyIDY4NCA5 ODkgNjg1IDAgNjg1IDQ1NCAwIDQ1NCAwIDAgMCA2MDEgNjIzIDUyMSA2MjMgNTk2IDM1MiA2MjMg NjMzIDI3NCAwIDU5MiAyNzQgOTczIDYzMyA2MDcgNjIzIDYyMyA0MjcgNTIxIDM5NCA2MzMgNTky IDgxOCA1OTIgNTkyIDUyNSAwIDQ1NF0gDQplbmRvYmoNCjEzOCAwIG9iag0KWyAyNTBdIA0KZW5k b2JqDQoxMzkgMCBvYmoNCjw8L1R5cGUvWFJlZi9TaXplIDEzOS9XWyAxIDQgMl0gL1Jvb3QgMSAw IFIvSW5mbyAyMiAwIFIvSURbPDA4NjFGOEUyQjUxRUY1NERBNDk2N0NGNDIyRjE4MDhDPjwwODYx RjhFMkI1MUVGNTREQTQ5NjdDRjQyMkYxODA4Qz5dIC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDMxNT4+DQpzdHJlYW0NCnicNdPHNkNhEMDxe6OLIEghokaJEl0QPZ3oUnVJROQNnGPHw3gAFraW 9raWNjyAVdzMn1nM73znfDNnFjOKokWxqGrZqCgl7uBVUN8Ew4/gzQq+d8F/LwRuhaBDCJmFsE2I 6uFFiD0KcRdE4FtIuIWkU0jRLK211mmz2JUryME1ZOHvS14ryCT+XyrooAzKoQIqoQqqoQZqQQ91 YIB6aIBGMEITNEMLmMAMFrBCK7SBDdrBDh3QCV3QDT1wA73ggD7ohwEYBCcMwTCMwCi4YAzGYQIm YQqmYQZmwQ1zMA8L4IFFWIJlWIFVWIN18IIP/BCAAgQhBGHYgE2IwBZsww7swh7swwEcQhRiEIcE JCEFR3AMJ3AKZ3AOF3AJachoC53/kEMo2IUnj/CcK6GavgTLg2D9VJRfhzM73A0KZW5kc3RyZWFt DQplbmRvYmoNCnhyZWYNCjAgMTQwDQowMDAwMDAwMDIzIDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAw MDAgbg0KMDAwMDAwMDEyNSAwMDAwMCBuDQowMDAwMDAwMTk1IDAwMDAwIG4NCjAwMDAwMDA0NTkg MDAwMDAgbg0KMDAwMDAwMzU3NyAwMDAwMCBuDQowMDAwMDE3MjUzIDAwMDAwIG4NCjAwMDAwMTc2 MjIgMDAwMDAgbg0KMDAwMDAxNzc5NiAwMDAwMCBuDQowMDAwMDE4MDQyIDAwMDAwIG4NCjAwMDAw MTgyMTIgMDAwMDAgbg0KMDAwMDAxODQ1NCAwMDAwMCBuDQowMDAwMDE4NzE1IDAwMDAwIG4NCjAw MDAwMjE3NzEgMDAwMDAgbg0KMDAwMDAyMTk0NiAwMDAwMCBuDQowMDAwMDIyMTg1IDAwMDAwIG4N CjAwMDAwMjIzMTggMDAwMDAgbg0KMDAwMDAyMjM0OCAwMDAwMCBuDQowMDAwMDIyNTA5IDAwMDAw IG4NCjAwMDAwMjI1ODMgMDAwMDAgbg0KMDAwMDAyMjgyNSAwMDAwMCBuDQowMDAwMDIzMDc2IDAw MDAwIG4NCjAwMDAwMjU0NjYgMDAwMDAgbg0KMDAwMDAwMDAyNCA2NTUzNSBmDQowMDAwMDAwMDI1 IDY1NTM1IGYNCjAwMDAwMDAwMjYgNjU1MzUgZg0KMDAwMDAwMDAyNyA2NTUzNSBmDQowMDAwMDAw MDI4IDY1NTM1IGYNCjAwMDAwMDAwMjkgNjU1MzUgZg0KMDAwMDAwMDAzMCA2NTUzNSBmDQowMDAw MDAwMDMxIDY1NTM1IGYNCjAwMDAwMDAwMzIgNjU1MzUgZg0KMDAwMDAwMDAzMyA2NTUzNSBmDQow MDAwMDAwMDM0IDY1NTM1IGYNCjAwMDAwMDAwMzUgNjU1MzUgZg0KMDAwMDAwMDAzNiA2NTUzNSBm DQowMDAwMDAwMDM3IDY1NTM1IGYNCjAwMDAwMDAwMzggNjU1MzUgZg0KMDAwMDAwMDAzOSA2NTUz NSBmDQowMDAwMDAwMDQwIDY1NTM1IGYNCjAwMDAwMDAwNDEgNjU1MzUgZg0KMDAwMDAwMDA0MiA2 NTUzNSBmDQowMDAwMDAwMDQzIDY1NTM1IGYNCjAwMDAwMDAwNDQgNjU1MzUgZg0KMDAwMDAwMDA0 NSA2NTUzNSBmDQowMDAwMDAwMDQ2IDY1NTM1IGYNCjAwMDAwMDAwNDcgNjU1MzUgZg0KMDAwMDAw MDA0OCA2NTUzNSBmDQowMDAwMDAwMDQ5IDY1NTM1IGYNCjAwMDAwMDAwNTAgNjU1MzUgZg0KMDAw MDAwMDA1MSA2NTUzNSBmDQowMDAwMDAwMDUyIDY1NTM1IGYNCjAwMDAwMDAwNTMgNjU1MzUgZg0K MDAwMDAwMDA1NCA2NTUzNSBmDQowMDAwMDAwMDU1IDY1NTM1IGYNCjAwMDAwMDAwNTYgNjU1MzUg Zg0KMDAwMDAwMDA1NyA2NTUzNSBmDQowMDAwMDAwMDU4IDY1NTM1IGYNCjAwMDAwMDAwNTkgNjU1 MzUgZg0KMDAwMDAwMDA2MCA2NTUzNSBmDQowMDAwMDAwMDYxIDY1NTM1IGYNCjAwMDAwMDAwNjIg NjU1MzUgZg0KMDAwMDAwMDA2MyA2NTUzNSBmDQowMDAwMDAwMDY0IDY1NTM1IGYNCjAwMDAwMDAw NjUgNjU1MzUgZg0KMDAwMDAwMDA2NiA2NTUzNSBmDQowMDAwMDAwMDY3IDY1NTM1IGYNCjAwMDAw MDAwNjggNjU1MzUgZg0KMDAwMDAwMDA2OSA2NTUzNSBmDQowMDAwMDAwMDcwIDY1NTM1IGYNCjAw MDAwMDAwNzEgNjU1MzUgZg0KMDAwMDAwMDA3MiA2NTUzNSBmDQowMDAwMDAwMDczIDY1NTM1IGYN CjAwMDAwMDAwNzQgNjU1MzUgZg0KMDAwMDAwMDA3NSA2NTUzNSBmDQowMDAwMDAwMDc2IDY1NTM1 IGYNCjAwMDAwMDAwNzcgNjU1MzUgZg0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDc5IDY1 NTM1IGYNCjAwMDAwMDAwODAgNjU1MzUgZg0KMDAwMDAwMDA4MSA2NTUzNSBmDQowMDAwMDAwMDgy IDY1NTM1IGYNCjAwMDAwMDAwODMgNjU1MzUgZg0KMDAwMDAwMDA4NCA2NTUzNSBmDQowMDAwMDAw MDg1IDY1NTM1IGYNCjAwMDAwMDAwODYgNjU1MzUgZg0KMDAwMDAwMDA4NyA2NTUzNSBmDQowMDAw MDAwMDg4IDY1NTM1IGYNCjAwMDAwMDAwODkgNjU1MzUgZg0KMDAwMDAwMDA5MCA2NTUzNSBmDQow MDAwMDAwMDkxIDY1NTM1IGYNCjAwMDAwMDAwOTIgNjU1MzUgZg0KMDAwMDAwMDA5MyA2NTUzNSBm DQowMDAwMDAwMDk0IDY1NTM1IGYNCjAwMDAwMDAwOTUgNjU1MzUgZg0KMDAwMDAwMDA5NiA2NTUz NSBmDQowMDAwMDAwMDk3IDY1NTM1IGYNCjAwMDAwMDAwOTggNjU1MzUgZg0KMDAwMDAwMDA5OSA2 NTUzNSBmDQowMDAwMDAwMTAwIDY1NTM1IGYNCjAwMDAwMDAxMDEgNjU1MzUgZg0KMDAwMDAwMDEw MiA2NTUzNSBmDQowMDAwMDAwMTAzIDY1NTM1IGYNCjAwMDAwMDAxMDQgNjU1MzUgZg0KMDAwMDAw MDEwNSA2NTUzNSBmDQowMDAwMDAwMTA2IDY1NTM1IGYNCjAwMDAwMDAxMDcgNjU1MzUgZg0KMDAw MDAwMDEwOCA2NTUzNSBmDQowMDAwMDAwMTA5IDY1NTM1IGYNCjAwMDAwMDAxMTAgNjU1MzUgZg0K MDAwMDAwMDExMSA2NTUzNSBmDQowMDAwMDAwMTEyIDY1NTM1IGYNCjAwMDAwMDAxMTMgNjU1MzUg Zg0KMDAwMDAwMDExNCA2NTUzNSBmDQowMDAwMDAwMTE1IDY1NTM1IGYNCjAwMDAwMDAxMTYgNjU1 MzUgZg0KMDAwMDAwMDExNyA2NTUzNSBmDQowMDAwMDAwMTE4IDY1NTM1IGYNCjAwMDAwMDAxMTkg NjU1MzUgZg0KMDAwMDAwMDEyMCA2NTUzNSBmDQowMDAwMDAwMTIxIDY1NTM1IGYNCjAwMDAwMDAx MjIgNjU1MzUgZg0KMDAwMDAwMDEyMyA2NTUzNSBmDQowMDAwMDAwMTI0IDY1NTM1IGYNCjAwMDAw MDAxMjUgNjU1MzUgZg0KMDAwMDAwMDEyNiA2NTUzNSBmDQowMDAwMDAwMTI3IDY1NTM1IGYNCjAw MDAwMDAxMjggNjU1MzUgZg0KMDAwMDAwMDEyOSA2NTUzNSBmDQowMDAwMDAwMTMwIDY1NTM1IGYN CjAwMDAwMDAxMzEgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDI3MTAzIDAwMDAw IG4NCjAwMDAwMjc0MjEgMDAwMDAgbg0KMDAwMDA0NjM5NSAwMDAwMCBuDQowMDAwMDQ2Njk1IDAw MDAwIG4NCjAwMDAwNzExNDggMDAwMDAgbg0KMDAwMDA3MTU1NyAwMDAwMCBuDQowMDAwMDcxOTEx IDAwMDAwIG4NCjAwMDAwNzE5MzkgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSAxNDAvUm9vdCAx IDAgUi9JbmZvIDIyIDAgUi9JRFs8MDg2MUY4RTJCNTFFRjU0REE0OTY3Q0Y0MjJGMTgwOEM+PDA4 NjFGOEUyQjUxRUY1NERBNDk2N0NGNDIyRjE4MDhDPl0gPj4NCnN0YXJ0eHJlZg0KNzI0NTcNCiUl RU9GDQp4cmVmDQowIDANCnRyYWlsZXINCjw8L1NpemUgMTQwL1Jvb3QgMSAwIFIvSW5mbyAyMiAw IFIvSURbPDA4NjFGOEUyQjUxRUY1NERBNDk2N0NGNDIyRjE4MDhDPjwwODYxRjhFMkI1MUVGNTRE QTQ5NjdDRjQyMkYxODA4Qz5dIC9QcmV2IDcyNDU3L1hSZWZTdG0gNzE5Mzk+Pg0Kc3RhcnR4cmVm DQo3NTQxNg0KJSVFT0Y= --001a113cd22a7a2050053710e70a Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --001a113cd22a7a2050053710e70a-- From nobody Mon Jul 11 15:25:05 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DEB12B02A; Mon, 11 Jul 2016 15:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl5AODtMLnIl; Mon, 11 Jul 2016 15:24:58 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9075F12D0AE; Mon, 11 Jul 2016 15:24:57 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 64E2F1FE02C8; Mon, 11 Jul 2016 15:24:57 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 11 Jul 2016 15:24:57 -0700 (PDT) Message-ID: <324122b57299b6f400483a0bf581b955.squirrel@www.trepanning.net> Date: Mon, 11 Jul 2016 15:24:57 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-calext-availability.all@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [secdir] secdir review of draft-ietf-calext-availability-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 22:24:59 -0000 Greetings, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies a way to use iCalendar to publish time periods of a person's availability and unavailability. For the record, I am not knowledgeable of namespace requirements on the components described in this draft so I'm just assuming that stuff is OK. I believe this draft is "Ready with issues". Those issues are: - the steps to calculate free-busy time (section 5) has a for loop that goes from the lowest priority entry to the highest priority entry. But the 2nd step says, "Determine if the 'VAVAILABILITY' is completely overridden by a higher priority component. If so ignore it." How can a higher priority component already hold that time if we're looping from lower priority to higher priority? This step seems superfluous or there's some assumption on the state of the calendar prior to the loop that I'm not getting. Please fix this or point me to the text that I missed. - I am very happy to see Privacy Considerations because that was the thing that jumped out at me when I started reading. But there are normative requirements in the Privacy Considerations and I feel those would be better placed in the appropriate sections of the draft that deal with that behavior. It is my feeling that Privacy Considerations (and Security Considerations) should consider the effects of the normative action described above them and not indicate additional normative requirements. Other than that, publish away! regards, Dan. From nobody Mon Jul 11 15:45:04 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CFA12D08D; Mon, 11 Jul 2016 15:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0ndM0D-6Ess; Mon, 11 Jul 2016 15:45:02 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B9712B020; Mon, 11 Jul 2016 15:45:01 -0700 (PDT) X-AuditID: 1209190f-06fff70000007bf7-e8-5784216b0650 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 15.0C.31735.B6124875; Mon, 11 Jul 2016 18:45:00 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u6BMiwCO022573; Mon, 11 Jul 2016 18:44:59 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u6BMitLr014200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2016 18:44:58 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u6BMitvX027666; Mon, 11 Jul 2016 18:44:55 -0400 (EDT) Date: Mon, 11 Jul 2016 18:44:55 -0400 (EDT) From: Benjamin Kaduk To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dnsop-maintain-ds.all@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUixCmqrZuj2BJu8Ga9rsWWvduZLGb8mchs 8WHhQxYHZo8lS34yBTBGcdmkpOZklqUW6dslcGXce32HseCPdcWs+w9YGxifGHQxcnJICJhI LFu8nb2LkYtDSKCNSWLa3LdQzkZGiV0dXSwQziEmie+fp7BBOA2MEu0/z7GB9LMIaEs83L2M EcRmE1CRmPlmI1hcRMBXYn7nRzBbWMBSYs702WA1vAIOEsu/fGAFsUUFdCRW75/CAhEXlDg5 8wmYzSygJbF8+jaWCYy8s5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRropebWaKX mlK6iREcTJL8OxjnNHgfYhTgYFTi4X1wujlciDWxrLgy9xCjJAeTkihvM3NLuBBfUn5KZUZi cUZ8UWlOavEhRgkOZiUR3l2yQDnelMTKqtSifJiUNAeLkjgvIwMDg5BAemJJanZqakFqEUxW hoNDSYL3lTxQo2BRanpqRVpmTglCmomDE2Q4D9DwhyA1vMUFibnFmekQ+VOMilLivPNBEgIg iYzSPLhecLTvZlJ9xSgO9Iowb68CUBUPMFHAdb8CGswENLjWoRlkcEkiQkqqgXHf/Q7+Z/Us t6Z6z1288G7+xIL7C0NbOcwkDC8+3bwof/9vplPTX11ZXbaFfUfZT/YTa8pirBRXtS9215Q6 4t/8etkkpeWv5+nb+jrFpCWvvnN4leTRb+cl92bu3cN6pK0i7/hqt39azB1X5DgMJJ0/3bj7 wNLB+9/3yie8Gi+NrjhU1J7c+O67EktxRqKhFnNRcSIAJm5qkdECAAA= Archived-At: Subject: [secdir] secdir review of draft-ietf-dnsop-maintain-ds-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 22:45:03 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I believe this document is ready with nits. This document also proposes to move RFC 7344 from Informational to Standards-Track, so I have also reviewed RFC 7344; I have some comments about RFC 7344, but I do not believe that they merit blocking the status change. RFC 7344 specifies the CDS and CDNSKEY DNS records that are used to automate DNSSEC key updates (as in double-DS key rollover) by communicating keying information from child zone to parent zone so the parent can include the updated DS records; this document extends those interfaces for use in removing DNSSEC from a child domain and, to some extent, the initial provisioning of DNSSEC for the child domain. The security considerations sections (of both documents) seem to accurately describe the potential issues with these interfaces, including the inherent loss of security in removing DNSSEC from a zone (but does describe scenarios in which it is the least-bad option). The treatment of using the CDS/CDNSKEY records for initial provisioning has a less complete protocol specified than the treatment of deletion, but still provides some benefit. In Section 3, first paragraph, it is unclear to me why the period that DNS answers for the child could be forged starts when the child publishes the CDS record -- DNS responses can always be forged in the absence of DNSSEC. The text in Section 3.1 seems to allow an authenticated trigger for the parent to poll, but does not indicate that the RRset retrieved by the parent should be presented in the UI for validation, leaving a potential window in which the CDS record could be forged and the wrong key used for the new DS record. Section 3.4 seems unuseful, or at least under-specified, to me -- if a requestor can create (or spoof) a CDS record and cause the parent to send a challenge, the attacker already has the capability to insert a record and could reply to the challenge. So, presumably the CDS record is not the trigger for the challenge, but the text could make it clear. (Also, what channel is used for the parent to instruct the requestor to insert the sigil record; presumably this is some authenticated UI which is also how the requestor is starting the enrollment process.) Section 4 (antepenultimate paragraph) makes the claim that this document does not define the DS Digest algorithm 0, but this document does make a normative requirement for when 0 should be used in a field that is specified to hold DS Digest algorithms, so I think it is reasonable to update the registry to note that fact. (While it probably does not make sense for any software to look at the digest algorithm before checking the security algorithm, is that really something we want to rule out?) Section 5 suggests that a parent zone could email a child zone contact address of pending changes; an automated system that sends email without rate-limiting controls runs the risk of being a DoS vector by filling the recipient's inbox. Maybe put a parenthetical "with rate limiting" as was done for the polling triggers in RFC 7344? Finally, there are a couple places where some mandatory action is contingent on "other acceptance tests" or similar underspecified application- or registrar-specific checks. This basically undermines the mandatory nature of the requirement due to the vagueness of additional checks, but I am not sure that any change is needed to the text of the document; I just wanted to mention the apparent disparity. Editorial notes appear after the comments on RFC 7344. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Additional comments on RFC 7344 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I doubt that these comments will be remembered by the time a 7344bis comes around, but will put them out there anyway. Section 3 (of RFC 7344) specifies that the absence of a CDS/CDNSKEY record in the child means that no changes are to be made to the DS records in the parent. An attacker that is able to prevent the parent zone's resolvers from seeing the CDS/CDNSKEY records would thus be able to prevent the DS update, a denial of service. One would hope that the DNSSEC-enabled parent zone would use a validating resolver when it queries the child zone, but it is probably worth mentioning explicitly, and the behavior in the error case when the query fails. It would have been nice if Section 4 had given a fuller description of what it means for the [CDS and CDNSKEY] RRsets to "match in content" when it restricts what the child can publish. Likewise, Section 4.1 could have given more detail as to whether only the parent SHOULD log the error, or if a child might be doing that validation and logging as well. In Section 6.1, where the delegation UI is being used to trigger CDS/CDNSKEY processing and key confirmation, it might be worth mentioning that that UI should be over a secure channel. (It should be anyway, but...) The security considerations text about "this mechanism SHOULD NOT be used to bypass intermediaries that might cache information" feels a bit like "hope and pray that nothing goes wrong", since it may not always be clear to all parties exactly what intermediates might be involved for any given child/parent. More concrete guidance about which parties must do what checking before enabling CDS/CDNSKEY service for which users could be useful. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Editorial notes for draft-ietf-dnsop-maintain-ds-03 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% In general, there are several places where the style and tone of the document are somewhat informal, which is a bit unexpected for me in a Standards-Track document, though not necessarily wrong. Things like Section 1.1, "The big issue", Section 2's "In many people's minds, [...] [t]his document argues [...]", Section 2's "In many people's minds, [...] this document argues[...]", etc.. The part in Section 1.1 where "[t]his document makes the assumption that there are reasonable policies that can be applied and will allow automation of trust introduction" might also be improved, perhaps as "This document shows that there are reasonable policies that allow for automation of trust introduction in some cases". In Section 1.2, could we get some additional punctuation around the list indices to help set them off from the associated text? There also seems to be strong overlap between some of them, like 1/3 and 1/4. (1) also doesn't seem quite grammatical; exactly what is the alternative to proper rollover? Should (4) say "the child zone" instead of just "the zone"? Section 1.3, first paragraph, last word, spell as "digest". Also Section 1.3, maybe reference Appendix A of RFC 7344 for the RRR background? In Section 2.1, is the semantics of publishing a CDS RRset interpreted to mean that, or *defined* to mean that? (Is the text in quotes actually a quotation from something else, or the newly-minted definition?) Still in Section 2.1, s/Reset/RRset/ In section 4, do we need list indices for CDS and CDNSKEY in the figure? The word "Users" is used only once in the document, in Section 5. Would it be better to use a more specific term ("domain owners", perhaps?) since "users" is a bit underspecified here? -Ben From nobody Mon Jul 11 16:45:03 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B45012D1A1 for ; Mon, 11 Jul 2016 16:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJyzwA3MycaW for ; Mon, 11 Jul 2016 16:45:01 -0700 (PDT) Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com [173.203.187.122]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9683B12D0E1 for ; Mon, 11 Jul 2016 16:45:00 -0700 (PDT) Received: from smtp8.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 834B3380239; Mon, 11 Jul 2016 19:44:55 -0400 (EDT) Received: from app20.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 798573800F6; Mon, 11 Jul 2016 19:44:55 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app20.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.5.4); Mon, 11 Jul 2016 19:44:55 -0400 Received: from hyperthought.com (localhost [127.0.0.1]) by app20.wa-webapps.iad3a (Postfix) with ESMTP id 6A24DE1801; Mon, 11 Jul 2016 19:44:55 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Mon, 11 Jul 2016 16:44:55 -0700 (PDT) Date: Mon, 11 Jul 2016 16:44:55 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-mmusic-mux-exclusive.all@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain X-Auth-ID: scott@hyperthought.com Message-ID: <1468280695.41981082@apps.rackspace.com> X-Mailer: webmail/12.5.1-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-mmusic-mux-exclusive-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 23:45:02 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A=0AMy apologies for being a few days late wit= h the review.=0A=0AFrom the document abstract: =0A=0A This document defin= es a new SDP media-level attribute, 'rtcp-mux-=0A only', that can be used= by an endpoint to indicate exclusive support=0A of RTP/RTCP multiplexing= . The document also updates RFC 5761, by=0A clarifying that an offerer c= an use a mechanism to indicate that it is=0A not able to send and receive= RTCP on separate ports.=0A=0AThe security considerations section says this= introduces no new security considerations in addition to those specified i= n [RFC3605] and [RFC5761]. (Actually, it says "in additions", so that shoul= d be corrected).=0A=0AI agree, I see no new issues.=0A=0A--Scott=0A=0A From nobody Tue Jul 12 02:31:35 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9EC12B026; Tue, 12 Jul 2016 02:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPdi-URvslug; Tue, 12 Jul 2016 02:31:33 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC45A128874; Tue, 12 Jul 2016 02:31:32 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-f8-5784b8f13c26 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 91.D6.18043.1F8B4875; Tue, 12 Jul 2016 11:31:29 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0294.000; Tue, 12 Jul 2016 11:31:29 +0200 From: Christer Holmberg To: "Steve.Hanna@infineon.com" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-holmberg-dispatch-rfc7315-updates.all@tools.ietf.org" Thread-Topic: secdir review for draft-holmberg-dispatch-rfc7315-updates-07 Thread-Index: AQHR1+8cuqB1sCfCAE+GA8aRMX4gMaAMMLswgAhxqwA= Date: Tue, 12 Jul 2016 09:31:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4656BEC50D7B8944B3CC2AC991E77F39@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2K7tO7HHS3hBpe/WlusfuxrMePPRGaL DwsfslhcmDaL3YHFY8mSn0wes3dNYvH4cvkzWwBzFJdNSmpOZllqkb5dAlfGh70N7AUNwhWz JjYwNzDO4O9i5OCQEDCRWHytsIuRE8gUk7hwbz1bFyMXh5DAEUaJU42f2SGcxYwSZ19vYQJp YBOwkOj+pw0SFxFoYJK43d3MDtItLOApMbV1AxuILSLgJXG/7TmUbSWxsusZE4jNIqAqsWv1 LhYQmxcovqf9GDOILSRQIXH/0i4wm1PAVeLiq14wmxHoou+n1oD1MguIS9x6Mp8J4lIBiSV7 zjND2KISLx//YwWxRQX0JL5/nQ0VV5T4+GofI0SvnsSNqVPYIGxriXu/t7FD2NoSyxa+Zoa4 R1Di5MwnLBMYxWchWTcLSfssJO2zkLTPQtK+gJF1FaNocWpxcW66kZFealFmcnFxfp5eXmrJ JkZgLB7c8ttqB+PB546HGAU4GJV4eBfcaw4XYk0sK67MPcQowcGsJMK7Zn1LuBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXFe/5eK4UIC6YklqdmpqQWpRTBZJg5OqQbGOe9S2m7EpKybM6GaNTfm 28YOeRs17o3WqyZocjy2LlqVfcI25Y90/P6q1GW7bP1O3M7zUGG8+2AuI/e+ZZfZdiVm8fGy L3XcW/iE5+7JP5N0ln5/3dXf3rHLzuaNXJ2ouDyrrZzwJN6Lfm4OnVXT1p7Pm+dVFePtN/2h 4fvDbMtu2U00PW2qxFKckWioxVxUnAgAiXfzYMECAAA= Archived-At: Subject: Re: [secdir] secdir review for draft-holmberg-dispatch-rfc7315-updates-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 09:31:35 -0000 Hi Steve, Thanks for your comments! Please see inline. >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > >This document updates RFC 7315 by changing restrictions on where >certain SIP private header extensions may be included, in order to >address new 3GPP use cases. > >This document is Ready with nits. > >I know little about SIP or 3GPP. I do know security, though. > >After reading this document and also reading the Security >Considerations section of RFC 7315, I believe that this document >is OK from a security standpoint. Few new security issues are >raised by this document and those that arise are properly >documented in the Security Considerations section of this >document. However, there are a few typos in the Security >Considerations section. > >* The second sentence of the Security Considerations section > ends with "the security considerations and assumptions (e.g. > regarding only sending information to trusted entities) also > to those messages." This clause is missing a verb. Maybe the > word "apply" should appear before "to those messages=B2. Also, > greater clarity could be achieved by changing "the security > considerations and assumptions" in that sentence fragment to > "the security considerations and assumptions described in > RFC 7315". I=B9ll fix as suggested: NEW: "This specification allows some header fields to be present in messages where they were previously not allowed, and the security considerations and assumptions described in [RFC7315] (e.g. regarding only sending information to trusted entities) also apply to those messages." > >* In the third sentence of the Security Considerations section, > "disallow" should be "disallows" and "message" should be > "messages". I=B9ll fix as suggested. >* In the fourth sentence of the Security Considerations section, > "if a header field occur" should be "if a header field occurs". I=B9ll fix as suggested. >With these minor changes, I think the document will be ready >to go from a security standpoint. Thanks! Regards, Christer From nobody Tue Jul 12 05:52:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A5412D82E; Tue, 12 Jul 2016 05:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2v7SaDmWIjE; Tue, 12 Jul 2016 05:52:37 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721D112D81A; Tue, 12 Jul 2016 05:52:34 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-b4-5784e7cd0972 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 96.22.03614.EC7E4875; Tue, 12 Jul 2016 14:51:26 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0294.000; Tue, 12 Jul 2016 08:52:33 -0400 From: Daniel Migault To: Dan Harkins , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-calext-availability.all@ietf.org" Thread-Topic: secdir review of draft-ietf-calext-availability-03 Thread-Index: AQHR28MRmJRM+fg80UybXqXIdH3KlqAUwOCQ Date: Tue, 12 Jul 2016 12:52:33 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117F29BFD@eusaamb107.ericsson.se> References: <324122b57299b6f400483a0bf581b955.squirrel@www.trepanning.net> In-Reply-To: <324122b57299b6f400483a0bf581b955.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXSPt+655y3hBs+eilgs/feFxeLw+j5G ixl/JjJbfFj4kMWBxWPJkp9MHs92v2QJYIrisklJzcksSy3St0vgyli19gBTwX7Bij2H9jM1 MN7j7WLk5JAQMJGY+fExK4QtJnHh3nq2LkYuDiGBo4wS7768ZgdJCAksZ5R4NNMfxGYTMJJo O9TPDlIkInCOUeLXvo1MIAlhAXuJ9Z+eMYPYIgIOElv/f2eCsI0kJq95AWRzcLAIqEo8/JYA EuYV8JV4c6GPBWK+l8TC7s9grZwC3hJ3DpwFizMCHfT91BqwMcwC4hK3nsxngjhUQGLJnvPM ELaoxMvH/6AeUJTY1z+dHaJeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRl FpKWBYwsqxg5SosLcnLTjQw3MQIj5JgEm+MOxr29nocYBTgYlXh4F9xrDhdiTSwrrsw9xCjB wawkwjsVGF9CvCmJlVWpRfnxRaU5qcWHGKU5WJTEefVfKoYLCaQnlqRmp6YWpBbBZJk4OKUa GLNdOZwiLE+4Rf+/UXk6RSiE/zT/laMVH/c/277Kbl7Z/x/XT8uXBOtOnCYweVKZeiDv7ke+ T/oENl5xCN7+f1b4ktfpEyuPKN8rfvTgM+9NwX0KPXsuZ7GvnNNxju/I3We7bjy9XM1bunf9 uXmrDE5JTDhkpBIWqqvssP3emv0ezSYcbVe/rN+uxFKckWioxVxUnAgAIrmzo4wCAAA= Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-calext-availability-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 12:52:39 -0000 Hi Dan,=20 Thanks for the review! BR,=20 Daniel -----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org]=20 Sent: Monday, July 11, 2016 6:25 PM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-calext-availability.all@ietf= .org Subject: secdir review of draft-ietf-calext-availability-03 Greetings, I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like = any other last call comments. This draft specifies a way to use iCalendar to publish time periods of a = person's availability and unavailability. For the record, I am not knowledg= eable of namespace requirements on the components described in this draft s= o I'm just assuming that stuff is OK. I believe this draft is "Ready with issues". Those issues are: - the steps to calculate free-busy time (section 5) has a for loop that goes from the lowest priority entry to the highest priority entry. But the 2nd step says, "Determine if the 'VAVAILABILITY' is completely overridden by a higher priority component. If so ignore it." How can a higher priority component already hold that time if we're looping from lower priority to higher priority? This step seems superfluous or there's some assumption on the state of the calendar prior to the loop that I'm not getting. Please fix this or point me to the text that I missed. - I am very happy to see Privacy Considerations because that was the thing that jumped out at me when I started reading. But there are normative requirements in the Privacy Considerations and I feel those would be better placed in the appropriate sections of the draft that deal with that behavior. It is my feeling that Privacy Considerations (and Security Considerations) should consider the effects of the normative action described above them and not indicate additional normative requirements. Other than that, publish away! regards, Dan. From nobody Tue Jul 12 08:19:53 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1319B12D848; Tue, 12 Jul 2016 08:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odXSPn1Q7jaW; Tue, 12 Jul 2016 08:19:48 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59FF12DD64; Tue, 12 Jul 2016 07:52:46 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u6CEqhVl025271 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Jul 2016 16:52:43 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.9) with ESMTP id u6CEqdoZ005399 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2016 14:52:42 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1468335163; bh=YqmI0wws/v1nekGBz/9KHTBo3t/OzQ63pXddbzBDY00=; h=To:From:Subject:Date; b=KFKz02dyj5ukWIksgFqkZ0HkvlQRLRllc6vA37ULTk/dD/gN5bskWgxO6hWHaBYgu wMnvmUZ6Mvje81LmTPTO1bHHdAhzlaIf+3SUe7Dxkr9HT/O//hRLXt+ZpJy/7f/bmt C/nBGwCV1q/aHhYs60KO7zw+R6xS+M9KrvhBB2sg= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.107] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 9.0.4 patch 1) with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Tue, 12 Jul 2016 16:52:37 +0200 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-trill-tree-selection.all@tools.ietf.org From: Leif Johansson Message-ID: <57850435.60605@sunet.se> Date: Tue, 12 Jul 2016 16:52:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09RhOQHFF - 601f9d891ff0 - 20160712 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: [secdir] secdir review of draft-ietf-trill-tree-selection-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:19:51 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is well outside my normal area of expertise. The claim in the Security Considerations section is that this document doesn't change the security properties of TRILL. This seems reasonable and I don't see any major issues with the document. Cheers Leif From nobody Tue Jul 12 11:57:21 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF8112B04E; Tue, 12 Jul 2016 11:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swtAmg8Afv-q; Tue, 12 Jul 2016 11:57:17 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE1A12B02B; Tue, 12 Jul 2016 11:57:17 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id s66so36425160oif.1; Tue, 12 Jul 2016 11:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5SpoKK27PpA92lLPRzAMOT3Ot0R8ZIq3RSg6dIy9Okc=; b=CGImH4/slvOdZ7Hv773x2EcD/OyRUyYOfuJuSltLUzeMztaMEIloOqYOfA+pGV/cZE o2UWIC6aNyY82brjT+iqkUhEx4NEEu5TkApmiMtg7K5d3sPT4xKKJmcRf+4X9xRMzJqe 3L24Y63SAXpt3XCR4c8U5OJkQ8AU0imU2ZsHO2opKgl3IZoWhk1eqHDuPHc7gUlLO3Vs WhqdBNE8PFI9O6nKiJxIRGPlUgIXOAf7fjMOPxbqQSqzpZsf9ZRzbKvc4HKB35PytaSu slXqvzbofCO/MI39Wg9CUDfxwnRM5zHWIJbzr5bzHixRYvzw4/K90Kh1L8FoCFQ1VCP9 +X7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5SpoKK27PpA92lLPRzAMOT3Ot0R8ZIq3RSg6dIy9Okc=; b=WmB8Yxm41y3JjgOzatQsZ/kmB6Wvmf9/JL0c6Tz70D2utNDx0r98T0HZyfdPuTFfNP 3lmuwnI3DxzmDUgv82LzbiRtKZm1pRL01eyJytABpzlSs5SU7NfMemkXecT4cFunt/Qr zu7/a+vATjK2SJaBeT//zDPl3SwAU1h1toVo8O2bo2uR1KoB2XQToJd2Xldc2yn0RdJG SSjcyAwMOgozE2PIiOMu8v6I27drV8kEhM8VmQA7FEO4Wiu7qmH5/5VPZ1zG2pdVOGGr ZII0WsxUkzghbuvGlU44PKKH0IMQ4bmaAxZTjlj4q0P6QYZp195Te1g+ES74BZscLty2 H4hw== X-Gm-Message-State: ALyK8tLMZ1UmgEzrf783P8j8Jt0a+KdCdebbIEECeUXPTcdN3Sjv9c45WHZ5j+Vaw6ebWYyGfPeupGmU6cRM9w== X-Received: by 10.202.205.65 with SMTP id d62mr8727712oig.114.1468349837064; Tue, 12 Jul 2016 11:57:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.40.40 with HTTP; Tue, 12 Jul 2016 11:57:02 -0700 (PDT) In-Reply-To: <57850435.60605@sunet.se> References: <57850435.60605@sunet.se> From: Donald Eastlake Date: Tue, 12 Jul 2016 14:57:02 -0400 Message-ID: To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-trill-tree-selection.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-trill-tree-selection-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 18:57:19 -0000 Hi Leif, Thanks for the review. Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Jul 12, 2016 at 10:52 AM, Leif Johansson wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document is well outside my normal area of expertise. The claim > in the Security Considerations section is that this document doesn't > change the security properties of TRILL. This seems reasonable and > I don't see any major issues with the document. > > Cheers Leif > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Thu Jul 14 04:59:28 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB61012B059 for ; Thu, 14 Jul 2016 04:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_hztjrEwlqR for ; Thu, 14 Jul 2016 04:59:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A87E12D5BC for ; Thu, 14 Jul 2016 04:59:23 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u6EBxJjL029065 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 14 Jul 2016 14:59:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6EBxJYS026225; Thu, 14 Jul 2016 14:59:19 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22407.32407.425980.65485@fireball.acr.fi> Date: Thu, 14 Jul 2016 14:59:19 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 11:59:26 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Matthew Miller is next in the rotation. For telechat 2016-08-04 Reviewer LC end Draft Tobias Gondrom T 2016-07-11 draft-sweet-rfc2910bis-08 Simon Josefsson T 2016-07-13 draft-ietf-6lo-ethertype-request-01 Warren Kumari T 2016-07-29 draft-sweet-rfc2911bis-09 David Mandelberg T 2016-08-01 draft-ietf-rtcweb-transports-14 Catherine Meadows T 2016-08-01 draft-ietf-xrblock-independent-burst-gap-discard-02 Yaron Sheffer TR2016-05-23 draft-ietf-dhc-topo-conf-09 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Jeffrey Hutzelman 2016-07-04 draft-ietf-sipcore-dns-dual-stack-07 Stephen Kent 2016-07-12 draft-ietf-nfsv4-scsi-layout-06 Ben Laurie 2016-08-04 draft-ietf-6man-multi-homed-host-07 Barry Leiba 2016-08-01 draft-ietf-clue-datachannel-13 Matt Lepinski 2016-08-04 draft-ietf-insipid-session-id-24 Chris Lonvick 2016-08-10 draft-ietf-mmusic-sdp-mux-attributes-13 Yaron Sheffer R2016-07-21 draft-ietf-trill-channel-tunnel-10 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-14 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-05 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 Liang Xia R2016-08-03 draft-ietf-netconf-restconf-15 -- kivinen@iki.fi From nobody Fri Jul 15 05:25:24 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A29812D1A9; Fri, 15 Jul 2016 05:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTcO-XlpQdg9; Fri, 15 Jul 2016 05:25:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF43D12D1A3; Fri, 15 Jul 2016 05:25:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSP90061; Fri, 15 Jul 2016 12:25:13 +0000 (GMT) Received: from SZXEMA415-HUB.china.huawei.com (10.82.72.33) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 15 Jul 2016 13:24:13 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.6]) by SZXEMA415-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0235.001; Fri, 15 Jul 2016 20:24:08 +0800 From: "Xialiang (Frank)" To: "'iesg@ietf.org'" , "'secdir@ietf.org'" , "draft-ietf-netconf-restconf.all@tools.ietf.org" Thread-Topic: Secdir (Re)review of draft-ietf-netconf-restconf-15: Thread-Index: AdHek8af5RdqrPV4TzG3jaIi8o9bKQ== Date: Fri, 15 Jul 2016 12:24:07 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.219.116] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AF8A1E0SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5788D62A.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.6, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: abc42f9bb1abdf37b86b2026999a80db Archived-At: Subject: [secdir] Secdir (Re)review of draft-ietf-netconf-restconf-15: X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 12:25:20 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12AF8A1E0SZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document describes an HTTP-based protocol that provides a programmatic= interface for accessing data defined in YANG, using the datastore concepts= defined in NETCONF. I have reviewed draft-ietf-netconf-restconf-09 as the Secdir before. My gen= eral thoughts about it is: Firstly, the document appears in reasonably good shape. Secondly, in general, the RESTCONF is an application protocol layered on th= e HTTP protocol. As mentioned in the document, just using the HTTPS (with T= LS) can address most of the security issues such as confidentiality, integr= ity, authentication, etc. In other words, RESTCONF is designed inherently b= ased on a good security base. Now, after several rounds of update, this draft has became better in the as= pect of security considerations. I don't see further security issues in add= ition to the description in the sections of "Transport Protocol Requirement= s" and "Security Considerations". In summary, I think this draft is Ready! Thanks! B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12AF8A1E0SZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

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

 

This document describes an HTTP= -based protocol that provides a programmatic interface for accessing data d= efined in YANG, using the datastore concepts defined in NETCONF.=

 

I have reviewed draft-ietf-netc= onf-restconf-09 as the Secdir before. My general thoughts about it is:=

 

Firstly, the document appears i= n reasonably good shape.

 

Secondly, in general, the RESTC= ONF is an application protocol layered on the HTTP protocol. As mentioned i= n the document, just using the HTTPS (with TLS) can address most of the sec= urity issues such as confidentiality, integrity, authentication, etc. In other words, RESTCONF is designed inher= ently based on a good security base.

 

 

Now, after several rounds of up= date, this draft has became better in the aspect of security considerations= . I don’t see further security issues in addition to the description = in the sections of “Transport Protocol Requirements” and “Security Considerations”.

 

In summary, I think this draft = is Ready!

 

Thanks!

 

B.R.

Frank

 

 

 

--_000_C02846B1344F344EB4FAA6FA7AF481F12AF8A1E0SZXEMA502MBSchi_-- From nobody Fri Jul 15 12:39:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAE312DD56; Fri, 15 Jul 2016 12:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJE3RSagaH9E; Fri, 15 Jul 2016 12:39:33 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5513712DD54; Fri, 15 Jul 2016 12:39:30 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id l125so110875210ywb.2; Fri, 15 Jul 2016 12:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=StMCrC/jylLi6kjuYEUvqBafKapoFyDUtxWFbkgOzoE=; b=yS4A3/k4KxpVq7L2PGgmhJWTKekmBCX7yFwYxqCRcW5ofL7p0jpvrHVjqOsxWe5RW2 mzh6PafNWMeTEf15+xDsx5mIQ/6AnaHWDiYorV+O6avkXuv/qbrd+Oud6EjiyTCk0Hyw eiy85sbW9d+aW6J2zV2O3+brwdDoGtzpSUUJzApwKOS7neIYMG9prwe5+idUob/Jd9Qm 99Y/WE/RszN05z2IYttG3bRO84nQrgBC+VmQWdn1CZ56mXfWd05u61GQZQPqCo+glPt0 R+jOSx2MZN2JxlkGZmBtN8KHDlYsFyCmsdPDxh5V9vJ4n9QxnQR0fPv5tUSiB4rb7Lse eIRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=StMCrC/jylLi6kjuYEUvqBafKapoFyDUtxWFbkgOzoE=; b=g1KMOkMnJaMKQ29wjaJUNox3N7CjD/HnCrMzOMIqgQ5+bxsQ9gaemKB0XlkwtSUY9K 0lDKB/5ZTtncaGP/B4pEWxcuQ16h/xhoEPkRXQhYbUivZtTB3d/uLTperNFmiRKqrFnZ 8DOCRWrRXzuTDC6tpmamVIHjjGqgyA8221l1JmxhtjtEtXeZXg47hvJxW4WsF0OKu2zI ZZfJvw/XE+6c6aOJsGwpVf2vZ0sUQ0REW975FrRuvOUYeiFjuV8PMi5n3o2p9SejgvYr 0g1jtlDgs9+d6a7g46XzeKelFt+PX3haiDUNAhfoPmNdaHovTl4wUiXeQY680uzhcJHf B9og== X-Gm-Message-State: ALyK8tLsqwpYYAJ8P1xhRcEvN0KLnLh9Gy2M6SfJgc/9UCck3hpMxoa82r8ih/te4gno9Chrc9T5jN3IMOhfPw== X-Received: by 10.37.52.87 with SMTP id b84mr15452469yba.60.1468611569239; Fri, 15 Jul 2016 12:39:29 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.83.33.137 with HTTP; Fri, 15 Jul 2016 12:39:28 -0700 (PDT) From: Barry Leiba Date: Fri, 15 Jul 2016 15:39:28 -0400 X-Google-Sender-Auth: PYTlumXe4suEztmsrDvh8cYlVRQ Message-ID: To: draft-ietf-clue-datachannel.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: clue@ietf.org, ietf@ietf.org, secdir@ietf.org Subject: [secdir] Security Directorate review of draft-ietf-clue-datachannel-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:39:35 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready for publication. It's well written, and, while I have a few minor comments, they are only of the most minor sort. -- Section 3.1 -- As described in [I-D.ietf-rtcweb-data-channel], the SCTP streams realizing a WebRTC data channel must be associated with the same SCTP association. In addition, both SCTP streams realizing the WebRTC data channel must use the same SCTP stream identifier value. These rules also apply to a CLUE data channel. I don't know that it matters a lot, but this seems to be an odd way of saying that because a CLUE data channel is a WebRTC data channel, a CLUE data channel behaves like and has the same rules as a WebRTC data channel. I think I might word it more straightforwardly that way, something like this: NEW Because a CLUE data channel is a special case of a WebRTC data channel [I-D.ietf-rtcweb-data-channel], a CLUE data channel behaves like a WebRTC data channel and abides by the same rules. In particular, the SCTP streams realizing a WebRTC data channel must be associated with the same SCTP association, and both SCTP streams realizing the WebRTC data channel must use the same SCTP stream identifier value. END Worded that way, it also supports the many other times in the document that you point out things that rtcweb-data-channel says that affect CLUE data channel behaviour. But, as I said, I don't know that it matters a lot, so... just a suggestion. -- Section 3.2.3 -- I think I'd move (or copy) the citation of [I-D.ietf-clue-protocol] to Section 1, where "CLUE protocol" is first mentioned. -- Section 3.3.1.1 -- CLUE entities SHOULD NOT transport the SCTPoDTLS association used to realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP" proto value), unless it is known that UDP/DTLS/SCTP will not work Are there other reasons to transport over TCP other than "knowing that UDP/DTLS/SCTP will not work"? If so, OK. If not, then I think you really mean "MUST NOT ... unless ...." -- References -- I don't think RFC 3264 is normative. -- Barry From nobody Sun Jul 17 14:54:21 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D71712D135 for ; Sun, 17 Jul 2016 14:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0DXhzumpjlk for ; Sun, 17 Jul 2016 14:54:16 -0700 (PDT) Received: from nm10-vm1.access.bullet.mail.bf1.yahoo.com (nm10-vm1.access.bullet.mail.bf1.yahoo.com [216.109.114.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABDFA12D137 for ; Sun, 17 Jul 2016 14:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1468792453; bh=vQPJYxDu5FaZH2H0m+SVKftqbD0VGkiWIc8hw3gwfsA=; h=From:Subject:To:Date:From:Subject; b=fbb2bTke3LUuJ5r0wjsuNvGzxc5OskDj3b1IJsEvYIRBopie9pBv6DRE0poet+/UYfSXQqe0C77PdTcfk4XcGG2c82/ZCpeTycYF4DF0o+3bM2JY0BgaOBCFcWgw/G01PMkIcw7Z+YwnQYA+Xq1w6iJFbt8k0Jykl2wFgXmdh+221e8T8tRtKYVZ3LjDOLiVHdt+5qGmNRxd6hED/fNiXJ4y8Q6G7CrUTivLErRPob7M+YU9KqF+oKGDVTzMidancnGGQ8/58O78pj3ZIkb73LuVo+4rNW+lLQI8ptnhlgjYuhVbcfwAtb6ojseSMIMxj5MczeDfV1jA6FjCOIXgNA== Received: from [66.196.81.166] by nm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Jul 2016 21:54:13 -0000 Received: from [98.138.226.244] by tm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Jul 2016 21:54:13 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 17 Jul 2016 21:54:13 -0000 X-Yahoo-Newman-Id: 473317.31496.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: O7XgePEVM1mxUgO7u3UDd8qTT.gSYN2TQpVSV4m9hKqApCA W6q9PWY8E8X0tsv782ol6L0_n4_ZSioszcVkY7NEFCO1m2dbWaUlC14epb_M xLGdLtPotpH_Vwr6JEeXRAv3RCY8m7HMADgDLljXlC8pnyM.adCnTxNh1ugq HOqJOhXeJSjuC0dhZk_kUyOn44NAOxJHwwSBoIHusSrDMSBF2.Znd1BeNeaq 5EZG6HYhTDKl0okIcyS.v.YEu_uXXiZ_dLoBT4Tt8kJzRLcNCYNgEFAJgJ5F HwVgSXwNUzvi0AfG_ud0wXJHW2YVU6CY9QqmxiwswffTt0yzxHYlODtVMRw_ 8ve5wES52B4Uk7QZNyd2BjFoQ42d7ebcqA362r.Vd5JPCaIRrGPmfbKKrA5z oob7dmwQSjMYqiGecRTG1GnOKiNAn_1rqvXXMiNjRcWd9dulwCtO20des4AV S5XVPhl1Gn1zSeC8oxhRuIJyR32HHJBfgvBYE4cHy.COhUZS9aD1p.dAeBf1 ghogf4KKme1L2T7.syoFAvKO8P33D.dHpIQJd9ZE_2KEgfMXVNBVqplRXrkc 1E.cYg3vo4bHOMvaeIHUn8MH0WQ-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.153] (209-6-88-55.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.88.55]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 925EA1C6035; Sun, 17 Jul 2016 17:54:11 -0400 (EDT) From: David Mandelberg To: iesg@ietf.org, secdir@ietf.org, draft-ietf-rtcweb-transports.all@ietf.org Message-ID: <578BFE7E.7050202@mandelberg.org> Date: Sun, 17 Jul 2016 17:54:06 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v3flw0h5wgE8ITRD2jbJfbs16Hpn0COTV" Archived-At: Subject: [secdir] secdir review of draft-ietf-rtcweb-transports-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 21:54:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --v3flw0h5wgE8ITRD2jbJfbs16Hpn0COTV Content-Type: multipart/mixed; boundary="SpmbDfqXalXrweRLIGREVf3ne3Iq7PWaS" From: David Mandelberg To: iesg@ietf.org, secdir@ietf.org, draft-ietf-rtcweb-transports.all@ietf.org Message-ID: <578BFE7E.7050202@mandelberg.org> Subject: secdir review of draft-ietf-rtcweb-transports-14 --SpmbDfqXalXrweRLIGREVf3ne3Iq7PWaS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I think this draft is ready. This draft does not define any new protocols, but rather references many existing protocols. I did not notice any places where it chooses a protocol that does not provide adequate security. As far as I can tell, it addresses all of the parts of draft-ietf-rtcweb-security-08 that it should address, primarily sections 4.2 and 4.3. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --SpmbDfqXalXrweRLIGREVf3ne3Iq7PWaS-- --v3flw0h5wgE8ITRD2jbJfbs16Hpn0COTV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAleL/n8ACgkQRKlmUHCg4sDDKgCeNHK0reaOZ19f4wHmlkrKoj7p ldUAmwVH7YhoPfLFkYfBGxPG2uRE9ezJ =ISkd -----END PGP SIGNATURE----- --v3flw0h5wgE8ITRD2jbJfbs16Hpn0COTV-- From nobody Sun Jul 17 20:46:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CE412D0C9; Sun, 17 Jul 2016 20:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na62W4Csf1fv; Sun, 17 Jul 2016 20:46:35 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC55112D0FC; Sun, 17 Jul 2016 20:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24556; q=dns/txt; s=iport; t=1468813595; x=1470023195; h=from:to:subject:date:message-id:mime-version; bh=BdsQdSy4FWx+la9jeXxG653jk4qx/jdiJWSbHuDMyCc=; b=Nb8gUO93x7Mx1ZEtNcHpxQ+WyJutdZabN/9N5fRaL7KpCVBHfmq5lYx/ TlBWB/emSBcivoJaFw3+q80mejtj4rDp02AfCGpuYLCRZFn0fVcj9o8el oRVretBDKa6m0XFBChus6X+PMk5zvVhYtU9G+R3hByM4aLCU/lzXX4NLj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgAYUIxX/5tdJa1SAQmCcU6BWLh0g?= =?us-ascii?q?XmHQzgUAQEBAQEBAWUnhGMMZhkBBjpAJwQBEIgylBaqfQEBAQcBAQEBI48PARG?= =?us-ascii?q?FcQWIJZB/AYE0jSqPN5AdAR42g3M/hicrGH8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,382,1464652800"; d="scan'208,217";a="298901087" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2016 03:46:34 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6I3kYt8025497 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jul 2016 03:46:34 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 17 Jul 2016 23:46:33 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Sun, 17 Jul 2016 23:46:33 -0400 From: "Nancy Cam-Winget (ncamwing)" To: "anima@ietf.org" , "secdir@ietf.org" Thread-Topic: Initial review of draft-ietf-anima-bootstrapping-keyinfra-03 Thread-Index: AQHR4Kb6hoXgv1OH80i6Ph02ZsBt5Q== Date: Mon, 18 Jul 2016 03:46:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.1.202] Content-Type: multipart/alternative; boundary="_000_D3B19F2517FA5Fncamwingciscocom_" MIME-Version: 1.0 Archived-At: Subject: [secdir] Initial review of draft-ietf-anima-bootstrapping-keyinfra-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 03:46:38 -0000 --_000_D3B19F2517FA5Fncamwingciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As the Security Advisor for Anima, I have reviewed draft-ietf-anima-bootstr= apping-keyinfra-03 and have the following comments: General =97=97=97=97=97 Device is used inconsistently, but I believe in general device in this draf= t is the =93target=94 or =93new device=94 that is being bootstrapped, corr= ect? Introduction =97=97=97=97=97 In the paragraph beginning with =93A precise answer to these questions=85.= =94 (at end of page 3) I believe =93devices from a variety of vendors=94 includes all network devi= ces as well as any generic device coming into the network and require boots= trap, but its not clear? Not clear what =93and a network infrastructure (the domain) that is operat= ed by parties that do not have any priviledged relationship with the device vendors=94=85..who are the device vendors? I think it is the =93n= ew device=94 manfufacturer or vendor? Terminology =97=97=97=97=97=97 I am presuming domain =3D internet domain? Typo: =93Imprint=94 definition =93key material to identity=94 should be = =93key material to identify=94 Pledge definition: I think all references to =93device=94 is the device nee= ding to be bootstrapped? Audit Token: it would be good to describe the =93manufacturer authorized si= gning authority=94 (e.g. MASA) as I believe the MASA is in general the vend= or=92s manufacturer but in general, the MASA is some authority that s the o= ne that can authorize the prospective devices to a particular domain (e.g. = the domain of interest). Thus the =93it=94 in the =93=85that it authorizes= bootstrap=94 is the MASA where the domain has assigned as the trusted auth= ority. Section 1.2 =97=97=97=97=97=97=97 Figure 1: New Entity =3D New Device (these two terms seems to be used inter= mittently, my nit would be to pick one for consistency) MASA service: doesn=92t the MASA also holds an authoritative view of what n= ew devices can join the specific domain? Ownership Tracker: in the Figure they are shown as part of the =93Vendor Se= rvice=94 and =93MASA=94, are they abstractly all the same component but can= physically be separate entities? As it is understood there could be devic= es that come from multiple vendors, there can be many instances of the =93V= endor Service=94=85.but could also imply that within a =93Vendor Service=94= there can be a decoupling of the MASA and Ownership Tracker? Section 3.1 =97=97=97=97-=97 =93A New Entity MUST NOT automatically initiate bootstrapping=85.=94 how c= an this be enforced? There should be some description of implications in t= he Security Considerations section (e.g. there may be instances in which a = New Entity may need to go to a =93factory default=94 state and be re-bootst= rapped?) Figure 2: =93Optional=94 can occur in advance=94 =85.not clear what steps = can be created in advance and how far in advance. As the New Entity reques= ts to join, it=92s ID is not known to the Registrar, at least until the TLS= connection is established=85.also, the Nonce is listed as optional, but SH= OULD or MUST be required to map it to provided Join Request (e.g. it should= be part of the same sequence). Clarity somewhere in the document should be provided as to the operionality= of which entity does the Authorization for the New Entity to be bootstrapp= ed (e.g. is it the MASA or the Domain Registrar)=85.at this point it is not= clear Figure 3: Should the box be =93Identify=94 vs =93Identity=94? Step 2: =93Identify itself=94 : what is meant by =93Although the Registrar = is also authenticated these credentials are only provisionally accepted at this time=94? I thin= k the Registrar is provisionally accepting the 802.1AR to protect the TLS c= hannel, is that the point of this sentence? But I also believe the New Dev= ice must provisionally accept the Registrar=92s cert (also indicated in Fig= ure 2)? Step 3: =93Request to Join=94 maps to =93Request Audit Token=94 in Figure 2= ? Step 4: =93This requires verification of=85=94: the New Entity does the ve= rification? How does it do that? There is not enough details in here to de= scribe how it actually does this. Perhaps these steps should be prefaces as= =93Summary=94 or =93Brief/Abbreviated=94 state descriptions=85. Step 5: this reads a bit awkward=85.I think the point of this step is that = it now has enough information, for instance, knowing the domain registrar= =92s certificate to be able to initiate certificate enrollment; and can do = such enrollment using RFC 7030. Correct? Step 6: a nit: membership is based on the successful certificate enrollment= of the new entity=85correct? This is correctly shown in Figure 3 :-) Section 3.1.1 =97=97=97=97=97=97 1st paragraph is awkward, especially the last sentence, what is the point o= f stating =93Therefore or clarity a Proxy is always assumed=94? I think th= e point is that typically, the discovery is typically achieved through a Pr= oxy but there can be cases in which it =93could=94 go to a Domain Registrar= , but unlikely, thus a Proxy is needed, right? Typo in step =93d=94 : there=92s an extra =93k=94 in =93bootstrapks service= =94 Section 3.1.2 =97=97=97=97=97=97 =93the communication protocol=94 to be more explicit is during the Discover= y protocol, correct? What is the =93bootstrapping protocol server=94 , the Domain Registrar? Section 3.1.3 =97=97=97=97=97=97=97 What is the =93bootstrapping protocol server=94 , the Domain Registrar? Th= is text seems to be inconsistent with Figure 2 as that Figure seems to indi= cate that the Join Request must be responded to before EST can come into pl= ay? Section 3.1.4 =97=97=97=97=97=97=97=97 Similarly, I didn=92t think EST was here =93yet=94=85.the Join Response (wh= ere the Audit Token is received by the New Entity) must be processed. It i= s implied here that the Domain Registrar=92s trust anchor is received. But= I think there are more explicit details to the contents of this response a= nd how the New Device can actually verify (not sure it can validate?) that = it has the right information to proceed with EST. Section 3.3 =97=97=97=97=97=97=97 Would be good to have naming consistancy: Domain registrar vs. Registrar vs= . Bootstrap Server (should be kept to 1 or 2 names to avoid confusion given= that there are already several actors in the flow). 1st paragraph: Implies that the bootstrap server is the one that maintains = the authorization database/state for which entities may be bootstrapped or = not? How does the Registrar know which/what MASA to reach to for the entity? Is= there a required trust relationship between the Registrar and the MASA to = process the Audit request? I think there is a MUST for this but I don=92t = see it in this section. This section speaks to using EST, but I think the Join Request/Response are= new messages (operations) which are augmented then to EST?? Section 4 =97=97=97=97=97=97 Is the Domain Operator the MASA? Figure 5 looks different than Figure 2 and should be consistent or perhaps = should be converged unless more details are to be provided in this sequence= ? Security Considerations =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97 I need to better understand the full flow and roles of the different actors= to later be able to more fully comment on what should be in the security c= onsiderations. I think given the current state, this section provides a good start but wou= ld like to see more on the considerations of trust between the different ac= tors (especially between the registrar and the MASA) - Nancy --_000_D3B19F2517FA5Fncamwingciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

As the S= ecurity Advisor for Anima, I have reviewed draft-ietf-anima-bootstrapping-k= eyinfra-03

and have= the following comments:


General<= /p>

=97=97= =97=97=97

Device i= s used inconsistently, but I believe in general device in this draft is the= =93target=94 or =93new device=94  that is being bootstrapped, correct= ?



Introduc= tion

=97=97= =97=97=97


In the p= aragraph beginning with =93A precise answer to these questions=85.=94 (at e= nd of page 3)

I believ= e =93devices from a variety of vendors=94 includes all network devices as w= ell as any generic device coming into the network and require bootstrap, bu= t its not clear?


Not clea= r what  =93and a network infrastructure (the domain) that is operated<= /p>

 &n= bsp; by parties that do not have any priviledged relationship with the

 &n= bsp; device vendors=94=85..who are the device vendors? I think it is the = =93new device=94 manfufacturer or vendor?


Terminol= ogy

=97=97= =97=97=97=97

I am pre= suming domain =3D internet domain?


Typo:&nb= sp; =93Imprint=94 definition =93key material to identity=94 should be =93ke= y material to identify=94


Pledge d= efinition: I think all references to =93device=94 is the device needing to = be bootstrapped?


Audit To= ken: it would be good to describe the =93manufacturer authorized signing au= thority=94 (e.g. MASA) as I believe the MASA is in general the vendor=92s m= anufacturer but in general, the MASA is some authority that s the one that can authorize the prospective devices t= o a particular domain (e.g. the domain of interest).  Thus the =93it= =94 in the =93=85that it authorizes bootstrap=94 is the MASA where the doma= in has assigned as the trusted authority.


Section = 1.2

=97=97= =97=97=97=97=97

Figure 1= : New Entity =3D New Device (these two terms seems to be used intermittentl= y, my nit would be to pick one for consistency)


MASA ser= vice: doesn=92t the MASA also holds an authoritative view of what new devic= es can join the specific domain?


Ownershi= p Tracker: in the Figure they are shown as part of the =93Vendor Service=94= and =93MASA=94, are they abstractly all the same component but can physica= lly be separate entities?  As it is understood there could be devices that come from multiple vendors, there can be many = instances of the =93Vendor Service=94=85.but could also imply that within a= =93Vendor Service=94 there can be a decoupling of the MASA and Ownership T= racker?


Section = 3.1

=97=97= =97=97-=97

=93A New= Entity MUST NOT automatically initiate bootstrapping=85.=94  how can = this be enforced?  There should be some description of implications in= the Security Considerations section (e.g. there may be instances in which a New Entity may need to go to a =93factory default= =94 state and be re-bootstrapped?)


Figure 2= :  =93Optional=94 can occur in advance=94 =85.not clear what steps can= be created in advance and how far in advance.  As the New Entity requ= ests to join, it=92s ID is not known to the Registrar, at least until the TLS connection is established=85.also, the Nonce is lis= ted as optional, but SHOULD or MUST be required to map it to provided Join = Request (e.g. it should be part of the same sequence).  

Clarity = somewhere in the document should be provided as to the operionality of whic= h entity does the Authorization for the New Entity to be bootstrapped (e.g.= is it the MASA or the Domain Registrar)=85.at this point it is not clear


Figure 3= : Should the box be =93Identify=94 vs =93Identity=94?


Step 2: = =93Identify itself=94 : what is meant by =93Although the Registrar is also = authenticated these

 &n= bsp;     credentials are only provisionally accepted at this time= =94?  I think the Registrar is provisionally accepting the 802.1AR to = protect the TLS channel, is that the point of this sentence?  But I also believe the New Device must provisionally accept the Registrar= =92s cert (also indicated in Figure 2)?


Step 3: = =93Request to Join=94 maps to =93Request Audit Token=94 in Figure 2?  =


Step 4:&= nbsp; =93This requires verification of=85=94: the New Entity does the verif= ication?  How does it do that? There is not enough details in here to = describe how it actually does this. Perhaps these steps should be prefaces as =93Summary=94 or =93Brief/Abbreviated=94 state= descriptions=85.


Step 5: = this reads a bit awkward=85.I think the point of this step is that it now h= as enough information, for instance, knowing the domain registrar=92s certi= ficate to be able to initiate certificate enrollment; and can do such enrollment using RFC 7030. Correct?


Step 6: = a nit: membership is based on the successful certificate enrollment of the = new entity=85correct?  This is correctly shown in Figure 3 :-)


Section = 3.1.1

=97=97= =97=97=97=97

1st para= graph is awkward, especially the last sentence, what is the point of statin= g =93Therefore or clarity a Proxy is always assumed=94?  I think the p= oint is that typically, the discovery is typically achieved through a Proxy but there can be cases in which it =93could=94 go= to a Domain Registrar, but unlikely, thus a Proxy is needed, right?


Typo in = step =93d=94 : there=92s an extra =93k=94 in =93bootstrapks service=94


Section = 3.1.2

=97=97= =97=97=97=97

=93the c= ommunication protocol=94 to be more explicit is during the Discovery protoc= ol, correct?


What is = the =93bootstrapping protocol server=94 , the Domain Registrar?


Section = 3.1.3

=97=97= =97=97=97=97=97

What is = the =93bootstrapping protocol server=94 , the Domain Registrar?  This = text seems to be inconsistent with Figure 2 as that Figure seems to indicat= e that the Join Request must be responded to before EST can come into play?


Section = 3.1.4

=97=97= =97=97=97=97=97=97

Similarl= y, I didn=92t think EST was here =93yet=94=85.the Join Response (where the = Audit Token is received by the New Entity) must be processed.  It is i= mplied here that the Domain Registrar=92s trust anchor is received.  But I think there are more explicit details to the cont= ents of this response and how the New Device can actually verify (not sure = it can validate?) that it has the right information to proceed with EST.


Section = 3.3

=97=97= =97=97=97=97=97

Would be= good to have naming consistancy: Domain registrar vs. Registrar vs. Bootst= rap Server (should be kept to 1 or 2 names to avoid confusion given that th= ere are already several actors in the flow).


1st para= graph: Implies that the bootstrap server is the one that maintains the auth= orization database/state for which entities may be bootstrapped or not? &nb= sp;


How does= the Registrar know which/what MASA to reach to for the entity?  Is th= ere a required trust relationship between the Registrar and the MASA to pro= cess the Audit request?  I think there is a MUST for this but I don=92t see it in this section.


This sec= tion speaks to using EST, but I think the Join Request/Response are new mes= sages (operations) which are augmented then to EST??


Section = 4

=97=97= =97=97=97=97

Is the D= omain Operator the MASA?  

Figure 5= looks different than Figure 2 and should be consistent or perhaps should b= e converged unless more details are to be provided in this sequence?



Security= Considerations

=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97

I need t= o better understand the full flow and roles of the different actors to late= r be able to more fully comment on what should be in the security considera= tions.


I think = given the current state, this section provides a good start but would like = to see more on the considerations of trust between the different actors (es= pecially between the registrar and the MASA)


- Nancy
--_000_D3B19F2517FA5Fncamwingciscocom_-- From nobody Sun Jul 17 20:47:35 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D2C12D18A; Sun, 17 Jul 2016 20:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-DG3mrGN97J; Sun, 17 Jul 2016 20:47:29 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C47712D0FC; Sun, 17 Jul 2016 20:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6029; q=dns/txt; s=iport; t=1468813648; x=1470023248; h=from:to:subject:date:message-id:mime-version; bh=4Y9214TdF4JBoHPPpmAnuXgVTsddBK2TNNVmyXms6QE=; b=EHItR+lTDAYvClvCg3b2mfO5CH8WxUKEap/X1GLMgFBis4ers6jG8ytu m5DiKpK7/t0sUNkdm+gkB8BzfYrjPV3HSIRDXGrNkypZ7uD5ZG604nf3q yMyt0YzhIbqSRKYikysoUdx+7w3bStjJ6iOfxI7PRd+uD4lQeI8Q/M5Ul U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAgDiUIxX/4cNJK1cgnFOgVizcIUEg?= =?us-ascii?q?XmHQzgUAQEBAQEBAWUnhGMnZAGBACcEAYhCvxMBAQEBBgEBAQEBIpUSBY5EimA?= =?us-ascii?q?BgTSNKo83kB0BHjaDc4cpfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,382,1464652800"; d="scan'208,217";a="125154613" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2016 03:47:12 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6I3lCKu027181 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jul 2016 03:47:12 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 17 Jul 2016 23:47:11 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Sun, 17 Jul 2016 23:47:11 -0400 From: "Nancy Cam-Winget (ncamwing)" To: "anima@ietf.org" , "secdir@ietf.org" Thread-Topic: Initial review of draft-ietf-anima-reference-model-01 Thread-Index: AQHR4KcQhmP1KNYyx0WDpAcA6/CBjw== Date: Mon, 18 Jul 2016 03:47:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.1.202] Content-Type: multipart/alternative; boundary="_000_D3B19F4917FA63ncamwingciscocom_" MIME-Version: 1.0 Archived-At: Subject: [secdir] Initial review of draft-ietf-anima-reference-model-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 03:47:30 -0000 --_000_D3B19F4917FA63ncamwingciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As the Security Advisor for Anima, I have reviewed draft-ietf-anima-referen= ce-model-01 and have the following comments: Editorial nits: Section 4.6 : ACP's full description should be called out as its the first = instance of its use in this draft. Section 7.1: "general concepts, such as sitting on top of the ANI, etc." se= ems to be a dangling sentence (at least ill formed). Section 7.2 typo in several references: "Enrolment" -> Enrollment Comments: Section 6: - Self-protecting against what attacks? All possible attacks (hard to pr= edict) or is it "known" attacks as described where? - All protocols are secure by default implies that all protocols a config= ured by default to be encrypted to provide both confidentiality and integri= ty? Section 6.2: is a device =3D autonomic node? Section 6.3: the MASA is the implied CA as well? Section 7.2 (as a whole): seems to be incomplete....are constrained vs. unc= onstrained nodes explained elsewhere? This description seems to imply its = definition being in this section, but perhaps more text is missing? Section 10: - The security considerations should discuss the potential for malware, e.= g. a node that has either been misconfigured or infected. - Should there be privacy considerations as potential topology and identit= ies be disclosed especially during discovery and bootstrap? Nancy --_000_D3B19F4917FA63ncamwingciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

As the S= ecurity Advisor for Anima, I have reviewed draft-ietf-anima-reference-model= -01

and have= the following comments:


Editoria= l nits:

Section = 4.6 : ACP’s full description should be called out as its the first in= stance of its use in this draft.


Section 7.1: “g= eneral concepts, such as sitting on top of the ANI, etc.” seems to be= a dangling sentence (at least ill formed).


Section 7.= 2 typo in several references: “Enrolment” -> Enrollment



Comments= :

Section = 6:  

  -= Self-protecting against what attacks?  All possible attacks (hard to = predict)  or is it “known” attacks as described where?

  -= All protocols are secure by default implies that all protocols a configure= d by default to be encrypted to provide both confidentiality and integrity?=


Section = 6.2:  is a device =3D autonomic node?


Section = 6.3: the MASA is the implied CA as well?


Section = 7.2 (as a whole): seems to be incomplete….are constrained vs. unconst= rained nodes explained elsewhere?  This description seems to imply its= definition being in this section, but perhaps more text is missing?


Section = 10:

 - = The security considerations should discuss the potential for malware, e.g. = a node that has either been misconfigured or infected.

 - = Should there be privacy considerations as potential topology and identities= be disclosed especially during discovery and bootstrap?



  &= nbsp;Nancy

--_000_D3B19F4917FA63ncamwingciscocom_-- From nobody Mon Jul 18 23:51:52 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30D312D100 for ; Mon, 18 Jul 2016 23:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzntgngVqS9T for ; Mon, 18 Jul 2016 23:51:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BB512B02A for ; Mon, 18 Jul 2016 23:51:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E813EBE47 for ; Tue, 19 Jul 2016 07:51:46 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcB_euyPeYUJ for ; Tue, 19 Jul 2016 07:51:45 +0100 (IST) Received: from [31.133.178.21] (dhcp-b215.meeting.ietf.org [31.133.178.21]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3D6BCBE3F for ; Tue, 19 Jul 2016 07:51:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1468911105; bh=mm80vgOI+dYQ/jfNLsO905H4jXiuZMFtmncM6jPJYME=; h=To:From:Subject:Date:From; b=oqdRqe9+NKME7OTRwsgiqLtKN1rDRTUeKT64SU0LufOeEohn+uKC5dFVC5fyY7JSg eq49OijsG6cBhor/CrIFFJIoKaALOQLiV8Uekdh9F4l2tWDnHB9znaMq/f9pUATMwH /6TmcWFJz+S9G6dDaJQfdets0M4lGfs0jSRzcWhQ= To: "secdir@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <578DCE00.5020805@cs.tcd.ie> Date: Tue, 19 Jul 2016 07:51:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000005070009010209060108" Archived-At: Subject: [secdir] reminder: secdir lunch is in tegel room X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 06:51:51 -0000 This is a cryptographically signed message in MIME format. --------------ms000005070009010209060108 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable See you there at about 1230 (+food acquisition delay) Cheers, S. --------------ms000005070009010209060108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTkw NjUxNDRaMC8GCSqGSIb3DQEJBDEiBCB8Kd7A7Atoy1rXim7AJ/IXwxX8FJUDxi3a5h64v+LJ EzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAVJm3toQK4qdrh/1I1WfiNG0y/8xAueUmAtHJKFdNh2uVTxWg9BZHq AMdnX57Ush/OF/wcrh7eFdQXzLfH3cxA99RiynBsmDGlSDTY2D6LCiCYVbF59bKib9OOKLAe LlPsV8+MEdVGpDOVqN5zc7X1e58DwNjkr03WHpuX41pLfjTBh0rIw6tFJGjHWQF1o2B72+k+ ghi9CJuzTR++4YmfBHqA4x2qwVmldddv2hWykquLNPqwapCOIvyO/FjWA4F+Gh9yBtsPT8ft +ZjB33QLU4fudtH2TWO6lkZSbBFHlafLZppWPdKMvK94aisKRWek9GSflUtqsEZby7ucGYdY AAAAAAAA --------------ms000005070009010209060108-- From nobody Tue Jul 19 01:17:27 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F24B12DC0C for ; Tue, 19 Jul 2016 01:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awMphkGiFhWi for ; Tue, 19 Jul 2016 01:17:24 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0D07F12D13E for ; Tue, 19 Jul 2016 01:17:24 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6019416CA26 for ; Tue, 19 Jul 2016 08:17:23 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 1446016C9C1 for ; Tue, 19 Jul 2016 08:17:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1468916243; bh=4i/Y9jUZP4CMPdNQu7UqAteKwEDLsj2XKZrmqep0sHg=; l=116; h=From:To:Date:References:In-Reply-To:From; b=aChKMOUJSno0Z2JH8QOca+fswk4CxlZ8R21BmaS4claCqc/cw83t0MIiv7AXMs+tN iJdRvkn+2i4HsRJ4ysX/XRyznUAnRUhb1KvmxvPOF0gry2oC4Nf5mimnywJSTcohcb pUKMWAYl/petWgmJd9l9raTuW5287sNlX5LCYUXA= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id E7EAD98082 for ; Tue, 19 Jul 2016 08:17:22 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 19 Jul 2016 04:17:22 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 19 Jul 2016 04:17:22 -0400 From: "Salz, Rich" To: "secdir@ietf.org" Thread-Topic: [secdir] reminder: secdir lunch is in tegel room Thread-Index: AQHR4YoK8VhyKzVOZki5/sOI/O2Pd6AfaLdg Date: Tue, 19 Jul 2016 08:17:21 +0000 Message-ID: <912cc4270e6b4ea99171a2930b89ff00@usma1ex-dag1mb1.msg.corp.akamai.com> References: <578DCE00.5020805@cs.tcd.ie> In-Reply-To: <578DCE00.5020805@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.153.26] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] reminder: secdir lunch is in tegel room X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 08:17:26 -0000 DQo+IFNlZSB5b3UgdGhlcmUgYXQgYWJvdXQgMTIzMCAoK2Zvb2QgYWNxdWlzaXRpb24gZGVsYXkp DQoNCmFueSByZWNvbW1lbmRhdGlvbnM/DQo= From nobody Tue Jul 19 01:26:37 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF17C12DBC0 for ; Tue, 19 Jul 2016 01:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-IG0YknbPne for ; Tue, 19 Jul 2016 01:26:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B598012D0DD for ; Tue, 19 Jul 2016 01:26:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 33F5FBE3E; Tue, 19 Jul 2016 09:26:29 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiQMBjibzh2S; Tue, 19 Jul 2016 09:26:27 +0100 (IST) Received: from [31.133.178.21] (dhcp-b215.meeting.ietf.org [31.133.178.21]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AB4E2BE38; Tue, 19 Jul 2016 09:26:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1468916787; bh=uL2/vdHXHJxRpiqBpLBDgZuVmg+7TUGO+0iPJ5NxAgg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QsSdbSWwHa4w4cT6D1Vbyy/XKr95oGeKgHdPvdM0H7tt+zc2DYgU04WAWSFyyEOuE wwChw8eQJVzuTfu19GNDg4Bd7OJgUXByj6/3Rr3goVqCIKhf4aYerddn0xaAFiiYzq XdtAzt26ET1bJ80tlQYpadOOcVIO9nxLebWy7vuQ= To: "Salz, Rich" , "secdir@ietf.org" References: <578DCE00.5020805@cs.tcd.ie> <912cc4270e6b4ea99171a2930b89ff00@usma1ex-dag1mb1.msg.corp.akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <401e7d5c-fd09-e9a1-0067-5f72b3f14b46@cs.tcd.ie> Date: Tue, 19 Jul 2016 09:26:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <912cc4270e6b4ea99171a2930b89ff00@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010809000904080403050005" Archived-At: Subject: Re: [secdir] reminder: secdir lunch is in tegel room X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 08:26:36 -0000 This is a cryptographically signed message in MIME format. --------------ms010809000904080403050005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19/07/16 09:17, Salz, Rich wrote: >=20 >> See you there at about 1230 (+food acquisition delay) >=20 > any recommendations? I haven't tried any but there was some chatter on the attendees list [1] S. [1] https://www.ietf.org/mail-archive/web/96attendees/current/msg00331.ht= ml > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 --------------ms010809000904080403050005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTkw ODI2MjZaMC8GCSqGSIb3DQEJBDEiBCBuG2kc2+0nwLJp1JjtLR0bKQS3lhKG2AaTPeNXP9OD 2jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAnvfRJfnz1dQxunIpakvh5gbjroFvhUhM5jmS/NC+8EiEUVV3SXaul 8u5OBUmoABinsP6nspSKjciQeqkfUnQD3Ke77L3Fpqs/zmhF7ZGfqPl6h4DwwDruNeKeb9rp UVOkEDOZw8I7mDoJk0eCwJwgCkDb1mu4xAEnx1aiwiVol+lXEcm+v5cNMsONi7LJ7oxePlzt OaD31GAXhD4V3HAaXiNI+86ZGuzvssah8nmS7t06PO3Rc3Q1T2HopUA5s98axDA7cGiX7AQv 1PvLlcIZYIWmfKhl4b1ne709/AGJwbOkT+dxLpnA/nvuGe6N7brwcFr+omstEbwmRgl0D5vI AAAAAAAA --------------ms010809000904080403050005-- From nobody Wed Jul 20 09:17:51 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4643D12D745; Wed, 20 Jul 2016 09:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r_eW1ZngJ0N; Wed, 20 Jul 2016 09:17:44 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB8212D4FB; Wed, 20 Jul 2016 09:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1545; q=dns/txt; s=iport; t=1469031464; x=1470241064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=k23SDWqEMcyrCzQSNvJLape+tDbwE9imyuRDlVq2udU=; b=ZXhhvCGOgnfjKg3CmZifm7yKX8X1Qg4s/XsrtV0OKwl7vzSoSjrupC8Y Cj07nvT8QvL6FLWq3nWwPNzDuZ9qm58G+fDUq578D3g7nmypcrAl+Fu83 AHpOa9MyyMSvh8pn36rt+FeuBAe2ZpbQxJK5XIyxsGQLQ9KntYqKn+htF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgDWo49X/5RdJa1aA4M/gVIGrDuKD?= =?us-ascii?q?IIPgXqGGgKBMzgUAQEBAQEBAWUnhFwBAQQBOj8FCwIBCA4KHhAhESUCBA4FiBY?= =?us-ascii?q?DDwi5LQ2ECAEBAQEBAQEBAQEBAQEBAQEBAQEBARyGKoF4glWCQ4F9ISaCZYIvB?= =?us-ascii?q?ZhyNAGMQ4IejzmIJYd6AR42g3Nuhih/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,395,1464652800"; d="scan'208";a="298333080" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 16:17:43 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u6KGHhnE003661 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 16:17:43 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 11:17:42 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 11:17:42 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Donald Eastlake Thread-Topic: SECDIR Review of draft-pd-dispatch-msrp-websocket-12 Thread-Index: AQHR1mwKOKLbBiieG02Ud0rnTNWPgqAh63SA Date: Wed, 20 Jul 2016 16:17:42 +0000 Message-ID: <04408A34-8FBA-4E60-8D8D-6B4501714E9A@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.171.33] Content-Type: text/plain; charset="us-ascii" Content-ID: <15243651D9AE6944A7F9DACD754FE140@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "iesg@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR Review of draft-pd-dispatch-msrp-websocket-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 16:17:46 -0000 Hi Donald -=20 Thanks for the review. Inline... > On Jul 5, 2016, at 5:18 AM, Donald Eastlake wrote: >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. Document editors and WG chairs should treat these comments just > like any other last call comments. >=20 > This draft specifies a new WebSocket sub-protocol as a reliable > transport mechanism between MSRP (Message Session Relay Protocol) > clients and relays. It depends on the use of secure WebSocket > connections (TLS) and existing authentication mechanisms. I am not > particularly familiar with WebSockets or MSRP but the Security > Considerations section looks adequate to me. >=20 > There are a lot of example message flows in this document that i don't > really know enough to evaluate. >=20 > Nits: >=20 > It is peculiar that Sections 10, Section 11, and Appendix A have only > a single subsection aa their entire content. In the case of Sections > 10 and 11, I think the 10.1 and 11.1 headers should just be > eliminated. In the case of Appendix A, probably the A.1 heading should > be moved up to the A level. Agreed. We have made all your suggested changes. Thanks, Gonzalo >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com From nobody Thu Jul 21 02:38:55 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DF412DBE8 for ; Thu, 21 Jul 2016 02:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxDfv1WYu_V5 for ; Thu, 21 Jul 2016 02:38:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02F712B004 for ; Thu, 21 Jul 2016 02:38:51 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u6L9clmE011705 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 21 Jul 2016 12:38:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6L9clRb008256; Thu, 21 Jul 2016 12:38:47 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22416.38951.270608.739085@fireball.acr.fi> Date: Thu, 21 Jul 2016 12:38:47 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 09:38:54 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Magnus Nystrom is next in the rotation. For telechat 2016-08-04 Reviewer LC end Draft Tobias Gondrom T 2016-07-11 draft-sweet-rfc2910bis-08 Paul Hoffman TR2016-07-04 draft-ietf-grow-blackholing-02 Simon Josefsson T 2016-07-13 draft-ietf-6lo-ethertype-request-01 Warren Kumari T 2016-07-29 draft-sweet-rfc2911bis-09 Catherine Meadows T 2016-08-01 draft-ietf-xrblock-independent-burst-gap-discard-02 Yaron Sheffer TR2016-05-23 draft-ietf-dhc-topo-conf-08 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Jeffrey Hutzelman 2016-07-04 draft-ietf-sipcore-dns-dual-stack-06 Stephen Kent 2016-07-12 draft-ietf-nfsv4-scsi-layout-06 Ben Laurie 2016-08-04 draft-ietf-6man-multi-homed-host-07 Matt Lepinski 2016-08-04 draft-ietf-insipid-session-id-24 Chris Lonvick 2016-08-10 draft-ietf-mmusic-sdp-mux-attributes-13 Matthew Miller 2016-08-06 draft-ietf-avtcore-rfc5764-mux-fixes-10 Adam Montville 2016-07-29 draft-ietf-dnsop-nxdomain-cut-03 Sandy Murphy 2016-08-12 draft-ietf-tsvwg-gre-in-udp-encap-13 Yoav Nir 2016-08-17 draft-seantek-ldap-pkcs9-05 Yaron Sheffer R2016-07-21 draft-ietf-trill-channel-tunnel-10 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-14 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-05 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 -- kivinen@iki.fi From nobody Sun Jul 24 07:38:56 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C4812D77C; Sun, 24 Jul 2016 07:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7wBH64-BRId; Sun, 24 Jul 2016 07:38:50 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613E112D6B9; Sun, 24 Jul 2016 07:38:50 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id r9so141453368ywg.0; Sun, 24 Jul 2016 07:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version; bh=g4tkgx2a3FNClWqFsv9pwJOufZn12DILBQG2Q+AcAtw=; b=iqSmyGc/uUVno+gkaitiUZRRGGkhRKWuhKcenfnrCgcr5oXSFmbmIzAZ3hBbfB1B8w mfg00txNeaJazsPVfSFC76D5mug7Vet5RiMbeOHc5HlciUDGtZ/SkR/c+rV8LT8gww1P qfcDc2b65W7WdOD+atFEmcjAXiEOI1gQGm0j3nk8B6CnZbo/FGic6mDRg58vwEIO8QvM H9GHqKWZGOA4xMqZdgUE1/q1oaAzpqFhzzEoeC0RngK84BLdLw0CJOyZ09835IGzMglh 9npZBMkMkUnE93OTg2nSnaTCG9Asqiw7qP948fKJAKFjl2w2g7DoHhV7BfpkazGFPZUQ k/bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=g4tkgx2a3FNClWqFsv9pwJOufZn12DILBQG2Q+AcAtw=; b=Q6v6uZsIyTFUMMFltAImCUD8rJqdAQ4Tb+iLytSyRQ4/+FAjfQzYF7wZNNpMQiFb4i 2uPaV21Xu2i/YvRCSZ1kVlC4H8qklTjBVyGUBcXH/v4nQ1bKjb7Bh9lQ4tdOJWyAEsGp khxh0s0VTn2FH/10KXdUQE1skqzHL73H0OAA1uPs+gepv0D/mJwQNPxSsIUl4tfRlj2c HigGe/DpMCjidmWmgP2QQEWHvHOEMzUUrVoVtw2czQbIFkuEb26Dx6GJbTDXicogACbz E68i/T+8mEQZ0ZjxLVpGNkixzr0P/ntfpdc5GcuKRHQqMDRtNM92wS4I9T3RIIYhPj5F 4yXw== X-Gm-Message-State: AEkooutGGKx5f7+RTKxJpRCvv2XaWR5/6INp8wFQuHvtMOBrf6WU/g3Aol907pnYRmolqA== X-Received: by 10.37.36.197 with SMTP id k188mr5418327ybk.30.1469371129454; Sun, 24 Jul 2016 07:38:49 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:3c32:47ac:f71f:323f]) by smtp.googlemail.com with ESMTPSA id j11sm246760ywa.39.2016.07.24.07.38.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jul 2016 07:38:49 -0700 (PDT) To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-mmusic-sdp-mux-attributes-13.all@ietf.org From: Chris Lonvick Message-ID: <5794D308.7010401@gmail.com> Date: Sun, 24 Jul 2016 09:39:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020507050402040909000305" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 14:38:52 -0000 This is a multi-part message in MIME format. --------------020507050402040909000305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I've been rather busy and haven't had time to thoroughly review this document. But I did look at the Security Considerations section and will recommend that some additions be made. The Security Considerations section says, "This document does not add any new security considerations beyond the existing considerations in the RFCs for protocols that are being multiplexed together. " (First paragraph.) I believe that it would be helpful to readers and implementers if the specification were to give pointers to RFCs for protocols that are being multiplexed together, and their security considerations. The section continues by saying, "The ways that SRTP streams are keyed is not believed to create any two-time pad vulnerability for the currently defined SRTP keying mechanism." (Second paragraph.) I may not have seen it but I don't believe that this document specifies keying for SRTP streams, but only references RFC4567 (Section 5.35) and RFC4572 (Section 5.36). If that's the case, then this document doesn't need to opine about possible vulnerabilities in that area; leave it to those or subsequent documents to make that analysis. It would be appropriate to reiterate that the CAUTION category may produce some problems. For completeness, it may be good to include pointers to other mmusic and SDP documents that have addressed security aspects. A statement of how that may apply to this specification would be appropriate. I don't think this would need to be detailed. Best regards, Chris --------------020507050402040909000305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

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

I've been rather busy and haven't had time to thoroughly review this document. But I did look at the Security Considerations section and will recommend that some additions be made. The Security Considerations section says, "This document does not add any new security considerations beyond the existing considerations in the RFCs for protocols that are being multiplexed together. " (First paragraph.) I believe that it would be helpful to readers and implementers if the specification were to give pointers to RFCs for protocols that are being multiplexed together, and their security considerations.

The section continues by saying, "The ways that SRTP streams are keyed is not believed to create any two-time pad vulnerability for the currently defined SRTP keying mechanism." (Second paragraph.) I may not have seen it but I don't believe that this document specifies keying for SRTP streams, but only references RFC4567 (Section 5.35) and RFC4572 (Section 5.36). If that's the case, then this document doesn't need to opine about possible vulnerabilities in that area; leave it to those or subsequent documents to make that analysis.

It would be appropriate to reiterate that the CAUTION category may produce some problems.

For completeness, it may be good to include pointers to other mmusic and SDP documents that have addressed security aspects. A statement of how that may apply to this specification would be appropriate. I don't think this would need to be detailed.

Best regards,
Chris
--------------020507050402040909000305-- From nobody Sun Jul 24 07:41:15 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F40412D862; Sun, 24 Jul 2016 07:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueU0mc2lNNUX; Sun, 24 Jul 2016 07:41:07 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B13E112D864; Sun, 24 Jul 2016 07:41:03 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id u134so140674415ywg.3; Sun, 24 Jul 2016 07:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=/u4QEQRZkyiBD4IraIKIwxe11Y60PJBa7KAq33UjP+A=; b=fua2t2Y/U3MZMAGd182V8bM20fjnc+4g/vy/5flOXogj87pGHxPaEqpoKNcPFH5SVx PMFiUhgIurZbYScbWOIN2523BuxUUscWaxUqP/tJDvgjDjQ+j+aqycVUerhKzdabn1fC iUjoLdYxRyeab2WGJRMEo1hi3SMrT27ERHgo5AGOACFGcjYFq9g+gq2n1I4sPK+/JFaw AYuftFcipKxGtPASg3iOhKHYs01lJ8HTxG/4SXyrS3ERXgucaxRr549Mvy+pSoiNITUz vPZbJ023XsuOFAbELVLM4FGokxOmD/MbI1Q1Ci37CDB6ze0ApltG0DFHy+cJBVwh9idQ ETIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=/u4QEQRZkyiBD4IraIKIwxe11Y60PJBa7KAq33UjP+A=; b=YSyqtIV/CxiOQ1n1SCAfUGUU839mTrbQ6CQCG0MxHDJEcu0Rmc86oiOPWYAzTm8f1W dEE9msdZfWLahgbszkrawJaMWfJIQX9TLALqC1t3QjUpfhVgMX7goXRKT0kELT1ff37s 8URrBlrR1C6r0CJyjS342zozSoEmw2yzylCH8MyOqbipJUeY3qhH4APG8tPBjRsbJoPw xkq1b6MGbTpHUZ9nx3pW5tIXfrouEBPmciHhgTNazds1VYSKNVJwD6UcfUGyTNOspXyo dJ6qnC/rFu22Ofjwo/vPjsHsGbxiCO2bGeCYxSv1o8yFbcO+7I4/m9fkweYutpCz7jMk pNbA== X-Gm-Message-State: AEkoouvDZF67m4dPkK2FbcoqH+mc6XTaXE1qMAsx0KvrdUSlaSJAjjV3Z8QPy8e/YQHhVg== X-Received: by 10.13.236.150 with SMTP id v144mr12159652ywe.9.1469371262942; Sun, 24 Jul 2016 07:41:02 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:3c32:47ac:f71f:323f]) by smtp.googlemail.com with ESMTPSA id j124sm9456712ywg.49.2016.07.24.07.41.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jul 2016 07:41:02 -0700 (PDT) To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org References: <5794D308.7010401@gmail.com> From: Chris Lonvick Message-ID: <5794D38E.90709@gmail.com> Date: Sun, 24 Jul 2016 09:41:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5794D308.7010401@gmail.com> Content-Type: multipart/alternative; boundary="------------010701030503080206000702" Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 14:41:08 -0000 This is a multi-part message in MIME format. --------------010701030503080206000702 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Apologies for the duplication - resending to the right alias. On 7/24/16 9:39 AM, Chris Lonvick wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I've been rather busy and haven't had time to thoroughly review this > document. But I did look at the Security Considerations section and > will recommend that some additions be made. The Security > Considerations section says, "This document does not add any new > security considerations beyond the existing considerations in the RFCs > for protocols that are being multiplexed together. " (First > paragraph.) I believe that it would be helpful to readers and > implementers if the specification were to give pointers to RFCs for > protocols that are being multiplexed together, and their security > considerations. > > The section continues by saying, "The ways that SRTP streams are keyed > is not believed to create any two-time pad vulnerability for the > currently defined SRTP keying mechanism." (Second paragraph.) I may > not have seen it but I don't believe that this document specifies > keying for SRTP streams, but only references RFC4567 (Section 5.35) > and RFC4572 (Section 5.36). If that's the case, then this document > doesn't need to opine about possible vulnerabilities in that area; > leave it to those or subsequent documents to make that analysis. > > It would be appropriate to reiterate that the CAUTION category may > produce some problems. > > For completeness, it may be good to include pointers to other mmusic > and SDP documents that have addressed security aspects. A statement of > how that may apply to this specification would be appropriate. I don't > think this would need to be detailed. > > Best regards, > Chris --------------010701030503080206000702 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Apologies for the duplication - resending to the right alias.

On 7/24/16 9:39 AM, Chris Lonvick wrote:
Hi,

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

I've been rather busy and haven't had time to thoroughly review this document. But I did look at the Security Considerations section and will recommend that some additions be made. The Security Considerations section says, "This document does not add any new security considerations beyond the existing considerations in the RFCs for protocols that are being multiplexed together. " (First paragraph.) I believe that it would be helpful to readers and implementers if the specification were to give pointers to RFCs for protocols that are being multiplexed together, and their security considerations.

The section continues by saying, "The ways that SRTP streams are keyed is not believed to create any two-time pad vulnerability for the currently defined SRTP keying mechanism." (Second paragraph.) I may not have seen it but I don't believe that this document specifies keying for SRTP streams, but only references RFC4567 (Section 5.35) and RFC4572 (Section 5.36). If that's the case, then this document doesn't need to opine about possible vulnerabilities in that area; leave it to those or subsequent documents to make that analysis.

It would be appropriate to reiterate that the CAUTION category may produce some problems.

For completeness, it may be good to include pointers to other mmusic and SDP documents that have addressed security aspects. A statement of how that may apply to this specification would be appropriate. I don't think this would need to be detailed.

Best regards,
Chris

--------------010701030503080206000702-- From nobody Tue Jul 26 13:38:48 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C850312D94F; Tue, 26 Jul 2016 13:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsPgHzOAtj-4; Tue, 26 Jul 2016 13:38:44 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26D912D5DB; Tue, 26 Jul 2016 13:38:41 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id q83so42066114iod.1; Tue, 26 Jul 2016 13:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:to:mime-version; bh=lCUER9FPl49r9eoDVzSJ4g9DGngbZNYCgEu41bG9S9Y=; b=QUDtn+uD12tNL42CVfSZTSLmkZKTDbO2p0xNKtlX3R76Q/bwt/B7whNQ+g3BR4ZYR2 8gqannwa25HC2BXsBfstiowbGttfOuZQTQr3KX4DWSqKpjpUidssmPd7pw7IL942Dx26 Zg8ak2Fg59dnmmznSpucPVhu8GYG7nw75mkF94OcUjZTSiz9jqazPWckqPXhfTi1KmpJ A0kp3lq147LQ4T4M4qkXKkRWmqCO4bzRjb7IfVzEEyldTwYgGMhf+LH0lHquZEkh9F5c iof3pfO4QWFHpuWLDVCNfD0zeQfnSu2PWUPy8UDu8i+TXOoiQjAREvv5UubSGMMIhokj tPuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:to:mime-version; bh=lCUER9FPl49r9eoDVzSJ4g9DGngbZNYCgEu41bG9S9Y=; b=OofXUGM8J5EwwGobdvnhHGtISklrdfWrlmGREWcutORHs9VvH+pZrViLOaGba5qH/U 53gqRD4KjUHnRFFOTiZYB0aeOFUauxixGl15swQNgarEwRYQkx7lX+BrahlQhCUcO7ZE ouMYuavqGcaxLo0OkAoxuLeluflJ6hWv9VxZqR1vR3E/D9ucCXrA/Qld8Z6waWY3T5Gy 2eg5b/Tp2b0iiIOWzphAJtfMnlCCpe6p9GxCh1+CJjZkPNOSDTo2c4AwmBaUdFGv48z4 SIss9biwvR4N+HfjhNuPWJ80631x8ALrkvyak3oGILIHn6t8c07POCQ+ERwLsaNsumEW BdMg== X-Gm-Message-State: AEkoouvI3RZ9PsXXUlSOWPzYx++X0lLElub4o2gXqomsTjINYSIhooXqSiz350R36X3yWg== X-Received: by 10.157.40.215 with SMTP id s81mr14727953ota.160.1469565520794; Tue, 26 Jul 2016 13:38:40 -0700 (PDT) Received: from adams-mbp.attlocal.net (99-64-100-131.lightspeed.austtx.sbcglobal.net. [99.64.100.131]) by smtp.gmail.com with ESMTPSA id l191sm984184oib.2.2016.07.26.13.38.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jul 2016 13:38:39 -0700 (PDT) From: Adam Montville X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_96301584-1359-4E37-B14D-8A8DF85E8328"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 26 Jul 2016 15:38:34 -0500 Message-Id: To: The IESG , secdir@ietf.org, draft-ietf-dnsop-nxdomain-cut.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [secdir] SECDIR review of draft-ietf-dnsop-nxdomain-cut X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 20:38:47 -0000 --Apple-Mail=_96301584-1359-4E37-B14D-8A8DF85E8328 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This document is: Ready This document explains the reasoning behind, and advantages of, NXDOMAIN = cut=E2=80=94a method of ensuring that non-existence of a node in the = domain name tree implies non-existence of the entire sub-tree. The = solution does seem to require DNSSEC, as mentioned in the security = considerations section, to avoid certain DOS circumstances (which are = already possible, but potentially amplified by NXDOMAIN cut). --Apple-Mail=_96301584-1359-4E37-B14D-8A8DF85E8328 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXl8pOAAoJEDEhyx7etgABHIgP/iAlezfhATGqrptABYnC8g1X Sp16DmT8k2U2edQQvBWXsjiXO0fh+FnyldiZAEEqaG+CknV7Ppl22LdGmiFGYVak wcgO/9gMvIEfGW8FTSxFPg+o2mRuddT8Vn3URjDjzJC9a0p6PCSfXg0asyvJwYte aLY7ZYKe/njXHTKFpIFCnsXcIK8xCPBR5ePZIPry5Pc+AUWw8Mvgn2pkXq0htq9O MKG53X2lPxWc+qS7EWV/In+O4CzZD/D5XsFDRT4hAEgy4tMbm/AkfNadoOcDH8kC /AlWKrr84ZS1IDfef3liWCcbYjic/0SoyeLveq9vU7FFBcgeeRAA61kTuXe4of5l Ykf6z2tPuXsiIFTlbUagASQQ/oIxwxtusXqacuYT1TXN67UlZLvMZKAmU2P+aa6W M8jZf/FTDEcRtC0K0Hbr7ze6LS1FBa+fkM5On3ZzMIz+y3srvna9ck8cBXTendxA 4Zi2dqhlaPWHh64Jg//rEMywqEGCfuknKGn3THMWKtbnhVtXTCdu2C2ZsnC9d44B eAlCd6bSl44KDlHqw6AqvpUVKMTAxr833mnM7NdZVGc8byC+Lu2kWIm9u69gD/It 1XtUPPBdHBD8SOGhoNS3f/aroPIgIArZcGXEYmOjBRpTPjvb0BiQkv3wMmbWeYKO Lu0pZg5H8zz6Ye4SmVYE =jJMb -----END PGP SIGNATURE----- --Apple-Mail=_96301584-1359-4E37-B14D-8A8DF85E8328-- From nobody Thu Jul 28 03:13:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE71312DE52 for ; Thu, 28 Jul 2016 03:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGoleaNwU07h for ; Thu, 28 Jul 2016 03:13:09 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC8D12DE49 for ; Thu, 28 Jul 2016 03:13:07 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u6SAD4li007905 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 Jul 2016 13:13:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u6SAD3ui011444; Thu, 28 Jul 2016 13:13:03 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22425.55983.742347.248368@fireball.acr.fi> Date: Thu, 28 Jul 2016 13:13:03 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 10:13:12 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Hilarie Orman is next in the rotation. For telechat 2016-08-04 Reviewer LC end Draft Tobias Gondrom T 2016-07-11 draft-sweet-rfc2910bis-08 Paul Hoffman TR2016-07-04 draft-ietf-grow-blackholing-02 Simon Josefsson T 2016-07-13 draft-ietf-6lo-ethertype-request-01 Warren Kumari T 2016-07-29 draft-sweet-rfc2911bis-09 Ben Laurie T 2016-08-04 draft-ietf-6man-multi-homed-host-07 Catherine Meadows T 2016-08-01 draft-ietf-xrblock-independent-burst-gap-discard-02 Yaron Sheffer TR2016-05-23 draft-ietf-dhc-topo-conf-08 For telechat 2016-08-18 Magnus Nystrom T 2016-08-10 draft-ietf-bess-ir-03 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Jeffrey Hutzelman 2016-07-04 draft-ietf-sipcore-dns-dual-stack-06 Stephen Kent 2016-07-12 draft-ietf-nfsv4-scsi-layout-06 Matt Lepinski 2016-08-04 draft-ietf-insipid-session-id-24 Matthew Miller 2016-08-06 draft-ietf-avtcore-rfc5764-mux-fixes-10 Sandy Murphy 2016-08-12 draft-ietf-tsvwg-gre-in-udp-encap-13 Yoav Nir 2016-08-17 draft-seantek-ldap-pkcs9-05 Yaron Sheffer R2016-07-21 draft-ietf-trill-channel-tunnel-10 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-14 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-05 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 -- kivinen@iki.fi From nobody Fri Jul 29 08:32:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E656112D58C; Fri, 29 Jul 2016 08:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqC1HiBhHGbD; Fri, 29 Jul 2016 08:32:44 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EA312B065; Fri, 29 Jul 2016 08:32:44 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id i5so157390788wmg.0; Fri, 29 Jul 2016 08:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=yfH8++JnNw/GBfe3fyqGoBXM8pgvunfHkGHTpCvfktk=; b=kSmnhERQVgPX1v8wj7JgNap9/PFjNbnam5WB95PfWe6rT0fLQNrdAN1PJ0iBVWv3bW YBLMnOtvC71Hac3leDf691YRrRhWbpX/duQ8tppsjMaNQVGsFg+mDsnZkIpPNtJ3R6+a dXZInQzfAbCCFLKC7giAltPFkyF6q8U5sYfza8yOM61G8nx3XkIqmhLy8CwvwRge5eTb TMUeOPW2QILic+tpwMANZSLxoo+UWD31qWm9Jfm3IEDuxia6B505H33G08zMgqT7/WMo qxQMClTD3NV1HYZv64yLnfQTKUtjhYri0BWUPRX/KmTxr4Oh+OZogY/IEYhTRS14W0k3 cAtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=yfH8++JnNw/GBfe3fyqGoBXM8pgvunfHkGHTpCvfktk=; b=W2Qk6p8R8BqVqNeGAw01tgtjhSawFVT4Cutb7i+YI5scq084u2nKAOm0z+tdEsfmSc TdhvFSYASam/UmDU7m0azTMNeEUaMU3ZCuwefgZxGt3+J5qVFIsEXfZ9PqQwOBsJwuFy IvnGVYDzKiic5tp/4G4ylCG/P4rYKHVPZHrhLiMUJANA0vr+XWcAuFPKkXtDZ/IRt2S9 dHvUKYsGbedOHVFYCp8e3kEwqPhMlH/uhGdUj14cniMYWxPckq4SLraqcDnEDmOjfdNj GEgWUgvKlGQsEkXrfW1z9ZBrbxWTwMIWa0fhtExnu1k3k+JwBQApWjU0ZXWDbgRLxK5B 5Fow== X-Gm-Message-State: AEkoousuxMVBosbDFF3pjpVkpdSIma8RifLNjSVIKDg64V/bg12s5TmCZ+QUzHs5Saycig== X-Received: by 10.28.171.214 with SMTP id u205mr25934691wme.97.1469806363038; Fri, 29 Jul 2016 08:32:43 -0700 (PDT) Received: from [10.0.0.5] (bzq-109-65-68-224.red.bezeqint.net. [109.65.68.224]) by smtp.gmail.com with ESMTPSA id f187sm3559789wmf.15.2016.07.29.08.32.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jul 2016 08:32:41 -0700 (PDT) From: Yaron Sheffer To: IETF Security Directorate , The IESG , draft-ietf-dhc-topo-conf.all@tools.ietf.org Message-ID: Date: Fri, 29 Jul 2016 18:32:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] Repeat SecDir review: draft-ietf-dhc-topo-conf-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 15:32:46 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes current practices for configuring DHCP in complex network scenarios, where the goal is to allow servers to configure DHCP clients differently depending on the client's network location. Summary The document is ready for publication. Details My previous SecDir review of -08 lamented the then short and essentially useless Security Considerations section. This section has now been significantly extended and as far as I can determine, is now at an appropriate level for this draft. I would like to thank the authors for addressing my comments! From nobody Fri Jul 29 09:17:33 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0588812D7F2; Fri, 29 Jul 2016 09:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibHql1aMy3Ms; Fri, 29 Jul 2016 09:17:26 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCF712D72A; Fri, 29 Jul 2016 09:17:25 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id i5so159098116wmg.0; Fri, 29 Jul 2016 09:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=cvCv4iTyyhptNleSfKCRb7EJdNvOBvJK79yuvCZTx/8=; b=KBEDvihumN8WyfwGHKuStze+h3vCg9hKlY1khebd8PtyCjkjfgjIjfRpFy1pQdxTiQ D8iyn8x45wJdkYavA/JsHwvDMN9T70tDVo+VrjRud+L6IXdpj6XeIccgcn47Wxqo6PXz oqTL2hom4160YuxCuea3igA6K5rBcxGcNqmWT4CrvjghNmgZzc/QasfyEVRcydtbCnnJ WHIAV80m3WaxwCmiv0O0S64gCAK35XZbXwwI/s/cTdcc0fovfLrXl1cIESZstxP1MkUx hlP+FEvswTy0g2B6EpdyjLsALHkqU+a9iz2SNPwMafXcGXcWKatwGl+09mPvVHI12iH9 /s9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=cvCv4iTyyhptNleSfKCRb7EJdNvOBvJK79yuvCZTx/8=; b=Z/5QuxfgolNKgDxBApvrSSdjQ6ABvmQ9jQkpOHcKyfg2YyLFPUfBCI3a+xabvieU8G Bt3RIHS//HOqWf0yuaCn1QUmAzIYKHBXPoXOOX1WnIA9VPBDK2nT6wOy5cbt5DV7Hakt VBA1anIa6Nm8sOSABKJAnGyARHdgjKuyJz09AMBS4gAFjHBT/b2/SxX7KKT7KsmQov+4 z0G1LkldE98iNMlFuWBvadwAE7pGYe2JbpWZXZzeSJnzXAj8PZsQbW0oEzR6GZd0tcSo tDAnVFCdxQODj2q88vL83jSBPbR7Zm6m6i3oUfAnLMT55kwJiduudt0HwhQv5y+VJwKd piZw== X-Gm-Message-State: AEkoouue/YMVHmUubDEo2ufP7PBMpB3LqrrPVa8jU9r6WCgvoUKK+XzDYwfvDk2PLCQuvQ== X-Received: by 10.28.163.199 with SMTP id m190mr1975155wme.5.1469809044454; Fri, 29 Jul 2016 09:17:24 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-177-218-223.red.bezeqint.net. [79.177.218.223]) by smtp.gmail.com with ESMTPSA id 17sm3765323wmf.6.2016.07.29.09.17.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jul 2016 09:17:23 -0700 (PDT) From: Yaron Sheffer To: IETF Security Directorate , draft-ietf-trill-channel-tunnel.all@tools.ietf.org, The IESG Message-ID: Date: Fri, 29 Jul 2016 19:17:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] Repeat SecDir review of draft-ietf-trill-channel-tunnel-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 16:17:28 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines a way to tunnel arbitrary frames of related control protocols within the TRILL "channel". Most of the document (and the focus of this review) is about security of this tunnel. Summary The document is ready for publication. Details My early review of -07 contained numerous comments, which were all addressed by the authors. I would like to thank them for greatly improving the document's treatment of security issues.