From nobody Tue Oct 3 09:29:53 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED2E134F39 for ; Tue, 3 Oct 2017 09:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 k0UShWwg_fit for ; Tue, 3 Oct 2017 09:29:45 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354EB134F3E for ; Tue, 3 Oct 2017 09:29:39 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 22C4588119 for ; Tue, 3 Oct 2017 09:29:39 -0700 (PDT) Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E00213218010 for ; Tue, 3 Oct 2017 09:29:38 -0700 (PDT) To: "dns-privacy@ietf.org" From: Brian Haberman Message-ID: <96833993-7021-ad00-b3cf-5eac4728d2b0@innovationslab.net> Date: Tue, 3 Oct 2017 12:29:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6RxUhLb6lwJBd3pm5iTBhIVnpLqR9053i" Archived-At: Subject: [dns-privacy] IETF 100 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 16:29:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6RxUhLb6lwJBd3pm5iTBhIVnpLqR9053i Content-Type: multipart/mixed; boundary="K6EOd1bRn1OLOfvTor1xkJR1VCEUuc7bX"; protected-headers="v1" From: Brian Haberman To: "dns-privacy@ietf.org" Message-ID: <96833993-7021-ad00-b3cf-5eac4728d2b0@innovationslab.net> Subject: IETF 100 --K6EOd1bRn1OLOfvTor1xkJR1VCEUuc7bX Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable All, The chairs have decided that we do not need a session in Singapore. There are some items (e.g., draft-ietf-padding-policy) that would benefit from on-list discussions, but not enough content to justify a meeting slot. Please consider yourself encouraged to participate in the DNS-over-HTTP discussions given its relevance to this WG's charter. Regards, Brian & Tim --K6EOd1bRn1OLOfvTor1xkJR1VCEUuc7bX-- --6RxUhLb6lwJBd3pm5iTBhIVnpLqR9053i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZ07rxAAoJEGjWPJxT0YthdGoP/R3beW7Wx03EgqTXQSU2TA7Z jN3wScIhBbhMvo5FbIY/t7yOnkNfrPajXlY1TaTZi2fjLywOiDwQZ2wZ2dIYrP6v l3x8l3G5DTmT+HOtCJODdBPYf+r5TFn4AneiF3wTxjlxXLOA+paseXlCyudNJ/ev WU/KRvPRbWNnqp85zSFw+Jg2sFa5Uv+r+04+/E+IngzcuDGUUEeFgcRwmkeD1heq 4iFWmmR2Yb4mE5RiTBxzFv/LB/UUO/KNpN3h9qdZUidukiEEbOj/mfBgtksMRnzS g0fgCXRSip8LhXwLjc2H9oZr/Evt8HmGwn7gTHCz278RBx0cWVsAUahwyPlyhI64 b+1vjFOGvaED8CBUadas/6DLbUr8FhuyhQ4T2zZcaX/1QyK0P1N7FomIs2THUpY9 onX5G4lNsfG3uJVqx7q3Q3E3Nag6gNqpPCSMu9BPRo6I6K5gCz6i8N8pcMw+LU+h 4vdiXuHRqelxWBZ0pVp8N+vsj0Nfcafr+iihZ0EF6xG6ZkX+mEXTYDpR1rglQLlo fXhK84vKkg2OpdAgLgZ+dT4urzMlKSg38aEMXi9/Y+Pwpp0zzVL3RIvfpaSfhKBc W692OtESC0IMGJuiFjuinHkI90FuCqrjptTh7I73OeagWR4MYP5gpRWKgJ7WMXWe lLoerZ1PNd8zrCL65Y6n =HJkJ -----END PGP SIGNATURE----- --6RxUhLb6lwJBd3pm5iTBhIVnpLqR9053i-- From nobody Fri Oct 6 10:01:22 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3440134B1B for ; Fri, 6 Oct 2017 10:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 Fmv3cHCLD7As for ; Fri, 6 Oct 2017 10:01:19 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 08F61134AD1 for ; Fri, 6 Oct 2017 10:00:58 -0700 (PDT) Received: from [2001:b98:204:102:fffa::1b] (port=56265) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1e0VzZ-00071C-Ij; Fri, 06 Oct 2017 18:00:56 +0100 From: Sara Dickinson Message-Id: <61E43C98-DFDB-4D0C-B37C-97A479948765@sinodun.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A7CA3DEB-3ADA-4D1B-AF8E-28B76AE7966A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 6 Oct 2017 18:00:49 +0100 In-Reply-To: <19F54F2956911544A32543B8A9BDE0759905AED2@NICS-EXCH2.sbg.nic.at> Cc: "dns-privacy@ietf.org" To: Alexander Mayrhofer References: <19F54F2956911544A32543B8A9BDE0759905AED2@NICS-EXCH2.sbg.nic.at> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [dns-privacy] Version -02 of draft-ietf-padding-policy X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 17:01:22 -0000 --Apple-Mail=_A7CA3DEB-3ADA-4D1B-AF8E-28B76AE7966A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Sep 2017, at 15:23, Alexander Mayrhofer = wrote: >=20 > Hello everyone, > =20 > =20 > I=E2=80=99ve just posted version -02 of the Padding Policy draft. This = version consideres comments from the Prague WG sesson and subsequent = mailing list discussions. Specifically, the major changes are: > =20 > - Changed Document status to =E2=80=9EExperimental=E2=80=9C > - Added =E2=80=9EMaximum Length=E2=80=9C padding strategy > - Reworded =E2=80=9EBlock Length=E2=80=9C strategy > - Added text with RFC2119 language to each strategy > - Provided justification for the recommended strategy. > =20 > Please review and comment. I=E2=80=99m happy to talk about it in = Singapore, and i think we should be pretty close to WGLC=E2=80=98ing it = out of our eyes after that :) Hi Alex,=20 Thanks for this update - I think this is taking shape now. I have a few = comments and a bunch of nits: Comments: - I wonder if it is worth a comment about the fact padding doesn=E2=80=99t= obfuscate that the packet is DNS traffic? The draft clearly talks only = about hampering size-based correlation attacks but it just struck me = that hiding the fact the traffic is DNS (for example, if port 443 were = used) is a non-goal for this document.=20 - I suspect the data used in the analysis didn=E2=80=99t include many = (if any) DNSSEC validating clients=E2=80=A6 If they become more common = then I would expect the response size padding to alter. Perhaps add a = comment to this effect in section 5? - Section 4.5: =E2=80=9CMaximum (and eventually minimum) padding = length.=E2=80=9D Why =E2=80=98eventually=E2=80=99 minimum? Do you mean = implicitly? - Section 4.6: s/Number of size of the set of Block Lengths/Number of = and the values for the set of Block Lengths/ ? - Section 5: List item (2). Would it be useful to be more explicit here = and say something like=20 =E2=80=9CIf a Server receives a query that includes the EDNS(0) padding = option, it MUST pad the corresponding response [RFC7830] and SHOULD pad = the response to a multiple of 468 octects." Nits - Introduction: Reference to RFC7830 at the start of the first sentance = is repeated. - I see EDNS, EDNS0 and EDNS(0) used in different places in the = document. Perhaps use EDNS(0) throughout? - Section 4: Full stop missing at the end of the first sentence. - Sections 4.2 and 4.5: Full stop missing at the end of the = =E2=80=98Advantages=E2=80=99 statement. - Section 4.2: s/of padding easily discoverable/of padding is easily = discoverable/ - Section 4.2 "padding hence must be assumed=E2=80=9D Remove hence? - Section 4.5: s/a good source of (pseudo) keeping/a good source of = (pseudo) random numbers which can keep up/ - Section 4.6: s/a few block lenght=E2=80=99es/a few block length = values/ - Section 4.6: s/selection of block lenght/selection of block length/ - Section 4.6: last sentence s/require further/requires further/ - Section 8: s/the chose policy/the chosen policy/ - Section 8: s/A clients carefully chosen Padding policy/A clients' = carefully chosen Padding policy/ - Section 8: s/server does apply an inffective (or no)/ server chooses = to apply an ineffective (or no)/ - Section 8: s/want to chose a DNS server/want to choose a DNS server/ Sara.=20= --Apple-Mail=_A7CA3DEB-3ADA-4D1B-AF8E-28B76AE7966A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 28 Sep 2017, at 15:23, Alexander Mayrhofer <alexander.mayrhofer@nic.at> wrote:

Hello everyone,
 
 
I=E2=80=99ve just posted = version -02 of the Padding Policy draft. This version consideres = comments from the Prague WG sesson and subsequent mailing list = discussions. Specifically, the major changes are:
 
-          Changed Document status to = =E2=80=9EExperimental=E2=80=9C
-          Added =E2=80=9EMaximum Length=E2=80=9C padding = strategy
-          Reworded =E2=80=9EBlock Length=E2=80=9C = strategy
-          Added text with RFC2119 language to each = strategy
-          Provided justification for the recommended = strategy.
 
Please review and comment. = I=E2=80=99m happy to talk about it in Singapore, and i think we should = be pretty close to WGLC=E2=80=98ing it out of our eyes after that :) =


Hi Alex, 

Thanks for this update - I think this is taking = shape now. I have a few comments and a bunch of nits:

Comments:
- I wonder if it is = worth a comment about the fact padding doesn=E2=80=99t obfuscate that = the packet is DNS traffic? The draft clearly talks only about hampering = size-based correlation attacks but it just struck me that hiding the = fact the traffic is DNS (for example, if port 443 were used) is a = non-goal for this document. 

- I suspect the data used in the = analysis didn=E2=80=99t include many (if any) DNSSEC validating = clients=E2=80=A6 If they become more common then I would expect the = response size padding to alter. Perhaps add a comment to this effect in = section 5?

- = Section 4.5: =E2=80=9CMaximum (and eventually minimum) padding = length.=E2=80=9D Why =E2=80=98eventually=E2=80=99 minimum? Do you mean = implicitly?

- = Section 4.6: s/Number of size of the set of Block Lengths/Number of and = the values for the set of Block Lengths/ ?

- Section 5: List item (2). Would it be = useful to be more explicit here and say something like 
=E2=80=9CIf a Server receives a query that includes the = EDNS(0) padding option, it MUST pad the corresponding response [RFC7830] = and SHOULD pad the
        = response to a multiple of 468 octects."

Nits
- = Introduction: Reference to RFC7830 at the start of the first sentance is = repeated.
- I see EDNS, EDNS0 and EDNS(0) used in = different places in the document. Perhaps use EDNS(0) = throughout?
- Section 4: Full stop missing at the = end of the first sentence.
- Sections 4.2 and 4.5: =  Full stop missing at the end of the =E2=80=98Advantages=E2=80=99 = statement.
- Section 4.2: s/of padding easily = discoverable/of padding is easily discoverable/
- = Section 4.2 "padding hence must be assumed=E2=80=9D  Remove = hence?
- Section = 4.5: s/a good source of = (pseudo) keeping/a good source of = (pseudo) random numbers which can keep up/
- Section 4.6: s/a few block lenght=E2=80=99es/a few block = length values/
- Section 4.6: s/selection = of block lenght/selection of block length/
- Section 4.6: last sentence s/require further/requires = further/
- Section 8: s/the chose = policy/the chosen policy/
- Section 8: s/A clients = carefully chosen Padding policy/A clients' carefully chosen Padding = policy/
- Section 8: s/server = does apply an inffective (or no)/ server chooses to apply an ineffective = (or no)/
- Section = 8: s/want to chose a DNS server/want to choose a DNS = server/

Sara. 
= --Apple-Mail=_A7CA3DEB-3ADA-4D1B-AF8E-28B76AE7966A-- From nobody Mon Oct 9 10:13:36 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D6B1346DA for ; Mon, 9 Oct 2017 10:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 6OKobATfxW46 for ; Mon, 9 Oct 2017 10:13:33 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 536E7133087 for ; Mon, 9 Oct 2017 10:13:33 -0700 (PDT) Received: from [2a02:8010:6126:0:bc1e:51ed:1dd3:320a] (port=54469) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1e1bcR-00029o-Sd for dns-privacy@ietf.org; Mon, 09 Oct 2017 18:13:32 +0100 From: Sara Dickinson Content-Type: multipart/alternative; boundary="Apple-Mail=_2BB6B5B7-498B-4BF5-AFAF-317F95115242" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Mon, 9 Oct 2017 18:13:30 +0100 To: dns-privacy@ietf.org X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: [dns-privacy] Call for Papers: NDSS Workshop on DNS Privacy 2018 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 17:13:35 -0000 --Apple-Mail=_2BB6B5B7-498B-4BF5-AFAF-317F95115242 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 With permission =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 Hi All,=20 Please consider submitting to the NDSS DNS Privacy Workshop 2018: = Increasing Usability and Decreasing Traceability. Call for papers: https://easychair.org/cfp/dprive2018 = Workshop Website: = https://dnsprivacy.org/wiki/display/DNSPWS/DNS+Privacy+Workshop = Location and Important Dates ----------------------------------------- Workshop Location: San Diego, CA, USA Workshop date: 18th Feb 2018 (co-located with NDSS 2018) Abstract submissions: 1st Dec 2017 anywhere-on-earth Paper submission: 8th Dec 2017 anywhere-on-earth Notifications and invitations to present at the workshop: 13th Jan 2018 Submissions may be new papers, papers already published, Short Papers, = or Position Papers. Also, please contact the TPC chairs if you want to suggest a panel. Allison, Sara and Melinda. --- *Workshop on DNS Privacy 2018* Background ----------------- DNS Privacy has been a growing concern of the IETF and others in the = Internet engineering community for the last few years. Almost every = activity on the Internet starts with a DNS query (and often several). * Those queries can reveal not only what websites an individual visits = but also metadata about other services such as the domains of email = contacts or chat services. =E2=80=A8 * Whilst the data in the DNS is public, individual DNS transactions made = by an end user should not be public.=E2=80=A8 * Today, however DNS queries are sent in clear text (using UDP or TCP) = which means passive eavesdroppers can observe all the DNS lookups = performed.=E2=80=A8 * The DNS is a globally distributed system that crosses international = boundaries and often uses servers in many different countries in order = to provide resilience.=E2=80=A8 * It is well known that the NSA used the MORECOWBELL tool to perform = mass surveillance of DNS traffic, and other surveillance techniques = involving DNS almost certainly are in play today. =E2=80=A8 * Some ISPs embed user information (e.g. a user ID or MAC address) = within DNS queries that go to the ISP=E2=80=99s resolver in order to = provide services such as Parental Filtering. This allows for = fingerprinting of individual users.=E2=80=A8 * Some CDNs embed user information (e.g. client subnets) in queries from = resolvers to authoritative servers (to geo-locate end users). This = allows for correlation of queries to particular subnets.=E2=80=A8 * Some ISPs log DNS queries at the resolver and share this information = with third-parties in ways not known or obvious to end users. The IETF's DPRIVE Working Group has taken initial protocol steps to = address these concerns (with much of the early work focussing on the = stub to resolver problem), publishing DNS Privacy Considerations (RFC = 7626), Specification for DNS over Transport Layer Security (RFC 7858), = and The EDNS(0) Padding Option (RFC 7830), and DNS Query Name = Minimisation to Improve Privacy (RFC 7816). However because of the great = diversity of the DNS ecosystem, and the pervasive role of DNS and domain = names in Internet applications and security, much is not fully = understood or resolved. =20 =20 The goal of this workshop is to bring together privacy and Internet = researchers with a diversity of backgrounds and views, to identify = promising long-term mitigations of the broad space of DNS privacy risks. Call for Submissions ----------------------------- We welcome submissions in the form of research papers, short papers, or = draft presentations, concerning all aspects of the threats, the = protocols, and future design spaces, of DNS privacy or the privacy of = adjacent protocols. Usability, traceability, measurement and analytical = evaluations are particularly encouraged.=20= --Apple-Mail=_2BB6B5B7-498B-4BF5-AFAF-317F95115242 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
With permission
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94


Hi All, 

Please consider submitting to the NDSS = DNS Privacy Workshop 2018: Increasing Usability and Decreasing = Traceability.

Call for papers: https://easychair.org/cfp/dprive2018
Workshop Website: https://dnsprivacy.org/wiki/display/DNSPWS/DNS+Privacy+Workshop=


Location and Important Dates
-----------------------------------------
Workshop Location: San Diego, CA, USA
Workshop = date: 18th Feb 2018 (co-located with NDSS 2018)

Abstract submissions: 1st Dec 2017 = anywhere-on-earth
Paper submission: 8th Dec 2017 = anywhere-on-earth
Notifications and invitations to present = at the workshop: 13th Jan 2018

Submissions may be new papers, papers = already published, Short Papers, or
Position Papers. =  Also, please contact the TPC chairs if you want to
suggest a panel.

Allison, Sara and Melinda.



---

*Workshop on DNS Privacy = 2018*

Background
-----------------
DNS Privacy has been a growing concern of the IETF and others = in the Internet engineering community for the last few years. =  Almost every activity on the Internet starts with a DNS query = (and often several).

*= Those queries can reveal not only what websites an individual visits = but also metadata about other services such as the domains of email = contacts or chat services. =E2=80=A8
* Whilst the data in the DNS is public, individual DNS = transactions made by an end user should not be public.=E2=80=A8
* Today, however DNS queries are sent = in clear text (using UDP or TCP) which means passive eavesdroppers = can observe all the DNS lookups performed.=E2=80=A8
* The DNS is a globally distributed = system that crosses international boundaries and often uses servers = in many different countries in order to provide resilience.=E2=80=A8
* It is well known that the NSA used = the MORECOWBELL tool to perform mass surveillance of DNS traffic, = and other surveillance techniques involving DNS almost certainly = are in play today.  =E2=80=A8
* = Some ISPs embed user information (e.g. a user ID or MAC address) within = DNS queries that go to the ISP=E2=80=99s resolver in order to = provide services such as Parental Filtering. This allows for = fingerprinting of individual users.=E2=80=A8
* Some CDNs embed user information (e.g. client subnets) in = queries from resolvers to authoritative servers (to geo-locate end = users). This allows for correlation of queries to particular = subnets.=E2=80=A8
* Some ISPs log = DNS queries at the resolver and share this information with = third-parties in ways not known or obvious to end users.

The IETF's DPRIVE = Working Group has taken initial protocol steps to address these = concerns (with much of the early work focussing on the stub = to resolver problem), publishing DNS Privacy Considerations (RFC = 7626), Specification for DNS over Transport Layer Security (RFC = 7858), and The EDNS(0) Padding Option (RFC 7830), and DNS Query = Name Minimisation to Improve Privacy (RFC 7816). However because of = the great diversity of the DNS ecosystem, and the pervasive role of DNS = and domain names in Internet applications and security, much is not = fully understood or resolved.  
 
The goal of this workshop is to bring together privacy and = Internet researchers with a diversity of backgrounds and views, to = identify promising long-term mitigations of the broad space of DNS = privacy risks.

Call for Submissions
-----------------------------
We welcome = submissions in the form of research papers, short papers, or = draft presentations, concerning all aspects of the threats, the = protocols, and future design spaces, of DNS privacy or the privacy = of adjacent protocols.  Usability, traceability, measurement = and analytical evaluations are particularly = encouraged. 
= --Apple-Mail=_2BB6B5B7-498B-4BF5-AFAF-317F95115242-- From nobody Sun Oct 22 23:14:48 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA6413DCB7 for ; Sun, 22 Oct 2017 23:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 cX5zJpQusHHX for ; Sun, 22 Oct 2017 23:14:43 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 5319C13DCB2 for ; Sun, 22 Oct 2017 23:14:42 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at with XWall v3.53 ; Mon, 23 Oct 2017 08:14:40 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0361.001; Mon, 23 Oct 2017 08:14:37 +0200 From: Alexander Mayrhofer To: "dns-privacy@ietf.org" Thread-Topic: dprive (bar) BoF? Thread-Index: AdNLxef89ZEJhpV1Q8mT+nlmvYbfwA== Date: Mon, 23 Oct 2017 06:14:36 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: multipart/alternative; boundary="_000_19F54F2956911544A32543B8A9BDE075990801B6NICSEXCH2sbgnic_" MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Subject: [dns-privacy] dprive (bar) BoF? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 06:14:48 -0000 --_000_19F54F2956911544A32543B8A9BDE075990801B6NICSEXCH2sbgnic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey all, since we're not scheduled for a session in Singapore - would anybody be int= erested in meeting up for a bar BoF during the meeting? eg. a lunch break? best, Alex --_000_19F54F2956911544A32543B8A9BDE075990801B6NICSEXCH2sbgnic_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey all,

 

since we’re not scheduled= for a session in Singapore – would anybody be interested in meeting = up for a bar BoF during the meeting? eg. a lunch break?

 

best,

Alex

 

--_000_19F54F2956911544A32543B8A9BDE075990801B6NICSEXCH2sbgnic_-- From nobody Sun Oct 22 23:43:27 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5E313E010 for ; Sun, 22 Oct 2017 23:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 mCEo5DXERXgj for ; Sun, 22 Oct 2017 23:43:23 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id CFAF413DFFA for ; Sun, 22 Oct 2017 23:43:22 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 5C1EDF99F; Mon, 23 Oct 2017 02:43:21 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id EA368204B0; Mon, 23 Oct 2017 02:43:13 -0400 (EDT) From: Daniel Kahn Gillmor To: Alexander Mayrhofer , "dns-privacy\@ietf.org" In-Reply-To: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> Date: Mon, 23 Oct 2017 02:43:13 -0400 Message-ID: <87inf6z7ni.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dns-privacy] dprive (bar) BoF? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 06:43:26 -0000 On Mon 2017-10-23 06:14:36 +0000, Alexander Mayrhofer wrote: > since we're not scheduled for a session in Singapore - would anybody > be interested in meeting up for a bar BoF during the meeting? eg. a > lunch break? I'd be interested. --dkg From nobody Sun Oct 22 23:49:40 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A7F13E0D9 for ; Sun, 22 Oct 2017 23:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 M8jLLa5SEkog for ; Sun, 22 Oct 2017 23:49:35 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 AF65013E0D6 for ; Sun, 22 Oct 2017 23:49:35 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id p87so16395088pfj.3 for ; Sun, 22 Oct 2017 23:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=mNeoOmzJ2t2Inc/Ofi+jHxVlINK4hfYnxgUY0NuR7O4=; b=Hxf6DQJe5n9phfMXCqUNoJdX5ckBUOvfj5YV84m1hbYxAwpWMeKqp1pzEhkl6UMf/R JSY/3BeSlCw8JW0uT8S/gJM/jGSu4NGzZOFCQnzsDHdD/Aj8z2o3wfZN6XWHzA4RGWLu avcP5ijOepiM4t2KOydHcA4HsHAMR9zemfQuANjJ/3Yb9PxIBsUUMJoqrbj1lXcyRT4/ fd0SRWRPPnn5lt8FKuPh24+otGY6+PD2ymgMFPDqTWFLyC+YFauR4+lehtbjM8Cp/fX4 9X+UfjcFgHExuHELyyZMIEkcIhuB+aiMbr/Wlx/sDBpvcb8+054C9Ku3RoaUaMuZ+MHQ MwHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=mNeoOmzJ2t2Inc/Ofi+jHxVlINK4hfYnxgUY0NuR7O4=; b=TW/QkQTXFS/GLZLfAnMmCscBuF1HZ5+g83+fc4gmROf8IUN/DPzpfQRNpcv+tXd2bb DdMDFK06SqCSWoYh8YqyumQUQnqEkJSsysXZGFCgZXaeRkq6MZpsM2prnT/EdI8iQqDn lZC8Np40VrIikq2Do1Uuwk4flP4N5Ddx567ep/8aJjsqkHEWBbnGocPGBah1I8SGMHIy Glvzwp1sfJjkvUypv6UJVp6rIwVyiAW9I/FeI9QwYaKicw7MrwGUnsHmldTtqJ+OROIW oEKsvY8o8GRoRTSnR0TYoeJlGzJkA6Q6wxJ/WOWJkIk4+CgK8ftrIYCkWbj8MXKIc0M7 zItg== X-Gm-Message-State: AMCzsaWi6cJGull7c7E3LUXcq3nSz4W+OiV67ADtw4aU5od/IHNlOzeP 1KclLQSYhQuuXHP43Br70SqpeUy4 X-Google-Smtp-Source: ABhQp+SCJmN+5oOL+7+kRxHPYFJ/++8AVCvIoFtLInKQsRCmS3w2eQzvUWFfh9w2vMkuWhuPVlCWhQ== X-Received: by 10.101.80.3 with SMTP id f3mr11197528pgo.109.1508741374581; Sun, 22 Oct 2017 23:49:34 -0700 (PDT) Received: from aspen.local (209-112-147-75-radius.dynamic.acsalaska.net. [209.112.147.75]) by smtp.gmail.com with ESMTPSA id z127sm10947816pfb.63.2017.10.22.23.49.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 23:49:33 -0700 (PDT) To: dns-privacy@ietf.org References: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> From: Melinda Shore Message-ID: <336f3434-e3e0-9ae3-ca67-b2611ae210bc@gmail.com> Date: Sun, 22 Oct 2017 22:49:30 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FsAxunV3VHOBSOoqFdvqjnDgkLEcauo4P" Archived-At: Subject: Re: [dns-privacy] dprive (bar) BoF? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 06:49:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FsAxunV3VHOBSOoqFdvqjnDgkLEcauo4P Content-Type: multipart/mixed; boundary="MoaIBj1LufV5JhbRIS0hsDrIE7NxmDHda"; protected-headers="v1" From: Melinda Shore To: dns-privacy@ietf.org Message-ID: <336f3434-e3e0-9ae3-ca67-b2611ae210bc@gmail.com> Subject: Re: [dns-privacy] dprive (bar) BoF? References: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> --MoaIBj1LufV5JhbRIS0hsDrIE7NxmDHda Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/22/17 10:14 PM, Alexander Mayrhofer wrote: > since we=92re not scheduled for a session in Singapore =96 would anybod= y be > interested in meeting up for a bar BoF during the meeting? eg. a lunch > break? I'd be interested. What topics do you have in mind? Also, while I'm always up for the bar, there's also the possibility of signing up for a side meeting room (see https://mailarchive.ietf.org/arch/msg/ietf/DMpUDd_Xp1OetPENwzgBXJXq3= VE) Melinda --MoaIBj1LufV5JhbRIS0hsDrIE7NxmDHda-- --FsAxunV3VHOBSOoqFdvqjnDgkLEcauo4P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ7ZD7AAoJELiGRpM6HoEuKFIP/iLZs7ruXZJ4y2Rp3oZSxbB8 IJpDF9zMwEUW3mpeaADS7w7uNs/r9xgHt+1z92uHghf1hX55InqClQiTY7BJDy6Y oMJy2/y6QgRHkre79FIg1bhXo6ccTba4zMioky/HxE/BAr5PjBcbPQUuPp2kc2em BDzaT/px5cSUAT1lKaKHcawueZHp4qOcAICgMJO+QPA0+XBjZ3EbkKf2C5R06Hg/ Ga77fWR/tX5ex1eyfCOO0jr7vskwUmnvRW3z2Co77TBlVquVISJOjy1Ssb5h/5Mk 6qBOB+1TVohYvLi6Ut3cZuGEkYatwaNZBdigCNPfwZLEg7v8bGCHGBlzJVutt/Uq DwbnDU8/bMVK5PSml3JoRTQuNZOQnRoZow/0aRWlVs/SSl1VscN7vgCG2CrmlHg8 3oP9lVI2r/IanChoLqSt5jG/vBUiq5mrq+M/V0o8W4Hjb+5NYe/O1t/t+1riY3sc LltcZDv30egCfRoHsrOm0nr00AMdHs5LzipFkyj1YQKypKEbhu+pwiIt4WhLwysB ue3YiNlzITwcURuQTYUtpFFiD0egjjuKWJtqacY/UZtPQISAkmXhGuB8YBFQ2UXu H3LZqQn9l7VKHgmdT8Bo09/p5IPXcD2FhIGAayDjc91NC/ZFajjTBk9iIGFO/dnF GFbP4rN8BHQSLnfGZJTz =+QTh -----END PGP SIGNATURE----- --FsAxunV3VHOBSOoqFdvqjnDgkLEcauo4P-- From nobody Sun Oct 22 23:57:50 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0074413E18E for ; Sun, 22 Oct 2017 23:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wisser.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 3rmlvVFngqj5 for ; Sun, 22 Oct 2017 23:57:47 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 2899313E17D for ; Sun, 22 Oct 2017 23:57:47 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id h34so12145597uaa.6 for ; Sun, 22 Oct 2017 23:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisser.se; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=0c2YHjj4R8xd05L1vKzePuJHVObO7DomiT9KcFrt4Ds=; b=3/VtoMxy0pC/K+RvEmsAu1ZBbj2KBHE/d4hbSzGXKfaLIZvRsKqgW9Wpc74ZSSFi82 +q1HFw+rcZDrb6eLQSCGLQjne8IahMbSDgQTjzOB3D+2B3u0FQl6+K6N0Z/pOWKC6/f7 hDrVSmezo9iF/xRVM9GMXBJxLP/i74sHrYvyp6co2mFVnHJCmlq1pVa39p86LrH91UxR u8CR27GeUsk52mXgQLwFN+kDlWreSqZalnBcCQGIdT3XyRUVldW/ZzxBMYSHJ0ztC5Oa KAmeoRfOYcWEGL7JO+O7DYVCRmPUA3TJpnEDLygxOXH+JbzOyPZkqsj1SqHF4+Ucalg8 zlNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=0c2YHjj4R8xd05L1vKzePuJHVObO7DomiT9KcFrt4Ds=; b=V9NQBvJWTeONhiijGKZ3apS4j4hCe/smpcWip91KErGrbGFiKcwg/Xmj2jAf5nGZSA rNdA1wwSsL15zAgS24mZ5KmtlIRZAfKroPAtZkLbwSN2Kb6LKk2Ng4dmZKr5fYALccnc 9yAI/fRaSe9YXzVOoLcQziSGhMceTSW09KD3Q3QK9beWnwJ8jSkO/4zPtAHt7f3aE+1e jTeqQphN2VXeDY6dXVmlSbtJXndAMuJMGjM8Fyyjigsc2JwXWWng3PUY3mKiv6bgcsWH Dz/S06Nv/0RBHlVLIyIhq4N+xqwOGHd95lKcPVpXRDRNHJkuYw8PLunYmx4AFttRKhR7 KCnQ== X-Gm-Message-State: AMCzsaUEQIK+TiBROSZflugQADy9TOIuwoBKEqhRx+BxiDKLOEL9NO+2 q8I1+b6MfXUGbrzfE1OxY/w30U3D2jq1rSdK+EBWlKZs X-Google-Smtp-Source: ABhQp+ROH/mJOAzQm4O9zStNmABaB5l9s7Evxdw4a6upK9K/fKwA/xFJ5PcT7s0VF+kRXrD/V6KGVIN5F71DHU4LeR4= X-Received: by 10.176.74.139 with SMTP id s11mr9037136uae.129.1508741865789; Sun, 22 Oct 2017 23:57:45 -0700 (PDT) MIME-Version: 1.0 References: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> From: Ulrich Wisser Date: Mon, 23 Oct 2017 06:57:35 +0000 Message-ID: Cc: dns-privacy@ietf.org Content-Type: multipart/alternative; boundary="f403045f90a4f7eef1055c3156a2" Archived-At: Subject: Re: [dns-privacy] dprive (bar) BoF? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 06:57:49 -0000 --f403045f90a4f7eef1055c3156a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Mon, Oct 23, 2017, 08:14 Alexander Mayrhofer wrote: > Hey all, > > > > since we=E2=80=99re not scheduled for a session in Singapore =E2=80=93 wo= uld anybody be > interested in meeting up for a bar BoF during the meeting? eg. a lunch > break? > > > > best, > > Alex > > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > --=20 Ulrich Wisser ulrich@wisser.se --f403045f90a4f7eef1055c3156a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1

On Mon, Oct 23, 2017,= 08:14 Alexander Mayrhofer <alexander.mayrhofer@nic.at> wrote:

Hey all,

=C2=A0

since we=E2=80=99re not schedul= ed for a session in Singapore =E2=80=93 would anybody be interested in meet= ing up for a bar BoF during the meeting? eg. a lunch break?

=C2=A0

best,

Alex

=C2=A0

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.= org
https://www.ietf.org/mailman/listinfo/dns-privacy
--f403045f90a4f7eef1055c3156a2-- From nobody Mon Oct 23 00:08:16 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E80213E363 for ; Mon, 23 Oct 2017 00:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 Vg8AQCC8aYHK for ; Mon, 23 Oct 2017 00:08:13 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 B0EC513E360 for ; Mon, 23 Oct 2017 00:08:12 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at with XWall v3.53 ; Mon, 23 Oct 2017 09:08:10 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0361.001; Mon, 23 Oct 2017 09:08:05 +0200 From: Alexander Mayrhofer To: Melinda Shore , "dns-privacy@ietf.org" Thread-Topic: [dns-privacy] dprive (bar) BoF? Thread-Index: AdNLxef89ZEJhpV1Q8mT+nlmvYbfwP//6M8A///a11A= Date: Mon, 23 Oct 2017 07:08:04 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075990802EC@NICS-EXCH2.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> <336f3434-e3e0-9ae3-ca67-b2611ae210bc@gmail.com> In-Reply-To: <336f3434-e3e0-9ae3-ca67-b2611ae210bc@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Subject: Re: [dns-privacy] dprive (bar) BoF? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 07:08:14 -0000 Melinda Shore wrote: > I'd be interested. What topics do you have in mind? Primarily, i had in mind to gather feedback on draft-ietf-dprive-padding-po= licy. I'm the author, and it's the last remaining dprive WG document, so i'= d like to get this one out of the door. Besides that, i'd like to hear abou= t implementation status/progress as well as everyone's thoughts / guts feel= ings of the connection between dprive and the "DNS over forms of HTTP" effo= rts. > Also, while I'm always up for the bar, there's also > the possibility of signing up for a side meeting room > (see > https://mailarchive.ietf.org/arch/msg/ietf/DMpUDd_Xp1OetPENwzgBXJX > q3VE) Yeah, i didn't necessarily mean a "drinking" BoF, but since BoF in the cont= ext of the IETF is more a formal event, i took "Bar BoF" as a synonym as a = meeting that's not on the IETF agenda. Once there's enough interest, i'll l= ook into securing a room (though, rooms are typically only available during= evenings, i guess) best, Alex From nobody Mon Oct 23 02:47:47 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7756213F224 for ; Mon, 23 Oct 2017 02:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 LkwASzvRjPio for ; Mon, 23 Oct 2017 02:47:43 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 813431375C9 for ; Mon, 23 Oct 2017 02:47:43 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id r79so16675010wrb.13 for ; Mon, 23 Oct 2017 02:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OxfLarsBmNLlSd3QJR7gpjVNZTaYLKhWa3m5sodMaLQ=; b=uBymGZwQR3M22eVnt2nOTgwYWcWChydlNDzFQj5+no6DxK5tajk4RdPPL31jGsgYMF bHAbvWM3ilGvYHpgdT6d+hv1kgvUqWSpA0ld5zDd/tt5u8h2cdWsKfQapc4m2NqmjeX4 N+y7BVRa3zBecJFvBwGzZCzXO99srZjYyuvACea5cPVnlPhH77a9/e1/OYh7G+OtsRZj U0I4QPjcdgi34NQiLW72nicmL//Q0yfjgB0Zq3R4xkPb7CgV4jIe4QuvFIKV125elZQj BlNl6YMitd9U0zn5OCyibGfjfC55ypfVClCl+aqOgZaOqVl7bFHXY43srLhha0vOEdKW +iLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OxfLarsBmNLlSd3QJR7gpjVNZTaYLKhWa3m5sodMaLQ=; b=Daf0fdEmTkpxmEtbbFsDol176Vqd//i1WZZB72s8azFkm45NPfHQfaHkSA391yb+2w AUgN2Hbnj22Rw0PPmoQ05YkrDra/e3W+Aqxkr8cw3aNfR4VwtxALzqoeqp3iHCwgINZs fMdVJ+x2A5JrEq4NOzw/tEsZo6zxkszlQguwAZDf86SK718V3+htKFLRE8M1gxEF+pRg AbLdtw/I4YL1hvSAusECb+LU192yvcuIk7oZMVAYk7imTO6zDdlKKxv9X0squcpWQY0U BQmhEasLmwZ96ObXevdn9kw8qU9kbg7O7E6d1P/H0yo/83d9I8gzLHAw5B5hnnT99gNM 3IFw== X-Gm-Message-State: AMCzsaWsNzCySkaEaCuW5D0kxGXd/msudQ8cWQU++cQtKDXK0Dj0ja5b rg1jiaEjxsHfJ/Sr9nCQAfNhWcOxL2jLxPAyJpb5GQ== X-Google-Smtp-Source: ABhQp+RK/KoTd5yCH7NamYSE0JIZi5yONC58S0ascCI3gGqD6Iz0stY41wexwblY63t4ptMQV+3SFpekOUeVJIh1LxM= X-Received: by 10.223.164.18 with SMTP id d18mr11895719wra.232.1508752061917; Mon, 23 Oct 2017 02:47:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.60 with HTTP; Mon, 23 Oct 2017 02:47:41 -0700 (PDT) In-Reply-To: <19F54F2956911544A32543B8A9BDE075990802EC@NICS-EXCH2.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> <336f3434-e3e0-9ae3-ca67-b2611ae210bc@gmail.com> <19F54F2956911544A32543B8A9BDE075990802EC@NICS-EXCH2.sbg.nic.at> From: tjw ietf Date: Mon, 23 Oct 2017 05:47:41 -0400 Message-ID: To: Alexander Mayrhofer Cc: Melinda Shore , "dns-privacy@ietf.org" Content-Type: multipart/alternative; boundary="f403045f1664b46ddb055c33b687" Archived-At: Subject: Re: [dns-privacy] dprive (bar) BoF? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 09:47:45 -0000 --f403045f1664b46ddb055c33b687 Content-Type: text/plain; charset="UTF-8" +1 I'll be glad to organize. FYI, I saw this on Hacker News: https://twitter.com/igrigorik/status/922286961498476544 DNS over TLS coming to Android On Mon, Oct 23, 2017 at 3:08 AM, Alexander Mayrhofer < alexander.mayrhofer@nic.at> wrote: > Melinda Shore wrote: > > I'd be interested. What topics do you have in mind? > > Primarily, i had in mind to gather feedback on draft-ietf-dprive-padding-policy. > I'm the author, and it's the last remaining dprive WG document, so i'd like > to get this one out of the door. Besides that, i'd like to hear about > implementation status/progress as well as everyone's thoughts / guts > feelings of the connection between dprive and the "DNS over forms of HTTP" > efforts. > > > Also, while I'm always up for the bar, there's also > > the possibility of signing up for a side meeting room > > (see > > https://mailarchive.ietf.org/arch/msg/ietf/DMpUDd_Xp1OetPENwzgBXJX > > q3VE) > > Yeah, i didn't necessarily mean a "drinking" BoF, but since BoF in the > context of the IETF is more a formal event, i took "Bar BoF" as a synonym > as a meeting that's not on the IETF agenda. Once there's enough interest, > i'll look into securing a room (though, rooms are typically only available > during evenings, i guess) > > best, > Alex > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > --f403045f1664b46ddb055c33b687 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 =C2=A0

I'll be glad to organize.= =C2=A0

FYI, I saw this on Hacker News: =C2=A0=C2= =A0http= s://twitter.com/igrigorik/status/922286961498476544

DNS over TLS coming to Android
=
On Mon, Oct 23, 2017 at 3:08 AM, Alexander M= ayrhofer <alexander.mayrhofer@nic.at> wrote:
Melinda Shore wrote:
> I'd be interested.=C2=A0 What topics do you have in mind?

Primarily, i had in mind to gather feedback on draft-ietf-dprive-pad= ding-policy. I'm the author, and it's the last remaining dpriv= e WG document, so i'd like to get this one out of the door. Besides tha= t, i'd like to hear about implementation status/progress as well as eve= ryone's thoughts / guts feelings of the connection between dprive and t= he "DNS over forms of HTTP" efforts.

> Also, while I'm always up for the bar, there's also
> the possibility of signing up for a side meeting room
> (see
> https://mailarchive.ietf.org/= arch/msg/ietf/DMpUDd_Xp1OetPENwzgBXJX
> q3VE)

Yeah, i didn't necessarily mean a "drinking" BoF, but = since BoF in the context of the IETF is more a formal event, i took "B= ar BoF" as a synonym as a meeting that's not on the IETF agenda. O= nce there's enough interest, i'll look into securing a room (though= , rooms are typically only available during evenings, i guess)

best,
Alex

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-priv= acy

--f403045f1664b46ddb055c33b687-- From nobody Mon Oct 23 03:07:17 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7676E13F3AE for ; Mon, 23 Oct 2017 03:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 ZadFGTDnvzdo for ; Mon, 23 Oct 2017 03:07:10 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 0C02413F3AB for ; Mon, 23 Oct 2017 03:07:09 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at with XWall v3.53 ; Mon, 23 Oct 2017 12:07:07 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0361.001; Mon, 23 Oct 2017 12:07:01 +0200 From: Alexander Mayrhofer To: tjw ietf CC: Melinda Shore , "dns-privacy@ietf.org" Thread-Topic: [dns-privacy] dprive (bar) BoF? Thread-Index: AdNLxef89ZEJhpV1Q8mT+nlmvYbfwP//6M8A///a11CAAFbygP//2UnQ Date: Mon, 23 Oct 2017 10:07:01 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE07599081772@NICS-EXCH2.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> <336f3434-e3e0-9ae3-ca67-b2611ae210bc@gmail.com> <19F54F2956911544A32543B8A9BDE075990802EC@NICS-EXCH2.sbg.nic.at> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: multipart/alternative; boundary="_000_19F54F2956911544A32543B8A9BDE07599081772NICSEXCH2sbgnic_" MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Subject: Re: [dns-privacy] dprive (bar) BoF? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 10:07:16 -0000 --_000_19F54F2956911544A32543B8A9BDE07599081772NICSEXCH2sbgnic_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kLi4uDQoNClRoaXMgc2VlbXMgdG8gYmUgdGhlIOKAnmNvcmXigJwgb2YgdGhlIEROUy1vdmVy LVRMUyBjb21taXRzIGZvciBBbmRyb2lkcyAodG9vayBhIHdoaWxlIHRvIGZpbmQpOg0KDQpodHRw czovL2FuZHJvaWQtcmV2aWV3Lmdvb2dsZXNvdXJjZS5jb20vIy9jL3BsYXRmb3JtL3N5c3RlbS9u ZXRkLysvMzgwNTkzLw0KDQpFeGNpdGluZyENCg0KQWxleA0KDQoNClZvbjogdGp3IGlldGYgW21h aWx0bzp0ancuaWV0ZkBnbWFpbC5jb21dDQpHZXNlbmRldDogTW9udGFnLCAyMy4gT2t0b2JlciAy MDE3IDExOjQ4DQpBbjogQWxleGFuZGVyIE1heXJob2ZlciA8YWxleGFuZGVyLm1heXJob2ZlckBu aWMuYXQ+DQpDYzogTWVsaW5kYSBTaG9yZSA8bWVsaW5kYS5zaG9yZUBnbWFpbC5jb20+OyBkbnMt cHJpdmFjeUBpZXRmLm9yZw0KQmV0cmVmZjogUmU6IFtkbnMtcHJpdmFjeV0gZHByaXZlIChiYXIp IEJvRj8NCg0KKzENCg0KSSdsbCBiZSBnbGFkIHRvIG9yZ2FuaXplLg0KDQpGWUksIEkgc2F3IHRo aXMgb24gSGFja2VyIE5ld3M6ICAgaHR0cHM6Ly90d2l0dGVyLmNvbS9pZ3JpZ29yaWsvc3RhdHVz LzkyMjI4Njk2MTQ5ODQ3NjU0NA0KDQpETlMgb3ZlciBUTFMgY29taW5nIHRvIEFuZHJvaWQNCg0K T24gTW9uLCBPY3QgMjMsIDIwMTcgYXQgMzowOCBBTSwgQWxleGFuZGVyIE1heXJob2ZlciA8YWxl eGFuZGVyLm1heXJob2ZlckBuaWMuYXQ8bWFpbHRvOmFsZXhhbmRlci5tYXlyaG9mZXJAbmljLmF0 Pj4gd3JvdGU6DQpNZWxpbmRhIFNob3JlIHdyb3RlOg0KPiBJJ2QgYmUgaW50ZXJlc3RlZC4gIFdo YXQgdG9waWNzIGRvIHlvdSBoYXZlIGluIG1pbmQ/DQoNClByaW1hcmlseSwgaSBoYWQgaW4gbWlu ZCB0byBnYXRoZXIgZmVlZGJhY2sgb24gZHJhZnQtaWV0Zi1kcHJpdmUtcGFkZGluZy1wb2xpY3ku IEknbSB0aGUgYXV0aG9yLCBhbmQgaXQncyB0aGUgbGFzdCByZW1haW5pbmcgZHByaXZlIFdHIGRv Y3VtZW50LCBzbyBpJ2QgbGlrZSB0byBnZXQgdGhpcyBvbmUgb3V0IG9mIHRoZSBkb29yLiBCZXNp ZGVzIHRoYXQsIGknZCBsaWtlIHRvIGhlYXIgYWJvdXQgaW1wbGVtZW50YXRpb24gc3RhdHVzL3By b2dyZXNzIGFzIHdlbGwgYXMgZXZlcnlvbmUncyB0aG91Z2h0cyAvIGd1dHMgZmVlbGluZ3Mgb2Yg dGhlIGNvbm5lY3Rpb24gYmV0d2VlbiBkcHJpdmUgYW5kIHRoZSAiRE5TIG92ZXIgZm9ybXMgb2Yg SFRUUCIgZWZmb3J0cy4NCg0KPiBBbHNvLCB3aGlsZSBJJ20gYWx3YXlzIHVwIGZvciB0aGUgYmFy LCB0aGVyZSdzIGFsc28NCj4gdGhlIHBvc3NpYmlsaXR5IG9mIHNpZ25pbmcgdXAgZm9yIGEgc2lk ZSBtZWV0aW5nIHJvb20NCj4gKHNlZQ0KPiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL2lldGYvRE1wVURkX1hwMU9ldFBFTnd6Z0JYSlgNCj4gcTNWRSkNCg0KWWVhaCwgaSBk aWRuJ3QgbmVjZXNzYXJpbHkgbWVhbiBhICJkcmlua2luZyIgQm9GLCBidXQgc2luY2UgQm9GIGlu IHRoZSBjb250ZXh0IG9mIHRoZSBJRVRGIGlzIG1vcmUgYSBmb3JtYWwgZXZlbnQsIGkgdG9vayAi QmFyIEJvRiIgYXMgYSBzeW5vbnltIGFzIGEgbWVldGluZyB0aGF0J3Mgbm90IG9uIHRoZSBJRVRG IGFnZW5kYS4gT25jZSB0aGVyZSdzIGVub3VnaCBpbnRlcmVzdCwgaSdsbCBsb29rIGludG8gc2Vj dXJpbmcgYSByb29tICh0aG91Z2gsIHJvb21zIGFyZSB0eXBpY2FsbHkgb25seSBhdmFpbGFibGUg ZHVyaW5nIGV2ZW5pbmdzLCBpIGd1ZXNzKQ0KDQpiZXN0LA0KQWxleA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG5zLXByaXZhY3kgbWFpbGluZyBs aXN0DQpkbnMtcHJpdmFjeUBpZXRmLm9yZzxtYWlsdG86ZG5zLXByaXZhY3lAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rucy1wcml2YWN5DQoNCg== --_000_19F54F2956911544A32543B8A9BDE07599081772NICSEXCH2sbgnic_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRS1NYWlsRm9ybWF0 dm9ybGFnZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4w Y20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QW5kLi4uDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoaXMgc2VlbXMgdG8gYmUg dGhlIOKAnmNvcmXigJwgb2YgdGhlIEROUy1vdmVyLVRMUyBjb21taXRzIGZvciBBbmRyb2lkcyAo dG9vayBhIHdoaWxlIHRvIGZpbmQpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9hbmRyb2lkLXJldmlldy5nb29nbGVzb3VyY2UuY29tLyMv Yy9wbGF0Zm9ybS9zeXN0ZW0vbmV0ZC8mIzQzOy8zODA1OTMvIj5odHRwczovL2FuZHJvaWQtcmV2 aWV3Lmdvb2dsZXNvdXJjZS5jb20vIy9jL3BsYXRmb3JtL3N5c3RlbS9uZXRkLyYjNDM7LzM4MDU5 My88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5FeGNpdGluZyE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFsZXg8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Vm9uOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdGp3IGlldGYgW21h aWx0bzp0ancuaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5HZXNlbmRldDo8L2I+IE1vbnRhZywg MjMuIE9rdG9iZXIgMjAxNyAxMTo0ODxicj4NCjxiPkFuOjwvYj4gQWxleGFuZGVyIE1heXJob2Zl ciAmbHQ7YWxleGFuZGVyLm1heXJob2ZlckBuaWMuYXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNZWxp bmRhIFNob3JlICZsdDttZWxpbmRhLnNob3JlQGdtYWlsLmNvbSZndDs7IGRucy1wcml2YWN5QGll dGYub3JnPGJyPg0KPGI+QmV0cmVmZjo8L2I+IFJlOiBbZG5zLXByaXZhY3ldIGRwcml2ZSAoYmFy KSBCb0Y/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiYjNDM7MSAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkknbGwgYmUgZ2xhZCB0byBvcmdhbml6ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RllJLCBJIHNhdyB0aGlzIG9uIEhh Y2tlciBOZXdzOiAmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL2lncmln b3Jpay9zdGF0dXMvOTIyMjg2OTYxNDk4NDc2NTQ0Ij5odHRwczovL3R3aXR0ZXIuY29tL2lncmln b3Jpay9zdGF0dXMvOTIyMjg2OTYxNDk4NDc2NTQ0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ETlMgb3ZlciBUTFMgY29taW5nIHRvIEFu ZHJvaWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gTW9uLCBPY3QgMjMsIDIwMTcgYXQgMzowOCBBTSwgQWxleGFuZGVyIE1heXJob2ZlciAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRlci5tYXlyaG9mZXJAbmljLmF0IiB0YXJnZXQ9Il9i bGFuayI+YWxleGFuZGVyLm1heXJob2ZlckBuaWMuYXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NZWxpbmRhIFNob3JlIHdy b3RlOjxicj4NCiZndDsgSSdkIGJlIGludGVyZXN0ZWQuJm5ic3A7IFdoYXQgdG9waWNzIGRvIHlv dSBoYXZlIGluIG1pbmQ/PGJyPg0KPGJyPg0KUHJpbWFyaWx5LCBpIGhhZCBpbiBtaW5kIHRvIGdh dGhlciBmZWVkYmFjayBvbiBkcmFmdC1pZXRmLWRwcml2ZS1wYWRkaW5nLXBvbGljeS4gSSdtIHRo ZSBhdXRob3IsIGFuZCBpdCdzIHRoZSBsYXN0IHJlbWFpbmluZyBkcHJpdmUgV0cgZG9jdW1lbnQs IHNvIGknZCBsaWtlIHRvIGdldCB0aGlzIG9uZSBvdXQgb2YgdGhlIGRvb3IuIEJlc2lkZXMgdGhh dCwgaSdkIGxpa2UgdG8gaGVhciBhYm91dCBpbXBsZW1lbnRhdGlvbiBzdGF0dXMvcHJvZ3Jlc3MN CiBhcyB3ZWxsIGFzIGV2ZXJ5b25lJ3MgdGhvdWdodHMgLyBndXRzIGZlZWxpbmdzIG9mIHRoZSBj b25uZWN0aW9uIGJldHdlZW4gZHByaXZlIGFuZCB0aGUgJnF1b3Q7RE5TIG92ZXIgZm9ybXMgb2Yg SFRUUCZxdW90OyBlZmZvcnRzLjxicj4NCjxicj4NCiZndDsgQWxzbywgd2hpbGUgSSdtIGFsd2F5 cyB1cCBmb3IgdGhlIGJhciwgdGhlcmUncyBhbHNvPGJyPg0KJmd0OyB0aGUgcG9zc2liaWxpdHkg b2Ygc2lnbmluZyB1cCBmb3IgYSBzaWRlIG1lZXRpbmcgcm9vbTxicj4NCiZndDsgKHNlZTxicj4N CiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pZXRm L0RNcFVEZF9YcDFPZXRQRU53emdCWEpYIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lldGYvRE1wVURkX1hwMU9ldFBFTnd6Z0JYSlg8L2E+ PGJyPg0KJmd0OyBxM1ZFKTxicj4NCjxicj4NClllYWgsIGkgZGlkbid0IG5lY2Vzc2FyaWx5IG1l YW4gYSAmcXVvdDtkcmlua2luZyZxdW90OyBCb0YsIGJ1dCBzaW5jZSBCb0YgaW4gdGhlIGNvbnRl eHQgb2YgdGhlIElFVEYgaXMgbW9yZSBhIGZvcm1hbCBldmVudCwgaSB0b29rICZxdW90O0JhciBC b0YmcXVvdDsgYXMgYSBzeW5vbnltIGFzIGEgbWVldGluZyB0aGF0J3Mgbm90IG9uIHRoZSBJRVRG IGFnZW5kYS4gT25jZSB0aGVyZSdzIGVub3VnaCBpbnRlcmVzdCwgaSdsbCBsb29rIGludG8gc2Vj dXJpbmcgYSByb29tICh0aG91Z2gsDQogcm9vbXMgYXJlIHR5cGljYWxseSBvbmx5IGF2YWlsYWJs ZSBkdXJpbmcgZXZlbmluZ3MsIGkgZ3Vlc3MpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCmJlc3QsPGJyPg0KQWxleDxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZG5zLXBy aXZhY3kgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmRucy1wcml2YWN5QGlldGYu b3JnIj5kbnMtcHJpdmFjeUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rucy1wcml2YWN5IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnMtcHJpdmFjeTwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_19F54F2956911544A32543B8A9BDE07599081772NICSEXCH2sbgnic_-- From nobody Mon Oct 23 03:08:58 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAC213F3A5 for ; Mon, 23 Oct 2017 03:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.145 X-Spam-Level: X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 yQVW5wCJWlbT for ; Mon, 23 Oct 2017 03:08:53 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-oln040092064019.outbound.protection.outlook.com [40.92.64.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8B2137C2E for ; Mon, 23 Oct 2017 03:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xRn6wFA4xTauK9qGxeheOh+P/aOy7I+tF2Fx2Dc4LVA=; b=FfnPDhf4ED3CuCoGwviOCye4ALtTJnHFSlt/ij7QDvB2/GLJ2VhKgKBOwhvIgz1rqulveT2HPwvKc8joTlxUGqlVV3qdzyoh4eCMMSszRAegsLFaPCfUgu+M2SKJ9nR30La3aeykYGsBOp72KVwXPZz+X9Qa9DY9dZO7KaUkQer9KJsn3MjVlMw5fTCCXq+BF4oITMmmWUBw/7l+tYQ47ra62U+SQEYHJDq0Dq4QEn5IZwElX2p0tuAttYPPZjCLdxKRIf+8s5kBsx7H/p+BCfcc8DagjMfV98IXlXzRP8QBeL1F9K0hLzchAqvlSx88TwVLHizbOor4KSNj6oUjQQ== Received: from HE1EUR01FT056.eop-EUR01.prod.protection.outlook.com (10.152.0.54) by HE1EUR01HT041.eop-EUR01.prod.protection.outlook.com (10.152.1.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.156.4; Mon, 23 Oct 2017 10:08:50 +0000 Received: from AM5PR0401MB2627.eurprd04.prod.outlook.com (10.152.0.51) by HE1EUR01FT056.mail.protection.outlook.com (10.152.0.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.156.4 via Frontend Transport; Mon, 23 Oct 2017 10:08:45 +0000 Received: from AM5PR0401MB2627.eurprd04.prod.outlook.com ([fe80::4079:74d1:d1c2:62b4]) by AM5PR0401MB2627.eurprd04.prod.outlook.com ([fe80::4079:74d1:d1c2:62b4%17]) with mapi id 15.20.0156.005; Mon, 23 Oct 2017 10:08:45 +0000 From: Antoine Germanos To: "dns-privacy@ietf.org" , "dns-privacy@ietf.org" Thread-Topic: dprive (bar) BoF? [Antoine Germanos] Thread-Index: AQHTS+bpKtZRoYhrJEmuBEGEZcVN8w== Date: Mon, 23 Oct 2017 10:08:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:79ADE00A889FD5F9374A56554031E6B49C69D489759156AC5907FE227DFF3B72; UpperCasedChecksum:EF614716DA48D6DCB742A36693E000184CE0E41777A2509BC95737CCBB1DC078; SizeAsReceived:7056; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [7D3bAMk/iNyfvcZ5VWahoQmG6AP2S9/H] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1EUR01HT041; 6:cYTdo33TMI3WUgnQTIEg9hzzpb8M3ZFEsJpBSZzmOtm1odk3TJp4k7hpfyN3z61uZb3IVEw/zEaxoIiHwjR2OsZrJBeZ8l1bL8HlOrKfAtG8+mmbwdGbciuqlUoeb9reBE+V+xJgxPJLgh/gz4Vpg5AsBJxmupyFvGSLUddv670XkWjMSoxvNLsWECiy24DuPF9GaowW0UfqUqfZbm6HquX8l4mPATEob8dXDALpjkgrn2fd96um+CrPxK5rU+Djk9xERNRbgpvGtcZ+X7xtBm/6A7X2r8yxeBQAIOYrg16bSCrgEPEGFmFCQTg1JiP14Zwrpfsd6591apPDoPP9wQ==; 5:11FiapeP+yhwRQmvdwTQ48rhdaJgfWtHxkownFZZpD/JaAj1xrrnp2yofmY5edXdViapXZQSQYBfTTXlYy3vY4PRi00cvOdhJZCw4AOOhsx0uS5aerxu22w+Gcz3AWaILdpGQ6XMg6ezr1pog+cHlA==; 24:D/gSLrmZdjgJ/PZP4cYeCuwWDvM9b1FIxNEDFx5PIzOJ4NXohv6NHMBsQ1x1l6Yx3AB9Q/mYqXdBJGxAn7zSd3o6Khm4Row9FJtkZ4/AYk8=; 7:m6stYCDd+ZOuYFsbv+K78wAkmKQ9VPFNMS4wBt6dyTrviw8Ifd7BBQKfxR1BGSQdtHBpeT9nzyOK/GjThy9TMJp30DB6xJsL0UKTiiOo1+WCh8Yc3P0KWx3I79RR6aKIT6envRPzg86It9Ypu9FK7saFJP2BWhkD522wh8gOWMSjG/C2AvRXN4TVchqaa1mEo1Q7cCZb0DJ70v6xqcykFR+Ko8QvUoHE7GVCs2PqzCU= x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 6ee1d944-de37-4913-1c64-08d519fe0bf4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:HE1EUR01HT041; x-ms-traffictypediagnostic: HE1EUR01HT041: x-exchange-antispam-report-test: UriScan:(31418570063057)(111885846020525)(81439100147899); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:HE1EUR01HT041; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1EUR01HT041; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1EUR01HT041; H:AM5PR0401MB2627.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0401MB2627F3EA4B229F5D42D4626499460AM5PR0401MB2627_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ee1d944-de37-4913-1c64-08d519fe0bf4 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 10:08:45.5415 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR01HT041 Archived-At: Subject: Re: [dns-privacy] dprive (bar) BoF? [Antoine Germanos] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 10:08:57 -0000 --_000_AM5PR0401MB2627F3EA4B229F5D42D4626499460AM5PR0401MB2627_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 Device? MUST [API ]? Link if possible. Regards Antoine Germanos=99 _____________________________ From: dns-privacy-request@ietf.org Sent: Monday, October 23, 2017 12:48 PM Subject: dns-privacy Digest, Vol 44, Issue 4 To: > Send dns-privacy mailing list submissions to dns-privacy@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/dns-privacy or, via email, send a message with subject or body 'help' to dns-privacy-request@ietf.org You can reach the person managing the list at dns-privacy-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dns-privacy digest..." Today's Topics: 1. dprive (bar) BoF? (Alexander Mayrhofer) 2. Re: dprive (bar) BoF? (Daniel Kahn Gillmor) 3. Re: dprive (bar) BoF? (Melinda Shore) 4. Re: dprive (bar) BoF? (Ulrich Wisser) 5. Re: dprive (bar) BoF? (Alexander Mayrhofer) 6. Re: dprive (bar) BoF? (tjw ietf) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 Oct 2017 06:14:36 +0000 From: Alexander Mayrhofer > To: "dns-privacy@ietf.org" > Subject: [dns-privacy] dprive (bar) BoF? Message-ID: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> Content-Type: text/plain; charset=3D"us-ascii" Hey all, since we're not scheduled for a session in Singapore - would anybody be int= erested in meeting up for a bar BoF during the meeting? eg. a lunch break? best, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Mon, 23 Oct 2017 02:43:13 -0400 From: Daniel Kahn Gillmor > To: Alexander Mayrhofer >, "dns-privacy\@ietf.org" > Subject: Re: [dns-privacy] dprive (bar) BoF? Message-ID: <87inf6z7ni.fsf@fifthhorseman.net> Content-Type: text/plain On Mon 2017-10-23 06:14:36 +0000, Alexander Mayrhofer wrote: > since we're not scheduled for a session in Singapore - would anybody > be interested in meeting up for a bar BoF during the meeting? eg. a > lunch break? I'd be interested. --dkg ------------------------------ Message: 3 Date: Sun, 22 Oct 2017 22:49:30 -0800 From: Melinda Shore > To: dns-privacy@ietf.org Subject: Re: [dns-privacy] dprive (bar) BoF? Message-ID: <336f3434-e3e0-9ae3-ca67-b2611ae210bc@gmail.com> Content-Type: text/plain; charset=3D"windows-1252" On 10/22/17 10:14 PM, Alexander Mayrhofer wrote: > since we?re not scheduled for a session in Singapore ? would anybody be > interested in meeting up for a bar BoF during the meeting? eg. a lunch > break? I'd be interested. What topics do you have in mind? Also, while I'm always up for the bar, there's also the possibility of signing up for a side meeting room (see https://mailarchive.ietf.org/arch/msg/ietf/DMpUDd_Xp1OetPENwzgBXJXq3VE= ) Melinda -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: ------------------------------ Message: 4 Date: Mon, 23 Oct 2017 06:57:35 +0000 From: Ulrich Wisser > Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] dprive (bar) BoF? Message-ID: = > Content-Type: text/plain; charset=3D"utf-8" +1 On Mon, Oct 23, 2017, 08:14 Alexander Mayrhofer > wrote: > Hey all, > > > > since we?re not scheduled for a session in Singapore ? would anybody be > interested in meeting up for a bar BoF during the meeting? eg. a lunch > break? > > > > best, > > Alex > > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > -- Ulrich Wisser ulrich@wisser.se -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Mon, 23 Oct 2017 07:08:04 +0000 From: Alexander Mayrhofer > To: Melinda Shore >= , "dns-privacy@ietf.org" > Subject: Re: [dns-privacy] dprive (bar) BoF? Message-ID: <19F54F2956911544A32543B8A9BDE075990802EC@NICS-EXCH2.sbg.nic.at> Content-Type: text/plain; charset=3D"us-ascii" Melinda Shore wrote: > I'd be interested. What topics do you have in mind? Primarily, i had in mind to gather feedback on draft-ietf-dprive-padding-po= licy. I'm the author, and it's the last remaining dprive WG document, so i'= d like to get this one out of the door. Besides that, i'd like to hear abou= t implementation status/progress as well as everyone's thoughts / guts feel= ings of the connection between dprive and the "DNS over forms of HTTP" effo= rts. > Also, while I'm always up for the bar, there's also > the possibility of signing up for a side meeting room > (see > https://mailarchive.ietf.org/arch/msg/ietf/DMpUDd_Xp1OetPENwzgBXJX > q3VE) Yeah, i didn't necessarily mean a "drinking" BoF, but since BoF in the cont= ext of the IETF is more a formal event, i took "Bar BoF" as a synonym as a = meeting that's not on the IETF agenda. Once there's enough interest, i'll l= ook into securing a room (though, rooms are typically only available during= evenings, i guess) best, Alex ------------------------------ Message: 6 Date: Mon, 23 Oct 2017 05:47:41 -0400 From: tjw ietf > To: Alexander Mayrhofer > Cc: Melinda Shore >= , "dns-privacy@ietf.org" > Subject: Re: [dns-privacy] dprive (bar) BoF? Message-ID: > Content-Type: text/plain; charset=3D"utf-8" +1 I'll be glad to organize. FYI, I saw this on Hacker News: https://twitter.com/igrigorik/status/922286961498476544 DNS over TLS coming to Android On Mon, Oct 23, 2017 at 3:08 AM, Alexander Mayrhofer < alexander.mayrhofer@nic.at> wrote: > Melinda Shore wrote: > > I'd be interested. What topics do you have in mind? > > Primarily, i had in mind to gather feedback on draft-ietf-dprive-padding-= policy. > I'm the author, and it's the last remaining dprive WG document, so i'd li= ke > to get this one out of the door. Besides that, i'd like to hear about > implementation status/progress as well as everyone's thoughts / guts > feelings of the connection between dprive and the "DNS over forms of HTTP= " > efforts. > > > Also, while I'm always up for the bar, there's also > > the possibility of signing up for a side meeting room > > (see > > https://mailarchive.ietf.org/arch/msg/ietf/DMpUDd_Xp1OetPENwzgBXJX > > q3VE) > > Yeah, i didn't necessarily mean a "drinking" BoF, but since BoF in the > context of the IETF is more a formal event, i took "Bar BoF" as a synonym > as a meeting that's not on the IETF agenda. Once there's enough interest, > i'll look into securing a room (though, rooms are typically only availabl= e > during evenings, i guess) > > best, > Alex > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy ------------------------------ End of dns-privacy Digest, Vol 44, Issue 4 ****************************************** --_000_AM5PR0401MB2627F3EA4B229F5D42D4626499460AM5PR0401MB2627_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1
Device? MUST [API ]?
 Link if possible.

Regards 
Antoine Germanos=99
_____________________________
From: dns-privacy-request@ietf.org
Sent: Monday, October 23, 2017 12:48 PM
Subject: dns-privacy Digest, Vol 44, Issue 4
To: <dns-privacy@ietf.org>


Send dns-privacy mailing list submissions to
dns-privacy@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/dns-priv= acy
or, via email, send a message with subject or body 'help' to
dns-privacy-request@ietf.org

You can reach the person managing the list at
dns-privacy-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dns-privacy digest..."


Today's Topics:

1. dprive (bar) BoF? (Alexander Mayrhofer)
2. Re: dprive (bar) BoF? (Daniel Kahn Gillmor)
3. Re: dprive (bar) BoF? (Melinda Shore)
4. Re: dprive (bar) BoF? (Ulrich Wisser)
5. Re: dprive (bar) BoF? (Alexander Mayrhofer)
6. Re: dprive (bar) BoF? (tjw ietf)


----------------------------------------------------------------------

Message: 1
Date: Mon, 23 Oct 2017 06:14:36 +0000
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at&g= t;
To: "dns-privacy@ietf.org" <dns-privacy@ietf= .org>
Subject: [dns-privacy] dprive (bar) BoF?
Message-ID:
<19F54F2956911544A32543= B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at>
Content-Type: text/plain; charset=3D"us-ascii"

Hey all,

since we're not scheduled for a session in Singapore - would anybody be int= erested in meeting up for a bar BoF during the meeting? eg. a lunch break?<= br>
best,
Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachmen= ts/20171023/8345c844/attachment.html>

------------------------------

Message: 2
Date: Mon, 23 Oct 2017 02:43:13 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Alexander Mayrhofer <alexander.mayrhofer@nic.at>= ;,
"dns-privacy\@ietf.org" <dns-privacy@ietf.org>=
Subject: Re: [dns-privacy] dprive (bar) BoF?
Message-ID: <87inf6z7ni.fsf@fifthhorseman.net>= ;
Content-Type: text/plain

On Mon 2017-10-23 06:14:36 +0000, Alexander Mayrhofer wrote:

> since we're not scheduled for a session in Singapore - would anybody > be interested in meeting up for a bar BoF during the meeting? eg. a > lunch break?

I'd be interested.

--dkg



------------------------------

Message: 3
Date: Sun, 22 Oct 2017 22:49:30 -0800
From: Melinda Shore <melinda.shore@gmail.com>
To: dns-privacy@ietf.org
Subject: Re: [dns-privacy] dprive (bar) BoF?
Message-ID: <336f3434-e3e0-9ae3-ca67-b= 2611ae210bc@gmail.com>
Content-Type: text/plain; charset=3D"windows-1252"

On 10/22/17 10:14 PM, Alexander Mayrhofer wrote:
> since we?re not scheduled for a session in Singapore ? would anybody b= e
> interested in meeting up for a bar BoF during the meeting? eg. a lunch=
> break?

I'd be interested. What topics do you have in mind?
Also, while I'm always up for the bar, there's also
the possibility of signing up for a side meeting room
(see https://mailarchive.ietf.org/arch/msg/ietf/DMpUDd_Xp1OetPENwzgBXJXq3VE)=

Melinda

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachment= s/20171022/36bdbbc8/attachment.asc>

------------------------------

Message: 4
Date: Mon, 23 Oct 2017 06:57:35 +0000
From: Ulrich Wisser <ulrich@wisser.se>
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] dprive (bar) BoF?
Message-ID:
<CAJ9-zoXt= 2d-T+ZBAcPcLzCR6GdX7z5g=3D7g9bL9_ceC8g8B=3Dyng@mail.gmail.com> Content-Type: text/plain; charset=3D"utf-8"

+1

On Mon, Oct 23, 2017, 08:14 Alexander Mayrhofer <alexander= .mayrhofer@nic.at>
wrote:

> Hey all,
>
>
>
> since we?re not scheduled for a session in Singapore ? would anybody b= e
> interested in meeting up for a bar BoF during the meeting? eg. a lunch=
> break?
>
>
>
> best,
>
> Alex
>
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
--
Ulrich Wisser
ulrich@wisser.se
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachmen= ts/20171023/b092ce5c/attachment.html>

------------------------------

Message: 5
Date: Mon, 23 Oct 2017 07:08:04 +0000
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at&= gt;
To: Melinda Shore <melinda.shore@gmail.com>, "dns-privacy@ietf.org"
<dns-privacy@ietf.org>
Subject: Re: [dns-privacy] dprive (bar) BoF?
Message-ID:
<19F54F2956911544A3254= 3B8A9BDE075990802EC@NICS-EXCH2.sbg.nic.at>
Content-Type: text/plain; charset=3D"us-ascii"

Melinda Shore wrote:
> I'd be interested. What topics do you have in mind?

Primarily, i had in mind to gather feedback on draft-ietf-dprive-padding-po= licy. I'm the author, and it's the last remaining dprive WG document, so i'= d like to get this one out of the door. Besides that, i'd like to hear abou= t implementation status/progress as well as everyone's thoughts / guts feelings of the connection between d= prive and the "DNS over forms of HTTP" efforts.

> Also, while I'm always up for the bar, there's also
> the possibility of signing up for a side meeting room
> (see
> https://mailarchive.ietf.org/arch/msg/ietf/DMpUDd_Xp1OetPENwzgBXJX
> q3VE)

Yeah, i didn't necessarily mean a "drinking" BoF, but since BoF i= n the context of the IETF is more a formal event, i took "Bar BoF"= ; as a synonym as a meeting that's not on the IETF agenda. Once there's eno= ugh interest, i'll look into securing a room (though, rooms are typically only available during evenings, i guess)

best,
Alex



------------------------------

Message: 6
Date: Mon, 23 Oct 2017 05:47:41 -0400
From: tjw ietf <tjw.ietf@gmail.com>
To: Alexander Mayrhofer <alexander.mayrhofer@nic.at>= ;
Cc: Melinda Shore <melinda.shore@gmail.com>, "dns-privacy@ietf.org"
<dns-privacy@ietf.org>
Subject: Re: [dns-privacy] dprive (bar) BoF?
Message-ID:
<C= ADyWQ+Gsh3c+OU+2MRFhLu4AqRCOGsFAXtE+wvYZedzuBXqzZw@mail.gma= il.com>
Content-Type: text/plain; charset=3D"utf-8"

+1

I'll be glad to organize.

FYI, I saw this on Hacker News:
https://twitter.com/igrigorik/status/92= 2286961498476544

DNS over TLS coming to Android

On Mon, Oct 23, 2017 at 3:08 AM, Alexander Mayrhofer <
alexander.mayrhofer@nic.at> wrote:

> Melinda Shore wrote:
> > I'd be interested. What topics do you have in mind?
>
> Primarily, i had in mind to gather feedback on draft-ietf-dprive-paddi= ng-policy.
> I'm the author, and it's the last remaining dprive WG document, so i'd= like
> to get this one out of the door. Besides that, i'd like to hear about<= br> > implementation status/progress as well as everyone's thoughts / guts > feelings of the connection between dprive and the "DNS over forms= of HTTP"
> efforts.
>
> > Also, while I'm always up for the bar, there's also
> > the possibility of signing up for a side meeting room
> > (see
> > https://mailarchive.ietf.org/arch/msg/ietf/DMpUDd_Xp1OetPENwzgBXJX
> > q3VE)
>
> Yeah, i didn't necessarily mean a "drinking" BoF, but since = BoF in the
> context of the IETF is more a formal event, i took "Bar BoF"= as a synonym
> as a meeting that's not on the IETF agenda. Once there's enough intere= st,
> i'll look into securing a room (though, rooms are typically only avail= able
> during evenings, i guess)
>
> best,
> Alex
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachmen= ts/20171023/ef0868b3/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-pri= vacy


------------------------------

End of dns-privacy Digest, Vol 44, Issue 4
******************************************


--_000_AM5PR0401MB2627F3EA4B229F5D42D4626499460AM5PR0401MB2627_-- From nobody Mon Oct 23 03:42:00 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B549E13F3B7 for ; Mon, 23 Oct 2017 03:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 QZdc8ao51jw1 for ; Mon, 23 Oct 2017 03:41:56 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A6C13AB36 for ; Mon, 23 Oct 2017 03:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=Gijb6LVSkG25tvQ+td9x0V3qjKbYCaXLSOchXnECS+I=; b=PXmqg3ZWMlWsokU1hsnNxTu74gmFnzhS4BO4KquYjBzpRX+NU//+j5GP+hUhVd7g4gXKxmxLDDrwPmIEAJjwWDn3FYCWDd3c9waO+LBTcNaN6Eq3ZmjhXZES7h0EC9Twb7A8w5ioWbQUm57itCaBxSYTHTX6WI1Avz8LntvzhAShUj8xdg7gQtmNtyExSGjvsMXn1gk5HBO7WgcIR0WKfzBhmQ18O44T502CtpxZz10i/hweCMR7CJ6lLr82LTtdIGeBp4zaC3hh0kgYRih55mM0fWGtQnKNlC7IL4v5r+uAaPWg7K5xcODz0acpA+UmINYwZfyRNkK/mkT5Niju0Q== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id v9NAfs1h025679-v9NAfs1j025679 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Mon, 23 Oct 2017 12:41:54 +0200 Received: from [94.198.159.133] (94.198.159.133) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 23 Oct 2017 12:41:53 +0200 To: "dns-privacy@ietf.org" References: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> <336f3434-e3e0-9ae3-ca67-b2611ae210bc@gmail.com> <19F54F2956911544A32543B8A9BDE075990802EC@NICS-EXCH2.sbg.nic.at> From: "Giovane C. M. Moura" Message-ID: <036ac08d-7ce9-a233-1b83-4bb18f42c8ed@sidn.nl> Date: Mon, 23 Oct 2017 12:41:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <19F54F2956911544A32543B8A9BDE075990802EC@NICS-EXCH2.sbg.nic.at> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.133] X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.133, helo=, mailFrom=giovane.moura@sidn.nl, headerFrom=giovane.moura@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of giovane.moura@sidn.nl designates 94.198.159.133 as permitted sender) smtp.mailfrom=giovane.moura@sidn.nl Archived-At: Subject: Re: [dns-privacy] dprive (bar) BoF? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 10:41:59 -0000 +1 /giovane On 10/23/2017 09:08 AM, Alexander Mayrhofer wrote: > Melinda Shore wrote: >> I'd be interested. What topics do you have in mind? From nobody Mon Oct 23 07:17:31 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0DA138F1D for ; Mon, 23 Oct 2017 07:17:28 -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 9XYhRxH3iMA6 for ; Mon, 23 Oct 2017 07:17:27 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 6DD19138BE0 for ; Mon, 23 Oct 2017 07:17:27 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id 134so20262828ioo.0 for ; Mon, 23 Oct 2017 07:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=04/wLIfq1At/gkF0z3K6DgmWBbN5u5F/jwX8Bzt00nc=; b=oQcmGgBbM2gKBW6EHJW7bi45tJpp2MZBGmhsu24sSQujugb1YGZQuvSIxzqmDR3ekX Ob9A3w3aNNVue5dBAQMAx5FfZUp8/eym4BRo8or7VHlXZxFiZYP6nexw/ncQFDX/sWJl lP+AmrXyZf9lF0JU63tfRwfFbNMpxhfjLC9eFMKGE8RszKxsNfbSwxiWJ1FLgkR/mlYv 5ks7vzmctg0Ig5QU377xMrjMaJ47abAyR5WB8TI6Ttvfdj7z6Q+VRZ+IRxgzTM9Z3noJ cONkADikD/uLHtLjzatC7YrLl4pgRvMt0ej5PR55iUAXld4+8KxLQj8hRWjscODH0PLE /f0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=04/wLIfq1At/gkF0z3K6DgmWBbN5u5F/jwX8Bzt00nc=; b=GNTqR2NjHb+fnU6FTMuBxJXpsUn+oFVzuD88tnb8iJJCK6Bo53m3GBWIa1j1EwzaV1 ks+lyyS7/piWUy9SgHFdA8BmEjh+080AjLExBQnRXHhAmIGz0G9qrHOEKw61zOKr2sS5 Iv+OAC/nYQJvYOHaeGPp1WIbvmmd0MJNV6U8epuG4bpyCpzjuIkUsRB+WjAU1lI8CxqX 9taSX3i1qglxZX2q8qe4bCc7AZq7dhTY+U1dB/44h6lEjSq6zLNpP9kFXl+cFar+09aj 3C6IBwm0Dr+eOjUkkPRVUympR32LKxiU2Y8gjIZKVQNChw/3e3Rei0471ivtxuOfC7j2 6/SQ== X-Gm-Message-State: AMCzsaWyGhzr3sktpIK8l/+XyTLdkcDTEvPHTThXKCLisA6OuedvfnYM p8a56WXxKbIDVvG8OaqPUEDzOBDwlKA0eI52qAQUpQ== X-Google-Smtp-Source: ABhQp+RmeGs3OdyU++9iLEFlkYhtRL9NBdAhZ2tFbGy+UHmVnnosEqHHmFMS/nwDt1QHT1tsDoa8+CILi6nXZbZSQ1s= X-Received: by 10.107.83.10 with SMTP id h10mr19033183iob.242.1508768246703; Mon, 23 Oct 2017 07:17:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.141.68 with HTTP; Mon, 23 Oct 2017 07:17:26 -0700 (PDT) In-Reply-To: <036ac08d-7ce9-a233-1b83-4bb18f42c8ed@sidn.nl> References: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> <336f3434-e3e0-9ae3-ca67-b2611ae210bc@gmail.com> <19F54F2956911544A32543B8A9BDE075990802EC@NICS-EXCH2.sbg.nic.at> <036ac08d-7ce9-a233-1b83-4bb18f42c8ed@sidn.nl> From: Christopher Wood Date: Mon, 23 Oct 2017 07:17:26 -0700 Message-ID: To: "Giovane C. M. Moura" Cc: "dns-privacy@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dns-privacy] dprive (bar) BoF? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 14:17:29 -0000 +1 On Mon, Oct 23, 2017 at 3:41 AM, Giovane C. M. Moura wrote: > +1 > > /giovane > > On 10/23/2017 09:08 AM, Alexander Mayrhofer wrote: >> >> Melinda Shore wrote: >>> >>> I'd be interested. What topics do you have in mind? > > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy From nobody Mon Oct 23 09:18:08 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B738F13954E for ; Mon, 23 Oct 2017 09:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 I7zogyS4iS4M for ; Mon, 23 Oct 2017 09:18:06 -0700 (PDT) Received: from smtp96.iad3a.emailsrvr.com (smtp96.iad3a.emailsrvr.com [173.203.187.96]) (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 DCB5B139507 for ; Mon, 23 Oct 2017 09:18:05 -0700 (PDT) Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id BE22461EC; Mon, 23 Oct 2017 12:18:02 -0400 (EDT) X-Auth-ID: bgreene@senki.org Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id E287A5C30; Mon, 23 Oct 2017 12:18:01 -0400 (EDT) X-Sender-Id: bgreene@senki.org Received: from [172.16.1.27] (c-73-92-124-43.hsd1.ca.comcast.net [73.92.124.43]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 23 Oct 2017 12:18:02 -0400 Content-Type: multipart/alternative; boundary=Apple-Mail-650F713E-D655-4AD4-B993-849172436D0F Mime-Version: 1.0 (1.0) From: Barry Raveendran Greene X-Mailer: iPad Mail (15A421) In-Reply-To: Date: Mon, 23 Oct 2017 09:18:00 -0700 Cc: Alexander Mayrhofer , "dns-privacy@ietf.org" , Melinda Shore Content-Transfer-Encoding: 7bit Message-Id: <862711D0-5376-423D-884D-CD5C474AFF54@senki.org> References: <19F54F2956911544A32543B8A9BDE075990801B6@NICS-EXCH2.sbg.nic.at> <336f3434-e3e0-9ae3-ca67-b2611ae210bc@gmail.com> <19F54F2956911544A32543B8A9BDE075990802EC@NICS-EXCH2.sbg.nic.at> To: tjw ietf Archived-At: Subject: Re: [dns-privacy] dprive (bar) BoF? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:18:08 -0000 --Apple-Mail-650F713E-D655-4AD4-B993-849172436D0F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Shifting the topic, would anyone be interested in give a talk on DPRIVE to o= ne of the Singapore meet-up groups? Sent from my iPad > On Oct 23, 2017, at 02:47, tjw ietf wrote: >=20 > +1 =20 >=20 > I'll be glad to organize.=20 >=20 > FYI, I saw this on Hacker News: https://twitter.com/igrigorik/status/922= 286961498476544 >=20 > DNS over TLS coming to Android >=20 >> On Mon, Oct 23, 2017 at 3:08 AM, Alexander Mayrhofer wrote: >> Melinda Shore wrote: >> > I'd be interested. What topics do you have in mind? >>=20 >> Primarily, i had in mind to gather feedback on draft-ietf-dprive-padding-= policy. I'm the author, and it's the last remaining dprive WG document, so i= 'd like to get this one out of the door. Besides that, i'd like to hear abou= t implementation status/progress as well as everyone's thoughts / guts feeli= ngs of the connection between dprive and the "DNS over forms of HTTP" effort= s. >>=20 >> > Also, while I'm always up for the bar, there's also >> > the possibility of signing up for a side meeting room >> > (see >> > https://mailarchive.ietf.org/arch/msg/ietf/DMpUDd_Xp1OetPENwzgBXJX >> > q3VE) >>=20 >> Yeah, i didn't necessarily mean a "drinking" BoF, but since BoF in the co= ntext of the IETF is more a formal event, i took "Bar BoF" as a synonym as a= meeting that's not on the IETF agenda. Once there's enough interest, i'll l= ook into securing a room (though, rooms are typically only available during e= venings, i guess) >>=20 >> best, >> Alex >>=20 >> _______________________________________________ >> dns-privacy mailing list >> dns-privacy@ietf.org >> https://www.ietf.org/mailman/listinfo/dns-privacy >=20 > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy --Apple-Mail-650F713E-D655-4AD4-B993-849172436D0F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Shifting the topic, would an= yone be interested in give a talk on DPRIVE to one of the Singapore meet-up g= roups?




Sent from my iPad

On Oct 23, 2017, at 02:47, tjw ietf <= tjw.ietf@gmail.com> wrote:
<= br>
+1  

<= /div>
I'll be glad to organize. 

FYI, I sa= w this on Hacker News:   https://twitter.com/igrigorik/status/922286961498= 476544

DNS over TLS coming to Android

On Mon, Oct 23, 2= 017 at 3:08 AM, Alexander Mayrhofer <alexander.mayrhofer@nic.at= > wrote:
Melinda S= hore wrote:
> I'd be interested.  What topics do you have in mind?

Primarily, i had in mind to gather feedback on draft-ietf-dprive-padd= ing-policy. I'm the author, and it's the last remaining dprive WG docum= ent, so i'd like to get this one out of the door. Besides that, i'd like to h= ear about implementation status/progress as well as everyone's thoughts / gu= ts feelings of the connection between dprive and the "DNS over forms of HTTP= " efforts.

> Also, while I'm always up for the bar, there's also
> the possibility of signing up for a side meeting room
> (see
> https://mailarchive.ietf.org/arch/msg/ietf/DMpUDd_Xp1OetPENwzgBXJX
> q3VE)

Yeah, i didn't necessarily mean a "drinking" BoF, but since BoF in th= e context of the IETF is more a formal event, i took "Bar BoF" as a synonym a= s a meeting that's not on the IETF agenda. Once there's enough interest, i'l= l look into securing a room (though, rooms are typically only available duri= ng evenings, i guess)

best,
Alex

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privac= y

____________________= ___________________________
dns-privacy mailing list<= br>dns-privacy@ietf.org
= https://www.ietf.org/mailman/listinfo/dns-privacy
= --Apple-Mail-650F713E-D655-4AD4-B993-849172436D0F-- From nobody Mon Oct 23 12:47:43 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610E3139561 for ; Mon, 23 Oct 2017 12:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] 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 GohAppxLAUMY for ; Mon, 23 Oct 2017 12:47:40 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 D72281393AF for ; Mon, 23 Oct 2017 12:47:39 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id CD0C02806A8 for ; Mon, 23 Oct 2017 21:47:37 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id C5EDF2806F2; Mon, 23 Oct 2017 21:47:37 +0200 (CEST) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id BF6EA2806F2 for ; Mon, 23 Oct 2017 21:47:37 +0200 (CEST) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id BC73B642A7A1 for ; Mon, 23 Oct 2017 21:47:37 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id B9B9D4012B; Mon, 23 Oct 2017 21:47:37 +0200 (CEST) Date: Mon, 23 Oct 2017 21:47:37 +0200 From: Stephane Bortzmeyer To: dns-privacy@ietf.org Message-ID: <20171023194737.c2am3yzzacvvtay3@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 9.1 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: Unsure, tests=bogofilter, spamicity=0.467132, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.10.23.193615 Archived-At: Subject: [dns-privacy] =?utf-8?q?Android_getting_=E2=80=9CDNS_over_TLS?= =?utf-8?q?=E2=80=9D_support_to_stop_ISPs_from_knowing_what_websites_you_v?= =?utf-8?q?isit?= X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 19:47:42 -0000 [There was a demo at the Bits-n-Bites in the last meeting, Prague.] https://www.xda-developers.com/android-dns-over-tls-website-privacy/amp/ From nobody Mon Oct 23 17:40:31 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C571113A2B8 for ; Mon, 23 Oct 2017 17:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tlGxMlk-TX_a for ; Mon, 23 Oct 2017 17:40:27 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FC1139438 for ; Mon, 23 Oct 2017 17:40:26 -0700 (PDT) Received: from [172.16.10.126] (unknown [107.13.249.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id E6D04E37; Mon, 23 Oct 2017 20:38:37 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1CE1C615-4459-4310-BE7A-48B2F1AA5F63" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 23 Oct 2017 20:40:21 -0400 In-Reply-To: <20171023194737.c2am3yzzacvvtay3@nic.fr> Cc: dns-privacy@ietf.org To: Stephane Bortzmeyer References: <20171023194737.c2am3yzzacvvtay3@nic.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dns-privacy] =?utf-8?q?Android_getting_=E2=80=9CDNS_over_TLS?= =?utf-8?q?=E2=80=9D_support_to_stop_ISPs_from_knowing_what_websites_you_v?= =?utf-8?q?isit?= X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 00:40:29 -0000 --Apple-Mail=_1CE1C615-4459-4310-BE7A-48B2F1AA5F63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 23, 2017, at 3:47 PM, Stephane Bortzmeyer = wrote: >=20 > [There was a demo at the Bits-n-Bites in the last meeting, Prague.] >=20 > = https://www.xda-developers.com/android-dns-over-tls-website-privacy/amp/ = = For those of you wondering about iOS DNS privacy, Apple added a new DNS = Proxy Network Extension in iOS 11 that should allow all DNS requests to = be proxied through a network extension app. I began work on a TLS over = DNS Proxy and soon discovered that the network extension currently = requires the device to be supervised or use a specific type of Mobile = Device Management (MDM). I have requested that they lift this = restriction (radar=20 --Apple-Mail=_1CE1C615-4459-4310-BE7A-48B2F1AA5F63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 23, 2017, at 3:47 PM, Stephane Bortzmeyer <bortzmeyer@nic.fr> = wrote:

[There was a demo at the Bits-n-Bites in the last meeting, = Prague.]

https://www.xda-developers.com/android-dns-over-tls-website-pri= vacy/amp/

For those of you wondering about iOS DNS privacy, = Apple added a new DNS Proxy Network Extension in iOS 11 that should = allow all DNS requests to be proxied through a network extension app. I = began work on a TLS over DNS Proxy and soon discovered that the network = extension currently requires the device to be supervised or use a = specific type of Mobile Device Management (MDM). I have requested that = they lift this restriction (radar 

= --Apple-Mail=_1CE1C615-4459-4310-BE7A-48B2F1AA5F63-- From nobody Mon Oct 23 17:43:44 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2DA13AEFD for ; Mon, 23 Oct 2017 17:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MEguyUZNVyB6 for ; Mon, 23 Oct 2017 17:43:41 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF0713AF04 for ; Mon, 23 Oct 2017 17:43:14 -0700 (PDT) Received: from [172.16.10.126] (unknown [107.13.249.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 524B5E39; Mon, 23 Oct 2017 20:41:27 -0400 (EDT) From: Tom Pusateri Message-Id: <72F6F5BF-7BE6-49F5-AD83-C93A22E6DB67@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7C7EF6E8-E19F-434F-8400-EFCD272566E3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 23 Oct 2017 20:43:10 -0400 In-Reply-To: Cc: dns-privacy@ietf.org To: Stephane Bortzmeyer References: <20171023194737.c2am3yzzacvvtay3@nic.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dns-privacy] =?utf-8?q?Android_getting_=E2=80=9CDNS_over_TLS?= =?utf-8?q?=E2=80=9D_support_to_stop_ISPs_from_knowing_what_websites_you_v?= =?utf-8?q?isit?= X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 00:43:43 -0000 --Apple-Mail=_7C7EF6E8-E19F-434F-8400-EFCD272566E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 23, 2017, at 8:40 PM, Tom Pusateri wrote: >=20 >=20 >> On Oct 23, 2017, at 3:47 PM, Stephane Bortzmeyer > wrote: >>=20 >> [There was a demo at the Bits-n-Bites in the last meeting, Prague.] >>=20 >> = https://www.xda-developers.com/android-dns-over-tls-website-privacy/amp/ = = >=20 > For those of you wondering about iOS DNS privacy, Apple added a new = DNS Proxy Network Extension in iOS 11 that should allow all DNS requests = to be proxied through a network extension app. I began work on a TLS = over DNS Proxy and soon discovered that the network extension currently = requires the device to be supervised or use a specific type of Mobile = Device Management (MDM). I have requested that they lift this = restriction (radar=20 >=20 Sorry, sent that one too soon=E2=80=A6 continuing... radar 34843801) and if you have an Apple Developer account and would = like to see this functionality (NEDNSProxyManager), I encourage you to = submit your own bug report at https://developer.apple.com/bug-reporting/ = since they are more likely to take action if there are more requests to = do so. Thanks, Tom --Apple-Mail=_7C7EF6E8-E19F-434F-8400-EFCD272566E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 23, 2017, at 8:40 PM, Tom Pusateri <pusateri@bangj.com> = wrote:


On Oct 23, 2017, at 3:47 PM, Stephane Bortzmeyer <bortzmeyer@nic.fr> = wrote:

[There was a demo at the Bits-n-Bites in the last meeting, = Prague.]

https://www.xda-developers.com/android-dns-over-tls-website-pri= vacy/amp/

For those of you wondering about iOS = DNS privacy, Apple added a new DNS Proxy Network Extension in iOS 11 = that should allow all DNS requests to be proxied through a network = extension app. I began work on a TLS over DNS Proxy and soon discovered = that the network extension currently requires the device to be = supervised or use a specific type of Mobile Device Management (MDM). I = have requested that they lift this restriction (radar 


Sorry, sent that one too soon=E2=80=A6 = continuing...

radar 34843801) and if you have an Apple Developer = account and would like to see this functionality (NEDNSProxyManager), I = encourage you to submit your own bug report at

https://developer.apple.com/bug-reporting/

since they are more = likely to take action if there are more requests to do so.

Thanks,
Tom


= --Apple-Mail=_7C7EF6E8-E19F-434F-8400-EFCD272566E3-- From nobody Fri Oct 27 05:55:15 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C614B13F444 for ; Fri, 27 Oct 2017 05:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5] 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 CLsmy42sCP1y for ; Fri, 27 Oct 2017 05:55:12 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 07EA71394E4 for ; Fri, 27 Oct 2017 05:55:12 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 39507281DB3 for ; Fri, 27 Oct 2017 14:55:10 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id 3461E281DB8; Fri, 27 Oct 2017 14:55:10 +0200 (CEST) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 2DC4E281DB3 for ; Fri, 27 Oct 2017 14:55:10 +0200 (CEST) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 2A97F642A7A1 for ; Fri, 27 Oct 2017 14:55:10 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 24474409F5; Fri, 27 Oct 2017 14:55:10 +0200 (CEST) Date: Fri, 27 Oct 2017 14:55:10 +0200 From: Stephane Bortzmeyer To: dns-privacy@ietf.org Message-ID: <20171027125510.foq7xeiqft2vl7rx@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 9.1 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.062261, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.10.27.124217 Archived-At: Subject: [dns-privacy] Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 12:55:14 -0000 The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles has a DISCUSS "This needs to be updated to indicate that the client MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise you're going to have interop problems." The DISCUSS was against -09, the current version is -11 (1.5 months old) which does address the problem "A client MUST only indicate support for raw public keys if it has an SPKI pinset pre-configured (for interoperability reasons)." Therefore, what's the problem with draft-ietf-dprive-dtls-and-tls-profiles? From nobody Fri Oct 27 06:31:00 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9438A13A292 for ; Fri, 27 Oct 2017 06:30:58 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 7PZL_IQ3E1G7 for ; Fri, 27 Oct 2017 06:30:56 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E0913F516 for ; Fri, 27 Oct 2017 06:30:56 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 73F14880E3 for ; Fri, 27 Oct 2017 06:30:56 -0700 (PDT) Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 3B4A33280AE4 for ; Fri, 27 Oct 2017 06:30:56 -0700 (PDT) To: dns-privacy@ietf.org References: <20171027125510.foq7xeiqft2vl7rx@nic.fr> From: Brian Haberman Message-ID: Date: Fri, 27 Oct 2017 09:30:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171027125510.foq7xeiqft2vl7rx@nic.fr> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tgrtFUmOmvW4D3pJc5fHjmPrp98KIKIKu" Archived-At: Subject: Re: [dns-privacy] Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 13:30:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tgrtFUmOmvW4D3pJc5fHjmPrp98KIKIKu Content-Type: multipart/mixed; boundary="KtCFjeUhBOR30RWp4mwqJeH7hSuWAum25"; protected-headers="v1" From: Brian Haberman To: dns-privacy@ietf.org Message-ID: Subject: Re: [dns-privacy] Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked? References: <20171027125510.foq7xeiqft2vl7rx@nic.fr> In-Reply-To: <20171027125510.foq7xeiqft2vl7rx@nic.fr> --KtCFjeUhBOR30RWp4mwqJeH7hSuWAum25 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Stephane, On 10/27/17 8:55 AM, Stephane Bortzmeyer wrote: > The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles > has a DISCUSS "This needs to be updated to indicate that the client > MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise > you're going to have interop problems." The DISCUSS was against -09, > the current version is -11 (1.5 months old) which does address the > problem "A client MUST only indicate support for raw public keys if it > has an SPKI pinset pre-configured (for interoperability reasons)." >=20 > Therefore, what's the problem with > draft-ietf-dprive-dtls-and-tls-profiles? >=20 There was discussions with EKR over his issues and a revision published. EKR asked for a review by DKG before he would clear his DISCUSS. We are waiting on that review. Regards, Brian --KtCFjeUhBOR30RWp4mwqJeH7hSuWAum25-- --tgrtFUmOmvW4D3pJc5fHjmPrp98KIKIKu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZ8zUPAAoJEGjWPJxT0YthVZgP/RIjO6WLeHBCVGaQ8KuFvIro 6HrtDs776txV+J3gR/Pt92guHHV2Kpd9s69vGi8QJVp9ndpzIKJroFDwrmyFN+jB t8vBGBRgPS7IJlg96AY7gds8dyrjCyEQLjj6PjacRsdrfVpHqzUI6DAA7v+jRz/I 8GB3ANN//0JJp2Cdp/BG/8dkl50WouR5sdtNzOnOdeZXR4RI1E1WwQV8x+Pd7gEM Ybv9wHq8UnpfGtZWaB6rwYionU7+aNdRA0S1DDp3MdC5y7s2IMRLLU/mEsygM8vk /bUu/C4hQvvP3IDIBnlxPXZKkQ7xk9vPjorIeBdoLS0ugSIlDMCtT34QaqnzHKr4 gL9wEmF9np9MJH06exwZGYtbGBNlpfPSlPghEnwKrk3NuP+AGcBxpgUWMYxYDP/R DN0hLuTjPjRAh2MQ6mK66/+B61te28M52V+xzcFPxNt0lkFGvx5YspDG41ed9Qls S5n/jI8OwdabRywnPgq9F486tgcXJBRr1hiTB387042jFC2K2AfPAs3FdOJl1B+O mbTdI5IoYjkN1oYP2e3Di3fa/NNoCilpr4YXbjmMBrhtCw38q8U9nClI3ImailGt GZIAWv3TTPIFacdRJTs8MXPbBLUuM2MK4DAAGVtqKBRC4Ay3KmWpv2IyQ4mBD+HE x9OFeFjK6mpz9UnA+b8P =PKk2 -----END PGP SIGNATURE----- --tgrtFUmOmvW4D3pJc5fHjmPrp98KIKIKu-- From nobody Fri Oct 27 15:36:07 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A589313F5F4 for ; Fri, 27 Oct 2017 15:36:05 -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 WLg6XpE1V2Pb for ; Fri, 27 Oct 2017 15:36:04 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 84AE11397F3 for ; Fri, 27 Oct 2017 15:36:04 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 5ED26F99A; Fri, 27 Oct 2017 18:36:03 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id AB86920453; Fri, 27 Oct 2017 18:35:50 -0400 (EDT) From: Daniel Kahn Gillmor To: Brian Haberman , dns-privacy@ietf.org In-Reply-To: References: <20171027125510.foq7xeiqft2vl7rx@nic.fr> Date: Fri, 27 Oct 2017 18:35:50 -0400 Message-ID: <87k1zgfcc9.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dns-privacy] Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 22:36:06 -0000 On Fri 2017-10-27 09:30:43 -0400, Brian Haberman wrote: > Hi Stephane, > > On 10/27/17 8:55 AM, Stephane Bortzmeyer wrote: >> The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles >> has a DISCUSS "This needs to be updated to indicate that the client >> MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise >> you're going to have interop problems." The DISCUSS was against -09, >> the current version is -11 (1.5 months old) which does address the >> problem "A client MUST only indicate support for raw public keys if it >> has an SPKI pinset pre-configured (for interoperability reasons)." >> >> Therefore, what's the problem with >> draft-ietf-dprive-dtls-and-tls-profiles? >> > > There was discussions with EKR over his issues and a revision published. > EKR asked for a review by DKG before he would clear his DISCUSS. We are > waiting on that review. my apologies. I'm going through that now and hope to post a review to the list by tomorrow. --dkg From nobody Sat Oct 28 04:53:58 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730C213F7B1 for ; Sat, 28 Oct 2017 04:53:57 -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 un4vakzB2lFb for ; Sat, 28 Oct 2017 04:53:55 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7D61413F5EF for ; Sat, 28 Oct 2017 04:53:55 -0700 (PDT) Received: from fifthhorseman.net (unknown [195.69.55.100]) by che.mayfirst.org (Postfix) with ESMTPSA id DD39DF99E for ; Sat, 28 Oct 2017 07:53:53 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 670E220453; Fri, 27 Oct 2017 23:40:18 -0400 (EDT) From: Daniel Kahn Gillmor To: dns-privacy@ietf.org Date: Fri, 27 Oct 2017 23:40:15 -0400 Message-ID: <878tfwey8w.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 11:53:57 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey DPRIVE folks-- Apologies for the delay, and that this message is so long. I've tried to reconstruct this discussion around draft-ietf-dprive-dtls-and-tls-profiles-11 as best i can, and my analysis follows. If i've misundertood or misanalyzed something, please let me know. Summary =2D------ I do not believe that DNSSEC validation is warranted as a mitigation against an active attacker in the context of an opportunistic metaquery, regardless of whether the client ultimately intends to follow either the Strict or Opportunistic profile. Furthermore, i believe that the proposal in draft-11 of making DNSSEC validation of metaqueries a MUST for the opportunistic profile is *actively harmful* to the stated goal of the opportunistic profile (i.e., "maximum chance of DNS service"). I like the reorganization and re-wording of the "Usage Profiles" section in draft-11, and think we should keep it. But i think the other changes between draft-10 and draft-11 are unwarranted and should be reverted. Analysis =2D------- AIUI, the scenario under discussion is: * A DNS client (following either the strict or the opportunistic profile) * using opportunistic meta-queries to find the desired DNS resolver * in the face of an active attacker We already know that an attacker capable of filtering the client's *outbound* traffic can cause a denial of service (for clients following the strict profile) or loss of privacy (for clients following the opportunistic profile, because they fall back to cleartext) simply by dropping outbound connections to *anywhere* TCP port 853. Likewise, We also know that an attacker capable of filtering the client's *inbound* traffic can cause a denial of service (strict clients) or loss of privacy (opportunistic clients) simply by dropping inbound connections from any TCP port 853. But the introduction of an opportunistically-secured meta-query introduces a DoS attack (strict clients) or loss of privacy (opportunistic clients) that can be achieved by a weaker attacker. Since we're talking about an attacker that is *not* in control of the network, the following analysis assumes that the the network provides "legitimate" DHCP service, which is supposed to point the client to a "legitimate" standard DNS resolver (which may or may not be privacy-enabled, but is sufficient for answering an opportunistic metaquery correctly). In particular, the attacker needs only one of the following two capabilities: (a) Controlling the "legitimate" DHCP server, or detecting the client's DHCP request and racing the "legitimate" DHCP server to return a DHCP response (this allows the attacker to set the resolver used by the client for its opportunistic metaquery), or =20=20 (b) Controlling the "legitimate" DNS resolver, or detecting the client's opportunistic metaquery and racing the "legitimate" DNS resolver to provide a malicious DNS response. In either case, the result is that the attacker has poisoned the client's meta-cache -- its best guess at the location of the desired privacy-enabled DNS resolver. A poisoned meta-cache results in a DoS for clients in "Strict" mode because the attacker's answering DNS resolver at the learned address cannot authenticate. A poisoned meta-cache results in a loss of privacy for clients in "Opportunistic" mode because they will connect without authentication to the attacker's answering DNS resolver. Have i got that right? DNSSEC validation does not mitigate this attack. Regardless of the profile, the client has four options when it discovers that the response to the metadata query was forged (or at any rate is not validatable). It can: (0) ignore the response, resulting in a DoS regardless of profile, or =20=20 (1) ignore the validation failure, and try connecting to the proposed address anyway (resulting in a DoS for strict clients because the server does not validate, or a loss of privacy for opportunistic clients), or (2) retry the metaquery (in the hopes that their attacker is in class "b" and not in full control of the "legitimate" DNS resolver) and maybe the legitimate DNS response will come in, or (3) abort the network connection and retry DHCP (in the hopes that the attacker is in class "a" and not in full control of the "legitimate" DHCP server) and maybe the legitimate DHCP response will come in. Choice 0 is the same outcome as the non-DNSSEC-validating scenario for strict clients (no mitigation), and *strictly worse* for opportunistic clients, because it converts a loss of privacy to a DoS, which is in direct opposition to the stated goal of the opportunistic profile. Choice 1 is exactly the same outcome as the non-DNSSEC-validating scenario for all clients. (no mitigation) Choices 2 and 3 are interesting thought experiments, but are not directly contemplated in the draft (and i think they would be a distraction from the goal of the draft -- this draft is not "how to do staged opportunistic fallback in the face of an arbitrarily corrupt network"), so i won't go into them here. At best, DNSSEC validation of the metaquery could be used to provide additional reporting information to any client-internal auditing/reporting or other defensive measures; but again, this draft should not go into those in any detail. Background =2D--------- To be clear about where this analysis is coming from, my rule of thumb for these two profiles is: * Strict =20 Do whatever you can to connect to the preferred privacy-enabled resolver, but don't actually send queries unless you're sure you have authenticated the server. * Opportunistic Do whatever you can to connect to the preferred privacy-enabled resolver, but go ahead and send your queries to it anyway, even if it cannot be authenticated. Note that both modes can report (e.g., to a local system auditor/monitor/policy-agent) any failures or errors they encounter. But Strict mode will fail closed (DoS), and Opportunistic mode will fail open (loss of privacy). To be clear: the client is *locally configured* to be either in Strict or Opportunistic mode. Orthogonally, it is also locally configured with some server authentication information. If its locally-configured server authentication information is of the form "ADN" only, then -- even when configured in Strict mode -- it will do an Opportunistic DNS resolution of the address of the desired resolver. This is the "opportunistic meta-query". Many moons ago, ekr wrote: > I.e., if you determine whether to adopt a Strict policy based on > Opportunistic queries, then you are back to the active attack > setting. But the client is *not* determining whether to adopt a Strict policy based on the opportunistic meta-query. It has already decided which profile it is using, and the opportunistic meta-query merely to find the IP address of its desired privacy-enabled DNS resolver. So i guess i'm still DISCUSSing ekr's DISCUSS, which is an unfortunate state for the draft to be in. :( I welcome clarification if i've misunderstood the problem we're trying to address here, or if i've somehow let myself lapse into some sort of "privacy nihilism". --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlnz/B8ACgkQFJitxsGS MjfuTg/+M8uo6zXR5B57qCmj83v7xoxYpYVeod6LYmU2UFqiPGulyc7+0s8/fvOZ WMyQCUt9mUr1iBl89lcjzh+gtCz3vHMjO0+fdXfJ8kp0OVGZ6qa8zJj6CfRja69n KtqhrCtkIIQiTSQoUPN7Crh61wT9UBXC25CJQKsM6+Ze6QvuC8etgHfLzn+qQlIG EA15T0SkG+LMROmcfiSZIEzhZfTmfFpv++oR7vHVumZaRdlEcIbNbTd75ce4mC8y qPJvDa2PO4nzKzuij1sEiEgeRWm2GPu/4tZ6e+OY32C9OL1AJsvrQ7IYnNBD/ahz 6D8XTObKGA0PJIwNiMnY+RzlBw9/qfYFUXKhobA/Hzd97gg8sbtiUtGbXvxdowKj /j3mJxeyi4RGvIQZR237iCC4hvVYdhp36TQV9ywqPMTW1V24C3rQYywmpZK5UrI4 GqliJaar2lrsHCAiEy2cmrrAssBLwydWUPrzCRms3RC2KzAmdu2+3oh/id6YJsku xCFIKrnLc8XjwAPz73c1PN2jyA+1x6sJ5F1R7fIugPGoG65ZQ105m4Pj18t8eRgi tDBg5I7AmPuzv6D0I2eUhga52sy+74rEaaUrQmpQikEgFhz1WicFjRzBeLePYawI F53fuBkK7KqctUwWBJ7D/jf7TUbz7RIfplIizSgQVt9xWZfD1us= =NSWG -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 28 09:03:54 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D723013FB01 for ; Sat, 28 Oct 2017 09:03: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 L_YHuw5XYzgE for ; Sat, 28 Oct 2017 09:03:48 -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 0A34013FB19 for ; Sat, 28 Oct 2017 09:03:38 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id h142so2414874vkf.7 for ; Sat, 28 Oct 2017 09:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fzw9gxRCaoyt9fDKb7UHx0JYhQ1L4Z6A2yR0U5TMQcs=; b=iHqbz6KlaFko1BKXWpjinpvDtxkA19eAlMg3u15M89y6eP8EeEQYBSNMp0w9Fwoprt OAe8GO8gtoWX36XL5pKb6nbOEAWPiorB1TEqBpU15uUCKetuNh42ogXNKsFkkgq8Ep2X ukY6BXgAYlNMGw0B0DAz+ve2jWSlf1AUluKDQnmVKQS5O0pxsjkcosa4ALO6cR9WHPmW 2HAcxlPdbGXsR7YPxpZMJaMzTa7Re5o93btDJswwh5A//S/NjDURm5ETSvEpFWi8hTcX 7sh40SZtBPfrciIiB/SC3aCB0Ma1KisCVs1mhxBf25nfZLLONex/iVpuxP2gip0GyvMv TCcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fzw9gxRCaoyt9fDKb7UHx0JYhQ1L4Z6A2yR0U5TMQcs=; b=DF1S2l+XiOQbzIRM6b3Mcfvo7RPpew48snV2p4Ih2NOHX0u7zfZgFMh5NtO5gB6PQ1 cvVZ3M6aGL9k9l6uo3G0i6yuawhHUKsZxljQD6zrcM2w4o8B/966Pb9v1hj7GkoZ7shX 70KczxSAWMMBzVWFKfcmtb30mlpnw6exnZAsz9f1utGE1cQRN+t8QpEDpsYG+4FYoYH8 7VxAuK7CnyoNMgSn0dwGnrCEtKYylMcxHg8ky6wg6gD5rwempCDtDak+AWQWN5Mei9Ks 5nyJR/h/KHNl/B2DuXGMQ2qn2aeoo8htX84+pB41vdShJrlZ1TyXO/nXetCcQhHXXec8 ZJ9Q== X-Gm-Message-State: AMCzsaVULo2i5mmzxE7h1ZJHva6PKO17Vov3s1ZqJHSTxQ+KHt1EltA3 rvsAg0Cw5YTYvGM4MdFWRv+E0Uoxgg9/2fevzidaUpGL X-Google-Smtp-Source: ABhQp+T6m76FHm1sybhH0N6QFS0nb6CDSJJq2DBZQi81IaK5rtSn2BmLOZnMi07pTP9jnvSWHmg2GYe3sQLCBpsjOr4= X-Received: by 10.31.248.203 with SMTP id w194mr3012539vkh.85.1509206617505; Sat, 28 Oct 2017 09:03:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.145 with HTTP; Sat, 28 Oct 2017 09:03:36 -0700 (PDT) In-Reply-To: <878tfwey8w.fsf@fifthhorseman.net> References: <878tfwey8w.fsf@fifthhorseman.net> From: Ben Schwartz Date: Sat, 28 Oct 2017 12:03:36 -0400 Message-ID: To: Daniel Kahn Gillmor Cc: dns-privacy@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c14c6846046fa055c9d8ceb" Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 16:03:53 -0000 --94eb2c14c6846046fa055c9d8ceb Content-Type: multipart/alternative; boundary="94eb2c14c68454b515055c9d8cf5" --94eb2c14c68454b515055c9d8cf5 Content-Type: text/plain; charset="UTF-8" I agree with DKG's analysis. Also, as an implementor, I think this requirement would be onerous. In the software I am modifying, implementing DNS-over-TLS is dramatically easier than adding a validating stub resolver. I wouldn't be implementing DNS-over-TLS if DNSSEC were mandatory (in either mode). On Fri, Oct 27, 2017 at 11:40 PM, Daniel Kahn Gillmor wrote: > Hey DPRIVE folks-- > > Apologies for the delay, and that this message is so long. I've tried > to reconstruct this discussion around > draft-ietf-dprive-dtls-and-tls-profiles-11 as best i can, and my > analysis follows. If i've misundertood or misanalyzed something, > please let me know. > > Summary > ------- > > I do not believe that DNSSEC validation is warranted as a mitigation > against an active attacker in the context of an opportunistic metaquery, > regardless of whether the client ultimately intends to follow either the > Strict or Opportunistic profile. > > Furthermore, i believe that the proposal in draft-11 of making DNSSEC > validation of metaqueries a MUST for the opportunistic profile is > *actively harmful* to the stated goal of the opportunistic profile > (i.e., "maximum chance of DNS service"). > > I like the reorganization and re-wording of the "Usage Profiles" > section in draft-11, and think we should keep it. But i think the > other changes between draft-10 and draft-11 are unwarranted and should > be reverted. > > > Analysis > -------- > > AIUI, the scenario under discussion is: > > * A DNS client (following either the strict or the opportunistic > profile) > * using opportunistic meta-queries to find the desired DNS resolver > * in the face of an active attacker > > We already know that an attacker capable of filtering the client's > *outbound* traffic can cause a denial of service (for clients following > the strict profile) or loss of privacy (for clients following the > opportunistic profile, because they fall back to cleartext) simply by > dropping outbound connections to *anywhere* TCP port 853. > > Likewise, We also know that an attacker capable of filtering the > client's *inbound* traffic can cause a denial of service (strict > clients) or loss of privacy (opportunistic clients) simply by dropping > inbound connections from any TCP port 853. > > But the introduction of an opportunistically-secured meta-query > introduces a DoS attack (strict clients) or loss of privacy > (opportunistic clients) that can be achieved by a weaker attacker. > Since we're talking about an attacker that is *not* in control of the > network, the following analysis assumes that the the network provides > "legitimate" DHCP service, which is supposed to point the client to a > "legitimate" standard DNS resolver (which may or may not be > privacy-enabled, but is sufficient for answering an opportunistic > metaquery correctly). > > In particular, the attacker needs only one of the following two > capabilities: > > (a) Controlling the "legitimate" DHCP server, or detecting the > client's DHCP request and racing the "legitimate" DHCP server to > return a DHCP response (this allows the attacker to set the > resolver used by the client for its opportunistic metaquery), or > > (b) Controlling the "legitimate" DNS resolver, or detecting the > client's opportunistic metaquery and racing the "legitimate" DNS > resolver to provide a malicious DNS response. > > In either case, the result is that the attacker has poisoned the > client's meta-cache -- its best guess at the location of the desired > privacy-enabled DNS resolver. A poisoned meta-cache results in a DoS > for clients in "Strict" mode because the attacker's answering DNS > resolver at the learned address cannot authenticate. A poisoned > meta-cache results in a loss of privacy for clients in "Opportunistic" > mode because they will connect without authentication to the attacker's > answering DNS resolver. > > Have i got that right? > > DNSSEC validation does not mitigate this attack. > > Regardless of the profile, the client has four options when it > discovers that the response to the metadata query was forged (or at > any rate is not validatable). It can: > > (0) ignore the response, resulting in a DoS regardless of profile, > or > > (1) ignore the validation failure, and try connecting to the > proposed address anyway (resulting in a DoS for strict clients > because the server does not validate, or a loss of privacy for > opportunistic clients), or > > (2) retry the metaquery (in the hopes that their attacker is in class > "b" and not in full control of the "legitimate" DNS resolver) and > maybe the legitimate DNS response will come in, or > > (3) abort the network connection and retry DHCP (in the hopes that the > attacker is in class "a" and not in full control of the > "legitimate" DHCP server) and maybe the legitimate DHCP response > will come in. > > Choice 0 is the same outcome as the non-DNSSEC-validating scenario for > strict clients (no mitigation), and *strictly worse* for opportunistic > clients, because it converts a loss of privacy to a DoS, which is in > direct opposition to the stated goal of the opportunistic profile. > > Choice 1 is exactly the same outcome as the non-DNSSEC-validating > scenario for all clients. (no mitigation) > > Choices 2 and 3 are interesting thought experiments, but are not > directly contemplated in the draft (and i think they would be a > distraction from the goal of the draft -- this draft is not "how to do > staged opportunistic fallback in the face of an arbitrarily corrupt > network"), so i won't go into them here. > > At best, DNSSEC validation of the metaquery could be used to provide > additional reporting information to any client-internal > auditing/reporting or other defensive measures; but again, this draft > should not go into those in any detail. > > Background > ---------- > > To be clear about where this analysis is coming from, my rule of thumb > for these two profiles is: > > * Strict > > Do whatever you can to connect to the preferred privacy-enabled > resolver, but don't actually send queries unless you're sure you > have authenticated the server. > > * Opportunistic > > Do whatever you can to connect to the preferred privacy-enabled > resolver, but go ahead and send your queries to it anyway, even if > it cannot be authenticated. > > Note that both modes can report (e.g., to a local system > auditor/monitor/policy-agent) any failures or errors they encounter. > But Strict mode will fail closed (DoS), and Opportunistic mode will > fail open (loss of privacy). > > To be clear: the client is *locally configured* to be either in Strict > or Opportunistic mode. Orthogonally, it is also locally configured with > some server authentication information. > > If its locally-configured server authentication information is of the > form "ADN" only, then -- even when configured in Strict mode -- it > will do an Opportunistic DNS resolution of the address of the desired > resolver. This is the "opportunistic meta-query". > > Many moons ago, ekr wrote: > > > I.e., if you determine whether to adopt a Strict policy based on > > Opportunistic queries, then you are back to the active attack > > setting. > > But the client is *not* determining whether to adopt a Strict policy > based on the opportunistic meta-query. It has already decided which > profile it is using, and the opportunistic meta-query merely to find > the IP address of its desired privacy-enabled DNS resolver. > > > So i guess i'm still DISCUSSing ekr's DISCUSS, which is an unfortunate > state for the draft to be in. :( > > > I welcome clarification if i've misunderstood the problem we're trying > to address here, or if i've somehow let myself lapse into some sort of > "privacy nihilism". > > --dkg > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > > --94eb2c14c68454b515055c9d8cf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with DKG's analysis.

Also, = as an implementor, I think this requirement would be onerous.=C2=A0 In the = software I am modifying, implementing DNS-over-TLS is dramatically easier t= han adding a validating stub resolver.=C2=A0 I wouldn't be implementing= DNS-over-TLS if DNSSEC were mandatory (in either mode).

On Fri, Oct 27, 2017 at = 11:40 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wr= ote:
Hey DPRIVE folks--

Apologies for the delay, and that this message is so long.=C2=A0 I've t= ried
to reconstruct this discussion around
draft-ietf-dprive-dtls-and-tls-profiles-11 as best i can, and my
analysis follows.=C2=A0 If i've misundertood or misanalyzed something,<= br> please let me know.

Summary
-------

I do not believe that DNSSEC validation is warranted as a mitigation
against an active attacker in the context of an opportunistic metaquery, regardless of whether the client ultimately intends to follow either the Strict or Opportunistic profile.

Furthermore, i believe that the proposal in draft-11 of making DNSSEC
validation of metaqueries a MUST for the opportunistic profile is
*actively harmful* to the stated goal of the opportunistic profile
(i.e., "maximum chance of DNS service").

I like the reorganization and re-wording of the "Usage Profiles"<= br> section in draft-11, and think we should keep it.=C2=A0 But i think the
other changes between draft-10 and draft-11 are unwarranted and should
be reverted.


Analysis
--------

AIUI, the scenario under discussion is:

=C2=A0* A DNS client (following either the strict or the opportunistic
=C2=A0 =C2=A0profile)
=C2=A0* using opportunistic meta-queries to find the desired DNS resolver =C2=A0* in the face of an active attacker

We already know that an attacker capable of filtering the client's
*outbound* traffic can cause a denial of service (for clients following
the strict profile) or loss of privacy (for clients following the
opportunistic profile, because they fall back to cleartext) simply by
dropping outbound connections to *anywhere* TCP port 853.

Likewise, We also know that an attacker capable of filtering the
client's *inbound* traffic can cause a denial of service (strict
clients) or loss of privacy (opportunistic clients) simply by dropping
inbound connections from any TCP port 853.

But the introduction of an opportunistically-secured meta-query
introduces a DoS attack (strict clients) or loss of privacy
(opportunistic clients) that can be achieved by a weaker attacker.
Since we're talking about an attacker that is *not* in control of the network, the following analysis assumes that the the network provides
"legitimate" DHCP service, which is supposed to point the client = to a
"legitimate" standard DNS resolver (which may or may not be
privacy-enabled, but is sufficient for answering an opportunistic
metaquery correctly).

In particular, the attacker needs only one of the following two
capabilities:

=C2=A0 (a) Controlling the "legitimate" DHCP server, or detecting= the
=C2=A0 =C2=A0 =C2=A0 client's DHCP request and racing the "legitim= ate" DHCP server to
=C2=A0 =C2=A0 =C2=A0 return a DHCP response (this allows the attacker to se= t the
=C2=A0 =C2=A0 =C2=A0 resolver used by the client for its opportunistic meta= query), or

=C2=A0 (b) Controlling the "legitimate" DNS resolver, or detectin= g the
=C2=A0 =C2=A0 =C2=A0 client's opportunistic metaquery and racing the &q= uot;legitimate" DNS
=C2=A0 =C2=A0 =C2=A0 resolver to provide a malicious DNS response.

In either case, the result is that the attacker has poisoned the
client's meta-cache -- its best guess at the location of the desired privacy-enabled DNS resolver.=C2=A0 A poisoned meta-cache results in a DoS<= br> for clients in "Strict" mode because the attacker's answering= DNS
resolver at the learned address cannot authenticate.=C2=A0 A poisoned
meta-cache results in a loss of privacy for clients in "Opportunistic&= quot;
mode because they will connect without authentication to the attacker's=
answering DNS resolver.

Have i got that right?

DNSSEC validation does not mitigate this attack.

Regardless of the profile, the client has four options when it
discovers that the response to the metadata query was forged (or at
any rate is not validatable).=C2=A0 It can:

=C2=A0 (0) ignore the response, resulting in a DoS regardless of profile, =C2=A0 =C2=A0 =C2=A0 or

=C2=A0 (1) ignore the validation failure, and try connecting to the
=C2=A0 =C2=A0 =C2=A0 proposed address anyway (resulting in a DoS for strict= clients
=C2=A0 =C2=A0 =C2=A0 because the server does not validate, or a loss of pri= vacy for
=C2=A0 =C2=A0 =C2=A0 opportunistic clients), or

=C2=A0 (2) retry the metaquery (in the hopes that their attacker is in clas= s
=C2=A0 =C2=A0 =C2=A0 "b" and not in full control of the "leg= itimate" DNS resolver) and
=C2=A0 =C2=A0 =C2=A0 maybe the legitimate DNS response will come in, or

=C2=A0 (3) abort the network connection and retry DHCP (in the hopes that t= he
=C2=A0 =C2=A0 =C2=A0 attacker is in class "a" and not in full con= trol of the
=C2=A0 =C2=A0 =C2=A0 "legitimate" DHCP server) and maybe the legi= timate DHCP response
=C2=A0 =C2=A0 =C2=A0 will come in.

Choice 0 is the same outcome as the non-DNSSEC-validating scenario for
strict clients (no mitigation), and *strictly worse* for opportunistic
clients, because it converts a loss of privacy to a DoS, which is in
direct opposition to the stated goal of the opportunistic profile.

Choice 1 is exactly the same outcome as the non-DNSSEC-validating
scenario for all clients. (no mitigation)

Choices 2 and 3 are interesting thought experiments, but are not
directly contemplated in the draft (and i think they would be a
distraction from the goal of the draft -- this draft is not "how to do=
staged opportunistic fallback in the face of an arbitrarily corrupt
network"), so i won't go into them here.

At best, DNSSEC validation of the metaquery could be used to provide
additional reporting information to any client-internal
auditing/reporting or other defensive measures; but again, this draft
should not go into those in any detail.

Background
----------

To be clear about where this analysis is coming from, my rule of thumb
for these two profiles is:

=C2=A0* Strict

=C2=A0 =C2=A0Do whatever you can to connect to the preferred privacy-enable= d
=C2=A0 =C2=A0resolver, but don't actually send queries unless you'r= e sure you
=C2=A0 =C2=A0have authenticated the server.

=C2=A0* Opportunistic

=C2=A0 =C2=A0Do whatever you can to connect to the preferred privacy-enable= d
=C2=A0 =C2=A0resolver, but go ahead and send your queries to it anyway, eve= n if
=C2=A0 =C2=A0it cannot be authenticated.

Note that both modes can report (e.g., to a local system
auditor/monitor/policy-agent) any failures or errors they encounter.
But Strict mode will fail closed (DoS), and Opportunistic mode will
fail open (loss of privacy).

To be clear: the client is *locally configured* to be either in Strict
or Opportunistic mode.=C2=A0 Orthogonally, it is also locally configured wi= th
some server authentication information.

If its locally-configured server authentication information is of the
form "ADN" only, then -- even when configured in Strict mode -- i= t
will do an Opportunistic DNS resolution of the address of the desired
resolver.=C2=A0 This is the "opportunistic meta-query".

Many moons ago, ekr wrote:

> I.e., if you determine whether to adopt a Strict policy based on
> Opportunistic queries, then you are back to the active attack
> setting.

But the client is *not* determining whether to adopt a Strict policy
based on the opportunistic meta-query.=C2=A0 It has already decided which profile it is using, and the opportunistic meta-query merely to find
the IP address of its desired privacy-enabled DNS resolver.


So i guess i'm still DISCUSSing ekr's DISCUSS, which is an unfortun= ate
state for the draft to be in. :(


I welcome clarification if i've misunderstood the problem we're try= ing
to address here, or if i've somehow let myself lapse into some sort of<= br> "privacy nihilism".

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--dkg

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-priv= acy


--94eb2c14c68454b515055c9d8cf5-- --94eb2c14c6846046fa055c9d8ceb Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMEWk1v8tAoqKgb7TXMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDcxNjE4MDA1N1oXDTE4MDEx MjE4MDA1N1owIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDrrvmiOAZVIqT/TMjrb2h2F3pRDbwPjoYSzvDlNRXLUzcCg2CJ l36iW3dmk3Uk0b5/75WIQYoQmadF45yr6fGoxDn9+Qu6hik36Cfrnb8Ch8pnX2jC4gYmE91pm30t /WRb0Bfowu4grOB/zO0vDUZdjFxN/dji7A/mdsk7P5PGcnYxdpnjXSlPTEVxhmheji+DGiCJasrp NNm4883FD4rFnanXYdnCq7Aku1rkA++G+fTQd+9HxlypxSnhExAit0HqOIyCgajEMb+xtkNCHjDH FsOH9ruRqlSKc7FlOLvm2RALFx+U9AqWWx28lyEVhsdeFh6hpLEo+Ae8z8CJYs3zAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFBe3U8DtRm5koQ3yzeR81BIU+BjrMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBRIW5hM7R7/1ED1m6w QFXdOIBKubSej9FmVfD+f9Wv/6ak/8Fbk6ByRSzsScPGnkDT2U3MD20bGa+qp5BbEc3gFMi26AIo 7e/G5NlFY6ejl0qKt0xDqbTC+dBYocL/iEYEoAcr0ddFmnIm+tYzXSqSS9dLxPG/dlRo6OTLqtOm 9mExKPl/poRX59vajzNtGnR8gjHIKYCSsG9DdpYMxdQjbyLe71wv/ehtAUO5TcFQshSTtkqkL0y/ UJn76TjASXDDQE0Ndax1+xKdXaNBXFkhh7s/spJxkTrWAYIR+6Vs11eyRKxHo6yMHV+rN71AQm+P dXTVU6D7/eZUZaWxeAc+MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMEWk1v8tA oqKgb7TXMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAoG+EKy6oykAkP5mjojEjh i8872TwEfaXwLWguim4iajAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzEwMjgxNjAzMzhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEACGHSKNQg6twNL0XrbbOhIUFH+Sy50XGu4yTuCPHV oKqlyx/LXwGS9ml3bWOF/Ben9HVqS01neGSoa+pxbeV7rVFLMKDMKYD76MvDtqVJsHBdTqdD/jYO 7gJC70V/y4g6sLNlXwDU660aeGKyDMpLKdVVEm66/yIvLR8e9cuVWxZTIlQuolg02lorBW+2KZs+ enfWDX3PwzC8W5AO4XvNqakxrSFegM6WVYzg90bEDcuKwpxBGof5LThnqba61iAkDNq3nGvz855F kkvzEcdBuHR2891Zr/dc58XRb5xjHE8hz+BtzG4TPEqY8G++K9t/G2Txy3s/ocAXwbqXv5Ysmw== --94eb2c14c6846046fa055c9d8ceb-- From nobody Mon Oct 30 02:10:07 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13C313F8D6 for ; Mon, 30 Oct 2017 02:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 70c08JScTq11 for ; Mon, 30 Oct 2017 02:10:01 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 888CC13F601 for ; Mon, 30 Oct 2017 02:10:01 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509354600; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=L 6zar7yhDH++SSlAKy2/uQVySeAk/ijTQJypLlb57D Q=; b=VsNaBi89Ce3JtdnjVOdjjbjprQPksDTZOfIEAtXl0vkA AkUfuZJvk3WzMOXU/dXvmKQWMoeMfnkOQDAdHudV1BUBID3y1n 4EaMjHVQhulM5UM/kD4XecBWQ8JxyAhdu4GHlLlumJ+TlBZWKn AF7hOuFWvb7WpkPT+zH7xLoEQmw= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 53aa_4561_b187bce0_68a8_4f68_8dfe_e05f67108552; Mon, 30 Oct 2017 04:10:00 -0500 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 03:09:45 -0600 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 03:09:44 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 30 Oct 2017 03:09:44 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 03:09:43 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Mon, 30 Oct 2017 09:09:40 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 09:09:40 +0000 From: "Konda, Tirumaleswar Reddy" To: Ben Schwartz , Daniel Kahn Gillmor CC: "dns-privacy@ietf.org" Thread-Topic: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Thread-Index: AQHTT+N/U3oS1xfLdkyJreqW4BxYC6L5bNgAgAKwpGA= Date: Mon, 30 Oct 2017 09:09:40 +0000 Message-ID: References: <878tfwey8w.fsf@fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:e5ysot5EtMG0773w1NMF+IIsxcoMxBht2puB+j/y8KzbrRKqE3f1fUeaRP8HlopFNwgNcxlTdPuzIitzhuSlhTFNwaB12I7R1go18/Sfoxaoz5HylD1IL96EA9Lmj9r+YF/G9Dk43rIQvPfk69Qai+3VpVdtz4UvUCvzFqt4rIC08UX7dlB0ScgxCdNrUDnZ0rQuKbKVZPY0+/C1hdiz9K4FGl/g0pCd0QoMAQCPzfOlbqFJnRKM1OJznQGleouG5VLqapXl5XxkWojeOyqtROT16sdfaUX2G35Fm5jAIfAI9dxvffTzjYYBdbBf9U04cA/woA1UVSSJ2P8p3snfdh55esTeOYYREXhRWskxDMY=; 5:6ykMGywwosREeg2JdMIERh0ziwE9ghytXMaIrnG88E2nBAynYRQKfjMhDqC4PCODGKuurZO57N91asVxvOXXSr59R3N8rRdbgFw9PaD4mK3DausGHWHZkKIAEU48Mdz7aG2XP/m3TWrM0czXXMugeKmVH3eRenYI6KxpQJ5qzEg=; 24:IvLA0ssK2KjMczHjVxYZGaDIzTGuZvwyhefZ5oDAT6iISb3DmQFWw9/eGf9jNB62863qn7HtEYTjf2GZFcUIKgcm71MVxmuRal+dwE0s7gM=; 7:Hm2ToOLZT5nYNDYHalAxwBoXEcMdzU6Vg+m3g6KpLoaDWsT38hhMQe409nRP7750eBdW14vmcYjXJFN4mJyL/+5ZrA+CHt2elgb1tdlSLlPR0LELRs7Yfp+ymGF9bYBbpyr5w9IgYHkpiz1o0vltGfuJ0FF3s9zNVzptqGBlfE5DeGZaIH4W5+13ADrPhLRvwavekf5D5FNZvwEDW7Vi5zG1gBJIl/LjXUSwZa4q/D4CpxtSxM7Kp+9/aagiHcd0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8b585bb1-ec69-414a-a47e-08d51f75f3e0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603238); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(21532816269658)(211171220733660); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(32952001)(199003)(189002)(52314003)(24454002)(72206003)(99286003)(81156014)(25786009)(55016002)(229853002)(101416001)(50986999)(81166006)(76176999)(54356999)(80792005)(8676002)(561944003)(2906002)(53936002)(106356001)(230783001)(105586002)(236005)(6306002)(54896002)(9686003)(606006)(74316002)(3280700002)(8936002)(5660300001)(2900100001)(14454004)(3660700001)(77096006)(97736004)(86362001)(66066001)(6506006)(6436002)(110136005)(68736007)(478600001)(19609705001)(7696004)(316002)(966005)(4326008)(6116002)(102836003)(3846002)(790700001)(2950100002)(33656002)(6246003)(53546010)(189998001)(7736002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788102A02C9B188B915258EEA590DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8b585bb1-ec69-414a-a47e-08d51f75f3e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 09:09:40.5076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6146> : inlines <6150> : streams <1768836> : uri <2524759> Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 09:10:04 -0000 --_000_DM5PR16MB1788102A02C9B188B915258EEA590DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEsIEROU1NFQyBpdHNlbGYgaXMgc3VzY2VwdGlibGUgdG8gYWN0aXZlIGF0dGFja3MgYW5kIG5l ZWRzIGEgc2VjdXJlIGNoYW5uZWwgdG8gcHJvdGVjdCBmcm9tIGFuIGFjdGl2ZSBhdHRhY2tlci4N Cg0KLVRpcnUNCg0KRnJvbTogZG5zLXByaXZhY3kgW21haWx0bzpkbnMtcHJpdmFjeS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVuIFNjaHdhcnR6DQpTZW50OiBTYXR1cmRheSwgT2N0 b2JlciAyOCwgMjAxNyA5OjM0IFBNDQpUbzogRGFuaWVsIEthaG4gR2lsbG1vciA8ZGtnQGZpZnRo aG9yc2VtYW4ubmV0Pg0KQ2M6IGRucy1wcml2YWN5QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Ru cy1wcml2YWN5XSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXByb2Zp bGVzLTExOiB3ZSBzaG91bGQgcmV2ZXJ0IEROU1NFQyB2YWxpZGF0aW9uIHJlcXVpcmVtZW50DQoN CkkgYWdyZWUgd2l0aCBES0cncyBhbmFseXNpcy4NCg0KQWxzbywgYXMgYW4gaW1wbGVtZW50b3Is IEkgdGhpbmsgdGhpcyByZXF1aXJlbWVudCB3b3VsZCBiZSBvbmVyb3VzLiAgSW4gdGhlIHNvZnR3 YXJlIEkgYW0gbW9kaWZ5aW5nLCBpbXBsZW1lbnRpbmcgRE5TLW92ZXItVExTIGlzIGRyYW1hdGlj YWxseSBlYXNpZXIgdGhhbiBhZGRpbmcgYSB2YWxpZGF0aW5nIHN0dWIgcmVzb2x2ZXIuICBJIHdv dWxkbid0IGJlIGltcGxlbWVudGluZyBETlMtb3Zlci1UTFMgaWYgRE5TU0VDIHdlcmUgbWFuZGF0 b3J5IChpbiBlaXRoZXIgbW9kZSkuDQoNCk9uIEZyaSwgT2N0IDI3LCAyMDE3IGF0IDExOjQwIFBN LCBEYW5pZWwgS2FobiBHaWxsbW9yIDxka2dAZmlmdGhob3JzZW1hbi5uZXQ8bWFpbHRvOmRrZ0Bm aWZ0aGhvcnNlbWFuLm5ldD4+IHdyb3RlOg0KSGV5IERQUklWRSBmb2xrcy0tDQoNCkFwb2xvZ2ll cyBmb3IgdGhlIGRlbGF5LCBhbmQgdGhhdCB0aGlzIG1lc3NhZ2UgaXMgc28gbG9uZy4gIEkndmUg dHJpZWQNCnRvIHJlY29uc3RydWN0IHRoaXMgZGlzY3Vzc2lvbiBhcm91bmQNCmRyYWZ0LWlldGYt ZHByaXZlLWR0bHMtYW5kLXRscy1wcm9maWxlcy0xMSBhcyBiZXN0IGkgY2FuLCBhbmQgbXkNCmFu YWx5c2lzIGZvbGxvd3MuICBJZiBpJ3ZlIG1pc3VuZGVydG9vZCBvciBtaXNhbmFseXplZCBzb21l dGhpbmcsDQpwbGVhc2UgbGV0IG1lIGtub3cuDQoNClN1bW1hcnkNCi0tLS0tLS0NCg0KSSBkbyBu b3QgYmVsaWV2ZSB0aGF0IEROU1NFQyB2YWxpZGF0aW9uIGlzIHdhcnJhbnRlZCBhcyBhIG1pdGln YXRpb24NCmFnYWluc3QgYW4gYWN0aXZlIGF0dGFja2VyIGluIHRoZSBjb250ZXh0IG9mIGFuIG9w cG9ydHVuaXN0aWMgbWV0YXF1ZXJ5LA0KcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBjbGllbnQg dWx0aW1hdGVseSBpbnRlbmRzIHRvIGZvbGxvdyBlaXRoZXIgdGhlDQpTdHJpY3Qgb3IgT3Bwb3J0 dW5pc3RpYyBwcm9maWxlLg0KDQpGdXJ0aGVybW9yZSwgaSBiZWxpZXZlIHRoYXQgdGhlIHByb3Bv c2FsIGluIGRyYWZ0LTExIG9mIG1ha2luZyBETlNTRUMNCnZhbGlkYXRpb24gb2YgbWV0YXF1ZXJp ZXMgYSBNVVNUIGZvciB0aGUgb3Bwb3J0dW5pc3RpYyBwcm9maWxlIGlzDQoqYWN0aXZlbHkgaGFy bWZ1bCogdG8gdGhlIHN0YXRlZCBnb2FsIG9mIHRoZSBvcHBvcnR1bmlzdGljIHByb2ZpbGUNCihp LmUuLCAibWF4aW11bSBjaGFuY2Ugb2YgRE5TIHNlcnZpY2UiKS4NCg0KSSBsaWtlIHRoZSByZW9y Z2FuaXphdGlvbiBhbmQgcmUtd29yZGluZyBvZiB0aGUgIlVzYWdlIFByb2ZpbGVzIg0Kc2VjdGlv biBpbiBkcmFmdC0xMSwgYW5kIHRoaW5rIHdlIHNob3VsZCBrZWVwIGl0LiAgQnV0IGkgdGhpbmsg dGhlDQpvdGhlciBjaGFuZ2VzIGJldHdlZW4gZHJhZnQtMTAgYW5kIGRyYWZ0LTExIGFyZSB1bndh cnJhbnRlZCBhbmQgc2hvdWxkDQpiZSByZXZlcnRlZC4NCg0KDQpBbmFseXNpcw0KLS0tLS0tLS0N Cg0KQUlVSSwgdGhlIHNjZW5hcmlvIHVuZGVyIGRpc2N1c3Npb24gaXM6DQoNCiAqIEEgRE5TIGNs aWVudCAoZm9sbG93aW5nIGVpdGhlciB0aGUgc3RyaWN0IG9yIHRoZSBvcHBvcnR1bmlzdGljDQog ICBwcm9maWxlKQ0KICogdXNpbmcgb3Bwb3J0dW5pc3RpYyBtZXRhLXF1ZXJpZXMgdG8gZmluZCB0 aGUgZGVzaXJlZCBETlMgcmVzb2x2ZXINCiAqIGluIHRoZSBmYWNlIG9mIGFuIGFjdGl2ZSBhdHRh Y2tlcg0KDQpXZSBhbHJlYWR5IGtub3cgdGhhdCBhbiBhdHRhY2tlciBjYXBhYmxlIG9mIGZpbHRl cmluZyB0aGUgY2xpZW50J3MNCipvdXRib3VuZCogdHJhZmZpYyBjYW4gY2F1c2UgYSBkZW5pYWwg b2Ygc2VydmljZSAoZm9yIGNsaWVudHMgZm9sbG93aW5nDQp0aGUgc3RyaWN0IHByb2ZpbGUpIG9y IGxvc3Mgb2YgcHJpdmFjeSAoZm9yIGNsaWVudHMgZm9sbG93aW5nIHRoZQ0Kb3Bwb3J0dW5pc3Rp YyBwcm9maWxlLCBiZWNhdXNlIHRoZXkgZmFsbCBiYWNrIHRvIGNsZWFydGV4dCkgc2ltcGx5IGJ5 DQpkcm9wcGluZyBvdXRib3VuZCBjb25uZWN0aW9ucyB0byAqYW55d2hlcmUqIFRDUCBwb3J0IDg1 My4NCg0KTGlrZXdpc2UsIFdlIGFsc28ga25vdyB0aGF0IGFuIGF0dGFja2VyIGNhcGFibGUgb2Yg ZmlsdGVyaW5nIHRoZQ0KY2xpZW50J3MgKmluYm91bmQqIHRyYWZmaWMgY2FuIGNhdXNlIGEgZGVu aWFsIG9mIHNlcnZpY2UgKHN0cmljdA0KY2xpZW50cykgb3IgbG9zcyBvZiBwcml2YWN5IChvcHBv cnR1bmlzdGljIGNsaWVudHMpIHNpbXBseSBieSBkcm9wcGluZw0KaW5ib3VuZCBjb25uZWN0aW9u cyBmcm9tIGFueSBUQ1AgcG9ydCA4NTMuDQoNCkJ1dCB0aGUgaW50cm9kdWN0aW9uIG9mIGFuIG9w cG9ydHVuaXN0aWNhbGx5LXNlY3VyZWQgbWV0YS1xdWVyeQ0KaW50cm9kdWNlcyBhIERvUyBhdHRh Y2sgKHN0cmljdCBjbGllbnRzKSBvciBsb3NzIG9mIHByaXZhY3kNCihvcHBvcnR1bmlzdGljIGNs aWVudHMpIHRoYXQgY2FuIGJlIGFjaGlldmVkIGJ5IGEgd2Vha2VyIGF0dGFja2VyLg0KU2luY2Ug d2UncmUgdGFsa2luZyBhYm91dCBhbiBhdHRhY2tlciB0aGF0IGlzICpub3QqIGluIGNvbnRyb2wg b2YgdGhlDQpuZXR3b3JrLCB0aGUgZm9sbG93aW5nIGFuYWx5c2lzIGFzc3VtZXMgdGhhdCB0aGUg dGhlIG5ldHdvcmsgcHJvdmlkZXMNCiJsZWdpdGltYXRlIiBESENQIHNlcnZpY2UsIHdoaWNoIGlz IHN1cHBvc2VkIHRvIHBvaW50IHRoZSBjbGllbnQgdG8gYQ0KImxlZ2l0aW1hdGUiIHN0YW5kYXJk IEROUyByZXNvbHZlciAod2hpY2ggbWF5IG9yIG1heSBub3QgYmUNCnByaXZhY3ktZW5hYmxlZCwg YnV0IGlzIHN1ZmZpY2llbnQgZm9yIGFuc3dlcmluZyBhbiBvcHBvcnR1bmlzdGljDQptZXRhcXVl cnkgY29ycmVjdGx5KS4NCg0KSW4gcGFydGljdWxhciwgdGhlIGF0dGFja2VyIG5lZWRzIG9ubHkg b25lIG9mIHRoZSBmb2xsb3dpbmcgdHdvDQpjYXBhYmlsaXRpZXM6DQoNCiAgKGEpIENvbnRyb2xs aW5nIHRoZSAibGVnaXRpbWF0ZSIgREhDUCBzZXJ2ZXIsIG9yIGRldGVjdGluZyB0aGUNCiAgICAg IGNsaWVudCdzIERIQ1AgcmVxdWVzdCBhbmQgcmFjaW5nIHRoZSAibGVnaXRpbWF0ZSIgREhDUCBz ZXJ2ZXIgdG8NCiAgICAgIHJldHVybiBhIERIQ1AgcmVzcG9uc2UgKHRoaXMgYWxsb3dzIHRoZSBh dHRhY2tlciB0byBzZXQgdGhlDQogICAgICByZXNvbHZlciB1c2VkIGJ5IHRoZSBjbGllbnQgZm9y IGl0cyBvcHBvcnR1bmlzdGljIG1ldGFxdWVyeSksIG9yDQoNCiAgKGIpIENvbnRyb2xsaW5nIHRo ZSAibGVnaXRpbWF0ZSIgRE5TIHJlc29sdmVyLCBvciBkZXRlY3RpbmcgdGhlDQogICAgICBjbGll bnQncyBvcHBvcnR1bmlzdGljIG1ldGFxdWVyeSBhbmQgcmFjaW5nIHRoZSAibGVnaXRpbWF0ZSIg RE5TDQogICAgICByZXNvbHZlciB0byBwcm92aWRlIGEgbWFsaWNpb3VzIEROUyByZXNwb25zZS4N Cg0KSW4gZWl0aGVyIGNhc2UsIHRoZSByZXN1bHQgaXMgdGhhdCB0aGUgYXR0YWNrZXIgaGFzIHBv aXNvbmVkIHRoZQ0KY2xpZW50J3MgbWV0YS1jYWNoZSAtLSBpdHMgYmVzdCBndWVzcyBhdCB0aGUg bG9jYXRpb24gb2YgdGhlIGRlc2lyZWQNCnByaXZhY3ktZW5hYmxlZCBETlMgcmVzb2x2ZXIuICBB IHBvaXNvbmVkIG1ldGEtY2FjaGUgcmVzdWx0cyBpbiBhIERvUw0KZm9yIGNsaWVudHMgaW4gIlN0 cmljdCIgbW9kZSBiZWNhdXNlIHRoZSBhdHRhY2tlcidzIGFuc3dlcmluZyBETlMNCnJlc29sdmVy IGF0IHRoZSBsZWFybmVkIGFkZHJlc3MgY2Fubm90IGF1dGhlbnRpY2F0ZS4gIEEgcG9pc29uZWQN Cm1ldGEtY2FjaGUgcmVzdWx0cyBpbiBhIGxvc3Mgb2YgcHJpdmFjeSBmb3IgY2xpZW50cyBpbiAi T3Bwb3J0dW5pc3RpYyINCm1vZGUgYmVjYXVzZSB0aGV5IHdpbGwgY29ubmVjdCB3aXRob3V0IGF1 dGhlbnRpY2F0aW9uIHRvIHRoZSBhdHRhY2tlcidzDQphbnN3ZXJpbmcgRE5TIHJlc29sdmVyLg0K DQpIYXZlIGkgZ290IHRoYXQgcmlnaHQ/DQoNCkROU1NFQyB2YWxpZGF0aW9uIGRvZXMgbm90IG1p dGlnYXRlIHRoaXMgYXR0YWNrLg0KDQpSZWdhcmRsZXNzIG9mIHRoZSBwcm9maWxlLCB0aGUgY2xp ZW50IGhhcyBmb3VyIG9wdGlvbnMgd2hlbiBpdA0KZGlzY292ZXJzIHRoYXQgdGhlIHJlc3BvbnNl IHRvIHRoZSBtZXRhZGF0YSBxdWVyeSB3YXMgZm9yZ2VkIChvciBhdA0KYW55IHJhdGUgaXMgbm90 IHZhbGlkYXRhYmxlKS4gIEl0IGNhbjoNCg0KICAoMCkgaWdub3JlIHRoZSByZXNwb25zZSwgcmVz dWx0aW5nIGluIGEgRG9TIHJlZ2FyZGxlc3Mgb2YgcHJvZmlsZSwNCiAgICAgIG9yDQoNCiAgKDEp IGlnbm9yZSB0aGUgdmFsaWRhdGlvbiBmYWlsdXJlLCBhbmQgdHJ5IGNvbm5lY3RpbmcgdG8gdGhl DQogICAgICBwcm9wb3NlZCBhZGRyZXNzIGFueXdheSAocmVzdWx0aW5nIGluIGEgRG9TIGZvciBz dHJpY3QgY2xpZW50cw0KICAgICAgYmVjYXVzZSB0aGUgc2VydmVyIGRvZXMgbm90IHZhbGlkYXRl LCBvciBhIGxvc3Mgb2YgcHJpdmFjeSBmb3INCiAgICAgIG9wcG9ydHVuaXN0aWMgY2xpZW50cyks IG9yDQoNCiAgKDIpIHJldHJ5IHRoZSBtZXRhcXVlcnkgKGluIHRoZSBob3BlcyB0aGF0IHRoZWly IGF0dGFja2VyIGlzIGluIGNsYXNzDQogICAgICAiYiIgYW5kIG5vdCBpbiBmdWxsIGNvbnRyb2wg b2YgdGhlICJsZWdpdGltYXRlIiBETlMgcmVzb2x2ZXIpIGFuZA0KICAgICAgbWF5YmUgdGhlIGxl Z2l0aW1hdGUgRE5TIHJlc3BvbnNlIHdpbGwgY29tZSBpbiwgb3INCg0KICAoMykgYWJvcnQgdGhl IG5ldHdvcmsgY29ubmVjdGlvbiBhbmQgcmV0cnkgREhDUCAoaW4gdGhlIGhvcGVzIHRoYXQgdGhl DQogICAgICBhdHRhY2tlciBpcyBpbiBjbGFzcyAiYSIgYW5kIG5vdCBpbiBmdWxsIGNvbnRyb2wg b2YgdGhlDQogICAgICAibGVnaXRpbWF0ZSIgREhDUCBzZXJ2ZXIpIGFuZCBtYXliZSB0aGUgbGVn aXRpbWF0ZSBESENQIHJlc3BvbnNlDQogICAgICB3aWxsIGNvbWUgaW4uDQoNCkNob2ljZSAwIGlz IHRoZSBzYW1lIG91dGNvbWUgYXMgdGhlIG5vbi1ETlNTRUMtdmFsaWRhdGluZyBzY2VuYXJpbyBm b3INCnN0cmljdCBjbGllbnRzIChubyBtaXRpZ2F0aW9uKSwgYW5kICpzdHJpY3RseSB3b3JzZSog Zm9yIG9wcG9ydHVuaXN0aWMNCmNsaWVudHMsIGJlY2F1c2UgaXQgY29udmVydHMgYSBsb3NzIG9m IHByaXZhY3kgdG8gYSBEb1MsIHdoaWNoIGlzIGluDQpkaXJlY3Qgb3Bwb3NpdGlvbiB0byB0aGUg c3RhdGVkIGdvYWwgb2YgdGhlIG9wcG9ydHVuaXN0aWMgcHJvZmlsZS4NCg0KQ2hvaWNlIDEgaXMg ZXhhY3RseSB0aGUgc2FtZSBvdXRjb21lIGFzIHRoZSBub24tRE5TU0VDLXZhbGlkYXRpbmcNCnNj ZW5hcmlvIGZvciBhbGwgY2xpZW50cy4gKG5vIG1pdGlnYXRpb24pDQoNCkNob2ljZXMgMiBhbmQg MyBhcmUgaW50ZXJlc3RpbmcgdGhvdWdodCBleHBlcmltZW50cywgYnV0IGFyZSBub3QNCmRpcmVj dGx5IGNvbnRlbXBsYXRlZCBpbiB0aGUgZHJhZnQgKGFuZCBpIHRoaW5rIHRoZXkgd291bGQgYmUg YQ0KZGlzdHJhY3Rpb24gZnJvbSB0aGUgZ29hbCBvZiB0aGUgZHJhZnQgLS0gdGhpcyBkcmFmdCBp cyBub3QgImhvdyB0byBkbw0Kc3RhZ2VkIG9wcG9ydHVuaXN0aWMgZmFsbGJhY2sgaW4gdGhlIGZh Y2Ugb2YgYW4gYXJiaXRyYXJpbHkgY29ycnVwdA0KbmV0d29yayIpLCBzbyBpIHdvbid0IGdvIGlu dG8gdGhlbSBoZXJlLg0KDQpBdCBiZXN0LCBETlNTRUMgdmFsaWRhdGlvbiBvZiB0aGUgbWV0YXF1 ZXJ5IGNvdWxkIGJlIHVzZWQgdG8gcHJvdmlkZQ0KYWRkaXRpb25hbCByZXBvcnRpbmcgaW5mb3Jt YXRpb24gdG8gYW55IGNsaWVudC1pbnRlcm5hbA0KYXVkaXRpbmcvcmVwb3J0aW5nIG9yIG90aGVy IGRlZmVuc2l2ZSBtZWFzdXJlczsgYnV0IGFnYWluLCB0aGlzIGRyYWZ0DQpzaG91bGQgbm90IGdv IGludG8gdGhvc2UgaW4gYW55IGRldGFpbC4NCg0KQmFja2dyb3VuZA0KLS0tLS0tLS0tLQ0KDQpU byBiZSBjbGVhciBhYm91dCB3aGVyZSB0aGlzIGFuYWx5c2lzIGlzIGNvbWluZyBmcm9tLCBteSBy dWxlIG9mIHRodW1iDQpmb3IgdGhlc2UgdHdvIHByb2ZpbGVzIGlzOg0KDQogKiBTdHJpY3QNCg0K ICAgRG8gd2hhdGV2ZXIgeW91IGNhbiB0byBjb25uZWN0IHRvIHRoZSBwcmVmZXJyZWQgcHJpdmFj eS1lbmFibGVkDQogICByZXNvbHZlciwgYnV0IGRvbid0IGFjdHVhbGx5IHNlbmQgcXVlcmllcyB1 bmxlc3MgeW91J3JlIHN1cmUgeW91DQogICBoYXZlIGF1dGhlbnRpY2F0ZWQgdGhlIHNlcnZlci4N Cg0KICogT3Bwb3J0dW5pc3RpYw0KDQogICBEbyB3aGF0ZXZlciB5b3UgY2FuIHRvIGNvbm5lY3Qg dG8gdGhlIHByZWZlcnJlZCBwcml2YWN5LWVuYWJsZWQNCiAgIHJlc29sdmVyLCBidXQgZ28gYWhl YWQgYW5kIHNlbmQgeW91ciBxdWVyaWVzIHRvIGl0IGFueXdheSwgZXZlbiBpZg0KICAgaXQgY2Fu bm90IGJlIGF1dGhlbnRpY2F0ZWQuDQoNCk5vdGUgdGhhdCBib3RoIG1vZGVzIGNhbiByZXBvcnQg KGUuZy4sIHRvIGEgbG9jYWwgc3lzdGVtDQphdWRpdG9yL21vbml0b3IvcG9saWN5LWFnZW50KSBh bnkgZmFpbHVyZXMgb3IgZXJyb3JzIHRoZXkgZW5jb3VudGVyLg0KQnV0IFN0cmljdCBtb2RlIHdp bGwgZmFpbCBjbG9zZWQgKERvUyksIGFuZCBPcHBvcnR1bmlzdGljIG1vZGUgd2lsbA0KZmFpbCBv cGVuIChsb3NzIG9mIHByaXZhY3kpLg0KDQpUbyBiZSBjbGVhcjogdGhlIGNsaWVudCBpcyAqbG9j YWxseSBjb25maWd1cmVkKiB0byBiZSBlaXRoZXIgaW4gU3RyaWN0DQpvciBPcHBvcnR1bmlzdGlj IG1vZGUuICBPcnRob2dvbmFsbHksIGl0IGlzIGFsc28gbG9jYWxseSBjb25maWd1cmVkIHdpdGgN CnNvbWUgc2VydmVyIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uLg0KDQpJZiBpdHMgbG9jYWxs eS1jb25maWd1cmVkIHNlcnZlciBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlvbiBpcyBvZiB0aGUN CmZvcm0gIkFETiIgb25seSwgdGhlbiAtLSBldmVuIHdoZW4gY29uZmlndXJlZCBpbiBTdHJpY3Qg bW9kZSAtLSBpdA0Kd2lsbCBkbyBhbiBPcHBvcnR1bmlzdGljIEROUyByZXNvbHV0aW9uIG9mIHRo ZSBhZGRyZXNzIG9mIHRoZSBkZXNpcmVkDQpyZXNvbHZlci4gIFRoaXMgaXMgdGhlICJvcHBvcnR1 bmlzdGljIG1ldGEtcXVlcnkiLg0KDQpNYW55IG1vb25zIGFnbywgZWtyIHdyb3RlOg0KDQo+IEku ZS4sIGlmIHlvdSBkZXRlcm1pbmUgd2hldGhlciB0byBhZG9wdCBhIFN0cmljdCBwb2xpY3kgYmFz ZWQgb24NCj4gT3Bwb3J0dW5pc3RpYyBxdWVyaWVzLCB0aGVuIHlvdSBhcmUgYmFjayB0byB0aGUg YWN0aXZlIGF0dGFjaw0KPiBzZXR0aW5nLg0KDQpCdXQgdGhlIGNsaWVudCBpcyAqbm90KiBkZXRl cm1pbmluZyB3aGV0aGVyIHRvIGFkb3B0IGEgU3RyaWN0IHBvbGljeQ0KYmFzZWQgb24gdGhlIG9w cG9ydHVuaXN0aWMgbWV0YS1xdWVyeS4gIEl0IGhhcyBhbHJlYWR5IGRlY2lkZWQgd2hpY2gNCnBy b2ZpbGUgaXQgaXMgdXNpbmcsIGFuZCB0aGUgb3Bwb3J0dW5pc3RpYyBtZXRhLXF1ZXJ5IG1lcmVs eSB0byBmaW5kDQp0aGUgSVAgYWRkcmVzcyBvZiBpdHMgZGVzaXJlZCBwcml2YWN5LWVuYWJsZWQg RE5TIHJlc29sdmVyLg0KDQoNClNvIGkgZ3Vlc3MgaSdtIHN0aWxsIERJU0NVU1NpbmcgZWtyJ3Mg RElTQ1VTUywgd2hpY2ggaXMgYW4gdW5mb3J0dW5hdGUNCnN0YXRlIGZvciB0aGUgZHJhZnQgdG8g YmUgaW4uIDooDQoNCg0KSSB3ZWxjb21lIGNsYXJpZmljYXRpb24gaWYgaSd2ZSBtaXN1bmRlcnN0 b29kIHRoZSBwcm9ibGVtIHdlJ3JlIHRyeWluZw0KdG8gYWRkcmVzcyBoZXJlLCBvciBpZiBpJ3Zl IHNvbWVob3cgbGV0IG15c2VsZiBsYXBzZSBpbnRvIHNvbWUgc29ydCBvZg0KInByaXZhY3kgbmlo aWxpc20iLg0KDQogICAgICAgICAtLWRrZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KZG5zLXByaXZhY3kgbWFpbGluZyBsaXN0DQpkbnMtcHJpdmFj eUBpZXRmLm9yZzxtYWlsdG86ZG5zLXByaXZhY3lAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rucy1wcml2YWN5DQoNCg== --_000_DM5PR16MB1788102A02C9B188B915258EEA590DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mIzQzOzEsIEROU1NFQyBpdHNlbGYg aXMgc3VzY2VwdGlibGUgdG8gYWN0aXZlIGF0dGFja3MgYW5kIG5lZWRzIGEgc2VjdXJlIGNoYW5u ZWwgdG8gcHJvdGVjdCBmcm9tIGFuIGFjdGl2ZSBhdHRhY2tlci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LVRp cnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJf TWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3Nw YW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGRucy1wcml2YWN5IFttYWlsdG86ZG5zLXByaXZhY3kt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVuIFNjaHdhcnR6PGJyPg0K PGI+U2VudDo8L2I+IFNhdHVyZGF5LCBPY3RvYmVyIDI4LCAyMDE3IDk6MzQgUE08YnI+DQo8Yj5U bzo8L2I+IERhbmllbCBLYWhuIEdpbGxtb3IgJmx0O2RrZ0BmaWZ0aGhvcnNlbWFuLm5ldCZndDs8 YnI+DQo8Yj5DYzo8L2I+IGRucy1wcml2YWN5QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbZG5zLXByaXZhY3ldIHJldmlldyBvZiBkcmFmdC1pZXRmLWRwcml2ZS1kdGxzLWFuZC10 bHMtcHJvZmlsZXMtMTE6IHdlIHNob3VsZCByZXZlcnQgRE5TU0VDIHZhbGlkYXRpb24gcmVxdWly ZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBhZ3JlZSB3aXRoIERLRydzIGFuYWx5c2lzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgYXMgYW4gaW1wbGVtZW50b3IsIEkgdGhpbmsgdGhp cyByZXF1aXJlbWVudCB3b3VsZCBiZSBvbmVyb3VzLiZuYnNwOyBJbiB0aGUgc29mdHdhcmUgSSBh bSBtb2RpZnlpbmcsIGltcGxlbWVudGluZyBETlMtb3Zlci1UTFMgaXMgZHJhbWF0aWNhbGx5IGVh c2llciB0aGFuIGFkZGluZyBhIHZhbGlkYXRpbmcgc3R1YiByZXNvbHZlci4mbmJzcDsgSSB3b3Vs ZG4ndCBiZSBpbXBsZW1lbnRpbmcgRE5TLW92ZXItVExTIGlmIEROU1NFQw0KIHdlcmUgbWFuZGF0 b3J5IChpbiBlaXRoZXIgbW9kZSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgT2N0IDI3LCAyMDE3IGF0IDExOjQwIFBNLCBEYW5p ZWwgS2FobiBHaWxsbW9yICZsdDs8YSBocmVmPSJtYWlsdG86ZGtnQGZpZnRoaG9yc2VtYW4ubmV0 IiB0YXJnZXQ9Il9ibGFuayI+ZGtnQGZpZnRoaG9yc2VtYW4ubmV0PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5IZXkgRFBSSVZFIGZvbGtzLS08YnI+DQo8YnI+DQpBcG9sb2dp ZXMgZm9yIHRoZSBkZWxheSwgYW5kIHRoYXQgdGhpcyBtZXNzYWdlIGlzIHNvIGxvbmcuJm5ic3A7 IEkndmUgdHJpZWQ8YnI+DQp0byByZWNvbnN0cnVjdCB0aGlzIGRpc2N1c3Npb24gYXJvdW5kPGJy Pg0KZHJhZnQtaWV0Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXByb2ZpbGVzLTExIGFzIGJlc3QgaSBj YW4sIGFuZCBteTxicj4NCmFuYWx5c2lzIGZvbGxvd3MuJm5ic3A7IElmIGkndmUgbWlzdW5kZXJ0 b29kIG9yIG1pc2FuYWx5emVkIHNvbWV0aGluZyw8YnI+DQpwbGVhc2UgbGV0IG1lIGtub3cuPGJy Pg0KPGJyPg0KU3VtbWFyeTxicj4NCi0tLS0tLS08YnI+DQo8YnI+DQpJIGRvIG5vdCBiZWxpZXZl IHRoYXQgRE5TU0VDIHZhbGlkYXRpb24gaXMgd2FycmFudGVkIGFzIGEgbWl0aWdhdGlvbjxicj4N CmFnYWluc3QgYW4gYWN0aXZlIGF0dGFja2VyIGluIHRoZSBjb250ZXh0IG9mIGFuIG9wcG9ydHVu aXN0aWMgbWV0YXF1ZXJ5LDxicj4NCnJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgY2xpZW50IHVs dGltYXRlbHkgaW50ZW5kcyB0byBmb2xsb3cgZWl0aGVyIHRoZTxicj4NClN0cmljdCBvciBPcHBv cnR1bmlzdGljIHByb2ZpbGUuPGJyPg0KPGJyPg0KRnVydGhlcm1vcmUsIGkgYmVsaWV2ZSB0aGF0 IHRoZSBwcm9wb3NhbCBpbiBkcmFmdC0xMSBvZiBtYWtpbmcgRE5TU0VDPGJyPg0KdmFsaWRhdGlv biBvZiBtZXRhcXVlcmllcyBhIE1VU1QgZm9yIHRoZSBvcHBvcnR1bmlzdGljIHByb2ZpbGUgaXM8 YnI+DQoqYWN0aXZlbHkgaGFybWZ1bCogdG8gdGhlIHN0YXRlZCBnb2FsIG9mIHRoZSBvcHBvcnR1 bmlzdGljIHByb2ZpbGU8YnI+DQooaS5lLiwgJnF1b3Q7bWF4aW11bSBjaGFuY2Ugb2YgRE5TIHNl cnZpY2UmcXVvdDspLjxicj4NCjxicj4NCkkgbGlrZSB0aGUgcmVvcmdhbml6YXRpb24gYW5kIHJl LXdvcmRpbmcgb2YgdGhlICZxdW90O1VzYWdlIFByb2ZpbGVzJnF1b3Q7PGJyPg0Kc2VjdGlvbiBp biBkcmFmdC0xMSwgYW5kIHRoaW5rIHdlIHNob3VsZCBrZWVwIGl0LiZuYnNwOyBCdXQgaSB0aGlu ayB0aGU8YnI+DQpvdGhlciBjaGFuZ2VzIGJldHdlZW4gZHJhZnQtMTAgYW5kIGRyYWZ0LTExIGFy ZSB1bndhcnJhbnRlZCBhbmQgc2hvdWxkPGJyPg0KYmUgcmV2ZXJ0ZWQuPGJyPg0KPGJyPg0KPGJy Pg0KQW5hbHlzaXM8YnI+DQotLS0tLS0tLTxicj4NCjxicj4NCkFJVUksIHRoZSBzY2VuYXJpbyB1 bmRlciBkaXNjdXNzaW9uIGlzOjxicj4NCjxicj4NCiZuYnNwOyogQSBETlMgY2xpZW50IChmb2xs b3dpbmcgZWl0aGVyIHRoZSBzdHJpY3Qgb3IgdGhlIG9wcG9ydHVuaXN0aWM8YnI+DQombmJzcDsg Jm5ic3A7cHJvZmlsZSk8YnI+DQombmJzcDsqIHVzaW5nIG9wcG9ydHVuaXN0aWMgbWV0YS1xdWVy aWVzIHRvIGZpbmQgdGhlIGRlc2lyZWQgRE5TIHJlc29sdmVyPGJyPg0KJm5ic3A7KiBpbiB0aGUg ZmFjZSBvZiBhbiBhY3RpdmUgYXR0YWNrZXI8YnI+DQo8YnI+DQpXZSBhbHJlYWR5IGtub3cgdGhh dCBhbiBhdHRhY2tlciBjYXBhYmxlIG9mIGZpbHRlcmluZyB0aGUgY2xpZW50J3M8YnI+DQoqb3V0 Ym91bmQqIHRyYWZmaWMgY2FuIGNhdXNlIGEgZGVuaWFsIG9mIHNlcnZpY2UgKGZvciBjbGllbnRz IGZvbGxvd2luZzxicj4NCnRoZSBzdHJpY3QgcHJvZmlsZSkgb3IgbG9zcyBvZiBwcml2YWN5IChm b3IgY2xpZW50cyBmb2xsb3dpbmcgdGhlPGJyPg0Kb3Bwb3J0dW5pc3RpYyBwcm9maWxlLCBiZWNh dXNlIHRoZXkgZmFsbCBiYWNrIHRvIGNsZWFydGV4dCkgc2ltcGx5IGJ5PGJyPg0KZHJvcHBpbmcg b3V0Ym91bmQgY29ubmVjdGlvbnMgdG8gKmFueXdoZXJlKiBUQ1AgcG9ydCA4NTMuPGJyPg0KPGJy Pg0KTGlrZXdpc2UsIFdlIGFsc28ga25vdyB0aGF0IGFuIGF0dGFja2VyIGNhcGFibGUgb2YgZmls dGVyaW5nIHRoZTxicj4NCmNsaWVudCdzICppbmJvdW5kKiB0cmFmZmljIGNhbiBjYXVzZSBhIGRl bmlhbCBvZiBzZXJ2aWNlIChzdHJpY3Q8YnI+DQpjbGllbnRzKSBvciBsb3NzIG9mIHByaXZhY3kg KG9wcG9ydHVuaXN0aWMgY2xpZW50cykgc2ltcGx5IGJ5IGRyb3BwaW5nPGJyPg0KaW5ib3VuZCBj b25uZWN0aW9ucyBmcm9tIGFueSBUQ1AgcG9ydCA4NTMuPGJyPg0KPGJyPg0KQnV0IHRoZSBpbnRy b2R1Y3Rpb24gb2YgYW4gb3Bwb3J0dW5pc3RpY2FsbHktc2VjdXJlZCBtZXRhLXF1ZXJ5PGJyPg0K aW50cm9kdWNlcyBhIERvUyBhdHRhY2sgKHN0cmljdCBjbGllbnRzKSBvciBsb3NzIG9mIHByaXZh Y3k8YnI+DQoob3Bwb3J0dW5pc3RpYyBjbGllbnRzKSB0aGF0IGNhbiBiZSBhY2hpZXZlZCBieSBh IHdlYWtlciBhdHRhY2tlci48YnI+DQpTaW5jZSB3ZSdyZSB0YWxraW5nIGFib3V0IGFuIGF0dGFj a2VyIHRoYXQgaXMgKm5vdCogaW4gY29udHJvbCBvZiB0aGU8YnI+DQpuZXR3b3JrLCB0aGUgZm9s bG93aW5nIGFuYWx5c2lzIGFzc3VtZXMgdGhhdCB0aGUgdGhlIG5ldHdvcmsgcHJvdmlkZXM8YnI+ DQomcXVvdDtsZWdpdGltYXRlJnF1b3Q7IERIQ1Agc2VydmljZSwgd2hpY2ggaXMgc3VwcG9zZWQg dG8gcG9pbnQgdGhlIGNsaWVudCB0byBhPGJyPg0KJnF1b3Q7bGVnaXRpbWF0ZSZxdW90OyBzdGFu ZGFyZCBETlMgcmVzb2x2ZXIgKHdoaWNoIG1heSBvciBtYXkgbm90IGJlPGJyPg0KcHJpdmFjeS1l bmFibGVkLCBidXQgaXMgc3VmZmljaWVudCBmb3IgYW5zd2VyaW5nIGFuIG9wcG9ydHVuaXN0aWM8 YnI+DQptZXRhcXVlcnkgY29ycmVjdGx5KS48YnI+DQo8YnI+DQpJbiBwYXJ0aWN1bGFyLCB0aGUg YXR0YWNrZXIgbmVlZHMgb25seSBvbmUgb2YgdGhlIGZvbGxvd2luZyB0d288YnI+DQpjYXBhYmls aXRpZXM6PGJyPg0KPGJyPg0KJm5ic3A7IChhKSBDb250cm9sbGluZyB0aGUgJnF1b3Q7bGVnaXRp bWF0ZSZxdW90OyBESENQIHNlcnZlciwgb3IgZGV0ZWN0aW5nIHRoZTxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IGNsaWVudCdzIERIQ1AgcmVxdWVzdCBhbmQgcmFjaW5nIHRoZSAmcXVvdDtsZWdp dGltYXRlJnF1b3Q7IERIQ1Agc2VydmVyIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmV0 dXJuIGEgREhDUCByZXNwb25zZSAodGhpcyBhbGxvd3MgdGhlIGF0dGFja2VyIHRvIHNldCB0aGU8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyByZXNvbHZlciB1c2VkIGJ5IHRoZSBjbGllbnQgZm9y IGl0cyBvcHBvcnR1bmlzdGljIG1ldGFxdWVyeSksIG9yPGJyPg0KPGJyPg0KJm5ic3A7IChiKSBD b250cm9sbGluZyB0aGUgJnF1b3Q7bGVnaXRpbWF0ZSZxdW90OyBETlMgcmVzb2x2ZXIsIG9yIGRl dGVjdGluZyB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBjbGllbnQncyBvcHBvcnR1bmlz dGljIG1ldGFxdWVyeSBhbmQgcmFjaW5nIHRoZSAmcXVvdDtsZWdpdGltYXRlJnF1b3Q7IEROUzxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlc29sdmVyIHRvIHByb3ZpZGUgYSBtYWxpY2lvdXMg RE5TIHJlc3BvbnNlLjxicj4NCjxicj4NCkluIGVpdGhlciBjYXNlLCB0aGUgcmVzdWx0IGlzIHRo YXQgdGhlIGF0dGFja2VyIGhhcyBwb2lzb25lZCB0aGU8YnI+DQpjbGllbnQncyBtZXRhLWNhY2hl IC0tIGl0cyBiZXN0IGd1ZXNzIGF0IHRoZSBsb2NhdGlvbiBvZiB0aGUgZGVzaXJlZDxicj4NCnBy aXZhY3ktZW5hYmxlZCBETlMgcmVzb2x2ZXIuJm5ic3A7IEEgcG9pc29uZWQgbWV0YS1jYWNoZSBy ZXN1bHRzIGluIGEgRG9TPGJyPg0KZm9yIGNsaWVudHMgaW4gJnF1b3Q7U3RyaWN0JnF1b3Q7IG1v ZGUgYmVjYXVzZSB0aGUgYXR0YWNrZXIncyBhbnN3ZXJpbmcgRE5TPGJyPg0KcmVzb2x2ZXIgYXQg dGhlIGxlYXJuZWQgYWRkcmVzcyBjYW5ub3QgYXV0aGVudGljYXRlLiZuYnNwOyBBIHBvaXNvbmVk PGJyPg0KbWV0YS1jYWNoZSByZXN1bHRzIGluIGEgbG9zcyBvZiBwcml2YWN5IGZvciBjbGllbnRz IGluICZxdW90O09wcG9ydHVuaXN0aWMmcXVvdDs8YnI+DQptb2RlIGJlY2F1c2UgdGhleSB3aWxs IGNvbm5lY3Qgd2l0aG91dCBhdXRoZW50aWNhdGlvbiB0byB0aGUgYXR0YWNrZXInczxicj4NCmFu c3dlcmluZyBETlMgcmVzb2x2ZXIuPGJyPg0KPGJyPg0KSGF2ZSBpIGdvdCB0aGF0IHJpZ2h0Pzxi cj4NCjxicj4NCkROU1NFQyB2YWxpZGF0aW9uIGRvZXMgbm90IG1pdGlnYXRlIHRoaXMgYXR0YWNr Ljxicj4NCjxicj4NClJlZ2FyZGxlc3Mgb2YgdGhlIHByb2ZpbGUsIHRoZSBjbGllbnQgaGFzIGZv dXIgb3B0aW9ucyB3aGVuIGl0PGJyPg0KZGlzY292ZXJzIHRoYXQgdGhlIHJlc3BvbnNlIHRvIHRo ZSBtZXRhZGF0YSBxdWVyeSB3YXMgZm9yZ2VkIChvciBhdDxicj4NCmFueSByYXRlIGlzIG5vdCB2 YWxpZGF0YWJsZSkuJm5ic3A7IEl0IGNhbjo8YnI+DQo8YnI+DQombmJzcDsgKDApIGlnbm9yZSB0 aGUgcmVzcG9uc2UsIHJlc3VsdGluZyBpbiBhIERvUyByZWdhcmRsZXNzIG9mIHByb2ZpbGUsPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgb3I8YnI+DQo8YnI+DQombmJzcDsgKDEpIGlnbm9yZSB0 aGUgdmFsaWRhdGlvbiBmYWlsdXJlLCBhbmQgdHJ5IGNvbm5lY3RpbmcgdG8gdGhlPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgcHJvcG9zZWQgYWRkcmVzcyBhbnl3YXkgKHJlc3VsdGluZyBpbiBh IERvUyBmb3Igc3RyaWN0IGNsaWVudHM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBiZWNhdXNl IHRoZSBzZXJ2ZXIgZG9lcyBub3QgdmFsaWRhdGUsIG9yIGEgbG9zcyBvZiBwcml2YWN5IGZvcjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IG9wcG9ydHVuaXN0aWMgY2xpZW50cyksIG9yPGJyPg0K PGJyPg0KJm5ic3A7ICgyKSByZXRyeSB0aGUgbWV0YXF1ZXJ5IChpbiB0aGUgaG9wZXMgdGhhdCB0 aGVpciBhdHRhY2tlciBpcyBpbiBjbGFzczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90 O2ImcXVvdDsgYW5kIG5vdCBpbiBmdWxsIGNvbnRyb2wgb2YgdGhlICZxdW90O2xlZ2l0aW1hdGUm cXVvdDsgRE5TIHJlc29sdmVyKSBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBtYXliZSB0 aGUgbGVnaXRpbWF0ZSBETlMgcmVzcG9uc2Ugd2lsbCBjb21lIGluLCBvcjxicj4NCjxicj4NCiZu YnNwOyAoMykgYWJvcnQgdGhlIG5ldHdvcmsgY29ubmVjdGlvbiBhbmQgcmV0cnkgREhDUCAoaW4g dGhlIGhvcGVzIHRoYXQgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYXR0YWNrZXIgaXMg aW4gY2xhc3MgJnF1b3Q7YSZxdW90OyBhbmQgbm90IGluIGZ1bGwgY29udHJvbCBvZiB0aGU8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtsZWdpdGltYXRlJnF1b3Q7IERIQ1Agc2VydmVy KSBhbmQgbWF5YmUgdGhlIGxlZ2l0aW1hdGUgREhDUCByZXNwb25zZTxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IHdpbGwgY29tZSBpbi48YnI+DQo8YnI+DQpDaG9pY2UgMCBpcyB0aGUgc2FtZSBv dXRjb21lIGFzIHRoZSBub24tRE5TU0VDLXZhbGlkYXRpbmcgc2NlbmFyaW8gZm9yPGJyPg0Kc3Ry aWN0IGNsaWVudHMgKG5vIG1pdGlnYXRpb24pLCBhbmQgKnN0cmljdGx5IHdvcnNlKiBmb3Igb3Bw b3J0dW5pc3RpYzxicj4NCmNsaWVudHMsIGJlY2F1c2UgaXQgY29udmVydHMgYSBsb3NzIG9mIHBy aXZhY3kgdG8gYSBEb1MsIHdoaWNoIGlzIGluPGJyPg0KZGlyZWN0IG9wcG9zaXRpb24gdG8gdGhl IHN0YXRlZCBnb2FsIG9mIHRoZSBvcHBvcnR1bmlzdGljIHByb2ZpbGUuPGJyPg0KPGJyPg0KQ2hv aWNlIDEgaXMgZXhhY3RseSB0aGUgc2FtZSBvdXRjb21lIGFzIHRoZSBub24tRE5TU0VDLXZhbGlk YXRpbmc8YnI+DQpzY2VuYXJpbyBmb3IgYWxsIGNsaWVudHMuIChubyBtaXRpZ2F0aW9uKTxicj4N Cjxicj4NCkNob2ljZXMgMiBhbmQgMyBhcmUgaW50ZXJlc3RpbmcgdGhvdWdodCBleHBlcmltZW50 cywgYnV0IGFyZSBub3Q8YnI+DQpkaXJlY3RseSBjb250ZW1wbGF0ZWQgaW4gdGhlIGRyYWZ0IChh bmQgaSB0aGluayB0aGV5IHdvdWxkIGJlIGE8YnI+DQpkaXN0cmFjdGlvbiBmcm9tIHRoZSBnb2Fs IG9mIHRoZSBkcmFmdCAtLSB0aGlzIGRyYWZ0IGlzIG5vdCAmcXVvdDtob3cgdG8gZG88YnI+DQpz dGFnZWQgb3Bwb3J0dW5pc3RpYyBmYWxsYmFjayBpbiB0aGUgZmFjZSBvZiBhbiBhcmJpdHJhcmls eSBjb3JydXB0PGJyPg0KbmV0d29yayZxdW90OyksIHNvIGkgd29uJ3QgZ28gaW50byB0aGVtIGhl cmUuPGJyPg0KPGJyPg0KQXQgYmVzdCwgRE5TU0VDIHZhbGlkYXRpb24gb2YgdGhlIG1ldGFxdWVy eSBjb3VsZCBiZSB1c2VkIHRvIHByb3ZpZGU8YnI+DQphZGRpdGlvbmFsIHJlcG9ydGluZyBpbmZv cm1hdGlvbiB0byBhbnkgY2xpZW50LWludGVybmFsPGJyPg0KYXVkaXRpbmcvcmVwb3J0aW5nIG9y IG90aGVyIGRlZmVuc2l2ZSBtZWFzdXJlczsgYnV0IGFnYWluLCB0aGlzIGRyYWZ0PGJyPg0Kc2hv dWxkIG5vdCBnbyBpbnRvIHRob3NlIGluIGFueSBkZXRhaWwuPGJyPg0KPGJyPg0KQmFja2dyb3Vu ZDxicj4NCi0tLS0tLS0tLS08YnI+DQo8YnI+DQpUbyBiZSBjbGVhciBhYm91dCB3aGVyZSB0aGlz IGFuYWx5c2lzIGlzIGNvbWluZyBmcm9tLCBteSBydWxlIG9mIHRodW1iPGJyPg0KZm9yIHRoZXNl IHR3byBwcm9maWxlcyBpczo8YnI+DQo8YnI+DQombmJzcDsqIFN0cmljdDxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDtEbyB3aGF0ZXZlciB5b3UgY2FuIHRvIGNvbm5lY3QgdG8gdGhlIHByZWZlcnJl ZCBwcml2YWN5LWVuYWJsZWQ8YnI+DQombmJzcDsgJm5ic3A7cmVzb2x2ZXIsIGJ1dCBkb24ndCBh Y3R1YWxseSBzZW5kIHF1ZXJpZXMgdW5sZXNzIHlvdSdyZSBzdXJlIHlvdTxicj4NCiZuYnNwOyAm bmJzcDtoYXZlIGF1dGhlbnRpY2F0ZWQgdGhlIHNlcnZlci48YnI+DQo8YnI+DQombmJzcDsqIE9w cG9ydHVuaXN0aWM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7RG8gd2hhdGV2ZXIgeW91IGNhbiB0 byBjb25uZWN0IHRvIHRoZSBwcmVmZXJyZWQgcHJpdmFjeS1lbmFibGVkPGJyPg0KJm5ic3A7ICZu YnNwO3Jlc29sdmVyLCBidXQgZ28gYWhlYWQgYW5kIHNlbmQgeW91ciBxdWVyaWVzIHRvIGl0IGFu eXdheSwgZXZlbiBpZjxicj4NCiZuYnNwOyAmbmJzcDtpdCBjYW5ub3QgYmUgYXV0aGVudGljYXRl ZC48YnI+DQo8YnI+DQpOb3RlIHRoYXQgYm90aCBtb2RlcyBjYW4gcmVwb3J0IChlLmcuLCB0byBh IGxvY2FsIHN5c3RlbTxicj4NCmF1ZGl0b3IvbW9uaXRvci9wb2xpY3ktYWdlbnQpIGFueSBmYWls dXJlcyBvciBlcnJvcnMgdGhleSBlbmNvdW50ZXIuPGJyPg0KQnV0IFN0cmljdCBtb2RlIHdpbGwg ZmFpbCBjbG9zZWQgKERvUyksIGFuZCBPcHBvcnR1bmlzdGljIG1vZGUgd2lsbDxicj4NCmZhaWwg b3BlbiAobG9zcyBvZiBwcml2YWN5KS48YnI+DQo8YnI+DQpUbyBiZSBjbGVhcjogdGhlIGNsaWVu dCBpcyAqbG9jYWxseSBjb25maWd1cmVkKiB0byBiZSBlaXRoZXIgaW4gU3RyaWN0PGJyPg0Kb3Ig T3Bwb3J0dW5pc3RpYyBtb2RlLiZuYnNwOyBPcnRob2dvbmFsbHksIGl0IGlzIGFsc28gbG9jYWxs eSBjb25maWd1cmVkIHdpdGg8YnI+DQpzb21lIHNlcnZlciBhdXRoZW50aWNhdGlvbiBpbmZvcm1h dGlvbi48YnI+DQo8YnI+DQpJZiBpdHMgbG9jYWxseS1jb25maWd1cmVkIHNlcnZlciBhdXRoZW50 aWNhdGlvbiBpbmZvcm1hdGlvbiBpcyBvZiB0aGU8YnI+DQpmb3JtICZxdW90O0FETiZxdW90OyBv bmx5LCB0aGVuIC0tIGV2ZW4gd2hlbiBjb25maWd1cmVkIGluIFN0cmljdCBtb2RlIC0tIGl0PGJy Pg0Kd2lsbCBkbyBhbiBPcHBvcnR1bmlzdGljIEROUyByZXNvbHV0aW9uIG9mIHRoZSBhZGRyZXNz IG9mIHRoZSBkZXNpcmVkPGJyPg0KcmVzb2x2ZXIuJm5ic3A7IFRoaXMgaXMgdGhlICZxdW90O29w cG9ydHVuaXN0aWMgbWV0YS1xdWVyeSZxdW90Oy48YnI+DQo8YnI+DQpNYW55IG1vb25zIGFnbywg ZWtyIHdyb3RlOjxicj4NCjxicj4NCiZndDsgSS5lLiwgaWYgeW91IGRldGVybWluZSB3aGV0aGVy IHRvIGFkb3B0IGEgU3RyaWN0IHBvbGljeSBiYXNlZCBvbjxicj4NCiZndDsgT3Bwb3J0dW5pc3Rp YyBxdWVyaWVzLCB0aGVuIHlvdSBhcmUgYmFjayB0byB0aGUgYWN0aXZlIGF0dGFjazxicj4NCiZn dDsgc2V0dGluZy48YnI+DQo8YnI+DQpCdXQgdGhlIGNsaWVudCBpcyAqbm90KiBkZXRlcm1pbmlu ZyB3aGV0aGVyIHRvIGFkb3B0IGEgU3RyaWN0IHBvbGljeTxicj4NCmJhc2VkIG9uIHRoZSBvcHBv cnR1bmlzdGljIG1ldGEtcXVlcnkuJm5ic3A7IEl0IGhhcyBhbHJlYWR5IGRlY2lkZWQgd2hpY2g8 YnI+DQpwcm9maWxlIGl0IGlzIHVzaW5nLCBhbmQgdGhlIG9wcG9ydHVuaXN0aWMgbWV0YS1xdWVy eSBtZXJlbHkgdG8gZmluZDxicj4NCnRoZSBJUCBhZGRyZXNzIG9mIGl0cyBkZXNpcmVkIHByaXZh Y3ktZW5hYmxlZCBETlMgcmVzb2x2ZXIuPGJyPg0KPGJyPg0KPGJyPg0KU28gaSBndWVzcyBpJ20g c3RpbGwgRElTQ1VTU2luZyBla3IncyBESVNDVVNTLCB3aGljaCBpcyBhbiB1bmZvcnR1bmF0ZTxi cj4NCnN0YXRlIGZvciB0aGUgZHJhZnQgdG8gYmUgaW4uIDooPGJyPg0KPGJyPg0KPGJyPg0KSSB3 ZWxjb21lIGNsYXJpZmljYXRpb24gaWYgaSd2ZSBtaXN1bmRlcnN0b29kIHRoZSBwcm9ibGVtIHdl J3JlIHRyeWluZzxicj4NCnRvIGFkZHJlc3MgaGVyZSwgb3IgaWYgaSd2ZSBzb21laG93IGxldCBt eXNlbGYgbGFwc2UgaW50byBzb21lIHNvcnQgb2Y8YnI+DQomcXVvdDtwcml2YWN5IG5paGlsaXNt JnF1b3Q7Ljxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFz cz0iaG9lbnpiIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LS1ka2c8L3NwYW4+ PGJyPg0KPC9zcGFuPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KZG5zLXByaXZhY3kgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOmRucy1wcml2YWN5QGlldGYub3JnIj5kbnMtcHJpdmFjeUBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rucy1wcml2YWN5 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k bnMtcHJpdmFjeTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB1788102A02C9B188B915258EEA590DM5PR16MB1788namp_-- From nobody Mon Oct 30 02:21:51 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4927913F93E for ; Mon, 30 Oct 2017 02:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 irsOTY1w6P5t for ; Mon, 30 Oct 2017 02:21:46 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 C1CFF13F932 for ; Mon, 30 Oct 2017 02:21:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yQTWS14Yzz3Yy; Mon, 30 Oct 2017 10:21:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1509355300; bh=63wV6nz7kJpveKMPgqSZEsdkqyWluGugqtU7AqU9UiM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=nPGh5QZV4ELdofFBlelKBDU8qDaoGx4vXHKPu3590GyDW11DxZYipBZ3cdZFt2Y45 +NRSrLP9tYL0wF+U5J7v5I0lrUauadwfp7Qy0KDxpuYwIw9sUYQ8GREB/nSjtMmY3M vxSZgH8XcSJWuGUjMkLdKkwLaO18mTDU9V2tlXUM= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cza7qBQq_u0z; Mon, 30 Oct 2017 10:21:33 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 30 Oct 2017 10:21:32 +0100 (CET) Received: from [100.64.13.2] (vpn.nohats.ca [193.110.157.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 63E9562D29; Mon, 30 Oct 2017 05:21:30 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 63E9562D29 Content-Type: multipart/alternative; boundary=Apple-Mail-2229A496-1043-4EC7-B930-F6696301AB37 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Mon, 30 Oct 2017 13:21:27 +0400 Cc: Ben Schwartz , Daniel Kahn Gillmor , "dns-privacy@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <4C03CDB2-C7CD-429A-A810-0CA44CA35BF8@nohats.ca> References: <878tfwey8w.fsf@fifthhorseman.net> To: "Konda, Tirumaleswar Reddy" Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 09:21:50 -0000 --Apple-Mail-2229A496-1043-4EC7-B930-F6696301AB37 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Oct 30, 2017, at 13:09, Konda, Tirumaleswar Reddy wrote: >=20 > +1, DNSSEC itself is susceptible to active attacks and needs a secure chan= nel to protect from an active attacker. What active attacks is DNSSEC vulnerable to? And how does that not affect TLS? Paul > =20 > -Tiru > =20 > From: dns-privacy [mailto:dns-privacy-bounces@ietf.org] On Behalf Of Ben S= chwartz > Sent: Saturday, October 28, 2017 9:34 PM > To: Daniel Kahn Gillmor > Cc: dns-privacy@ietf.org > Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profil= es-11: we should revert DNSSEC validation requirement > =20 > I agree with DKG's analysis. > =20 > Also, as an implementor, I think this requirement would be onerous. In th= e software I am modifying, implementing DNS-over-TLS is dramatically easier t= han adding a validating stub resolver. I wouldn't be implementing DNS-over-= TLS if DNSSEC were mandatory (in either mode). > =20 > On Fri, Oct 27, 2017 at 11:40 PM, Daniel Kahn Gillmor wrote: > Hey DPRIVE folks-- >=20 > Apologies for the delay, and that this message is so long. I've tried > to reconstruct this discussion around > draft-ietf-dprive-dtls-and-tls-profiles-11 as best i can, and my > analysis follows. If i've misundertood or misanalyzed something, > please let me know. >=20 > Summary > ------- >=20 > I do not believe that DNSSEC validation is warranted as a mitigation > against an active attacker in the context of an opportunistic metaquery, > regardless of whether the client ultimately intends to follow either the > Strict or Opportunistic profile. >=20 > Furthermore, i believe that the proposal in draft-11 of making DNSSEC > validation of metaqueries a MUST for the opportunistic profile is > *actively harmful* to the stated goal of the opportunistic profile > (i.e., "maximum chance of DNS service"). >=20 > I like the reorganization and re-wording of the "Usage Profiles" > section in draft-11, and think we should keep it. But i think the > other changes between draft-10 and draft-11 are unwarranted and should > be reverted. >=20 >=20 > Analysis > -------- >=20 > AIUI, the scenario under discussion is: >=20 > * A DNS client (following either the strict or the opportunistic > profile) > * using opportunistic meta-queries to find the desired DNS resolver > * in the face of an active attacker >=20 > We already know that an attacker capable of filtering the client's > *outbound* traffic can cause a denial of service (for clients following > the strict profile) or loss of privacy (for clients following the > opportunistic profile, because they fall back to cleartext) simply by > dropping outbound connections to *anywhere* TCP port 853. >=20 > Likewise, We also know that an attacker capable of filtering the > client's *inbound* traffic can cause a denial of service (strict > clients) or loss of privacy (opportunistic clients) simply by dropping > inbound connections from any TCP port 853. >=20 > But the introduction of an opportunistically-secured meta-query > introduces a DoS attack (strict clients) or loss of privacy > (opportunistic clients) that can be achieved by a weaker attacker. > Since we're talking about an attacker that is *not* in control of the > network, the following analysis assumes that the the network provides > "legitimate" DHCP service, which is supposed to point the client to a > "legitimate" standard DNS resolver (which may or may not be > privacy-enabled, but is sufficient for answering an opportunistic > metaquery correctly). >=20 > In particular, the attacker needs only one of the following two > capabilities: >=20 > (a) Controlling the "legitimate" DHCP server, or detecting the > client's DHCP request and racing the "legitimate" DHCP server to > return a DHCP response (this allows the attacker to set the > resolver used by the client for its opportunistic metaquery), or >=20 > (b) Controlling the "legitimate" DNS resolver, or detecting the > client's opportunistic metaquery and racing the "legitimate" DNS > resolver to provide a malicious DNS response. >=20 > In either case, the result is that the attacker has poisoned the > client's meta-cache -- its best guess at the location of the desired > privacy-enabled DNS resolver. A poisoned meta-cache results in a DoS > for clients in "Strict" mode because the attacker's answering DNS > resolver at the learned address cannot authenticate. A poisoned > meta-cache results in a loss of privacy for clients in "Opportunistic" > mode because they will connect without authentication to the attacker's > answering DNS resolver. >=20 > Have i got that right? >=20 > DNSSEC validation does not mitigate this attack. >=20 > Regardless of the profile, the client has four options when it > discovers that the response to the metadata query was forged (or at > any rate is not validatable). It can: >=20 > (0) ignore the response, resulting in a DoS regardless of profile, > or >=20 > (1) ignore the validation failure, and try connecting to the > proposed address anyway (resulting in a DoS for strict clients > because the server does not validate, or a loss of privacy for > opportunistic clients), or >=20 > (2) retry the metaquery (in the hopes that their attacker is in class > "b" and not in full control of the "legitimate" DNS resolver) and > maybe the legitimate DNS response will come in, or >=20 > (3) abort the network connection and retry DHCP (in the hopes that the > attacker is in class "a" and not in full control of the > "legitimate" DHCP server) and maybe the legitimate DHCP response > will come in. >=20 > Choice 0 is the same outcome as the non-DNSSEC-validating scenario for > strict clients (no mitigation), and *strictly worse* for opportunistic > clients, because it converts a loss of privacy to a DoS, which is in > direct opposition to the stated goal of the opportunistic profile. >=20 > Choice 1 is exactly the same outcome as the non-DNSSEC-validating > scenario for all clients. (no mitigation) >=20 > Choices 2 and 3 are interesting thought experiments, but are not > directly contemplated in the draft (and i think they would be a > distraction from the goal of the draft -- this draft is not "how to do > staged opportunistic fallback in the face of an arbitrarily corrupt > network"), so i won't go into them here. >=20 > At best, DNSSEC validation of the metaquery could be used to provide > additional reporting information to any client-internal > auditing/reporting or other defensive measures; but again, this draft > should not go into those in any detail. >=20 > Background > ---------- >=20 > To be clear about where this analysis is coming from, my rule of thumb > for these two profiles is: >=20 > * Strict >=20 > Do whatever you can to connect to the preferred privacy-enabled > resolver, but don't actually send queries unless you're sure you > have authenticated the server. >=20 > * Opportunistic >=20 > Do whatever you can to connect to the preferred privacy-enabled > resolver, but go ahead and send your queries to it anyway, even if > it cannot be authenticated. >=20 > Note that both modes can report (e.g., to a local system > auditor/monitor/policy-agent) any failures or errors they encounter. > But Strict mode will fail closed (DoS), and Opportunistic mode will > fail open (loss of privacy). >=20 > To be clear: the client is *locally configured* to be either in Strict > or Opportunistic mode. Orthogonally, it is also locally configured with > some server authentication information. >=20 > If its locally-configured server authentication information is of the > form "ADN" only, then -- even when configured in Strict mode -- it > will do an Opportunistic DNS resolution of the address of the desired > resolver. This is the "opportunistic meta-query". >=20 > Many moons ago, ekr wrote: >=20 > > I.e., if you determine whether to adopt a Strict policy based on > > Opportunistic queries, then you are back to the active attack > > setting. >=20 > But the client is *not* determining whether to adopt a Strict policy > based on the opportunistic meta-query. It has already decided which > profile it is using, and the opportunistic meta-query merely to find > the IP address of its desired privacy-enabled DNS resolver. >=20 >=20 > So i guess i'm still DISCUSSing ekr's DISCUSS, which is an unfortunate > state for the draft to be in. :( >=20 >=20 > I welcome clarification if i've misunderstood the problem we're trying > to address here, or if i've somehow let myself lapse into some sort of > "privacy nihilism". >=20 > --dkg >=20 > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy >=20 > =20 > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy --Apple-Mail-2229A496-1043-4EC7-B930-F6696301AB37 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Oct 30, 2017, at 13:09, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> wrote:

+1, DNSSEC itself is susceptible to active attacks and needs a secure channel to protect from an active attacker.


What active attacks is DNSSEC vulnerable to?

And how does that not affect TLS?

Paul


 

-Tiru

 

From: dns-privacy [mailto:dns-privacy-bounces@ietf.org] On Behalf Of Ben Schwartz
Sent: Saturday, October 28, 2017 9:34 PM
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

 

I agree with DKG's analysis.

 

Also, as an implementor, I think this requirement would be onerous.  In the software I am modifying, implementing DNS-over-TLS is dramatically easier than adding a validating stub resolver.  I wouldn't be implementing DNS-over-TLS if DNSSEC were mandatory (in either mode).

 

On Fri, Oct 27, 2017 at 11:40 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:

Hey DPRIVE folks--

Apologies for the delay, and that this message is so long.  I've tried
to reconstruct this discussion around
draft-ietf-dprive-dtls-and-tls-profiles-11 as best i can, and my
analysis follows.  If i've misundertood or misanalyzed something,
please let me know.

Summary
-------

I do not believe that DNSSEC validation is warranted as a mitigation
against an active attacker in the context of an opportunistic metaquery,
regardless of whether the client ultimately intends to follow either the
Strict or Opportunistic profile.

Furthermore, i believe that the proposal in draft-11 of making DNSSEC
validation of metaqueries a MUST for the opportunistic profile is
*actively harmful* to the stated goal of the opportunistic profile
(i.e., "maximum chance of DNS service").

I like the reorganization and re-wording of the "Usage Profiles"
section in draft-11, and think we should keep it.  But i think the
other changes between draft-10 and draft-11 are unwarranted and should
be reverted.


Analysis
--------

AIUI, the scenario under discussion is:

 * A DNS client (following either the strict or the opportunistic
   profile)
 * using opportunistic meta-queries to find the desired DNS resolver
 * in the face of an active attacker

We already know that an attacker capable of filtering the client's
*outbound* traffic can cause a denial of service (for clients following
the strict profile) or loss of privacy (for clients following the
opportunistic profile, because they fall back to cleartext) simply by
dropping outbound connections to *anywhere* TCP port 853.

Likewise, We also know that an attacker capable of filtering the
client's *inbound* traffic can cause a denial of service (strict
clients) or loss of privacy (opportunistic clients) simply by dropping
inbound connections from any TCP port 853.

But the introduction of an opportunistically-secured meta-query
introduces a DoS attack (strict clients) or loss of privacy
(opportunistic clients) that can be achieved by a weaker attacker.
Since we're talking about an attacker that is *not* in control of the
network, the following analysis assumes that the the network provides
"legitimate" DHCP service, which is supposed to point the client to a
"legitimate" standard DNS resolver (which may or may not be
privacy-enabled, but is sufficient for answering an opportunistic
metaquery correctly).

In particular, the attacker needs only one of the following two
capabilities:

  (a) Controlling the "legitimate" DHCP server, or detecting the
      client's DHCP request and racing the "legitimate" DHCP server to
      return a DHCP response (this allows the attacker to set the
      resolver used by the client for its opportunistic metaquery), or

  (b) Controlling the "legitimate" DNS resolver, or detecting the
      client's opportunistic metaquery and racing the "legitimate" DNS
      resolver to provide a malicious DNS response.

In either case, the result is that the attacker has poisoned the
client's meta-cache -- its best guess at the location of the desired
privacy-enabled DNS resolver.  A poisoned meta-cache results in a DoS
for clients in "Strict" mode because the attacker's answering DNS
resolver at the learned address cannot authenticate.  A poisoned
meta-cache results in a loss of privacy for clients in "Opportunistic"
mode because they will connect without authentication to the attacker's
answering DNS resolver.

Have i got that right?

DNSSEC validation does not mitigate this attack.

Regardless of the profile, the client has four options when it
discovers that the response to the metadata query was forged (or at
any rate is not validatable).  It can:

  (0) ignore the response, resulting in a DoS regardless of profile,
      or

  (1) ignore the validation failure, and try connecting to the
      proposed address anyway (resulting in a DoS for strict clients
      because the server does not validate, or a loss of privacy for
      opportunistic clients), or

  (2) retry the metaquery (in the hopes that their attacker is in class
      "b" and not in full control of the "legitimate" DNS resolver) and
      maybe the legitimate DNS response will come in, or

  (3) abort the network connection and retry DHCP (in the hopes that the
      attacker is in class "a" and not in full control of the
      "legitimate" DHCP server) and maybe the legitimate DHCP response
      will come in.

Choice 0 is the same outcome as the non-DNSSEC-validating scenario for
strict clients (no mitigation), and *strictly worse* for opportunistic
clients, because it converts a loss of privacy to a DoS, which is in
direct opposition to the stated goal of the opportunistic profile.

Choice 1 is exactly the same outcome as the non-DNSSEC-validating
scenario for all clients. (no mitigation)

Choices 2 and 3 are interesting thought experiments, but are not
directly contemplated in the draft (and i think they would be a
distraction from the goal of the draft -- this draft is not "how to do
staged opportunistic fallback in the face of an arbitrarily corrupt
network"), so i won't go into them here.

At best, DNSSEC validation of the metaquery could be used to provide
additional reporting information to any client-internal
auditing/reporting or other defensive measures; but again, this draft
should not go into those in any detail.

Background
----------

To be clear about where this analysis is coming from, my rule of thumb
for these two profiles is:

 * Strict

   Do whatever you can to connect to the preferred privacy-enabled
   resolver, but don't actually send queries unless you're sure you
   have authenticated the server.

 * Opportunistic

   Do whatever you can to connect to the preferred privacy-enabled
   resolver, but go ahead and send your queries to it anyway, even if
   it cannot be authenticated.

Note that both modes can report (e.g., to a local system
auditor/monitor/policy-agent) any failures or errors they encounter.
But Strict mode will fail closed (DoS), and Opportunistic mode will
fail open (loss of privacy).

To be clear: the client is *locally configured* to be either in Strict
or Opportunistic mode.  Orthogonally, it is also locally configured with
some server authentication information.

If its locally-configured server authentication information is of the
form "ADN" only, then -- even when configured in Strict mode -- it
will do an Opportunistic DNS resolution of the address of the desired
resolver.  This is the "opportunistic meta-query".

Many moons ago, ekr wrote:

> I.e., if you determine whether to adopt a Strict policy based on
> Opportunistic queries, then you are back to the active attack
> setting.

But the client is *not* determining whether to adopt a Strict policy
based on the opportunistic meta-query.  It has already decided which
profile it is using, and the opportunistic meta-query merely to find
the IP address of its desired privacy-enabled DNS resolver.


So i guess i'm still DISCUSSing ekr's DISCUSS, which is an unfortunate
state for the draft to be in. :(


I welcome clarification if i've misunderstood the problem we're trying
to address here, or if i've somehow let myself lapse into some sort of
"privacy nihilism".

         --dkg

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

 

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
--Apple-Mail-2229A496-1043-4EC7-B930-F6696301AB37-- From nobody Mon Oct 30 04:02:38 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805CC13F994 for ; Mon, 30 Oct 2017 04:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 pEYWzHDofBrZ for ; Mon, 30 Oct 2017 04:02:28 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 6EE8013F710 for ; Mon, 30 Oct 2017 04:02:28 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509361343; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=J /Tph4PTow+F4BsxdxGFPo3Z9XZ/pW4jrvmahjyJpZ Y=; b=as0bxj2pxMcuxbzWWpF4maCpGDbZqDw0ueaI4fpMoZ1d 0PRjImGxkny0yP/ZkUkMY8gDgtXyz/0NSpHnrsJGbrNA5ubwzb kZE2/qqVKWgVjhcD4953BoOMFdx4AJCmwWX3LRlY8VdzuK8MHT 3tlS1hAv5hx14cjiqiwlB2jxJwA= Received: from DNVEXAPP1N04.corpzone.internalzone.com (dnvexapp1n04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 53a7_3a8a_ae422543_32ac_4d8a_8e65_6ef25550acb0; Mon, 30 Oct 2017 06:02:22 -0500 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 05:02:16 -0600 Received: from DNVEX10N01.corpzone.internalzone.com (10.44.82.192) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 30 Oct 2017 05:02:16 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEX10N01.corpzone.internalzone.com (10.44.82.192) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 30 Oct 2017 05:02:16 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 05:02:16 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Mon, 30 Oct 2017 11:02:14 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 11:02:14 +0000 From: "Konda, Tirumaleswar Reddy" To: Paul Wouters CC: Ben Schwartz , Daniel Kahn Gillmor , "dns-privacy@ietf.org" Thread-Topic: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Thread-Index: AQHTT+N/U3oS1xfLdkyJreqW4BxYC6L5bNgAgAKwpGCAAAOpgIAAGQGA Date: Mon, 30 Oct 2017 11:02:14 +0000 Message-ID: References: <878tfwey8w.fsf@fifthhorseman.net> <4C03CDB2-C7CD-429A-A810-0CA44CA35BF8@nohats.ca> In-Reply-To: <4C03CDB2-C7CD-429A-A810-0CA44CA35BF8@nohats.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:Jqo4Ow8cD8sXxRg31DiPp8Qwjwt4AGL1cwtwRcOGXFW19mXyvDnxFWv5eZMuDgMKFRwsWuF+WONZxyxzwJuqbH45+4LO2imuPw0QZtSPM8QgnTX2e7rhHHiFKu2B+XalpMQMd2qbII2XdxVGsgoq1Fs7gyCFqypRr0XY6MmgBRthDlafY4gTwJGZgQBEAeXTTuDH9CUKidILfor52apAbSS795BseMn1sw3Dk2EtPduBVikCUNd6ehcup4sMnCcHt9DyN1uUlVI7gUTuTAbE3Zwf5SJh0up/lnGKRisweVOpxhn56tXJ6x+BOohzVQiU/dLKynbQwA4hgJm/JWE9v44QdMkMOY0N/tfqjz3L5Lc=; 5:aG3KePK87lRa9QSSmjK5Iykrg/cK9tUtJ5Ez3ceyLNARf8bk6430rK8XhT81K/9ZgYgFwruyHE3xnQcohv4Rz0kGdja6/Y5tjIm/rL9GvXkhqxvPs2Rj381fPUIs4YIXZbUZAe8cMAaMgq2c5vZ1LV/XdkalpMVBkctAxVOIu5Y=; 24:K5GvsJ9hpaWv9X31yF2rOlFmIPuil77MAcbA7eh1mVSdAB4prwJ6/C6/jLYFIJt4oFWgmNiB0luPTww+RGdgY+XJNrve3jtIns0WrtyJHWI=; 7:+j8/OtbnBc4upJspEikAliQ4X4ckUaprq9DcvFMMLgNz5BOj4fd77B1tcYExzOi/8H5rpjnt2I35IVuFWDACMsq4b3VyVuzO+EKQ6KhSGqGNrO/nw0enrzX1CbrGoTKyYlLjVf/ILTnfioOgvxaJSOFRQF8uolMPdlNytpxWNjehjR7yXqpnwK2oSdRmQCDU2r7ZYLzHZ7WVxeuGfEjLsuSMtszxyCx6hgYiaXFG0i5CZ7a0TaSUSiTxopj8UlCy x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 22652763-78a3-4a6e-32cf-08d51f85ada8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603238); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(153496737603132)(21748063052155)(21532816269658)(211171220733660)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(3231020)(93006095)(93001095)(920507026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(24454002)(189002)(199003)(52314003)(32952001)(101416001)(86362001)(6436002)(189998001)(33656002)(53936002)(54906003)(55016002)(561944003)(2950100002)(6916009)(7736002)(230783001)(8936002)(2900100001)(14454004)(74316002)(7696004)(34040400001)(5660300001)(66066001)(105586002)(106356001)(93886005)(8676002)(316002)(53546010)(81166006)(6246003)(606006)(3846002)(81156014)(6116002)(790700001)(102836003)(2906002)(68736007)(54896002)(3660700001)(99286003)(19609705001)(4326008)(9686003)(97736004)(3280700002)(966005)(229853002)(25786009)(6306002)(50986999)(478600001)(54356999)(80792005)(77096006)(6506006)(236005)(72206003)(76176999)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788C0A59EDED66095D2F52BEA590DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 22652763-78a3-4a6e-32cf-08d51f85ada8 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 11:02:14.6292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6146> : inlines <6150> : streams <1768843> : uri <2524808> Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 11:02:36 -0000 --_000_DM5PR16MB1788C0A59EDED66095D2F52BEA590DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW4gYWN0aXZlIGF0dGFja2VyIGNhbiBkcm9wIEROUyBtZXNzYWdlcyB3aXRoIEROU1NFQyByZWNv cmRzLCBzZXQgdGhlIENEIGJpdCBpbiB0aGUgRE5TIHF1ZXJ5LCBBRCBiaXQgaW4gdGhlIEROUyBy ZXNwb25zZSAoc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MDM1I3NlY3Rpb24t NyksIGNsZWFyIHRoZSBETlNTRUMgT0sgYml0IGluIHRoZSBETlMgcXVlcnkgb3Igc3RyaXAgdGhl IEROU1NFQyBkYXRhIGZyb20gdGhlIEROUyByZXNwb25zZSB0byBkaXNhYmxlIEROU1NFQyAoU2Vj dGlvbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzIyNSkuDQoNCkROU1NFQyBjYW5u b3QgYmUgbWFuZGF0ZWQgZm9yIG9wcG9ydHVuaXN0aWMgcHJvZmlsZS4NCg0KLVRpcnUNCg0KRnJv bTogUGF1bCBXb3V0ZXJzIFttYWlsdG86cGF1bEBub2hhdHMuY2FdDQpTZW50OiBNb25kYXksIE9j dG9iZXIgMzAsIDIwMTcgMjo1MSBQTQ0KVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRp cnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+DQpDYzogQmVuIFNjaHdhcnR6IDxiZW1h c2NAZ29vZ2xlLmNvbT47IERhbmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5l dD47IGRucy1wcml2YWN5QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Rucy1wcml2YWN5XSByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXByb2ZpbGVzLTExOiB3ZSBzaG91 bGQgcmV2ZXJ0IEROU1NFQyB2YWxpZGF0aW9uIHJlcXVpcmVtZW50DQoNCk9uIE9jdCAzMCwgMjAx NywgYXQgMTM6MDksIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5 X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5j b20+PiB3cm90ZToNCg0KKzEsIEROU1NFQyBpdHNlbGYgaXMgc3VzY2VwdGlibGUgdG8gYWN0aXZl IGF0dGFja3MgYW5kIG5lZWRzIGEgc2VjdXJlIGNoYW5uZWwgdG8gcHJvdGVjdCBmcm9tIGFuIGFj dGl2ZSBhdHRhY2tlci4NCg0KV2hhdCBhY3RpdmUgYXR0YWNrcyBpcyBETlNTRUMgdnVsbmVyYWJs ZSB0bz8NCg0KQW5kIGhvdyBkb2VzIHRoYXQgbm90IGFmZmVjdCBUTFM/DQoNClBhdWwNCg0KDQoN Cg0KLVRpcnUNCg0KRnJvbTogZG5zLXByaXZhY3kgW21haWx0bzpkbnMtcHJpdmFjeS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVuIFNjaHdhcnR6DQpTZW50OiBTYXR1cmRheSwgT2N0 b2JlciAyOCwgMjAxNyA5OjM0IFBNDQpUbzogRGFuaWVsIEthaG4gR2lsbG1vciA8ZGtnQGZpZnRo aG9yc2VtYW4ubmV0PG1haWx0bzpka2dAZmlmdGhob3JzZW1hbi5uZXQ+Pg0KQ2M6IGRucy1wcml2 YWN5QGlldGYub3JnPG1haWx0bzpkbnMtcHJpdmFjeUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb ZG5zLXByaXZhY3ldIHJldmlldyBvZiBkcmFmdC1pZXRmLWRwcml2ZS1kdGxzLWFuZC10bHMtcHJv ZmlsZXMtMTE6IHdlIHNob3VsZCByZXZlcnQgRE5TU0VDIHZhbGlkYXRpb24gcmVxdWlyZW1lbnQN Cg0KSSBhZ3JlZSB3aXRoIERLRydzIGFuYWx5c2lzLg0KDQpBbHNvLCBhcyBhbiBpbXBsZW1lbnRv ciwgSSB0aGluayB0aGlzIHJlcXVpcmVtZW50IHdvdWxkIGJlIG9uZXJvdXMuICBJbiB0aGUgc29m dHdhcmUgSSBhbSBtb2RpZnlpbmcsIGltcGxlbWVudGluZyBETlMtb3Zlci1UTFMgaXMgZHJhbWF0 aWNhbGx5IGVhc2llciB0aGFuIGFkZGluZyBhIHZhbGlkYXRpbmcgc3R1YiByZXNvbHZlci4gIEkg d291bGRuJ3QgYmUgaW1wbGVtZW50aW5nIEROUy1vdmVyLVRMUyBpZiBETlNTRUMgd2VyZSBtYW5k YXRvcnkgKGluIGVpdGhlciBtb2RlKS4NCg0KT24gRnJpLCBPY3QgMjcsIDIwMTcgYXQgMTE6NDAg UE0sIERhbmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldDxtYWlsdG86ZGtn QGZpZnRoaG9yc2VtYW4ubmV0Pj4gd3JvdGU6DQpIZXkgRFBSSVZFIGZvbGtzLS0NCg0KQXBvbG9n aWVzIGZvciB0aGUgZGVsYXksIGFuZCB0aGF0IHRoaXMgbWVzc2FnZSBpcyBzbyBsb25nLiAgSSd2 ZSB0cmllZA0KdG8gcmVjb25zdHJ1Y3QgdGhpcyBkaXNjdXNzaW9uIGFyb3VuZA0KZHJhZnQtaWV0 Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXByb2ZpbGVzLTExIGFzIGJlc3QgaSBjYW4sIGFuZCBteQ0K YW5hbHlzaXMgZm9sbG93cy4gIElmIGkndmUgbWlzdW5kZXJ0b29kIG9yIG1pc2FuYWx5emVkIHNv bWV0aGluZywNCnBsZWFzZSBsZXQgbWUga25vdy4NCg0KU3VtbWFyeQ0KLS0tLS0tLQ0KDQpJIGRv IG5vdCBiZWxpZXZlIHRoYXQgRE5TU0VDIHZhbGlkYXRpb24gaXMgd2FycmFudGVkIGFzIGEgbWl0 aWdhdGlvbg0KYWdhaW5zdCBhbiBhY3RpdmUgYXR0YWNrZXIgaW4gdGhlIGNvbnRleHQgb2YgYW4g b3Bwb3J0dW5pc3RpYyBtZXRhcXVlcnksDQpyZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIGNsaWVu dCB1bHRpbWF0ZWx5IGludGVuZHMgdG8gZm9sbG93IGVpdGhlciB0aGUNClN0cmljdCBvciBPcHBv cnR1bmlzdGljIHByb2ZpbGUuDQoNCkZ1cnRoZXJtb3JlLCBpIGJlbGlldmUgdGhhdCB0aGUgcHJv cG9zYWwgaW4gZHJhZnQtMTEgb2YgbWFraW5nIEROU1NFQw0KdmFsaWRhdGlvbiBvZiBtZXRhcXVl cmllcyBhIE1VU1QgZm9yIHRoZSBvcHBvcnR1bmlzdGljIHByb2ZpbGUgaXMNCiphY3RpdmVseSBo YXJtZnVsKiB0byB0aGUgc3RhdGVkIGdvYWwgb2YgdGhlIG9wcG9ydHVuaXN0aWMgcHJvZmlsZQ0K KGkuZS4sICJtYXhpbXVtIGNoYW5jZSBvZiBETlMgc2VydmljZSIpLg0KDQpJIGxpa2UgdGhlIHJl b3JnYW5pemF0aW9uIGFuZCByZS13b3JkaW5nIG9mIHRoZSAiVXNhZ2UgUHJvZmlsZXMiDQpzZWN0 aW9uIGluIGRyYWZ0LTExLCBhbmQgdGhpbmsgd2Ugc2hvdWxkIGtlZXAgaXQuICBCdXQgaSB0aGlu ayB0aGUNCm90aGVyIGNoYW5nZXMgYmV0d2VlbiBkcmFmdC0xMCBhbmQgZHJhZnQtMTEgYXJlIHVu d2FycmFudGVkIGFuZCBzaG91bGQNCmJlIHJldmVydGVkLg0KDQoNCkFuYWx5c2lzDQotLS0tLS0t LQ0KDQpBSVVJLCB0aGUgc2NlbmFyaW8gdW5kZXIgZGlzY3Vzc2lvbiBpczoNCg0KICogQSBETlMg Y2xpZW50IChmb2xsb3dpbmcgZWl0aGVyIHRoZSBzdHJpY3Qgb3IgdGhlIG9wcG9ydHVuaXN0aWMN CiAgIHByb2ZpbGUpDQogKiB1c2luZyBvcHBvcnR1bmlzdGljIG1ldGEtcXVlcmllcyB0byBmaW5k IHRoZSBkZXNpcmVkIEROUyByZXNvbHZlcg0KICogaW4gdGhlIGZhY2Ugb2YgYW4gYWN0aXZlIGF0 dGFja2VyDQoNCldlIGFscmVhZHkga25vdyB0aGF0IGFuIGF0dGFja2VyIGNhcGFibGUgb2YgZmls dGVyaW5nIHRoZSBjbGllbnQncw0KKm91dGJvdW5kKiB0cmFmZmljIGNhbiBjYXVzZSBhIGRlbmlh bCBvZiBzZXJ2aWNlIChmb3IgY2xpZW50cyBmb2xsb3dpbmcNCnRoZSBzdHJpY3QgcHJvZmlsZSkg b3IgbG9zcyBvZiBwcml2YWN5IChmb3IgY2xpZW50cyBmb2xsb3dpbmcgdGhlDQpvcHBvcnR1bmlz dGljIHByb2ZpbGUsIGJlY2F1c2UgdGhleSBmYWxsIGJhY2sgdG8gY2xlYXJ0ZXh0KSBzaW1wbHkg YnkNCmRyb3BwaW5nIG91dGJvdW5kIGNvbm5lY3Rpb25zIHRvICphbnl3aGVyZSogVENQIHBvcnQg ODUzLg0KDQpMaWtld2lzZSwgV2UgYWxzbyBrbm93IHRoYXQgYW4gYXR0YWNrZXIgY2FwYWJsZSBv ZiBmaWx0ZXJpbmcgdGhlDQpjbGllbnQncyAqaW5ib3VuZCogdHJhZmZpYyBjYW4gY2F1c2UgYSBk ZW5pYWwgb2Ygc2VydmljZSAoc3RyaWN0DQpjbGllbnRzKSBvciBsb3NzIG9mIHByaXZhY3kgKG9w cG9ydHVuaXN0aWMgY2xpZW50cykgc2ltcGx5IGJ5IGRyb3BwaW5nDQppbmJvdW5kIGNvbm5lY3Rp b25zIGZyb20gYW55IFRDUCBwb3J0IDg1My4NCg0KQnV0IHRoZSBpbnRyb2R1Y3Rpb24gb2YgYW4g b3Bwb3J0dW5pc3RpY2FsbHktc2VjdXJlZCBtZXRhLXF1ZXJ5DQppbnRyb2R1Y2VzIGEgRG9TIGF0 dGFjayAoc3RyaWN0IGNsaWVudHMpIG9yIGxvc3Mgb2YgcHJpdmFjeQ0KKG9wcG9ydHVuaXN0aWMg Y2xpZW50cykgdGhhdCBjYW4gYmUgYWNoaWV2ZWQgYnkgYSB3ZWFrZXIgYXR0YWNrZXIuDQpTaW5j ZSB3ZSdyZSB0YWxraW5nIGFib3V0IGFuIGF0dGFja2VyIHRoYXQgaXMgKm5vdCogaW4gY29udHJv bCBvZiB0aGUNCm5ldHdvcmssIHRoZSBmb2xsb3dpbmcgYW5hbHlzaXMgYXNzdW1lcyB0aGF0IHRo ZSB0aGUgbmV0d29yayBwcm92aWRlcw0KImxlZ2l0aW1hdGUiIERIQ1Agc2VydmljZSwgd2hpY2gg aXMgc3VwcG9zZWQgdG8gcG9pbnQgdGhlIGNsaWVudCB0byBhDQoibGVnaXRpbWF0ZSIgc3RhbmRh cmQgRE5TIHJlc29sdmVyICh3aGljaCBtYXkgb3IgbWF5IG5vdCBiZQ0KcHJpdmFjeS1lbmFibGVk LCBidXQgaXMgc3VmZmljaWVudCBmb3IgYW5zd2VyaW5nIGFuIG9wcG9ydHVuaXN0aWMNCm1ldGFx dWVyeSBjb3JyZWN0bHkpLg0KDQpJbiBwYXJ0aWN1bGFyLCB0aGUgYXR0YWNrZXIgbmVlZHMgb25s eSBvbmUgb2YgdGhlIGZvbGxvd2luZyB0d28NCmNhcGFiaWxpdGllczoNCg0KICAoYSkgQ29udHJv bGxpbmcgdGhlICJsZWdpdGltYXRlIiBESENQIHNlcnZlciwgb3IgZGV0ZWN0aW5nIHRoZQ0KICAg ICAgY2xpZW50J3MgREhDUCByZXF1ZXN0IGFuZCByYWNpbmcgdGhlICJsZWdpdGltYXRlIiBESENQ IHNlcnZlciB0bw0KICAgICAgcmV0dXJuIGEgREhDUCByZXNwb25zZSAodGhpcyBhbGxvd3MgdGhl IGF0dGFja2VyIHRvIHNldCB0aGUNCiAgICAgIHJlc29sdmVyIHVzZWQgYnkgdGhlIGNsaWVudCBm b3IgaXRzIG9wcG9ydHVuaXN0aWMgbWV0YXF1ZXJ5KSwgb3INCg0KICAoYikgQ29udHJvbGxpbmcg dGhlICJsZWdpdGltYXRlIiBETlMgcmVzb2x2ZXIsIG9yIGRldGVjdGluZyB0aGUNCiAgICAgIGNs aWVudCdzIG9wcG9ydHVuaXN0aWMgbWV0YXF1ZXJ5IGFuZCByYWNpbmcgdGhlICJsZWdpdGltYXRl IiBETlMNCiAgICAgIHJlc29sdmVyIHRvIHByb3ZpZGUgYSBtYWxpY2lvdXMgRE5TIHJlc3BvbnNl Lg0KDQpJbiBlaXRoZXIgY2FzZSwgdGhlIHJlc3VsdCBpcyB0aGF0IHRoZSBhdHRhY2tlciBoYXMg cG9pc29uZWQgdGhlDQpjbGllbnQncyBtZXRhLWNhY2hlIC0tIGl0cyBiZXN0IGd1ZXNzIGF0IHRo ZSBsb2NhdGlvbiBvZiB0aGUgZGVzaXJlZA0KcHJpdmFjeS1lbmFibGVkIEROUyByZXNvbHZlci4g IEEgcG9pc29uZWQgbWV0YS1jYWNoZSByZXN1bHRzIGluIGEgRG9TDQpmb3IgY2xpZW50cyBpbiAi U3RyaWN0IiBtb2RlIGJlY2F1c2UgdGhlIGF0dGFja2VyJ3MgYW5zd2VyaW5nIEROUw0KcmVzb2x2 ZXIgYXQgdGhlIGxlYXJuZWQgYWRkcmVzcyBjYW5ub3QgYXV0aGVudGljYXRlLiAgQSBwb2lzb25l ZA0KbWV0YS1jYWNoZSByZXN1bHRzIGluIGEgbG9zcyBvZiBwcml2YWN5IGZvciBjbGllbnRzIGlu ICJPcHBvcnR1bmlzdGljIg0KbW9kZSBiZWNhdXNlIHRoZXkgd2lsbCBjb25uZWN0IHdpdGhvdXQg YXV0aGVudGljYXRpb24gdG8gdGhlIGF0dGFja2VyJ3MNCmFuc3dlcmluZyBETlMgcmVzb2x2ZXIu DQoNCkhhdmUgaSBnb3QgdGhhdCByaWdodD8NCg0KRE5TU0VDIHZhbGlkYXRpb24gZG9lcyBub3Qg bWl0aWdhdGUgdGhpcyBhdHRhY2suDQoNClJlZ2FyZGxlc3Mgb2YgdGhlIHByb2ZpbGUsIHRoZSBj bGllbnQgaGFzIGZvdXIgb3B0aW9ucyB3aGVuIGl0DQpkaXNjb3ZlcnMgdGhhdCB0aGUgcmVzcG9u c2UgdG8gdGhlIG1ldGFkYXRhIHF1ZXJ5IHdhcyBmb3JnZWQgKG9yIGF0DQphbnkgcmF0ZSBpcyBu b3QgdmFsaWRhdGFibGUpLiAgSXQgY2FuOg0KDQogICgwKSBpZ25vcmUgdGhlIHJlc3BvbnNlLCBy ZXN1bHRpbmcgaW4gYSBEb1MgcmVnYXJkbGVzcyBvZiBwcm9maWxlLA0KICAgICAgb3INCg0KICAo MSkgaWdub3JlIHRoZSB2YWxpZGF0aW9uIGZhaWx1cmUsIGFuZCB0cnkgY29ubmVjdGluZyB0byB0 aGUNCiAgICAgIHByb3Bvc2VkIGFkZHJlc3MgYW55d2F5IChyZXN1bHRpbmcgaW4gYSBEb1MgZm9y IHN0cmljdCBjbGllbnRzDQogICAgICBiZWNhdXNlIHRoZSBzZXJ2ZXIgZG9lcyBub3QgdmFsaWRh dGUsIG9yIGEgbG9zcyBvZiBwcml2YWN5IGZvcg0KICAgICAgb3Bwb3J0dW5pc3RpYyBjbGllbnRz KSwgb3INCg0KICAoMikgcmV0cnkgdGhlIG1ldGFxdWVyeSAoaW4gdGhlIGhvcGVzIHRoYXQgdGhl aXIgYXR0YWNrZXIgaXMgaW4gY2xhc3MNCiAgICAgICJiIiBhbmQgbm90IGluIGZ1bGwgY29udHJv bCBvZiB0aGUgImxlZ2l0aW1hdGUiIEROUyByZXNvbHZlcikgYW5kDQogICAgICBtYXliZSB0aGUg bGVnaXRpbWF0ZSBETlMgcmVzcG9uc2Ugd2lsbCBjb21lIGluLCBvcg0KDQogICgzKSBhYm9ydCB0 aGUgbmV0d29yayBjb25uZWN0aW9uIGFuZCByZXRyeSBESENQIChpbiB0aGUgaG9wZXMgdGhhdCB0 aGUNCiAgICAgIGF0dGFja2VyIGlzIGluIGNsYXNzICJhIiBhbmQgbm90IGluIGZ1bGwgY29udHJv bCBvZiB0aGUNCiAgICAgICJsZWdpdGltYXRlIiBESENQIHNlcnZlcikgYW5kIG1heWJlIHRoZSBs ZWdpdGltYXRlIERIQ1AgcmVzcG9uc2UNCiAgICAgIHdpbGwgY29tZSBpbi4NCg0KQ2hvaWNlIDAg aXMgdGhlIHNhbWUgb3V0Y29tZSBhcyB0aGUgbm9uLUROU1NFQy12YWxpZGF0aW5nIHNjZW5hcmlv IGZvcg0Kc3RyaWN0IGNsaWVudHMgKG5vIG1pdGlnYXRpb24pLCBhbmQgKnN0cmljdGx5IHdvcnNl KiBmb3Igb3Bwb3J0dW5pc3RpYw0KY2xpZW50cywgYmVjYXVzZSBpdCBjb252ZXJ0cyBhIGxvc3Mg b2YgcHJpdmFjeSB0byBhIERvUywgd2hpY2ggaXMgaW4NCmRpcmVjdCBvcHBvc2l0aW9uIHRvIHRo ZSBzdGF0ZWQgZ29hbCBvZiB0aGUgb3Bwb3J0dW5pc3RpYyBwcm9maWxlLg0KDQpDaG9pY2UgMSBp cyBleGFjdGx5IHRoZSBzYW1lIG91dGNvbWUgYXMgdGhlIG5vbi1ETlNTRUMtdmFsaWRhdGluZw0K c2NlbmFyaW8gZm9yIGFsbCBjbGllbnRzLiAobm8gbWl0aWdhdGlvbikNCg0KQ2hvaWNlcyAyIGFu ZCAzIGFyZSBpbnRlcmVzdGluZyB0aG91Z2h0IGV4cGVyaW1lbnRzLCBidXQgYXJlIG5vdA0KZGly ZWN0bHkgY29udGVtcGxhdGVkIGluIHRoZSBkcmFmdCAoYW5kIGkgdGhpbmsgdGhleSB3b3VsZCBi ZSBhDQpkaXN0cmFjdGlvbiBmcm9tIHRoZSBnb2FsIG9mIHRoZSBkcmFmdCAtLSB0aGlzIGRyYWZ0 IGlzIG5vdCAiaG93IHRvIGRvDQpzdGFnZWQgb3Bwb3J0dW5pc3RpYyBmYWxsYmFjayBpbiB0aGUg ZmFjZSBvZiBhbiBhcmJpdHJhcmlseSBjb3JydXB0DQpuZXR3b3JrIiksIHNvIGkgd29uJ3QgZ28g aW50byB0aGVtIGhlcmUuDQoNCkF0IGJlc3QsIEROU1NFQyB2YWxpZGF0aW9uIG9mIHRoZSBtZXRh cXVlcnkgY291bGQgYmUgdXNlZCB0byBwcm92aWRlDQphZGRpdGlvbmFsIHJlcG9ydGluZyBpbmZv cm1hdGlvbiB0byBhbnkgY2xpZW50LWludGVybmFsDQphdWRpdGluZy9yZXBvcnRpbmcgb3Igb3Ro ZXIgZGVmZW5zaXZlIG1lYXN1cmVzOyBidXQgYWdhaW4sIHRoaXMgZHJhZnQNCnNob3VsZCBub3Qg Z28gaW50byB0aG9zZSBpbiBhbnkgZGV0YWlsLg0KDQpCYWNrZ3JvdW5kDQotLS0tLS0tLS0tDQoN ClRvIGJlIGNsZWFyIGFib3V0IHdoZXJlIHRoaXMgYW5hbHlzaXMgaXMgY29taW5nIGZyb20sIG15 IHJ1bGUgb2YgdGh1bWINCmZvciB0aGVzZSB0d28gcHJvZmlsZXMgaXM6DQoNCiAqIFN0cmljdA0K DQogICBEbyB3aGF0ZXZlciB5b3UgY2FuIHRvIGNvbm5lY3QgdG8gdGhlIHByZWZlcnJlZCBwcml2 YWN5LWVuYWJsZWQNCiAgIHJlc29sdmVyLCBidXQgZG9uJ3QgYWN0dWFsbHkgc2VuZCBxdWVyaWVz IHVubGVzcyB5b3UncmUgc3VyZSB5b3UNCiAgIGhhdmUgYXV0aGVudGljYXRlZCB0aGUgc2VydmVy Lg0KDQogKiBPcHBvcnR1bmlzdGljDQoNCiAgIERvIHdoYXRldmVyIHlvdSBjYW4gdG8gY29ubmVj dCB0byB0aGUgcHJlZmVycmVkIHByaXZhY3ktZW5hYmxlZA0KICAgcmVzb2x2ZXIsIGJ1dCBnbyBh aGVhZCBhbmQgc2VuZCB5b3VyIHF1ZXJpZXMgdG8gaXQgYW55d2F5LCBldmVuIGlmDQogICBpdCBj YW5ub3QgYmUgYXV0aGVudGljYXRlZC4NCg0KTm90ZSB0aGF0IGJvdGggbW9kZXMgY2FuIHJlcG9y dCAoZS5nLiwgdG8gYSBsb2NhbCBzeXN0ZW0NCmF1ZGl0b3IvbW9uaXRvci9wb2xpY3ktYWdlbnQp IGFueSBmYWlsdXJlcyBvciBlcnJvcnMgdGhleSBlbmNvdW50ZXIuDQpCdXQgU3RyaWN0IG1vZGUg d2lsbCBmYWlsIGNsb3NlZCAoRG9TKSwgYW5kIE9wcG9ydHVuaXN0aWMgbW9kZSB3aWxsDQpmYWls IG9wZW4gKGxvc3Mgb2YgcHJpdmFjeSkuDQoNClRvIGJlIGNsZWFyOiB0aGUgY2xpZW50IGlzICps b2NhbGx5IGNvbmZpZ3VyZWQqIHRvIGJlIGVpdGhlciBpbiBTdHJpY3QNCm9yIE9wcG9ydHVuaXN0 aWMgbW9kZS4gIE9ydGhvZ29uYWxseSwgaXQgaXMgYWxzbyBsb2NhbGx5IGNvbmZpZ3VyZWQgd2l0 aA0Kc29tZSBzZXJ2ZXIgYXV0aGVudGljYXRpb24gaW5mb3JtYXRpb24uDQoNCklmIGl0cyBsb2Nh bGx5LWNvbmZpZ3VyZWQgc2VydmVyIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uIGlzIG9mIHRo ZQ0KZm9ybSAiQUROIiBvbmx5LCB0aGVuIC0tIGV2ZW4gd2hlbiBjb25maWd1cmVkIGluIFN0cmlj dCBtb2RlIC0tIGl0DQp3aWxsIGRvIGFuIE9wcG9ydHVuaXN0aWMgRE5TIHJlc29sdXRpb24gb2Yg dGhlIGFkZHJlc3Mgb2YgdGhlIGRlc2lyZWQNCnJlc29sdmVyLiAgVGhpcyBpcyB0aGUgIm9wcG9y dHVuaXN0aWMgbWV0YS1xdWVyeSIuDQoNCk1hbnkgbW9vbnMgYWdvLCBla3Igd3JvdGU6DQoNCj4g SS5lLiwgaWYgeW91IGRldGVybWluZSB3aGV0aGVyIHRvIGFkb3B0IGEgU3RyaWN0IHBvbGljeSBi YXNlZCBvbg0KPiBPcHBvcnR1bmlzdGljIHF1ZXJpZXMsIHRoZW4geW91IGFyZSBiYWNrIHRvIHRo ZSBhY3RpdmUgYXR0YWNrDQo+IHNldHRpbmcuDQoNCkJ1dCB0aGUgY2xpZW50IGlzICpub3QqIGRl dGVybWluaW5nIHdoZXRoZXIgdG8gYWRvcHQgYSBTdHJpY3QgcG9saWN5DQpiYXNlZCBvbiB0aGUg b3Bwb3J0dW5pc3RpYyBtZXRhLXF1ZXJ5LiAgSXQgaGFzIGFscmVhZHkgZGVjaWRlZCB3aGljaA0K cHJvZmlsZSBpdCBpcyB1c2luZywgYW5kIHRoZSBvcHBvcnR1bmlzdGljIG1ldGEtcXVlcnkgbWVy ZWx5IHRvIGZpbmQNCnRoZSBJUCBhZGRyZXNzIG9mIGl0cyBkZXNpcmVkIHByaXZhY3ktZW5hYmxl ZCBETlMgcmVzb2x2ZXIuDQoNCg0KU28gaSBndWVzcyBpJ20gc3RpbGwgRElTQ1VTU2luZyBla3In cyBESVNDVVNTLCB3aGljaCBpcyBhbiB1bmZvcnR1bmF0ZQ0Kc3RhdGUgZm9yIHRoZSBkcmFmdCB0 byBiZSBpbi4gOigNCg0KDQpJIHdlbGNvbWUgY2xhcmlmaWNhdGlvbiBpZiBpJ3ZlIG1pc3VuZGVy c3Rvb2QgdGhlIHByb2JsZW0gd2UncmUgdHJ5aW5nDQp0byBhZGRyZXNzIGhlcmUsIG9yIGlmIGkn dmUgc29tZWhvdyBsZXQgbXlzZWxmIGxhcHNlIGludG8gc29tZSBzb3J0IG9mDQoicHJpdmFjeSBu aWhpbGlzbSIuDQoNCiAgICAgICAgIC0tZGtnDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpkbnMtcHJpdmFjeSBtYWlsaW5nIGxpc3QNCmRucy1wcml2 YWN5QGlldGYub3JnPG1haWx0bzpkbnMtcHJpdmFjeUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zLXByaXZhY3kNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRucy1wcml2YWN5IG1haWxpbmcgbGlzdA0K ZG5zLXByaXZhY3lAaWV0Zi5vcmc8bWFpbHRvOmRucy1wcml2YWN5QGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnMtcHJpdmFjeQ0K --_000_DM5PR16MB1788C0A59EDED66095D2F52BEA590DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5 bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp Zjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW4gYWN0 aXZlIGF0dGFja2VyIGNhbiBkcm9wIEROUyBtZXNzYWdlcyB3aXRoIEROU1NFQyByZWNvcmRzLCBz ZXQgdGhlIENEIGJpdCBpbiB0aGUgRE5TIHF1ZXJ5LCBBRCBiaXQgaW4gdGhlIEROUyByZXNwb25z ZSAoc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MDM1I3NlY3Rpb24tNyksDQog Y2xlYXIgdGhlIEROU1NFQyBPSyBiaXQgaW4gdGhlIEROUyBxdWVyeSBvciBzdHJpcCB0aGUgRE5T U0VDIGRhdGEgZnJvbSB0aGUgRE5TIHJlc3BvbnNlIHRvIGRpc2FibGUgRE5TU0VDIChTZWN0aW9u DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzIyNSI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzMyMjU8L2E+KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RE5TU0VDIGNh bm5vdCBiZSBtYW5kYXRlZCBmb3Igb3Bwb3J0dW5pc3RpYyBwcm9maWxlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5h bWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2Ui Pjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUGF1bCBXb3V0ZXJzIFttYWlsdG86cGF1bEBu b2hhdHMuY2FdDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDMwLCAyMDE3IDI6 NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0O1RpcnVt YWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBCZW4gU2No d2FydHogJmx0O2JlbWFzY0Bnb29nbGUuY29tJmd0OzsgRGFuaWVsIEthaG4gR2lsbG1vciAmbHQ7 ZGtnQGZpZnRoaG9yc2VtYW4ubmV0Jmd0OzsgZG5zLXByaXZhY3lAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtkbnMtcHJpdmFjeV0gcmV2aWV3IG9mIGRyYWZ0LWlldGYtZHByaXZl LWR0bHMtYW5kLXRscy1wcm9maWxlcy0xMTogd2Ugc2hvdWxkIHJldmVydCBETlNTRUMgdmFsaWRh dGlvbiByZXF1aXJlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE9jdCAzMCwgMjAxNywgYXQgMTM6MDksIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVk ZHkgJmx0OzxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29t Ij5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+JiM0MzsxLCBETlNTRUMgaXRzZWxmIGlzIHN1c2NlcHRpYmxlIHRvIGFjdGl2ZSBhdHRhY2tz IGFuZCBuZWVkcyBhIHNlY3VyZSBjaGFubmVsIHRvIHByb3RlY3QgZnJvbSBhbiBhY3RpdmUgYXR0 YWNrZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGFjdGl2ZSBhdHRhY2tzIGlzIEROU1NFQyB2 dWxuZXJhYmxlIHRvPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmQgaG93IGRvZXMgdGhhdCBub3QgYWZmZWN0IFRMUz88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGF1bDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPi1UaXJ1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IGRucy1wcml2YWN5IFs8YSBocmVmPSJtYWlsdG86ZG5zLXByaXZhY3ktYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRucy1wcml2YWN5LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5CZW4gU2Nod2FydHo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJk YXksIE9jdG9iZXIgMjgsIDIwMTcgOTozNCBQTTxicj4NCjxiPlRvOjwvYj4gRGFuaWVsIEthaG4g R2lsbG1vciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRrZ0BmaWZ0aGhvcnNlbWFuLm5ldCI+ZGtnQGZp ZnRoaG9yc2VtYW4ubmV0PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpk bnMtcHJpdmFjeUBpZXRmLm9yZyI+ZG5zLXByaXZhY3lAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbZG5zLXByaXZhY3ldIHJldmlldyBvZiBkcmFmdC1pZXRmLWRwcml2ZS1k dGxzLWFuZC10bHMtcHJvZmlsZXMtMTE6IHdlIHNob3VsZCByZXZlcnQgRE5TU0VDIHZhbGlkYXRp b24gcmVxdWlyZW1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIERLRydzIGFuYWx5c2lzLjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgYXMgYW4gaW1wbGVtZW50b3IsIEkg dGhpbmsgdGhpcyByZXF1aXJlbWVudCB3b3VsZCBiZSBvbmVyb3VzLiZuYnNwOyBJbiB0aGUgc29m dHdhcmUgSSBhbSBtb2RpZnlpbmcsIGltcGxlbWVudGluZyBETlMtb3Zlci1UTFMgaXMgZHJhbWF0 aWNhbGx5IGVhc2llciB0aGFuIGFkZGluZyBhIHZhbGlkYXRpbmcgc3R1YiByZXNvbHZlci4mbmJz cDsgSSB3b3VsZG4ndCBiZSBpbXBsZW1lbnRpbmcgRE5TLW92ZXItVExTIGlmIEROU1NFQw0KIHdl cmUgbWFuZGF0b3J5IChpbiBlaXRoZXIgbW9kZSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgT2N0IDI3LCAyMDE3IGF0IDExOjQw IFBNLCBEYW5pZWwgS2FobiBHaWxsbW9yICZsdDs8YSBocmVmPSJtYWlsdG86ZGtnQGZpZnRoaG9y c2VtYW4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+ZGtnQGZpZnRoaG9yc2VtYW4ubmV0PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+SGV5IERQUklWRSBmb2xrcy0tPGJyPg0KPGJyPg0KQXBvbG9naWVzIGZvciB0aGUg ZGVsYXksIGFuZCB0aGF0IHRoaXMgbWVzc2FnZSBpcyBzbyBsb25nLiZuYnNwOyBJJ3ZlIHRyaWVk PGJyPg0KdG8gcmVjb25zdHJ1Y3QgdGhpcyBkaXNjdXNzaW9uIGFyb3VuZDxicj4NCmRyYWZ0LWll dGYtZHByaXZlLWR0bHMtYW5kLXRscy1wcm9maWxlcy0xMSBhcyBiZXN0IGkgY2FuLCBhbmQgbXk8 YnI+DQphbmFseXNpcyBmb2xsb3dzLiZuYnNwOyBJZiBpJ3ZlIG1pc3VuZGVydG9vZCBvciBtaXNh bmFseXplZCBzb21ldGhpbmcsPGJyPg0KcGxlYXNlIGxldCBtZSBrbm93Ljxicj4NCjxicj4NClN1 bW1hcnk8YnI+DQotLS0tLS0tPGJyPg0KPGJyPg0KSSBkbyBub3QgYmVsaWV2ZSB0aGF0IEROU1NF QyB2YWxpZGF0aW9uIGlzIHdhcnJhbnRlZCBhcyBhIG1pdGlnYXRpb248YnI+DQphZ2FpbnN0IGFu IGFjdGl2ZSBhdHRhY2tlciBpbiB0aGUgY29udGV4dCBvZiBhbiBvcHBvcnR1bmlzdGljIG1ldGFx dWVyeSw8YnI+DQpyZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIGNsaWVudCB1bHRpbWF0ZWx5IGlu dGVuZHMgdG8gZm9sbG93IGVpdGhlciB0aGU8YnI+DQpTdHJpY3Qgb3IgT3Bwb3J0dW5pc3RpYyBw cm9maWxlLjxicj4NCjxicj4NCkZ1cnRoZXJtb3JlLCBpIGJlbGlldmUgdGhhdCB0aGUgcHJvcG9z YWwgaW4gZHJhZnQtMTEgb2YgbWFraW5nIEROU1NFQzxicj4NCnZhbGlkYXRpb24gb2YgbWV0YXF1 ZXJpZXMgYSBNVVNUIGZvciB0aGUgb3Bwb3J0dW5pc3RpYyBwcm9maWxlIGlzPGJyPg0KKmFjdGl2 ZWx5IGhhcm1mdWwqIHRvIHRoZSBzdGF0ZWQgZ29hbCBvZiB0aGUgb3Bwb3J0dW5pc3RpYyBwcm9m aWxlPGJyPg0KKGkuZS4sICZxdW90O21heGltdW0gY2hhbmNlIG9mIEROUyBzZXJ2aWNlJnF1b3Q7 KS48YnI+DQo8YnI+DQpJIGxpa2UgdGhlIHJlb3JnYW5pemF0aW9uIGFuZCByZS13b3JkaW5nIG9m IHRoZSAmcXVvdDtVc2FnZSBQcm9maWxlcyZxdW90Ozxicj4NCnNlY3Rpb24gaW4gZHJhZnQtMTEs IGFuZCB0aGluayB3ZSBzaG91bGQga2VlcCBpdC4mbmJzcDsgQnV0IGkgdGhpbmsgdGhlPGJyPg0K b3RoZXIgY2hhbmdlcyBiZXR3ZWVuIGRyYWZ0LTEwIGFuZCBkcmFmdC0xMSBhcmUgdW53YXJyYW50 ZWQgYW5kIHNob3VsZDxicj4NCmJlIHJldmVydGVkLjxicj4NCjxicj4NCjxicj4NCkFuYWx5c2lz PGJyPg0KLS0tLS0tLS08YnI+DQo8YnI+DQpBSVVJLCB0aGUgc2NlbmFyaW8gdW5kZXIgZGlzY3Vz c2lvbiBpczo8YnI+DQo8YnI+DQombmJzcDsqIEEgRE5TIGNsaWVudCAoZm9sbG93aW5nIGVpdGhl ciB0aGUgc3RyaWN0IG9yIHRoZSBvcHBvcnR1bmlzdGljPGJyPg0KJm5ic3A7ICZuYnNwO3Byb2Zp bGUpPGJyPg0KJm5ic3A7KiB1c2luZyBvcHBvcnR1bmlzdGljIG1ldGEtcXVlcmllcyB0byBmaW5k IHRoZSBkZXNpcmVkIEROUyByZXNvbHZlcjxicj4NCiZuYnNwOyogaW4gdGhlIGZhY2Ugb2YgYW4g YWN0aXZlIGF0dGFja2VyPGJyPg0KPGJyPg0KV2UgYWxyZWFkeSBrbm93IHRoYXQgYW4gYXR0YWNr ZXIgY2FwYWJsZSBvZiBmaWx0ZXJpbmcgdGhlIGNsaWVudCdzPGJyPg0KKm91dGJvdW5kKiB0cmFm ZmljIGNhbiBjYXVzZSBhIGRlbmlhbCBvZiBzZXJ2aWNlIChmb3IgY2xpZW50cyBmb2xsb3dpbmc8 YnI+DQp0aGUgc3RyaWN0IHByb2ZpbGUpIG9yIGxvc3Mgb2YgcHJpdmFjeSAoZm9yIGNsaWVudHMg Zm9sbG93aW5nIHRoZTxicj4NCm9wcG9ydHVuaXN0aWMgcHJvZmlsZSwgYmVjYXVzZSB0aGV5IGZh bGwgYmFjayB0byBjbGVhcnRleHQpIHNpbXBseSBieTxicj4NCmRyb3BwaW5nIG91dGJvdW5kIGNv bm5lY3Rpb25zIHRvICphbnl3aGVyZSogVENQIHBvcnQgODUzLjxicj4NCjxicj4NCkxpa2V3aXNl LCBXZSBhbHNvIGtub3cgdGhhdCBhbiBhdHRhY2tlciBjYXBhYmxlIG9mIGZpbHRlcmluZyB0aGU8 YnI+DQpjbGllbnQncyAqaW5ib3VuZCogdHJhZmZpYyBjYW4gY2F1c2UgYSBkZW5pYWwgb2Ygc2Vy dmljZSAoc3RyaWN0PGJyPg0KY2xpZW50cykgb3IgbG9zcyBvZiBwcml2YWN5IChvcHBvcnR1bmlz dGljIGNsaWVudHMpIHNpbXBseSBieSBkcm9wcGluZzxicj4NCmluYm91bmQgY29ubmVjdGlvbnMg ZnJvbSBhbnkgVENQIHBvcnQgODUzLjxicj4NCjxicj4NCkJ1dCB0aGUgaW50cm9kdWN0aW9uIG9m IGFuIG9wcG9ydHVuaXN0aWNhbGx5LXNlY3VyZWQgbWV0YS1xdWVyeTxicj4NCmludHJvZHVjZXMg YSBEb1MgYXR0YWNrIChzdHJpY3QgY2xpZW50cykgb3IgbG9zcyBvZiBwcml2YWN5PGJyPg0KKG9w cG9ydHVuaXN0aWMgY2xpZW50cykgdGhhdCBjYW4gYmUgYWNoaWV2ZWQgYnkgYSB3ZWFrZXIgYXR0 YWNrZXIuPGJyPg0KU2luY2Ugd2UncmUgdGFsa2luZyBhYm91dCBhbiBhdHRhY2tlciB0aGF0IGlz ICpub3QqIGluIGNvbnRyb2wgb2YgdGhlPGJyPg0KbmV0d29yaywgdGhlIGZvbGxvd2luZyBhbmFs eXNpcyBhc3N1bWVzIHRoYXQgdGhlIHRoZSBuZXR3b3JrIHByb3ZpZGVzPGJyPg0KJnF1b3Q7bGVn aXRpbWF0ZSZxdW90OyBESENQIHNlcnZpY2UsIHdoaWNoIGlzIHN1cHBvc2VkIHRvIHBvaW50IHRo ZSBjbGllbnQgdG8gYTxicj4NCiZxdW90O2xlZ2l0aW1hdGUmcXVvdDsgc3RhbmRhcmQgRE5TIHJl c29sdmVyICh3aGljaCBtYXkgb3IgbWF5IG5vdCBiZTxicj4NCnByaXZhY3ktZW5hYmxlZCwgYnV0 IGlzIHN1ZmZpY2llbnQgZm9yIGFuc3dlcmluZyBhbiBvcHBvcnR1bmlzdGljPGJyPg0KbWV0YXF1 ZXJ5IGNvcnJlY3RseSkuPGJyPg0KPGJyPg0KSW4gcGFydGljdWxhciwgdGhlIGF0dGFja2VyIG5l ZWRzIG9ubHkgb25lIG9mIHRoZSBmb2xsb3dpbmcgdHdvPGJyPg0KY2FwYWJpbGl0aWVzOjxicj4N Cjxicj4NCiZuYnNwOyAoYSkgQ29udHJvbGxpbmcgdGhlICZxdW90O2xlZ2l0aW1hdGUmcXVvdDsg REhDUCBzZXJ2ZXIsIG9yIGRldGVjdGluZyB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBj bGllbnQncyBESENQIHJlcXVlc3QgYW5kIHJhY2luZyB0aGUgJnF1b3Q7bGVnaXRpbWF0ZSZxdW90 OyBESENQIHNlcnZlciB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHJldHVybiBhIERIQ1Ag cmVzcG9uc2UgKHRoaXMgYWxsb3dzIHRoZSBhdHRhY2tlciB0byBzZXQgdGhlPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgcmVzb2x2ZXIgdXNlZCBieSB0aGUgY2xpZW50IGZvciBpdHMgb3Bwb3J0 dW5pc3RpYyBtZXRhcXVlcnkpLCBvcjxicj4NCjxicj4NCiZuYnNwOyAoYikgQ29udHJvbGxpbmcg dGhlICZxdW90O2xlZ2l0aW1hdGUmcXVvdDsgRE5TIHJlc29sdmVyLCBvciBkZXRlY3RpbmcgdGhl PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2xpZW50J3Mgb3Bwb3J0dW5pc3RpYyBtZXRhcXVl cnkgYW5kIHJhY2luZyB0aGUgJnF1b3Q7bGVnaXRpbWF0ZSZxdW90OyBETlM8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyByZXNvbHZlciB0byBwcm92aWRlIGEgbWFsaWNpb3VzIEROUyByZXNwb25z ZS48YnI+DQo8YnI+DQpJbiBlaXRoZXIgY2FzZSwgdGhlIHJlc3VsdCBpcyB0aGF0IHRoZSBhdHRh Y2tlciBoYXMgcG9pc29uZWQgdGhlPGJyPg0KY2xpZW50J3MgbWV0YS1jYWNoZSAtLSBpdHMgYmVz dCBndWVzcyBhdCB0aGUgbG9jYXRpb24gb2YgdGhlIGRlc2lyZWQ8YnI+DQpwcml2YWN5LWVuYWJs ZWQgRE5TIHJlc29sdmVyLiZuYnNwOyBBIHBvaXNvbmVkIG1ldGEtY2FjaGUgcmVzdWx0cyBpbiBh IERvUzxicj4NCmZvciBjbGllbnRzIGluICZxdW90O1N0cmljdCZxdW90OyBtb2RlIGJlY2F1c2Ug dGhlIGF0dGFja2VyJ3MgYW5zd2VyaW5nIEROUzxicj4NCnJlc29sdmVyIGF0IHRoZSBsZWFybmVk IGFkZHJlc3MgY2Fubm90IGF1dGhlbnRpY2F0ZS4mbmJzcDsgQSBwb2lzb25lZDxicj4NCm1ldGEt Y2FjaGUgcmVzdWx0cyBpbiBhIGxvc3Mgb2YgcHJpdmFjeSBmb3IgY2xpZW50cyBpbiAmcXVvdDtP cHBvcnR1bmlzdGljJnF1b3Q7PGJyPg0KbW9kZSBiZWNhdXNlIHRoZXkgd2lsbCBjb25uZWN0IHdp dGhvdXQgYXV0aGVudGljYXRpb24gdG8gdGhlIGF0dGFja2VyJ3M8YnI+DQphbnN3ZXJpbmcgRE5T IHJlc29sdmVyLjxicj4NCjxicj4NCkhhdmUgaSBnb3QgdGhhdCByaWdodD88YnI+DQo8YnI+DQpE TlNTRUMgdmFsaWRhdGlvbiBkb2VzIG5vdCBtaXRpZ2F0ZSB0aGlzIGF0dGFjay48YnI+DQo8YnI+ DQpSZWdhcmRsZXNzIG9mIHRoZSBwcm9maWxlLCB0aGUgY2xpZW50IGhhcyBmb3VyIG9wdGlvbnMg d2hlbiBpdDxicj4NCmRpc2NvdmVycyB0aGF0IHRoZSByZXNwb25zZSB0byB0aGUgbWV0YWRhdGEg cXVlcnkgd2FzIGZvcmdlZCAob3IgYXQ8YnI+DQphbnkgcmF0ZSBpcyBub3QgdmFsaWRhdGFibGUp LiZuYnNwOyBJdCBjYW46PGJyPg0KPGJyPg0KJm5ic3A7ICgwKSBpZ25vcmUgdGhlIHJlc3BvbnNl LCByZXN1bHRpbmcgaW4gYSBEb1MgcmVnYXJkbGVzcyBvZiBwcm9maWxlLDxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7IG9yPGJyPg0KPGJyPg0KJm5ic3A7ICgxKSBpZ25vcmUgdGhlIHZhbGlkYXRp b24gZmFpbHVyZSwgYW5kIHRyeSBjb25uZWN0aW5nIHRvIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IHByb3Bvc2VkIGFkZHJlc3MgYW55d2F5IChyZXN1bHRpbmcgaW4gYSBEb1MgZm9yIHN0 cmljdCBjbGllbnRzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmVjYXVzZSB0aGUgc2VydmVy IGRvZXMgbm90IHZhbGlkYXRlLCBvciBhIGxvc3Mgb2YgcHJpdmFjeSBmb3I8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBvcHBvcnR1bmlzdGljIGNsaWVudHMpLCBvcjxicj4NCjxicj4NCiZuYnNw OyAoMikgcmV0cnkgdGhlIG1ldGFxdWVyeSAoaW4gdGhlIGhvcGVzIHRoYXQgdGhlaXIgYXR0YWNr ZXIgaXMgaW4gY2xhc3M8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtiJnF1b3Q7IGFu ZCBub3QgaW4gZnVsbCBjb250cm9sIG9mIHRoZSAmcXVvdDtsZWdpdGltYXRlJnF1b3Q7IEROUyBy ZXNvbHZlcikgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgbWF5YmUgdGhlIGxlZ2l0aW1h dGUgRE5TIHJlc3BvbnNlIHdpbGwgY29tZSBpbiwgb3I8YnI+DQo8YnI+DQombmJzcDsgKDMpIGFi b3J0IHRoZSBuZXR3b3JrIGNvbm5lY3Rpb24gYW5kIHJldHJ5IERIQ1AgKGluIHRoZSBob3BlcyB0 aGF0IHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGF0dGFja2VyIGlzIGluIGNsYXNzICZx dW90O2EmcXVvdDsgYW5kIG5vdCBpbiBmdWxsIGNvbnRyb2wgb2YgdGhlPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJnF1b3Q7bGVnaXRpbWF0ZSZxdW90OyBESENQIHNlcnZlcikgYW5kIG1heWJl IHRoZSBsZWdpdGltYXRlIERIQ1AgcmVzcG9uc2U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB3 aWxsIGNvbWUgaW4uPGJyPg0KPGJyPg0KQ2hvaWNlIDAgaXMgdGhlIHNhbWUgb3V0Y29tZSBhcyB0 aGUgbm9uLUROU1NFQy12YWxpZGF0aW5nIHNjZW5hcmlvIGZvcjxicj4NCnN0cmljdCBjbGllbnRz IChubyBtaXRpZ2F0aW9uKSwgYW5kICpzdHJpY3RseSB3b3JzZSogZm9yIG9wcG9ydHVuaXN0aWM8 YnI+DQpjbGllbnRzLCBiZWNhdXNlIGl0IGNvbnZlcnRzIGEgbG9zcyBvZiBwcml2YWN5IHRvIGEg RG9TLCB3aGljaCBpcyBpbjxicj4NCmRpcmVjdCBvcHBvc2l0aW9uIHRvIHRoZSBzdGF0ZWQgZ29h bCBvZiB0aGUgb3Bwb3J0dW5pc3RpYyBwcm9maWxlLjxicj4NCjxicj4NCkNob2ljZSAxIGlzIGV4 YWN0bHkgdGhlIHNhbWUgb3V0Y29tZSBhcyB0aGUgbm9uLUROU1NFQy12YWxpZGF0aW5nPGJyPg0K c2NlbmFyaW8gZm9yIGFsbCBjbGllbnRzLiAobm8gbWl0aWdhdGlvbik8YnI+DQo8YnI+DQpDaG9p Y2VzIDIgYW5kIDMgYXJlIGludGVyZXN0aW5nIHRob3VnaHQgZXhwZXJpbWVudHMsIGJ1dCBhcmUg bm90PGJyPg0KZGlyZWN0bHkgY29udGVtcGxhdGVkIGluIHRoZSBkcmFmdCAoYW5kIGkgdGhpbmsg dGhleSB3b3VsZCBiZSBhPGJyPg0KZGlzdHJhY3Rpb24gZnJvbSB0aGUgZ29hbCBvZiB0aGUgZHJh ZnQgLS0gdGhpcyBkcmFmdCBpcyBub3QgJnF1b3Q7aG93IHRvIGRvPGJyPg0Kc3RhZ2VkIG9wcG9y dHVuaXN0aWMgZmFsbGJhY2sgaW4gdGhlIGZhY2Ugb2YgYW4gYXJiaXRyYXJpbHkgY29ycnVwdDxi cj4NCm5ldHdvcmsmcXVvdDspLCBzbyBpIHdvbid0IGdvIGludG8gdGhlbSBoZXJlLjxicj4NCjxi cj4NCkF0IGJlc3QsIEROU1NFQyB2YWxpZGF0aW9uIG9mIHRoZSBtZXRhcXVlcnkgY291bGQgYmUg dXNlZCB0byBwcm92aWRlPGJyPg0KYWRkaXRpb25hbCByZXBvcnRpbmcgaW5mb3JtYXRpb24gdG8g YW55IGNsaWVudC1pbnRlcm5hbDxicj4NCmF1ZGl0aW5nL3JlcG9ydGluZyBvciBvdGhlciBkZWZl bnNpdmUgbWVhc3VyZXM7IGJ1dCBhZ2FpbiwgdGhpcyBkcmFmdDxicj4NCnNob3VsZCBub3QgZ28g aW50byB0aG9zZSBpbiBhbnkgZGV0YWlsLjxicj4NCjxicj4NCkJhY2tncm91bmQ8YnI+DQotLS0t LS0tLS0tPGJyPg0KPGJyPg0KVG8gYmUgY2xlYXIgYWJvdXQgd2hlcmUgdGhpcyBhbmFseXNpcyBp cyBjb21pbmcgZnJvbSwgbXkgcnVsZSBvZiB0aHVtYjxicj4NCmZvciB0aGVzZSB0d28gcHJvZmls ZXMgaXM6PGJyPg0KPGJyPg0KJm5ic3A7KiBTdHJpY3Q8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 RG8gd2hhdGV2ZXIgeW91IGNhbiB0byBjb25uZWN0IHRvIHRoZSBwcmVmZXJyZWQgcHJpdmFjeS1l bmFibGVkPGJyPg0KJm5ic3A7ICZuYnNwO3Jlc29sdmVyLCBidXQgZG9uJ3QgYWN0dWFsbHkgc2Vu ZCBxdWVyaWVzIHVubGVzcyB5b3UncmUgc3VyZSB5b3U8YnI+DQombmJzcDsgJm5ic3A7aGF2ZSBh dXRoZW50aWNhdGVkIHRoZSBzZXJ2ZXIuPGJyPg0KPGJyPg0KJm5ic3A7KiBPcHBvcnR1bmlzdGlj PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0RvIHdoYXRldmVyIHlvdSBjYW4gdG8gY29ubmVjdCB0 byB0aGUgcHJlZmVycmVkIHByaXZhY3ktZW5hYmxlZDxicj4NCiZuYnNwOyAmbmJzcDtyZXNvbHZl ciwgYnV0IGdvIGFoZWFkIGFuZCBzZW5kIHlvdXIgcXVlcmllcyB0byBpdCBhbnl3YXksIGV2ZW4g aWY8YnI+DQombmJzcDsgJm5ic3A7aXQgY2Fubm90IGJlIGF1dGhlbnRpY2F0ZWQuPGJyPg0KPGJy Pg0KTm90ZSB0aGF0IGJvdGggbW9kZXMgY2FuIHJlcG9ydCAoZS5nLiwgdG8gYSBsb2NhbCBzeXN0 ZW08YnI+DQphdWRpdG9yL21vbml0b3IvcG9saWN5LWFnZW50KSBhbnkgZmFpbHVyZXMgb3IgZXJy b3JzIHRoZXkgZW5jb3VudGVyLjxicj4NCkJ1dCBTdHJpY3QgbW9kZSB3aWxsIGZhaWwgY2xvc2Vk IChEb1MpLCBhbmQgT3Bwb3J0dW5pc3RpYyBtb2RlIHdpbGw8YnI+DQpmYWlsIG9wZW4gKGxvc3Mg b2YgcHJpdmFjeSkuPGJyPg0KPGJyPg0KVG8gYmUgY2xlYXI6IHRoZSBjbGllbnQgaXMgKmxvY2Fs bHkgY29uZmlndXJlZCogdG8gYmUgZWl0aGVyIGluIFN0cmljdDxicj4NCm9yIE9wcG9ydHVuaXN0 aWMgbW9kZS4mbmJzcDsgT3J0aG9nb25hbGx5LCBpdCBpcyBhbHNvIGxvY2FsbHkgY29uZmlndXJl ZCB3aXRoPGJyPg0Kc29tZSBzZXJ2ZXIgYXV0aGVudGljYXRpb24gaW5mb3JtYXRpb24uPGJyPg0K PGJyPg0KSWYgaXRzIGxvY2FsbHktY29uZmlndXJlZCBzZXJ2ZXIgYXV0aGVudGljYXRpb24gaW5m b3JtYXRpb24gaXMgb2YgdGhlPGJyPg0KZm9ybSAmcXVvdDtBRE4mcXVvdDsgb25seSwgdGhlbiAt LSBldmVuIHdoZW4gY29uZmlndXJlZCBpbiBTdHJpY3QgbW9kZSAtLSBpdDxicj4NCndpbGwgZG8g YW4gT3Bwb3J0dW5pc3RpYyBETlMgcmVzb2x1dGlvbiBvZiB0aGUgYWRkcmVzcyBvZiB0aGUgZGVz aXJlZDxicj4NCnJlc29sdmVyLiZuYnNwOyBUaGlzIGlzIHRoZSAmcXVvdDtvcHBvcnR1bmlzdGlj IG1ldGEtcXVlcnkmcXVvdDsuPGJyPg0KPGJyPg0KTWFueSBtb29ucyBhZ28sIGVrciB3cm90ZTo8 YnI+DQo8YnI+DQomZ3Q7IEkuZS4sIGlmIHlvdSBkZXRlcm1pbmUgd2hldGhlciB0byBhZG9wdCBh IFN0cmljdCBwb2xpY3kgYmFzZWQgb248YnI+DQomZ3Q7IE9wcG9ydHVuaXN0aWMgcXVlcmllcywg dGhlbiB5b3UgYXJlIGJhY2sgdG8gdGhlIGFjdGl2ZSBhdHRhY2s8YnI+DQomZ3Q7IHNldHRpbmcu PGJyPg0KPGJyPg0KQnV0IHRoZSBjbGllbnQgaXMgKm5vdCogZGV0ZXJtaW5pbmcgd2hldGhlciB0 byBhZG9wdCBhIFN0cmljdCBwb2xpY3k8YnI+DQpiYXNlZCBvbiB0aGUgb3Bwb3J0dW5pc3RpYyBt ZXRhLXF1ZXJ5LiZuYnNwOyBJdCBoYXMgYWxyZWFkeSBkZWNpZGVkIHdoaWNoPGJyPg0KcHJvZmls ZSBpdCBpcyB1c2luZywgYW5kIHRoZSBvcHBvcnR1bmlzdGljIG1ldGEtcXVlcnkgbWVyZWx5IHRv IGZpbmQ8YnI+DQp0aGUgSVAgYWRkcmVzcyBvZiBpdHMgZGVzaXJlZCBwcml2YWN5LWVuYWJsZWQg RE5TIHJlc29sdmVyLjxicj4NCjxicj4NCjxicj4NClNvIGkgZ3Vlc3MgaSdtIHN0aWxsIERJU0NV U1NpbmcgZWtyJ3MgRElTQ1VTUywgd2hpY2ggaXMgYW4gdW5mb3J0dW5hdGU8YnI+DQpzdGF0ZSBm b3IgdGhlIGRyYWZ0IHRvIGJlIGluLiA6KDxicj4NCjxicj4NCjxicj4NCkkgd2VsY29tZSBjbGFy aWZpY2F0aW9uIGlmIGkndmUgbWlzdW5kZXJzdG9vZCB0aGUgcHJvYmxlbSB3ZSdyZSB0cnlpbmc8 YnI+DQp0byBhZGRyZXNzIGhlcmUsIG9yIGlmIGkndmUgc29tZWhvdyBsZXQgbXlzZWxmIGxhcHNl IGludG8gc29tZSBzb3J0IG9mPGJyPg0KJnF1b3Q7cHJpdmFjeSBuaWhpbGlzbSZxdW90Oy48YnI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tZGtnPC9zcGFuPjxicj4NCjwvc3Bh bj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCmRucy1wcml2YWN5IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpkbnMtcHJp dmFjeUBpZXRmLm9yZyI+ZG5zLXByaXZhY3lAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnMtcHJpdmFjeSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zLXByaXZhY3k8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkbnMtcHJpdmFjeSBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZG5zLXByaXZhY3lAaWV0Zi5vcmciPmRucy1wcml2 YWN5QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG5zLXByaXZhY3kiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG5zLXByaXZhY3k8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB1788C0A59EDED66095D2F52BEA590DM5PR16MB1788namp_-- From nobody Mon Oct 30 04:17:31 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7094913F7A8 for ; Mon, 30 Oct 2017 04:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 LR8aMMDDv_LG for ; Mon, 30 Oct 2017 04:17:28 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 8AC4C13F655 for ; Mon, 30 Oct 2017 04:17:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yQX506HhFz1L5; Mon, 30 Oct 2017 12:17:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1509362244; bh=rI5xFl2NkVL5V3NjOe+QLbBGjwKxb+LlJ30EjL29P1s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hxhS8ItRuPotsechQrxVI/mH2Gk3UQ/aaDT/3xqDnMMs7lOtPC8D9+S/Q5RaMg4rU ZRldZ/bmwLSbFFvwVIQt+FYWuqWo08401OahcH1+ms40nX7BWDVdOhkk6i2qSpmZqg LvcLvKsuGn0IeWQtndGS5s6PNcfNg6Voe8UvudAo= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Z6FSttItHgOT; Mon, 30 Oct 2017 12:17:21 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 30 Oct 2017 12:17:20 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B063862D29; Mon, 30 Oct 2017 07:17:19 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B063862D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 97E1040D35AF; Mon, 30 Oct 2017 07:17:19 -0400 (EDT) Date: Mon, 30 Oct 2017 07:17:19 -0400 (EDT) From: Paul Wouters To: "Konda, Tirumaleswar Reddy" cc: Ben Schwartz , Daniel Kahn Gillmor , "dns-privacy@ietf.org" In-Reply-To: Message-ID: References: <878tfwey8w.fsf@fifthhorseman.net> <4C03CDB2-C7CD-429A-A810-0CA44CA35BF8@nohats.ca> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 11:17:30 -0000 On Mon, 30 Oct 2017, Konda, Tirumaleswar Reddy wrote: > An active attacker can drop DNS messages with DNSSEC records The same attacker can block TLS to 8.8.8.8 > set the CD bit in the DNS query, AD bit in the DNS response That will do nothing to validating DNS servers, as they don't use those bits for anything. > clear the DNSSEC OK bit in the DNS query That will return a BOGUS answer and will be detected as DoS attack. > or strip the DNSSEC data from the DNS response to disable DNSSEC (Section https://tools.ietf.org/html/rfc3225). That will return a BOGUS or INDETERMINATE answer and will be detected as DoS attack. You have not shown any actual active attack against DNSSEC. You have only shown denial of service attaks by packet mangling/dropping. All of that applies equally to TLS. Paul From nobody Mon Oct 30 04:19:42 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750E013F722 for ; Mon, 30 Oct 2017 04:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 zugl7_B0CfVB for ; Mon, 30 Oct 2017 04:19:40 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 DBDB913F717 for ; Mon, 30 Oct 2017 04:19:39 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yQX7Z2nNnz3BD; Mon, 30 Oct 2017 12:19:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1509362378; bh=5PiT7qXZmyizRF11FYqCTwxQmvymRLa3rT7OQXWQD9Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KNbFEUmLxpqQLHfj/4Vo+IUVoaecNDiPcVkPd+3c2pEX3KyXBaMXvLkCZkUFaHSTb 8YZsU0qN19rP1hAnzhqj5BcyWEtVQFYXwi3uI5Tbznm8dBpPc4cZE1S06c3Nac3lrp 3VBQiXWx9KdXc3dh++DNlaF1/MCCq1qg18w5XLV4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id xhFpCVTagnlf; Mon, 30 Oct 2017 12:19:37 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 30 Oct 2017 12:19:37 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8472762D29; Mon, 30 Oct 2017 07:19:36 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8472762D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6C26340D35AF; Mon, 30 Oct 2017 07:19:36 -0400 (EDT) Date: Mon, 30 Oct 2017 07:19:36 -0400 (EDT) From: Paul Wouters To: "Konda, Tirumaleswar Reddy" cc: Ben Schwartz , "dns-privacy@ietf.org" , Daniel Kahn Gillmor In-Reply-To: Message-ID: References: <878tfwey8w.fsf@fifthhorseman.net> <4C03CDB2-C7CD-429A-A810-0CA44CA35BF8@nohats.ca> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 11:19:41 -0000 On Mon, 30 Oct 2017, Konda, Tirumaleswar Reddy wrote: > draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC > validation requirement Just to be clear. DNSSEC provides authentication of data. TLS provides privacy of data. Both are needed so I am against this proposed change to remove DNSSEC validation as a requirement. DNSSEC is part of the core DNS. It's not a cherry. Paul From nobody Mon Oct 30 05:49:41 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F043713F5A3 for ; Mon, 30 Oct 2017 05:49:39 -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 ObFURIqCV0hL for ; Mon, 30 Oct 2017 05:49:37 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id B28EE139680 for ; Mon, 30 Oct 2017 05:49:37 -0700 (PDT) Received: from fifthhorseman.net (p578E653F.dip0.t-ipconnect.de [87.142.101.63]) by che.mayfirst.org (Postfix) with ESMTPSA id D8D58F99A; Mon, 30 Oct 2017 08:49:35 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 769C320650; Mon, 30 Oct 2017 13:31:07 +0100 (CET) From: Daniel Kahn Gillmor To: Paul Wouters , "Konda\, Tirumaleswar Reddy" Cc: Ben Schwartz , "dns-privacy\@ietf.org" In-Reply-To: References: <878tfwey8w.fsf@fifthhorseman.net> <4C03CDB2-C7CD-429A-A810-0CA44CA35BF8@nohats.ca> Date: Mon, 30 Oct 2017 13:31:04 +0100 Message-ID: <87fua0ddh3.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 12:49:40 -0000 --=-=-= Content-Type: text/plain On Mon 2017-10-30 07:19:36 -0400, Paul Wouters wrote: > Just to be clear. DNSSEC provides authentication of data. TLS provides > privacy of data. Both are needed so I am against this proposed change > to remove DNSSEC validation as a requirement. DNSSEC is part of the > core DNS. It's not a cherry. I'm not claiming that no clients should implement DNSSEC validation. I would be happy if every client did so. Please don't mistake this as a generic judgement on DNSSEC. It's about one particular situation where hard-fail is a bad idea. In particular, the situation under discussion is what clients should do in the event of a DNSSEC validation failure of an opportunistic "meta-query". As a reminder, the "opportunistic meta-query" is the best-effort lookup of the IP address(es) of the preferred DNS privacy resolver, under either Strict or Opportunistic profiles. In either profile, the meta-query itself is opportunistic -- it's an attempt to find some channel to the preferred resolver. But let's look at the two profiles separately: a) under the opportunistic profile, dropping the response to an opportunistic meta-query in the event of a DNSSEC validation failure transforms a loss of privacy into a DoS. This does not meet the stated goal of the opportunistic profile, "maximum chance of DNS service". b) under the strict profile, dropping the response to an opportunistic meta-query in the event of a DNSSEC validation failure will result in the same outcome (DoS) where the response to the meta-query comes from an attacker, because the attacker couldn't have provided a valid TLS endpoint in the first place. But in the scenario where DNSSEC either isn't available, or is misconfigured, it converts a successful connection attempt into a DoS. This is a net loss for the user. Put more simply: Opportunistic meta-queries are opportunistic. Encouraging or requiring hard-fail to DNSSEC validation of an opportunistic meta-query just amounts to a reduction of service, and provides no security or privacy improvements that i can see. If the goal is to enforce corroborative authentication of the DNS privacy server (e.g. via both DNSSEC and the X.509 cartel), i welcome a writeup of a "Extra Strict" profile that adds a DNSSEC validation requirement to the Strict profile. But that's not this draft. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAln3G4gACgkQFJitxsGS MjfchRAApuIZX4S5Aby7eSUKZ58Vq73rRaIP6OMKTYATQqz0qyAwQ6rQ8ajFrTFU N4nk5MJorNhL8eH8eXFX0/WoBzHvtpswGsTHedhtrUQBwH/HkPiaudHZ/4s0nOkh 0ocUyVlMiwSxAQtHnXkkrP361hMATU1RHmizBg3jG8lhZK85dn2pq+zpv4RoMpHD O+odUJXjQSfcI46MojknVUtceE9FWE5nL0sXIHvuC9okQdC7kU72H2pymPVBi8NP LlAklS2KdEHJkSANWlSpp09nb9l6c9xBvk/AQHi1eLa9SsD5Tf3kF55ALRb6lS0q EBETa4bCU1nfMm7TrAV8bYuLGAh/LJawk3gI1pSP3wNrgeTTL5ABAcRWrvlwZkSU Zc0L4FRrqFAl7B8kfrzNW8jmZ8zWgXFVMj1CkBi81bhnKH1CLmONctll2EtfWgw2 Aa4AZw4NGJgflRrazJOFtPpJVYhMN+E+sjuU+lNl95L/XQ6sVjsQRGrZSY1HhNwB SozR/AxDybNhncCQNVbdtRSheuipOrUE2pLavB5JMmfI1WAMFfVvGQMP+xGBBtg9 HK6DXzM9dZXeGQczUkxeFMgCJ1x3ySNWOGDcc+HcHONFWda+/csXDtsYdKBoeKBC 8LmSkpS3PEE5QwtyMXZEyEmy7wojKfUmg1QfAxULiIDnbA6aNnE= =/KWd -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 30 06:09:51 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B5D13F907 for ; Mon, 30 Oct 2017 06:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, 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 GiUFKVDHvj0N for ; Mon, 30 Oct 2017 06:09: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 28E7313F4FD for ; Mon, 30 Oct 2017 06:09:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5AA36BE50; Mon, 30 Oct 2017 13:09:46 +0000 (GMT) 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 I0C1FDcfpKNE; Mon, 30 Oct 2017 13:09:40 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 215CBBE4D; Mon, 30 Oct 2017 13:09:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1509368980; bh=/TSsieEVEHVeX59Vum5GO90n4mHL1UjbAgWEPc0ub4E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kZwF9fsjxIsEdHrwOkrELyh6EqtKW1KKydV+wOIL+Dy4q2FT6+aO3QsmbgP8mX8jo XN9AotTdwZHBYAuwzVkjdH79emblV+eiAyilS+IuYEh1seO3UkIOz+Fq1hLWeAtM0L fkaOL7krI3qQD3U/XEBangjDzRZpN5vXZjPz/dSg= To: Daniel Kahn Gillmor , dns-privacy@ietf.org References: <878tfwey8w.fsf@fifthhorseman.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <7edaeaf5-c2df-910a-cc8e-0528b4ac0950@cs.tcd.ie> Date: Mon, 30 Oct 2017 13:09:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <878tfwey8w.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T7V88bHMVaPRkmCPTo5IaTIhTqMcRp3aV" Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 13:09:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T7V88bHMVaPRkmCPTo5IaTIhTqMcRp3aV Content-Type: multipart/mixed; boundary="RI2SWk0Eghi0kVTj15hxovTVmQTJ9I6TA"; protected-headers="v1" From: Stephen Farrell To: Daniel Kahn Gillmor , dns-privacy@ietf.org Message-ID: <7edaeaf5-c2df-910a-cc8e-0528b4ac0950@cs.tcd.ie> Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement References: <878tfwey8w.fsf@fifthhorseman.net> In-Reply-To: <878tfwey8w.fsf@fifthhorseman.net> --RI2SWk0Eghi0kVTj15hxovTVmQTJ9I6TA Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 28/10/17 04:40, Daniel Kahn Gillmor wrote: >=20 > Furthermore, i believe that the proposal in draft-11 of making DNSSEC > validation of metaqueries a MUST for the opportunistic profile is > *actively harmful* to the stated goal of the opportunistic profile > (i.e., "maximum chance of DNS service"). I just re-read the draft. I agree that requiring DNSSEC validation of anything to succeed when using the opportunistic profile is a bad plan. Requiring an attempt at DNSSEC validation is fine, but given only a small percentage of the DNS is signed, and DPRIVE won't IMO drive that to a much bigger figure, (or at least not for a long time) it makes no sense to put such a barrier in the way of use of opportunistic security. Cheers, S. --RI2SWk0Eghi0kVTj15hxovTVmQTJ9I6TA-- --T7V88bHMVaPRkmCPTo5IaTIhTqMcRp3aV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ9ySTAAoJEC88hzaAX42iFDsH/1arrGBqkWvwwk6fz1n7xThU +Pm1HSp6t6ZYs8lIuqzo3vTKp0W/7r/QvKR/p6H4OB+95JS9pGs0uTq8Lgj1wjOd yC1y3GUv4l6RtoMFBh/hk+PdbWFbnXjcdzehOx8Y/z+1fkiL3qYRDfKvALL1kUeT 1X5Vtmwhg5OViiptBm2AS8XF+9cPEsPmGNt1N3yFvP2cEqb2yU/Zw/gwNB0qi3C2 S4kqEV2v4nwvpZvKYju5HmwvDdcnoZHWXh7OEUUrcGSr65JMIyvqLXXjkySAocUN 9j0dWUafBSa7sKc0v5a2hbsOhJ30RJAmMSrWgTEg/hMMBILPDsnXeLuuKj+Xum0= =evbA -----END PGP SIGNATURE----- --T7V88bHMVaPRkmCPTo5IaTIhTqMcRp3aV-- From nobody Mon Oct 30 06:11:55 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2699613AB12 for ; Mon, 30 Oct 2017 06:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 uDIaUf9fiYMf for ; Mon, 30 Oct 2017 06:11:47 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 CD1B413A214 for ; Mon, 30 Oct 2017 06:11:46 -0700 (PDT) Received: from [2001:b98:204:102:fffa::14b4] (port=49559) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1e99qy-0003a4-V6; Mon, 30 Oct 2017 13:11:45 +0000 From: Sara Dickinson Message-Id: <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F2440190-AEC9-4BEE-BEA3-5004E4FB6A92"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 30 Oct 2017 13:11:41 +0000 In-Reply-To: <878tfwey8w.fsf@fifthhorseman.net> Cc: dns-privacy@ietf.org To: Daniel Kahn Gillmor References: <878tfwey8w.fsf@fifthhorseman.net> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 3 Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 13:11:54 -0000 --Apple-Mail=_F2440190-AEC9-4BEE-BEA3-5004E4FB6A92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Oct 2017, at 04:40, Daniel Kahn Gillmor = wrote: >=20 > Hey DPRIVE folks-- >=20 > Apologies for the delay, and that this message is so long. I've tried > to reconstruct this discussion around > draft-ietf-dprive-dtls-and-tls-profiles-11 as best i can, and my > analysis follows. If i've misundertood or misanalyzed something, > please let me know. >=20 > Summary > ------- >=20 > I do not believe that DNSSEC validation is warranted as a mitigation > against an active attacker in the context of an opportunistic = metaquery, > regardless of whether the client ultimately intends to follow either = the > Strict or Opportunistic profile. >=20 > Furthermore, i believe that the proposal in draft-11 of making DNSSEC > validation of metaqueries a MUST for the opportunistic profile is > *actively harmful* to the stated goal of the opportunistic profile > (i.e., "maximum chance of DNS service=E2=80=9D). >=20 > I like the reorganization and re-wording of the "Usage Profiles" > section in draft-11, and think we should keep it. But i think the > other changes between draft-10 and draft-11 are unwarranted and should > be reverted. Hi dkg, Thanks for the feedback, I agree with the bulk of your analysis with the = exception of one part (see below). Therefore I=E2=80=99d argue not to = revert the changes to section 7.2 completely since I really do think a = description there of the trade-offs of DNSSEC validation are warranted = regardless of the final decision on the requirement, even if it ends up = just being a MAY (although I would like to see SHOULD as a minimum for = opportunistic). I can also recognise the implementation overhead, however this is = required for only one of the 3 cases of how the client may be = provisioned: * IP address only (no meta-query required) * IP address and ADN (no meta-query required) * ADN only (meta-query required) So it is for the case where a client was directly and securely = configured with just the ADN of a server it expects to provide privacy. = If a client doesn=E2=80=99t want to implement DNSSEC then it can always = restrict the opportunistic profile to requiring one of the first 2 = configurations. >=20 >=20 > Analysis > -------- >=20 > AIUI, the scenario under discussion is: >=20 > * A DNS client (following either the strict or the opportunistic > profile) > * using opportunistic meta-queries to find the desired DNS resolver > * in the face of an active attacker >=20 > We already know that an attacker capable of filtering the client's > *outbound* traffic can cause a denial of service (for clients = following > the strict profile) or loss of privacy (for clients following the > opportunistic profile, because they fall back to cleartext) simply by > dropping outbound connections to *anywhere* TCP port 853. >=20 > Likewise, We also know that an attacker capable of filtering the > client's *inbound* traffic can cause a denial of service (strict > clients) or loss of privacy (opportunistic clients) simply by dropping > inbound connections from any TCP port 853. >=20 > But the introduction of an opportunistically-secured meta-query > introduces a DoS attack (strict clients) or loss of privacy > (opportunistic clients) that can be achieved by a weaker attacker. > Since we're talking about an attacker that is *not* in control of the > network, the following analysis assumes that the the network provides > "legitimate" DHCP service, which is supposed to point the client to a > "legitimate" standard DNS resolver (which may or may not be > privacy-enabled, but is sufficient for answering an opportunistic > metaquery correctly). >=20 > In particular, the attacker needs only one of the following two > capabilities: >=20 > (a) Controlling the "legitimate" DHCP server, or detecting the > client's DHCP request and racing the "legitimate" DHCP server to > return a DHCP response (this allows the attacker to set the > resolver used by the client for its opportunistic metaquery), or >=20 > (b) Controlling the "legitimate" DNS resolver, or detecting the > client's opportunistic metaquery and racing the "legitimate" DNS > resolver to provide a malicious DNS response. >=20 > In either case, the result is that the attacker has poisoned the > client's meta-cache -- its best guess at the location of the desired > privacy-enabled DNS resolver. A poisoned meta-cache results in a DoS > for clients in "Strict" mode because the attacker's answering DNS > resolver at the learned address cannot authenticate. A poisoned > meta-cache results in a loss of privacy for clients in "Opportunistic" > mode because they will connect without authentication to the = attacker's > answering DNS resolver. >=20 > Have i got that right? >=20 > DNSSEC validation does not mitigate this attack. >=20 > Regardless of the profile, the client has four options when it > discovers that the response to the metadata query was forged (or at > any rate is not validatable). It can: >=20 > (0) ignore the response, resulting in a DoS regardless of profile, > or >=20 > (1) ignore the validation failure, and try connecting to the > proposed address anyway (resulting in a DoS for strict clients > because the server does not validate, or a loss of privacy for > opportunistic clients), or >=20 > (2) retry the metaquery (in the hopes that their attacker is in class > "b" and not in full control of the "legitimate" DNS resolver) and > maybe the legitimate DNS response will come in, or >=20 > (3) abort the network connection and retry DHCP (in the hopes that = the > attacker is in class "a" and not in full control of the > "legitimate" DHCP server) and maybe the legitimate DHCP response > will come in. >=20 > Choice 0 is the same outcome as the non-DNSSEC-validating scenario for > strict clients (no mitigation), Agreed - DNSSEC validation just provides earlier detection for Strict = clients > and *strictly worse* for opportunistic > clients, because it converts a loss of privacy to a DoS, which is in > direct opposition to the stated goal of the opportunistic profile. I=E2=80=99d disagree that connecting to a server for which the = meta-query response failed DNSSEC validation results in _just_ a loss of = privacy for Opportunistic in this case. If the answer was BOGUS then it = seems reasonable to assume the server is not legitimate and so = connecting also results in the clients' entire DNS service being = controlled by the attacker. Take the case where the DNS server from DHCP really is legitimate. The = fact that the meta-query answer _could_ be spoofed provides a vector for = an opportunistic client to be directed to an attackers' DNS server. Note = that this attack is not possible on a =E2=80=99normal=E2=80=99 client = that directly uses the DHCP provided server, the attacker has to attack = each individual query. My concern here is that without DNSSEC validation = of the re-direct Opportunistic clients have an additional risk of this = kind of attack than =E2=80=99normal=E2=80=99 ones. Also this is only a guaranteed DoS for the case where there is only a = single server configured. If there are multiple servers then the = attacker must spoof the meta-query answers for _all_ the servers to = achieve DoS. If it only spoofs one then the client can still get = service. So one way to look at the trade-off seems to be is it worse that an = attacker can block your DNS service or gets an extra chance to control = all your DNS answers? I think you are arguing that for opportunistic the = latter is preferable because a principle of Opportunistic is that it = shouldn=E2=80=99t fail? If the WG decided that to be the case then it = needs to be clear in the document this choice comes with an additional = risk (and yet still not guarantee of privacy). >=20 > Choice 1 is exactly the same outcome as the non-DNSSEC-validating > scenario for all clients. (no mitigation) >=20 > Choices 2 and 3 are interesting thought experiments, but are not > directly contemplated in the draft (and i think they would be a > distraction from the goal of the draft -- this draft is not "how to do > staged opportunistic fallback in the face of an arbitrarily corrupt > network"), so i won't go into them here. >=20 > At best, DNSSEC validation of the metaquery could be used to provide > additional reporting information to any client-internal > auditing/reporting or other defensive measures; but again, this draft > should not go into those in any detail. >=20 > Background > ---------- >=20 > To be clear about where this analysis is coming from, my rule of thumb > for these two profiles is: >=20 > * Strict >=20 > Do whatever you can to connect to the preferred privacy-enabled > resolver, but don't actually send queries unless you're sure you > have authenticated the server. >=20 > * Opportunistic >=20 > Do whatever you can to connect to the preferred privacy-enabled > resolver, but go ahead and send your queries to it anyway, even if > it cannot be authenticated. > Note that both modes can report (e.g., to a local system > auditor/monitor/policy-agent) any failures or errors they encounter. > But Strict mode will fail closed (DoS), and Opportunistic mode will > fail open (loss of privacy). >=20 > To be clear: the client is *locally configured* to be either in Strict > or Opportunistic mode. Orthogonally, it is also locally configured = with > some server authentication information. >=20 > If its locally-configured server authentication information is of the > form "ADN" only, then -- even when configured in Strict mode -- it > will do an Opportunistic DNS resolution of the address of the desired > resolver. This is the "opportunistic meta-query". >=20 >=20 >=20 > So i guess i'm still DISCUSSing ekr's DISCUSS, which is an unfortunate > state for the draft to be in. :( Technically his DISCUSS was on a different topic (SPKI handling) as = Stephane pointed out, this was an issue that came out of a separate = comment he made. Sara. --Apple-Mail=_F2440190-AEC9-4BEE-BEA3-5004E4FB6A92 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ9yUOAAoJEJrQ44WBAj4V/cEQAJlg4+xCg11GLpCeFCiYTeKo I+p+uL+xYiJ1eY571274Vvk6s/u8dCJGCxBzDaZo2wQ00cxE5UN0+mGmNtkUFOWD 3qwfBysOIEDWKEH4acxDqBIz04Y3k/8T0HBNi/k1q3TbJRD9tKT+ki5MBej5ruF1 0qtOhOsokw8M20GD7obTVnND6VVgYoj0ZSoK4+NMLIacfXmYyZ6ehik3O75S+Sjm Hnx9x1rGU34qfTy5IrnKUJ76T+oFEZf/YtlUp4tBkLgclvtCpjtg0zca+t12iDZf JazxVkKpvzstP3+eykB4P9RrWSxqbOKs8nE+vFZk8RvXQ/tMtBzOHLIAoAfZUBod ldWpWk2m62bmLyrSrHFTU1X201zPyUD97WL1u801MJkjBgnkE7dUNNCKSov1vb5U dZP9EJloNmXvbnDw3OwPaSnZaDh77iT56d//ryV6UVOsiozFROl/EI+Z4Hv59In1 hvnkGuXaR+dhOP3es8SKOka26sc5kGd8p/XC48y7c5UHK0qYDPxMr5mfgvPPhraX yX3mOVhPZ3wSszR843hysMm4SJZeg+dcyPHlBZEJ5P0WxPsxqshbMRtxbZFoasPX Ok50Nyk8xqpVNx88g7ij9NgqwqIleiltDqM0mpVwVj+rVRkBGrYzYmdK/ygokvWU NRaZLy5VVvpw7S6/Lcq/ =pENw -----END PGP SIGNATURE----- --Apple-Mail=_F2440190-AEC9-4BEE-BEA3-5004E4FB6A92-- From nobody Mon Oct 30 06:34:16 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A6A13F4FB for ; Mon, 30 Oct 2017 06:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=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 wdSso__Zi84e for ; Mon, 30 Oct 2017 06:34:06 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 4B22B13F89F for ; Mon, 30 Oct 2017 06:34:06 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C6A6A280E82; Mon, 30 Oct 2017 14:34:03 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id C1031280E87; Mon, 30 Oct 2017 14:34:03 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id BA930280E82; Mon, 30 Oct 2017 14:34:03 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id B79F76420F63; Mon, 30 Oct 2017 14:34:03 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id B422C409E4; Mon, 30 Oct 2017 14:34:03 +0100 (CET) Date: Mon, 30 Oct 2017 14:34:03 +0100 From: Stephane Bortzmeyer To: Daniel Kahn Gillmor Cc: dns-privacy@ietf.org Message-ID: <20171030133403.2yyw4m4ldjdcyl7f@nic.fr> References: <878tfwey8w.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878tfwey8w.fsf@fifthhorseman.net> X-Operating-System: Debian GNU/Linux 9.1 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.051231, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.10.30.133016 Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 13:34:15 -0000 On Fri, Oct 27, 2017 at 11:40:15PM -0400, Daniel Kahn Gillmor wrote a message of 219 lines which said: > I do not believe that DNSSEC validation is warranted as a mitigation > against an active attacker in the context of an opportunistic > metaquery, I see the point but it seems to me a small detail in a 29-pages document. So, IMHO, it should not cause yet another long delay for a draft that already lingered too much. > But i think the other changes between draft-10 and draft-11 are > unwarranted and should be reverted. There are very few changes and, except the DNSSEC *requirment*, they seem good to me. I agree with Sara "I really do think a description there of the trade-offs of DNSSEC validation are warranted". From nobody Mon Oct 30 07:46:51 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6E413FA1A for ; Mon, 30 Oct 2017 07:46:49 -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 N39sVVbYRdyZ for ; Mon, 30 Oct 2017 07:46:48 -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 E95A913FA15 for ; Mon, 30 Oct 2017 07:46:46 -0700 (PDT) Received: from [169.254.173.149] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v9UEjMf2062940 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Oct 2017 07:45:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.173.149] From: "Paul Hoffman" To: "Sara Dickinson" Cc: dns-privacy@ietf.org Date: Mon, 30 Oct 2017 07:46:43 -0700 Message-ID: <9D3816E2-AE0D-4803-BBE8-FA98A196D376@vpnc.org> In-Reply-To: <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 14:46:49 -0000 On 30 Oct 2017, at 6:11, Sara Dickinson wrote: > I’d disagree that connecting to a server for which the meta-query > response failed DNSSEC validation results in _just_ a loss of privacy > for Opportunistic in this case. If the answer was BOGUS then it seems > reasonable to assume the server is not legitimate and so connecting > also results in the clients' entire DNS service being controlled by > the attacker. There are many ways to get a BOGUS response that have nothing to do with the information being "not legitimate". Typically today, BOGUS comes from misconfigured servers such as expired keys, some nameservers out of sync, and so on. You cannot infer from a BOGUS response about why it is bogus. > Take the case where the DNS server from DHCP really is legitimate. The > fact that the meta-query answer _could_ be spoofed provides a vector > for an opportunistic client to be directed to an attackers' DNS > server. Note that this attack is not possible on a ’normal’ client > that directly uses the DHCP provided server, the attacker has to > attack each individual query. My concern here is that without DNSSEC > validation of the re-direct Opportunistic clients have an additional > risk of this kind of attack than ’normal’ ones. Spoofing in normal DHCP and spoofing without DNSSEC seem equivalent to me. > Also this is only a guaranteed DoS for the case where there is only a > single server configured. If there are multiple servers then the > attacker must spoof the meta-query answers for _all_ the servers to > achieve DoS. If it only spoofs one then the client can still get > service. ...unless the attacker can spoof the (typically) two servers that the client has addresses to. > So one way to look at the trade-off seems to be is it worse that an > attacker can block your DNS service or gets an extra chance to control > all your DNS answers? I think you are arguing that for opportunistic > the latter is preferable because a principle of Opportunistic is that > it shouldn’t fail? If the WG decided that to be the case then it > needs to be clear in the document this choice comes with an additional > risk (and yet still not guarantee of privacy). It is only an "additional risk" for a very limited attacker who can only attack one of a set of addresses. If the WG wants to go down the path of making Opportunistic encryption even more difficult in order to feel that we offered the best security, requiring DNSSEC on the client is a good way to do that. I would still prefer more ubiquitous encryption. --Paul Hoffman From nobody Mon Oct 30 08:16:12 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03C413F3F4 for ; Mon, 30 Oct 2017 08:16:10 -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 SzxB3dZE_1Yl for ; Mon, 30 Oct 2017 08:16:08 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7270A13FA40 for ; Mon, 30 Oct 2017 08:15:15 -0700 (PDT) Received: from fifthhorseman.net (p578E653F.dip0.t-ipconnect.de [87.142.101.63]) by che.mayfirst.org (Postfix) with ESMTPSA id 2AD37F99A; Mon, 30 Oct 2017 11:15:14 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 242E22063B; Mon, 30 Oct 2017 16:08:39 +0100 (CET) From: Daniel Kahn Gillmor To: Sara Dickinson Cc: dns-privacy@ietf.org In-Reply-To: <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> Date: Mon, 30 Oct 2017 16:08:35 +0100 Message-ID: <871slkd66k.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 15:16:11 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote: > I really do think a description there of the trade-offs of DNSSEC > validation are warranted I agree that a discussion of the tradeoffs involved in DNSSEC validation of the opportunistic meta-query is warranted. I just come to a different conclusion than the requirements in draft-11. > if it ends up just being a MAY (although I would like to see SHOULD as > a minimum for opportunistic). SHOULD validate, but with what failure mode? are we really saying that opportunistic SHOULD deliver a DoS instead of a loss of privacy? I discuss a few optional responses for failures in opportunistic mode below. > I can also recognise the implementation overhead, however this is > required for only one of the 3 cases of how the client may be > provisioned: > > * IP address only (no meta-query required) > > * IP address and ADN (no meta-query required) > > * ADN only (meta-query required) > > So it is for the case where a client was directly and securely > configured with just the ADN of a server it expects to provide > privacy. If a client doesn=E2=80=99t want to implement DNSSEC then it can > always restrict the opportunistic profile to requiring one of the > first 2 configurations. The cheapest and simplest implementation in terms of user experience to get to verifiable opportunistic profile (that is, a profile that can at least report that DNS privacy has been achieved, even if it won't be enforced) seems to be: * allow the local administrator to provide a name for the preferred DNS resolver Since it's opportunistic, it can even be enabled by default. But this is the "ADN only" use case. Saying it's not usable with the opportunistic profile without DNSSEC validation would be a shame. >> Choice 0 is the same outcome as the non-DNSSEC-validating scenario for >> strict clients (no mitigation), > > Agreed - DNSSEC validation just provides earlier detection for Strict cli= ents or, converts success to failure in the case of DNSSEC misconfiguration (because the connection would otherwise have succeeded) :( > I=E2=80=99d disagree that connecting to a server for which the meta-query > response failed DNSSEC validation results in _just_ a loss of privacy > for Opportunistic in this case. If the answer was BOGUS then it seems > reasonable to assume the server is not legitimate and so connecting > also results in the clients' entire DNS service being controlled by > the attacker. sure, but this is the case for non-private DNS as well, right? So the mitigation in this case is with respect to the features that "private DNS" is supposed to offer. Whatever those features are, they are absent given an attacker-controlled DNS resolver. So if the DNS-over-TLS server is intended to also provide integrity protection, yes, that would also be lost. I think we're agreeing here, right? I apologize if "loss of privacy" is a misleading shorthand. > Take the case where the DNS server from DHCP really is legitimate. The > fact that the meta-query answer _could_ be spoofed provides a vector > for an opportunistic client to be directed to an attackers' DNS > server. Note that this attack is not possible on a =E2=80=99normal=E2=80= =99 client > that directly uses the DHCP provided server, the attacker has to > attack each individual query. My concern here is that without DNSSEC > validation of the re-direct Opportunistic clients have an additional > risk of this kind of attack than =E2=80=99normal=E2=80=99 ones. ok, i think i understand. The concern is that a non-network-controlling attacker who can spoof DNS responses but can't spoof DHCP responses can now take over full DNS resolution of opportunistic clients just by racing (and winning) the legitimate metaquery response. This is true, but the threat model we're worrying now include all of the following characteristics: * attacker does not control the client's network (otherwise, they could redirect the port 853 queries anyway) =20 * attacker cannot (or has failed to) race the client's DHCP connection (otherwise, they'd point to a different DNS server anyway) * attacker *can* race the legitimate response to the client's opportunistic metaquery. * client is in opportunistic mode. So the question is, in this particular corner case, what is the right mitigation to the scenario where "if DNSSEC validation of the opportunistic metaquery fails=E2=80=A6" ? if the answer is "=E2=80=A6proceed as though it had not failed (trying to connect to the preferred server's proposed address), but continue listening for another response to the metaquery; prefer subsequent metaquery responses that do have DNSSEC validation over those responses that are not DNSSEC validated." Then i'd be ok with it, but it's not specified in the draft. If the answer is "=E2=80=A6hard-fail and deny DNS service", then i think th= at's incorrect given the goals of opportunistic mode. If the answer is "=E2=80=A6stop trying to use opportunistic DNS privacy entirely, but fall back to using the DHCP-provided resolver for all queries" then i think that's a mistake -- we've already demonstrated that we're in a scenario where the attacker can race the DHCP-provided resolver and win. So what do we gain by making this the failure mode? > Also this is only a guaranteed DoS for the case where there is only a > single server configured. If there are multiple servers then the > attacker must spoof the meta-query answers for _all_ the servers to > achieve DoS. If it only spoofs one then the client can still get > service. I think this equivalent to my responses-to-failed-validation #2 -- retrying the opportunistic metaquery. (also, equivalent to "=E2=80=A6but continue listening=E2=80=A6" in the paragraphs above.) I agree that's an interesting case, but i think it's an additional complexity as yet unspecified in the draft. :( > So one way to look at the trade-off seems to be is it worse that an > attacker can block your DNS service or gets an extra chance to control > all your DNS answers? I think you are arguing that for opportunistic > the latter is preferable because a principle of Opportunistic is that > it shouldn=E2=80=99t fail? If the WG decided that to be the case then it = needs > to be clear in the document this choice comes with an additional risk > (and yet still not guarantee of privacy). it is "an extra chance only" in the scenario where points outlined above hold. An attacker who can also race and beat the DHCP server has the exact same chance already, right? > Technically his DISCUSS was on a different topic (SPKI handling) as > Stephane pointed out, this was an issue that came out of a separate > comment he made. Hm, sorry, i'll try to follow up on that in the other sub-thread. Thanks for the discussion. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAln3QHQACgkQFJitxsGS Mjcuqg/9GPVhnKDIhknT8y1LaGSwHWl9zXp0K9iqsOd57fKmzSlD53N2e3PZ+XjV uhCFrnEcDEujrZisjXReoGNun2ESNIAZEEE0x1WRqpPg7RUHfemNI8+iALp8Tr5S Pv87la2Z00dlXdjsPYLtA4WCkO2B/CBCwf9Hwe4VZZZE9L+Uhp/hOrxV7aUzRebg feE2MvTwxCeRXLnd/WH7N8ahqKuhaq17dSnGzPYHysMuKt6gpgguxRy6kdcJw3M3 7ynfUm5WK706h5Yafexgnjny+5m2dMRMplScHK9rBi2SCvHUAPKXZoXYX6wfw0Mo /0FANxjkyxd/KL/ObLaiH/apyHJGuQZeOl46YeLdBWedCjdrpY+scECw+6EVwADm HBv+S/gS7pzPaH7EfqnVxgiY+Ssy6r/NGfvgUDjaeTBGayRfXnuHfqqXRCaC+L4M jlhNVssv1wJLqtOw554eAxPJuABMSwAQzqbWl7gbXMYoFmrDRf5GTwm6raSh2SL0 lf32KjJvZekP6z5ttnOWkL0yUO5cXAx8fDJS49JhUpCoW7IN+UOympZouIzeJki1 AnKm90EBv17U97sMXQR3PG5ttG5AhycGCPN+03huiRCOaF1f427xXwv8ebVv9GFL nx0VvryMH/ffYzmf1rtrUUPU6a7JUvuInBrxVM542uIHY03BioU= =YM8e -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 30 08:33:40 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800D61B0002 for ; Mon, 30 Oct 2017 08:33:37 -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 b7XwW0nt5QHx for ; Mon, 30 Oct 2017 08:33:35 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id E75601FE009 for ; Mon, 30 Oct 2017 08:27:26 -0700 (PDT) Received: from fifthhorseman.net (p578E653F.dip0.t-ipconnect.de [87.142.101.63]) by che.mayfirst.org (Postfix) with ESMTPSA id 5FC9EF99A; Mon, 30 Oct 2017 11:27:26 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B58C42063B; Mon, 30 Oct 2017 16:27:19 +0100 (CET) From: Daniel Kahn Gillmor To: Stephane Bortzmeyer , dns-privacy@ietf.org In-Reply-To: <20171027125510.foq7xeiqft2vl7rx@nic.fr> References: <20171027125510.foq7xeiqft2vl7rx@nic.fr> Date: Mon, 30 Oct 2017 16:27:16 +0100 Message-ID: <87y3nsbqqz.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked? X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 15:33:37 -0000 --=-=-= Content-Type: text/plain On Fri 2017-10-27 15:55:10 +0200, Stephane Bortzmeyer wrote: > The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles > has a DISCUSS "This needs to be updated to indicate that the client > MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise > you're going to have interop problems." I agree that this DISCUSS should be cleared, since draft-10 and draft-11 both state: A client MUST only indicate support for raw public keys if it has an SPKI pinset pre-configured (for interoperability reasons). Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAln3RNQACgkQFJitxsGS MjfsVA/9ENvH3oCg8RCtOBQhTiJzjU/Stub0S9NU8FNTKmGfi9yHzOdIp12IljI/ n8x/8XzTl7V6+QHpByusbXHv6MaX1YcpcLAORu5errghec/nHe7dgl7F0unY/GWN kCyLWScGncwEoRPhiloqw6i8mO4QzkD31gYUpFXjGtAqVYb+8tPpVSKrmwBA1T5y wlFcnOnsyf1hUcpd+g/LTufPkI08F9sGlL9qQsDt9WHgTErYjSy9KYRNiC66MaSr XMoQUHBtTUHyaLDReYLfpFunUmh7XKXwf34rXoPbbaXlIDW8BCIq2sLxSSkoc8Op oKRjeO7TCA/UwaQ6yPlxdG7ADb58ByKsVxPzb5WE78IZiSU2HFR2qVtQuBlzwB/r dNODM3l2RM4ayRgwuo4FRtZK3H5LHw7rfA/hKQmwASzTRKiClR6YAnMsjf8c9n5Z S4zHDsy6iX2POvaeApOLILSgrefqDfstObJSM6Mdz1wjStMCDelMcMDdDaGQPkEN ZklVdoxs5KDrucQmBFs8ap73EpAVatmd5BNhFl+Iulvyyy2FdLj+V0YMwsYG9ESN rffjzh1OkTxLhAfJpHHX294WRfJFBJ/2glAtzkeO2fKJ0+9Fazf72j3zmbKDyaIY DcU/NZpw8MeMJo3T39C58j4aOIb7wE5nWO1K+X7aq1UHP+Rsd+4= =9iX1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 30 08:51:35 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460E54A2B for ; Mon, 30 Oct 2017 08:51:33 -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 MMP6TO7oNExS for ; Mon, 30 Oct 2017 08:51:32 -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 3D1714A99 for ; Mon, 30 Oct 2017 08:42:22 -0700 (PDT) Received: from [169.254.173.149] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v9UFeu1K070219 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Oct 2017 08:40:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.173.149] From: "Paul Hoffman" To: "Daniel Kahn Gillmor" Cc: dns-privacy@ietf.org Date: Mon, 30 Oct 2017 08:42:18 -0700 Message-ID: <1B2537D5-DFD7-407A-A84E-925C85EF9268@vpnc.org> In-Reply-To: <871slkd66k.fsf@fifthhorseman.net> References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> <871slkd66k.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 15:51:33 -0000 On 30 Oct 2017, at 8:08, Daniel Kahn Gillmor wrote: > On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote: >> if it ends up just being a MAY (although I would like to see SHOULD >> as >> a minimum for opportunistic). > > SHOULD validate, but with what failure mode? +1 to the question: we're talking about Opportunistic mode here. > are we really saying that > opportunistic SHOULD deliver a DoS instead of a loss of privacy? Some of us are most emphatically not saying that. . . . > sure, but this is the case for non-private DNS as well, right? So the > mitigation in this case is with respect to the features that "private > DNS" is supposed to offer. Whatever those features are, they are > absent > given an attacker-controlled DNS resolver. So if the DNS-over-TLS > server is intended to also provide integrity protection, yes, that > would > also be lost. I think we're agreeing here, right? I apologize if > "loss > of privacy" is a misleading shorthand. > >> Take the case where the DNS server from DHCP really is legitimate. >> The >> fact that the meta-query answer _could_ be spoofed provides a vector >> for an opportunistic client to be directed to an attackers' DNS >> server. Note that this attack is not possible on a ’normal’ >> client >> that directly uses the DHCP provided server, the attacker has to >> attack each individual query. My concern here is that without DNSSEC >> validation of the re-direct Opportunistic clients have an additional >> risk of this kind of attack than ’normal’ ones. > > ok, i think i understand. The concern is that a > non-network-controlling > attacker who can spoof DNS responses but can't spoof DHCP responses > can > now take over full DNS resolution of opportunistic clients just by > racing (and winning) the legitimate metaquery response. > > This is true, but the threat model we're worrying now include all of > the > following characteristics: > > * attacker does not control the client's network (otherwise, they > could > redirect the port 853 queries anyway) > > * attacker cannot (or has failed to) race the client's DHCP > connection > (otherwise, they'd point to a different DNS server anyway) > > * attacker *can* race the legitimate response to the client's > opportunistic metaquery. > > * client is in opportunistic mode. > > So the question is, in this particular corner case, what is the right > mitigation to the scenario where "if DNSSEC validation of the > opportunistic metaquery fails…" ? > > if the answer is "…proceed as though it had not failed (trying to > connect to the preferred server's proposed address), but continue > listening for another response to the metaquery; prefer subsequent > metaquery responses that do have DNSSEC validation over those > responses > that are not DNSSEC validated." Then i'd be ok with it, but it's not > specified in the draft. > > If the answer is "…hard-fail and deny DNS service", then i think > that's > incorrect given the goals of opportunistic mode. Agree. And fully agree that an attacker who can do the third bullet *but not the second* is a very obscure corner case. Having this document say, in essence, "you don't get opportunistic encryption unless you add a DNSSEC validation stack" feels like a regression to the original goals of this WG. --Paul Hoffman From nobody Mon Oct 30 09:10:55 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695B76644 for ; Mon, 30 Oct 2017 09:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, 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 YeMibDgLCoYq for ; Mon, 30 Oct 2017 09:10:50 -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 9DFD04E09 for ; Mon, 30 Oct 2017 08:59:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4BACEBE4C; Mon, 30 Oct 2017 15:59:24 +0000 (GMT) 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 VYcsF48aUrVx; Mon, 30 Oct 2017 15:59:23 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D17F5BE47; Mon, 30 Oct 2017 15:59:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1509379163; bh=AkoxNt8LZ7502M+yHM6LkKHkgh4RXFNaX4VIG+P5uzQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=xMhwUdvKI02gSZ8FbUCiQWcWQpSSCB2CLygF48Km9KjlPAamAaqJMI0OEy9dsJ9jS 7Nho0hPT4p0UD859K8ftyJnIpZwZjFPZZNchKN5Yg2GdMEZEn7BkIpdnY9KDfumvFm 3m9ScAsIdyFbGoVC3tXLi0qovv+u6Y4cify9Co1s= To: Paul Hoffman , Daniel Kahn Gillmor Cc: dns-privacy@ietf.org References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> <871slkd66k.fsf@fifthhorseman.net> <1B2537D5-DFD7-407A-A84E-925C85EF9268@vpnc.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 30 Oct 2017 15:59:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1B2537D5-DFD7-407A-A84E-925C85EF9268@vpnc.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1kJlNxjM4EchkoFWefegtM4pkf2X9kRW0" Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:10:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1kJlNxjM4EchkoFWefegtM4pkf2X9kRW0 Content-Type: multipart/mixed; boundary="T5iWjus6eeAoG3I6i2UWGJCKjaUaVov0Q"; protected-headers="v1" From: Stephen Farrell To: Paul Hoffman , Daniel Kahn Gillmor Cc: dns-privacy@ietf.org Message-ID: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> <871slkd66k.fsf@fifthhorseman.net> <1B2537D5-DFD7-407A-A84E-925C85EF9268@vpnc.org> In-Reply-To: <1B2537D5-DFD7-407A-A84E-925C85EF9268@vpnc.org> --T5iWjus6eeAoG3I6i2UWGJCKjaUaVov0Q Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 30/10/17 15:42, Paul Hoffman wrote: > Having this document say, in essence, "you don't get opportunistic > encryption unless you add a DNSSEC validation stack" feels like a > regression to the original goals of this WG. I'm not sure that having a stack is such a barrier in reality. Requiring that some DNSSEC signatures validate in order to win the opportunistic game is the problem I think. I'd personally be fine with a "MUST try DNSSEC" statement, though that could be argued to be OTT, given the probability of success, but as DKG and you (and I) agree, it's the failure mode that needs fixing in the draft. S. --T5iWjus6eeAoG3I6i2UWGJCKjaUaVov0Q-- --1kJlNxjM4EchkoFWefegtM4pkf2X9kRW0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ90xZAAoJEC88hzaAX42i8lsH/ilU4RjPvXVOieY+4rga3NJy IhC+0bRTvHPzr2Sv94req65WVqXGE6mBiA7SFPVrENiOrety1AOgJkpFA1nXKdOD dqnB7UmNRV8QiA0Vtpf1psqvAIjjXSCGmzwTQxO2KKkej0axCQWA2vBy1oQKEKOY 8UtYH+ICVJMA/5U2SlIsmju8Xg1YSq1V5ZuTqNvrlu2JepOx0bFYzk2i4CFjRVLh NPqf5RE/Dabj0L/Kw3oFP5IpZaHqzlQmv/ZsPm6v6ZoNoCeYdB7s2pretYO+3dRn b46ccNOLUw52KDU41jNSRXCQdVyWM9r1GLLKPmWKJn9cP/K23Jv0yraiXKxzmpI= =4HRm -----END PGP SIGNATURE----- --1kJlNxjM4EchkoFWefegtM4pkf2X9kRW0-- From nobody Mon Oct 30 09:22:52 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF115F7B for ; Mon, 30 Oct 2017 09:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 hxACCOMMdjcZ for ; Mon, 30 Oct 2017 09:22:49 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 AA5085F7C for ; Mon, 30 Oct 2017 09:12:01 -0700 (PDT) Received: from [62.232.251.194] (port=5444 helo=[192.168.12.23]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1e9CfQ-0000Wm-7Q; Mon, 30 Oct 2017 16:12:00 +0000 From: Sara Dickinson Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5B71FBBA-D2E2-4177-BD0E-80C4ED8D6C97"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 30 Oct 2017 16:11:57 +0000 In-Reply-To: <871slkd66k.fsf@fifthhorseman.net> Cc: dns-privacy@ietf.org To: Daniel Kahn Gillmor References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> <871slkd66k.fsf@fifthhorseman.net> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 3 Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:22:52 -0000 --Apple-Mail=_5B71FBBA-D2E2-4177-BD0E-80C4ED8D6C97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30 Oct 2017, at 15:08, Daniel Kahn Gillmor = wrote: >=20 > On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote: >> I really do think a description there of the trade-offs of DNSSEC >> validation are warranted >=20 > I agree that a discussion of the tradeoffs involved in DNSSEC = validation > of the opportunistic meta-query is warranted. I just come to a > different conclusion than the requirements in draft-11. >=20 >> if it ends up just being a MAY (although I would like to see SHOULD = as >> a minimum for opportunistic). >=20 > SHOULD validate, but with what failure mode? are we really saying = that > opportunistic SHOULD deliver a DoS instead of a loss of privacy? I > discuss a few optional responses for failures in opportunistic mode > below. Can we separate out Opportunistic Privacy from Opportunistic DNSSEC = (which I don=E2=80=99t think is really a thing, apart from a logging = mechanism)? They are orthogonal. Because if not=E2=80=A6. are you saying that a fully validating stub = using Opportunistic privacy mode shouldn=E2=80=99t DNSSEC validation = anything, ever? Or it can validate all answers except the one for it=E2=80= =99s DNS resolver? :-) >=20 >>> Choice 0 is the same outcome as the non-DNSSEC-validating scenario = for >>> strict clients (no mitigation), >>=20 >> Agreed - DNSSEC validation just provides earlier detection for Strict = clients >=20 > or, converts success to failure in the case of DNSSEC misconfiguration > (because the connection would otherwise have succeeded) :( Ok, but =E2=80=A6 If the DNSSEC is misconfigured for a privacy server = then DANE authentication won=E2=80=99t work either=E2=80=A6 >=20 >> So one way to look at the trade-off seems to be is it worse that an >> attacker can block your DNS service or gets an extra chance to = control >> all your DNS answers? I think you are arguing that for opportunistic >> the latter is preferable because a principle of Opportunistic is that >> it shouldn=E2=80=99t fail? If the WG decided that to be the case then = it needs >> to be clear in the document this choice comes with an additional risk >> (and yet still not guarantee of privacy). >=20 > it is "an extra chance only" in the scenario where points outlined = above > hold. An attacker who can also race and beat the DHCP server has the > exact same chance already, right? I don=E2=80=99t buy the =E2=80=98if DHCP is already vulnerable we = shouldn=E2=80=99t worry about securing the meta-query=E2=80=99 argument. = I'd like to think we are designing Opportunistic such that the = meta-query is at least as secure as whatever mechanism is or might be = used in future to obtain the default DNS server so that opportunistic is = no weaker than =E2=80=99no privacy=E2=80=99. I hear the case that requiring DNSSEC validation could block deployment = for the specific case of ADN only + Opportunistic. So ti sounds like it = boils down to two alternatives in section 7.2: =E2=80=9C Such records SHOULD be validated when using Opportunistic = Privacy.=E2=80=9D =E2=80=9C Such records MAY be validated when using Opportunistic = Privacy.=E2=80=9D I=E2=80=99d obviously favour SHOULD. Sara --Apple-Mail=_5B71FBBA-D2E2-4177-BD0E-80C4ED8D6C97 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ909NAAoJEJrQ44WBAj4VM8wP/0W+ynM1/t5sBtk7LwoWTo7G LefqCoGEEQAEhBrMnjwIltrQPQuaI000UEbBjM6vCuPQ9LL3F3VAZK3CuxZE3NX1 O/GWutCN1k7PpkKpM6c3YkqjHJMRfo7iF/UDBrF0hl486dC2UprqX07UZcrCE0aj aBzv+u9SNsknpBjTF1deki+oepn0OCCArgY5dINFTU9HEqC+h1fAjGmdy3j8NE0m SNG/pJXFKBaEvyvlwb1OgVKDcQDqRLBFTPdzOvgnWSnFPqo81NNy8FQSlNp6bMoz LUlx/wU6ehekV5pH5eP5VNyZj6Z2Fdv/jWzzJUyt0Cq/fpFzTuwJRv9z7fKqxvki EwwgPedob6sLUtXUuv+hd9ur/EW/dOBlhJXQv9EzDpdVqxSTLcqbCgcn1PXrGfwz Xg91h+An033/DkH/deEhAaaiajt4y9jVmieodrJwt2X7lsbgYdhSnnXqJeOI9n0F NzAP90yBu3HgLSVWDbcVkIa57sAxfTFBslQ8wyIZym/INcPUGGXv7P3IiPeAH63y NE6sAvH5yS7LRAqXdMgof0B2OoSgmcgMWO7ro0JORXlbxT+qGztBWV4qOKzRujpc 8OxuIRQW8K35RR7RWmYwabWzJbDhtQVuDSgLF/pk9bwHzVc4MEc/HNVnHli8+/0T DAcdvBsFKHI+bVTnGjO6 =FW1A -----END PGP SIGNATURE----- --Apple-Mail=_5B71FBBA-D2E2-4177-BD0E-80C4ED8D6C97-- From nobody Mon Oct 30 09:24:18 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84B61DA583 for ; Mon, 30 Oct 2017 09:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.924 X-Spam-Level: X-Spam-Status: No, score=-3.924 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 CtGE-vIKBcKd for ; Mon, 30 Oct 2017 09:24:10 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-oln040092068078.outbound.protection.outlook.com [40.92.68.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3129913FE80 for ; Mon, 30 Oct 2017 09:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sUVxa2TbZqan1tdKmf6/lBDsppVMiHdRrVi0/aJSYEw=; b=CnpbCXIdNde3yIFQkHDJ8FmqH2tasL391IwdjJI+Ihs9ft2cTB7fIR72g7ncbUdxZ/77E3Ha4W0ddK5PNo4w5epTQ+OFVBbWHV15/VEgzY1PCVp8jD+zAIbe2MF/u+pydozZP/nA7MHVvW/dt0EUPOdinCkQrB9YoWvHfdZ5Ag6qD7qlXDvMSHBbx3802Vf/aSK0XqOvNftXDOPpIproK7EbpKOLg2T9qlOWdGSxkhUIWVKaNj43p1EmZeRg+uZHVkk7yLD6M2a+TikzdyoFUe0uRVoameNvBjqkur9ln9DaBJGbjC8GzcYLGmosVZl0ceRa8gP5g5SQtdr2qGOuVA== Received: from AM5EUR02FT053.eop-EUR02.prod.protection.outlook.com (10.152.8.51) by AM5EUR02HT203.eop-EUR02.prod.protection.outlook.com (10.152.9.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.178.5; Mon, 30 Oct 2017 16:13:32 +0000 Received: from AM5PR0401MB2627.eurprd04.prod.outlook.com (10.152.8.59) by AM5EUR02FT053.mail.protection.outlook.com (10.152.9.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.178.5 via Frontend Transport; Mon, 30 Oct 2017 16:13:27 +0000 Received: from AM5PR0401MB2627.eurprd04.prod.outlook.com ([fe80::4079:74d1:d1c2:62b4]) by AM5PR0401MB2627.eurprd04.prod.outlook.com ([fe80::4079:74d1:d1c2:62b4%17]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 16:13:26 +0000 From: Antoine Germanos To: "dns-privacy@ietf.org" , "dns-privacy@ietf.org" Thread-Topic: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Thread-Index: AQHTUZoEU0FdwrcpvU+0vMRD8u03Hg== Date: Mon, 30 Oct 2017 16:13:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:D4272071531C40EA58179D62D628CDF190508B434A752A0424E5253F397C3730; UpperCasedChecksum:EDBA00652B4C52CA14C912650BEB610C5B74F132D2F71A23474C52C24FEF1F51; SizeAsReceived:7204; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [QdhatbXGE0EOYz4Wt4d0KEsDG/cTxzIo] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5EUR02HT203; 6:59kv+zMGwM7hEPt26F5SHonY5gWcJM4ofkwLrpO8or8G4/ZrKwPQ+vkWrlyXDNUMTa67zf579AV1Jlvuhlw+QKGnp5oG/kyROYsxXsz73/e9CUphVcCh/dqae6bBRjDuGO22zoQJwIygJiQmFf1iJlEYnpFMMk1iaODQvxxkLo4p0qr0s89vbKl2qhJ3aBp0V/9cqmyjaVgKCAuUJZITU/b8Yt2nfZstNaYtDJySAq2NrPpPwMq89iUNclACAQkL8+Cx7DNFNo0SjC0s5UtGk+5COQqVGZl0Hr6Oy9U7DZCh9xl53rEC4y7h1r8gxS5XZIf2foJH5W2nsNoTiyV8olDTrynVxYtpscUEaU0Me04=; 5:0Fn+1WC8zH2lmpPs44ZcfKJBcWaGdNcNdbjJQtE5NRi7TdGDoYvktmFEP+XZVo71VFmGR0jtzO1x0aciXB8WYUTDJqPrH02lO+eb7nz1OWvEEMt5jMH0yks0jXzwHkOvfj2aYLLZ1pM0L1ywHhs4mTKrEOn4HJQ3qkfI43h2e+0=; 24:XlTX4ZC4OrZJKZP4VnFiiYSE+fF4K7shDu5swiJ32B9Ouo13GEr5ZxjhhZnB7ZPTC4p+6i4Wq2KiOcvyfiyWXmBqT6VIPE4/JBPCDqRgSM8=; 7:jKZXoUWkNPwJTvxcRgCBILlNfUjyy5CxkgNjlf2fdy0YAjp6P0B2yRwZwPHMnFLprArUvefSyEuFUsRTK9H2usyVayAEioeU8lbQtuOnFTFO2pb51I1RT4rDxO9iYb5IhoH6G2EtMfTkEmFZblb15D/K9FBsXV+iEgbpZo3R5uUn+1g0L4Zv+vUPUzLf0JXpjMCIqhn10P9bAD3wPCZSuDDW0gPskZpovVxqka/u7h9dwKBHaLTSKTr3fA3qFPS0 x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 742cb7b9-1bc6-4fe1-92b1-08d51fb1272d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:AM5EUR02HT203; x-ms-traffictypediagnostic: AM5EUR02HT203: x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(192374486261705)(81439100147899)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:AM5EUR02HT203; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5EUR02HT203; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:AM5EUR02HT203; H:AM5PR0401MB2627.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0401MB2627AD2E6D8E45CB514F1DC399590AM5PR0401MB2627_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 742cb7b9-1bc6-4fe1-92b1-08d51fb1272d X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 16:13:26.9295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR02HT203 Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:24:17 -0000 --_000_AM5PR0401MB2627AD2E6D8E45CB514F1DC399590AM5PR0401MB2627_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Antoine Germanos=99 ________________________________ From: dns-privacy on behalf of dns-privacy-r= equest@ietf.org Sent: Monday, October 30, 2017 6:10:54 PM To: dns-privacy@ietf.org Subject: dns-privacy Digest, Vol 44, Issue 13 Send dns-privacy mailing list submissions to dns-privacy@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/dns-privacy or, via email, send a message with subject or body 'help' to dns-privacy-request@ietf.org You can reach the person managing the list at dns-privacy-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dns-privacy digest..." Today's Topics: 1. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement (Stephane Bortzmeyer) 2. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement (Paul Hoffman) 3. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement (Daniel Kahn Gillmor) 4. Re: Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked? (Daniel Kahn Gillmor) 5. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement (Paul Hoffman) 6. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement (Stephen Farrell) ---------------------------------------------------------------------- Message: 1 Date: Mon, 30 Oct 2017 14:34:03 +0100 From: Stephane Bortzmeyer To: Daniel Kahn Gillmor Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Message-ID: <20171030133403.2yyw4m4ldjdcyl7f@nic.fr> Content-Type: text/plain; charset=3Dus-ascii On Fri, Oct 27, 2017 at 11:40:15PM -0400, Daniel Kahn Gillmor wrote a message of 219 lines which said: > I do not believe that DNSSEC validation is warranted as a mitigation > against an active attacker in the context of an opportunistic > metaquery, I see the point but it seems to me a small detail in a 29-pages document. So, IMHO, it should not cause yet another long delay for a draft that already lingered too much. > But i think the other changes between draft-10 and draft-11 are > unwarranted and should be reverted. There are very few changes and, except the DNSSEC *requirment*, they seem good to me. I agree with Sara "I really do think a description there of the trade-offs of DNSSEC validation are warranted". ------------------------------ Message: 2 Date: Mon, 30 Oct 2017 07:46:43 -0700 From: "Paul Hoffman" To: "Sara Dickinson" Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Message-ID: <9D3816E2-AE0D-4803-BBE8-FA98A196D376@vpnc.org> Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed On 30 Oct 2017, at 6:11, Sara Dickinson wrote: > I?d disagree that connecting to a server for which the meta-query > response failed DNSSEC validation results in _just_ a loss of privacy > for Opportunistic in this case. If the answer was BOGUS then it seems > reasonable to assume the server is not legitimate and so connecting > also results in the clients' entire DNS service being controlled by > the attacker. There are many ways to get a BOGUS response that have nothing to do with the information being "not legitimate". Typically today, BOGUS comes from misconfigured servers such as expired keys, some nameservers out of sync, and so on. You cannot infer from a BOGUS response about why it is bogus. > Take the case where the DNS server from DHCP really is legitimate. The > fact that the meta-query answer _could_ be spoofed provides a vector > for an opportunistic client to be directed to an attackers' DNS > server. Note that this attack is not possible on a ?normal? client > that directly uses the DHCP provided server, the attacker has to > attack each individual query. My concern here is that without DNSSEC > validation of the re-direct Opportunistic clients have an additional > risk of this kind of attack than ?normal? ones. Spoofing in normal DHCP and spoofing without DNSSEC seem equivalent to me. > Also this is only a guaranteed DoS for the case where there is only a > single server configured. If there are multiple servers then the > attacker must spoof the meta-query answers for _all_ the servers to > achieve DoS. If it only spoofs one then the client can still get > service. ...unless the attacker can spoof the (typically) two servers that the client has addresses to. > So one way to look at the trade-off seems to be is it worse that an > attacker can block your DNS service or gets an extra chance to control > all your DNS answers? I think you are arguing that for opportunistic > the latter is preferable because a principle of Opportunistic is that > it shouldn?t fail? If the WG decided that to be the case then it > needs to be clear in the document this choice comes with an additional > risk (and yet still not guarantee of privacy). It is only an "additional risk" for a very limited attacker who can only attack one of a set of addresses. If the WG wants to go down the path of making Opportunistic encryption even more difficult in order to feel that we offered the best security, requiring DNSSEC on the client is a good way to do that. I would still prefer more ubiquitous encryption. --Paul Hoffman ------------------------------ Message: 3 Date: Mon, 30 Oct 2017 16:08:35 +0100 From: Daniel Kahn Gillmor To: Sara Dickinson Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Message-ID: <871slkd66k.fsf@fifthhorseman.net> Content-Type: text/plain; charset=3D"utf-8" On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote: > I really do think a description there of the trade-offs of DNSSEC > validation are warranted I agree that a discussion of the tradeoffs involved in DNSSEC validation of the opportunistic meta-query is warranted. I just come to a different conclusion than the requirements in draft-11. > if it ends up just being a MAY (although I would like to see SHOULD as > a minimum for opportunistic). SHOULD validate, but with what failure mode? are we really saying that opportunistic SHOULD deliver a DoS instead of a loss of privacy? I discuss a few optional responses for failures in opportunistic mode below. > I can also recognise the implementation overhead, however this is > required for only one of the 3 cases of how the client may be > provisioned: > > * IP address only (no meta-query required) > > * IP address and ADN (no meta-query required) > > * ADN only (meta-query required) > > So it is for the case where a client was directly and securely > configured with just the ADN of a server it expects to provide > privacy. If a client doesn?t want to implement DNSSEC then it can > always restrict the opportunistic profile to requiring one of the > first 2 configurations. The cheapest and simplest implementation in terms of user experience to get to verifiable opportunistic profile (that is, a profile that can at least report that DNS privacy has been achieved, even if it won't be enforced) seems to be: * allow the local administrator to provide a name for the preferred DNS resolver Since it's opportunistic, it can even be enabled by default. But this is the "ADN only" use case. Saying it's not usable with the opportunistic profile without DNSSEC validation would be a shame. >> Choice 0 is the same outcome as the non-DNSSEC-validating scenario for >> strict clients (no mitigation), > > Agreed - DNSSEC validation just provides earlier detection for Strict cli= ents or, converts success to failure in the case of DNSSEC misconfiguration (because the connection would otherwise have succeeded) :( > I?d disagree that connecting to a server for which the meta-query > response failed DNSSEC validation results in _just_ a loss of privacy > for Opportunistic in this case. If the answer was BOGUS then it seems > reasonable to assume the server is not legitimate and so connecting > also results in the clients' entire DNS service being controlled by > the attacker. sure, but this is the case for non-private DNS as well, right? So the mitigation in this case is with respect to the features that "private DNS" is supposed to offer. Whatever those features are, they are absent given an attacker-controlled DNS resolver. So if the DNS-over-TLS server is intended to also provide integrity protection, yes, that would also be lost. I think we're agreeing here, right? I apologize if "loss of privacy" is a misleading shorthand. > Take the case where the DNS server from DHCP really is legitimate. The > fact that the meta-query answer _could_ be spoofed provides a vector > for an opportunistic client to be directed to an attackers' DNS > server. Note that this attack is not possible on a ?normal? client > that directly uses the DHCP provided server, the attacker has to > attack each individual query. My concern here is that without DNSSEC > validation of the re-direct Opportunistic clients have an additional > risk of this kind of attack than ?normal? ones. ok, i think i understand. The concern is that a non-network-controlling attacker who can spoof DNS responses but can't spoof DHCP responses can now take over full DNS resolution of opportunistic clients just by racing (and winning) the legitimate metaquery response. This is true, but the threat model we're worrying now include all of the following characteristics: * attacker does not control the client's network (otherwise, they could redirect the port 853 queries anyway) * attacker cannot (or has failed to) race the client's DHCP connection (otherwise, they'd point to a different DNS server anyway) * attacker *can* race the legitimate response to the client's opportunistic metaquery. * client is in opportunistic mode. So the question is, in this particular corner case, what is the right mitigation to the scenario where "if DNSSEC validation of the opportunistic metaquery fails?" ? if the answer is "?proceed as though it had not failed (trying to connect to the preferred server's proposed address), but continue listening for another response to the metaquery; prefer subsequent metaquery responses that do have DNSSEC validation over those responses that are not DNSSEC validated." Then i'd be ok with it, but it's not specified in the draft. If the answer is "?hard-fail and deny DNS service", then i think that's incorrect given the goals of opportunistic mode. If the answer is "?stop trying to use opportunistic DNS privacy entirely, but fall back to using the DHCP-provided resolver for all queries" then i think that's a mistake -- we've already demonstrated that we're in a scenario where the attacker can race the DHCP-provided resolver and win. So what do we gain by making this the failure mode? > Also this is only a guaranteed DoS for the case where there is only a > single server configured. If there are multiple servers then the > attacker must spoof the meta-query answers for _all_ the servers to > achieve DoS. If it only spoofs one then the client can still get > service. I think this equivalent to my responses-to-failed-validation #2 -- retrying the opportunistic metaquery. (also, equivalent to "?but continue listening?" in the paragraphs above.) I agree that's an interesting case, but i think it's an additional complexity as yet unspecified in the draft. :( > So one way to look at the trade-off seems to be is it worse that an > attacker can block your DNS service or gets an extra chance to control > all your DNS answers? I think you are arguing that for opportunistic > the latter is preferable because a principle of Opportunistic is that > it shouldn?t fail? If the WG decided that to be the case then it needs > to be clear in the document this choice comes with an additional risk > (and yet still not guarantee of privacy). it is "an extra chance only" in the scenario where points outlined above hold. An attacker who can also race and beat the DHCP server has the exact same chance already, right? > Technically his DISCUSS was on a different topic (SPKI handling) as > Stephane pointed out, this was an issue that came out of a separate > comment he made. Hm, sorry, i'll try to follow up on that in the other sub-thread. Thanks for the discussion. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: ------------------------------ Message: 4 Date: Mon, 30 Oct 2017 16:27:16 +0100 From: Daniel Kahn Gillmor To: Stephane Bortzmeyer , dns-privacy@ietf.org Subject: Re: [dns-privacy] Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked? Message-ID: <87y3nsbqqz.fsf@fifthhorseman.net> Content-Type: text/plain; charset=3D"us-ascii" On Fri 2017-10-27 15:55:10 +0200, Stephane Bortzmeyer wrote: > The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles > has a DISCUSS "This needs to be updated to indicate that the client > MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise > you're going to have interop problems." I agree that this DISCUSS should be cleared, since draft-10 and draft-11 both state: A client MUST only indicate support for raw public keys if it has an SPKI pinset pre-configured (for interoperability reasons). Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: ------------------------------ Message: 5 Date: Mon, 30 Oct 2017 08:42:18 -0700 From: "Paul Hoffman" To: "Daniel Kahn Gillmor" Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Message-ID: <1B2537D5-DFD7-407A-A84E-925C85EF9268@vpnc.org> Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed On 30 Oct 2017, at 8:08, Daniel Kahn Gillmor wrote: > On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote: >> if it ends up just being a MAY (although I would like to see SHOULD >> as >> a minimum for opportunistic). > > SHOULD validate, but with what failure mode? +1 to the question: we're talking about Opportunistic mode here. > are we really saying that > opportunistic SHOULD deliver a DoS instead of a loss of privacy? Some of us are most emphatically not saying that. . . . > sure, but this is the case for non-private DNS as well, right? So the > mitigation in this case is with respect to the features that "private > DNS" is supposed to offer. Whatever those features are, they are > absent > given an attacker-controlled DNS resolver. So if the DNS-over-TLS > server is intended to also provide integrity protection, yes, that > would > also be lost. I think we're agreeing here, right? I apologize if > "loss > of privacy" is a misleading shorthand. > >> Take the case where the DNS server from DHCP really is legitimate. >> The >> fact that the meta-query answer _could_ be spoofed provides a vector >> for an opportunistic client to be directed to an attackers' DNS >> server. Note that this attack is not possible on a ?normal? >> client >> that directly uses the DHCP provided server, the attacker has to >> attack each individual query. My concern here is that without DNSSEC >> validation of the re-direct Opportunistic clients have an additional >> risk of this kind of attack than ?normal? ones. > > ok, i think i understand. The concern is that a > non-network-controlling > attacker who can spoof DNS responses but can't spoof DHCP responses > can > now take over full DNS resolution of opportunistic clients just by > racing (and winning) the legitimate metaquery response. > > This is true, but the threat model we're worrying now include all of > the > following characteristics: > > * attacker does not control the client's network (otherwise, they > could > redirect the port 853 queries anyway) > > * attacker cannot (or has failed to) race the client's DHCP > connection > (otherwise, they'd point to a different DNS server anyway) > > * attacker *can* race the legitimate response to the client's > opportunistic metaquery. > > * client is in opportunistic mode. > > So the question is, in this particular corner case, what is the right > mitigation to the scenario where "if DNSSEC validation of the > opportunistic metaquery fails?" ? > > if the answer is "?proceed as though it had not failed (trying to > connect to the preferred server's proposed address), but continue > listening for another response to the metaquery; prefer subsequent > metaquery responses that do have DNSSEC validation over those > responses > that are not DNSSEC validated." Then i'd be ok with it, but it's not > specified in the draft. > > If the answer is "?hard-fail and deny DNS service", then i think > that's > incorrect given the goals of opportunistic mode. Agree. And fully agree that an attacker who can do the third bullet *but not the second* is a very obscure corner case. Having this document say, in essence, "you don't get opportunistic encryption unless you add a DNSSEC validation stack" feels like a regression to the original goals of this WG. --Paul Hoffman ------------------------------ Message: 6 Date: Mon, 30 Oct 2017 15:59:21 +0000 From: Stephen Farrell To: Paul Hoffman , Daniel Kahn Gillmor Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Message-ID: Content-Type: text/plain; charset=3D"utf-8" Hiya, On 30/10/17 15:42, Paul Hoffman wrote: > Having this document say, in essence, "you don't get opportunistic > encryption unless you add a DNSSEC validation stack" feels like a > regression to the original goals of this WG. I'm not sure that having a stack is such a barrier in reality. Requiring that some DNSSEC signatures validate in order to win the opportunistic game is the problem I think. I'd personally be fine with a "MUST try DNSSEC" statement, though that could be argued to be OTT, given the probability of success, but as DKG and you (and I) agree, it's the failure mode that needs fixing in the draft. S. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: ------------------------------ Subject: Digest Footer _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy ------------------------------ End of dns-privacy Digest, Vol 44, Issue 13 ******************************************* --_000_AM5PR0401MB2627AD2E6D8E45CB514F1DC399590AM5PR0401MB2627_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Antoine Germanos=99
From: dns-privacy <dns= -privacy-bounces@ietf.org> on behalf of dns-privacy-request@ietf.org <= ;dns-privacy-request@ietf.org>
Sent: Monday, October 30, 2017 6:10:54 PM
To: dns-privacy@ietf.org
Subject: dns-privacy Digest, Vol 44, Issue 13
 
Send dns-privacy mailing list submissions to
        dns-privacy@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/dns-pri= vacy
or, via email, send a message with subject or body 'help' to
        dns-privacy-request@ietf.org

You can reach the person managing the list at
        dns-privacy-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dns-privacy digest..."


Today's Topics:

   1. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: w= e
      should revert DNSSEC validation requirement = (Stephane Bortzmeyer)
   2. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: w= e
      should revert DNSSEC validation requirement = (Paul Hoffman)
   3. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: w= e
      should revert DNSSEC validation requirement = (Daniel Kahn Gillmor)
   4. Re: Why is draft-ietf-dprive-dtls-and-tls-profiles still       blocked? (Daniel Kahn Gillmor)
   5. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: w= e
      should revert DNSSEC validation requirement = (Paul Hoffman)
   6. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: w= e
      should revert DNSSEC validation requirement = (Stephen Farrell)


----------------------------------------------------------------------

Message: 1
Date: Mon, 30 Oct 2017 14:34:03 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-p= rofiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <20171030133403.2yyw4m4ldjdcyl7f@nic.fr>
Content-Type: text/plain; charset=3Dus-ascii

On Fri, Oct 27, 2017 at 11:40:15PM -0400,
 Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote
 a message of 219 lines which said:

> I do not believe that DNSSEC validation is warranted as a mitigation > against an active attacker in the context of an opportunistic
> metaquery,

I see the point but it seems to me a small detail in a 29-pages
document. So, IMHO, it should not cause yet another long delay for a
draft that already lingered too much.

> But i think the other changes between draft-10 and draft-11 are
> unwarranted and should be reverted.

There are very few changes and, except the DNSSEC *requirment*, they
seem good to me. I agree with Sara "I really do think a description there of the trade-offs of DNSSEC validation are warranted".



------------------------------

Message: 2
Date: Mon, 30 Oct 2017 07:46:43 -0700
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: "Sara Dickinson" <sara@sinodun.com>
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-p= rofiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <9D3816E2-AE0D-4803-BBE8-FA98A196D376@vpnc.org>
Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed

On 30 Oct 2017, at 6:11, Sara Dickinson wrote:

> I?d disagree that connecting to a server for which the meta-query
> response failed DNSSEC validation results in _just_ a loss of privacy =
> for Opportunistic in this case. If the answer was BOGUS then it seems =
> reasonable to assume the server is not legitimate and so connecting > also results in the clients' entire DNS service being controlled by > the attacker.

There are many ways to get a BOGUS response that have nothing to do with the information being "not legitimate". Typically today, BOGUS co= mes
from misconfigured servers such as expired keys, some nameservers out of sync, and so on.

You cannot infer from a BOGUS response about why it is bogus.

> Take the case where the DNS server from DHCP really is legitimate. The=
> fact that the meta-query answer _could_ be spoofed provides a vector <= br> > for an opportunistic client to be directed to an attackers' DNS
> server. Note that this attack is not possible on a ?normal? client > that directly uses the DHCP provided server, the attacker has to
> attack each individual query. My concern here is that without DNSSEC <= br> > validation of the re-direct Opportunistic clients have an additional <= br> > risk of this kind of attack than ?normal? ones.

Spoofing in normal DHCP and spoofing without DNSSEC seem equivalent to
me.

> Also this is only a guaranteed DoS for the case where there is only a =
> single server configured. If there are multiple servers then the
> attacker must spoof the meta-query answers for _all_ the servers to > achieve DoS. If it only spoofs one then the client can still get
> service.

...unless the attacker can spoof the (typically) two servers that the
client has addresses to.

> So one way to look at the trade-off seems to be is it worse that an > attacker can block your DNS service or gets an extra chance to control=
> all your DNS answers? I think you are arguing that for opportunistic <= br> > the latter is preferable because a principle of Opportunistic is that =
> it shouldn?t fail? If the WG decided that to be the case then it
> needs to be clear in the document this choice comes with an additional=
> risk (and yet still not guarantee of privacy).

It is only an "additional risk" for a very limited attacker who c= an only
attack one of a set of addresses.

If the WG wants to go down the path of making Opportunistic encryption
even more difficult in order to feel that we offered the best security, requiring DNSSEC on the client is a good way to do that. I would still
prefer more ubiquitous encryption.

--Paul Hoffman



------------------------------

Message: 3
Date: Mon, 30 Oct 2017 16:08:35 +0100
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Sara Dickinson <sara@sinodun.com>
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-p= rofiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <871slkd66k.fsf@fifthhorseman.net>
Content-Type: text/plain; charset=3D"utf-8"

On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote:
> I really do think a description there of the trade-offs of DNSSEC
> validation are warranted

I agree that a discussion of the tradeoffs involved in DNSSEC validation of the opportunistic meta-query is warranted.  I just come to a
different conclusion than the requirements in draft-11.

> if it ends up just being a MAY (although I would like to see SHOULD as=
> a minimum for opportunistic).

SHOULD validate, but with what failure mode?  are we really saying tha= t
opportunistic SHOULD deliver a DoS instead of a loss of privacy?  I discuss a few optional responses for failures in opportunistic mode
below.

> I can also recognise the implementation overhead, however this is
> required for only one of the 3 cases of how the client may be
> provisioned:
>
> * IP address only (no meta-query required)
>
> * IP address and ADN (no meta-query required)
>
> * ADN only (meta-query required)
>
> So it is for the case where a client was directly and securely
> configured with just the ADN of a server it expects to provide
> privacy. If a client doesn?t want to implement DNSSEC then it can
> always restrict the opportunistic profile to requiring one of the
> first 2 configurations.

The cheapest and simplest implementation in terms of user experience to
get to verifiable opportunistic profile (that is, a profile that can at
least report that DNS privacy has been achieved, even if it won't be
enforced) seems to be:

  * allow the local administrator to provide a name for the preferred<= br>     DNS resolver

Since it's opportunistic, it can even be enabled by default.

But this is the "ADN only" use case.  Saying it's not usable= with the
opportunistic profile without DNSSEC validation would be a shame.

>> Choice 0 is the same outcome as the non-DNSSEC-validating scenario= for
>> strict clients (no mitigation),
>
> Agreed - DNSSEC validation just provides earlier detection for Strict = clients

or, converts success to failure in the case of DNSSEC misconfiguration
(because the connection would otherwise have succeeded) :(

> I?d disagree that connecting to a server for which the meta-query
> response failed DNSSEC validation results in _just_ a loss of privacy<= br> > for Opportunistic in this case. If the answer was BOGUS then it seems<= br> > reasonable to assume the server is not legitimate and so connecting > also results in the clients' entire DNS service being controlled by > the attacker.

sure, but this is the case for non-private DNS as well, right?  So the=
mitigation in this case is with respect to the features that "private<= br> DNS" is supposed to offer.  Whatever those features are, they are= absent
given an attacker-controlled DNS resolver.  So if the DNS-over-TLS
server is intended to also provide integrity protection, yes, that would also be lost.  I think we're agreeing here, right?  I apologize i= f "loss
of privacy" is a misleading shorthand.

> Take the case where the DNS server from DHCP really is legitimate. The=
> fact that the meta-query answer _could_ be spoofed provides a vector > for an opportunistic client to be directed to an attackers' DNS
> server. Note that this attack is not possible on a ?normal? client
> that directly uses the DHCP provided server, the attacker has to
> attack each individual query. My concern here is that without DNSSEC > validation of the re-direct Opportunistic clients have an additional > risk of this kind of attack than ?normal? ones.

ok, i think i understand.  The concern is that a non-network-controlli= ng
attacker who can spoof DNS responses but can't spoof DHCP responses can
now take over full DNS resolution of opportunistic clients just by
racing (and winning) the legitimate metaquery response.

This is true, but the threat model we're worrying now include all of the following characteristics:

 * attacker does not control the client's network (otherwise, they cou= ld
   redirect the port 853 queries anyway)
 
 * attacker cannot (or has failed to) race the client's DHCP connectio= n
   (otherwise, they'd point to a different DNS server anyway)

 * attacker *can* race the legitimate response to the client's
   opportunistic metaquery.

 * client is in opportunistic mode.

So the question is, in this particular corner case, what is the right
mitigation to the scenario where "if DNSSEC validation of the
opportunistic metaquery fails?" ?

if the answer is "?proceed as though it had not failed (trying to
connect to the preferred server's proposed address), but continue
listening for another response to the metaquery; prefer subsequent
metaquery responses that do have DNSSEC validation over those responses
that are not DNSSEC validated." Then i'd be ok with it, but it's not specified in the draft.

If the answer is "?hard-fail and deny DNS service", then i think = that's
incorrect given the goals of opportunistic mode.

If the answer is "?stop trying to use opportunistic DNS privacy
entirely, but fall back to using the DHCP-provided resolver for all
queries" then i think that's a mistake -- we've already demonstrated that we're in a scenario where the attacker can race the DHCP-provided
resolver and win.  So what do we gain by making this the failure mode?=

> Also this is only a guaranteed DoS for the case where there is only a<= br> > single server configured. If there are multiple servers then the
> attacker must spoof the meta-query answers for _all_ the servers to > achieve DoS. If it only spoofs one then the client can still get
> service.

I think this equivalent to my responses-to-failed-validation #2 --
retrying the opportunistic metaquery.  (also, equivalent to "?but=
continue listening?" in the paragraphs above.) I agree that's an
interesting case, but i think it's an additional complexity as yet
unspecified in the draft.  :(

> So one way to look at the trade-off seems to be is it worse that an > attacker can block your DNS service or gets an extra chance to control=
> all your DNS answers? I think you are arguing that for opportunistic > the latter is preferable because a principle of Opportunistic is that<= br> > it shouldn?t fail? If the WG decided that to be the case then it needs=
> to be clear in the document this choice comes with an additional risk<= br> > (and yet still not guarantee of privacy).

it is "an extra chance only" in the scenario where points outline= d above
hold.  An attacker who can also race and beat the DHCP server has the<= br> exact same chance already, right?

> Technically his DISCUSS was on a different topic (SPKI handling) as > Stephane pointed out, this was an issue that came out of a separate > comment he made.

Hm, sorry, i'll try to follow up on that in the other sub-thread.

Thanks for the discussion.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://mailarchive.ietf.org/ar= ch/browse/dns-privacy/attachments/20171030/671db67b/attachment.asc><= br>
------------------------------

Message: 4
Date: Mon, 30 Oct 2017 16:27:16 +0100
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, dns-privacy@ietf.org
Subject: Re: [dns-privacy] Why is
        draft-ietf-dprive-dtls-and-tls-p= rofiles still blocked?
Message-ID: <87y3nsbqqz.fsf@fifthhorseman.net>
Content-Type: text/plain; charset=3D"us-ascii"

On Fri 2017-10-27 15:55:10 +0200, Stephane Bortzmeyer wrote:
> The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles<= br> > has a DISCUSS "This needs to be updated to indicate that the clie= nt
> MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise
> you're going to have interop problems."

I agree that this DISCUSS should be cleared, since draft-10 and draft-11 both state:

    A client MUST only indicate support for raw public keys = if it has an
    SPKI pinset pre-configured (for interoperability reasons= ).

Regards,

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://mailarchive.ietf.org/ar= ch/browse/dns-privacy/attachments/20171030/639c412b/attachment.asc><= br>
------------------------------

Message: 5
Date: Mon, 30 Oct 2017 08:42:18 -0700
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: "Daniel Kahn Gillmor" <dkg@fifthhorseman.net>
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-p= rofiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <1B2537D5-DFD7-407A-A84E-925C85EF9268@vpnc.org>
Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed

On 30 Oct 2017, at 8:08, Daniel Kahn Gillmor wrote:

> On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote:
>> if it ends up just being a MAY (although I would like to see SHOUL= D
>> as
>> a minimum for opportunistic).
>
> SHOULD validate, but with what failure mode?

+1 to the question: we're talking about Opportunistic mode here.

> are we really saying that
> opportunistic SHOULD deliver a DoS instead of a loss of privacy?

Some of us are most emphatically not saying that.

. . .

> sure, but this is the case for non-private DNS as well, right?  S= o the
> mitigation in this case is with respect to the features that "pri= vate
> DNS" is supposed to offer.  Whatever those features are, the= y are
> absent
> given an attacker-controlled DNS resolver.  So if the DNS-over-TL= S
> server is intended to also provide integrity protection, yes, that > would
> also be lost.  I think we're agreeing here, right?  I apolog= ize if
> "loss
> of privacy" is a misleading shorthand.
>
>> Take the case where the DNS server from DHCP really is legitimate.=
>> The
>> fact that the meta-query answer _could_ be spoofed provides a vect= or
>> for an opportunistic client to be directed to an attackers' DNS >> server. Note that this attack is not possible on a ?normal?
>> client
>> that directly uses the DHCP provided server, the attacker has to >> attack each individual query. My concern here is that without DNSS= EC
>> validation of the re-direct Opportunistic clients have an addition= al
>> risk of this kind of attack than ?normal? ones.
>
> ok, i think i understand.  The concern is that a
> non-network-controlling
> attacker who can spoof DNS responses but can't spoof DHCP responses > can
> now take over full DNS resolution of opportunistic clients just by
> racing (and winning) the legitimate metaquery response.
>
> This is true, but the threat model we're worrying now include all of <= br> > the
> following characteristics:
>
>  * attacker does not control the client's network (otherwise, the= y
> could
>    redirect the port 853 queries anyway)
>
>  * attacker cannot (or has failed to) race the client's DHCP
> connection
>    (otherwise, they'd point to a different DNS server a= nyway)
>
>  * attacker *can* race the legitimate response to the client's >    opportunistic metaquery.
>
>  * client is in opportunistic mode.
>
> So the question is, in this particular corner case, what is the right<= br> > mitigation to the scenario where "if DNSSEC validation of the
> opportunistic metaquery fails?" ?
>
> if the answer is "?proceed as though it had not failed (trying to=
> connect to the preferred server's proposed address), but continue
> listening for another response to the metaquery; prefer subsequent
> metaquery responses that do have DNSSEC validation over those
> responses
> that are not DNSSEC validated." Then i'd be ok with it, but it's = not
> specified in the draft.
>
> If the answer is "?hard-fail and deny DNS service", then i t= hink
> that's
> incorrect given the goals of opportunistic mode.

Agree. And fully agree that an attacker who can do the third bullet *but not the second* is a very obscure corner case.

Having this document say, in essence, "you don't get opportunistic encryption unless you add a DNSSEC validation stack" feels like a
regression to the original goals of this WG.

--Paul Hoffman



------------------------------

Message: 6
Date: Mon, 30 Oct 2017 15:59:21 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: Paul Hoffman <paul.hoffman@vpnc.org>, Daniel Kahn Gillmor
        <dkg@fifthhorseman.net> Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-p= rofiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <ac8f15bf-73fb-6728-e846-293c4da5bfaa@cs.tcd.ie>
Content-Type: text/plain; charset=3D"utf-8"


Hiya,

On 30/10/17 15:42, Paul Hoffman wrote:
> Having this document say, in essence, "you don't get opportunisti= c
> encryption unless you add a DNSSEC validation stack" feels like a=
> regression to the original goals of this WG.

I'm not sure that having a stack is such a barrier in reality.
Requiring that some DNSSEC signatures validate in order to win
the opportunistic game is the problem I think.

I'd personally be fine with a "MUST try DNSSEC" statement, though=
that could be argued to be OTT, given the probability of success,
but as DKG and you (and I) agree, it's the failure mode that needs
fixing in the draft.

S.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://mailarchive.ietf.org/ar= ch/browse/dns-privacy/attachments/20171030/00fb8f85/attachment.asc><= br>
------------------------------

Subject: Digest Footer

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.i= etf.org/mailman/listinfo/dns-privacy


------------------------------

End of dns-privacy Digest, Vol 44, Issue 13
*******************************************
 --_000_AM5PR0401MB2627AD2E6D8E45CB514F1DC399590AM5PR0401MB2627_-- From nobody Mon Oct 30 13:05:01 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E575313FAE1 for ; Mon, 30 Oct 2017 13:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 cSjU8H86eCJl for ; Mon, 30 Oct 2017 13:04:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 B62C613F403 for ; Mon, 30 Oct 2017 13:04:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yQlng0DPkzF7M; Mon, 30 Oct 2017 21:04:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1509393895; bh=3HHamuoJjrcZXFzf1kInNXEaaIiWZw2f02ZfyE99jTA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kyadvvduRlyROJn0Z9gqDHMj4paz7uHCQuLeeHvi7jPiQ5+2R6t6GfvzBhmZDuTKx OXFlOlVaEzCD75xH55n5i9vJEXDQ+HEk7cQ6cplWXNxVNrbASRs/j1jPc464+7E92r 9ebB97hZOQezcFotiSGoHFB1pKErcM+ipZxhp2s8= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ip_ANH5YGjk7; Mon, 30 Oct 2017 21:04:53 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 30 Oct 2017 21:04:52 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E189462D29; Mon, 30 Oct 2017 16:04:51 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E189462D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CA73940D35AF; Mon, 30 Oct 2017 16:04:51 -0400 (EDT) Date: Mon, 30 Oct 2017 16:04:51 -0400 (EDT) From: Paul Wouters To: Daniel Kahn Gillmor cc: Sara Dickinson , dns-privacy@ietf.org In-Reply-To: <871slkd66k.fsf@fifthhorseman.net> Message-ID: References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> <871slkd66k.fsf@fifthhorseman.net> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 20:05:00 -0000 On Mon, 30 Oct 2017, Daniel Kahn Gillmor wrote: > Date: Mon, 30 Oct 2017 11:08:35 > From: Daniel Kahn Gillmor > Cc: dns-privacy@ietf.org > To: Sara Dickinson > Subject: Re: [dns-privacy] review of > draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC > validation requirement > > On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote: >> I really do think a description there of the trade-offs of DNSSEC >> validation are warranted > > I agree that a discussion of the tradeoffs involved in DNSSEC validation > of the opportunistic meta-query is warranted. I just come to a > different conclusion than the requirements in draft-11. If a client allows multiple type of profiles, then DNSSEC might not be needed to reach a pre-configured Strict profile with a trust anchor. Then the decision to be made is, if that Strict profile is unavailable, does that make the current network hostile enough to not use it? And if no strict profile is configured, well then anyting is better then nothing. >> if it ends up just being a MAY (although I would like to see SHOULD as >> a minimum for opportunistic). > > SHOULD validate, but with what failure mode? are we really saying that > opportunistic SHOULD deliver a DoS instead of a loss of privacy? I > discuss a few optional responses for failures in opportunistic mode > below. If talking about the meta query, see above. If talking about DNSESC validation for the actual content queries, I think it should be considered that anything not properly supporting DNSSEC is an active attack against the user, and I would be okay with a hard fail. > The cheapest and simplest implementation in terms of user experience to > get to verifiable opportunistic profile (that is, a profile that can at > least report that DNS privacy has been achieved, even if it won't be > enforced) seems to be: I thought "opportunistic" meant "do not report to the user" so as to guarantee that the user is still thinking they are in the realm of "not private" even if there is encryption happening, because without a trust anchor, the user cannot know if this opportunistic party is privacy preserving? > or, converts success to failure in the case of DNSSEC misconfiguration > (because the connection would otherwise have succeeded) :( A dnssec failure is no different then a certificate failure, and browsers are now doing something really close to hard fail on those now. >> I’d disagree that connecting to a server for which the meta-query >> response failed DNSSEC validation results in _just_ a loss of privacy >> for Opportunistic in this case. If the answer was BOGUS then it seems >> reasonable to assume the server is not legitimate and so connecting >> also results in the clients' entire DNS service being controlled by >> the attacker. I guess I see two different opportunistic cases. One where you find a DNS server, get to an IP and/or public key, use DNSSEC to confirm the key/name in the public real DNS (via that server) and protected with DNSSEC. For instance, a coffeeshop chain could do so, and if it links to say publicdns.starbucks.com then you have some confidence then the local instance of the coffeeshop cannot see your traffic. And then there is the opportunistic case where you simply will never find out the identity, and where you just assume the provider could be the attaker. I feel those two user cases are different. The first one, I could decide not to use my local starbucks when it starts to fail using the chain's configured DNS server. The second case I know I'm giving my privacy to someone who could be malicious, but I still prefer that over not using their DNS. (although in practise, my guess is as soon as google DNS supports TLS, everyone will have at least one Strict profile with their key and never use an opportunistic profile. >> Take the case where the DNS server from DHCP really is legitimate. The >> fact that the meta-query answer _could_ be spoofed provides a vector >> for an opportunistic client to be directed to an attackers' DNS >> server. Note that this attack is not possible on a ’normal’ client >> that directly uses the DHCP provided server, the attacker has to >> attack each individual query. My concern here is that without DNSSEC >> validation of the re-direct Opportunistic clients have an additional >> risk of this kind of attack than ’normal’ ones. > > ok, i think i understand. The concern is that a non-network-controlling > attacker who can spoof DNS responses but can't spoof DHCP responses can > now take over full DNS resolution of opportunistic clients just by > racing (and winning) the legitimate metaquery response. I think that's really rare now. Most "shared wifi" solutions constrain the clients and prevent them from talking to each other. In the coffeeshop the customers cannot see my laptop, but the coffeeshop owner can. Paul From nobody Tue Oct 31 08:07:17 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBAB13F752 for ; Tue, 31 Oct 2017 08:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 SbiLqzuzvqhs for ; Tue, 31 Oct 2017 08:07:13 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 0ACB313F75B for ; Tue, 31 Oct 2017 08:06:23 -0700 (PDT) Received: from [2001:b98:204:102:fffa::14b4] (port=56885) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1e9Y7Q-0002hx-BD; Tue, 31 Oct 2017 15:06:20 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sara Dickinson In-Reply-To: Date: Tue, 31 Oct 2017 15:06:16 +0000 Cc: Daniel Kahn Gillmor , dns-privacy@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7709D3C3-D879-421B-B81A-7908F521B9D5@sinodun.com> References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> <871slkd66k.fsf@fifthhorseman.net> To: Paul Wouters X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 15:07:15 -0000 So here is an example of how Stubby works today. It has separate = settings for Transports(UDP/TCP/TLS), Usage profile and DNSSEC. The = relevant DNSSEC options are: - dnssec_return_status - blocks BOGUS answers, returns all others with = status information (secure vs insecure vs indeterminate) - dnssec_return_only_secure - does what is says on the tin where =E2=80=98dnssec_return_status=E2=80=99 is obviously what we = recommend if you want DNSSEC.=20 If I have stubby configured like that then connecting to a DNS server = with a BOGUS A record just because I=E2=80=99m in opportunistic privacy = mode seems questionable.=20 So maybe =E2=80=9CA DNSSEC validating client SHOULD apply the same = validation policy to the A/AAAA meta-query lookup as it does to other = queries.=E2=80=9D? Sara. > On 30 Oct 2017, at 20:04, Paul Wouters wrote: >=20 > On Mon, 30 Oct 2017, Daniel Kahn Gillmor wrote: >=20 >> Date: Mon, 30 Oct 2017 11:08:35 >> From: Daniel Kahn Gillmor >> Cc: dns-privacy@ietf.org >> To: Sara Dickinson >> Subject: Re: [dns-privacy] review of >> draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert = DNSSEC >> validation requirement >> On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote: >>> I really do think a description there of the trade-offs of DNSSEC >>> validation are warranted >>=20 >> I agree that a discussion of the tradeoffs involved in DNSSEC = validation >> of the opportunistic meta-query is warranted. I just come to a >> different conclusion than the requirements in draft-11. >=20 > If a client allows multiple type of profiles, then DNSSEC might not be > needed to reach a pre-configured Strict profile with a trust anchor. > Then the decision to be made is, if that Strict profile is = unavailable, > does that make the current network hostile enough to not use it? And = if > no strict profile is configured, well then anyting is better then > nothing. >=20 >>> if it ends up just being a MAY (although I would like to see SHOULD = as >>> a minimum for opportunistic). >>=20 >> SHOULD validate, but with what failure mode? are we really saying = that >> opportunistic SHOULD deliver a DoS instead of a loss of privacy? I >> discuss a few optional responses for failures in opportunistic mode >> below. >=20 > If talking about the meta query, see above. If talking about DNSESC > validation for the actual content queries, I think it should be > considered that anything not properly supporting DNSSEC is an active > attack against the user, and I would be okay with a hard fail. >=20 >> The cheapest and simplest implementation in terms of user experience = to >> get to verifiable opportunistic profile (that is, a profile that can = at >> least report that DNS privacy has been achieved, even if it won't be >> enforced) seems to be: >=20 > I thought "opportunistic" meant "do not report to the user" so as to > guarantee that the user is still thinking they are in the realm of = "not > private" even if there is encryption happening, because without a = trust > anchor, the user cannot know if this opportunistic party is privacy > preserving? >=20 >> or, converts success to failure in the case of DNSSEC = misconfiguration >> (because the connection would otherwise have succeeded) :( >=20 > A dnssec failure is no different then a certificate failure, and > browsers are now doing something really close to hard fail on those = now. >=20 >>> I=E2=80=99d disagree that connecting to a server for which the = meta-query >>> response failed DNSSEC validation results in _just_ a loss of = privacy >>> for Opportunistic in this case. If the answer was BOGUS then it = seems >>> reasonable to assume the server is not legitimate and so connecting >>> also results in the clients' entire DNS service being controlled by >>> the attacker. >=20 > I guess I see two different opportunistic cases. One where you find > a DNS server, get to an IP and/or public key, use DNSSEC to confirm = the > key/name in the public real DNS (via that server) and protected with > DNSSEC. For instance, a coffeeshop chain could do so, and if it links = to > say publicdns.starbucks.com then you have some confidence then the = local > instance of the coffeeshop cannot see your traffic. And then there is > the opportunistic case where you simply will never find out the > identity, and where you just assume the provider could be the attaker. >=20 > I feel those two user cases are different. The first one, I could = decide > not to use my local starbucks when it starts to fail using the chain's > configured DNS server. The second case I know I'm giving my privacy to > someone who could be malicious, but I still prefer that over not using > their DNS. (although in practise, my guess is as soon as google DNS > supports TLS, everyone will have at least one Strict profile with = their > key and never use an opportunistic profile. >=20 >>> Take the case where the DNS server from DHCP really is legitimate. = The >>> fact that the meta-query answer _could_ be spoofed provides a vector >>> for an opportunistic client to be directed to an attackers' DNS >>> server. Note that this attack is not possible on a =E2=80=99normal=E2=80= =99 client >>> that directly uses the DHCP provided server, the attacker has to >>> attack each individual query. My concern here is that without DNSSEC >>> validation of the re-direct Opportunistic clients have an additional >>> risk of this kind of attack than =E2=80=99normal=E2=80=99 ones. >>=20 >> ok, i think i understand. The concern is that a = non-network-controlling >> attacker who can spoof DNS responses but can't spoof DHCP responses = can >> now take over full DNS resolution of opportunistic clients just by >> racing (and winning) the legitimate metaquery response. >=20 > I think that's really rare now. Most "shared wifi" solutions constrain = the > clients and prevent them from talking to each other. In the coffeeshop > the customers cannot see my laptop, but the coffeeshop owner can. >=20 > Paul >=20 > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy From nobody Tue Oct 31 08:15:28 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7EE13F722 for ; Tue, 31 Oct 2017 08:15:26 -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 fUiZHliFXDJd for ; Tue, 31 Oct 2017 08:15:25 -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 93EF413F7BE for ; Tue, 31 Oct 2017 08:12:48 -0700 (PDT) Received: from [10.32.60.231] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v9VFBNU9028711 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Oct 2017 08:11:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.231] From: "Paul Hoffman" To: "Sara Dickinson" Cc: dns-privacy@ietf.org Date: Tue, 31 Oct 2017 08:12:45 -0700 Message-ID: In-Reply-To: <7709D3C3-D879-421B-B81A-7908F521B9D5@sinodun.com> References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> <871slkd66k.fsf@fifthhorseman.net> <7709D3C3-D879-421B-B81A-7908F521B9D5@sinodun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 15:15:27 -0000 On 31 Oct 2017, at 8:06, Sara Dickinson wrote: > So maybe “A DNSSEC validating client SHOULD apply the same > validation policy to the A/AAAA meta-query lookup as it does to other > queries.”? That could be misinterpreted to indicate that there has to be some positive validation policy. How about: A DNSSEC validating client SHOULD apply the same validation policy to the A/AAAA meta-query lookup as it does to other queries. A client that does not validate DNSSEC SHOULD apply any policy it has to the A/AAAA meta-query lookup. --Paul Hoffman From nobody Tue Oct 31 11:39:55 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1D413F595 for ; Tue, 31 Oct 2017 11:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, 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 gAWP2PWE1N0a for ; Tue, 31 Oct 2017 11:39:51 -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 9F6CE13F516 for ; Tue, 31 Oct 2017 11:39:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7186BBEAA; Tue, 31 Oct 2017 18:39:49 +0000 (GMT) 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 gmyIxYfL32hI; Tue, 31 Oct 2017 18:39:47 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7F144BED4; Tue, 31 Oct 2017 18:39:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1509475144; bh=vHm+uA/PRruAOkmo7o6DLmPxN2AX6hqHhPxudk2mIAE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kxu4UcyUFmcOi6dXvNLtSUKAoPRc00Ui47hMtm1FePdgUB4vmrYqWXaD04hfEQ89+ oeSCq1Evj7bsASF074L2HZSPmxhwU+ooXH5ujgsw2Ue9ShwF+IGZYg6d1xKfroSBcS mdf0CWsWHC7EkPxDLVNVMWab06hcXwe4NHZXXpQ4= To: Paul Hoffman , Sara Dickinson Cc: dns-privacy@ietf.org References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> <871slkd66k.fsf@fifthhorseman.net> <7709D3C3-D879-421B-B81A-7908F521B9D5@sinodun.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 31 Oct 2017 18:39:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rKBA8k2cfW8D69faU9sIKLWaGQbDjQQV1" Archived-At: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 18:39:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rKBA8k2cfW8D69faU9sIKLWaGQbDjQQV1 Content-Type: multipart/mixed; boundary="qgnFnrPKh6J2u4aLBU7kcCoe4Drf5saXM"; protected-headers="v1" From: Stephen Farrell To: Paul Hoffman , Sara Dickinson Cc: dns-privacy@ietf.org Message-ID: Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> <871slkd66k.fsf@fifthhorseman.net> <7709D3C3-D879-421B-B81A-7908F521B9D5@sinodun.com> In-Reply-To: --qgnFnrPKh6J2u4aLBU7kcCoe4Drf5saXM Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 31/10/17 15:12, Paul Hoffman wrote: > On 31 Oct 2017, at 8:06, Sara Dickinson wrote: >=20 >> So maybe =E2=80=9CA DNSSEC validating client SHOULD apply the same val= idation >> policy to the A/AAAA meta-query lookup as it does to other queries.=E2= =80=9D? >=20 > That could be misinterpreted to indicate that there has to be some > positive validation policy. How about: > =C2=A0=C2=A0 A DNSSEC validating client SHOULD apply the same validatio= n policy > =C2=A0=C2=A0 to the A/AAAA meta-query lookup as it does to other querie= s. > =C2=A0=C2=A0 A client that does not validate DNSSEC SHOULD apply any po= licy it > =C2=A0=C2=A0 has to the A/AAAA meta-query lookup. So I think either of the above could be ok. The main thing for me is that we do not insist that a server has to get DNSSEC setup before they can do opportunistic DNS security. I think the above is ok in that respect. Just checking: I think that means that with the opportunistic profile, only servers that have DNSSEC setup and where the client validates and gets a badly signed response would be affected, all other cases would still get DNS privacy of some sort. If that's right, I can live with it. Cheers, S. >=20 > --Paul Hoffman >=20 > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy --qgnFnrPKh6J2u4aLBU7kcCoe4Drf5saXM-- --rKBA8k2cfW8D69faU9sIKLWaGQbDjQQV1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ+MNIAAoJEC88hzaAX42ilJYH/ia6PEdebM6Gu5T88XHYDwMK dQgOADN/XvjmLbiDbF0DREcnTNT6QC6Mla+/6Rk16eki1pSoe3i0ByDiq3uAwI3R Wc2l1/HBZUNsITI2X7bWsd6G/J2y06mR6XiFJ7wpRCMTPbN7SZVkNu1Hv/4950Y5 gWIjE6PPkKZ1AuX4ZfaLMRiys5EcksR6rRFH3AUwHLYRA3VZ1/VqUzxiwhCwu6tl b06E+5/7sUVd633FlFdiBqr2D2RNg8fEJHloKNzm7sqfiIHdvUAguMzNZGapieBp 4QdYtMDYk+uz9fhhN21kK64GOdMsvW6qHBaW3BvRNSO6UK3OGlzpZBSsp9+O7aQ= =8d2P -----END PGP SIGNATURE----- --rKBA8k2cfW8D69faU9sIKLWaGQbDjQQV1-- From nobody Tue Oct 31 13:21:04 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93DF1397F3 for ; Tue, 31 Oct 2017 13:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 FwIUzTb8MurW for ; Tue, 31 Oct 2017 13:20:56 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-oln040092067049.outbound.protection.outlook.com [40.92.67.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A59B13F5FD for ; Tue, 31 Oct 2017 13:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ky+hNDDOtNVRRylbpPcVrSizBU+hhF/QIzFYujBq8Bc=; b=repZGpOvkFcqmL4JYf1VT8cLVWslzTEDoznbmt8ChFQyv9S9cWl1WG5BSZQJeGmNlehxCWfftoaCEbPSKuR0AtHvkgR3k6JgRoVq6b/W3xWfpD1hVfBjSP8qdAqdpkCGnY9K4bsDu3Rxu+jkIXwhb7THMqzfQxn+iW0VJ8goT4K4lXoyMUYZGvmJWZNT09lRDRjnSfR+E6Vt5qsRs6fOXgeX7XXCZ4nkoeH9O6YOFT2hWKy9MW4BY7hdVqT4FmJQKccSNecEVwG39kCjcHQodmyr0XiZYg7oHZ3fTBEz6yxMaFK5BD1Ew349hfWMMV1mOVHLXqV3AfNg65rN3vQaFQ== Received: from VE1EUR02FT040.eop-EUR02.prod.protection.outlook.com (10.152.12.56) by VE1EUR02HT213.eop-EUR02.prod.protection.outlook.com (10.152.13.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.178.5; Tue, 31 Oct 2017 20:20:53 +0000 Received: from AM5PR0401MB2627.eurprd04.prod.outlook.com (10.152.12.53) by VE1EUR02FT040.mail.protection.outlook.com (10.152.13.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.178.5 via Frontend Transport; Tue, 31 Oct 2017 20:20:48 +0000 Received: from AM5PR0401MB2627.eurprd04.prod.outlook.com ([fe80::4079:74d1:d1c2:62b4]) by AM5PR0401MB2627.eurprd04.prod.outlook.com ([fe80::4079:74d1:d1c2:62b4%17]) with mapi id 15.20.0178.014; Tue, 31 Oct 2017 20:20:48 +0000 From: Antoine Germanos To: "dns-privacy@ietf.org" , "dns-privacy@ietf.org" Thread-Topic: dns-privacy Digest, Vol 44, Issue 15 Thread-Index: AQHTUnqVIQ7ITABx70aGONi73kIIa6L+ZoJ0 Date: Tue, 31 Oct 2017 20:20:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:B4C2032C06BFC0EE1137DD87A47BDB3BE1691ED83BAB9277148105A272FDCE75; UpperCasedChecksum:E611A0A2908906D25720FE87DA3805CCC11B2B6A9DBE947552516DCF37D855C4; SizeAsReceived:7072; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [gEgViqKybRdankcQpgT+n3MzdtgO2ni1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VE1EUR02HT213; 6:qNTmnF4k7bkmKshb1BfnEU/Vnv9arEZwPIsWwtBWjvsfY7Dw3ACsuWnoZuGdAmLQj2PBL55QH2EYdJqyZqZdCu0KYnEKqns1uQ/vSiDtaL57CT1DguorKcU2KVyEFtMG24Q19z907iT3RHyr4z3b0wmDcgUHgM1h9Xr1QxM6dAo3ATc333rzgkoc8Udu83GuuIdxP/3hwt1YZgOo+BNgl/kYZ2lvWUYd3XZIShUQGYAdyJQVevdzW8d3X5xHaw36NBhrXG7os7gqbXrlI3Vp0vkOo4srNBnfDfAJav0POH9uqO58xbb9NyMG5k9+5Rn08mjIkta5kenjiDu3bNjYzBwSjvTxc4Bkjt5A1aHu9N0=; 5:qPmrF1wvGt9b4Y0iJR1ftj4faI9tuQ96g2oY4ulyEBMwVD73VmtgIkbu8Dn8yOA4VeT2twMBfuSQleUPGmbQNds8NnmOrnlBEzlRSUNPFFqjjc8IHKzKB6PD7RhdeZEjK1aia64qSBEJz9+jszzIGxfAAl4SeEHWuliCcWeuXjc=; 24:6FcuZn3zXxd6RZQK4rGihR0+apDJ26oD5a9Rn1SQkOmidnNoFvSpWcCa78N1BLS97NUYY0b3wDTOZDrfB84EFsL9XA3n6/SvycZX1rz7HoI=; 7:vhfjviG30WeKA53lq8zLNNz700+w6shHpPoCSuxS+cSu/ksFpirXH+fZbz2+VzSjRTgfXP8f9SB9kXOPSTrHyE+G7Cm/qnkCekXIyX7HvbRbDV9L9+bBDhA0HFvq+CxAStbzxcnd0rSy5quPb8xS9pgDwmp5AXfuM3gSoomgkMR7c4XVAfzCPWJOxU7HLcXcjYaw+SKx53nd88sgFTVI/S8WgtfF84yj9hRnhpszJrs2t3Qfd51eq2ABuL5UYVp6 x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: a10d8ca6-33e6-4ccd-3a93-08d5209cdfa3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:VE1EUR02HT213; x-ms-traffictypediagnostic: VE1EUR02HT213: x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(81439100147899)(1717195254398); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:VE1EUR02HT213; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VE1EUR02HT213; x-forefront-prvs: 04772EA191 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:VE1EUR02HT213; H:AM5PR0401MB2627.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0401MB2627BFF9CCA1B819D749A891995E0AM5PR0401MB2627_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: a10d8ca6-33e6-4ccd-3a93-08d5209cdfa3 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 20:20:48.1327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT213 Archived-At: Subject: Re: [dns-privacy] dns-privacy Digest, Vol 44, Issue 15 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 20:21:01 -0000 --_000_AM5PR0401MB2627BFF9CCA1B819D749A891995E0AM5PR0401MB2627_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkFzIGZvciB0aGUgc2NlbmFyaW8sIGxldOKAmXMgdGFsayBhYm91dCBTdGFy YnVja3MgZWcgOw0KDQpnb29kIG9uZSBieSB0aGUgd2F5LCBJIGxvdmUgU3RhcmJ1Y2tzIC4NCkxl dOKAmXMgc2F5IEkgYW0gbWVldGluZyB3aXRoIHNvbWVvbmUgdGhhdCB0b3VjaGVkIGJhc2Ugd2l0 aCBtZSBzYXlpbmcgaGUgaXMgYSBmYW1pbHkgcmVsYXRpdmUuDQoNCkhlIHRvdWNoZWQgYmFzZSB3 aXRoIG1lIHNheWluZyBJIGFzIHJlbGF0aXZlIHRvIGhpcyBsYXRlIGF1bnQgLCBzdXBwb3NlZGx5 IG15IG1vdGhlcuKAmXMgZ3JhbmRtb3RoZXIsIGhpcyBhdW50IGluIHRoZSBzYW1lIHRpbWUsIHRo dXMgSSBzaG91bGQgc2lnbiBzb21lIHBhcGVycyBiZWNveiBJIGRvIGluaGVyaXQgYSBzbWFsbCBw YXJ0IG9mIHRoZSBhc3NldHMgLg0KDQpPcHBvcnR1bmlzdGljIG9yLiBOb3QsIHdobyB3b3VsZCBq dXN0IGlnbm9yZSBzdWNoIGEgcHJvcG9zYWwsIGF0IGxlYXN0IGZyb20gd2hhdCBJIGtub3csIEkg aGVhcmQgbXkgbW9tIHRhbGtpbmcgb25jZSBhYm91dCB0aGUgbGF0ZSBnb25lIGFuZCB0aGF0IHRo ZXkgd2VyZSByZWFsbHkgY2xvc2UgcmVsYXRpdmVzLg0KDQpTdXBwb3NlZGx5IGluIHRoaXMgc2Nl bmFyaW8sIHdoZXJlICwgaWYgc28sIHdlIGFyZSBhbGwgZmFtaWx5ICwgd2h5IG5vdCB0byB0b3Vj aCBiYXNlIHdpdGggaGltICwgYWxyZWFkeSB0aGUgcGFwZXJzIGhlIGdhdmUgbWUgbWUgYWJvdXQg dGhlIGluaGVyaXRhbmNlLCB3ZXJlIGFscmVhZHkgbm90YXJpemVkLCBhbmQgbWVudGlvbmVkIHRo ZSBmYW1pbHkgdHJlZSAsIHZlcnkgY2xlYXIgaW4gdGhlIGhlYWRlci5hcyBwcm9vZnMgYmVpbmcu IFJlbGF0aXZlUyAoIHRoZSBub3RhcnkgaGFkIG1lbnRpb25lZCB0aGUgbmFtZSBvZiBteSBtb20g YW5kIGFjY29yZGluZ2x5IGhlciBzaXN0ZXIgLCB3aG8gcGFzc2VkIGF3YXkgeWVzdGVyZGF5LCB1 bmZvcnR1bmF0ZSBjb2luY2lkZW5jZSBpbmRlZWQuDQoNCldoZW4gd2UgdGFsa2VkLCBhcyByZWxh dGl2ZXMgLCBub3RoaW5nIG5ldyB3YXMgYnJvdWdodCB0byBkaXNjdXNzaW9uLCBJICwgYXMgYWx3 YXlzIGN1cmlvdXMgdG8gZGlzY292ZXIgYW5kIERpR0cgbW9yZSBpbiB0aGUgZmFtaWx5IHRyZWUg LCByZWxhdGl2ZXMsIG9yICwgTm90Lg0KV2hlbiBhIHdoaWxlIGFnbywNCkkgd2FzIGludml0ZWQg dG8gbHVuY2ggaW4gbXkgZXgtd2lmZSBmYW1pbHkgcGFsYWNlLCBteSBtb20sIHNvIGF0dGFjaGVk IHRvIG1haW50YWluIG91ciBmYW1pbHksIHZlcnkgc3Ryb25nIHJvb3RzIGNvbmNlcm5pbmcganVz dCBnYXRoZXJpbmcgdGhlIGZhbWlseSBtZW1iZXJzIG9uIG9jY2FzaW9ucywgdmVyeSBzdHJpY3Qg Y29uY2VybmluZyB0aGUgY29kZSBhbmQgdGhlIGNvbmR1Y3QsIHNoZSBpcyB0aGUgZGF1Z2h0ZXIg b2YgYSBMb3JkLCBhbmQgZXRpcXVldHRlIG1hdHRlcnMgYSBsb3QgZm9yIGhlciwNCldoZW4gaSB0 b29rIG15IGtpZHMgb24gdGhhbmtzZ2l2aW5nIHRvIG15IGV4LXdpZmUgZmFtaWx5IHBhbGFjZSwg KCB0aGV5IGhhdmUgYmVlbiBhIGxvdCBvZiB3ZWRkaW5ncyBhbmQgZGl2b3JjZXMgYmV0d2VlbiBt eSBmYW1pbHkgYW5kIG15IGV4LSB3aWZlIGZhbWlseSApDQoNCkJ5IHRoZW4gLCBteSBtb20gYm95 Y290dGVkIG1lIGZvciBhIHdoaWxlIGFuZCB0aG91Z2h0IEkgd291bGQgbGVhdmUgdGhlIGtpZHMg Y3VzdG9keSB0byBteSBleC13aWZlLCBzbyBtdWNoIGF0dGFjaGVkIGFuZCBzdHJpY3QgYWJvdXQg a2VlcGluZyB0aGUgZmFtaWx5IHRvZ2V0aGVyLiBTaGUgbGF0ZXIga25ldyB0aGF0IG15IGJveXMg aGF2ZSBvdXIgZmFtaWx5IHJvb3RzIGluIHRoZWlyIEROQSwgKD8gQSB2ZXJ5IHdlbGwgYW5jaG9y ZWQgYW5jZXN0cnkpIC0gbm90aGluZyBvbiBlYXJ0aCBjYW4gYnJlYWsgdGhpcyBsaW5rIC4gQW5k IGhvbmVzdGx5IEkgYW0gZmVkIHVwIHdpdGggbXkgbW9tIGNvbmNlcm5zIGFmdGVyIDMwIHllYXJz IG9mIGJlaW5nIGluIGEgc2l0dWF0aW9uIHdoZXJlIEkgc2hvdWxkIHByb3ZlIHRvIGhlciB0aGF0 IOKAnGluZGVlZCwgZm9yIHN1cmUsIG5vIG1hdHRlciB3aGF0LCBldmVuIGlmIHRoZXkgd2lsbCB0 YWtlIG15IHNvdWzigJ0gSSB3b3VsZCBuZXZlciBjaGFuZ2UgbXkgZmFtaWx5IG5hbWUgb3IgbXkg Ym95cyBmYW1pbHkgbmFtZS4gQW4gaXNzdWUgbXkgZXggLSB3aWZlIGxhd3llciB1c2VkIGp1c3Qg dG8gYmxhY2ttYWlsIG15IGZhbWlseSAsIGtub3dpbmcgaG93IG11Y2ggd2UgYXJlIGF0dGFjaGVk IGVhY2ggb25lIHRvIHRoZSBvdGhlci4NCg0KQW5kIGNvbmNlcm5pbmcgcG9pc29uaW5nIG15IGRy aW5rOyBqdXN0IHRha2UgYSBtaW51dGUgYW5kIHRoaW5rIHNlcmlvdXNseSBvZiBpdDsgaGUgaXMg dGhlIG93bmVyIG9mIFN0YXJidWNrcyEhISBIZSBjYW4sIHdvdWxkLCBjb3VsZCwgd2lsbCBtYXli ZSBwb2lzb24gZXZlcnlvbmUuIFNvLCB0aGlua2luZyBvZiBpdCwgY2FsY3VsYXRpbmcgdGhlIHJp c2sgaSUgaGUgY291bGQgaGF2ZSBwb2lzb25lZCBteSBkcmluayBpcyB0aGUgc2FtZSAlIGFueWJv ZHkgb2YgdXMgY291bGQgZmF2ZSBldmVyeSBtb3JuaW5nIHdoZW4gZ3JhYmJpbmcgaGlzIGNvZmZl ZS4NCg0KSWYgZWFjaCBvZiB1cyB3aWxsIGtlZXAgb24gc3VzcGVjdGluZyBlYWNoIG90aGVy4oCZ cyAsIHRoYW4gdGhlIHJ1bGUgaXMgZ29ubmEgYmUgdGhlIGV4Y2VwdGlvbiwgYW5kIHRoZSBleGNl cHRpb24gcnVsZSEhIE91ciBiZWxpZWZzLCBwcmluY2lwbGVzICwgb3duIGNvbnZpY3Rpb25zLCBh bmQgc2FtZSB2aXNpb24gaXMgd2hhdCBwdXQgdXMgdG9nZXRoZXIgOyB0cnVlLCB3ZSBoYXZlIHRv IGtlZXAgdGhlIGNpcmNsZSDirZXvuI8gYSBbIGNpcmNsZSBdICwgYW5kIHN0YXkgYXdha2VuIGFu ZCBhd2FyZSwgYnV0IGlmIGl04oCZcyBnb25uYSBiZSBhbiBhbGwtdGltZSB0cnVzdCBpc3N1ZXMg Ym91bmNpbmcgaW4gYSB0ZW5uaXMgcGxheWdyb3VuZDsgaXQgd2lsbCBsaXRlcmFsbHkgYmVjb21l IGp1c3QgYSDigJxnYW1l4oCdIG9mIGhpZGUgYW5kIHNlZWssIGluc3RlYWQgb2YgdGhlIENvbW1v biBDb21tdW5pdHkgQ29tbWl0bWVudCwgYSBQZXJwZXR1YWwgUGl0Y2hpbmcgUHJvYmFiaWxpdGll czsgdGhlbiAuLi4ubGV04oCZcyBnbyBQUFAgUC1QICggcGhvbmV0aWNzKSAuDQoNClRoaXMgaXMg bXkgb3BpbmlvbiwgaSBmb3IgbXlzZWxmIHdhbnQgd2l0aCBwbGVhc3VyZSBkZWRpY2F0aW5nIG15 IHRpbWUgdG8gYSBjb21tb24gYmVsaWVmLCBhbmQgYmV0dGVyIGJlIOKAnG9wcG9ydHVuaXN0aWPi gJ0gdGhhbiBiZWluZyDigJxTa2VwdGljYWzigJ07IGFuZCBiZXR0ZXIgdGhhbiB0aG9zZSAyIGlz IHRvIGJlaGF2ZSBsaWtlIHdlIHNob3VsZCwgb25lIGNvbW11bml0eSwgbm90IGxhYmVsaW5nIGFu ZCBkb3VidGluZyBlYWNoIG90aGVycy4NCg0KWW91IGNvdWxkIHNheSB3aGF0ZXZlciB1IHdhbnQs IGtpY2sgbWUgb2ZmLCBidXQgaG9uZXN0bHksIEkgYW0gaW4gZm9yIG15IHN0cm9uZyBiZWxpZXZl IGluIGEgY29tbW9uIHZpc2lvbi4gQW5kIGhvdyB0byBkZXZlbG9wIGl0ICwgcmF0aGVyIHRoYW4g 4oCcZW52ZWxvcOKAnSBpdC4NCg0KR3JlZXRpbmdzLA0KQW50b2luZQ0KDQoNCkFudG9pbmUgR2Vy bWFub3PihKINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBkbnMtcHJp dmFjeSA8ZG5zLXByaXZhY3ktYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGRucy1wcml2 YWN5LXJlcXVlc3RAaWV0Zi5vcmcgPGRucy1wcml2YWN5LXJlcXVlc3RAaWV0Zi5vcmc+DQpTZW50 OiBUdWVzZGF5LCBPY3RvYmVyIDMxLCAyMDE3IDk6MDA6MTYgUE0NClRvOiBkbnMtcHJpdmFjeUBp ZXRmLm9yZw0KU3ViamVjdDogZG5zLXByaXZhY3kgRGlnZXN0LCBWb2wgNDQsIElzc3VlIDE1DQoN ClNlbmQgZG5zLXByaXZhY3kgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQogICAgICAgIGRu cy1wcml2YWN5QGlldGYub3JnDQoNClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhl IFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Rucy1wcml2YWN5DQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3 aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8NCiAgICAgICAgZG5zLXByaXZhY3ktcmVxdWVz dEBpZXRmLm9yZw0KDQpZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3Qg YXQNCiAgICAgICAgZG5zLXByaXZhY3ktb3duZXJAaWV0Zi5vcmcNCg0KV2hlbiByZXBseWluZywg cGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYw0KdGhh biAiUmU6IENvbnRlbnRzIG9mIGRucy1wcml2YWN5IGRpZ2VzdC4uLiINCg0KDQpUb2RheSdzIFRv cGljczoNCg0KICAgMS4gUmU6IHJldmlldyBvZiBkcmFmdC1pZXRmLWRwcml2ZS1kdGxzLWFuZC10 bHMtcHJvZmlsZXMtMTE6IHdlDQogICAgICBzaG91bGQgcmV2ZXJ0IEROU1NFQyB2YWxpZGF0aW9u IHJlcXVpcmVtZW50IChQYXVsIFdvdXRlcnMpDQogICAyLiBSZTogcmV2aWV3IG9mIGRyYWZ0LWll dGYtZHByaXZlLWR0bHMtYW5kLXRscy1wcm9maWxlcy0xMTogd2UNCiAgICAgIHNob3VsZCByZXZl cnQgRE5TU0VDIHZhbGlkYXRpb24gcmVxdWlyZW1lbnQgKFNhcmEgRGlja2luc29uKQ0KICAgMy4g UmU6IHJldmlldyBvZiBkcmFmdC1pZXRmLWRwcml2ZS1kdGxzLWFuZC10bHMtcHJvZmlsZXMtMTE6 IHdlDQogICAgICBzaG91bGQgcmV2ZXJ0IEROU1NFQyB2YWxpZGF0aW9uIHJlcXVpcmVtZW50IChQ YXVsIEhvZmZtYW4pDQogICA0LiBSZTogcmV2aWV3IG9mIGRyYWZ0LWlldGYtZHByaXZlLWR0bHMt YW5kLXRscy1wcm9maWxlcy0xMTogd2UNCiAgICAgIHNob3VsZCByZXZlcnQgRE5TU0VDIHZhbGlk YXRpb24gcmVxdWlyZW1lbnQgKFN0ZXBoZW4gRmFycmVsbCkNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Ck1lc3NhZ2U6IDENCkRhdGU6IE1vbiwgMzAgT2N0IDIwMTcgMTY6MDQ6NTEgLTA0MDAgKEVEVCkN CkZyb206IFBhdWwgV291dGVycyA8cGF1bEBub2hhdHMuY2E+DQpUbzogRGFuaWVsIEthaG4gR2ls bG1vciA8ZGtnQGZpZnRoaG9yc2VtYW4ubmV0Pg0KQ2M6IFNhcmEgRGlja2luc29uIDxzYXJhQHNp bm9kdW4uY29tPiwgZG5zLXByaXZhY3lAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZG5zLXByaXZh Y3ldIHJldmlldyBvZg0KICAgICAgICBkcmFmdC1pZXRmLWRwcml2ZS1kdGxzLWFuZC10bHMtcHJv ZmlsZXMtMTE6IHdlIHNob3VsZCByZXZlcnQgRE5TU0VDDQogICAgICAgIHZhbGlkYXRpb24gcmVx dWlyZW1lbnQNCk1lc3NhZ2UtSUQ6IDxhbHBpbmUuTFJILjIuMjEuMTcxMDMwMTUzOTUwMC4zMTA4 MkBib2ZoLm5vaGF0cy5jYT4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD11dGYt ODsgZm9ybWF0PWZsb3dlZA0KDQpPbiBNb24sIDMwIE9jdCAyMDE3LCBEYW5pZWwgS2FobiBHaWxs bW9yIHdyb3RlOg0KDQo+IERhdGU6IE1vbiwgMzAgT2N0IDIwMTcgMTE6MDg6MzUNCj4gRnJvbTog RGFuaWVsIEthaG4gR2lsbG1vciA8ZGtnQGZpZnRoaG9yc2VtYW4ubmV0Pg0KPiBDYzogZG5zLXBy aXZhY3lAaWV0Zi5vcmcNCj4gVG86IFNhcmEgRGlja2luc29uIDxzYXJhQHNpbm9kdW4uY29tPg0K PiBTdWJqZWN0OiBSZTogW2Rucy1wcml2YWN5XSByZXZpZXcgb2YNCj4gICAgIGRyYWZ0LWlldGYt ZHByaXZlLWR0bHMtYW5kLXRscy1wcm9maWxlcy0xMTogd2Ugc2hvdWxkIHJldmVydCBETlNTRUMN Cj4gICAgIHZhbGlkYXRpb24gcmVxdWlyZW1lbnQNCj4NCj4gT24gTW9uIDIwMTctMTAtMzAgMTM6 MTE6NDEgKzAwMDAsIFNhcmEgRGlja2luc29uIHdyb3RlOg0KPj4gSSByZWFsbHkgZG8gdGhpbmsg YSBkZXNjcmlwdGlvbiB0aGVyZSBvZiB0aGUgdHJhZGUtb2ZmcyBvZiBETlNTRUMNCj4+IHZhbGlk YXRpb24gYXJlIHdhcnJhbnRlZA0KPg0KPiBJIGFncmVlIHRoYXQgYSBkaXNjdXNzaW9uIG9mIHRo ZSB0cmFkZW9mZnMgaW52b2x2ZWQgaW4gRE5TU0VDIHZhbGlkYXRpb24NCj4gb2YgdGhlIG9wcG9y dHVuaXN0aWMgbWV0YS1xdWVyeSBpcyB3YXJyYW50ZWQuICBJIGp1c3QgY29tZSB0byBhDQo+IGRp ZmZlcmVudCBjb25jbHVzaW9uIHRoYW4gdGhlIHJlcXVpcmVtZW50cyBpbiBkcmFmdC0xMS4NCg0K SWYgYSBjbGllbnQgYWxsb3dzIG11bHRpcGxlIHR5cGUgb2YgcHJvZmlsZXMsIHRoZW4gRE5TU0VD IG1pZ2h0IG5vdCBiZQ0KbmVlZGVkIHRvIHJlYWNoIGEgcHJlLWNvbmZpZ3VyZWQgU3RyaWN0IHBy b2ZpbGUgd2l0aCBhIHRydXN0IGFuY2hvci4NClRoZW4gdGhlIGRlY2lzaW9uIHRvIGJlIG1hZGUg aXMsIGlmIHRoYXQgU3RyaWN0IHByb2ZpbGUgaXMgdW5hdmFpbGFibGUsDQpkb2VzIHRoYXQgbWFr ZSB0aGUgY3VycmVudCBuZXR3b3JrIGhvc3RpbGUgZW5vdWdoIHRvIG5vdCB1c2UgaXQ/IEFuZCBp Zg0Kbm8gc3RyaWN0IHByb2ZpbGUgaXMgY29uZmlndXJlZCwgd2VsbCB0aGVuIGFueXRpbmcgaXMg YmV0dGVyIHRoZW4NCm5vdGhpbmcuDQoNCj4+IGlmIGl0IGVuZHMgdXAganVzdCBiZWluZyBhIE1B WSAoYWx0aG91Z2ggSSB3b3VsZCBsaWtlIHRvIHNlZSBTSE9VTEQgYXMNCj4+IGEgbWluaW11bSBm b3Igb3Bwb3J0dW5pc3RpYykuDQo+DQo+IFNIT1VMRCB2YWxpZGF0ZSwgYnV0IHdpdGggd2hhdCBm YWlsdXJlIG1vZGU/ICBhcmUgd2UgcmVhbGx5IHNheWluZyB0aGF0DQo+IG9wcG9ydHVuaXN0aWMg U0hPVUxEIGRlbGl2ZXIgYSBEb1MgaW5zdGVhZCBvZiBhIGxvc3Mgb2YgcHJpdmFjeT8gIEkNCj4g ZGlzY3VzcyBhIGZldyBvcHRpb25hbCByZXNwb25zZXMgZm9yIGZhaWx1cmVzIGluIG9wcG9ydHVu aXN0aWMgbW9kZQ0KPiBiZWxvdy4NCg0KSWYgdGFsa2luZyBhYm91dCB0aGUgbWV0YSBxdWVyeSwg c2VlIGFib3ZlLiBJZiB0YWxraW5nIGFib3V0IEROU0VTQw0KdmFsaWRhdGlvbiBmb3IgdGhlIGFj dHVhbCBjb250ZW50IHF1ZXJpZXMsIEkgdGhpbmsgaXQgc2hvdWxkIGJlDQpjb25zaWRlcmVkIHRo YXQgYW55dGhpbmcgbm90IHByb3Blcmx5IHN1cHBvcnRpbmcgRE5TU0VDIGlzIGFuIGFjdGl2ZQ0K YXR0YWNrIGFnYWluc3QgdGhlIHVzZXIsIGFuZCBJIHdvdWxkIGJlIG9rYXkgd2l0aCBhIGhhcmQg ZmFpbC4NCg0KPiBUaGUgY2hlYXBlc3QgYW5kIHNpbXBsZXN0IGltcGxlbWVudGF0aW9uIGluIHRl cm1zIG9mIHVzZXIgZXhwZXJpZW5jZSB0bw0KPiBnZXQgdG8gdmVyaWZpYWJsZSBvcHBvcnR1bmlz dGljIHByb2ZpbGUgKHRoYXQgaXMsIGEgcHJvZmlsZSB0aGF0IGNhbiBhdA0KPiBsZWFzdCByZXBv cnQgdGhhdCBETlMgcHJpdmFjeSBoYXMgYmVlbiBhY2hpZXZlZCwgZXZlbiBpZiBpdCB3b24ndCBi ZQ0KPiBlbmZvcmNlZCkgc2VlbXMgdG8gYmU6DQoNCkkgdGhvdWdodCAib3Bwb3J0dW5pc3RpYyIg bWVhbnQgImRvIG5vdCByZXBvcnQgdG8gdGhlIHVzZXIiIHNvIGFzIHRvDQpndWFyYW50ZWUgdGhh dCB0aGUgdXNlciBpcyBzdGlsbCB0aGlua2luZyB0aGV5IGFyZSBpbiB0aGUgcmVhbG0gb2YgIm5v dA0KcHJpdmF0ZSIgZXZlbiBpZiB0aGVyZSBpcyBlbmNyeXB0aW9uIGhhcHBlbmluZywgYmVjYXVz ZSB3aXRob3V0IGEgdHJ1c3QNCmFuY2hvciwgdGhlIHVzZXIgY2Fubm90IGtub3cgaWYgdGhpcyBv cHBvcnR1bmlzdGljIHBhcnR5IGlzIHByaXZhY3kNCnByZXNlcnZpbmc/DQoNCj4gb3IsIGNvbnZl cnRzIHN1Y2Nlc3MgdG8gZmFpbHVyZSBpbiB0aGUgY2FzZSBvZiBETlNTRUMgbWlzY29uZmlndXJh dGlvbg0KPiAoYmVjYXVzZSB0aGUgY29ubmVjdGlvbiB3b3VsZCBvdGhlcndpc2UgaGF2ZSBzdWNj ZWVkZWQpIDooDQoNCkEgZG5zc2VjIGZhaWx1cmUgaXMgbm8gZGlmZmVyZW50IHRoZW4gYSBjZXJ0 aWZpY2F0ZSBmYWlsdXJlLCBhbmQNCmJyb3dzZXJzIGFyZSBub3cgZG9pbmcgc29tZXRoaW5nIHJl YWxseSBjbG9zZSB0byBoYXJkIGZhaWwgb24gdGhvc2Ugbm93Lg0KDQo+PiBJP2QgZGlzYWdyZWUg dGhhdCBjb25uZWN0aW5nIHRvIGEgc2VydmVyIGZvciB3aGljaCB0aGUgbWV0YS1xdWVyeQ0KPj4g cmVzcG9uc2UgZmFpbGVkIEROU1NFQyB2YWxpZGF0aW9uIHJlc3VsdHMgaW4gX2p1c3RfIGEgbG9z cyBvZiBwcml2YWN5DQo+PiBmb3IgT3Bwb3J0dW5pc3RpYyBpbiB0aGlzIGNhc2UuIElmIHRoZSBh bnN3ZXIgd2FzIEJPR1VTIHRoZW4gaXQgc2VlbXMNCj4+IHJlYXNvbmFibGUgdG8gYXNzdW1lIHRo ZSBzZXJ2ZXIgaXMgbm90IGxlZ2l0aW1hdGUgYW5kIHNvIGNvbm5lY3RpbmcNCj4+IGFsc28gcmVz dWx0cyBpbiB0aGUgY2xpZW50cycgZW50aXJlIEROUyBzZXJ2aWNlIGJlaW5nIGNvbnRyb2xsZWQg YnkNCj4+IHRoZSBhdHRhY2tlci4NCg0KSSBndWVzcyBJIHNlZSB0d28gZGlmZmVyZW50IG9wcG9y dHVuaXN0aWMgY2FzZXMuIE9uZSB3aGVyZSB5b3UgZmluZA0KYSBETlMgc2VydmVyLCBnZXQgdG8g YW4gSVAgYW5kL29yIHB1YmxpYyBrZXksIHVzZSBETlNTRUMgdG8gY29uZmlybSB0aGUNCmtleS9u YW1lIGluIHRoZSBwdWJsaWMgcmVhbCBETlMgKHZpYSB0aGF0IHNlcnZlcikgYW5kIHByb3RlY3Rl ZCB3aXRoDQpETlNTRUMuIEZvciBpbnN0YW5jZSwgYSBjb2ZmZWVzaG9wIGNoYWluIGNvdWxkIGRv IHNvLCBhbmQgaWYgaXQgbGlua3MgdG8NCnNheSBwdWJsaWNkbnMuc3RhcmJ1Y2tzLmNvbSB0aGVu IHlvdSBoYXZlIHNvbWUgY29uZmlkZW5jZSB0aGVuIHRoZSBsb2NhbA0KaW5zdGFuY2Ugb2YgdGhl IGNvZmZlZXNob3AgY2Fubm90IHNlZSB5b3VyIHRyYWZmaWMuIEFuZCB0aGVuIHRoZXJlIGlzDQp0 aGUgb3Bwb3J0dW5pc3RpYyBjYXNlIHdoZXJlIHlvdSBzaW1wbHkgd2lsbCBuZXZlciBmaW5kIG91 dCB0aGUNCmlkZW50aXR5LCBhbmQgd2hlcmUgeW91IGp1c3QgYXNzdW1lIHRoZSBwcm92aWRlciBj b3VsZCBiZSB0aGUgYXR0YWtlci4NCg0KSSBmZWVsIHRob3NlIHR3byB1c2VyIGNhc2VzIGFyZSBk aWZmZXJlbnQuIFRoZSBmaXJzdCBvbmUsIEkgY291bGQgZGVjaWRlDQpub3QgdG8gdXNlIG15IGxv Y2FsIHN0YXJidWNrcyB3aGVuIGl0IHN0YXJ0cyB0byBmYWlsIHVzaW5nIHRoZSBjaGFpbidzDQpj b25maWd1cmVkIEROUyBzZXJ2ZXIuIFRoZSBzZWNvbmQgY2FzZSBJIGtub3cgSSdtIGdpdmluZyBt eSBwcml2YWN5IHRvDQpzb21lb25lIHdobyBjb3VsZCBiZSBtYWxpY2lvdXMsIGJ1dCBJIHN0aWxs IHByZWZlciB0aGF0IG92ZXIgbm90IHVzaW5nDQp0aGVpciBETlMuIChhbHRob3VnaCBpbiBwcmFj dGlzZSwgbXkgZ3Vlc3MgaXMgYXMgc29vbiBhcyBnb29nbGUgRE5TDQpzdXBwb3J0cyBUTFMsIGV2 ZXJ5b25lIHdpbGwgaGF2ZSBhdCBsZWFzdCBvbmUgU3RyaWN0IHByb2ZpbGUgd2l0aCB0aGVpcg0K a2V5IGFuZCBuZXZlciB1c2UgYW4gb3Bwb3J0dW5pc3RpYyBwcm9maWxlLg0KDQo+PiBUYWtlIHRo ZSBjYXNlIHdoZXJlIHRoZSBETlMgc2VydmVyIGZyb20gREhDUCByZWFsbHkgaXMgbGVnaXRpbWF0 ZS4gVGhlDQo+PiBmYWN0IHRoYXQgdGhlIG1ldGEtcXVlcnkgYW5zd2VyIF9jb3VsZF8gYmUgc3Bv b2ZlZCBwcm92aWRlcyBhIHZlY3Rvcg0KPj4gZm9yIGFuIG9wcG9ydHVuaXN0aWMgY2xpZW50IHRv IGJlIGRpcmVjdGVkIHRvIGFuIGF0dGFja2VycycgRE5TDQo+PiBzZXJ2ZXIuIE5vdGUgdGhhdCB0 aGlzIGF0dGFjayBpcyBub3QgcG9zc2libGUgb24gYSA/bm9ybWFsPyBjbGllbnQNCj4+IHRoYXQg ZGlyZWN0bHkgdXNlcyB0aGUgREhDUCBwcm92aWRlZCBzZXJ2ZXIsIHRoZSBhdHRhY2tlciBoYXMg dG8NCj4+IGF0dGFjayBlYWNoIGluZGl2aWR1YWwgcXVlcnkuIE15IGNvbmNlcm4gaGVyZSBpcyB0 aGF0IHdpdGhvdXQgRE5TU0VDDQo+PiB2YWxpZGF0aW9uIG9mIHRoZSByZS1kaXJlY3QgT3Bwb3J0 dW5pc3RpYyBjbGllbnRzIGhhdmUgYW4gYWRkaXRpb25hbA0KPj4gcmlzayBvZiB0aGlzIGtpbmQg b2YgYXR0YWNrIHRoYW4gP25vcm1hbD8gb25lcy4NCj4NCj4gb2ssIGkgdGhpbmsgaSB1bmRlcnN0 YW5kLiAgVGhlIGNvbmNlcm4gaXMgdGhhdCBhIG5vbi1uZXR3b3JrLWNvbnRyb2xsaW5nDQo+IGF0 dGFja2VyIHdobyBjYW4gc3Bvb2YgRE5TIHJlc3BvbnNlcyBidXQgY2FuJ3Qgc3Bvb2YgREhDUCBy ZXNwb25zZXMgY2FuDQo+IG5vdyB0YWtlIG92ZXIgZnVsbCBETlMgcmVzb2x1dGlvbiBvZiBvcHBv cnR1bmlzdGljIGNsaWVudHMganVzdCBieQ0KPiByYWNpbmcgKGFuZCB3aW5uaW5nKSB0aGUgbGVn aXRpbWF0ZSBtZXRhcXVlcnkgcmVzcG9uc2UuDQoNCkkgdGhpbmsgdGhhdCdzIHJlYWxseSByYXJl IG5vdy4gTW9zdCAic2hhcmVkIHdpZmkiIHNvbHV0aW9ucyBjb25zdHJhaW4gdGhlDQpjbGllbnRz IGFuZCBwcmV2ZW50IHRoZW0gZnJvbSB0YWxraW5nIHRvIGVhY2ggb3RoZXIuIEluIHRoZSBjb2Zm ZWVzaG9wDQp0aGUgY3VzdG9tZXJzIGNhbm5vdCBzZWUgbXkgbGFwdG9wLCBidXQgdGhlIGNvZmZl ZXNob3Agb3duZXIgY2FuLg0KDQpQYXVsDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KTWVzc2FnZTogMg0KRGF0ZTogVHVlLCAzMSBPY3QgMjAxNyAxNTowNjoxNiArMDAw MA0KRnJvbTogU2FyYSBEaWNraW5zb24gPHNhcmFAc2lub2R1bi5jb20+DQpUbzogUGF1bCBXb3V0 ZXJzIDxwYXVsQG5vaGF0cy5jYT4NCkNjOiBEYW5pZWwgS2FobiBHaWxsbW9yIDxka2dAZmlmdGho b3JzZW1hbi5uZXQ+LCBkbnMtcHJpdmFjeUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkbnMtcHJp dmFjeV0gcmV2aWV3IG9mDQogICAgICAgIGRyYWZ0LWlldGYtZHByaXZlLWR0bHMtYW5kLXRscy1w cm9maWxlcy0xMTogd2Ugc2hvdWxkIHJldmVydCBETlNTRUMNCiAgICAgICAgdmFsaWRhdGlvbiBy ZXF1aXJlbWVudA0KTWVzc2FnZS1JRDogPDc3MDlEM0MzLUQ4NzktNDIxQi1CODFBLTc5MDhGNTIx QjlENUBzaW5vZHVuLmNvbT4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD11dGYt OA0KDQpTbyBoZXJlIGlzIGFuIGV4YW1wbGUgb2YgaG93IFN0dWJieSB3b3JrcyB0b2RheS4gSXQg aGFzIHNlcGFyYXRlIHNldHRpbmdzIGZvciBUcmFuc3BvcnRzKFVEUC9UQ1AvVExTKSwgVXNhZ2Ug cHJvZmlsZSBhbmQgRE5TU0VDLiBUaGUgcmVsZXZhbnQgRE5TU0VDIG9wdGlvbnMgYXJlOg0KDQot IGRuc3NlY19yZXR1cm5fc3RhdHVzICAtIGJsb2NrcyBCT0dVUyBhbnN3ZXJzLCByZXR1cm5zIGFs bCBvdGhlcnMgd2l0aCBzdGF0dXMgaW5mb3JtYXRpb24gKHNlY3VyZSB2cyBpbnNlY3VyZSB2cyBp bmRldGVybWluYXRlKQ0KLSBkbnNzZWNfcmV0dXJuX29ubHlfc2VjdXJlICAgLSBkb2VzIHdoYXQg aXMgc2F5cyBvbiB0aGUgdGluDQoNCndoZXJlID9kbnNzZWNfcmV0dXJuX3N0YXR1cz8gaXMgb2J2 aW91c2x5IHdoYXQgd2UgcmVjb21tZW5kIGlmIHlvdSB3YW50IEROU1NFQy4NCg0KSWYgSSBoYXZl IHN0dWJieSBjb25maWd1cmVkIGxpa2UgdGhhdCB0aGVuIGNvbm5lY3RpbmcgdG8gYSBETlMgc2Vy dmVyIHdpdGggYSBCT0dVUyBBIHJlY29yZCBqdXN0IGJlY2F1c2UgST9tIGluIG9wcG9ydHVuaXN0 aWMgcHJpdmFjeSBtb2RlIHNlZW1zIHF1ZXN0aW9uYWJsZS4NCg0KU28gbWF5YmUgP0EgRE5TU0VD IHZhbGlkYXRpbmcgY2xpZW50IFNIT1VMRCBhcHBseSB0aGUgc2FtZSB2YWxpZGF0aW9uIHBvbGlj eSB0byB0aGUgQS9BQUFBIG1ldGEtcXVlcnkgbG9va3VwIGFzIGl0IGRvZXMgdG8gb3RoZXIgcXVl cmllcy4/Pw0KDQpTYXJhLg0KDQo+IE9uIDMwIE9jdCAyMDE3LCBhdCAyMDowNCwgUGF1bCBXb3V0 ZXJzIDxwYXVsQG5vaGF0cy5jYT4gd3JvdGU6DQo+DQo+IE9uIE1vbiwgMzAgT2N0IDIwMTcsIERh bmllbCBLYWhuIEdpbGxtb3Igd3JvdGU6DQo+DQo+PiBEYXRlOiBNb24sIDMwIE9jdCAyMDE3IDEx OjA4OjM1DQo+PiBGcm9tOiBEYW5pZWwgS2FobiBHaWxsbW9yIDxka2dAZmlmdGhob3JzZW1hbi5u ZXQ+DQo+PiBDYzogZG5zLXByaXZhY3lAaWV0Zi5vcmcNCj4+IFRvOiBTYXJhIERpY2tpbnNvbiA8 c2FyYUBzaW5vZHVuLmNvbT4NCj4+IFN1YmplY3Q6IFJlOiBbZG5zLXByaXZhY3ldIHJldmlldyBv Zg0KPj4gICAgZHJhZnQtaWV0Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXByb2ZpbGVzLTExOiB3ZSBz aG91bGQgcmV2ZXJ0IEROU1NFQw0KPj4gICAgdmFsaWRhdGlvbiByZXF1aXJlbWVudA0KPj4gT24g TW9uIDIwMTctMTAtMzAgMTM6MTE6NDEgKzAwMDAsIFNhcmEgRGlja2luc29uIHdyb3RlOg0KPj4+ IEkgcmVhbGx5IGRvIHRoaW5rIGEgZGVzY3JpcHRpb24gdGhlcmUgb2YgdGhlIHRyYWRlLW9mZnMg b2YgRE5TU0VDDQo+Pj4gdmFsaWRhdGlvbiBhcmUgd2FycmFudGVkDQo+Pg0KPj4gSSBhZ3JlZSB0 aGF0IGEgZGlzY3Vzc2lvbiBvZiB0aGUgdHJhZGVvZmZzIGludm9sdmVkIGluIEROU1NFQyB2YWxp ZGF0aW9uDQo+PiBvZiB0aGUgb3Bwb3J0dW5pc3RpYyBtZXRhLXF1ZXJ5IGlzIHdhcnJhbnRlZC4g IEkganVzdCBjb21lIHRvIGENCj4+IGRpZmZlcmVudCBjb25jbHVzaW9uIHRoYW4gdGhlIHJlcXVp cmVtZW50cyBpbiBkcmFmdC0xMS4NCj4NCj4gSWYgYSBjbGllbnQgYWxsb3dzIG11bHRpcGxlIHR5 cGUgb2YgcHJvZmlsZXMsIHRoZW4gRE5TU0VDIG1pZ2h0IG5vdCBiZQ0KPiBuZWVkZWQgdG8gcmVh Y2ggYSBwcmUtY29uZmlndXJlZCBTdHJpY3QgcHJvZmlsZSB3aXRoIGEgdHJ1c3QgYW5jaG9yLg0K PiBUaGVuIHRoZSBkZWNpc2lvbiB0byBiZSBtYWRlIGlzLCBpZiB0aGF0IFN0cmljdCBwcm9maWxl IGlzIHVuYXZhaWxhYmxlLA0KPiBkb2VzIHRoYXQgbWFrZSB0aGUgY3VycmVudCBuZXR3b3JrIGhv c3RpbGUgZW5vdWdoIHRvIG5vdCB1c2UgaXQ/IEFuZCBpZg0KPiBubyBzdHJpY3QgcHJvZmlsZSBp cyBjb25maWd1cmVkLCB3ZWxsIHRoZW4gYW55dGluZyBpcyBiZXR0ZXIgdGhlbg0KPiBub3RoaW5n Lg0KPg0KPj4+IGlmIGl0IGVuZHMgdXAganVzdCBiZWluZyBhIE1BWSAoYWx0aG91Z2ggSSB3b3Vs ZCBsaWtlIHRvIHNlZSBTSE9VTEQgYXMNCj4+PiBhIG1pbmltdW0gZm9yIG9wcG9ydHVuaXN0aWMp Lg0KPj4NCj4+IFNIT1VMRCB2YWxpZGF0ZSwgYnV0IHdpdGggd2hhdCBmYWlsdXJlIG1vZGU/ICBh cmUgd2UgcmVhbGx5IHNheWluZyB0aGF0DQo+PiBvcHBvcnR1bmlzdGljIFNIT1VMRCBkZWxpdmVy IGEgRG9TIGluc3RlYWQgb2YgYSBsb3NzIG9mIHByaXZhY3k/ICBJDQo+PiBkaXNjdXNzIGEgZmV3 IG9wdGlvbmFsIHJlc3BvbnNlcyBmb3IgZmFpbHVyZXMgaW4gb3Bwb3J0dW5pc3RpYyBtb2RlDQo+ PiBiZWxvdy4NCj4NCj4gSWYgdGFsa2luZyBhYm91dCB0aGUgbWV0YSBxdWVyeSwgc2VlIGFib3Zl LiBJZiB0YWxraW5nIGFib3V0IEROU0VTQw0KPiB2YWxpZGF0aW9uIGZvciB0aGUgYWN0dWFsIGNv bnRlbnQgcXVlcmllcywgSSB0aGluayBpdCBzaG91bGQgYmUNCj4gY29uc2lkZXJlZCB0aGF0IGFu eXRoaW5nIG5vdCBwcm9wZXJseSBzdXBwb3J0aW5nIEROU1NFQyBpcyBhbiBhY3RpdmUNCj4gYXR0 YWNrIGFnYWluc3QgdGhlIHVzZXIsIGFuZCBJIHdvdWxkIGJlIG9rYXkgd2l0aCBhIGhhcmQgZmFp bC4NCj4NCj4+IFRoZSBjaGVhcGVzdCBhbmQgc2ltcGxlc3QgaW1wbGVtZW50YXRpb24gaW4gdGVy bXMgb2YgdXNlciBleHBlcmllbmNlIHRvDQo+PiBnZXQgdG8gdmVyaWZpYWJsZSBvcHBvcnR1bmlz dGljIHByb2ZpbGUgKHRoYXQgaXMsIGEgcHJvZmlsZSB0aGF0IGNhbiBhdA0KPj4gbGVhc3QgcmVw b3J0IHRoYXQgRE5TIHByaXZhY3kgaGFzIGJlZW4gYWNoaWV2ZWQsIGV2ZW4gaWYgaXQgd29uJ3Qg YmUNCj4+IGVuZm9yY2VkKSBzZWVtcyB0byBiZToNCj4NCj4gSSB0aG91Z2h0ICJvcHBvcnR1bmlz dGljIiBtZWFudCAiZG8gbm90IHJlcG9ydCB0byB0aGUgdXNlciIgc28gYXMgdG8NCj4gZ3VhcmFu dGVlIHRoYXQgdGhlIHVzZXIgaXMgc3RpbGwgdGhpbmtpbmcgdGhleSBhcmUgaW4gdGhlIHJlYWxt IG9mICJub3QNCj4gcHJpdmF0ZSIgZXZlbiBpZiB0aGVyZSBpcyBlbmNyeXB0aW9uIGhhcHBlbmlu ZywgYmVjYXVzZSB3aXRob3V0IGEgdHJ1c3QNCj4gYW5jaG9yLCB0aGUgdXNlciBjYW5ub3Qga25v dyBpZiB0aGlzIG9wcG9ydHVuaXN0aWMgcGFydHkgaXMgcHJpdmFjeQ0KPiBwcmVzZXJ2aW5nPw0K Pg0KPj4gb3IsIGNvbnZlcnRzIHN1Y2Nlc3MgdG8gZmFpbHVyZSBpbiB0aGUgY2FzZSBvZiBETlNT RUMgbWlzY29uZmlndXJhdGlvbg0KPj4gKGJlY2F1c2UgdGhlIGNvbm5lY3Rpb24gd291bGQgb3Ro ZXJ3aXNlIGhhdmUgc3VjY2VlZGVkKSA6KA0KPg0KPiBBIGRuc3NlYyBmYWlsdXJlIGlzIG5vIGRp ZmZlcmVudCB0aGVuIGEgY2VydGlmaWNhdGUgZmFpbHVyZSwgYW5kDQo+IGJyb3dzZXJzIGFyZSBu b3cgZG9pbmcgc29tZXRoaW5nIHJlYWxseSBjbG9zZSB0byBoYXJkIGZhaWwgb24gdGhvc2Ugbm93 Lg0KPg0KPj4+IEk/ZCBkaXNhZ3JlZSB0aGF0IGNvbm5lY3RpbmcgdG8gYSBzZXJ2ZXIgZm9yIHdo aWNoIHRoZSBtZXRhLXF1ZXJ5DQo+Pj4gcmVzcG9uc2UgZmFpbGVkIEROU1NFQyB2YWxpZGF0aW9u IHJlc3VsdHMgaW4gX2p1c3RfIGEgbG9zcyBvZiBwcml2YWN5DQo+Pj4gZm9yIE9wcG9ydHVuaXN0 aWMgaW4gdGhpcyBjYXNlLiBJZiB0aGUgYW5zd2VyIHdhcyBCT0dVUyB0aGVuIGl0IHNlZW1zDQo+ Pj4gcmVhc29uYWJsZSB0byBhc3N1bWUgdGhlIHNlcnZlciBpcyBub3QgbGVnaXRpbWF0ZSBhbmQg c28gY29ubmVjdGluZw0KPj4+IGFsc28gcmVzdWx0cyBpbiB0aGUgY2xpZW50cycgZW50aXJlIERO UyBzZXJ2aWNlIGJlaW5nIGNvbnRyb2xsZWQgYnkNCj4+PiB0aGUgYXR0YWNrZXIuDQo+DQo+IEkg Z3Vlc3MgSSBzZWUgdHdvIGRpZmZlcmVudCBvcHBvcnR1bmlzdGljIGNhc2VzLiBPbmUgd2hlcmUg eW91IGZpbmQNCj4gYSBETlMgc2VydmVyLCBnZXQgdG8gYW4gSVAgYW5kL29yIHB1YmxpYyBrZXks IHVzZSBETlNTRUMgdG8gY29uZmlybSB0aGUNCj4ga2V5L25hbWUgaW4gdGhlIHB1YmxpYyByZWFs IEROUyAodmlhIHRoYXQgc2VydmVyKSBhbmQgcHJvdGVjdGVkIHdpdGgNCj4gRE5TU0VDLiBGb3Ig aW5zdGFuY2UsIGEgY29mZmVlc2hvcCBjaGFpbiBjb3VsZCBkbyBzbywgYW5kIGlmIGl0IGxpbmtz IHRvDQo+IHNheSBwdWJsaWNkbnMuc3RhcmJ1Y2tzLmNvbSB0aGVuIHlvdSBoYXZlIHNvbWUgY29u ZmlkZW5jZSB0aGVuIHRoZSBsb2NhbA0KPiBpbnN0YW5jZSBvZiB0aGUgY29mZmVlc2hvcCBjYW5u b3Qgc2VlIHlvdXIgdHJhZmZpYy4gQW5kIHRoZW4gdGhlcmUgaXMNCj4gdGhlIG9wcG9ydHVuaXN0 aWMgY2FzZSB3aGVyZSB5b3Ugc2ltcGx5IHdpbGwgbmV2ZXIgZmluZCBvdXQgdGhlDQo+IGlkZW50 aXR5LCBhbmQgd2hlcmUgeW91IGp1c3QgYXNzdW1lIHRoZSBwcm92aWRlciBjb3VsZCBiZSB0aGUg YXR0YWtlci4NCj4NCj4gSSBmZWVsIHRob3NlIHR3byB1c2VyIGNhc2VzIGFyZSBkaWZmZXJlbnQu IFRoZSBmaXJzdCBvbmUsIEkgY291bGQgZGVjaWRlDQo+IG5vdCB0byB1c2UgbXkgbG9jYWwgc3Rh cmJ1Y2tzIHdoZW4gaXQgc3RhcnRzIHRvIGZhaWwgdXNpbmcgdGhlIGNoYWluJ3MNCj4gY29uZmln dXJlZCBETlMgc2VydmVyLiBUaGUgc2Vjb25kIGNhc2UgSSBrbm93IEknbSBnaXZpbmcgbXkgcHJp dmFjeSB0bw0KPiBzb21lb25lIHdobyBjb3VsZCBiZSBtYWxpY2lvdXMsIGJ1dCBJIHN0aWxsIHBy ZWZlciB0aGF0IG92ZXIgbm90IHVzaW5nDQo+IHRoZWlyIEROUy4gKGFsdGhvdWdoIGluIHByYWN0 aXNlLCBteSBndWVzcyBpcyBhcyBzb29uIGFzIGdvb2dsZSBETlMNCj4gc3VwcG9ydHMgVExTLCBl dmVyeW9uZSB3aWxsIGhhdmUgYXQgbGVhc3Qgb25lIFN0cmljdCBwcm9maWxlIHdpdGggdGhlaXIN Cj4ga2V5IGFuZCBuZXZlciB1c2UgYW4gb3Bwb3J0dW5pc3RpYyBwcm9maWxlLg0KPg0KPj4+IFRh a2UgdGhlIGNhc2Ugd2hlcmUgdGhlIEROUyBzZXJ2ZXIgZnJvbSBESENQIHJlYWxseSBpcyBsZWdp dGltYXRlLiBUaGUNCj4+PiBmYWN0IHRoYXQgdGhlIG1ldGEtcXVlcnkgYW5zd2VyIF9jb3VsZF8g YmUgc3Bvb2ZlZCBwcm92aWRlcyBhIHZlY3Rvcg0KPj4+IGZvciBhbiBvcHBvcnR1bmlzdGljIGNs aWVudCB0byBiZSBkaXJlY3RlZCB0byBhbiBhdHRhY2tlcnMnIEROUw0KPj4+IHNlcnZlci4gTm90 ZSB0aGF0IHRoaXMgYXR0YWNrIGlzIG5vdCBwb3NzaWJsZSBvbiBhID9ub3JtYWw/IGNsaWVudA0K Pj4+IHRoYXQgZGlyZWN0bHkgdXNlcyB0aGUgREhDUCBwcm92aWRlZCBzZXJ2ZXIsIHRoZSBhdHRh Y2tlciBoYXMgdG8NCj4+PiBhdHRhY2sgZWFjaCBpbmRpdmlkdWFsIHF1ZXJ5LiBNeSBjb25jZXJu IGhlcmUgaXMgdGhhdCB3aXRob3V0IEROU1NFQw0KPj4+IHZhbGlkYXRpb24gb2YgdGhlIHJlLWRp cmVjdCBPcHBvcnR1bmlzdGljIGNsaWVudHMgaGF2ZSBhbiBhZGRpdGlvbmFsDQo+Pj4gcmlzayBv ZiB0aGlzIGtpbmQgb2YgYXR0YWNrIHRoYW4gP25vcm1hbD8gb25lcy4NCj4+DQo+PiBvaywgaSB0 aGluayBpIHVuZGVyc3RhbmQuICBUaGUgY29uY2VybiBpcyB0aGF0IGEgbm9uLW5ldHdvcmstY29u dHJvbGxpbmcNCj4+IGF0dGFja2VyIHdobyBjYW4gc3Bvb2YgRE5TIHJlc3BvbnNlcyBidXQgY2Fu J3Qgc3Bvb2YgREhDUCByZXNwb25zZXMgY2FuDQo+PiBub3cgdGFrZSBvdmVyIGZ1bGwgRE5TIHJl c29sdXRpb24gb2Ygb3Bwb3J0dW5pc3RpYyBjbGllbnRzIGp1c3QgYnkNCj4+IHJhY2luZyAoYW5k IHdpbm5pbmcpIHRoZSBsZWdpdGltYXRlIG1ldGFxdWVyeSByZXNwb25zZS4NCj4NCj4gSSB0aGlu ayB0aGF0J3MgcmVhbGx5IHJhcmUgbm93LiBNb3N0ICJzaGFyZWQgd2lmaSIgc29sdXRpb25zIGNv bnN0cmFpbiB0aGUNCj4gY2xpZW50cyBhbmQgcHJldmVudCB0aGVtIGZyb20gdGFsa2luZyB0byBl YWNoIG90aGVyLiBJbiB0aGUgY29mZmVlc2hvcA0KPiB0aGUgY3VzdG9tZXJzIGNhbm5vdCBzZWUg bXkgbGFwdG9wLCBidXQgdGhlIGNvZmZlZXNob3Agb3duZXIgY2FuLg0KPg0KPiBQYXVsDQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRucy1w cml2YWN5IG1haWxpbmcgbGlzdA0KPiBkbnMtcHJpdmFjeUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rucy1wcml2YWN5DQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTWVzc2FnZTogMw0KRGF0ZTogVHVlLCAzMSBPY3QgMjAx NyAwODoxMjo0NSAtMDcwMA0KRnJvbTogIlBhdWwgSG9mZm1hbiIgPHBhdWwuaG9mZm1hbkB2cG5j Lm9yZz4NClRvOiAiU2FyYSBEaWNraW5zb24iIDxzYXJhQHNpbm9kdW4uY29tPg0KQ2M6IGRucy1w cml2YWN5QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Rucy1wcml2YWN5XSByZXZpZXcgb2YNCiAg ICAgICAgZHJhZnQtaWV0Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXByb2ZpbGVzLTExOiB3ZSBzaG91 bGQgcmV2ZXJ0IEROU1NFQw0KICAgICAgICB2YWxpZGF0aW9uIHJlcXVpcmVtZW50DQpNZXNzYWdl LUlEOiA8RTRGOUYxNTItQUNDQS00Qzc1LUE2QTQtMDBFMTBCMjAyNUFCQHZwbmMub3JnPg0KQ29u dGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04OyBmb3JtYXQ9Zmxvd2VkDQoNCk9u IDMxIE9jdCAyMDE3LCBhdCA4OjA2LCBTYXJhIERpY2tpbnNvbiB3cm90ZToNCg0KPiBTbyBtYXli ZSA/QSBETlNTRUMgdmFsaWRhdGluZyBjbGllbnQgU0hPVUxEIGFwcGx5IHRoZSBzYW1lDQo+IHZh bGlkYXRpb24gcG9saWN5IHRvIHRoZSBBL0FBQUEgbWV0YS1xdWVyeSBsb29rdXAgYXMgaXQgZG9l cyB0byBvdGhlcg0KPiBxdWVyaWVzLj8/DQoNClRoYXQgY291bGQgYmUgbWlzaW50ZXJwcmV0ZWQg dG8gaW5kaWNhdGUgdGhhdCB0aGVyZSBoYXMgdG8gYmUgc29tZQ0KcG9zaXRpdmUgdmFsaWRhdGlv biBwb2xpY3kuIEhvdyBhYm91dDoNCiAgICBBIEROU1NFQyB2YWxpZGF0aW5nIGNsaWVudCBTSE9V TEQgYXBwbHkgdGhlIHNhbWUgdmFsaWRhdGlvbiBwb2xpY3kNCiAgICB0byB0aGUgQS9BQUFBIG1l dGEtcXVlcnkgbG9va3VwIGFzIGl0IGRvZXMgdG8gb3RoZXIgcXVlcmllcy4NCiAgICBBIGNsaWVu dCB0aGF0IGRvZXMgbm90IHZhbGlkYXRlIEROU1NFQyBTSE9VTEQgYXBwbHkgYW55IHBvbGljeSBp dA0KICAgIGhhcyB0byB0aGUgQS9BQUFBIG1ldGEtcXVlcnkgbG9va3VwLg0KDQotLVBhdWwgSG9m Zm1hbg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk1lc3NhZ2U6IDQN CkRhdGU6IFR1ZSwgMzEgT2N0IDIwMTcgMTg6Mzk6MDMgKzAwMDANCkZyb206IFN0ZXBoZW4gRmFy cmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4NClRvOiBQYXVsIEhvZmZtYW4gPHBhdWwu aG9mZm1hbkB2cG5jLm9yZz4sIFNhcmEgRGlja2luc29uDQogICAgICAgIDxzYXJhQHNpbm9kdW4u Y29tPg0KQ2M6IGRucy1wcml2YWN5QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Rucy1wcml2YWN5 XSByZXZpZXcgb2YNCiAgICAgICAgZHJhZnQtaWV0Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXByb2Zp bGVzLTExOiB3ZSBzaG91bGQgcmV2ZXJ0IEROU1NFQw0KICAgICAgICB2YWxpZGF0aW9uIHJlcXVp cmVtZW50DQpNZXNzYWdlLUlEOiA8ZDA4ODRmMzMtNDI1OC0yNGI1LTdlYWQtNjZhN2M2NGRkNzhh QGNzLnRjZC5pZT4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXRmLTgiDQoN Cg0KSGl5YSwNCg0KT24gMzEvMTAvMTcgMTU6MTIsIFBhdWwgSG9mZm1hbiB3cm90ZToNCj4gT24g MzEgT2N0IDIwMTcsIGF0IDg6MDYsIFNhcmEgRGlja2luc29uIHdyb3RlOg0KPg0KPj4gU28gbWF5 YmUgP0EgRE5TU0VDIHZhbGlkYXRpbmcgY2xpZW50IFNIT1VMRCBhcHBseSB0aGUgc2FtZSB2YWxp ZGF0aW9uDQo+PiBwb2xpY3kgdG8gdGhlIEEvQUFBQSBtZXRhLXF1ZXJ5IGxvb2t1cCBhcyBpdCBk b2VzIHRvIG90aGVyIHF1ZXJpZXMuPz8NCj4NCj4gVGhhdCBjb3VsZCBiZSBtaXNpbnRlcnByZXRl ZCB0byBpbmRpY2F0ZSB0aGF0IHRoZXJlIGhhcyB0byBiZSBzb21lDQo+IHBvc2l0aXZlIHZhbGlk YXRpb24gcG9saWN5LiBIb3cgYWJvdXQ6DQo+ID8/IEEgRE5TU0VDIHZhbGlkYXRpbmcgY2xpZW50 IFNIT1VMRCBhcHBseSB0aGUgc2FtZSB2YWxpZGF0aW9uIHBvbGljeQ0KPiA/PyB0byB0aGUgQS9B QUFBIG1ldGEtcXVlcnkgbG9va3VwIGFzIGl0IGRvZXMgdG8gb3RoZXIgcXVlcmllcy4NCj4gPz8g QSBjbGllbnQgdGhhdCBkb2VzIG5vdCB2YWxpZGF0ZSBETlNTRUMgU0hPVUxEIGFwcGx5IGFueSBw b2xpY3kgaXQNCj4gPz8gaGFzIHRvIHRoZSBBL0FBQUEgbWV0YS1xdWVyeSBsb29rdXAuDQoNClNv IEkgdGhpbmsgZWl0aGVyIG9mIHRoZSBhYm92ZSBjb3VsZCBiZSBvay4NCg0KVGhlIG1haW4gdGhp bmcgZm9yIG1lIGlzIHRoYXQgd2UgZG8gbm90IGluc2lzdCB0aGF0IGEgc2VydmVyDQpoYXMgdG8g Z2V0IEROU1NFQyBzZXR1cCBiZWZvcmUgdGhleSBjYW4gZG8gb3Bwb3J0dW5pc3RpYyBETlMNCnNl Y3VyaXR5LiBJIHRoaW5rIHRoZSBhYm92ZSBpcyBvayBpbiB0aGF0IHJlc3BlY3QuDQoNCkp1c3Qg Y2hlY2tpbmc6IEkgdGhpbmsgdGhhdCBtZWFucyB0aGF0IHdpdGggdGhlIG9wcG9ydHVuaXN0aWMN CnByb2ZpbGUsIG9ubHkgc2VydmVycyB0aGF0IGhhdmUgRE5TU0VDIHNldHVwIGFuZCB3aGVyZSB0 aGUNCmNsaWVudCB2YWxpZGF0ZXMgYW5kIGdldHMgYSBiYWRseSBzaWduZWQgcmVzcG9uc2Ugd291 bGQgYmUNCmFmZmVjdGVkLCBhbGwgb3RoZXIgY2FzZXMgd291bGQgc3RpbGwgZ2V0IEROUyBwcml2 YWN5IG9mIHNvbWUNCnNvcnQuIElmIHRoYXQncyByaWdodCwgSSBjYW4gbGl2ZSB3aXRoIGl0Lg0K DQpDaGVlcnMsDQpTLg0KDQo+DQo+IC0tUGF1bCBIb2ZmbWFuDQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRucy1wcml2YWN5IG1haWxpbmcg bGlzdA0KPiBkbnMtcHJpdmFjeUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Rucy1wcml2YWN5DQoNCi0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0t LS0tLS0tLS0tLQ0KQSBub24tdGV4dCBhdHRhY2htZW50IHdhcyBzY3J1YmJlZC4uLg0KTmFtZTog c2lnbmF0dXJlLmFzYw0KVHlwZTogYXBwbGljYXRpb24vcGdwLXNpZ25hdHVyZQ0KU2l6ZTogNDU1 IGJ5dGVzDQpEZXNjOiBPcGVuUEdQIGRpZ2l0YWwgc2lnbmF0dXJlDQpVUkw6IDxodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL2Rucy1wcml2YWN5L2F0dGFjaG1lbnRzLzIw MTcxMDMxLzRhMmMxODY2L2F0dGFjaG1lbnQuYXNjPg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KU3ViamVjdDogRGlnZXN0IEZvb3Rlcg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG5zLXByaXZhY3kgbWFpbGluZyBsaXN0DQpk bnMtcHJpdmFjeUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kbnMtcHJpdmFjeQ0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpFbmQg b2YgZG5zLXByaXZhY3kgRGlnZXN0LCBWb2wgNDQsIElzc3VlIDE1DQoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQo= --_000_AM5PR0401MB2627BFF9CCA1B819D749A891995E0AM5PR0401MB2627_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2IGlkPSJ4X2NvbXBvc2UtY29udGFpbmVyIiBpdGVt c2NvcGU9IiIgaXRlbXR5cGU9Imh0dHBzOi8vc2NoZW1hLm9yZy9FbWFpbE1lc3NhZ2UiIHN0eWxl PSJkaXJlY3Rpb246bHRyIj4NCjxzcGFuIGl0ZW1wcm9wPSJjcmVhdG9yIiBpdGVtc2NvcGU9IiIg aXRlbXR5cGU9Imh0dHBzOi8vc2NoZW1hLm9yZy9Pcmdhbml6YXRpb24iPjxzcGFuIGl0ZW1wcm9w PSJuYW1lIj48L3NwYW4+PC9zcGFuPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rp b246bHRyIj5EZWFyIGFsbCw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJk aXJlY3Rpb246bHRyIj5BcyBmb3IgdGhlIHNjZW5hcmlvLCBsZXTigJlzIHRhbGsgYWJvdXQgU3Rh cmJ1Y2tzIGVnIDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rp b246bHRyIj5nb29kIG9uZSBieSB0aGUgd2F5LCBJIGxvdmUgU3RhcmJ1Y2tzIC48L2Rpdj4NCjxk aXYgc3R5bGU9ImRpcmVjdGlvbjpsdHIiPkxldOKAmXMgc2F5IEkgYW0gbWVldGluZyB3aXRoIHNv bWVvbmUgdGhhdCB0b3VjaGVkIGJhc2Ugd2l0aCBtZSBzYXlpbmcgaGUgaXMgYSBmYW1pbHkgcmVs YXRpdmUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOmx0 ciI+SGUgdG91Y2hlZCBiYXNlIHdpdGggbWUgc2F5aW5nIEkgYXMgcmVsYXRpdmUgdG8gaGlzIGxh dGUgYXVudCAsIHN1cHBvc2VkbHkgbXkgbW90aGVy4oCZcyBncmFuZG1vdGhlciwgaGlzIGF1bnQg aW4gdGhlIHNhbWUgdGltZSwgdGh1cyBJIHNob3VsZCBzaWduIHNvbWUgcGFwZXJzIGJlY296IEkg ZG8gaW5oZXJpdCBhIHNtYWxsIHBhcnQgb2YgdGhlIGFzc2V0cyAuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOmx0ciI+T3Bwb3J0dW5pc3RpYyBvci4gTm90 LCB3aG8gd291bGQganVzdCBpZ25vcmUgc3VjaCBhIHByb3Bvc2FsLCBhdCBsZWFzdCBmcm9tIHdo YXQgSSBrbm93LCBJIGhlYXJkIG15IG1vbSB0YWxraW5nIG9uY2UgYWJvdXQgdGhlIGxhdGUgZ29u ZSBhbmQgdGhhdCB0aGV5IHdlcmUgcmVhbGx5IGNsb3NlIHJlbGF0aXZlcy48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246bHRyIj5TdXBwb3NlZGx5IGluIHRo aXMgc2NlbmFyaW8sIHdoZXJlICwgaWYgc28sIHdlIGFyZSBhbGwgZmFtaWx5ICwgd2h5IG5vdCB0 byB0b3VjaCBiYXNlIHdpdGggaGltICwgYWxyZWFkeSB0aGUgcGFwZXJzIGhlIGdhdmUgbWUgbWUg YWJvdXQgdGhlIGluaGVyaXRhbmNlLCB3ZXJlIGFscmVhZHkgbm90YXJpemVkLCBhbmQgbWVudGlv bmVkIHRoZSBmYW1pbHkgdHJlZSAsIHZlcnkgY2xlYXIgaW4gdGhlIGhlYWRlci5hcw0KIHByb29m cyBiZWluZy4gUmVsYXRpdmVTICggdGhlIG5vdGFyeSBoYWQgbWVudGlvbmVkIHRoZSBuYW1lIG9m IG15IG1vbSBhbmQgYWNjb3JkaW5nbHkgaGVyIHNpc3RlciAsIHdobyBwYXNzZWQgYXdheSB5ZXN0 ZXJkYXksIHVuZm9ydHVuYXRlIGNvaW5jaWRlbmNlIGluZGVlZC48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246bHRyIj5XaGVuIHdlIHRhbGtlZCwgYXMgcmVs YXRpdmVzICwgbm90aGluZyBuZXcgd2FzIGJyb3VnaHQgdG8gZGlzY3Vzc2lvbiwgSSAsIGFzIGFs d2F5cyBjdXJpb3VzIHRvIGRpc2NvdmVyIGFuZCBEaUdHIG1vcmUgaW4gdGhlIGZhbWlseSB0cmVl ICwgcmVsYXRpdmVzLCBvciAsIE5vdC48L2Rpdj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjpsdHIi PldoZW4gYSB3aGlsZSBhZ28sPC9kaXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246bHRyIj5JIHdh cyBpbnZpdGVkIHRvIGx1bmNoIGluIG15IGV4LXdpZmUgZmFtaWx5IHBhbGFjZSwgbXkgbW9tLCBz byBhdHRhY2hlZCB0byBtYWludGFpbiBvdXIgZmFtaWx5LCB2ZXJ5IHN0cm9uZyByb290cyBjb25j ZXJuaW5nIGp1c3QgZ2F0aGVyaW5nIHRoZSBmYW1pbHkgbWVtYmVycyBvbiBvY2Nhc2lvbnMsIHZl cnkgc3RyaWN0IGNvbmNlcm5pbmcgdGhlIGNvZGUgYW5kIHRoZSBjb25kdWN0LCBzaGUgaXMgdGhl DQogZGF1Z2h0ZXIgb2YgYSBMb3JkLCBhbmQgZXRpcXVldHRlIG1hdHRlcnMgYSBsb3QgZm9yIGhl ciw8L2Rpdj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjpsdHIiPldoZW4gaSB0b29rIG15IGtpZHMg b24gdGhhbmtzZ2l2aW5nIHRvIG15IGV4LXdpZmUgZmFtaWx5IHBhbGFjZSwgKCB0aGV5IGhhdmUg YmVlbiBhIGxvdCBvZiB3ZWRkaW5ncyBhbmQgZGl2b3JjZXMgYmV0d2VlbiBteSBmYW1pbHkgYW5k IG15IGV4LSB3aWZlIGZhbWlseSApPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iZGlyZWN0aW9uOmx0ciI+QnkgdGhlbiAsIG15IG1vbSBib3ljb3R0ZWQgbWUgZm9yIGEgd2hp bGUgYW5kIHRob3VnaHQgSSB3b3VsZCBsZWF2ZSB0aGUga2lkcyBjdXN0b2R5IHRvIG15IGV4LXdp ZmUsIHNvIG11Y2ggYXR0YWNoZWQgYW5kIHN0cmljdCBhYm91dCBrZWVwaW5nIHRoZSBmYW1pbHkg dG9nZXRoZXIuIFNoZSBsYXRlciBrbmV3IHRoYXQgbXkgYm95cyBoYXZlIG91ciBmYW1pbHkgcm9v dHMgaW4gdGhlaXIgRE5BLCAoPw0KIEEgdmVyeSB3ZWxsIGFuY2hvcmVkIGFuY2VzdHJ5KSAtIG5v dGhpbmcgb24gZWFydGggY2FuIGJyZWFrIHRoaXMgbGluayAuIEFuZCBob25lc3RseSBJIGFtIGZl ZCB1cCB3aXRoIG15IG1vbSBjb25jZXJucyBhZnRlciAzMCB5ZWFycyBvZiBiZWluZyBpbiBhIHNp dHVhdGlvbiB3aGVyZSBJIHNob3VsZCBwcm92ZSB0byBoZXIgdGhhdCDigJxpbmRlZWQsIGZvciBz dXJlLCBubyBtYXR0ZXIgd2hhdCwgZXZlbiBpZiB0aGV5IHdpbGwgdGFrZSBteSBzb3Vs4oCdDQog SSB3b3VsZCBuZXZlciBjaGFuZ2UgbXkgZmFtaWx5IG5hbWUgb3IgbXkgYm95cyBmYW1pbHkgbmFt ZS4gQW4gaXNzdWUgbXkgZXggLSB3aWZlIGxhd3llciB1c2VkIGp1c3QgdG8gYmxhY2ttYWlsIG15 IGZhbWlseSAsIGtub3dpbmcgaG93IG11Y2ggd2UgYXJlIGF0dGFjaGVkIGVhY2ggb25lIHRvIHRo ZSBvdGhlci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246 bHRyIj5BbmQgY29uY2VybmluZyBwb2lzb25pbmcgbXkgZHJpbms7IGp1c3QgdGFrZSBhIG1pbnV0 ZSBhbmQgdGhpbmsgc2VyaW91c2x5IG9mIGl0OyBoZSBpcyB0aGUgb3duZXIgb2YgU3RhcmJ1Y2tz ISEhIEhlIGNhbiwgd291bGQsIGNvdWxkLCB3aWxsIG1heWJlIHBvaXNvbiBldmVyeW9uZS4gU28s IHRoaW5raW5nIG9mIGl0LCBjYWxjdWxhdGluZyB0aGUgcmlzayBpJSBoZSBjb3VsZCBoYXZlIHBv aXNvbmVkDQogbXkgZHJpbmsgaXMgdGhlIHNhbWUgJSBhbnlib2R5IG9mIHVzIGNvdWxkIGZhdmUg ZXZlcnkgbW9ybmluZyB3aGVuIGdyYWJiaW5nIGhpcyBjb2ZmZWUuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOmx0ciI+SWYgZWFjaCBvZiB1cyB3aWxsIGtl ZXAgb24gc3VzcGVjdGluZyBlYWNoIG90aGVy4oCZcyAsIHRoYW4gdGhlIHJ1bGUgaXMgZ29ubmEg YmUgdGhlIGV4Y2VwdGlvbiwgYW5kIHRoZSBleGNlcHRpb24gcnVsZSEhIE91ciBiZWxpZWZzLCBw cmluY2lwbGVzICwgb3duIGNvbnZpY3Rpb25zLCBhbmQgc2FtZSB2aXNpb24gaXMgd2hhdCBwdXQg dXMgdG9nZXRoZXIgOyB0cnVlLCB3ZSBoYXZlIHRvIGtlZXAgdGhlDQogY2lyY2xlIOKtle+4jyBh IFsgY2lyY2xlIF0gLCBhbmQgc3RheSBhd2FrZW4gYW5kIGF3YXJlLCBidXQgaWYgaXTigJlzIGdv bm5hIGJlIGFuIGFsbC10aW1lIHRydXN0IGlzc3VlcyBib3VuY2luZyBpbiBhIHRlbm5pcyBwbGF5 Z3JvdW5kOyBpdCB3aWxsIGxpdGVyYWxseSBiZWNvbWUganVzdCBhIOKAnGdhbWXigJ0gb2YgaGlk ZSBhbmQgc2VlaywgaW5zdGVhZCBvZiB0aGUgQ29tbW9uIENvbW11bml0eSBDb21taXRtZW50LCBh IFBlcnBldHVhbCBQaXRjaGluZyBQcm9iYWJpbGl0aWVzOw0KIHRoZW4gLi4uLmxldOKAmXMgZ28g UFBQIFAtUCAoIHBob25ldGljcykgLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImRpcmVjdGlvbjpsdHIiPlRoaXMgaXMgbXkgb3BpbmlvbiwgaSBmb3IgbXlzZWxmIHdhbnQg d2l0aCBwbGVhc3VyZSBkZWRpY2F0aW5nIG15IHRpbWUgdG8gYSBjb21tb24gYmVsaWVmLCBhbmQg YmV0dGVyIGJlIOKAnG9wcG9ydHVuaXN0aWPigJ0gdGhhbiBiZWluZyDigJxTa2VwdGljYWzigJ07 IGFuZCBiZXR0ZXIgdGhhbiB0aG9zZSAyIGlzIHRvIGJlaGF2ZSBsaWtlIHdlIHNob3VsZCwgb25l IGNvbW11bml0eSwgbm90IGxhYmVsaW5nIGFuZA0KIGRvdWJ0aW5nIGVhY2ggb3RoZXJzLjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjpsdHIiPllvdSBjb3Vs ZCBzYXkgd2hhdGV2ZXIgdSB3YW50LCBraWNrIG1lIG9mZiwgYnV0IGhvbmVzdGx5LCBJIGFtIGlu IGZvciBteSBzdHJvbmcgYmVsaWV2ZSBpbiBhIGNvbW1vbiB2aXNpb24uIEFuZCBob3cgdG8gZGV2 ZWxvcCBpdCAsIHJhdGhlciB0aGFuIOKAnGVudmVsb3DigJ0gaXQuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOmx0ciI+R3JlZXRpbmdzLDwvZGl2Pg0KPGRp diBzdHlsZT0iZGlyZWN0aW9uOmx0ciI+QW50b2luZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfYWNvbXBsaV9zaWduYXR1 cmUiPg0KPGRpdj5BbnRvaW5lIEdlcm1hbm9z4oSiPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8aHIgdGFiaW5kZXg9Ii0xIiBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdpZHRo Ojk4JSI+DQo8ZGl2IGlkPSJ4X2RpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJD YWxpYnJpLCBzYW5zLXNlcmlmIiBjb2xvcj0iIzAwMDAwMCIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0 Ij48Yj5Gcm9tOjwvYj4gZG5zLXByaXZhY3kgJmx0O2Rucy1wcml2YWN5LWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IG9uIGJlaGFsZiBvZiBkbnMtcHJpdmFjeS1yZXF1ZXN0QGlldGYub3JnICZsdDtkbnMt cHJpdmFjeS1yZXF1ZXN0QGlldGYub3JnJmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBP Y3RvYmVyIDMxLCAyMDE3IDk6MDA6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IGRucy1wcml2YWN5QGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IGRucy1wcml2YWN5IERpZ2VzdCwgVm9sIDQ0LCBJ c3N1ZSAxNTwvZm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGZvbnQg c2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFp blRleHQiPlNlbmQgZG5zLXByaXZhY3kgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRucy1wcml2YWN5QGll dGYub3JnPGJyPg0KPGJyPg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29y bGQgV2lkZSBXZWIsIHZpc2l0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG5zLXByaXZhY3kiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zLXBy aXZhY3k8L2E+PGJyPg0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0 IG9yIGJvZHkgJ2hlbHAnIHRvPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRucy1wcml2YWN5LXJlcXVlc3RAaWV0Zi5vcmc8YnI+DQo8YnI+DQpZb3UgY2Fu IHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQ8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZG5zLXByaXZhY3ktb3duZXJAaWV0Zi5vcmc8 YnI+DQo8YnI+DQpXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBz byBpdCBpcyBtb3JlIHNwZWNpZmljPGJyPg0KdGhhbiAmcXVvdDtSZTogQ29udGVudHMgb2YgZG5z LXByaXZhY3kgZGlnZXN0Li4uJnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0KVG9kYXkncyBUb3BpY3M6 PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IDEuIFJlOiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kcHJp dmUtZHRscy1hbmQtdGxzLXByb2ZpbGVzLTExOiB3ZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBzaG91bGQgcmV2ZXJ0IEROU1NFQyB2YWxpZGF0aW9uIHJlcXVpcmVtZW50IChQ YXVsIFdvdXRlcnMpPGJyPg0KJm5ic3A7Jm5ic3A7IDIuIFJlOiByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXByb2ZpbGVzLTExOiB3ZTxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBzaG91bGQgcmV2ZXJ0IEROU1NFQyB2YWxpZGF0aW9uIHJlcXVpcmVt ZW50IChTYXJhIERpY2tpbnNvbik8YnI+DQombmJzcDsmbmJzcDsgMy4gUmU6IHJldmlldyBvZiBk cmFmdC1pZXRmLWRwcml2ZS1kdGxzLWFuZC10bHMtcHJvZmlsZXMtMTE6IHdlPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNob3VsZCByZXZlcnQgRE5TU0VDIHZhbGlkYXRpb24g cmVxdWlyZW1lbnQgKFBhdWwgSG9mZm1hbik8YnI+DQombmJzcDsmbmJzcDsgNC4gUmU6IHJldmll dyBvZiBkcmFmdC1pZXRmLWRwcml2ZS1kdGxzLWFuZC10bHMtcHJvZmlsZXMtMTE6IHdlPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNob3VsZCByZXZlcnQgRE5TU0VDIHZhbGlk YXRpb24gcmVxdWlyZW1lbnQgKFN0ZXBoZW4gRmFycmVsbCk8YnI+DQo8YnI+DQo8YnI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KPGJyPg0KTWVzc2FnZTogMTxicj4NCkRhdGU6IE1vbiwgMzAgT2N0IDIw MTcgMTY6MDQ6NTEgLTA0MDAgKEVEVCk8YnI+DQpGcm9tOiBQYXVsIFdvdXRlcnMgJmx0O3BhdWxA bm9oYXRzLmNhJmd0Ozxicj4NClRvOiBEYW5pZWwgS2FobiBHaWxsbW9yICZsdDtka2dAZmlmdGho b3JzZW1hbi5uZXQmZ3Q7PGJyPg0KQ2M6IFNhcmEgRGlja2luc29uICZsdDtzYXJhQHNpbm9kdW4u Y29tJmd0OywgZG5zLXByaXZhY3lAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBSZTogW2Rucy1wcml2 YWN5XSByZXZpZXcgb2Y8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZHJhZnQtaWV0Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXByb2ZpbGVzLTExOiB3ZSBzaG91 bGQgcmV2ZXJ0IEROU1NFQzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB2YWxpZGF0aW9uIHJlcXVpcmVtZW50PGJyPg0KTWVzc2FnZS1JRDogJmx0O2FscGlu ZS5MUkguMi4yMS4xNzEwMzAxNTM5NTAwLjMxMDgyQGJvZmgubm9oYXRzLmNhJmd0Ozxicj4NCkNv bnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD11dGYtODsgZm9ybWF0PWZsb3dlZDxicj4N Cjxicj4NCk9uIE1vbiwgMzAgT2N0IDIwMTcsIERhbmllbCBLYWhuIEdpbGxtb3Igd3JvdGU6PGJy Pg0KPGJyPg0KJmd0OyBEYXRlOiBNb24sIDMwIE9jdCAyMDE3IDExOjA4OjM1PGJyPg0KJmd0OyBG cm9tOiBEYW5pZWwgS2FobiBHaWxsbW9yICZsdDtka2dAZmlmdGhob3JzZW1hbi5uZXQmZ3Q7PGJy Pg0KJmd0OyBDYzogZG5zLXByaXZhY3lAaWV0Zi5vcmc8YnI+DQomZ3Q7IFRvOiBTYXJhIERpY2tp bnNvbiAmbHQ7c2FyYUBzaW5vZHVuLmNvbSZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbZG5z LXByaXZhY3ldIHJldmlldyBvZjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJh ZnQtaWV0Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXByb2ZpbGVzLTExOiB3ZSBzaG91bGQgcmV2ZXJ0 IEROU1NFQzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFsaWRhdGlvbiByZXF1 aXJlbWVudDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBNb24gMjAxNy0xMC0zMCAxMzoxMTo0MSAm IzQzOzAwMDAsIFNhcmEgRGlja2luc29uIHdyb3RlOjxicj4NCiZndDsmZ3Q7IEkgcmVhbGx5IGRv IHRoaW5rIGEgZGVzY3JpcHRpb24gdGhlcmUgb2YgdGhlIHRyYWRlLW9mZnMgb2YgRE5TU0VDPGJy Pg0KJmd0OyZndDsgdmFsaWRhdGlvbiBhcmUgd2FycmFudGVkPGJyPg0KJmd0Ozxicj4NCiZndDsg SSBhZ3JlZSB0aGF0IGEgZGlzY3Vzc2lvbiBvZiB0aGUgdHJhZGVvZmZzIGludm9sdmVkIGluIERO U1NFQyB2YWxpZGF0aW9uPGJyPg0KJmd0OyBvZiB0aGUgb3Bwb3J0dW5pc3RpYyBtZXRhLXF1ZXJ5 IGlzIHdhcnJhbnRlZC4mbmJzcDsgSSBqdXN0IGNvbWUgdG8gYTxicj4NCiZndDsgZGlmZmVyZW50 IGNvbmNsdXNpb24gdGhhbiB0aGUgcmVxdWlyZW1lbnRzIGluIGRyYWZ0LTExLjxicj4NCjxicj4N CklmIGEgY2xpZW50IGFsbG93cyBtdWx0aXBsZSB0eXBlIG9mIHByb2ZpbGVzLCB0aGVuIEROU1NF QyBtaWdodCBub3QgYmU8YnI+DQpuZWVkZWQgdG8gcmVhY2ggYSBwcmUtY29uZmlndXJlZCBTdHJp Y3QgcHJvZmlsZSB3aXRoIGEgdHJ1c3QgYW5jaG9yLjxicj4NClRoZW4gdGhlIGRlY2lzaW9uIHRv IGJlIG1hZGUgaXMsIGlmIHRoYXQgU3RyaWN0IHByb2ZpbGUgaXMgdW5hdmFpbGFibGUsPGJyPg0K ZG9lcyB0aGF0IG1ha2UgdGhlIGN1cnJlbnQgbmV0d29yayBob3N0aWxlIGVub3VnaCB0byBub3Qg dXNlIGl0PyBBbmQgaWY8YnI+DQpubyBzdHJpY3QgcHJvZmlsZSBpcyBjb25maWd1cmVkLCB3ZWxs IHRoZW4gYW55dGluZyBpcyBiZXR0ZXIgdGhlbjxicj4NCm5vdGhpbmcuPGJyPg0KPGJyPg0KJmd0 OyZndDsgaWYgaXQgZW5kcyB1cCBqdXN0IGJlaW5nIGEgTUFZIChhbHRob3VnaCBJIHdvdWxkIGxp a2UgdG8gc2VlIFNIT1VMRCBhczxicj4NCiZndDsmZ3Q7IGEgbWluaW11bSBmb3Igb3Bwb3J0dW5p c3RpYykuPGJyPg0KJmd0Ozxicj4NCiZndDsgU0hPVUxEIHZhbGlkYXRlLCBidXQgd2l0aCB3aGF0 IGZhaWx1cmUgbW9kZT8mbmJzcDsgYXJlIHdlIHJlYWxseSBzYXlpbmcgdGhhdDxicj4NCiZndDsg b3Bwb3J0dW5pc3RpYyBTSE9VTEQgZGVsaXZlciBhIERvUyBpbnN0ZWFkIG9mIGEgbG9zcyBvZiBw cml2YWN5PyZuYnNwOyBJPGJyPg0KJmd0OyBkaXNjdXNzIGEgZmV3IG9wdGlvbmFsIHJlc3BvbnNl cyBmb3IgZmFpbHVyZXMgaW4gb3Bwb3J0dW5pc3RpYyBtb2RlPGJyPg0KJmd0OyBiZWxvdy48YnI+ DQo8YnI+DQpJZiB0YWxraW5nIGFib3V0IHRoZSBtZXRhIHF1ZXJ5LCBzZWUgYWJvdmUuIElmIHRh bGtpbmcgYWJvdXQgRE5TRVNDPGJyPg0KdmFsaWRhdGlvbiBmb3IgdGhlIGFjdHVhbCBjb250ZW50 IHF1ZXJpZXMsIEkgdGhpbmsgaXQgc2hvdWxkIGJlPGJyPg0KY29uc2lkZXJlZCB0aGF0IGFueXRo aW5nIG5vdCBwcm9wZXJseSBzdXBwb3J0aW5nIEROU1NFQyBpcyBhbiBhY3RpdmU8YnI+DQphdHRh Y2sgYWdhaW5zdCB0aGUgdXNlciwgYW5kIEkgd291bGQgYmUgb2theSB3aXRoIGEgaGFyZCBmYWls Ljxicj4NCjxicj4NCiZndDsgVGhlIGNoZWFwZXN0IGFuZCBzaW1wbGVzdCBpbXBsZW1lbnRhdGlv biBpbiB0ZXJtcyBvZiB1c2VyIGV4cGVyaWVuY2UgdG88YnI+DQomZ3Q7IGdldCB0byB2ZXJpZmlh YmxlIG9wcG9ydHVuaXN0aWMgcHJvZmlsZSAodGhhdCBpcywgYSBwcm9maWxlIHRoYXQgY2FuIGF0 PGJyPg0KJmd0OyBsZWFzdCByZXBvcnQgdGhhdCBETlMgcHJpdmFjeSBoYXMgYmVlbiBhY2hpZXZl ZCwgZXZlbiBpZiBpdCB3b24ndCBiZTxicj4NCiZndDsgZW5mb3JjZWQpIHNlZW1zIHRvIGJlOjxi cj4NCjxicj4NCkkgdGhvdWdodCAmcXVvdDtvcHBvcnR1bmlzdGljJnF1b3Q7IG1lYW50ICZxdW90 O2RvIG5vdCByZXBvcnQgdG8gdGhlIHVzZXImcXVvdDsgc28gYXMgdG88YnI+DQpndWFyYW50ZWUg dGhhdCB0aGUgdXNlciBpcyBzdGlsbCB0aGlua2luZyB0aGV5IGFyZSBpbiB0aGUgcmVhbG0gb2Yg JnF1b3Q7bm90PGJyPg0KcHJpdmF0ZSZxdW90OyBldmVuIGlmIHRoZXJlIGlzIGVuY3J5cHRpb24g aGFwcGVuaW5nLCBiZWNhdXNlIHdpdGhvdXQgYSB0cnVzdDxicj4NCmFuY2hvciwgdGhlIHVzZXIg Y2Fubm90IGtub3cgaWYgdGhpcyBvcHBvcnR1bmlzdGljIHBhcnR5IGlzIHByaXZhY3k8YnI+DQpw cmVzZXJ2aW5nPzxicj4NCjxicj4NCiZndDsgb3IsIGNvbnZlcnRzIHN1Y2Nlc3MgdG8gZmFpbHVy ZSBpbiB0aGUgY2FzZSBvZiBETlNTRUMgbWlzY29uZmlndXJhdGlvbjxicj4NCiZndDsgKGJlY2F1 c2UgdGhlIGNvbm5lY3Rpb24gd291bGQgb3RoZXJ3aXNlIGhhdmUgc3VjY2VlZGVkKSA6KDxicj4N Cjxicj4NCkEgZG5zc2VjIGZhaWx1cmUgaXMgbm8gZGlmZmVyZW50IHRoZW4gYSBjZXJ0aWZpY2F0 ZSBmYWlsdXJlLCBhbmQ8YnI+DQpicm93c2VycyBhcmUgbm93IGRvaW5nIHNvbWV0aGluZyByZWFs bHkgY2xvc2UgdG8gaGFyZCBmYWlsIG9uIHRob3NlIG5vdy48YnI+DQo8YnI+DQomZ3Q7Jmd0OyBJ P2QgZGlzYWdyZWUgdGhhdCBjb25uZWN0aW5nIHRvIGEgc2VydmVyIGZvciB3aGljaCB0aGUgbWV0 YS1xdWVyeTxicj4NCiZndDsmZ3Q7IHJlc3BvbnNlIGZhaWxlZCBETlNTRUMgdmFsaWRhdGlvbiBy ZXN1bHRzIGluIF9qdXN0XyBhIGxvc3Mgb2YgcHJpdmFjeTxicj4NCiZndDsmZ3Q7IGZvciBPcHBv cnR1bmlzdGljIGluIHRoaXMgY2FzZS4gSWYgdGhlIGFuc3dlciB3YXMgQk9HVVMgdGhlbiBpdCBz ZWVtczxicj4NCiZndDsmZ3Q7IHJlYXNvbmFibGUgdG8gYXNzdW1lIHRoZSBzZXJ2ZXIgaXMgbm90 IGxlZ2l0aW1hdGUgYW5kIHNvIGNvbm5lY3Rpbmc8YnI+DQomZ3Q7Jmd0OyBhbHNvIHJlc3VsdHMg aW4gdGhlIGNsaWVudHMnIGVudGlyZSBETlMgc2VydmljZSBiZWluZyBjb250cm9sbGVkIGJ5PGJy Pg0KJmd0OyZndDsgdGhlIGF0dGFja2VyLjxicj4NCjxicj4NCkkgZ3Vlc3MgSSBzZWUgdHdvIGRp ZmZlcmVudCBvcHBvcnR1bmlzdGljIGNhc2VzLiBPbmUgd2hlcmUgeW91IGZpbmQ8YnI+DQphIERO UyBzZXJ2ZXIsIGdldCB0byBhbiBJUCBhbmQvb3IgcHVibGljIGtleSwgdXNlIEROU1NFQyB0byBj b25maXJtIHRoZTxicj4NCmtleS9uYW1lIGluIHRoZSBwdWJsaWMgcmVhbCBETlMgKHZpYSB0aGF0 IHNlcnZlcikgYW5kIHByb3RlY3RlZCB3aXRoPGJyPg0KRE5TU0VDLiBGb3IgaW5zdGFuY2UsIGEg Y29mZmVlc2hvcCBjaGFpbiBjb3VsZCBkbyBzbywgYW5kIGlmIGl0IGxpbmtzIHRvPGJyPg0Kc2F5 IHB1YmxpY2Rucy5zdGFyYnVja3MuY29tIHRoZW4geW91IGhhdmUgc29tZSBjb25maWRlbmNlIHRo ZW4gdGhlIGxvY2FsPGJyPg0KaW5zdGFuY2Ugb2YgdGhlIGNvZmZlZXNob3AgY2Fubm90IHNlZSB5 b3VyIHRyYWZmaWMuIEFuZCB0aGVuIHRoZXJlIGlzPGJyPg0KdGhlIG9wcG9ydHVuaXN0aWMgY2Fz ZSB3aGVyZSB5b3Ugc2ltcGx5IHdpbGwgbmV2ZXIgZmluZCBvdXQgdGhlPGJyPg0KaWRlbnRpdHks IGFuZCB3aGVyZSB5b3UganVzdCBhc3N1bWUgdGhlIHByb3ZpZGVyIGNvdWxkIGJlIHRoZSBhdHRh a2VyLjxicj4NCjxicj4NCkkgZmVlbCB0aG9zZSB0d28gdXNlciBjYXNlcyBhcmUgZGlmZmVyZW50 LiBUaGUgZmlyc3Qgb25lLCBJIGNvdWxkIGRlY2lkZTxicj4NCm5vdCB0byB1c2UgbXkgbG9jYWwg c3RhcmJ1Y2tzIHdoZW4gaXQgc3RhcnRzIHRvIGZhaWwgdXNpbmcgdGhlIGNoYWluJ3M8YnI+DQpj b25maWd1cmVkIEROUyBzZXJ2ZXIuIFRoZSBzZWNvbmQgY2FzZSBJIGtub3cgSSdtIGdpdmluZyBt eSBwcml2YWN5IHRvPGJyPg0Kc29tZW9uZSB3aG8gY291bGQgYmUgbWFsaWNpb3VzLCBidXQgSSBz dGlsbCBwcmVmZXIgdGhhdCBvdmVyIG5vdCB1c2luZzxicj4NCnRoZWlyIEROUy4gKGFsdGhvdWdo IGluIHByYWN0aXNlLCBteSBndWVzcyBpcyBhcyBzb29uIGFzIGdvb2dsZSBETlM8YnI+DQpzdXBw b3J0cyBUTFMsIGV2ZXJ5b25lIHdpbGwgaGF2ZSBhdCBsZWFzdCBvbmUgU3RyaWN0IHByb2ZpbGUg d2l0aCB0aGVpcjxicj4NCmtleSBhbmQgbmV2ZXIgdXNlIGFuIG9wcG9ydHVuaXN0aWMgcHJvZmls ZS48YnI+DQo8YnI+DQomZ3Q7Jmd0OyBUYWtlIHRoZSBjYXNlIHdoZXJlIHRoZSBETlMgc2VydmVy IGZyb20gREhDUCByZWFsbHkgaXMgbGVnaXRpbWF0ZS4gVGhlPGJyPg0KJmd0OyZndDsgZmFjdCB0 aGF0IHRoZSBtZXRhLXF1ZXJ5IGFuc3dlciBfY291bGRfIGJlIHNwb29mZWQgcHJvdmlkZXMgYSB2 ZWN0b3I8YnI+DQomZ3Q7Jmd0OyBmb3IgYW4gb3Bwb3J0dW5pc3RpYyBjbGllbnQgdG8gYmUgZGly ZWN0ZWQgdG8gYW4gYXR0YWNrZXJzJyBETlM8YnI+DQomZ3Q7Jmd0OyBzZXJ2ZXIuIE5vdGUgdGhh dCB0aGlzIGF0dGFjayBpcyBub3QgcG9zc2libGUgb24gYSA/bm9ybWFsPyBjbGllbnQ8YnI+DQom Z3Q7Jmd0OyB0aGF0IGRpcmVjdGx5IHVzZXMgdGhlIERIQ1AgcHJvdmlkZWQgc2VydmVyLCB0aGUg YXR0YWNrZXIgaGFzIHRvPGJyPg0KJmd0OyZndDsgYXR0YWNrIGVhY2ggaW5kaXZpZHVhbCBxdWVy eS4gTXkgY29uY2VybiBoZXJlIGlzIHRoYXQgd2l0aG91dCBETlNTRUM8YnI+DQomZ3Q7Jmd0OyB2 YWxpZGF0aW9uIG9mIHRoZSByZS1kaXJlY3QgT3Bwb3J0dW5pc3RpYyBjbGllbnRzIGhhdmUgYW4g YWRkaXRpb25hbDxicj4NCiZndDsmZ3Q7IHJpc2sgb2YgdGhpcyBraW5kIG9mIGF0dGFjayB0aGFu ID9ub3JtYWw/IG9uZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgb2ssIGkgdGhpbmsgaSB1bmRlcnN0 YW5kLiZuYnNwOyBUaGUgY29uY2VybiBpcyB0aGF0IGEgbm9uLW5ldHdvcmstY29udHJvbGxpbmc8 YnI+DQomZ3Q7IGF0dGFja2VyIHdobyBjYW4gc3Bvb2YgRE5TIHJlc3BvbnNlcyBidXQgY2FuJ3Qg c3Bvb2YgREhDUCByZXNwb25zZXMgY2FuPGJyPg0KJmd0OyBub3cgdGFrZSBvdmVyIGZ1bGwgRE5T IHJlc29sdXRpb24gb2Ygb3Bwb3J0dW5pc3RpYyBjbGllbnRzIGp1c3QgYnk8YnI+DQomZ3Q7IHJh Y2luZyAoYW5kIHdpbm5pbmcpIHRoZSBsZWdpdGltYXRlIG1ldGFxdWVyeSByZXNwb25zZS48YnI+ DQo8YnI+DQpJIHRoaW5rIHRoYXQncyByZWFsbHkgcmFyZSBub3cuIE1vc3QgJnF1b3Q7c2hhcmVk IHdpZmkmcXVvdDsgc29sdXRpb25zIGNvbnN0cmFpbiB0aGU8YnI+DQpjbGllbnRzIGFuZCBwcmV2 ZW50IHRoZW0gZnJvbSB0YWxraW5nIHRvIGVhY2ggb3RoZXIuIEluIHRoZSBjb2ZmZWVzaG9wPGJy Pg0KdGhlIGN1c3RvbWVycyBjYW5ub3Qgc2VlIG15IGxhcHRvcCwgYnV0IHRoZSBjb2ZmZWVzaG9w IG93bmVyIGNhbi48YnI+DQo8YnI+DQpQYXVsPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KTWVzc2FnZTogMjxicj4NCkRhdGU6 IFR1ZSwgMzEgT2N0IDIwMTcgMTU6MDY6MTYgJiM0MzswMDAwPGJyPg0KRnJvbTogU2FyYSBEaWNr aW5zb24gJmx0O3NhcmFAc2lub2R1bi5jb20mZ3Q7PGJyPg0KVG86IFBhdWwgV291dGVycyAmbHQ7 cGF1bEBub2hhdHMuY2EmZ3Q7PGJyPg0KQ2M6IERhbmllbCBLYWhuIEdpbGxtb3IgJmx0O2RrZ0Bm aWZ0aGhvcnNlbWFuLm5ldCZndDssIGRucy1wcml2YWN5QGlldGYub3JnPGJyPg0KU3ViamVjdDog UmU6IFtkbnMtcHJpdmFjeV0gcmV2aWV3IG9mPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWlldGYtZHByaXZlLWR0bHMtYW5kLXRscy1wcm9maWxl cy0xMTogd2Ugc2hvdWxkIHJldmVydCBETlNTRUM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFsaWRhdGlvbiByZXF1aXJlbWVudDxicj4NCk1lc3NhZ2Ut SUQ6ICZsdDs3NzA5RDNDMy1EODc5LTQyMUItQjgxQS03OTA4RjUyMUI5RDVAc2lub2R1bi5jb20m Z3Q7PGJyPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04PGJyPg0KPGJy Pg0KU28gaGVyZSBpcyBhbiBleGFtcGxlIG9mIGhvdyBTdHViYnkgd29ya3MgdG9kYXkuIEl0IGhh cyBzZXBhcmF0ZSBzZXR0aW5ncyBmb3IgVHJhbnNwb3J0cyhVRFAvVENQL1RMUyksIFVzYWdlIHBy b2ZpbGUgYW5kIEROU1NFQy4gVGhlIHJlbGV2YW50IEROU1NFQyBvcHRpb25zIGFyZTo8YnI+DQo8 YnI+DQotIGRuc3NlY19yZXR1cm5fc3RhdHVzJm5ic3A7IC0gYmxvY2tzIEJPR1VTIGFuc3dlcnMs IHJldHVybnMgYWxsIG90aGVycyB3aXRoIHN0YXR1cyBpbmZvcm1hdGlvbiAoc2VjdXJlIHZzIGlu c2VjdXJlIHZzIGluZGV0ZXJtaW5hdGUpPGJyPg0KLSBkbnNzZWNfcmV0dXJuX29ubHlfc2VjdXJl Jm5ic3A7Jm5ic3A7IC0gZG9lcyB3aGF0IGlzIHNheXMgb24gdGhlIHRpbjxicj4NCjxicj4NCndo ZXJlID9kbnNzZWNfcmV0dXJuX3N0YXR1cz8gaXMgb2J2aW91c2x5IHdoYXQgd2UgcmVjb21tZW5k IGlmIHlvdSB3YW50IEROU1NFQy4gPGJyPg0KPGJyPg0KSWYgSSBoYXZlIHN0dWJieSBjb25maWd1 cmVkIGxpa2UgdGhhdCB0aGVuIGNvbm5lY3RpbmcgdG8gYSBETlMgc2VydmVyIHdpdGggYSBCT0dV UyBBIHJlY29yZCBqdXN0IGJlY2F1c2UgST9tIGluIG9wcG9ydHVuaXN0aWMgcHJpdmFjeSBtb2Rl IHNlZW1zIHF1ZXN0aW9uYWJsZS4NCjxicj4NCjxicj4NClNvIG1heWJlID9BIEROU1NFQyB2YWxp ZGF0aW5nIGNsaWVudCBTSE9VTEQgYXBwbHkgdGhlIHNhbWUgdmFsaWRhdGlvbiBwb2xpY3kgdG8g dGhlIEEvQUFBQSBtZXRhLXF1ZXJ5IGxvb2t1cCBhcyBpdCBkb2VzIHRvIG90aGVyIHF1ZXJpZXMu Pz88YnI+DQo8YnI+DQpTYXJhLjxicj4NCjxicj4NCiZndDsgT24gMzAgT2N0IDIwMTcsIGF0IDIw OjA0LCBQYXVsIFdvdXRlcnMgJmx0O3BhdWxAbm9oYXRzLmNhJmd0OyB3cm90ZTo8YnI+DQomZ3Q7 IDxicj4NCiZndDsgT24gTW9uLCAzMCBPY3QgMjAxNywgRGFuaWVsIEthaG4gR2lsbG1vciB3cm90 ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IERhdGU6IE1vbiwgMzAgT2N0IDIwMTcgMTE6MDg6 MzU8YnI+DQomZ3Q7Jmd0OyBGcm9tOiBEYW5pZWwgS2FobiBHaWxsbW9yICZsdDtka2dAZmlmdGho b3JzZW1hbi5uZXQmZ3Q7PGJyPg0KJmd0OyZndDsgQ2M6IGRucy1wcml2YWN5QGlldGYub3JnPGJy Pg0KJmd0OyZndDsgVG86IFNhcmEgRGlja2luc29uICZsdDtzYXJhQHNpbm9kdW4uY29tJmd0Ozxi cj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbZG5zLXByaXZhY3ldIHJldmlldyBvZjxicj4NCiZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWlldGYtZHByaXZlLWR0bHMtYW5kLXRscy1w cm9maWxlcy0xMTogd2Ugc2hvdWxkIHJldmVydCBETlNTRUM8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyB2YWxpZGF0aW9uIHJlcXVpcmVtZW50PGJyPg0KJmd0OyZndDsgT24gTW9uIDIw MTctMTAtMzAgMTM6MTE6NDEgJiM0MzswMDAwLCBTYXJhIERpY2tpbnNvbiB3cm90ZTo8YnI+DQom Z3Q7Jmd0OyZndDsgSSByZWFsbHkgZG8gdGhpbmsgYSBkZXNjcmlwdGlvbiB0aGVyZSBvZiB0aGUg dHJhZGUtb2ZmcyBvZiBETlNTRUM8YnI+DQomZ3Q7Jmd0OyZndDsgdmFsaWRhdGlvbiBhcmUgd2Fy cmFudGVkPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSSBhZ3JlZSB0aGF0IGEgZGlzY3Vz c2lvbiBvZiB0aGUgdHJhZGVvZmZzIGludm9sdmVkIGluIEROU1NFQyB2YWxpZGF0aW9uPGJyPg0K Jmd0OyZndDsgb2YgdGhlIG9wcG9ydHVuaXN0aWMgbWV0YS1xdWVyeSBpcyB3YXJyYW50ZWQuJm5i c3A7IEkganVzdCBjb21lIHRvIGE8YnI+DQomZ3Q7Jmd0OyBkaWZmZXJlbnQgY29uY2x1c2lvbiB0 aGFuIHRoZSByZXF1aXJlbWVudHMgaW4gZHJhZnQtMTEuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElm IGEgY2xpZW50IGFsbG93cyBtdWx0aXBsZSB0eXBlIG9mIHByb2ZpbGVzLCB0aGVuIEROU1NFQyBt aWdodCBub3QgYmU8YnI+DQomZ3Q7IG5lZWRlZCB0byByZWFjaCBhIHByZS1jb25maWd1cmVkIFN0 cmljdCBwcm9maWxlIHdpdGggYSB0cnVzdCBhbmNob3IuPGJyPg0KJmd0OyBUaGVuIHRoZSBkZWNp c2lvbiB0byBiZSBtYWRlIGlzLCBpZiB0aGF0IFN0cmljdCBwcm9maWxlIGlzIHVuYXZhaWxhYmxl LDxicj4NCiZndDsgZG9lcyB0aGF0IG1ha2UgdGhlIGN1cnJlbnQgbmV0d29yayBob3N0aWxlIGVu b3VnaCB0byBub3QgdXNlIGl0PyBBbmQgaWY8YnI+DQomZ3Q7IG5vIHN0cmljdCBwcm9maWxlIGlz IGNvbmZpZ3VyZWQsIHdlbGwgdGhlbiBhbnl0aW5nIGlzIGJldHRlciB0aGVuPGJyPg0KJmd0OyBu b3RoaW5nLjxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IGlmIGl0IGVuZHMgdXAganVzdCBi ZWluZyBhIE1BWSAoYWx0aG91Z2ggSSB3b3VsZCBsaWtlIHRvIHNlZSBTSE9VTEQgYXM8YnI+DQom Z3Q7Jmd0OyZndDsgYSBtaW5pbXVtIGZvciBvcHBvcnR1bmlzdGljKS48YnI+DQomZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyBTSE9VTEQgdmFsaWRhdGUsIGJ1dCB3aXRoIHdoYXQgZmFpbHVyZSBtb2Rl PyZuYnNwOyBhcmUgd2UgcmVhbGx5IHNheWluZyB0aGF0PGJyPg0KJmd0OyZndDsgb3Bwb3J0dW5p c3RpYyBTSE9VTEQgZGVsaXZlciBhIERvUyBpbnN0ZWFkIG9mIGEgbG9zcyBvZiBwcml2YWN5PyZu YnNwOyBJPGJyPg0KJmd0OyZndDsgZGlzY3VzcyBhIGZldyBvcHRpb25hbCByZXNwb25zZXMgZm9y IGZhaWx1cmVzIGluIG9wcG9ydHVuaXN0aWMgbW9kZTxicj4NCiZndDsmZ3Q7IGJlbG93Ljxicj4N CiZndDsgPGJyPg0KJmd0OyBJZiB0YWxraW5nIGFib3V0IHRoZSBtZXRhIHF1ZXJ5LCBzZWUgYWJv dmUuIElmIHRhbGtpbmcgYWJvdXQgRE5TRVNDPGJyPg0KJmd0OyB2YWxpZGF0aW9uIGZvciB0aGUg YWN0dWFsIGNvbnRlbnQgcXVlcmllcywgSSB0aGluayBpdCBzaG91bGQgYmU8YnI+DQomZ3Q7IGNv bnNpZGVyZWQgdGhhdCBhbnl0aGluZyBub3QgcHJvcGVybHkgc3VwcG9ydGluZyBETlNTRUMgaXMg YW4gYWN0aXZlPGJyPg0KJmd0OyBhdHRhY2sgYWdhaW5zdCB0aGUgdXNlciwgYW5kIEkgd291bGQg YmUgb2theSB3aXRoIGEgaGFyZCBmYWlsLjxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgVGhlIGNo ZWFwZXN0IGFuZCBzaW1wbGVzdCBpbXBsZW1lbnRhdGlvbiBpbiB0ZXJtcyBvZiB1c2VyIGV4cGVy aWVuY2UgdG88YnI+DQomZ3Q7Jmd0OyBnZXQgdG8gdmVyaWZpYWJsZSBvcHBvcnR1bmlzdGljIHBy b2ZpbGUgKHRoYXQgaXMsIGEgcHJvZmlsZSB0aGF0IGNhbiBhdDxicj4NCiZndDsmZ3Q7IGxlYXN0 IHJlcG9ydCB0aGF0IEROUyBwcml2YWN5IGhhcyBiZWVuIGFjaGlldmVkLCBldmVuIGlmIGl0IHdv bid0IGJlPGJyPg0KJmd0OyZndDsgZW5mb3JjZWQpIHNlZW1zIHRvIGJlOjxicj4NCiZndDsgPGJy Pg0KJmd0OyBJIHRob3VnaHQgJnF1b3Q7b3Bwb3J0dW5pc3RpYyZxdW90OyBtZWFudCAmcXVvdDtk byBub3QgcmVwb3J0IHRvIHRoZSB1c2VyJnF1b3Q7IHNvIGFzIHRvPGJyPg0KJmd0OyBndWFyYW50 ZWUgdGhhdCB0aGUgdXNlciBpcyBzdGlsbCB0aGlua2luZyB0aGV5IGFyZSBpbiB0aGUgcmVhbG0g b2YgJnF1b3Q7bm90PGJyPg0KJmd0OyBwcml2YXRlJnF1b3Q7IGV2ZW4gaWYgdGhlcmUgaXMgZW5j cnlwdGlvbiBoYXBwZW5pbmcsIGJlY2F1c2Ugd2l0aG91dCBhIHRydXN0PGJyPg0KJmd0OyBhbmNo b3IsIHRoZSB1c2VyIGNhbm5vdCBrbm93IGlmIHRoaXMgb3Bwb3J0dW5pc3RpYyBwYXJ0eSBpcyBw cml2YWN5PGJyPg0KJmd0OyBwcmVzZXJ2aW5nPzxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgb3Is IGNvbnZlcnRzIHN1Y2Nlc3MgdG8gZmFpbHVyZSBpbiB0aGUgY2FzZSBvZiBETlNTRUMgbWlzY29u ZmlndXJhdGlvbjxicj4NCiZndDsmZ3Q7IChiZWNhdXNlIHRoZSBjb25uZWN0aW9uIHdvdWxkIG90 aGVyd2lzZSBoYXZlIHN1Y2NlZWRlZCkgOig8YnI+DQomZ3Q7IDxicj4NCiZndDsgQSBkbnNzZWMg ZmFpbHVyZSBpcyBubyBkaWZmZXJlbnQgdGhlbiBhIGNlcnRpZmljYXRlIGZhaWx1cmUsIGFuZDxi cj4NCiZndDsgYnJvd3NlcnMgYXJlIG5vdyBkb2luZyBzb21ldGhpbmcgcmVhbGx5IGNsb3NlIHRv IGhhcmQgZmFpbCBvbiB0aG9zZSBub3cuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgST9k IGRpc2FncmVlIHRoYXQgY29ubmVjdGluZyB0byBhIHNlcnZlciBmb3Igd2hpY2ggdGhlIG1ldGEt cXVlcnk8YnI+DQomZ3Q7Jmd0OyZndDsgcmVzcG9uc2UgZmFpbGVkIEROU1NFQyB2YWxpZGF0aW9u IHJlc3VsdHMgaW4gX2p1c3RfIGEgbG9zcyBvZiBwcml2YWN5PGJyPg0KJmd0OyZndDsmZ3Q7IGZv ciBPcHBvcnR1bmlzdGljIGluIHRoaXMgY2FzZS4gSWYgdGhlIGFuc3dlciB3YXMgQk9HVVMgdGhl biBpdCBzZWVtczxicj4NCiZndDsmZ3Q7Jmd0OyByZWFzb25hYmxlIHRvIGFzc3VtZSB0aGUgc2Vy dmVyIGlzIG5vdCBsZWdpdGltYXRlIGFuZCBzbyBjb25uZWN0aW5nPGJyPg0KJmd0OyZndDsmZ3Q7 IGFsc28gcmVzdWx0cyBpbiB0aGUgY2xpZW50cycgZW50aXJlIEROUyBzZXJ2aWNlIGJlaW5nIGNv bnRyb2xsZWQgYnk8YnI+DQomZ3Q7Jmd0OyZndDsgdGhlIGF0dGFja2VyLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBJIGd1ZXNzIEkgc2VlIHR3byBkaWZmZXJlbnQgb3Bwb3J0dW5pc3RpYyBjYXNlcy4g T25lIHdoZXJlIHlvdSBmaW5kPGJyPg0KJmd0OyBhIEROUyBzZXJ2ZXIsIGdldCB0byBhbiBJUCBh bmQvb3IgcHVibGljIGtleSwgdXNlIEROU1NFQyB0byBjb25maXJtIHRoZTxicj4NCiZndDsga2V5 L25hbWUgaW4gdGhlIHB1YmxpYyByZWFsIEROUyAodmlhIHRoYXQgc2VydmVyKSBhbmQgcHJvdGVj dGVkIHdpdGg8YnI+DQomZ3Q7IEROU1NFQy4gRm9yIGluc3RhbmNlLCBhIGNvZmZlZXNob3AgY2hh aW4gY291bGQgZG8gc28sIGFuZCBpZiBpdCBsaW5rcyB0bzxicj4NCiZndDsgc2F5IHB1YmxpY2Ru cy5zdGFyYnVja3MuY29tIHRoZW4geW91IGhhdmUgc29tZSBjb25maWRlbmNlIHRoZW4gdGhlIGxv Y2FsPGJyPg0KJmd0OyBpbnN0YW5jZSBvZiB0aGUgY29mZmVlc2hvcCBjYW5ub3Qgc2VlIHlvdXIg dHJhZmZpYy4gQW5kIHRoZW4gdGhlcmUgaXM8YnI+DQomZ3Q7IHRoZSBvcHBvcnR1bmlzdGljIGNh c2Ugd2hlcmUgeW91IHNpbXBseSB3aWxsIG5ldmVyIGZpbmQgb3V0IHRoZTxicj4NCiZndDsgaWRl bnRpdHksIGFuZCB3aGVyZSB5b3UganVzdCBhc3N1bWUgdGhlIHByb3ZpZGVyIGNvdWxkIGJlIHRo ZSBhdHRha2VyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGZlZWwgdGhvc2UgdHdvIHVzZXIgY2Fz ZXMgYXJlIGRpZmZlcmVudC4gVGhlIGZpcnN0IG9uZSwgSSBjb3VsZCBkZWNpZGU8YnI+DQomZ3Q7 IG5vdCB0byB1c2UgbXkgbG9jYWwgc3RhcmJ1Y2tzIHdoZW4gaXQgc3RhcnRzIHRvIGZhaWwgdXNp bmcgdGhlIGNoYWluJ3M8YnI+DQomZ3Q7IGNvbmZpZ3VyZWQgRE5TIHNlcnZlci4gVGhlIHNlY29u ZCBjYXNlIEkga25vdyBJJ20gZ2l2aW5nIG15IHByaXZhY3kgdG88YnI+DQomZ3Q7IHNvbWVvbmUg d2hvIGNvdWxkIGJlIG1hbGljaW91cywgYnV0IEkgc3RpbGwgcHJlZmVyIHRoYXQgb3ZlciBub3Qg dXNpbmc8YnI+DQomZ3Q7IHRoZWlyIEROUy4gKGFsdGhvdWdoIGluIHByYWN0aXNlLCBteSBndWVz cyBpcyBhcyBzb29uIGFzIGdvb2dsZSBETlM8YnI+DQomZ3Q7IHN1cHBvcnRzIFRMUywgZXZlcnlv bmUgd2lsbCBoYXZlIGF0IGxlYXN0IG9uZSBTdHJpY3QgcHJvZmlsZSB3aXRoIHRoZWlyPGJyPg0K Jmd0OyBrZXkgYW5kIG5ldmVyIHVzZSBhbiBvcHBvcnR1bmlzdGljIHByb2ZpbGUuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7Jmd0OyZndDsgVGFrZSB0aGUgY2FzZSB3aGVyZSB0aGUgRE5TIHNlcnZlciBm cm9tIERIQ1AgcmVhbGx5IGlzIGxlZ2l0aW1hdGUuIFRoZTxicj4NCiZndDsmZ3Q7Jmd0OyBmYWN0 IHRoYXQgdGhlIG1ldGEtcXVlcnkgYW5zd2VyIF9jb3VsZF8gYmUgc3Bvb2ZlZCBwcm92aWRlcyBh IHZlY3Rvcjxicj4NCiZndDsmZ3Q7Jmd0OyBmb3IgYW4gb3Bwb3J0dW5pc3RpYyBjbGllbnQgdG8g YmUgZGlyZWN0ZWQgdG8gYW4gYXR0YWNrZXJzJyBETlM8YnI+DQomZ3Q7Jmd0OyZndDsgc2VydmVy LiBOb3RlIHRoYXQgdGhpcyBhdHRhY2sgaXMgbm90IHBvc3NpYmxlIG9uIGEgP25vcm1hbD8gY2xp ZW50PGJyPg0KJmd0OyZndDsmZ3Q7IHRoYXQgZGlyZWN0bHkgdXNlcyB0aGUgREhDUCBwcm92aWRl ZCBzZXJ2ZXIsIHRoZSBhdHRhY2tlciBoYXMgdG88YnI+DQomZ3Q7Jmd0OyZndDsgYXR0YWNrIGVh Y2ggaW5kaXZpZHVhbCBxdWVyeS4gTXkgY29uY2VybiBoZXJlIGlzIHRoYXQgd2l0aG91dCBETlNT RUM8YnI+DQomZ3Q7Jmd0OyZndDsgdmFsaWRhdGlvbiBvZiB0aGUgcmUtZGlyZWN0IE9wcG9ydHVu aXN0aWMgY2xpZW50cyBoYXZlIGFuIGFkZGl0aW9uYWw8YnI+DQomZ3Q7Jmd0OyZndDsgcmlzayBv ZiB0aGlzIGtpbmQgb2YgYXR0YWNrIHRoYW4gP25vcm1hbD8gb25lcy48YnI+DQomZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyBvaywgaSB0aGluayBpIHVuZGVyc3RhbmQuJm5ic3A7IFRoZSBjb25jZXJu IGlzIHRoYXQgYSBub24tbmV0d29yay1jb250cm9sbGluZzxicj4NCiZndDsmZ3Q7IGF0dGFja2Vy IHdobyBjYW4gc3Bvb2YgRE5TIHJlc3BvbnNlcyBidXQgY2FuJ3Qgc3Bvb2YgREhDUCByZXNwb25z ZXMgY2FuPGJyPg0KJmd0OyZndDsgbm93IHRha2Ugb3ZlciBmdWxsIEROUyByZXNvbHV0aW9uIG9m IG9wcG9ydHVuaXN0aWMgY2xpZW50cyBqdXN0IGJ5PGJyPg0KJmd0OyZndDsgcmFjaW5nIChhbmQg d2lubmluZykgdGhlIGxlZ2l0aW1hdGUgbWV0YXF1ZXJ5IHJlc3BvbnNlLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBJIHRoaW5rIHRoYXQncyByZWFsbHkgcmFyZSBub3cuIE1vc3QgJnF1b3Q7c2hhcmVk IHdpZmkmcXVvdDsgc29sdXRpb25zIGNvbnN0cmFpbiB0aGU8YnI+DQomZ3Q7IGNsaWVudHMgYW5k IHByZXZlbnQgdGhlbSBmcm9tIHRhbGtpbmcgdG8gZWFjaCBvdGhlci4gSW4gdGhlIGNvZmZlZXNo b3A8YnI+DQomZ3Q7IHRoZSBjdXN0b21lcnMgY2Fubm90IHNlZSBteSBsYXB0b3AsIGJ1dCB0aGUg Y29mZmVlc2hvcCBvd25lciBjYW4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFBhdWw8YnI+DQomZ3Q7 IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7IGRucy1wcml2YWN5IG1haWxpbmcgbGlzdDxicj4NCiZndDsgZG5zLXByaXZh Y3lAaWV0Zi5vcmc8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG5zLXByaXZhY3kiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG5zLXByaXZhY3k8L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KTWVzc2FnZTogMzxicj4NCkRhdGU6IFR1ZSwg MzEgT2N0IDIwMTcgMDg6MTI6NDUgLTA3MDA8YnI+DQpGcm9tOiAmcXVvdDtQYXVsIEhvZmZtYW4m cXVvdDsgJmx0O3BhdWwuaG9mZm1hbkB2cG5jLm9yZyZndDs8YnI+DQpUbzogJnF1b3Q7U2FyYSBE aWNraW5zb24mcXVvdDsgJmx0O3NhcmFAc2lub2R1bi5jb20mZ3Q7PGJyPg0KQ2M6IGRucy1wcml2 YWN5QGlldGYub3JnPGJyPg0KU3ViamVjdDogUmU6IFtkbnMtcHJpdmFjeV0gcmV2aWV3IG9mPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWlldGYt ZHByaXZlLWR0bHMtYW5kLXRscy1wcm9maWxlcy0xMTogd2Ugc2hvdWxkIHJldmVydCBETlNTRUM8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFsaWRhdGlv biByZXF1aXJlbWVudDxicj4NCk1lc3NhZ2UtSUQ6ICZsdDtFNEY5RjE1Mi1BQ0NBLTRDNzUtQTZB NC0wMEUxMEIyMDI1QUJAdnBuYy5vcmcmZ3Q7PGJyPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWlu OyBjaGFyc2V0PXV0Zi04OyBmb3JtYXQ9Zmxvd2VkPGJyPg0KPGJyPg0KT24gMzEgT2N0IDIwMTcs IGF0IDg6MDYsIFNhcmEgRGlja2luc29uIHdyb3RlOjxicj4NCjxicj4NCiZndDsgU28gbWF5YmUg P0EgRE5TU0VDIHZhbGlkYXRpbmcgY2xpZW50IFNIT1VMRCBhcHBseSB0aGUgc2FtZSA8YnI+DQom Z3Q7IHZhbGlkYXRpb24gcG9saWN5IHRvIHRoZSBBL0FBQUEgbWV0YS1xdWVyeSBsb29rdXAgYXMg aXQgZG9lcyB0byBvdGhlciA8YnI+DQomZ3Q7IHF1ZXJpZXMuPz88YnI+DQo8YnI+DQpUaGF0IGNv dWxkIGJlIG1pc2ludGVycHJldGVkIHRvIGluZGljYXRlIHRoYXQgdGhlcmUgaGFzIHRvIGJlIHNv bWUgPGJyPg0KcG9zaXRpdmUgdmFsaWRhdGlvbiBwb2xpY3kuIEhvdyBhYm91dDo8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgQSBETlNTRUMgdmFsaWRhdGluZyBjbGllbnQgU0hPVUxEIGFwcGx5IHRo ZSBzYW1lIHZhbGlkYXRpb24gcG9saWN5PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIHRoZSBB L0FBQUEgbWV0YS1xdWVyeSBsb29rdXAgYXMgaXQgZG9lcyB0byBvdGhlciBxdWVyaWVzLjxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyBBIGNsaWVudCB0aGF0IGRvZXMgbm90IHZhbGlkYXRlIEROU1NF QyBTSE9VTEQgYXBwbHkgYW55IHBvbGljeSBpdDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBoYXMg dG8gdGhlIEEvQUFBQSBtZXRhLXF1ZXJ5IGxvb2t1cC48YnI+DQo8YnI+DQotLVBhdWwgSG9mZm1h bjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCjxicj4NCk1lc3NhZ2U6IDQ8YnI+DQpEYXRlOiBUdWUsIDMxIE9jdCAyMDE3IDE4OjM5OjAz ICYjNDM7MDAwMDxicj4NCkZyb206IFN0ZXBoZW4gRmFycmVsbCAmbHQ7c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZSZndDs8YnI+DQpUbzogUGF1bCBIb2ZmbWFuICZsdDtwYXVsLmhvZmZtYW5AdnBu Yy5vcmcmZ3Q7LCBTYXJhIERpY2tpbnNvbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7c2FyYUBzaW5vZHVuLmNvbSZndDs8YnI+DQpDYzogZG5zLXBy aXZhY3lAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBSZTogW2Rucy1wcml2YWN5XSByZXZpZXcgb2Y8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0 Zi1kcHJpdmUtZHRscy1hbmQtdGxzLXByb2ZpbGVzLTExOiB3ZSBzaG91bGQgcmV2ZXJ0IEROU1NF Qzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWxpZGF0 aW9uIHJlcXVpcmVtZW50PGJyPg0KTWVzc2FnZS1JRDogJmx0O2QwODg0ZjMzLTQyNTgtMjRiNS03 ZWFkLTY2YTdjNjRkZDc4YUBjcy50Y2QuaWUmZ3Q7PGJyPg0KQ29udGVudC1UeXBlOiB0ZXh0L3Bs YWluOyBjaGFyc2V0PSZxdW90O3V0Zi04JnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0KSGl5YSw8YnI+ DQo8YnI+DQpPbiAzMS8xMC8xNyAxNToxMiwgUGF1bCBIb2ZmbWFuIHdyb3RlOjxicj4NCiZndDsg T24gMzEgT2N0IDIwMTcsIGF0IDg6MDYsIFNhcmEgRGlja2luc29uIHdyb3RlOjxicj4NCiZndDsg PGJyPg0KJmd0OyZndDsgU28gbWF5YmUgP0EgRE5TU0VDIHZhbGlkYXRpbmcgY2xpZW50IFNIT1VM RCBhcHBseSB0aGUgc2FtZSB2YWxpZGF0aW9uPGJyPg0KJmd0OyZndDsgcG9saWN5IHRvIHRoZSBB L0FBQUEgbWV0YS1xdWVyeSBsb29rdXAgYXMgaXQgZG9lcyB0byBvdGhlciBxdWVyaWVzLj8/PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFRoYXQgY291bGQgYmUgbWlzaW50ZXJwcmV0ZWQgdG8gaW5kaWNh dGUgdGhhdCB0aGVyZSBoYXMgdG8gYmUgc29tZTxicj4NCiZndDsgcG9zaXRpdmUgdmFsaWRhdGlv biBwb2xpY3kuIEhvdyBhYm91dDo8YnI+DQomZ3Q7ID8/IEEgRE5TU0VDIHZhbGlkYXRpbmcgY2xp ZW50IFNIT1VMRCBhcHBseSB0aGUgc2FtZSB2YWxpZGF0aW9uIHBvbGljeTxicj4NCiZndDsgPz8g dG8gdGhlIEEvQUFBQSBtZXRhLXF1ZXJ5IGxvb2t1cCBhcyBpdCBkb2VzIHRvIG90aGVyIHF1ZXJp ZXMuPGJyPg0KJmd0OyA/PyBBIGNsaWVudCB0aGF0IGRvZXMgbm90IHZhbGlkYXRlIEROU1NFQyBT SE9VTEQgYXBwbHkgYW55IHBvbGljeSBpdDxicj4NCiZndDsgPz8gaGFzIHRvIHRoZSBBL0FBQUEg bWV0YS1xdWVyeSBsb29rdXAuPGJyPg0KPGJyPg0KU28gSSB0aGluayBlaXRoZXIgb2YgdGhlIGFi b3ZlIGNvdWxkIGJlIG9rLjxicj4NCjxicj4NClRoZSBtYWluIHRoaW5nIGZvciBtZSBpcyB0aGF0 IHdlIGRvIG5vdCBpbnNpc3QgdGhhdCBhIHNlcnZlcjxicj4NCmhhcyB0byBnZXQgRE5TU0VDIHNl dHVwIGJlZm9yZSB0aGV5IGNhbiBkbyBvcHBvcnR1bmlzdGljIEROUzxicj4NCnNlY3VyaXR5LiBJ IHRoaW5rIHRoZSBhYm92ZSBpcyBvayBpbiB0aGF0IHJlc3BlY3QuPGJyPg0KPGJyPg0KSnVzdCBj aGVja2luZzogSSB0aGluayB0aGF0IG1lYW5zIHRoYXQgd2l0aCB0aGUgb3Bwb3J0dW5pc3RpYzxi cj4NCnByb2ZpbGUsIG9ubHkgc2VydmVycyB0aGF0IGhhdmUgRE5TU0VDIHNldHVwIGFuZCB3aGVy ZSB0aGU8YnI+DQpjbGllbnQgdmFsaWRhdGVzIGFuZCBnZXRzIGEgYmFkbHkgc2lnbmVkIHJlc3Bv bnNlIHdvdWxkIGJlPGJyPg0KYWZmZWN0ZWQsIGFsbCBvdGhlciBjYXNlcyB3b3VsZCBzdGlsbCBn ZXQgRE5TIHByaXZhY3kgb2Ygc29tZTxicj4NCnNvcnQuIElmIHRoYXQncyByaWdodCwgSSBjYW4g bGl2ZSB3aXRoIGl0Ljxicj4NCjxicj4NCkNoZWVycyw8YnI+DQpTLjxicj4NCjxicj4NCiZndDsg PGJyPg0KJmd0OyAtLVBhdWwgSG9mZm1hbjxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgZG5zLXByaXZh Y3kgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBkbnMtcHJpdmFjeUBpZXRmLm9yZzxicj4NCiZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnMtcHJpdmFj eSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnMtcHJpdmFjeTwvYT48 YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS08YnI+DQpB IG5vbi10ZXh0IGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4uPGJyPg0KTmFtZTogc2lnbmF0dXJl LmFzYzxicj4NClR5cGU6IGFwcGxpY2F0aW9uL3BncC1zaWduYXR1cmU8YnI+DQpTaXplOiA0NTUg Ynl0ZXM8YnI+DQpEZXNjOiBPcGVuUEdQIGRpZ2l0YWwgc2lnbmF0dXJlPGJyPg0KVVJMOiAmbHQ7 PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9kbnMtcHJp dmFjeS9hdHRhY2htZW50cy8yMDE3MTAzMS80YTJjMTg2Ni9hdHRhY2htZW50LmFzYyI+aHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9kbnMtcHJpdmFjeS9hdHRhY2htZW50 cy8yMDE3MTAzMS80YTJjMTg2Ni9hdHRhY2htZW50LmFzYzwvYT4mZ3Q7PGJyPg0KPGJyPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KU3ViamVjdDogRGlnZXN0IEZv b3Rlcjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KZG5zLXByaXZhY3kgbWFpbGluZyBsaXN0PGJyPg0KZG5zLXByaXZhY3lAaWV0 Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Rucy1wcml2YWN5Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rucy1w cml2YWN5PC9hPjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCjxicj4NCkVuZCBvZiBkbnMtcHJpdmFjeSBEaWdlc3QsIFZvbCA0NCwgSXNzdWUgMTU8 YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KPC9k aXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM5PR0401MB2627BFF9CCA1B819D749A891995E0AM5PR0401MB2627_--