From nobody Mon Jun 1 03:22:54 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081DC3A0F06 for ; Mon, 1 Jun 2020 03:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 6bSUkMkNo5vK for ; Mon, 1 Jun 2020 03:22:50 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 31EAB3A0F02 for ; Mon, 1 Jun 2020 03:22:50 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id c3so10858733wru.12 for ; Mon, 01 Jun 2020 03:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JvIB9HV2kUDeB6axUI62hikM2F+eLVdI06XOIlVc84c=; b=vMp1LlqA1V6WAReZR5PUPMXUbeOrpks5rLVHrPMquvTh7I381+7ikd58UljVP4kOE8 BHJ8ukPuJgNL/iR/+qCkq2bvrtpRX/i/P74V8YJUK/Sv+plYxn317NaRBxJn5Wsy+MAH OAXLdMi/pM3I7nmx2BL8YL4I+8HGsfqqEJPtfE12Zq2iZMLtCN3wLFdSO0pgOQTj5RT8 qxnYG59FNsQBkhCep6PcJVnoQVnHMlDtDJyhxQi5RdZ1oore+76FNFCm1X+shdYKmnHb xcFBlOJEqWo27mfG/X6ZXYslY5NEMv0y0452eIxwAzuMfEGlXbb5cV+ZrsZIPv1wCwVh Zhag== 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:to:cc; bh=JvIB9HV2kUDeB6axUI62hikM2F+eLVdI06XOIlVc84c=; b=HqEl6F1VJ6qvYkLP5WgWB1+guw06fGmOB1QZpOhIA39n/3nYXGUbqxsve7LRIUZtix +5zvtx3ScxYeLSELUgL9TMpSUZRa0vaaAH6T0X4U08+40zi3k53lG/Oqve0L3s8llCQH NreNkQ32KsFNDx3WRWoGMT1eg66pyzEXgS1TUS1D4jaRORzvg+MuXG1pm19s1OPyg0iW juqcDO6itJAtEykaxYK9xx5i0M+f41xk2IMspjv5MdVcb0/kjskCtT5RdprXpvxgUSGz sHJNJT9crnbU3oLMaeZ4SK2HS1Dxll/N7ZwAQFaCN9hTZ2HJrn5kCQWAeMwy26Wq9yQa pa1A== X-Gm-Message-State: AOAM533tqR9K8ZWC4cNmrMXe683SaccHz2G9mzaWJLbrLFcTf3doBZgP zLFbrXSuTFzvtKeCW6ueuBuFZkdVSBd3PDIy9Z8= X-Google-Smtp-Source: ABdhPJxW2QFG/Ujy0dkrXLBwrNpxUVwNLxUfKxSEKBU7vkvHTgfzUjG7tw1NPwOn4z+2WT4iX9sVnN2n/+R1wqJS0nU= X-Received: by 2002:adf:e588:: with SMTP id l8mr22771932wrm.255.1591006968541; Mon, 01 Jun 2020 03:22:48 -0700 (PDT) MIME-Version: 1.0 References: <159064546659.30784.12927519685709906985@ietfa.amsl.com> <86151027.6608.1590676320799@appsuite-gw2.open-xchange.com> In-Reply-To: <86151027.6608.1590676320799@appsuite-gw2.open-xchange.com> From: tirumal reddy Date: Mon, 1 Jun 2020 15:52:36 +0530 Message-ID: To: Vittorio Bertola Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000031f4fb05a7032d04" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-add-server-policy-selection-02.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 10:22:52 -0000 --00000000000031f4fb05a7032d04 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please see inline On Thu, 28 May 2020 at 20:02, Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > Il 28/05/2020 12:19 tirumal reddy ha scritto: > > > Hi all, > > We prepared an updated version of > https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-02 to > address comments from Neil. It discusses how a DNS client can authenticat= e > it is connecting to a DoH/DoT server hosted by a specific organization > (e.g., ISP). We now rely on I-D.pp-add-resinfo to retrieve the Policy > Assertion Token (PAT). > > Comments are welcome. > > Thanks for this work. I think we need feedback by client developers that > would consume this information. You might need something more detailed or > specific to express the server's policies; for example, machine-readable > indication of authentication support, logging policies, or fine-grained > description of filtering policies could be used by clients that want to > standardize their analysis and presentation of server features. It's good > to have an extension mechanism, but there would still be the need for > agreement on what the new claims mean. > The attributes defined in the draft do not convey any =E2=80=9Cprivacy clai= ms=E2=80=9D like logging policies. We don=E2=80=99t want to compete/replace the privacy stat= ements written by an attorney and create any ambiguity or under-represent the legal statements. The attributes identify the capabilities of the DoH server (e.g., malware filtering) and the attribute privacyurl provides a URL that points to the human readable privacy policy statement. The main purpose of this draft is to discuss how a DNS client can cryptographically identify it is connecting to a DoT/DoH server hosted by a specific organization (e.g., ISP). It is particularly useful when the DoH/DoT server is insecurely discovered and prevents the client from connecting to a attackers server. Can you please provide more details on what you mean by machine-readable authentication support and what kind of fine-grained description of filtering policies should be conveyed to the client ? Cheers, -Tiru > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > --00000000000031f4fb05a7032d04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please see inline=C2=A0

On Thu,= 28 May 2020 at 20:02, Vittorio Bertola <vittorio.bertola@open-xchange.com> wrote:
=20 =20 =20



Hi all,

We prepared an updated version of=20 https://tools.ietf.org/html/draft-reddy-add-s= erver-policy-selection-02 to address comments from Neil. It discusses h= ow a DNS client can authenticate it is connecting to a DoH/DoT server hoste= d by a specific organization (e.g., ISP). We now rely on I-D.pp-add-resinfo= to retrieve the Policy Assertion Token (PAT).

Comments are welcome.
Thanks for this work. I think we need feedback by client developers that= would consume this information. You might need something more detailed or = specific to express the server's policies; for example, machine-readabl= e indication of authentication support, logging policies, or fine-grained d= escription of filtering policies could be used by clients that want to stan= dardize their analysis and presentation of server features. It's good t= o have an extension mechanism, but there would still be the need for agreem= ent on what the new claims mean.
=C2=A0
<= div>The attributes defined in the draft do not convey any =E2=80=9Cprivacy = claims=E2=80=9D like logging policies. We don=E2=80=99t want to compete/rep= lace the privacy statements written by an attorney and create any ambiguity= or under-represent the legal statements. The attributes identify the capab= ilities of the DoH server (e.g., malware filtering) and the attribute=C2=A0= privacyurl=C2=A0provides a URL that points to the human readable privacy po= licy statement.=C2=A0

The main purpose of this dra= ft is to discuss how a DNS client can cryptographically identify it is conn= ecting to a DoT/DoH=C2=A0server=C2=A0hosted by a specific orga= nization (e.g., ISP).=C2=A0 It is particularly useful when the DoH/DoT=C2= =A0server=C2=A0is insecurely discovered and prevents the clien= t from connecting to a attackers=C2=A0server.

Can you please provide more details on what you mean by machine-re= adable authentication support and what kind of fine-grained description of = filtering policies should be conveyed to the client ?

<= div>Cheers,
-Tiru

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchangevit=
torio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torin=
o, Italy
=20
--00000000000031f4fb05a7032d04-- From nobody Mon Jun 1 09:45:57 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B473A129A for ; Mon, 1 Jun 2020 09:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=open-xchange.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 VIaqNAIlc9TY for ; Mon, 1 Jun 2020 09:45:47 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 8B0DF3A1301 for ; Mon, 1 Jun 2020 09:45:37 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 4ABF86A25C; Mon, 1 Jun 2020 18:45:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1591029935; bh=Pj0kTLW/5FVweNvz76btwTs/TF2D6aLr20vQD3GbWso=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=hIRSdUi+iztSbC7gB64C+RXgQHtUwbc0t97devd8ihcnrVG4JgeVb/JqEqIuHn9+J GhykcX0Z2BCClsaaItabMz5RJMytzD0sc47G01m7k3PIgM84kKgHIqhuPi2c+OSYXp 8HkIpec+/8Klqe7RCJgpVCmd/IyPliVNMXkHXnNqW/rNBK5GQaGqZIo70h3OQwCjnR lcWI6r/2FjLPeWB0snapauwamPlzM/Q+mDLvdg4EeEQtIxLVnkCnPuBgaAGOZkRVJR E0RPcTPUMb5WKQlp0Pb9vyavU/DP4aXIrOA3Kpq/9PUcKhPIiXIQeXw4biOzMwEPTX mQQ0Kgrx0Ed2A== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 3B7BD3C0333; Mon, 1 Jun 2020 18:45:35 +0200 (CEST) Date: Mon, 1 Jun 2020 18:45:34 +0200 (CEST) From: Vittorio Bertola To: tirumal reddy Cc: ADD Mailing list Message-ID: <199199696.10466.1591029935148@appsuite-gw1.open-xchange.com> In-Reply-To: References: <159064546659.30784.12927519685709906985@ietfa.amsl.com> <86151027.6608.1590676320799@appsuite-gw2.open-xchange.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10464_2037749997.1591029935118" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] [EXT] Re: Fwd: New Version Notification for draft-reddy-add-server-policy-selection-02.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 16:45:56 -0000 ------=_Part_10464_2037749997.1591029935118 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 01/06/2020 12:22 tirumal reddy ha scritto: > > > Can you please provide more details on what you mean by machine-readable authentication support and what kind of fine-grained description of filtering policies should be conveyed to the client ? > This is really a question for client developers. However, perhaps a server with conditional access (example: an ISP server which is made available to the ISP's customers also when roaming onto other networks) would like to express that it requires user authentication (with certain methods, in a certain domain) before usage, so that the client knows that it has to be performed, or can avoid this resolver if it is just looking for open ones. In terms of filtering policies, "malware filtering" is quite general: does it include botnets? Phishing? Even more for "policy blocking": there are at least two big categories (blocked by operator policy vs blocked by law); for the former category, there are several different possible policies (parental control, productivity control, audiovisual blocking etc) which could by the way be applied differently to different users; for the latter, you would at least need to know which law (which jurisdiction) is being applied. IMHO just knowing that the resolver does "some filtering" is not very useful; on one hand, all resolvers in most jurisdictions will be required by law/courts to filter at least something, and on the other, should you actually care about this kind of information to determine whether you want to use or not a resolver that you just discovered, you would need to tell what is being filtered at a more detailed level. But again, it does not make sense to delve further into detailing this information if it is not going to be consumed by the clients. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_10464_2037749997.1591029935118 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 01/06/2020 12:22 tirumal reddy <kondtir@gmail.com> ha scritto:


Can you please provide more details on what you mean by machine-readable authentication support and what kind of fine-grained description of filtering policies should be conveyed to the client ?
This is really a question for client developers. However, perhaps a server with conditional access (example: an ISP server which is made available to the ISP's customers also when roaming onto other networks) would like to express that it requires user authentication (with certain methods, in a certain domain) before usage, so that the client knows that it has to be performed, or can avoid this resolver if it is just looking for open ones.

In terms of filtering policies, "malware filtering" is quite general: does it include botnets? Phishing? Even more for "policy blocking": there are at least two big categories (blocked by operator policy vs blocked by law); for the former category, there are several different possible policies (parental control, productivity control, audiovisual blocking etc) which could by the way be applied differently to different users; for the latter, you would at least need to know which law (which jurisdiction) is being applied. IMHO just knowing that the resolver does "some filtering" is not very useful; on one hand, all resolvers in most jurisdictions will be required by law/courts to filter at least something, and on the other, should you actually care about this kind of information to determine whether you want to use or not a resolver that you just discovered, you would need to tell what is being filtered at a more detailed level.

But again, it does not make sense to delve further into detailing this information if it is not going to be consumed by the clients.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_10464_2037749997.1591029935118-- From nobody Tue Jun 2 05:15:49 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB953A0755 for ; Tue, 2 Jun 2020 05:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 bwxnjpSSODRs for ; Tue, 2 Jun 2020 05:15:45 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 71F613A060A for ; Tue, 2 Jun 2020 05:15:45 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id p5so11564621ile.6 for ; Tue, 02 Jun 2020 05:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/zCsGxdDsbYhaXSfMGH/0Op5J46SCI+QEl1+OyqxLIM=; b=I6DGqfssiWmQtnO9zIDG5ugScQgPDh7+g0kXAOTOllXdic16WBml5Mmd2ZqlMn9pOh 8SccbclnBfA7/wml+dvc2ctkk9rjPSxR1mmTysnwiJJQp9GK4HLbPTELxjhPTT2KB0sS EJGUDhrnCj0qT12vaHDoDKs/z+Lih93EOTUTzXHvBCTAYkw/GZr8LYfBBrUSpVofDwb5 XTA97JVt/Lr7ld5y0Riw2TG+hX8rioRe+TPI63ZzdvvcvIKBXHDW523zVop3CmnUoHkO biQCTy2alg4xadHfUUOoZrMOR/3S+BAVUZ41oTCqNbSl46PWzvvVrSwqjpFgZ9lhZeIw 9ihQ== 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:to:cc; bh=/zCsGxdDsbYhaXSfMGH/0Op5J46SCI+QEl1+OyqxLIM=; b=Hh3ebDQgGIWsrOFrkcOHxJUGff+DQOSpxH6qFpMhSfXnjHoOCWy9yd/k7KruMlSY17 eZZe0p1eUYBGduLjhjmaxXNsLqYfGK3XaHODk2tSLwh3n8PA9d7C9P6O7T7q59UbdCER qXG5hip7HL9M+gYEnVlDgG8pHpsw3JaBcm5uaZl8WeiIrgdPmR1FeVHNyZ5/W4RpYHnq TlrGpiqCvrRLDaljRd130FaKABy7+7d1HPchR8O0fvKhEa/IDQW0S9qnO6jWAFqAhmyD wUKk7qfTNBI1JD4Ie1JjuQIxhYEgsNwCcJvniBCNrc+HtndO5vk8j/emW+0cRK001VZW LkMg== X-Gm-Message-State: AOAM531A3DNpYva24FjY0joqpsT6JATiVIdS2WmnuF0SSdfN6eEQnCVh kNyYQa4rjw/Z6s0dZ6fveqisD9TIr6NnyANXaA0Uao4D X-Google-Smtp-Source: ABdhPJw/dBLc4HYjpMZIm+2l00757cOWFuvCmitANAr2Lz92R8IAgT7gVjPfrmANEcT3Cl6xU9+5Jv1MELLlDHvBlHQ= X-Received: by 2002:a05:6e02:144:: with SMTP id j4mr24693814ilr.214.1591100144627; Tue, 02 Jun 2020 05:15:44 -0700 (PDT) MIME-Version: 1.0 References: <159064546659.30784.12927519685709906985@ietfa.amsl.com> <86151027.6608.1590676320799@appsuite-gw2.open-xchange.com> <199199696.10466.1591029935148@appsuite-gw1.open-xchange.com> In-Reply-To: <199199696.10466.1591029935148@appsuite-gw1.open-xchange.com> From: tirumal reddy Date: Tue, 2 Jun 2020 17:45:33 +0530 Message-ID: To: Vittorio Bertola Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000ec34e705a718dea3" Archived-At: Subject: Re: [Add] [EXT] Re: Fwd: New Version Notification for draft-reddy-add-server-policy-selection-02.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 12:15:48 -0000 --000000000000ec34e705a718dea3 Content-Type: text/plain; charset="UTF-8" Please see inline On Mon, 1 Jun 2020 at 22:15, Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > Il 01/06/2020 12:22 tirumal reddy ha scritto: > > > Can you please provide more details on what you mean by machine-readable > authentication support and what kind of fine-grained description of > filtering policies should be conveyed to the client ? > > This is really a question for client developers. However, perhaps a server > with conditional access (example: an ISP server which is made available to > the ISP's customers also when roaming onto other networks) would like to > express that it requires user authentication (with certain methods, in a > certain domain) before usage, so that the client knows that it has to be > performed, or can avoid this resolver if it is just looking for open ones. > Good point, client authentication looks like a relevant use case for Enterprise provided DoH/DoT server to authenticate roaming users. For example, Firefox DoH setting accepts user credentials (network.trr.credentials) to authenticate the user to use the DoH server but I don't see any support client certificate based authentication yet. Anyways, I guess we can assume other DoH/DoT client implementations will also support client authentication in near future. I don't get the ISP use case, what credentials will be used by the ISP's customers and how will the browser/OS be provisioned to use the credentials ? > > In terms of filtering policies, "malware filtering" is quite general: does > it include botnets? Phishing? > Yes, malicious botnet command and control servers will be also be blocked. Malicious bots are typically considered a subset of malware. We will update to include capability of the resolver to block phishing sites. > Even more for "policy blocking": there are at least two big categories > (blocked by operator policy vs blocked by law); for the former category, > there are several different possible policies (parental control, > productivity control, audiovisual blocking etc) which could by the way be > applied differently to different users; for the latter, you would at least > need to know which law (which jurisdiction) is being applied. IMHO just > knowing that the resolver does "some filtering" is not very useful; on one > hand, all resolvers in most jurisdictions will be required by law/courts to > filter at least something, and on the other, should you actually care about > this kind of information to determine whether you want to use or not a > resolver that you just discovered, you would need to tell what is being > filtered at a more detailed level. > I would say this type of blocking access to domains falls under the category of "censorship" contrary to filtering malware/phishing domains. > > > But again, it does not make sense to delve further into detailing this > information if it is not going to be consumed by the clients. > Agreed. > > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > --000000000000ec34e705a718dea3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please see inline

On Mon, 1 Jun= 2020 at 22:15, Vittorio Bertola <vittorio.bertola@open-xchange.com> = wrote:
=20 =20 =20

Il 01/06/2020 12:22 tirumal reddy <kondtir@gmail.com> ha scritto:


Can you please provide more details on what you mean by machine-reada= ble authentication support and what kind of fine-grained description of fil= tering policies should be conveyed to the client ?
This is really a question for client developers. However, perhaps a serv= er with conditional access (example: an ISP server which is made available = to the ISP's customers also when roaming onto other networks) would lik= e to express that it requires user authentication (with certain methods, in= a certain domain) before usage, so that the client knows that it has to be= performed, or can avoid this resolver if it is just looking for open ones.= =20

Good point, client auth= entication looks like a relevant use case for Enterprise provided DoH/DoT s= erver to authenticate roaming users. For example, Firefox DoH setting accep= ts user credentials=C2=A0(network.trr.credentials)= to authenticate the user to use the DoH server but I don't see any sup= port client certificate based authentication yet. Anyways, I guess we can a= ssume other DoH/DoT client implementations will also support client authent= ication in near future.=C2=A0

I don'= ;t get the ISP use case, what credentials will be used by the ISP's cus= tomers and how will the=C2=A0browser/OS be provisioned to use=C2=A0the=C2= =A0credentials ?
=C2=A0

In terms of filtering policies, "malware filtering" is quite g= eneral: does it include botnets?=C2=A0 Phishing?

Yes, malicious botnet command = and control servers will be also be blocked. Malicious bots are typically c= onsidered a subset of malware. We will update to include capability of the = resolver to block phishing sites.
=C2=A0
Even more for "policy bl= ocking": there are at least two big categories (blocked by operator po= licy vs blocked by law); for the former category, there are several differe= nt possible policies (parental control, productivity control, audiovisual b= locking etc) which could by the way be applied differently to different use= rs; for the latter, you would at least need to know which law (which jurisd= iction) is being applied. IMHO just knowing that the resolver does "so= me filtering" is not very useful; on one hand, all resolvers in most j= urisdictions will be required by law/courts to filter at least something, a= nd on the other, should you actually care about this kind of information to= determine whether you want to use or not a resolver that you just discover= ed, you would need to tell what is being filtered at a more detailed level.=

I would say this type of bloc= king access to domains falls under the category of "censorship" c= ontrary to filtering malware/phishing domains.
=C2=A0


But again, it does not make sense to delve further into detailing this i= nformation if it is not going to be consumed by the clients.

Agreed.



--=20 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchangevit=
torio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torin=
o, Italy
=20
--000000000000ec34e705a718dea3-- From nobody Wed Jun 3 10:45:50 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93DE3A0C63 for ; Wed, 3 Jun 2020 10:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=open-xchange.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 wPZ-zyY-iGDy for ; Wed, 3 Jun 2020 10:45:47 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 3D8C13A0C3E for ; Wed, 3 Jun 2020 10:45:47 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPS id 337236A30E; Wed, 3 Jun 2020 19:45:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1591206345; bh=/76+W366e3+SznhulxIBQPnsSCa5ASXRsGFknhpNBe4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=rCyorhl4g2QU3AYybgted6ApkXd2xPXfFSlywEtDbNvMwRuSGk/VLfjKaNSdA9kw/ aJOFMlHdCUH3CzIA9skqYRrx85wTBj38QOcGQXYmrHqaoUpFcK8xKnuiGchfbxNItQ 3tDS3Lhj2110HcUf6b5jj2M64srGQmvOtUYftiIzWK/xsCYdclWif33RiEg8lR/o4W udeeYOaiSgj209FC6Xjno6sZ8Soy30Psmtz5trG3/I3Rhv8oN//oT+ZvoufbbiHbLA cUvjnqoC/qiaO+OGPPLPRHkpQ2lureaHkWrxiF+BKskkK4fDA0ugl5dpFdLoOtY8wz C58s2ZHQVd7AQ== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 0998D3C0333; Wed, 3 Jun 2020 19:45:45 +0200 (CEST) Date: Wed, 3 Jun 2020 19:45:44 +0200 (CEST) From: Vittorio Bertola To: tirumal reddy Cc: ADD Mailing list Message-ID: <703165933.16255.1591206344926@appsuite-gw1.open-xchange.com> In-Reply-To: References: <159064546659.30784.12927519685709906985@ietfa.amsl.com> <86151027.6608.1590676320799@appsuite-gw2.open-xchange.com> <199199696.10466.1591029935148@appsuite-gw1.open-xchange.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16253_601637814.1591206344899" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] [EXT] Re: Fwd: New Version Notification for draft-reddy-add-server-policy-selection-02.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 17:45:49 -0000 ------=_Part_16253_601637814.1591206344899 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 02/06/2020 14:15 tirumal reddy ha scritto: > > Good point, client authentication looks like a relevant use case for Enterprise provided DoH/DoT server to authenticate roaming users. For example, Firefox DoH setting accepts user credentials (network.trr. credentials) to authenticate the user to use the DoH server but I don't see any support client certificate based authentication yet. Anyways, I guess we can assume other DoH/DoT client implementations will also support client authentication in near future. > > I don't get the ISP use case, what credentials will be used by the ISP's customers and how will the browser/OS be provisioned to use the credentials ? > The same way as in the enterprise use case. Think of those ISPs that require you to authenticate before using their SMTP server from outside their network. > > > > Even more for "policy blocking": there are at least two big categories (blocked by operator policy vs blocked by law); for the former category, there are several different possible policies (parental control, productivity control, audiovisual blocking etc) which could by the way be applied differently to different users; for the latter, you would at least need to know which law (which jurisdiction) is being applied. IMHO just knowing that the resolver does "some filtering" is not very useful; on one hand, all resolvers in most jurisdictions will be required by law/courts to filter at least something, and on the other, should you actually care about this kind of information to determine whether you want to use or not a resolver that you just discovered, you would need to tell what is being filtered at a more detailed level. > > > > > > I would say this type of blocking access to domains falls under the category of "censorship" contrary to filtering malware/phishing domains. > Well, to some people "policy blocking" seems to be an euphemism for censorship, no matter what gets blocked and why. In HRPC, actually, a draft currently under discussion defines even malware blocking as "censorship". However, the use of more or less loaded terminology is out of scope - the point is rather whether it would be useful for the client to know the policies more in detail or whether a generic "I filter stuff" signal is useful. But again, this depends on the clients. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_16253_601637814.1591206344899 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 02/06/2020 14:15 tirumal reddy <kondtir@gmail.com> ha scritto:

Good point, client authentication looks like a relevant use case for Enterprise provided DoH/DoT server to authenticate roaming users. For example, Firefox DoH setting accepts user credentials (network.trr. credentials) to authenticate the user to use the DoH server but I don't see any support client certificate based authentication yet. Anyways, I guess we can assume other DoH/DoT client implementations will also support client authentication in near future. 

I don't get the ISP use case, what credentials will be used by the ISP's customers and how will the browser/OS be provisioned to use the credentials ?
The same way as in the enterprise use case. Think of those ISPs that require you to authenticate before using their SMTP server from outside their network.
Even more for "policy blocking": there are at least two big categories (blocked by operator policy vs blocked by law); for the former category, there are several different possible policies (parental control, productivity control, audiovisual blocking etc) which could by the way be applied differently to different users; for the latter, you would at least need to know which law (which jurisdiction) is being applied. IMHO just knowing that the resolver does "some filtering" is not very useful; on one hand, all resolvers in most jurisdictions will be required by law/courts to filter at least something, and on the other, should you actually care about this kind of information to determine whether you want to use or not a resolver that you just discovered, you would need to tell what is being filtered at a more detailed level.

I would say this type of blocking access to domains falls under the category of "censorship" contrary to filtering malware/phishing domains.
Well, to some people "policy blocking" seems to be an euphemism for censorship, no matter what gets blocked and why. In HRPC, actually, a draft currently under discussion defines even malware blocking as "censorship". However, the use of more or less loaded terminology is out of scope - the point is rather whether it would be useful for the client to know the policies more in detail or whether a generic "I filter stuff" signal is useful. But again, this depends on the clients.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_16253_601637814.1591206344899-- From nobody Wed Jun 3 10:52:59 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920A73A0C84 for ; Wed, 3 Jun 2020 10:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=open-xchange.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 0fWSBQwUL7Ph for ; Wed, 3 Jun 2020 10:52:56 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 286C93A0C5C for ; Wed, 3 Jun 2020 10:52:56 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 288E66A304; Wed, 3 Jun 2020 19:52:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1591206774; bh=f8IBJDMq4cn3EDZN75o+ZUwLGeHyN16VW3iGE6m8JMY=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=94KhkTAw1p0jUJNbpdD4Y0p1AtJYeWIEQyjrDViEhjoaMEsakIci0uVqYko2DS65y /UzRm5aecjAKU9hPO7iqXdGjCxGtuJdtX6OTsdAkWmRc7/k21Qfk5aOy5U9BXFO4rR J7r/cEIxiu7v1E8b8wdWwcpe6G89iyfy4Vto0Zjbckp+osagCs71xQdqxTB37hAKmr zSr8WJQyANVKTkKxGWP5q0lLPgwwSHk43MNdJt15NBB1l1aUyIpeUd3YggnPkpPFuv ejKLMBnTEQA37uCjRotLlN2kOZM5NYgq5C14EGfbLLoTu8rFfRBt0qFIdzNOhLWbHn 6Cvw4dIxFZ/PA== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 1A2383C0333; Wed, 3 Jun 2020 19:52:54 +0200 (CEST) Date: Wed, 3 Jun 2020 19:52:53 +0200 (CEST) From: Vittorio Bertola To: tirumal reddy Cc: ADD Mailing list Message-ID: <1170324347.16268.1591206774005@appsuite-gw1.open-xchange.com> In-Reply-To: <703165933.16255.1591206344926@appsuite-gw1.open-xchange.com> References: <159064546659.30784.12927519685709906985@ietfa.amsl.com> <86151027.6608.1590676320799@appsuite-gw2.open-xchange.com> <199199696.10466.1591029935148@appsuite-gw1.open-xchange.com> <703165933.16255.1591206344926@appsuite-gw1.open-xchange.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16266_795063656.1591206773994" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] [EXT] Re: Fwd: New Version Notification for draft-reddy-add-server-policy-selection-02.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 17:52:58 -0000 ------=_Part_16266_795063656.1591206773994 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 03/06/2020 19:45 Vittorio Bertola ha scritto: > > > > > > > Il 02/06/2020 14:15 tirumal reddy ha scritto > > > > > > > > > > > > I would say this type of blocking access to domains falls under the category of "censorship" contrary to filtering malware/phishing domains. > > > > > Well, to some people "policy blocking" seems to be an euphemism for censorship, no matter what gets blocked and why. In HRPC > [correction: for some reason, it's actually PEARG] -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_16266_795063656.1591206773994 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 03/06/2020 19:45 Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org> ha scritto:



Il 02/06/2020 14:15 tirumal reddy <kondtir@gmail.com> ha scritto


I would say this type of blocking access to domains falls under the category of "censorship" contrary to filtering malware/phishing domains.
Well, to some people "policy blocking" seems to be an euphemism for censorship, no matter what gets blocked and why. In HRPC
[correction: for some reason, it's actually PEARG]

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_16266_795063656.1591206773994-- From nobody Fri Jun 5 14:15:13 2020 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6CC3A0DA5; Fri, 5 Jun 2020 14:15:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: barryleiba@computer.org, add-chairs@ietf.org, add@ietf.org, glenn.deen@nbcuni.com X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159139171109.11327.17461970390242844442@ietfa.amsl.com> Date: Fri, 05 Jun 2020 14:15:11 -0700 Archived-At: Subject: [Add] add - New Meeting Session Request for IETF 108 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 21:15:11 -0000 A new meeting session request has just been submitted by Glenn Deen, a Chair of the add working group. --------------------------------------------------------- Working Group Name: Adaptive DNS Discovery Area Name: Internet Area Session Requester: Glenn Deen Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 200 Conflicts to Avoid: Chair Conflict: mops tsvwg mboned Technology Overlap: capport dhc dnsop dprive opsawg wpack Key Participant Conflict: httpbis tls quic People who must be present: Barry Leiba Glenn Deen David C Lawrence Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jun 8 06:22:58 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85B83A0A9E for ; Mon, 8 Jun 2020 06:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 PODfc1DfZxtk for ; Mon, 8 Jun 2020 06:22:55 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 F3D643A0A0C for ; Mon, 8 Jun 2020 06:22:54 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id 18so16639948iln.9 for ; Mon, 08 Jun 2020 06:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h/7MN5Vte4tWBPZ8he+vvZSkybauhujFRUBSZjZWBy8=; b=r5OyYhi8GHW8u/YpuDbG0u+ixzhKoSBGsjgGUln0qalP0R2VBu5EH4o4JwRH1LM43U oCArp2MtaqGUX6rZWdCr+MIo+EaSs74jnWTuPUOO1LBjynO2epGY3ZozucHguhekpGvA bTpHmmlPsx6k05cQTEywgkQGW0ZYt20fB+intRoCybLfmZ/Xqt/acxMTySIk4HiuQYN8 4G3CByQY2YbyI6Q/aHgQR5wG2890hO59nKFRNmH9ZEx9KsxmVv4kmu1Hbgcn6dqs/N7c eFAlnH/1kYEujh6x0q9FYRQRm69rcvzusgR6SsuKWr3zN3F/R7PoLP/+p5nTV2GqOLQ/ NRtA== 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:to:cc; bh=h/7MN5Vte4tWBPZ8he+vvZSkybauhujFRUBSZjZWBy8=; b=njX8UZ6mdnx56Eo9FehHHCzs1jHvCoO7d66ooZxC31nlOqR0K1/F+PuxEFmExo46vh dPxjBXQN1z+leWKheOdi/o1M/0G7/W01NGHUTlnteGxhGrwSEpgWy/z5wcXxi2b1sbNm JrE9e2Tga81f43J0oAQ+oIuPqCY3sQMlT8fZNjAY20cIeSc3ac8sxHwsslO/apFkBNH2 UYQ9NZ+O/PcEhEX5AOgSzxiIMnB4CT55HObd+fKExLEqXjg2lBWvrYaqdaYgSAXhHf1i kqpMH9hy/ZF1v+2Ao2p0t3HDXIfphWaEHlXoJPaHXeSpsAk82CiLFLF9a+FPYtKX8CaO dSTA== X-Gm-Message-State: AOAM530BA/p5aOKAY5P/r8mJY+F8X/p6D7RkB76+HReTpYoDO2LTv4Jn N+/ZNoK46vxBIoM+CXIje6okoTog4wjaaQdt2VwWvTBQ0to= X-Google-Smtp-Source: ABdhPJzZCVUDxdxkzfUZYP+HW2CHPpMuR3nLSJZrFd3j94pG1h/7HVR6FithZ5OQ3a3orUbK3aaIewa+WhAlCGg/pcU= X-Received: by 2002:a92:6411:: with SMTP id y17mr22242410ilb.161.1591622572723; Mon, 08 Jun 2020 06:22:52 -0700 (PDT) MIME-Version: 1.0 References: <159064546659.30784.12927519685709906985@ietfa.amsl.com> <86151027.6608.1590676320799@appsuite-gw2.open-xchange.com> <199199696.10466.1591029935148@appsuite-gw1.open-xchange.com> <703165933.16255.1591206344926@appsuite-gw1.open-xchange.com> In-Reply-To: <703165933.16255.1591206344926@appsuite-gw1.open-xchange.com> From: tirumal reddy Date: Mon, 8 Jun 2020 18:52:41 +0530 Message-ID: To: Vittorio Bertola Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000010527d05a7928295" Archived-At: Subject: Re: [Add] [EXT] Re: Fwd: New Version Notification for draft-reddy-add-server-policy-selection-02.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 13:22:57 -0000 --00000000000010527d05a7928295 Content-Type: text/plain; charset="UTF-8" On Wed, 3 Jun 2020 at 23:15, Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > Il 02/06/2020 14:15 tirumal reddy ha scritto: > > Good point, client authentication looks like a relevant use case for > Enterprise provided DoH/DoT server to authenticate roaming users. For > example, Firefox DoH setting accepts user credentials (network.trr. credentials) > to authenticate the user to use the DoH server but I don't see any support > client certificate based authentication yet. Anyways, I guess we can assume > other DoH/DoT client implementations will also support client > authentication in near future. > > I don't get the ISP use case, what credentials will be used by the ISP's > customers and how will the browser/OS be provisioned to use the credentials > ? > > The same way as in the enterprise use case. Think of those ISPs that > require you to authenticate before using their SMTP server from outside > their network. > Got it, Thanks. > Even more for "policy blocking": there are at least two big categories > (blocked by operator policy vs blocked by law); for the former category, > there are several different possible policies (parental control, > productivity control, audiovisual blocking etc) which could by the way be > applied differently to different users; for the latter, you would at least > need to know which law (which jurisdiction) is being applied. IMHO just > knowing that the resolver does "some filtering" is not very useful; on one > hand, all resolvers in most jurisdictions will be required by law/courts to > filter at least something, and on the other, should you actually care about > this kind of information to determine whether you want to use or not a > resolver that you just discovered, you would need to tell what is being > filtered at a more detailed level. > > > I would say this type of blocking access to domains falls under the > category of "censorship" contrary to filtering malware/phishing domains. > > Well, to some people "policy blocking" seems to be an euphemism for > censorship, no matter what gets blocked and why. In HRPC, actually, a draft > currently under discussion defines even malware blocking as "censorship". > However, the use of more or less loaded terminology is out of scope - the > point is rather whether it would be useful for the client to know the > policies more in detail or whether a generic "I filter stuff" signal is > useful. But again, this depends on the clients. > I will go with the definitions of "censorship" and "blocking" defined in Sections 4.16 and 4.17 in https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16. Cheers, -Tiru > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > --00000000000010527d05a7928295 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 3 Jun 2020 at 23:15, Vittorio Ber= tola <vittorio.bert= ola@open-xchange.com> wrote:
=20 =20 =20

Il 02/06/2020 14:15 tirumal reddy <kondtir@gmail.com> ha scritto:

Good point, client authentication looks like a relevant use case for = Enterprise provided DoH/DoT server to authenticate roaming users. For examp= le, Firefox DoH setting accepts user credentials (network.trr. credentials) to authenticate the user to use the DoH server but= I don't see any support client certificate based authentication yet. A= nyways, I guess we can assume other DoH/DoT client implementations will als= o support client authentication in near future.=C2=A0

I don't get the ISP use case, what credentials will be used by th= e ISP's customers and how will the=C2=A0browser/OS be provisioned to us= e=C2=A0the=C2=A0credentials ?
The same way as in the enterprise use case. Think of those ISPs that req= uire you to authenticate before using their SMTP server from outside their = network.

Got it, Thanks.=C2=A0<= /div>
=C2=A0
Even more for "policy blocking": there are at least two b= ig categories (blocked by operator policy vs blocked by law); for the forme= r category, there are several different possible policies (parental control= , productivity control, audiovisual blocking etc) which could by the way be= applied differently to different users; for the latter, you would at least= need to know which law (which jurisdiction) is being applied. IMHO just kn= owing that the resolver does "some filtering" is not very useful;= on one hand, all resolvers in most jurisdictions will be required by law/c= ourts to filter at least something, and on the other, should you actually c= are about this kind of information to determine whether you want to use or = not a resolver that you just discovered, you would need to tell what is bei= ng filtered at a more detailed level.

I would say this type of blocking access to domains falls under the c= ategory of "censorship" contrary to filtering malware/phishing do= mains.
Well, to some people "policy blocking" seems to be an euphemis= m for censorship, no matter what gets blocked and why. In HRPC, actually, a= draft currently under discussion defines even malware blocking as "ce= nsorship". However, the use of more or less loaded terminology is out = of scope - the point is rather whether it would be useful for the client to= know the policies more in detail or whether a generic "I filter stuff= " signal is useful. But again, this depends on the clients.

I will go with the definitions of "c= ensorship" and "blocking" defined in Sections 4.16 and 4.17 = in=C2=A0https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16.= =C2=A0

Cheers,
-Tiru
=C2=A0

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchangevit=
torio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torin=
o, Italy
=20
--00000000000010527d05a7928295-- From nobody Fri Jun 19 07:28:02 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84923A0A41; Fri, 19 Jun 2020 07:28:00 -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, SPF_HELO_NONE=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 12T2Y7FTu9Jk; Fri, 19 Jun 2020 07:27:59 -0700 (PDT) Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 F3AC13A0A25; Fri, 19 Jun 2020 07:27:58 -0700 (PDT) Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 05JERwiv011392 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 19 Jun 2020 14:27:58 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 07:27:56 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Fri, 19 Jun 2020 07:27:56 -0700 From: Paul Hoffman To: Ben Schwartz CC: ADD Mailing list Thread-Topic: [Ext] [Add] New versions of draft-pp-add-stub-upgrade and draft-pp-add-resinfo Thread-Index: AQHWRkXTzhytK3HLZ0Wq+cpVy612/w== Date: Fri, 19 Jun 2020 14:27:56 +0000 Message-ID: <2670FAB5-C624-4154-AD58-7A06E5292145@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_78D28023-3E3E-45A3-9E06-90F13B738DC7"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-19_14:2020-06-19, 2020-06-19 signatures=0 Archived-At: Subject: Re: [Add] [Ext] New versions of draft-pp-add-stub-upgrade and draft-pp-add-resinfo X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 14:28:01 -0000 --Apple-Mail=_78D28023-3E3E-45A3-9E06-90F13B738DC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Apologies for the belated reply. On May 16, 2020, at 1:09 PM, Ben Schwartz = wrote: > Thanks; I like this version of RESINFO. Some comments on Section 2: > * "... it can use that configuration to actually be authoritative for = the addresses on which it responds." -> I don't understand what an = "address" is in this sentence. Does it refer to a reverse-IP name? Or = to the hostname of the resolver, in cases where the resolver has a known = name (e.g. DNS-over-TLS)? Good catch. These sentences were left over from earlier drafts that were = about addresses; we'll fix this in the next draft. > * "Any query for the RESINFO RRtype that does not have a QNAME of = resolver-info.arpa/IN is meaningless and MUST result in a NODATA or = NXDOMAIN response." -> I would like this to be relaxed (see proposal = below). >=20 > Proposal: DNSSEC-authenticated RESINFO for named resolvers > Most resolvers are known to the client by their IP (learned via DHCP, = etc.). However, there are some systems (e.g. Android) that allow the = user to identify a preferred resolver by hostname. I propose that any = resolver that is known to its clients by hostname (currently only DoT = resolvers) MUST additionally publish its RESINFO record on its hostname, = and clients MAY query $hostname/IN/RESINFO instead of = resolver-info.arpa/IN/RESINFO. This would enable authentication of = RESINFO for clients who perform DNSSEC validation and have a resolver = identified by hostname. >=20 > Possible use cases: > * Authenticated DoH to named resolvers without also having to = implement DoT (and without requiring the user to provide the full DoH = URI template). > * Authentication and non-repudiability of (TBD) non-upgrade-related = metadata in RESINFO. This is an interesting proposal. We cannot say "MUST" because a resolver = cannot empirically know all the domain names that all clients might know = it as. However, a resolver that has configuration that says "you are = known as $name1 and $name2" could indeed respond to those RESINFO = queries on those names, and those responses would be signed if those = zones are signed. We'll add this to the next draft. > I have more problems with the "Upgrade" draft: > Section 2.1: > * "dot-ports" -> I think this should be "dot-addresses" in = hostname:port syntax, to enable authentication. The "hostname" part can = be optional to indicate "same IP, unauthenticated". This could be interpreted as a change from being information about this = resolver to being information about this or other resolvers, such as = "that resolver over there is our preferred DoT resolver". We had that = earlier, and it seemed like people didn't like that. Instead, we could add "dot-hostnames" that would a list of hostnames = that this resolver is known by. Would that work for you? If so, that = would be good for the draft if the WG adopts it. > * "The host part of the URI template MUST be an IP address." -> I = think this is exactly wrong. =20 This seems to spark the most debate. > IP address certificates provide less security than named certificates,=20= It completely depends on the mechanism used by the CA to authenticate = domain names; in many cases, IP address certificates have the same = assurances as domain certificates. > and are also dramatically more difficult to acquire. ...currently. This protocol is meant to be used over the long term, not = just now. > I would remove this requirement, and also change the examples to use = named URLs. This, too, is a good discussion if the WG adopts this draft. To be = clear: we're not against the use of domain names in the URLs, but we = don't want to force them in when they are contentious. > Section 3: > * "upgradeNoAuth" -> I think this should be removed. If the resolver = claims a name, we should always validate, and fail hard if validation = fails. If by "we" you mean a specific stub resolver, that is fine: set that = variable to "false". There are plenty of use cases where some clients = want opportunistic encryption to protect against off-path snooping but = cannot authenticate, such as if the client does not have the CA used by = the resolver in its trust anchor pile. > * "start TLS session on resIP port 443" -> I don't understand the = intent of this algorithm, but it does not support HTTP/3, nor URLs with = non-default ports. Excellent points. We'll change this to use the DoH port for HTTP/2, and = add something for HTTP/3. > It also seems to imply that the DoH server must run on the same IP = address as the Do53 server, which is not true for many major = deployments. Also a good point. We need to do more in the pseudocode to deal with DoH = templates that point to resolvers other than the one queried. > I would replace this entire section with "Do DoH". That is too simplistic to be useful here. > * This section is missing "just try TLS on port 853", Agree. We could add a paragraph that gives that as an example, showing = with the inputs for that might be. > which is the status quo for DoT upgrade. It is the status quo for one significant implementation, yes. :-) --Paul Hoffman and Puneet Sood= --Apple-Mail=_78D28023-3E3E-45A3-9E06-90F13B738DC7 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwNjE5MTQyNzU2WjAvBgkqhkiG9w0BCQQxIgQgnXVpy7dC3Cu0OALa2NQxz1gU3y0s eHjWwEB3HZc8gkcwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAGdrBMK/K7YBTQ2Rv9OvMMvAWE3JX4bgsmhKnP54kMjv Pr9DrHsX8iVDUkUxz6OSbRWjFve3Xu3XqlRO4FXuYKzV56DeMpFNTikbdELSJN2POWpSDNWUg2je mqfRkeB0FWY80YKahLRy5KJg3hghV4TLTsDVgNKc0JU+vT8pKfZ405o/hlhr/pNd0vNoeLFFGZBy 04dKapM9Nj7Hfog/Ni6+7aNoEla2A7X7006fJ70F4tj6qXBTrlc8nyUOqVFS1peCpHZnCiFsIFMU mLkZnYd8Z5fGjUhTHIDDLx46w5uqjDDI9lf420EhywwHMYtJ9dnKrpZpdh14DG+F1rGczJ0AAAAA AAA= --Apple-Mail=_78D28023-3E3E-45A3-9E06-90F13B738DC7-- From nobody Mon Jun 22 19:17:52 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCB83A16F4 for ; Mon, 22 Jun 2020 19:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=comcast.com header.b=nd0xrgGj; dkim=pass (2048-bit key) header.d=comcast.com header.b=MjeqczS1; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=AtBWuOqV 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 EJyffIQLUsha for ; Mon, 22 Jun 2020 19:17:48 -0700 (PDT) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (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 B7C903A16F3 for ; Mon, 22 Jun 2020 19:17:47 -0700 (PDT) Received: from pps.filterd (m0156894.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05N2FgDf001670 for ; Mon, 22 Jun 2020 22:17:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : mime-version; s=20190412; bh=Zf8UOA7p9xhYRLhfMif+hnExGu3dh4c5VoQflpaUbmE=; b=nd0xrgGjo2On147qj7oI/mtq0LAe8e9Fye1D5Nyh9EdoeqC9MH7YJN+aj+WWIGgvPu+f VWH1Wsr0HPfK/wWKzQHKRBELHn+TuNExexqKK3e1kpI9KuKLnpLfegizODsbt4s1xFyR O5T4yf2PT+kS834lbec7SHeaKuYmOMVY3fA8kCr+gNoVVbO3ypvMGjYjz5JTVwJX20Rm vc/4YuWGtnCELktTcYJh/LWNAiQdUgIegZcdyqLCSO4Dj9lWg00Bl7KAQl29Tct8GvGi 82MBnCHgjtzrOV1CEJnnaJyOYm1G1aGx8EflIzbjhAXabdvx4lVSqlvD7CXNHMsdqE9y ag== Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) by mx0b-00143702.pphosted.com with ESMTP id 31sfath032-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 22 Jun 2020 22:17:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1592878666; x=2456792266; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Zf8UOA7p9xhYRLhfMif+hnExGu3dh4c5VoQflpaUbmE=; b=MjeqczS1B5uMa3k8Z0KBbmk6GSH9y7fEDuR2jbdBKO4fZvs1zDC3rbhk8ah+/gBy 922S66kHmrIOiylhcHDjWmK3CpYyCDfVQSFpDzTavriLgorNQc9iCq5H2MB9HGZg 99mYd75+XdG+aR1y7HmcF6lNBZwWikGt/IDgjd1RP3pQ9Mr4KpHn+zIZS25oUchc KxIqeHcYak0M2ggt/ez87KbBbiJxwvsa3m2qYqRJO4n8H6zo7QYQ8ZNR2r09fk0w EEidtrj1IabwuOI9RHl5/9bR31dSUXnvyoOlffOrFEB+WlKdU9UmWBJRupMFXH4l 61EtZAjTg7a3R7+kj5r6OA==; X-AuditID: a2962c47-52fff7000001f819-75-5ef1664a7862 Received: from COPDCEX49.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id EA.E2.63513.A4661FE5; Mon, 22 Jun 2020 20:17:46 -0600 (MDT) Received: from COPDCEX51.cable.comcast.com (147.191.125.150) by COPDCEX49.cable.comcast.com (147.191.125.148) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 22 Jun 2020 20:17:45 -0600 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX51.cable.comcast.com (147.191.125.150) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 22 Jun 2020 20:17:45 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.55) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 22 Jun 2020 22:17:50 -0400 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by BY5PR11MB3894.namprd11.prod.outlook.com (2603:10b6:a03:18c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Tue, 23 Jun 2020 02:17:43 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::e91c:5c07:a6ce:5da0]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::e91c:5c07:a6ce:5da0%4]) with mapi id 15.20.3109.027; Tue, 23 Jun 2020 02:17:43 +0000 From: "Deen, Glenn" To: ADD Mailing list Thread-Topic: Reminder: Important upcoming ADD dates Thread-Index: AQHWSQR6pxIGrKjiTU2Suu0V/F1kbQ== Date: Tue, 23 Jun 2020 02:17:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [107.184.135.4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4570aa1a-59d1-4382-9827-08d8171b9ce5 x-ms-traffictypediagnostic: BY5PR11MB3894: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 04433051BF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: W5WD+p8XBeOMeOAHDa2Uo3wyxUFswaxG5k+5yyAxSCwQfEciFUjURQlYNEI9Jy23djSokiykcjOg+k6q0ohPfufEdGnMKlkYf9TVGuXG9aB+TnEaRX5raQAQIWUYwe52o3wkHJCGUub75GrkiK5Ddxw8ag88ik1OGNo6oSkJGaegqyyhujohLoPhrPbUlLYjHlySf623CufAmGjcIZobpEVtK3ToJsd94uB4TLcqhciX0vE8ot5MeeXWJZpvkhcXKMJOB2YOOUdVNDxRHH61LRP6QBVRzkpifz8XolZre6ohI10iqHAb325fujzdQ0P03OV4pu1FYU9z6/duOTsMgg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(136003)(396003)(346002)(366004)(36756003)(6486002)(2616005)(26005)(8936002)(66476007)(66556008)(76116006)(8676002)(6506007)(66946007)(66446008)(316002)(86362001)(4744005)(64756008)(6916009)(6512007)(33656002)(71200400001)(5660300002)(2906002)(186003)(83380400001)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: tb4zKYd/hQXRHWp030WHv8SKAiHTEjv00IjhMhABXNON+3HyhLnpxR9FeptyhtgNQCdp2L6w4f2YJoDH9P1l26LoUSw8bCQ4cmJvRCPWl/lfK24F0bu3Ff7tDrdsZVpotzEkNJKtAS1l+KNGqjlJGtA2OVuuHVWxmv1CSOIrz/WKn0gLWEgbShEWMwGqtTNXWYohocFmSVvtpfS1T+aj2Y0yKaHJ6aFzfvJ22GbdtuQf5y7wTyYGngRyAhsmODLaA9ISD/hmCITUuNkkjYxvA8NjYYKdoi4w68CdUh1ct6ujbNtXBvCfJvUYYYlyVkYkV1ZYweQ1e8VTaVfwpN5aNqTKm71CVL9y9mBkDxqMIMrPvAXYDHU+GHces7LRH06bQVyGELdZnudCPYunouCuKq8j6xM6kyDYI6lzmjEMPx3d6+/jobccXNqUBISRQ2ejQWHQmr2TlA9PtUjd6X0HY54dZIeH8dWXc7pIIld/AWlIfNlJHN1uBNRX4N6TngrB x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PAsiwUXdLgS3jlgRMzcfphW4UPxhn1/EIFi3BnlNbH+gFDmaQAJel7/3uLaJo6tJphvZ3dDyyz0Xwdjijg5wgVMwLal2FT8fYeXyI/XAoci/yCQWQGjvOjFntpWV1KCNw2HDSGcduGvH7X8DvKTaK2vqh7aZUcFbexEeFQ6AEaahfUM4Ga6u3zq8Dv7QsQE9A3MqpuYtHHQ18G0y82j3xMfighgVDpRQjOJot2C6F3ovKNsHi9tt3mR1e/VhvQCFjdxj7VtOqTCQvck7IDOBeZKTa3w0fPQOCoqXj3nXbwSFDZsSRhgwzdKiVEYFv1kd2o7Ix0nvucPhnteLVFVMCg== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vkqZHgnqAPtDPigT/g01SAyWJcW7ztrF6TZ5GzZ7SHE=; b=fWkpiVQlDk7ZnNKnhWoSRJ/ve1SLlL2TSBsdh26jZnzbskWTZGyXvIFSxb8O24rpZpT6jnXlgwUO4VQQAC4+//FNTnXVLw0u29sEqBDjAqfCOsXl7wx5dzABoQjV3wkZklrjZNKE/BhxG5py8mC+I1n1Yg7ARuDPOwQsgoKwTtg62raBzsg/sz3IbnSyAWQRrMIKfwi/K3v/XCBYwuE0S+l/WoDvC9+qRGGJNzjY90Yi+UnV9dX3+uRzNlFfnYvr4zm58UfJkq3cNXxYO67xCN/KJs+fKvsx4VUJwR/S4d5miYMvj+2h/I3MfhOG0/7QbuKtEwGPLveztTXLPXYD4Q== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vkqZHgnqAPtDPigT/g01SAyWJcW7ztrF6TZ5GzZ7SHE=; b=AtBWuOqVulI93D3HXRNpOwPRWQ6mL7XlNmitLJMgfeJ41qbaRTAVNT8I2z7VbrHmg4y9vsYLCSKR9kQOIKBtoMt/MapYm0atc6nh2EIQ4MahQMX8zqIxDO/VLTakPULtq02zG7zo9qbh+t0pTYjblaJpFXI8ukVyO+oruIhzm4U= x-ms-exchange-crosstenant-network-message-id: 4570aa1a-59d1-4382-9827-08d8171b9ce5 x-ms-exchange-crosstenant-originalarrivaltime: 23 Jun 2020 02:17:43.5614 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 1gOglsk4gmv0kjoS3VtwPBCfMZhGPsLUS+16KcxYHEtcHeAJGbWdh+UQHZnEkpaYrB4wRTldRBxNhJgZjBRmNrnWMsRxjiaKXOad9oovAoY= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB3894 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_BC510184B5544A8C8D34D97E9C34033Acomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsWSUDRnsq5X2sc4g92rhC3+n17H5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKmXf7EXfPWr+Ht3IksD4x2fLkYODgkBE4m/T827GLk4hAQO M0lM721hgXAOMUrsvruaCcK5wyix+u06dgjnBKPEga2/oTJLmCQmPn/DDOE8YpTYv2AOI8hg NgEdiW2b7bsYOTlEBJQllt7dzgQSFhbQl3izIB/EFAFafXpNPUSFnsTKHdtZQGwWAVWJ12/7 GEFsXgE7iemvDzGB2IwCYhLfT60Bs5kFxCVuPZkPZksICEgs2XOeGcIWlXj5+B8riC0KtOne +s9g3zAKdDFKvOo6wAhRpChxvv8HlC0rcWl+N5TtK/Hx9kF2CFtL4ujur+yQIMqWWLtbGSKs JvFu82aochmJO9MPQ+2Vk1jV+5AFJv7gxnY2kL0SAr+ZJK7M+c4I4Txglti05hrUgiUsEpvf 5U1gNJiF5CEIO0ni+r+3YDavgKDEyZlPWGYB3cEsoCmxfpc+RImixJTuh+wQtoZE65y5ULaH xJbr35iR1Sxg5FjFyGtoZqRnaGqgZ2KiZ264iRGYbhZN03HfwfjhfOwhRgEORiUe3sPxH+OE WBPLiitzgXHPwawkwvs64F2cEG9KYmVValF+fFFpTmrxIUZpDhYlcd6eqy/ihATSE0tSs1NT C1KLYLJMHJxSDYyLtsqJB07Zr79W0fVi+L5PHCZzfniJOBWzzt0kmZ+WnZ97ePVue15N/2Pu nmereVf/e1QqUxzVwL0k4kfycv+p7UKL6z4eM5/LubDusX3rye0mr3fLCub9kZTQLLZVWmau aLi2Tf6ONXvK/HPtJ5I9N0jopKpfPJTxbNpaFeXqoz8zbpX1rVFiKc5INNRiLipOBAAt/AzM MwMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-22_16:2020-06-22, 2020-06-22 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Add] Reminder: Important upcoming ADD dates X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 02:17:51 -0000 --_000_BC510184B5544A8C8D34D97E9C34033Acomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IFRoZSBBREQgY2hhaXJzIHdvdWxkIGxpa2UgdG8gcmVtaW5kIGV2ZXJ5b25lIG9mIGEgY291cGxl IG9mIHVwY29taW5nIGRhdGVzLCBhbmQgdG8gYXNrIGZvciBzdWJtaXNzaW9ucyBmb3IgdGhlIEFE RCBJRVRGMTA4IHNlc3Npb24uDQoNCkp1bmUgMjYg4oCTIEVhcmx5IEJpcmQgUmVnaXN0cmF0aW9u IEN1dC1PZmYNCg0KSnVseSAgMTMgIC0gSUQgU3VibWlzc2lvbiBkZWFkbGluZSBhaGVhZCBvZiBJ RVRGIDEwOA0KDQpKdWx5IDI3LTMxIElFVEYgMTA4IOKAkyBXZeKAmXZlIHJlcXVlc3RlZCBhIHNl c3Npb24gZm9yIEFERCBhbmQgYXJlIHdhaXRpbmcgZm9yIGl0IGJlIHNjaGVkdWxlZC4NCg0KTm93 OiAgSXTigJlzIG5ldmVyIHRvbyBzb29uIHRvIHJlcXVlc3QgYSBzbG90IG9uIHRoZSBBREQgSUVU RiAxMDggYWdlbmRhLCBwbGVhc2Ugc2VuZCBlbWFpbCB0byBhZGQtY2hhaXJzQGlldGYub3JnPG1h aWx0bzphZGQtY2hhaXJzQGlldGYub3JnPiAgd2l0aCBob3cgbXVjaCB0aW1lIHlvdeKAmWQgbGlr ZSBhbmQgd2hhdCB5b3XigJlsbCBiZSBwcmVzZW50aW5nIG9uLg0KDQoNCg0KVGhhbmtzLA0KR2xl bm4gRGVlbiAmIERhdmlkIExhd3JlbmNlIOKAkyB5b3VyIGZyaWVuZGx5IEFERCBjaGFpcnMNCg0K --_000_BC510184B5544A8C8D34D97E9C34033Acomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMiA2IDMgNSA0IDUgMiAzIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0Mx Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJ Y29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3Jt YWw7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUt Y29udmVydGVkLXNwYWNlO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFj ayI+Jm5ic3A7VGhlIEFERCBjaGFpcnMgd291bGQgbGlrZSB0byByZW1pbmQgZXZlcnlvbmUgb2Yg YSBjb3VwbGUgb2YgdXBjb21pbmcgZGF0ZXMsIGFuZCB0byBhc2sgZm9yIHN1Ym1pc3Npb25zIGZv ciB0aGUgQUREIElFVEYxMDggc2Vzc2lvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdl YmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7 Y29sb3I6YmxhY2siPkp1bmUgMjYg4oCTIEVhcmx5IEJpcmQgUmVnaXN0cmF0aW9uIEN1dC1PZmY8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtj b2xvcjpibGFjayI+SnVseSAmbmJzcDsxMyAmbmJzcDstIElEIFN1Ym1pc3Npb24gZGVhZGxpbmUg YWhlYWQgb2YgSUVURiAxMDg8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6 IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4 dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRv Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0 bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZl dGljYTtjb2xvcjpibGFjayI+SnVseSAyNy0zMSBJRVRGIDEwOCDigJMgV2XigJl2ZSByZXF1ZXN0 ZWQgYSBzZXNzaW9uIGZvciBBREQgYW5kIGFyZSB3YWl0aW5nIGZvciBpdCBiZSBzY2hlZHVsZWQu PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lk b3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29y cGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNp emUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2si Pk5vdzogJm5ic3A7SXTigJlzIG5ldmVyIHRvbyBzb29uIHRvIHJlcXVlc3QgYSBzbG90IG9uIHRo ZSBBREQgSUVURiAxMDggYWdlbmRhLCBwbGVhc2Ugc2VuZCBlbWFpbCB0bzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86YWRkLWNo YWlyc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDU2M0MxIj5hZGQtY2hhaXJzQGlldGYub3JnPC9zcGFuPjwv YT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7 d2l0aA0KIGhvdyBtdWNoIHRpbWUgeW914oCZZCBsaWtlIGFuZCB3aGF0IHlvdeKAmWxsIGJlIHBy ZXNlbnRpbmcgb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxp Z246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdl YmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0 ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBh dXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVs dmV0aWNhO2NvbG9yOmJsYWNrIj5UaGFua3MsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNh cmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5z OiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFk anVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBw eCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj5HbGVu biBEZWVuICZhbXA7IERhdmlkIExhd3JlbmNlIOKAkyB5b3VyIGZyaWVuZGx5IEFERCBjaGFpcnMg Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BC510184B5544A8C8D34D97E9C34033Acomcastcom_-- From nobody Mon Jun 22 23:11:35 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AE43A179A for ; Mon, 22 Jun 2020 23:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 cYqn5xaSt8Dw for ; Mon, 22 Jun 2020 23:11:31 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 C3BCD3A1799 for ; Mon, 22 Jun 2020 23:11:31 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id y2so4499533ioy.3 for ; Mon, 22 Jun 2020 23:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E/cwJ4sQO90rkf2Fd7LBv97GEppKzOb7Ajz2Op4hIfk=; b=Ub9gDGW34ZLA38kqq9Mkn5Dkw4EWHg8ITdR9/Atr6wOyWiPmz67yYZfFutm3GrJTzS kGyJVQj5PJ2NVD3yeFB0sXN3bySkKigDAYWZd2lj/tttkt6uy0XEGyGxz39Z1wm9ay2R iXmaEL+uKy7jNknkQmCvA8f1rcfVUW6N9GoxWIddqpVJAurYnRny8yl+9ezj1qv8QQQe W+3Kyr/c5d+Cg6/t5DkRUWdvJ9tNzqWdPcQvNiA1djTz1c8XdLst+TMTfbQg7njxnWL4 R2IzYiycZQdXM9UcdrjkGp9ooY+Tnwyz8VaKjsuvZaOCoMh2xlYMqdioSRtx5MphZBZO py4Q== 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:to:cc; bh=E/cwJ4sQO90rkf2Fd7LBv97GEppKzOb7Ajz2Op4hIfk=; b=eRg8fFB4XjimFk2TZvB2j3aFj9OahzHY3DiJ8Ip0LJhm6afhpzZvq+rrwuxjWWVj45 OwCZ4BRipLSmMKxo4DPMCCFzKsxhx4RJbT2siRAJOpt+kVgqFIma/+VKVLzqeqAjrYBo rP6mnbqthyRSUPenp7L4b8xAzJjwGgMo+oNBtjan9Lm2GNUF9SlmDPXmyp+eA+uoT7Y8 +L4FEwtJfT6ufYdAQLqKBXErCS29AoVNdC4M1w74jF+yUsTWqtUlvkGU9RM033QEfAnb xHGN2PJ8U7FqZ123x1Ju2XN3ifoLvvmplZbcoBcVgVYN/g/SGdLxsG+cNz+dOnWwPUB6 N4MA== X-Gm-Message-State: AOAM533lRxremmaDX+okJ8Ogi7lmdVYO4VU2Iosn02uARQ++hzbR2LRV PyOZdIn9v7tMV86WP54chgDotDlk8ejMRA2PXQT8BIa4Iwc= X-Google-Smtp-Source: ABdhPJzsiN28bzN+0kk+Ow2l8NAX6AJOV7QvAwVIez8ZRVFLlVgzIcAnkxzpjfEex9i64jRiknvyRG0CkN0mks79x+w= X-Received: by 2002:a05:6602:2c0a:: with SMTP id w10mr23471562iov.46.1592892690684; Mon, 22 Jun 2020 23:11:30 -0700 (PDT) MIME-Version: 1.0 References: <159247351170.10058.420472825533339226@ietfa.amsl.com> In-Reply-To: <159247351170.10058.420472825533339226@ietfa.amsl.com> From: tirumal reddy Date: Tue, 23 Jun 2020 11:41:19 +0530 Message-ID: To: ADD Mailing list Cc: Dan Wing , "Michael C. Richardson" , Mohamed Boucadair Content-Type: multipart/alternative; boundary="000000000000fe5f8105a8ba3a23" Archived-At: Subject: Re: [Add] New Version Notification for draft-reddy-add-server-policy-selection-03.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 06:11:33 -0000 --000000000000fe5f8105a8ba3a23 Content-Type: text/plain; charset="UTF-8" Hi all, We prepared an updated version of https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-03 to address comments from Vittorio. The draft has been updated to provide the reasons for filtering (1) malware (2) phishing (3) block-list due to a policy by the operator of the DNS server (4) censored blocking based on a requirement from an external entity. As a reminder, it discusses how a DNS client can authenticate it is connecting to a DoH/DoT server hosted by a specific organization (e.g., ISP). This information is cryptographically signed to attest its authenticity. It is particularly useful when the DoH/DoT server is insecurely discovered and prevents the client from connecting to an attackers server. Comments and suggestions are more than welcome. Cheers, -Tiru On Thu, 18 Jun 2020 at 15:15, wrote: > > A new version of I-D, draft-reddy-add-server-policy-selection-03.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF repository. > > Name: draft-reddy-add-server-policy-selection > Revision: 03 > Title: DNS Server Selection: DNS Server Information with > Assertion Token > Document date: 2020-06-17 > Group: Individual Submission > Pages: 24 > URL: > https://www.ietf.org/internet-drafts/draft-reddy-add-server-policy-selection-03.txt > Status: > https://datatracker.ietf.org/doc/draft-reddy-add-server-policy-selection/ > Htmlized: > https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-03 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-reddy-add-server-policy-selection > Diff: > https://www.ietf.org/rfcdiff?url2=draft-reddy-add-server-policy-selection-03 > > Abstract: > The document defines a mechanism that allows communication of DNS > resolver information to DNS clients for use in server selection > decisions. In particular, the document defines a mechanism for a DNS > server to communicate its filtering policy and privacy statement URL > to DNS clients. This information is cryptographically signed to > attest its authenticity. Such information is used for the selection > of DNS resolvers. Typically, evaluating the DNS privacy statement, > filtering policy, and the signatory, DNS clients with minimum human > intervention can select the DNS server that best supports the user's > desired privacy and filtering policy. > > This assertion is useful for encrypted DNS (e.g., DNS-over-TLS and > DNS-over-HTTPS) servers that are either public resolvers or are > discovered in a local network. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > --000000000000fe5f8105a8ba3a23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi all,

We prepared an updated version of https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-03 to address comments from Vittorio. The draft has been updated to provide= the reasons for filtering (1) malware (2) phishing (3) block-list due to a= policy by the operator of the DNS server (4) censored blocking=C2=A0based = on a requirement from an external entity.

As a reminder, it discusse= s how a DNS client can authenticate it is connecting to a DoH/DoT server ho= sted by a specific
organization (e.g., ISP). This information is crypto= graphically signed to attest its authenticity. It is particularly useful=C2=A0when the DoH/DoT server is insecurely discovered and prevents the cl= ient from connecting to an attackers server.

Comments and suggestion= s are more than welcome.

Cheers,
-Tiru

On Thu, 18 Jun 2020 at = 15:15, <internet-drafts@ietf= .org> wrote:

A new version of I-D, draft-reddy-add-server-policy-selection-03.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-add-server-policy= -selection
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNS Server Selection: DNS Server I= nformation with Assertion Token
Document date:=C2=A0 2020-06-17
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 24
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-red= dy-add-server-policy-selection-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-reddy-add-server-polic= y-selection/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-0= 3
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-reddy-add-server-p= olicy-selection
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-add= -server-policy-selection-03

Abstract:
=C2=A0 =C2=A0The document defines a mechanism that allows communication of = DNS
=C2=A0 =C2=A0resolver information to DNS clients for use in server selectio= n
=C2=A0 =C2=A0decisions.=C2=A0 In particular, the document defines a mechani= sm for a DNS
=C2=A0 =C2=A0server to communicate its filtering policy and privacy stateme= nt URL
=C2=A0 =C2=A0to DNS clients.=C2=A0 This information is cryptographically si= gned to
=C2=A0 =C2=A0attest its authenticity.=C2=A0 Such information is used for th= e selection
=C2=A0 =C2=A0of DNS resolvers.=C2=A0 Typically, evaluating the DNS privacy = statement,
=C2=A0 =C2=A0filtering policy, and the signatory, DNS clients with minimum = human
=C2=A0 =C2=A0intervention can select the DNS server that best supports the = user's
=C2=A0 =C2=A0desired privacy and filtering policy.

=C2=A0 =C2=A0This assertion is useful for encrypted DNS (e.g., DNS-over-TLS= and
=C2=A0 =C2=A0DNS-over-HTTPS) servers that are either public resolvers or ar= e
=C2=A0 =C2=A0discovered in a local network.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--000000000000fe5f8105a8ba3a23-- From nobody Tue Jun 23 22:31:11 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4723B3A080E for ; Tue, 23 Jun 2020 22:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 XfGoc_EGSswA for ; Tue, 23 Jun 2020 22:31:08 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 136E43A080C for ; Tue, 23 Jun 2020 22:31:07 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id k6so905355ili.6 for ; Tue, 23 Jun 2020 22:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ovy8DaWyofNjFm18gbksZEyMbFOMNdtIX0T/z6K7/sQ=; b=gvgdWniPMXy52ErPbH4kLJrLTn5lFrlHP9XIaAmspTAURa5cwmHbJcVWrN/JIG/ojy TR5qeJ29Y/QN2jfg3+1hJ00W+xHYVhr40YG3dO4oPDuEy+pEVtvERS1JbAp73PYKDvUU FHhmv/cZvMlIXeA4gkJwuN5dEgXJ/sy7jugilFQ4BSgsAUYklIU1cm9l2O9ZEwL2JuPK gnw6CPdsfv9KT1Ld+3LNHdwjNGA92nqUGdHXtzAO/Q7waoif2kRKmL9zdF1k5/2EibNX aW79sLk24cD3P0n9xxaRwmhjdqvZuWd7Q/8GXpJC6uRYAOfA8KOXQB2jevG++WyB85Yz QvPg== 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:to; bh=Ovy8DaWyofNjFm18gbksZEyMbFOMNdtIX0T/z6K7/sQ=; b=uNDfWZMvBmF5BPh4Ncldy06xSFDo7mFQBNfkbPRw208IiQbm1f0M+xxOvcJN5HsS3T 66kMX7qvRI1Yk6RtoZes6AN59DRlHNAd4QGz4QYYfX4CrdaX4bUBv20e1B4Q7KUl7QdI vzAXbjs6LL4Gi8UDVbzJp6TUGjrYSallCgXH6GQWtNQAOnspGEaA22nSjIJWiG5TF3kT 87ken9b682k0sw8GHnwVnDvgph8QWxN/YaDFUg15aBK9eIiLOWCwZKOBfrw3FPoDvV45 Azt3EWZS9EntHmFTcMy5EH8vLU+UhgmnEFKE6WKE7QPx4/aRX013DqoR1SYFwW49mf59 jxLw== X-Gm-Message-State: AOAM530MqNZ+/NvrcLCSRMAFsKlcnTCZof1hOj0udSkgcL+Y2ZVzlpcW GV0JFwHwrwLFcWLBFjbxWDHgThAY6ecTAxTbFRO4+51i X-Google-Smtp-Source: ABdhPJxD4tWGMN+Fkr+1op92PLGD8uHfJFw2m7Tm6kh5RrEHBbdUxsbmkRO4oIP4OmcZi6Q/9lN6e6UQk8VOckMVQqg= X-Received: by 2002:a05:6e02:d09:: with SMTP id g9mr27588215ilj.300.1592976666791; Tue, 23 Jun 2020 22:31:06 -0700 (PDT) MIME-Version: 1.0 References: <159289883315.6227.2187942590404503002@ietfa.amsl.com> In-Reply-To: <159289883315.6227.2187942590404503002@ietfa.amsl.com> From: tirumal reddy Date: Wed, 24 Jun 2020 11:00:54 +0530 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000005c12fd05a8cdc885" Archived-At: Subject: [Add] Fwd: New Version Notification for draft-reddy-add-enterprise-00.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 05:31:10 -0000 --0000000000005c12fd05a8cdc885 Content-Type: text/plain; charset="UTF-8" Hi all, This draft https://tools.ietf.org/html/draft-reddy-add-enterprise-00 discusses DoH/DoT deployment considerations for Enterprise networks. It discusses mechanisms to configure IT-owned, IoT and BYOD devices (with/without MDM) with the DoH/DoT server used by the Enterprise network. Comments and suggestions are welcome. Cheers, -Tiru ---------- Forwarded message --------- From: Date: Tue, 23 Jun 2020 at 13:23 Subject: New Version Notification for draft-reddy-add-enterprise-00.txt To: Dan Wing , Tirumaleswar Reddy.K < kondtir@gmail.com> A new version of I-D, draft-reddy-add-enterprise-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-reddy-add-enterprise Revision: 00 Title: DNS-over-HTTPS and DNS-over-TLS Server Deployment Considerations for Enterprise Networks Document date: 2020-06-23 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-reddy-add-enterprise-00.txt Status: https://datatracker.ietf.org/doc/draft-reddy-add-enterprise/ Htmlized: https://tools.ietf.org/html/draft-reddy-add-enterprise-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise Abstract: This document discusses DoH/DoT deployment considerations for Enterprise networks. It particularly sketches the required steps to use DNS-over-TLS (DoT) and/or DNS-over-HTTPS (DoH) server provided by the Enterprise network. One of the goals of the document is to assess to what extent existing tools can be used to provide such service. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000005c12fd05a8cdc885 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

This draft https://tools.ietf.= org/html/draft-reddy-add-enterprise-00 discusses DoH/DoT deployment con= siderations for
Enterprise networks. It discusses mechanisms to configur= e IT-owned, IoT and BYOD devices (with/without MDM) with the=C2=A0DoH/DoT s= erver used by the Enterprise network.

Comments and suggestions are w= elcome.

Cheers,
-Tiru

---------- Forwarded message ---------
Fro= m: <internet-drafts@ietf.org>
Date: Tue, 23 Jun 2= 020 at 13:23
Subject: New Version Notification for draft-reddy-add-enter= prise-00.txt
To: Dan Wing <dwing-ietf@fuggles.com>, Tirumaleswar Reddy.K <= kondtir@gmail.com>



A new version of I-D, draft-reddy-add-enterprise-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-add-enterprise Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNS-over-HTTPS and DNS-over-TLS Se= rver Deployment Considerations for Enterprise Networks
Document date:=C2=A0 2020-06-23
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-reddy-add-enterp= rise-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-reddy-add-enterprise/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-reddy-add-enterprise-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise


Abstract:
=C2=A0 =C2=A0This document discusses DoH/DoT deployment considerations for<= br> =C2=A0 =C2=A0Enterprise networks.=C2=A0 It particularly sketches the requir= ed steps to
=C2=A0 =C2=A0use DNS-over-TLS (DoT) and/or DNS-over-HTTPS (DoH) server prov= ided by
=C2=A0 =C2=A0the Enterprise network.

=C2=A0 =C2=A0One of the goals of the document is to assess to what extent e= xisting
=C2=A0 =C2=A0tools can be used to provide such service.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--0000000000005c12fd05a8cdc885-- From nobody Thu Jun 25 07:06:04 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADF53A0B81 for ; Thu, 25 Jun 2020 07:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 445tfmZztvG9 for ; Thu, 25 Jun 2020 07:06:00 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 C8A4E3A0B83 for ; Thu, 25 Jun 2020 07:05:59 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id o4so3288100lfi.7 for ; Thu, 25 Jun 2020 07:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=+1TIk6kB8TKW8zwdGBdSLPtzl4Oy8XQjFPPr2WvrJZw=; b=ujgB2QkcGHr9ayQD3l61Yf0nzu3fZ+r9Knqkqi79SFPl+sxVaCTOEjkZuVmU3qE+Gl vhZPkMOeqjlwiaDDHVWYLYjC4etK6Ilwrfn1N9J1kTTol409Gr6yXu9lYB12bihSsCZf FR/uQy2P/Ciu0Q1lKwD0B9lO1BehXKtV+gJZUoqd+QOGhd/F+Zsr7Llt8P2srBkChyZA gsQ8fttWzpaNjYa79UwrydyDVkKH54fVwy4wkoVtvv5KvEp6KGnt0Nwc8e3t+6JKq9EX FU/RKkfBl5LX0Jxvh00F7milgIOw0JgEXt1/zzhvSiCujEFaW1awRR4WL8MNnC0/3U+i inrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+1TIk6kB8TKW8zwdGBdSLPtzl4Oy8XQjFPPr2WvrJZw=; b=UdP81DyuYalSEjR4J9ajh1UUyNq0sSjBjIB9hxy9Kmdy6534aOBcu92TWyYgpkTdmA cajLSRZyLdxMtm9awLhsR86wq8dxDlVb9TawyFNgbKgHGh5Z2JxFB5/n6Uv6UGiQLxLH +jbBP2m/mjs3Um65cIQlqwijSUmOOoEcLKxLoYO0MezVxOegHxzjap/hS4SYSteT20bn 5yh08/K8S7dOb/r0n6RAAxI3aHaULXYmOjJ5+bG9sovRzr5uYuGDETPuEbjAu0EZ1a7C QI3XBK4+uctrtI3LlsqNyrveg7qLF/TWo3U5REuPAJPPsinyE1BczTvj3iBCCqxt+qVa h/TQ== X-Gm-Message-State: AOAM5330H0OVs++sOjRKmnkd28zHKVYubEEIwelhJIfCasBkn2UhQEH6 FxHAce/DlFyzr/DZ8MuIkrgPvgMtq+SiZXm7oM6L2rQvq90yiw== X-Google-Smtp-Source: ABdhPJwSUlSvoItbqW4gTYboF5mEYYNzuzo5nznhlvPKL4+V8itN0UCClnEJ+lxgfOP0poID2pK1+tbecXG6EtIT2Bk= X-Received: by 2002:ac2:4c2a:: with SMTP id u10mr18228970lfq.168.1593093957479; Thu, 25 Jun 2020 07:05:57 -0700 (PDT) MIME-Version: 1.0 From: Eric Rescorla Date: Thu, 25 Jun 2020 07:05:21 -0700 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000006e0b9605a8e91759" Archived-At: Subject: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 14:06:02 -0000 --0000000000006e0b9605a8e91759 Content-Type: text/plain; charset="UTF-8" Hi folks, As has been noted previously, the current Firefox DoH/TRR design bypasses the ISP resolver even if the ISP resolver supports DoH. I have just posted draft-rescorla-doh-cdisco-00, which describes a CNAME-based mechanism for discovering when a local resolver supports DoH/TRR. Firefox can then determine whether that resolver is on the TRR list and if so can use it in preference to generic resolver. The use of CNAME was chosen for pragmatic reasons (laid out in the draft). We're studying other designs but thought it would be a good idea to document this one. See: https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt -Ekr --0000000000006e0b9605a8e91759 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

As has been noted previously, the current= Firefox DoH/TRR design
bypasses the ISP resolver even if the ISP resolv= er supports DoH.

I have just posted draft-rescorla-doh-cdisco-00, wh= ich describes a
CNAME-based mechanism for discovering when a local resol= ver supports
DoH/TRR. Firefox can then determine whether that resolver i= s on the
TRR list and if so can use it in preference to generic resolver= . The
use of CNAME was chosen for pragmatic reasons (laid out in the dra= ft).
We're studying other designs but thought it would be a good ide= a
to document this one.

See: https://www.ietf.org/internet= -drafts/draft-rescorla-doh-cdisco-00.txt

-Ekr







--0000000000006e0b9605a8e91759-- From nobody Thu Jun 25 13:14:43 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39183A100C for ; Thu, 25 Jun 2020 13:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 Hh4uC3HtqS4l for ; Thu, 25 Jun 2020 13:14:29 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 CF9D23A0FE8 for ; Thu, 25 Jun 2020 13:14:28 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id u12so5731017qth.12 for ; Thu, 25 Jun 2020 13:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xQassPQScjee3bn4+z7fqB6ybXyMgzOYa3OnAEwOyrI=; b=IBX7afkVxL0PQ6hSmfhnX7sSnB/UzDEejI2CfqA5ZNLIESsvrqHoopJP5PoCde3BIY xRPASxxzMBhYii1XYQNWZl+RCf9207YZOGqLq8COXTEEiFFtWPdUWtLOVom2H7aC6rCm tsWelUADabxBz+h9Mq691cMMGb7f6Xfdp+cik1JuPH+1S2YphWvQX/6Dnw9t9lisQX7s rK4gAS0HNKFw0pOPxNKf3LteCV/Bg7l7T50gf/1uJbrEhUYA6EPXt8+Y+P/PFQ8oMkve RpOf/kxjdf/tAF8rdbdmbktITDQv40WkmpmCWdzxIPW5IDxYAqc9MXIQ4O1lr+0xsyp8 Hl+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xQassPQScjee3bn4+z7fqB6ybXyMgzOYa3OnAEwOyrI=; b=AgZXdIqJxo2PjjOKO679wY/V3lpuE+uFnW668fF892QrhsQQ++DK40mqTD4Lf1/cJu Mj5iQudhRhQ8KcApEieW6zCUxrn7cYfYbL/xBzfibZIBM/YbwCAeXYSH6MmqwXsvE9ZW fDMPzyqJsJD9RTcEg2ShA2S8/mTf9Q/I8hSdkP57rftFvdmgTnqFTE3GuzF3ikmm3XC9 v/5q6Z97V1dgYME//se5ddJJzw41luAHBl4X0sR80KtKasYnQHOoHyYeyhWQkrzVInC+ uh0TNv9ZG9isy2RvMzN0fT7XCpsMRcEAPFQrL9dePKjqjjD+BvolcGxbsUZBN6e15Tb9 vD0g== X-Gm-Message-State: AOAM533eqgbOdTfyboK1EnY4438RdlKNHu62RA9/BgEqgafG/YEKisM7 ZpwORNE4L0/lJE8iZi0CX40Dqj8fFoy8rbkrbyvQGN2VL7Q= X-Google-Smtp-Source: ABdhPJz8FbYWCw280M0X33Wo3/PuUmu8u/OY1oXoH28T2u6+2wq7QM/cozzN+YFphYcgbVdMDeFh1PvtC9rTIqYvmLY= X-Received: by 2002:ac8:32fd:: with SMTP id a58mr30729409qtb.321.1593116067554; Thu, 25 Jun 2020 13:14:27 -0700 (PDT) MIME-Version: 1.0 From: Alec Muffett Date: Thu, 25 Jun 2020 21:13:51 +0100 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000004ae86905a8ee3d6c" Archived-At: Subject: [Add] OONI Report: "DNS over TLS blocked in Iran" X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 20:14:42 -0000 --0000000000004ae86905a8ee3d6c Content-Type: text/plain; charset="UTF-8" Source: https://ooni.org/post/2020-iran-dot/ The locks are being screwed down, and it sounds like an opportunity for something more discreet, like DoH perhaps? - alec *DNS over TLS (DoT) is a network protocol that allows one to use DNS over TLS (i.e. with encryption and authentication of the remote DNS server).We investigated whether DoT works in Iran by gathering a list of 31 well-known DoT endpoints and running experiments from four distinct Iranian mobile and fixed-line Internet Service Providers (ISPs): MCI, TCI, Irancell, and Shatel.We discovered that:* - *57% of the endpoints are blocked on a least one ISP; * - *the blocking is not implemented uniformly across ISPs; * - *most blocking happens by interfering with the TLS handshake; * - *in some cases TLS handshake blocking seems to depend on the SNI, while in other cases it seems to depend strictly on the TCP endpoint being used; * - *forcing TLSv1.3 does not change the rate of successful TLS handshakes compared to letting the server choose a TLS version between v1.0 and v1.3. * *In this report, we share details from our experiments and findings.* (continues at https://ooni.org/post/2020-iran-dot/) -- http://dropsafe.crypticide.com/aboutalecm --0000000000004ae86905a8ee3d6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The locks are being screwed down, a= nd it sounds like an opportunity for something more discreet, like DoH perh= aps?

=C2=A0 - alec

DNS over= TLS (DoT) is a network protocol that allows one to use DNS over TLS (i.e. = with encryption and authentication of the remote DNS server).

We inv= estigated whether DoT works in Iran by gathering a list of 31 well-known Do= T endpoints and running experiments from four distinct Iranian mobile and f= ixed-line Internet Service Providers (ISPs): MCI, TCI, Irancell, and Shatel= .

We discovered that:
  • 57% of the endpoints are blo= cked on a least one ISP;
  • the blocking is not implemented= uniformly across ISPs;
  • most blocking happens by interfe= ring with the TLS handshake;
  • in some cases TLS handshake= blocking seems to depend on the SNI, while in other cases it seems to depe= nd strictly on the TCP endpoint being used;
  • forcing TLSv= 1.3 does not change the rate of successful TLS handshakes compared to letti= ng the server choose a TLS version between v1.0 and v1.3.
=
In this report, we share details from our experiments and findings.<= br>
(continues at=C2=A0https://ooni.org/post/2020-iran-dot/)
--0000000000004ae86905a8ee3d6c-- From nobody Thu Jun 25 18:24:33 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4150D3A10CA for ; Thu, 25 Jun 2020 18:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Yz+ERhD6; dkim=pass (1536-bit key) header.d=taugh.com header.b=RU5xmugk 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 Wp6-LUv03vs0 for ; Thu, 25 Jun 2020 18:24:30 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 D52F23A10C9 for ; Thu, 25 Jun 2020 18:24:29 -0700 (PDT) Received: (qmail 4200 invoked from network); 26 Jun 2020 01:24:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1065.5ef54e4c.k2006; bh=VrF7gaOA2MkwYxgB9VgPTbL980NInvyNXHst///mUaA=; b=Yz+ERhD6qOHd9T6DSn0qLFpcTflAgNSo4EZPpA0zROnqbTVmZEdu1cA6+rfs2tTFAMHoRsb6uOd0XqngVTjVB+TX/0jaThyqNTEv9XRsOHv56Q0k3goW8Q3albEPh1RhebOjyK18d1ArtoPL3I/gGhHIL6eOM2gM8pdZkb/rN26eM1RRZO69QIbsIaqyyhxdZ5HKp/De01A4QQXEKCPWcRz/keWvkPWXq1PNZFLXQt/p+g5aw7EVZwP2R6ETKwEH DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1065.5ef54e4c.k2006; bh=VrF7gaOA2MkwYxgB9VgPTbL980NInvyNXHst///mUaA=; b=RU5xmugkboh/Pcy1Opd7sHn1/C5PPaCMZHlUj5D8CYIlsU8hYOh2/YfAeCiPzn0jXF9t3nXzdLiyeeeftaPp9QtiErbxrLO6kqInpFaWsUHGG9aKo7tWuDz93st/hMGnS+4lwOy/F8ga69kp+sO7PYWG7D5SE0JlbKU35oyOhiko83NgQinPHZJJIfiXw4Q1O9tQdqmLGzgK49IzaQIkFs2oW8kLH1Evc1bKvESQUjGOJwmzE4Uh728IkxlusU4l Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 26 Jun 2020 01:24:28 -0000 Received: by ary.qy (Postfix, from userid 501) id CDF041BB3FB9; Thu, 25 Jun 2020 21:24:27 -0400 (EDT) Date: 25 Jun 2020 21:24:27 -0400 Message-Id: <20200626012427.CDF041BB3FB9@ary.qy> From: "John Levine" To: add@ietf.org Cc: ekr@rtfm.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 01:24:31 -0000 In article you write: >I have just posted draft-rescorla-doh-cdisco-00, which describes a >CNAME-based mechanism for discovering when a local resolver supports >DoH/TRR. ... It looks like you're mixing together two questions: "I want an index into my local DoH table" and "where's a DoH resolver?" They're both plausible questions but I wouldn't mix them together. For the first question, a CNAME lookup to doh-resolver.arpa (a name we can easily ensure never exists in the public DNS) seems OK. For the second question, I'd do a URI lookup of _doh._tcp.doh-resolver.arpa or if you don't trust your local crudware resolver to handle URI, a TXT record. In both cases you can't use DNSSEC but that seems inevitable for this kind of bootstrap. R's, John From nobody Fri Jun 26 00:38:28 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5AA3A11B0 for ; Fri, 26 Jun 2020 00:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 99Od-Sr4wTbn for ; Fri, 26 Jun 2020 00:38:26 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 F0B023A11A4 for ; Fri, 26 Jun 2020 00:38:25 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id w9so7620129ilk.13 for ; Fri, 26 Jun 2020 00:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V81qbLw0nLjsOV3ud/AhWBnj+OlYLTe59kZ5wrWsoiU=; b=DsXDGLAoIPpnR8zkn5cdtneSDXCM6aVlRsBkxBtUnfbIbAx7Z6qXoaBzkoEG6Wd+9U DktFXvsp2fkVN0DjDQr0EkA7Pl3wUJUrTKFJ/tzV2aMN6vgGwUgImsiA2clz46C1a0sY dj/RLumS6OEVg4Oe3zWxXsgS2UdBMHwVuzGsoBaeIa1FQh13gCeGYOkNZesxH4Q/PGZ8 U9E0rADDHKOZv+a3mGfd1M5Sba0jhVtvyBlZNcM+8ALIr3WHF3Jd0y0s1W9+rAIs2/+z Kud4wnRdkdX4LHYyxcLgkhsU+m6fmixXukFtdQHT2h07isK6zdwLOkTRBkm58mTIwFCG s4Og== 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:to:cc; bh=V81qbLw0nLjsOV3ud/AhWBnj+OlYLTe59kZ5wrWsoiU=; b=Hq5k9Tm5sRbfB+uJqLMUVq12xvB5HxuwGWud2Dwk1G2q1ah0rXWER8JLagGe6aa8kP MSxyW70mYM2Hlif+wVc3V4HGz/2q45tKhWvXhue/9bGlttEVz3bAIjkbysYr6XecMa+M cFERKC0qMTYkZ0kEjwi5PfQ6pmQqorfo26YRxpqtH/O2geODGEOUrZ12Pr0j+xGCM8Ab 3UamtMe/3E+J/sJTz3yKV/N0X3FJvjRmzYyaHE8YZrDlACvzMj0dctAOt5Hbd22l582h WqV81ekgBBz75weCf0q7Hzsic13dSdVDBc1wW54u77KiFyzPBB9neVZZ9+/EUKAk+uDh 2cKg== X-Gm-Message-State: AOAM530VxnmWd65IOablXcmKhGARtAVEVPK7E4a2ZwrtmjWcbGXncKM0 vpPATrsb1WaxLur9DOXnf6rc1GYMIP80AOjzQao9ebZZBLc= X-Google-Smtp-Source: ABdhPJyQ2C93HzhwrXBrJm7kyWHgbWUAeoXGb+iJD5qIb5UmRfcGFd7ZMMpdthtM1CruqgMijs4rDWikeREEPClrmsI= X-Received: by 2002:a92:79cb:: with SMTP id u194mr1822783ilc.161.1593157105129; Fri, 26 Jun 2020 00:38:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: tirumal reddy Date: Fri, 26 Jun 2020 13:08:13 +0530 Message-ID: To: Eric Rescorla Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000052a6d905a8f7cb8f" Archived-At: Subject: Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 07:38:28 -0000 --00000000000052a6d905a8f7cb8f Content-Type: text/plain; charset="UTF-8" On Thu, 25 Jun 2020 at 19:36, Eric Rescorla wrote: > Hi folks, > > As has been noted previously, the current Firefox DoH/TRR design > bypasses the ISP resolver even if the ISP resolver supports DoH. > > I have just posted draft-rescorla-doh-cdisco-00, which describes a > CNAME-based mechanism for discovering when a local resolver supports > DoH/TRR. Firefox can then determine whether that resolver is on the > TRR list and if so can use it in preference to generic resolver.. The > use of CNAME was chosen for pragmatic reasons (laid out in the draft). > We're studying other designs but thought it would be a good idea > to document this one. > > See: https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt > 2. Some consumer-grade middleboxes (e.g., WiFI routers) may block unknown RRTypes. The data here is quite old and limited, but still not particularly promising. Now-a-days several security vendors are offering security services in home networks (co-located on the home router or on a seperate device). McAfee security service co-located on Home routers does not block unknown RRTypes. -Tiru > > -Ekr > > > > > > > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000052a6d905a8f7cb8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 25 Jun 2020 at 19:36, Eric Re= scorla <ekr@rtfm.com> wrote:
<= /div>
Hi = folks,

As has been noted previously, the current Firefox DoH/TRR des= ign
bypasses the ISP resolver even if the ISP resolver supports DoH.
=
I have just posted draft-rescorla-doh-cdisco-00, which describes a
C= NAME-based mechanism for discovering when a local resolver supports
DoH/= TRR. Firefox can then determine whether that resolver is on the
TRR list= and if so can use it in preference to generic resolver.. The
use of CNA= ME was chosen for pragmatic reasons (laid out in the draft).
We're s= tudying other designs but thought it would be a good idea
to document th= is one.

See: https://www.ietf.org/internet-= drafts/draft-rescorla-doh-cdisco-00.txt

    2.  Some co=
nsumer-grade middleboxes (e.g., WiFI routers) may block
        unknown RRTypes.  The data here is quite old and limited, but
        still not particularly promising.

No= w-a-days several security vendors are offering security services in home ne= tworks (co-located on the home router or on a seperate device). McAfee secu= rity service co-located on Home routers does not block unknown RRTypes.

-Tiru



-Ekr







--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000052a6d905a8f7cb8f-- From nobody Fri Jun 26 14:28:48 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44873A0CA0 for ; Fri, 26 Jun 2020 14:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=apple.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 a8OOtPFnVY62 for ; Fri, 26 Jun 2020 14:28:43 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 87F7A3A0C9F for ; Fri, 26 Jun 2020 14:28:43 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 05QLJiY2021158 for ; Fri, 26 Jun 2020 14:28:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=wwE1jOG1zf8Ty7UnIvq3tCA6uT9Ch9AQeqMUQc4j9bA=; b=JjZ2T04O2a5yyJ6292xA0bNL5WHJAO51gNUrr45weNqWXSP15W/9boD/QFkfwC7+vzR4 kufJQ91ImCAidplltdtyDwmAbl8WkEwhvAm6Irm1+YsTB7SSiDUv1BM7ike91rPOcOXS NzS2XnK1jXPe7JFdJ+ucKedcXj4rTRw9gbiaXudA/PYGQ7GgcmHrbAPstBuMYPcXA7Xe r1eTxCHKhv+c3W0LG4lbFR2RgnE2mbp/G/pkA/Of9FMSZkkXSQGG7pC42SAOH3njkLSF 2eqZ84dqNqEFLjB5nOeOrbj4BfuHTlXqUXDIIgbZ8kHY1mnCMBLh20En7bim2wr9DY0Z +g== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 31uurxu9st-21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 26 Jun 2020 14:28:41 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QCJ00L36YBTD0H0@rn-mailsvcp-mta-lapp03.rno.apple.com> for add@ietf.org; Fri, 26 Jun 2020 14:28:41 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QCJ00P00Y75PV00@rn-mailsvcp-mmp-lapp02.rno.apple.com> for add@ietf.org; Fri, 26 Jun 2020 14:28:41 -0700 (PDT) X-Va-A: X-Va-T-CD: 5daaeb935bbe0e8d25090cf6b04f92b4 X-Va-E-CD: c10540ee026d34ce700dbe4e87c40fd4 X-Va-R-CD: b9c8a414f1e97e5ac01914532a054dbe X-Va-CD: 0 X-Va-ID: cddb7cf6-e8b1-447f-b2eb-c4fa311e50c1 X-V-A: X-V-T-CD: 5daaeb935bbe0e8d25090cf6b04f92b4 X-V-E-CD: c10540ee026d34ce700dbe4e87c40fd4 X-V-R-CD: b9c8a414f1e97e5ac01914532a054dbe X-V-CD: 0 X-V-ID: 581553de-194d-484e-914d-a8744d08c19c X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-26_12:2020-06-26, 2020-06-26 signatures=0 Received: from [17.234.81.96] (unknown [17.234.81.96]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QCJ009EWYBSK300@rn-mailsvcp-mmp-lapp02.rno.apple.com> for add@ietf.org; Fri, 26 Jun 2020 14:28:41 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_AF7AFC73-4664-46B2-963A-2BD54B737F6B" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Message-id: <637E7D0A-AF96-4D7D-B7CB-69E04F995F6F@apple.com> Date: Fri, 26 Jun 2020 14:28:40 -0700 To: ADD Mailing list X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-26_12:2020-06-26, 2020-06-26 signatures=0 Archived-At: Subject: [Add] Encrypted DNS support in iOS and macOS X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 21:28:47 -0000 --Apple-Mail=_AF7AFC73-4664-46B2-963A-2BD54B737F6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I want to share some relevant updates with the ADD working group about = encrypted DNS support in iOS and macOS. In the iOS 14 and macOS 11 betas, DoH and DoT are both natively = supported by the system DNS resolvers. These are technologies that many = apps have already been using on iOS and macOS via VPN provider APIs or = by embedding application-specific DNS resolver code. Now that these = protocols are built into the operating system, these use cases can move = over to a system-provided path that provides greater efficiency and = tighter integration with built-in APIs that provide Happy Eyeballs and = other features. These videos released as part of the Worldwide Developer Conference = cover details of how encrypted DNS can be used by app developers: Build trust through better privacy: = https://developer.apple.com/videos/play/wwdc2020/10676 = (Timestamps = 11:55-13:50) Enable encrypted DNS: = https://developer.apple.com/videos/play/wwdc2020/10047/ = One of the key goals of integrating encrypted DNS into the operating = system is ensuring that when users get the privacy and security benefits = of encrypted DNS, they don=E2=80=99t have to face breakages for key use = cases that require interaction with local DNS providers and = private/enterprise DNS servers. Beyond that, the APIs are designed to = make it easy to migrate to automatic use of encrypted DNS=E2=80=94the = goal of the ADD working group. To summarize the WWDC videos, there are three different ways that = encrypted DNS is being used in the iOS and macOS betas: Provide a system-wide encrypted DNS resolver selection, as an = alternative to providing a =E2=80=9CVPN=E2=80=9D configuration that just = configures DNS Require encrypted DNS within an app (along with a resolver to prefer if = no encrypted resolver is otherwise available), as an alternative to apps = embedding their own DNS resolution code Start automatically discovering designated resolvers for domains that = advertise a DoH URI I=E2=80=99m including details for each of these three mechanisms below. Best, Tommy System-wide: (https://developer.apple.com/documentation/networkextension/dns_settings = )= (https://developer.apple.com/documentation/devicemanagement/dnssettings = ) A system-wide DNS configuration can be provided either by an app that = uses the NetworkExtension framework, or a configuration profile that can = be installed by the user or by an enterprise Mobile Device Management = solution. These configurations can select an encrypted DNS server for = all domains or only a subset of domains; and can apply to all networks = or a subset of networks and network types. System-wide configurations require an explicit opt-in by a user through = Settings, or configuration of a managed device by an enterprise or = similar organization. To this end, it is equivalent to how a VPN applies = on the operating system. System-wide configurations are meant to not interfere with critical = services that need to use the local network resolver. Captive network = interaction and cellular network services continue to use the resolver = configured by the local network. Similarly, if a VPN is active, the VPN = resolver takes precedence for whichever domains it handles. Note that = VPN providers can now indicate that an encrypted DNS resolver should be = used within the VPN tunnel as well. Since these system-wide configurations are based on a user opt-in, there = is no mechanism for a local network to disable them. If the connections = are blocked, resolution will fail rather than sending out in the clear. = This is because these configurations are equivalent to using a = VPN=E2=80=94they represent a security policy that the system enforces on = behalf of the user. App opt-in: = (https://developer.apple.com/documentation/network/nwparameters/privacycon= text/3548851-requireencryptednameresolution = ) An app can choose to opt into encrypted DNS for resolution within its = process. This is compatible with any system API that does name = resolution, whether a connect-by-name API or in standard APIs like = getaddrinfo(). The opt-in here is specifically about requiring that specific DNS = resolutions use some encrypted DNS protocol (DoH or DoT). Since many = devices at first won=E2=80=99t be using encrypted DNS, the app can = provide a DNS resolver config to use as a =E2=80=9Cfallback=E2=80=9D. = This config indicates a DoH or DoT server to use if and only if the = resolution wouldn=E2=80=99t otherwise use DoH or DoT. If there is a = system-wide configuration, or a VPN configuration, or automatic = detection of DoH or DoT, then the app will use those resolvers instead. It is important that applications can enable a policy to require = encrypted DNS without needing to rewrite their connection logic or adopt = entirely different APIs for name resolution. It is also important that = as they require encrypted DNS, they have a path forward to be compatible = with user preferences around DNS and mechanisms for automatic use of = encrypted DNS. If the efforts of ADD are successful in defining standard = ways to make encrypted DNS more universal, any app that adopts these = APIs should be ready. Automatic discovery: The iOS and macOS betas also start going down the road of automatic = discovery by implementing some of the mechanisms described in = https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html = . = I=E2=80=99m including the details below to explain any traffic you see = being generated by these betas, and to explain how to interact with the = system if you want to experiment. The system isn=E2=80=99t doing any = automatic use of locally-hosted DoH/DoT servers at this point. Specifically, the system: Starts sending out requests for HTTPS(HTTPSSVC) records along with A and = AAAA queries. This is currently using the testing RR type of 65479. The = plan is to use the official allocation once that is made after the wire = format is finalized. It parses out a DoH URI template with a key value = of 7. This value will also change to one in the correct = first-come-first-served range when we change RR type numbers. Relies on validating that a given zone allows designation to a DoH = server using the mechanism described in Section 3.3, Mutual Confirmation = with PvD JSON. Along with the client support, Apple is running a DoH server = (https://doh.dns.apple.com/dns-query = ) for a very limited set of names = within apple.com . This is not a general-purpose DoH = resolver, but one that is only meant to be used as a designated resolver = for Apple properties. The configuration is at = https://doh.dns.apple.com/.well-known/pvd/dns-query = , and the = confirmation is performed by checking https://apple.com/.well-known/pvd = . If connections to the automatically discovered DoH resolvers fail, the = system currently fails over to use traditional DNS. If the user has selected a system-wide DoH resolver, that will take = precedence. However, any app opt-in prefers using the discovered = resolver to the app-provided resolver. --Apple-Mail=_AF7AFC73-4664-46B2-963A-2BD54B737F6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello,

I want to share some relevant updates = with the ADD working group about encrypted DNS support in iOS and = macOS.

In the iOS 14 and macOS 11 betas, DoH = and DoT are both natively supported by the system DNS resolvers. These = are technologies that many apps have already been using on iOS and macOS = via VPN provider APIs or by embedding application-specific DNS resolver = code. Now that these protocols are built into the operating system, = these use cases can move over to a system-provided path that provides = greater efficiency and tighter integration with built-in APIs that = provide Happy Eyeballs and other features.

These videos released as part = of the Worldwide Developer Conference cover details of how encrypted DNS = can be used by app developers:

Build trust through better = privacy: https://developer.apple.com/videos/play/wwdc2020/10676 = ;(Timestamps 11:55-13:50)

One of the key goals of integrating encrypted DNS into the = operating system is ensuring that when users get the privacy and = security benefits of encrypted DNS, they don=E2=80=99t have to face = breakages for key use cases that require interaction with local DNS = providers and private/enterprise DNS servers. Beyond that, the APIs are = designed to make it easy to migrate to automatic use of encrypted = DNS=E2=80=94the goal of the ADD working group.

To summarize the WWDC videos, = there are three different ways that encrypted DNS is being used in the = iOS and macOS betas:
  1. Provide a system-wide encrypted DNS resolver selection, as an = alternative to providing a =E2=80=9CVPN=E2=80=9D configuration that just = configures DNS
  2. Require encrypted DNS within an app (along with a resolver to = prefer if no encrypted resolver is otherwise available), as an = alternative to apps embedding their own DNS resolution code
  3. Start automatically discovering designated resolvers for = domains that advertise a DoH URI
I=E2=80=99m = including details for each of these three mechanisms below.

Best,
Tommy



System-wide:
(https://developer.apple.com/documentation/networkextension/dns_= settings)
(https://developer.apple.com/documentation/devicemanagement/dnss= ettings)
A system-wide DNS configuration = can be provided either by an app that uses the NetworkExtension = framework, or a configuration profile that can be installed by the user = or by an enterprise Mobile Device Management solution. These = configurations can select an encrypted DNS server for all domains or = only a subset of domains; and can apply to all networks or a subset of = networks and network types.

System-wide configurations = require an explicit opt-in by a user through Settings, or configuration = of a managed device by an enterprise or similar organization. To this = end, it is equivalent to how a VPN applies on the operating = system.

System-wide configurations are meant to = not interfere with critical services that need to use the local network = resolver. Captive network interaction and cellular network services = continue to use the resolver configured by the local network. Similarly, = if a VPN is active, the VPN resolver takes precedence for whichever = domains it handles. Note that VPN providers can now indicate that an = encrypted DNS resolver should be used within the VPN tunnel as = well.

Since these system-wide configurations are based on a user = opt-in, there is no mechanism for a local network to disable them. If = the connections are blocked, resolution will fail rather than sending = out in the clear. This is because these configurations are equivalent to = using a VPN=E2=80=94they represent a security policy that the system = enforces on behalf of the user.

App opt-in:
(https://developer.apple.com/documentation/network/nwparameters/= privacycontext/3548851-requireencryptednameresolution)
An app can choose to opt into encrypted DNS for resolution = within its process. This is compatible with any system API that does = name resolution, whether a connect-by-name API or in standard APIs like = getaddrinfo().

The opt-in here is specifically about = requiring that specific DNS resolutions use some encrypted DNS protocol = (DoH or DoT). Since many devices at first won=E2=80=99t be using = encrypted DNS, the app can provide a DNS resolver config to use as a = =E2=80=9Cfallback=E2=80=9D. This config indicates a DoH or DoT server to = use if and only if the resolution wouldn=E2=80=99t otherwise use DoH or = DoT. If there is a system-wide configuration, or a VPN configuration, or = automatic detection of DoH or DoT, then the app will use those resolvers = instead.

It is important that applications can = enable a policy to require encrypted DNS without needing to rewrite = their connection logic or adopt entirely different APIs for name = resolution. It is also important that as they require encrypted DNS, = they have a path forward to be compatible with user preferences around = DNS and mechanisms for automatic use of encrypted DNS. If the efforts of = ADD are successful in defining standard ways to make encrypted DNS more = universal, any app that adopts these APIs should be ready.

Automatic = discovery:

The iOS and macOS betas also start = going down the road of automatic discovery by implementing some of the = mechanisms described in https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00= .html. I=E2=80=99m including the details below to explain any = traffic you see being generated by these betas, and to explain how to = interact with the system if you want to experiment. The system isn=E2=80=99= t doing any automatic use of locally-hosted DoH/DoT servers at this = point.

Specifically, the system:
  • Starts sending out requests for HTTPS(HTTPSSVC) records along = with A and AAAA queries. This is currently using the testing RR type of = 65479. The plan is to use the official allocation once that is made = after the wire format is finalized. It parses out a DoH URI template = with a key value of 7. This value will also change to one in the correct = first-come-first-served range when we change RR type numbers.
  • Relies on validating that a given zone allows designation to = a DoH server using the mechanism described in Section 3.3, Mutual = Confirmation with PvD JSON.
Along with the = client support, Apple is running a DoH server (https://doh.dns.apple.com/dns-query) for a very = limited set of names within apple.com. This is not a = general-purpose DoH resolver, but one that is only meant to be used as a = designated resolver for Apple properties. The configuration is at https://doh.dns.apple.com/.well-known/pvd/dns-query,= and the confirmation is performed by checking https://apple.com/.well-known/pvd.

If = connections to the automatically discovered DoH resolvers fail, the = system currently fails over to use traditional DNS.

If the user = has selected a system-wide DoH resolver, that will take precedence. = However, any app opt-in prefers using the discovered resolver to the = app-provided resolver.

= --Apple-Mail=_AF7AFC73-4664-46B2-963A-2BD54B737F6B-- From nobody Fri Jun 26 14:46:24 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DB73A0CCE for ; Fri, 26 Jun 2020 14:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=apple.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 rLu8I_XUjpcV for ; Fri, 26 Jun 2020 14:46:20 -0700 (PDT) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 76E1E3A0CCD for ; Fri, 26 Jun 2020 14:46:20 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 05QLaJ44028609; Fri, 26 Jun 2020 14:46:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=TEcli7rBfUw7dyb5x+h7pzk9JncVObDXdaeiR9UVg5M=; b=X0J6BXbX1RIpx1YCSNLftYEVc7OH+7FeRMnT7U/t75MulL5B14xglRwLIxtb8ECSaLe3 atTskXB0e3e52/srVJlzLVQlDZwOYSO0VNgOqyjCMlYhPXdyR/6QXEbxPKbqea1AtfKe 3qtZQvYgzso5gULONDZJsTJ5/zPOy6SOHxFveetKEGOUwLALHQNjfgc6g7ty93vThQM1 rjBQpN4w1p/2cVJMzl5MrziyT7fIRswVMKrLAHcUtawLe/s11iaUJqJLzGbrvM3uxoxX TkLjohNvFqTyUq0q5rdkINtumNXjUWCLVc3R+4svZxPESG/nw6ZdCfIkYq/rW9wnp3N5 5g== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by nwk-aaemail-lapp01.apple.com with ESMTP id 31uut6ke8q-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 26 Jun 2020 14:46:20 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QCJ00SXTZ57YJ70@rn-mailsvcp-mta-lapp01.rno.apple.com>; Fri, 26 Jun 2020 14:46:19 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QCJ00Z00YZZA100@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Fri, 26 Jun 2020 14:46:19 -0700 (PDT) X-Va-A: X-Va-T-CD: 1682cb633e8834c32dfc165e32ca8e8d X-Va-E-CD: e62e75a901ccfe6f540d297acf2a8a70 X-Va-R-CD: 058881bde0e11f2926a580f2a100d551 X-Va-CD: 0 X-Va-ID: a9a53d7c-7114-4c8a-9c96-3ad2d1b31832 X-V-A: X-V-T-CD: 1682cb633e8834c32dfc165e32ca8e8d X-V-E-CD: e62e75a901ccfe6f540d297acf2a8a70 X-V-R-CD: 058881bde0e11f2926a580f2a100d551 X-V-CD: 0 X-V-ID: 3548e422-3082-4d27-8bc3-f9bff59a65de X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-26_12:2020-06-26, 2020-06-26 signatures=0 Received: from [17.234.81.96] (unknown [17.234.81.96]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QCJ00GIJZ56LG00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Fri, 26 Jun 2020 14:46:19 -0700 (PDT) From: Tommy Pauly Message-id: <1AB2782B-87C0-4991-8703-AE2C98411AFC@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_812D50F8-DA17-4557-B434-C2605008FE2E" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Fri, 26 Jun 2020 14:46:18 -0700 In-reply-to: Cc: ADD Mailing list To: Eric Rescorla References: X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-26_12:2020-06-26, 2020-06-26 signatures=0 Archived-At: Subject: Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 21:46:22 -0000 --Apple-Mail=_812D50F8-DA17-4557-B434-C2605008FE2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ekr, Thanks for sharing this draft. Very exciting to see this step forward in = supporting the automatic use of DoH. Regarding the choice of using DNS + CNAME, I completely understand and = sympathize with the practical deployment aspects. Going forward, I=E2=80=99= d like to see if collectively we can use a record that gives a full DoH = URI. Your draft does reference the option of using HTTPS RRs for this, = as Tommy Jensen has proposed in = https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html#name-= discovery-of-doh-capabiliti = . In my email to this list just a bit ago, I mentioned that we=E2=80=99re = starting to request these RR types (well, the older version for = HTTPSSVC, but will be updated) on the iOS and macOS betas. Hopefully we = can measure based on that how much RRType interference exists in = networks. I=E2=80=99d be curious to hear what kinds of measurements the = Mozilla team is taking in this space, as you are able to share. I=E2=80=99d also be interested to have a discussion here about the = acceptable ranges for breakage. Certainly, if the percentage of home = wifi setups that fails with a new RRType is very high, it=E2=80=99s a = problem. However, if the percentage is lower but still significant (say, = 5%?), we can consider the tradeoff of solutions. Intolerance to passing = unknown RRTypes is one way that this could break; however, there are = many other ways a local wifi router could potentially interfere. For = example, a wifi router might not recurse to the ISP's DNS resolver, but = some other resolver (which if it is 1.1.1.1 or 8.8.8.8 would support = DoH, but could be something else that doesn=E2=80=99t). There will = always be *some* tail of networks that won=E2=80=99t work, even with the = CNAME approach; and I=E2=80=99d like to see a long-term solution that = allows for richer information than just a hostname. Thoughts? Best, Tommy > On Jun 25, 2020, at 7:05 AM, Eric Rescorla wrote: >=20 > Hi folks, >=20 > As has been noted previously, the current Firefox DoH/TRR design > bypasses the ISP resolver even if the ISP resolver supports DoH. >=20 > I have just posted draft-rescorla-doh-cdisco-00, which describes a > CNAME-based mechanism for discovering when a local resolver supports > DoH/TRR. Firefox can then determine whether that resolver is on the > TRR list and if so can use it in preference to generic resolver.. The > use of CNAME was chosen for pragmatic reasons (laid out in the draft). > We're studying other designs but thought it would be a good idea > to document this one. >=20 > See: = https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt = >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add --Apple-Mail=_812D50F8-DA17-4557-B434-C2605008FE2E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ekr,

Thanks for = sharing this draft. Very exciting to see this step forward in supporting = the automatic use of DoH.

Regarding the choice of using DNS + CNAME, I completely = understand and sympathize with the practical deployment aspects. Going = forward, I=E2=80=99d like to see if collectively we can use a record = that gives a full DoH URI. Your draft does reference the option of using = HTTPS RRs for this, as Tommy Jensen has proposed in https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00= .html#name-discovery-of-doh-capabiliti.

In my email to this list just a bit = ago, I mentioned that we=E2=80=99re starting to request these RR types = (well, the older version for HTTPSSVC, but will be updated) on the iOS = and macOS betas. Hopefully we can measure based on that how much RRType = interference exists in networks. I=E2=80=99d be curious to hear what = kinds of measurements the Mozilla team is taking in this space, as you = are able to share.

I=E2=80=99d also be interested to have a discussion here = about the acceptable ranges for breakage. Certainly, if the percentage = of home wifi setups that fails with a new RRType is very high, it=E2=80=99= s a problem. However, if the percentage is lower but still significant = (say, 5%?), we can consider the tradeoff of solutions. Intolerance to = passing unknown RRTypes is one way that this could break; however, there = are many other ways a local wifi router could potentially interfere. For = example, a wifi router might not recurse to the ISP's DNS resolver, but = some other resolver (which if it is 1.1.1.1 or 8.8.8.8 would support = DoH, but could be something else that doesn=E2=80=99t). There will = always be *some* tail of networks that won=E2=80=99t work, even with the = CNAME approach; and I=E2=80=99d like to see a long-term solution that = allows for richer information than just a hostname. Thoughts?

Best,
Tommy

On Jun 25, 2020, at 7:05 AM, = Eric Rescorla <ekr@rtfm.com> wrote:

Hi folks,

As has been noted = previously, the current Firefox DoH/TRR design
bypasses = the ISP resolver even if the ISP resolver supports DoH.

I have just posted draft-rescorla-doh-cdisco-00, which = describes a
CNAME-based mechanism for discovering when a = local resolver supports
DoH/TRR. Firefox can then = determine whether that resolver is on the
TRR list and if = so can use it in preference to generic resolver.. The
use = of CNAME was chosen for pragmatic reasons (laid out in the draft).
We're studying other designs but thought it would be a good = idea
to document this one.

See:= https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-= 00.txt

-Ekr







--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

= --Apple-Mail=_812D50F8-DA17-4557-B434-C2605008FE2E-- From nobody Fri Jun 26 15:08:47 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05D43A0CE7 for ; Fri, 26 Jun 2020 15:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6_w1WJ2_0n8 for ; Fri, 26 Jun 2020 15:08:43 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 731CF3A0CE5 for ; Fri, 26 Jun 2020 15:08:43 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id d21so5944479lfb.6 for ; Fri, 26 Jun 2020 15:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dYEbaBvVagTr55yGbDCHNtDgqo36vxg7OGumMrJOjt8=; b=STfn0w2fIy4dbflD2ojpk9wEAW4QRO56TBCObj48MwpdlSlJefV8LtAcA036qFiO0p lTU4qj8iT1LaXdiAgcqXuw+8o29EWlDmv3sYsofNV6uutrdX618Y6hDZYSgXR0sTODky KglZW3HJWgb3IQl6mpL9M4aPE7LkqGBY75RW72Tfwmp4SPu/3yEHs0X5Ldho+V9MavDV v/OyxKxDdwIMT85AqN3dJzRz/ZpcXDI8TUh2N2nXwFPMB5BEtVWd20MUVDV8RJFbFaio eBRsBLhmLlPGnGN86V+d6WIInKqm2FCljfMpQbdnihcRrqauVRxC0O248hkEPiRHLqRM YH8g== 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:to:cc; bh=dYEbaBvVagTr55yGbDCHNtDgqo36vxg7OGumMrJOjt8=; b=tLwe3jt8C4uIPP8lttwTSkzbmqgYf9RJ2vuURyDnEzcX1wYywo3okiBJeBm+IWEVqY qE37h4vZi5X21f1/nRduQJIzt5XgcxDUEsDf9FfpzgBQMC6F3fEBZEa+TJ0CzPqxGhNP CAdLc7HgCr2eWHDJHfXIuhhiyDD4Sk7UAVS+lTh4XCVf5Emh4yRUsqjbVLzwzL8H2om1 sFoq6G/rsqDYfJf3lxIH7F3AGfsaDLTZLRe31NkO2m+/F4n37GUYgVqg9Hv2zNUvQ9E+ LXf+TFl4iZOLj21FwGBtOPG4T+tWM+Z52LJXYweDFKvDLp3KVLZEEWWymuOoWo52ttgZ cqFA== X-Gm-Message-State: AOAM530H157JwcOHDSvhPfFepV1UdM1Zlf8tfhXVbKQUv2fl6sdQJRRT KaB1APq7N+HYbZWlfIEC06urY4r385cbAT3wf+pbOA== X-Google-Smtp-Source: ABdhPJyJLQnjFbonY1CrGuDt506uVmspwQxtqkX/04OrDYcB2ten/JsuzqHpIciYpbOYGqdz4O9OiRfFT6pv1F0BSvI= X-Received: by 2002:ac2:4c2a:: with SMTP id u10mr2954740lfq.168.1593209321436; Fri, 26 Jun 2020 15:08:41 -0700 (PDT) MIME-Version: 1.0 References: <1AB2782B-87C0-4991-8703-AE2C98411AFC@apple.com> In-Reply-To: <1AB2782B-87C0-4991-8703-AE2C98411AFC@apple.com> From: Eric Rescorla Date: Fri, 26 Jun 2020 15:08:05 -0700 Message-ID: To: Tommy Pauly Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000a872ca05a903f325" Archived-At: Subject: Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 22:08:46 -0000 --000000000000a872ca05a903f325 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 26, 2020 at 2:46 PM Tommy Pauly wrote: > Hi Ekr, > > Thanks for sharing this draft. Very exciting to see this step forward in > supporting the automatic use of DoH. > > Regarding the choice of using DNS + CNAME, I completely understand and > sympathize with the practical deployment aspects. Going forward, I=E2=80= =99d like > to see if collectively we can use a record that gives a full DoH URI. You= r > draft does reference the option of using HTTPS RRs for this, as Tommy > Jensen has proposed in > https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html#name= -discovery-of-doh-capabiliti > . > > In my email to this list just a bit ago, I mentioned that we=E2=80=99re s= tarting > to request these RR types (well, the older version for HTTPSSVC, but will > be updated) on the iOS and macOS betas. Hopefully we can measure based on > that how much RRType interference exists in networks. I=E2=80=99d be curi= ous to > hear what kinds of measurements the Mozilla team is taking in this space, > as you are able to share. > We're just starting the work to collect data, but we expect to publish it once we have it. I=E2=80=99d also be interested to have a discussion here about the acceptab= le > ranges for breakage. Certainly, if the percentage of home wifi setups tha= t > fails with a new RRType is very high, it=E2=80=99s a problem. However, if= the > percentage is lower but still significant (say, 5%?), we can consider the > tradeoff of solutions. Intolerance to passing unknown RRTypes is one way > that this could break; however, there are many other ways a local wifi > router could potentially interfere. For example, a wifi router might not > recurse to the ISP's DNS resolver, but some other resolver (which if it i= s > 1.1.1.1 or 8.8.8.8 would support DoH, but could be something else that > doesn=E2=80=99t). > Sure. Though note that it's proxying to a non-TRR resolver then whether it filters CNAMEs doesn't matter because the intent here would be to use a default TRR. I'd be interested in hearing what tradeoffs you see here. Other than inelegance, what's problematic about the CNAME approach? There will always be *some* tail of networks that won=E2=80=99t work, even = with the > CNAME approach; and I=E2=80=99d like to see a long-term solution that all= ows for > richer information than just a hostname. Thoughts? > Well, as I said when this group was first formed, we should start by figuring out what we are trying to accomplish and the threat model. For the TRR case, it's not actually the hostname we are interested in but rather the identity of the network-associated TRR. The hostname is just a convenient lookup key. If an ISP told us they wanted to use ".invalid" that wouldn't be a problem for us as long as it was unique. The scenario you seem to be interested in is one in which the user joins the network and then learns that the associated Do53 resolver supports DoH and then connects to it with whatever coordinates that resolver (or DHCP or whatever) provides. That clearly is not useful in the 3552 threat model which assumes that the attacker entirely controls the network because the attacker can just send their own resolver coordinates. That isn't to say that there aren't more limited but still realistic threat models where this would be useful, but I think you should start by describing those. -Ekr > Best, > Tommy > > On Jun 25, 2020, at 7:05 AM, Eric Rescorla wrote: > > Hi folks, > > As has been noted previously, the current Firefox DoH/TRR design > bypasses the ISP resolver even if the ISP resolver supports DoH. > > I have just posted draft-rescorla-doh-cdisco-00, which describes a > CNAME-based mechanism for discovering when a local resolver supports > DoH/TRR. Firefox can then determine whether that resolver is on the > TRR list and if so can use it in preference to generic resolver.. The > use of CNAME was chosen for pragmatic reasons (laid out in the draft). > We're studying other designs but thought it would be a good idea > to document this one. > > See: https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.tx= t > > -Ekr > > > > > > > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > > > --000000000000a872ca05a903f325 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jun 26, 2020 at 2:46 PM Tommy= Pauly <tpauly@apple.com> wro= te:
Hi Ekr,

Thanks for shari= ng this draft. Very exciting to see this step forward in supporting the aut= omatic use of DoH.

Regarding the choice of using D= NS + CNAME, I completely understand and sympathize with the practical deplo= yment aspects. Going forward, I=E2=80=99d like to see if collectively we ca= n use a record that gives a full DoH URI. Your draft does reference the opt= ion of using HTTPS RRs for this, as Tommy Jensen has proposed in https://tools.ietf.org/id/dr= aft-pauly-add-resolver-discovery-00.html#name-discovery-of-doh-capabiliti.

<= /blockquote>

We're just starting the work to collect= data, but we expect to publish it once we have it.


=C2=A0
Sure. Though note that it's proxying to a non-TRR resolv= er then whether it filters CNAMEs doesn't matter because the intent her= e would be to use a default TRR.

=
I'd be interested in hearing what tradeoffs = you see here. Other than inelegance, what's problematic about the CNAME= approach?


<= div style=3D"overflow-wrap: break-word;">
There will always be *some* = tail of networks that won=E2=80=99t work, even with the CNAME approach; and= I=E2=80=99d like to see a long-term solution that allows for richer inform= ation than just a hostname. Thoughts?

Well, as I said when this group was first formed, we should start by= figuring out what we are trying to accomplish and the threat model.

For the TRR case, it's not actually the hostnam= e we are interested in but rather the identity of the network-associated TR= R. The hostname is just a convenient lookup key. If an ISP told us they wan= ted to use "<isp-name>.invalid" that wouldn't be a prob= lem for us as long as it was unique.

The scenario = you seem to be interested in is one in which the user joins the network and= then learns that the associated Do53 resolver supports DoH and then connec= ts to it with whatever coordinates that resolver (or DHCP or whatever) prov= ides. That clearly is not useful in the 3552 threat model which assumes tha= t the attacker entirely controls the network because the attacker can just = send their own resolver coordinates. That isn't to say that there aren&= #39;t more limited but still realistic threat models where this would be us= eful, but I think you should start by describing those.

<= /div>
-Ekr


Be= st,
Tommy

On Jun 25, 2= 020, at 7:05 AM, Eric Rescorla <ekr@rtfm.com> wrote:

<= /blockquote>

--000000000000a872ca05a903f325-- From nobody Fri Jun 26 16:10:52 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1AE3A0D03 for ; Fri, 26 Jun 2020 16:10:50 -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, SPF_HELO_NONE=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 GPFSv-5Gl_vb for ; Fri, 26 Jun 2020 16:10:49 -0700 (PDT) Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 121343A0D01 for ; Fri, 26 Jun 2020 16:10:48 -0700 (PDT) Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa4.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 05QNAk3o014321 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 26 Jun 2020 23:10:47 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 26 Jun 2020 16:10:45 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Fri, 26 Jun 2020 16:10:45 -0700 From: Paul Hoffman To: ADD Mailing list Thread-Topic: [Ext] [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers Thread-Index: AQHWSvnIzvNV3+WnzUi6g9v0kfBTC6jr/W2A Date: Fri, 26 Jun 2020 23:10:44 +0000 Message-ID: <0478F516-47AE-419E-B95D-F546A2F12ABB@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_01FD4943-D480-46B6-B782-E246539EF882"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-26_12:2020-06-26, 2020-06-26 signatures=0 Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 23:10:51 -0000 --Apple-Mail=_01FD4943-D480-46B6-B782-E246539EF882 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 25, 2020, at 7:05 AM, Eric Rescorla wrote: > As has been noted previously, the current Firefox DoH/TRR design > bypasses the ISP resolver even if the ISP resolver supports DoH. >=20 > I have just posted draft-rescorla-doh-cdisco-00, which describes a > CNAME-based mechanism for discovering when a local resolver supports > DoH/TRR. Firefox can then determine whether that resolver is on the > TRR list and if so can use it in preference to generic resolver.. The > use of CNAME was chosen for pragmatic reasons (laid out in the draft). > We're studying other designs but thought it would be a good idea > to document this one. >=20 > See: = https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt A particular relevant part of this draft for this WG is: 3.2. Why a CNAME? Most other proposed designs (e.g., [I-D.pp-add-resinfo] and [I-D.pp-add-stub-upgrade], and [I-D.pauly-add-resolver-discovery]) use new RRtypes. While this may be the right answer eventually, it is less convenient for immediate deployment, for several reasons: 1. It is somewhat more difficult (though not impossible) to look up new RRTypes on the client and provision them on the ISP resolver. 2. Some consumer-grade middleboxes (e.g., WiFI routers) may block unknown RRTypes. The data here is quite old and limited, but still not particularly promising. The choice to use a CNAME does have one major drawback: it does not let us provide the URL template but only the name of the resolver. This is not a problem for our system in practice because Firefox will only connect to resolvers on a preconfigured list and thus will use the CNAME as a lookup key for that list. The Mozilla team is working to measure the rate of new RRType interference and may revise this approach depending on the results of that. [[OPEN ISSUE: We are working to measure the rate of new RRType interference and may revise this approach depending on the results of that.]] Point 1 feels overstated. The clients we are talking about here are = modern web browsers, which can clearly write whatever they want in their = DNS queries. I cannot imagine that an ISP resolver that has to also act = as an authoritative server would have any restriction on what RRtypes = they can provision. Point 2 is interesting, and I'm glad to hear that Mozilla and Apple are = looking into it. The key part of that is what is "unknown" to any such = middlebox. The research should definitely look at whether CNAME is in = the list of unknown RRtypes, given that stub resolvers rarely send CNAME = queries. The major drawback that is listed does indeed seem major for use cases = other than Mozilla's TRR. This WG has been discussing other use cases, = so it feels restrictive to consider a solution that is focused on just = that one use case unless the middlebox problem is shown to be crippling = to the use of new and more flexible RRtypes. --Paul Hoffman= --Apple-Mail=_01FD4943-D480-46B6-B782-E246539EF882 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwNjI2MjMxMDQzWjAvBgkqhkiG9w0BCQQxIgQg3c0O2aMCyxie97OnxVOQdeJ8DXOY 6EDCZCuLLi+061IwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAEHVycM7RW3owoF8ImCJsI/oa+zic+cUHU1+9Cra7utI Kffe14AZHW4vM/X/CaiCEC8kXA7gDDYNiCO4LtN6bWr1t1TBmNErApb16mokRBcd5YNsZdLEizj5 FniLMHrVc/APyahpptzy2YxJ0azgJHA29gWj2jZ8uUQiB7sX8frjUB1q+Rd+LgTXxrwHWuUszkaA F+bZe2kJPoEcvTspjK5srCnv0wrSDw22206ZfO5HNnQTfN+KvLQwM4AIJextfvziGfL8PFXchdE1 cCZHKkfK/2MDvLrqQ+vnpuYlO4ALM+ARhSBk00+FqxeYB9MaKQODXxdenGgSmeUJMcENreIAAAAA AAA= --Apple-Mail=_01FD4943-D480-46B6-B782-E246539EF882-- From nobody Fri Jun 26 17:05:00 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053D53A0D27 for ; Fri, 26 Jun 2020 17:04:59 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeEZqaWwrlrm for ; Fri, 26 Jun 2020 17:04:57 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672F93A0CB3 for ; Fri, 26 Jun 2020 17:04:57 -0700 (PDT) Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 55222B0588; Sat, 27 Jun 2020 00:04:54 +0000 (UTC) From: Paul Vixie To: Tommy Pauly , add@ietf.org Cc: ADD Mailing list , Eric Rescorla Date: Sat, 27 Jun 2020 00:04:52 +0000 Message-ID: <2013869.BjYadG0qc2@linux-9daj> Organization: none In-Reply-To: References: <1AB2782B-87C0-4991-8703-AE2C98411AFC@apple.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 00:04:59 -0000 On Friday, 26 June 2020 22:08:05 UTC Eric Rescorla wrote: > ... Other than inelegance, what's problematic about the CNAME approach? inelegance is permanent, accretive, and earns compound interest. we ought not dismiss inelegance as the basis for reluctance. inelegance is not inevitable nor is it automatically acceptable. > ... > > The scenario you seem to be interested in is one in which the user joins > the network and then learns that the associated Do53 resolver supports DoH > and then connects to it with whatever coordinates that resolver (or DHCP or > whatever) provides. That clearly is not useful in the 3552 threat model > which assumes that the attacker entirely controls the network because the > attacker can just send their own resolver coordinates. That isn't to say > that there aren't more limited but still realistic threat models where this > would be useful, but I think you should start by describing those. as we describe them, we should also describe their scale, their age, and their likely lifespan. the 3552 threat model, while it does use the term 'pervasive', is nowhere near as common as the SASE (secure access service edge) operations model, nor will it ever be. if apps who want to do their own DNS treat any DoH failure as an attack, and start an arms race of spy-vs-spy bypass along the lines of Tor, that's going to feel problematic to any of us whose privately owned securely operated edge networks have a local-only DNS policy. RESINFO could probably get better results by using TXT, because of long tail problems. but ultimately we have to pick a default assumption that we can act on when secure resolver discovery fails. "OMG it's a 3552 attack" is not the only interpretation we could think of for this. it's entirely possible that the most engineering solution to the discovery problem is to fail hard when the middlebox prevents authenticated policy negotiation, to force middlebox upgrades. i know that "tough love" is a hard sell, but "assume 3552 attack" is also a form of tough love. -- Paul From nobody Fri Jun 26 17:36:44 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F083A08E6 for ; Fri, 26 Jun 2020 17:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6wPTGcAXHMs for ; Fri, 26 Jun 2020 17:36:40 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 673203A0820 for ; Fri, 26 Jun 2020 17:36:40 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id o4so6082589lfi.7 for ; Fri, 26 Jun 2020 17:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d6Fa56m7GOr2Ih87QoCDKCTmgeI2qJCoJ1740+OG6wc=; b=EePKAS2C9UXMVf451OAZp+dgjXKNEJNOuGASv1lAaWLj8kCmnFxUOPd5MCY5TE1TFV PMh+u+yHsklvy7QitKC2Lw/bDISlV7XPV1SjFyP+grBVNSO5iYlSEFtw91OAgFGz4/kD /27PvyqoR+5oNPyXJ1+XpE3GAYTnoj4qczQt6uZa8r014R7h1NubxjLBhPU9CFnxdban R7Myfa0aG77QeoUPDhJPH0y0dtKcZgfl+7eCrQO8VeuXlvPVnWpKfM5xd9lyLqw8FiCt fMSq21Z0tUb1t5mjLO0tNQn6XiKZiQ9oVriz+JLq7n/1eYUHn9VtdNOkOiDujKXfnsaq +Xbw== 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:to:cc; bh=d6Fa56m7GOr2Ih87QoCDKCTmgeI2qJCoJ1740+OG6wc=; b=JqJ94J7/6lKd6iTmXOW/Csx5eVwSxobD73Q7ZwO60VoVumXxk77J7v4qzYpljOyp/I nIABYRmYpqtowNGMARDlKj793qsuSPX/tFFqdLtUvFa5lvXMrO39EmlcskxHx6L+zMQh nNovOlwCYkdfZqUjSDsZuLBGa0lHeagnvU0Aw+sMhwMAHtv3dZlIJeAlVOx90DGqmrxt X8WM9LuvWTw6kRlKcBzsTd8LpDmSipJqDqN3Du6t8ktOCb2kP4UWE4YerwXJdCdHuyGN VL1HqAfbE9oBdwDSRIdBWMjWmG1VfcsY6B6396dwT6jKEmb4pmPXzfccrUYPwYweoo7u PIVA== X-Gm-Message-State: AOAM531zj29744bP1Xm4LBKEnsq1HR9oA0KX0O43WqlMfMO8iDXMNv4V 5ZGbMHffw44YVBrMSp7JAT4hsZ3KU/FRW8sgzNtUTw== X-Google-Smtp-Source: ABdhPJzhyo/f4HK6beiJK9yCYqQ1SSM3NQvjqH/tolAl7libQ2L6cpQu298w9JOliJD2kHcJrsYaowxWepDoaOzl1nQ= X-Received: by 2002:ac2:5226:: with SMTP id i6mr3305273lfl.55.1593218198451; Fri, 26 Jun 2020 17:36:38 -0700 (PDT) MIME-Version: 1.0 References: <0478F516-47AE-419E-B95D-F546A2F12ABB@icann.org> In-Reply-To: <0478F516-47AE-419E-B95D-F546A2F12ABB@icann.org> From: Eric Rescorla Date: Fri, 26 Jun 2020 17:36:02 -0700 Message-ID: To: Paul Hoffman Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000c4d5ca05a9060451" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 00:36:43 -0000 --000000000000c4d5ca05a9060451 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 26, 2020 at 4:11 PM Paul Hoffman wrote: > On Jun 25, 2020, at 7:05 AM, Eric Rescorla wrote: > > > As has been noted previously, the current Firefox DoH/TRR design > > bypasses the ISP resolver even if the ISP resolver supports DoH. > > > > I have just posted draft-rescorla-doh-cdisco-00, which describes a > > CNAME-based mechanism for discovering when a local resolver supports > > DoH/TRR. Firefox can then determine whether that resolver is on the > > TRR list and if so can use it in preference to generic resolver.. The > > use of CNAME was chosen for pragmatic reasons (laid out in the draft). > > We're studying other designs but thought it would be a good idea > > to document this one. > > > > See: > https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt > > A particular relevant part of this draft for this WG is: > > 3.2. Why a CNAME? > > Most other proposed designs (e.g., [I-D.pp-add-resinfo] and > [I-D.pp-add-stub-upgrade], and [I-D.pauly-add-resolver-discovery]) > use new RRtypes. While this may be the right answer eventually, it > is less convenient for immediate deployment, for several reasons: > > 1. It is somewhat more difficult (though not impossible) to look up > new RRTypes on the client and provision them on the ISP resolver. > > 2. Some consumer-grade middleboxes (e.g., WiFI routers) may block > unknown RRTypes. The data here is quite old and limited, but > still not particularly promising. > > The choice to use a CNAME does have one major drawback: it does not > let us provide the URL template but only the name of the resolver. > This is not a problem for our system in practice because Firefox will > only connect to resolvers on a preconfigured list and thus will use > the CNAME as a lookup key for that list. The Mozilla team is working > to measure the rate of new RRType interference and may revise this > approach depending on the results of that. > > [[OPEN ISSUE: We are working to measure the rate of new RRType > interference and may revise this approach depending on the results of > that.]] > > Point 1 feels overstated. The clients we are talking about here are modern > web browsers, which can clearly write whatever they want in their DNS > queries. "clearly" is doing a lot of work here. Sure, it's just software so we could do this. However, Firefox uses the system resolver and in particular calls getaddrinfo(). So while yes, we could in theory write our own resolver or plumb to the OS-specific more flexible interfaces (e.g. res_query()) up to the part of the code that needs this information. Hence, as I said, "somewhat more difficult (though not impossible)". I cannot imagine that an ISP resolver that has to also act as an > authoritative server would have any restriction on what RRtypes they can > provision. > I do not operate such a resolver so I cannot speak to this point. Point 2 is interesting, and I'm glad to hear that Mozilla and Apple are > looking into it. The key part of that is what is "unknown" to any such > middlebox. The research should definitely look at whether CNAME is in the > list of unknown RRtypes, given that stub resolvers rarely send CNAME > queries. > > The major drawback that is listed does indeed seem major for use cases > other than Mozilla's TRR. This WG has been discussing other use cases, so > it feels restrictive to consider a solution that is focused on just that > one use case unless the middlebox problem is shown to be crippling to the > use of new and more flexible RRtypes. > We haven't asked the WG to consider this draft. As I said in my message, we thought it would be useful to document it, hence the draft. -Ekr --000000000000c4d5ca05a9060451 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jun 26, 2020 at 4:11 PM Paul = Hoffman <paul.hoffman@icann.or= g> wrote:
On Jun 25, 2020, at 7:05 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> As has been noted previously, the current Firefox DoH/TRR design
> bypasses the ISP resolver even if the ISP resolver supports DoH.
>
> I have just posted draft-rescorla-doh-cdisco-00, which describes a
> CNAME-based mechanism for discovering when a local resolver supports > DoH/TRR. Firefox can then determine whether that resolver is on the > TRR list and if so can use it in preference to generic resolver.. The<= br> > use of CNAME was chosen for pragmatic reasons (laid out in the draft).=
> We're studying other designs but thought it would be a good idea > to document this one.
>
> See: https://www.ietf.org/= internet-drafts/draft-rescorla-doh-cdisco-00.txt

A particular relevant part of this draft for this WG is:

3.2.=C2=A0 Why a CNAME?

=C2=A0 =C2=A0Most other proposed designs (e.g., [I-D.pp-add-resinfo] and =C2=A0 =C2=A0[I-D.pp-add-stub-upgrade], and [I-D.pauly-add-resolver-discove= ry])
=C2=A0 =C2=A0use new RRtypes.=C2=A0 While this may be the right answer even= tually, it
=C2=A0 =C2=A0is less convenient for immediate deployment, for several reaso= ns:

=C2=A0 =C2=A01.=C2=A0 It is somewhat more difficult (though not impossible)= to look up
=C2=A0 =C2=A0 =C2=A0 =C2=A0new RRTypes on the client and provision them on = the ISP resolver.

=C2=A0 =C2=A02.=C2=A0 Some consumer-grade middleboxes (e.g., WiFI routers) = may block
=C2=A0 =C2=A0 =C2=A0 =C2=A0unknown RRTypes.=C2=A0 The data here is quite ol= d and limited, but
=C2=A0 =C2=A0 =C2=A0 =C2=A0still not particularly promising.

=C2=A0 =C2=A0The choice to use a CNAME does have one major drawback: it doe= s not
=C2=A0 =C2=A0let us provide the URL template but only the name of the resol= ver.
=C2=A0 =C2=A0This is not a problem for our system in practice because Firef= ox will
=C2=A0 =C2=A0only connect to resolvers on a preconfigured list and thus wil= l use
=C2=A0 =C2=A0the CNAME as a lookup key for that list.=C2=A0 The Mozilla tea= m is working
=C2=A0 =C2=A0to measure the rate of new RRType interference and may revise = this
=C2=A0 =C2=A0approach depending on the results of that.

=C2=A0 =C2=A0[[OPEN ISSUE: We are working to measure the rate of new RRType=
=C2=A0 =C2=A0interference and may revise this approach depending on the res= ults of
=C2=A0 =C2=A0that.]]

Point 1 feels overstated. The clients we are talking about here are modern = web browsers, which can clearly write whatever they want in their DNS queri= es.

"clearly" is doing a lot of = work here. Sure, it's just software so we could do this. However, Firef= ox uses the system resolver and in particular calls getaddrinfo(). So while= yes, we could in theory write our own resolver or plumb to the OS-specific= more flexible interfaces (e.g. res_query()) up to the part of the code tha= t needs this information. Hence, as I said, "somewhat more difficult (= though not impossible)".


I cannot imagine that an ISP r= esolver that has to also act as an authoritative server would have any rest= riction on what RRtypes they can provision.

=
I do not operate such a resolver so I cannot speak to this point.
=


Point 2 is interesting, and I'm glad to hear that Mozilla and Apple are= looking into it. The key part of that is what is "unknown" to an= y such middlebox. The research should definitely look at whether CNAME is i= n the list of unknown RRtypes, given that stub resolvers rarely send CNAME = queries.

The major drawback that is listed does indeed seem major for use cases othe= r than Mozilla's TRR. This WG has been discussing other use cases, so i= t feels restrictive to consider a solution that is focused on just that one= use case unless the middlebox problem is shown to be crippling to the use = of new and more flexible RRtypes.

We ha= ven't asked the WG to consider this draft. As I said in my message, we = thought it would be useful to document it, hence the draft.
<= br>
-Ekr

--000000000000c4d5ca05a9060451-- From nobody Fri Jun 26 17:48:16 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5993A0917 for ; Fri, 26 Jun 2020 17:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaPEwdGzWi5i for ; Fri, 26 Jun 2020 17:48:12 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24943A0914 for ; Fri, 26 Jun 2020 17:48:11 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id 9so12118631ljc.8 for ; Fri, 26 Jun 2020 17:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mW17HAql1VvWf7NleRvv9iTUwlGke4yRCliUU6MdDSA=; b=XRK3jpWvUkJKQe4kEmvwkX4yw5dRCiATLNczAwqbhLsH/1EUvvVQr4TTy76YBBRhpN /C2zqphn69PiK+nHqj/hKfHuBY5tBDVav6+ZaEK031HBddteUmsJFO0H2Wmv3wLkedVj hHu0N6Gje8oGBzBiIFIdgI/JQ/lHwlCJSa1QCrUQyptaLcHvnYdWaZf1cVd9yGv6WrzQ kUsP7O9ZEPejPN9Uaw53cRTemQBeUKZ8dCftaIyalGrRd4dDuJ7SZCwcincWTIBjDRIE siuocJQ7T5QGJSzKEp77MyKomdb7Mf58ET56XTUdIXNKWC11S1SeFuNcAzK1JN6u3oiA EXiw== 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:to:cc; bh=mW17HAql1VvWf7NleRvv9iTUwlGke4yRCliUU6MdDSA=; b=ZVmFC24e4YO/rOTHcP2NQqLlQ7X+T5+7D/Gjd7nBEgSg3DjcTj+FaLly4m79S9rgOO V4Q8vbZjFZvO4ZoXQImPOlTlygWpx3WPWR9SK1bRPhCnJ5Qz63T3kB2trpIFe3/iovXb T592BC5wyt2HkHSYoYvKgfeC61dAbLZVBrmueIFMKJbHjNmtfkUUZqQVP4iz3d6ndyq4 md8P5r17RgNis9kRlWYR8b9w9RmfJKHCvpj57DeQPShIa+XYDd32wfe+PE3jFE2Eu+6L z62uQELSdJeiTQLvFDmg1f85wzQrO40dTTYSs/nozyF8G0fs259c94Fq4yuuGK2za+2N pTxg== X-Gm-Message-State: AOAM532kLdqiAQ6kShQEcjRDS17xbphPAQLo2Jyq9ahLjyooZkGyArk3 xPUQVlWQpOF2Mg+BUXYHZfI+GkSgYW4OR9+KgXwDew== X-Google-Smtp-Source: ABdhPJxSSS907dDpqD2EiQ+qGNA+xSEJLWuHvrnjsAytoJbqe1r4kIP68G79rp4615AWoUwlyVn0yZfJo+7ObY5A+Bw= X-Received: by 2002:a2e:2a42:: with SMTP id q63mr2870380ljq.265.1593218890020; Fri, 26 Jun 2020 17:48:10 -0700 (PDT) MIME-Version: 1.0 References: <1AB2782B-87C0-4991-8703-AE2C98411AFC@apple.com> <2013869.BjYadG0qc2@linux-9daj> In-Reply-To: <2013869.BjYadG0qc2@linux-9daj> From: Eric Rescorla Date: Fri, 26 Jun 2020 17:47:34 -0700 Message-ID: To: Paul Vixie Cc: Tommy Pauly , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000fd4f4005a9062d74" Archived-At: Subject: Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 00:48:15 -0000 --000000000000fd4f4005a9062d74 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 26, 2020 at 5:04 PM Paul Vixie wrote: > On Friday, 26 June 2020 22:08:05 UTC Eric Rescorla wrote: > > ... Other than inelegance, what's problematic about the CNAME approach? > > inelegance is permanent, accretive, and earns compound interest. we ought > not > dismiss inelegance as the basis for reluctance. inelegance is not > inevitable > nor is it automatically acceptable. > > > ... > > > > The scenario you seem to be interested in is one in which the user joins > > the network and then learns that the associated Do53 resolver supports > DoH > > and then connects to it with whatever coordinates that resolver (or DHCP > or > > whatever) provides. That clearly is not useful in the 3552 threat model > > which assumes that the attacker entirely controls the network because the > > attacker can just send their own resolver coordinates. That isn't to say > > that there aren't more limited but still realistic threat models where > this > > would be useful, but I think you should start by describing those. > > as we describe them, we should also describe their scale, their age, and > their > likely lifespan. the 3552 threat model, while it does use the term > 'pervasive', is nowhere near as common as the SASE (secure access service > edge) operations model, nor will it ever be. if apps who want to do their > own > DNS treat any DoH failure as an attack, and start an arms race of > spy-vs-spy > bypass along the lines of Tor, that's going to feel problematic to any of > us > whose privately owned securely operated edge networks have a local-only > DNS > policy. > > RESINFO could probably get better results by using TXT, because of long > tail > problems. but ultimately we have to pick a default assumption that we can > act > on when secure resolver discovery fails. "OMG it's a 3552 attack" is not > the > only interpretation we could think of for this. it's entirely possible > that > the most engineering solution to the discovery problem is to fail hard > when > the middlebox prevents authenticated policy negotiation, to force > middlebox > upgrades. i know that "tough love" is a hard sell, but "assume 3552 > attack" is > also a form of tough love. > Hi Paul, I think this response perhaps conflates two somewhat different issues, namely CNAME versus authenticated policy propagation. Ignoring the question of CNAME for the moment, if a device joins a network and gets its configuration from that network (e.g., via DHCP), then it is trusting that network to provide the configuration. So, the question then becomes what benefit is obtained if that network supplies a Do[TH] server rather than a Do53 server. In the 3552 model, we assume the attacker has complete control of the network and can therefore supply its own server, so it's not clear what the security benefit is. Conversely, if the network is totally secure and trusted, then it's *also* not clear what the security benefit is. So, if we are to have unauthenticated discovery of Do[TH] servers, then we must have some other threat model. For instance we might think that the attacker can read all packets but for some reason can't impersonate the DHCP server. What I'm saying is that we should start by laying out what that threat model is and then we can define what, if any, technical measures add security benefit in that threat model. That would be true even if we knew that there weren't middleboxes which tampered with new record types. Two more points, if I may: 1. Where this interfaces with the question of CNAME versus RESINFO is that RESINFO is much more flexible, but (as above) it's not clear we can securely make use of this flexibility. 2. It's worth nothing that there are scenarios where the device can get authenticated network configuration (for instance, if the device is managed and has had some sort of authentication key installed). The comments above do not apply to this scenario but rather to the scenario where you have a naive device joining a network. -Ekr --000000000000fd4f4005a9062d74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jun 26, 2020 at 5:04 PM Paul = Vixie <paul@redbarn.org> wrot= e:
On Friday, 26= June 2020 22:08:05 UTC Eric Rescorla wrote:
> ... Other than inelegance, what's problematic about the CNAME appr= oach?

inelegance is permanent, accretive, and earns compound interest. we ought n= ot
dismiss inelegance as the basis for reluctance. inelegance is not inevitabl= e
nor is it automatically acceptable.

> ...
>
> The scenario you seem to be interested in is one in which the user joi= ns
> the network and then learns that the associated Do53 resolver supports= DoH
> and then connects to it with whatever coordinates that resolver (or DH= CP or
> whatever) provides. That clearly is not useful in the 3552 threat mode= l
> which assumes that the attacker entirely controls the network because = the
> attacker can just send their own resolver coordinates. That isn't = to say
> that there aren't more limited but still realistic threat models w= here this
> would be useful, but I think you should start by describing those.

as we describe them, we should also describe their scale, their age, and th= eir
likely lifespan. the 3552 threat model, while it does use the term
'pervasive', is nowhere near as common as the SASE (secure access s= ervice
edge) operations model, nor will it ever be. if apps who want to do their o= wn
DNS treat any DoH failure as an attack, and start an arms race of spy-vs-sp= y
bypass along the lines of Tor, that's going to feel problematic to any = of us
whose privately owned securely operated edge networks have a local-only DNS=
policy.

RESINFO could probably get better results by using TXT, because of long tai= l
problems. but ultimately we have to pick a default assumption that we can a= ct
on when secure resolver discovery fails. "OMG it's a 3552 attack&q= uot; is not the
only interpretation we could think of for this. it's entirely possible = that
the most engineering solution to the discovery problem is to fail hard when=
the middlebox prevents authenticated policy negotiation, to force middlebox=
upgrades. i know that "tough love" is a hard sell, but "assu= me 3552 attack" is
also a form of tough love.

Hi Paul,

I= think this response perhaps conflates two somewhat different issues,
na= mely CNAME versus authenticated policy propagation.

Ignoring the que= stion of CNAME for the moment, if a device joins a
network and gets its = configuration from that network (e.g., via DHCP),
then it is trusting th= at network to provide the configuration. So, the
question then becomes w= hat benefit is obtained if that network
supplies a Do[TH] server rather = than a Do53 server. In the 3552 model,
we assume the attacker has comple= te control of the network and can
therefore supply its own server, so it= 's not clear what the security
benefit is. Conversely, if the networ= k is totally secure and trusted,
then it's *also* not clear what the= security benefit is.

So, if we are to have unauthenticated discover= y of Do[TH] servers,
then we must have some other threat model. For inst= ance we might
think that the attacker can read all packets but for some = reason
can't impersonate the DHCP server. What I'm saying is tha= t we should
start by laying out what that threat model is and then we ca= n define
what, if any, technical measures add security benefit in that t= hreat
model. That would be true even if we knew that there weren'tmiddleboxes which tampered with new record types.


Two more poi= nts, if I may:

1. Where this interfaces with the question of CNAME v= ersus RESINFO
is that RESINFO is much more flexible, but (as above) it&#= 39;s not
clear we can securely make use of this flexibility.

2. I= t's worth nothing that there are scenarios where the device
can get = authenticated network configuration (for instance, if
the device is mana= ged and has had some sort of authentication key
installed). The comments= above do not apply to this scenario
but rather to the scenario where yo= u have a naive device joining
a network.

-Ekr =C2=A0 =C2=A0
<= /div>
--000000000000fd4f4005a9062d74-- From nobody Fri Jun 26 18:04:17 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B2B3A0838 for ; Fri, 26 Jun 2020 18:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=frobbit.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 leFXEMX_ie25 for ; Fri, 26 Jun 2020 18:04:14 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (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 79B413A07C0 for ; Fri, 26 Jun 2020 18:04:14 -0700 (PDT) Received: from [192.165.72.100] (unknown [IPv6:2a02:80:3ffc:0:35ba:2f13:98f6:fb05]) by mail.frobbit.se (Postfix) with ESMTPSA id 2782C23E4D; Sat, 27 Jun 2020 03:04:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1593219852; bh=EUidLmz5XkbJKxodX7IpKRZ8+ywxRqLxZcqk7sSOiQY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=irwO9e4jYOaeNct3/rR4EgCp0kuq/XpQOyX4gN49gUZq8lB1GZ05rD2sCjODrU//V E9gZBDmSoFO68Ev81vnbVUMp33dYrvM/701YzYBWNr1vEmWfQezxG3eqo90+HSClW0 uk06W6izcVirjgeqda/PRhuFpD/06UnCatQZKyXU= From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Eric Rescorla" Cc: "Tommy Pauly" , "ADD Mailing list" Date: Sat, 27 Jun 2020 03:04:10 +0200 X-Mailer: MailMate Trial (1.13.1r5671) Message-ID: <3E23A64D-C58D-44D0-AA49-2C3129D9AE6C@frobbit.se> In-Reply-To: References: <1AB2782B-87C0-4991-8703-AE2C98411AFC@apple.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_F9B71589-4F51-41F9-8DA3-4A806C4AE81E_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 01:04:16 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_F9B71589-4F51-41F9-8DA3-4A806C4AE81E_= Content-Type: text/plain FWIW, there is a URI resource record, RFC 7553, that gives a URI as RDATA. Patrik --=_MailMate_F9B71589-4F51-41F9-8DA3-4A806C4AE81E_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCXvabCw8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI182YxQCgmVsOl321hMbAxJCopOL5aTGu82YAniPLKSYV iiDgSI7KI8FLSIMKdffM =EoLg -----END PGP SIGNATURE----- --=_MailMate_F9B71589-4F51-41F9-8DA3-4A806C4AE81E_=-- From nobody Fri Jun 26 23:10:52 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0EB3A0D9C for ; Fri, 26 Jun 2020 23:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 PMbHSZYo2IiY for ; Fri, 26 Jun 2020 23:10:41 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 282C93A0D7E for ; Fri, 26 Jun 2020 23:10:41 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id k6so10285845ili.6 for ; Fri, 26 Jun 2020 23:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xyg8X8VEthzCcIvwETHEXtaaXetKDUzGwuBmjDZ/pmc=; b=Icf4m53W+tECPufLooaPjaTvNIwhhuHpe9gNyHe0QxFAxibT1c4zzKLv9DPzYVrC7I Zewy9sUmA58wRIrJzKY7VUnEq5n7SpNMH1mxq+GgCJLaBQEjoyWUg/j1NENTksmi4isi iWRVwVY3tUlOCeDlfcWnC2dU2Xuw87fdSE6Zp+1W/dvihpGmiwafP5kY5zdHdtjiM7gr UEg+BW3LAVLzPAyjl+5BtKJljPSf+rXzoWFxDAi1Om+rrhQVt5IrdHO8md9uOAgS8/no UP0QLi7XEf9ACehnCzWOgIkHoYE6eQMGA8CAJod8oNkLZrvru98Y+tUcvNGeNxvOpVaf GrwA== 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:to:cc; bh=xyg8X8VEthzCcIvwETHEXtaaXetKDUzGwuBmjDZ/pmc=; b=UxAsj9ZrYFdkLLLGVwozgda5KYtFIoa1H8kKDOiAXkGdQWbFlf3mN+L9F4F6lmZkqC FSRqic3bX7+3irJx1I9Y2V/2RrEq6xbghJkKyYU91pTlGd4npVp5V+J6/6TJF6w+30VW WCaRn3BIUBVOyZgZ7UeIQrVFuMXPKes1g5NY/3a/QXRxuvHZpXlmNLOTioMy0qiCExWh O9+JeD/ld3il3J7rrmQTp6ceT6b4G53zTAhirc+DV2iy6WGn32KzCJivjjlZlpS5ANy1 W9c02kBQTKtqqvDC3QSG3ziMCdUUmIgXx9LfErHhuxk+rR+iWjkhEsELiXh3UlXyYgbx lagg== X-Gm-Message-State: AOAM531RfQmHzH0V8iJgeIvT3JmayeUHTeoFTpWbuhwhu2OFaBp/MAfA tbUELwQGmwcnJyAYIP5xXXmd0Tl7B6Vyyr7fMy/slQ== X-Google-Smtp-Source: ABdhPJy32tQasFX0LPgthGp4RPRY7JCnMZqRkvpXO5RR4Kj6NYles5qEUSDexBCnO2IuuSF/ZMr+BpekKeHEk1SeYBc= X-Received: by 2002:a92:a04e:: with SMTP id b14mr6692896ilm.261.1593238240175; Fri, 26 Jun 2020 23:10:40 -0700 (PDT) MIME-Version: 1.0 References: <637E7D0A-AF96-4D7D-B7CB-69E04F995F6F@apple.com> In-Reply-To: <637E7D0A-AF96-4D7D-B7CB-69E04F995F6F@apple.com> From: Manu Bretelle Date: Fri, 26 Jun 2020 23:10:29 -0700 Message-ID: To: Tommy Pauly Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000592a1405a90aaf4c" Archived-At: Subject: Re: [Add] Encrypted DNS support in iOS and macOS X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 06:10:51 -0000 --000000000000592a1405a90aaf4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Tommy for providing more on the technical details behind the implementation. The implementation looks solid and will take care of a lot of the edge cases (captive portal, administered device, vpn, happy eyeball), lifting a lot from the application developpers. There is one case that I did not see mentioned yet and I wonder if it is already supported or if there is any plan in supporting/detecting it, which is NAT64/DNS64. Thanks! Manu On Fri, Jun 26, 2020 at 2:28 PM Tommy Pauly wrote: > Hello, > > I want to share some relevant updates with the ADD working group about > encrypted DNS support in iOS and macOS. > > In the iOS 14 and macOS 11 betas, DoH and DoT are both natively supported > by the system DNS resolvers. These are technologies that many apps have > already been using on iOS and macOS via VPN provider APIs or by embedding > application-specific DNS resolver code. Now that these protocols are buil= t > into the operating system, these use cases can move over to a > system-provided path that provides greater efficiency and tighter > integration with built-in APIs that provide Happy Eyeballs and other > features. > > These videos released as part of the Worldwide Developer Conference cover > details of how encrypted DNS can be used by app developers: > > Build trust through better privacy: > https://developer.apple.com/videos/play/wwdc2020/10676 (Timestamps > 11:55-13:50) > Enable encrypted DNS: > https://developer.apple.com/videos/play/wwdc2020/10047/ > > One of the key goals of integrating encrypted DNS into the operating > system is ensuring that when users get the privacy and security benefits = of > encrypted DNS, they don=E2=80=99t have to face breakages for key use case= s that > require interaction with local DNS providers and private/enterprise DNS > servers. Beyond that, the APIs are designed to make it easy to migrate to > automatic use of encrypted DNS=E2=80=94the goal of the ADD working group. > > To summarize the WWDC videos, there are three different ways that > encrypted DNS is being used in the iOS and macOS betas: > > 1. Provide a system-wide encrypted DNS resolver selection, as an > alternative to providing a =E2=80=9CVPN=E2=80=9D configuration that ju= st configures DNS > 2. Require encrypted DNS within an app (along with a resolver to > prefer if no encrypted resolver is otherwise available), as an alterna= tive > to apps embedding their own DNS resolution code > 3. Start automatically discovering designated resolvers for domains > that advertise a DoH URI > > I=E2=80=99m including details for each of these three mechanisms below. > > Best, > Tommy > > > > System-wide: > (https://developer.apple.com/documentation/networkextension/dns_settings) > (https://developer.apple.com/documentation/devicemanagement/dnssettings) > A system-wide DNS configuration can be provided either by an app that use= s > the NetworkExtension framework, or a configuration profile that can be > installed by the user or by an enterprise Mobile Device Management > solution. These configurations can select an encrypted DNS server for all > domains or only a subset of domains; and can apply to all networks or a > subset of networks and network types. > > System-wide configurations require an explicit opt-in by a user through > Settings, or configuration of a managed device by an enterprise or simila= r > organization. To this end, it is equivalent to how a VPN applies on the > operating system. > > System-wide configurations are meant to not interfere with critical > services that need to use the local network resolver. Captive network > interaction and cellular network services continue to use the resolver > configured by the local network. Similarly, if a VPN is active, the VPN > resolver takes precedence for whichever domains it handles. Note that VPN > providers can now indicate that an encrypted DNS resolver should be used > within the VPN tunnel as well. > > Since these system-wide configurations are based on a user opt-in, there > is no mechanism for a local network to disable them. If the connections a= re > blocked, resolution will fail rather than sending out in the clear. This = is > because these configurations are equivalent to using a VPN=E2=80=94they r= epresent a > security policy that the system enforces on behalf of the user. > > App opt-in: > ( > https://developer.apple.com/documentation/network/nwparameters/privacycon= text/3548851-requireencryptednameresolution > ) > An app can choose to opt into encrypted DNS for resolution within its > process. This is compatible with any system API that does name resolution= , > whether a connect-by-name API or in standard APIs like getaddrinfo(). > > The opt-in here is specifically about requiring that specific DNS > resolutions use some encrypted DNS protocol (DoH or DoT). Since many > devices at first won=E2=80=99t be using encrypted DNS, the app can provid= e a DNS > resolver config to use as a =E2=80=9Cfallback=E2=80=9D. This config indic= ates a DoH or DoT > server to use if and only if the resolution wouldn=E2=80=99t otherwise us= e DoH or > DoT. If there is a system-wide configuration, or a VPN configuration, or > automatic detection of DoH or DoT, then the app will use those resolvers > instead. > > It is important that applications can enable a policy to require encrypte= d > DNS without needing to rewrite their connection logic or adopt entirely > different APIs for name resolution. It is also important that as they > require encrypted DNS, they have a path forward to be compatible with use= r > preferences around DNS and mechanisms for automatic use of encrypted DNS. > If the efforts of ADD are successful in defining standard ways to make > encrypted DNS more universal, any app that adopts these APIs should be > ready. > > Automatic discovery: > > The iOS and macOS betas also start going down the road of automatic > discovery by implementing some of the mechanisms described in > https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00..html > . > I=E2=80=99m including the details below to explain any traffic you see be= ing > generated by these betas, and to explain how to interact with the system = if > you want to experiment. The system isn=E2=80=99t doing any automatic use = of > locally-hosted DoH/DoT servers at this point. > > Specifically, the system: > > - Starts sending out requests for HTTPS(HTTPSSVC) records along with A > and AAAA queries. This is currently using the testing RR type of 65479= . The > plan is to use the official allocation once that is made after the wir= e > format is finalized. It parses out a DoH URI template with a key value= of > 7. This value will also change to one in the correct > first-come-first-served range when we change RR type numbers. > - Relies on validating that a given zone allows designation to a DoH > server using the mechanism described in Section 3.3, Mutual Confirmati= on > with PvD JSON. > > Along with the client support, Apple is running a DoH server ( > https://doh.dns.apple.com/dns-query) for a very limited set of names > within apple.com. This is not a general-purpose DoH resolver, but one > that is only meant to be used as a designated resolver for Apple > properties. The configuration is at > https://doh.dns.apple.com/.well-known/pvd/dns-query, and the confirmation > is performed by checking https://apple.com/.well-known/pvd. > > If connections to the automatically discovered DoH resolvers fail, the > system currently fails over to use traditional DNS. > > If the user has selected a system-wide DoH resolver, that will take > precedence. However, any app opt-in prefers using the discovered resolver > to the app-provided resolver. > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000592a1405a90aaf4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Tommy for providing more on the technical details b= ehind the implementation.
The implementation=C2=A0looks solid and will = take care of a lot of the edge cases (captive portal, administered device, = vpn, happy eyeball), lifting a lot from the application developpers.
There is one case that I did not see mentioned yet and I wonder if it is a= lready supported or if there is any plan in supporting/detecting it, which = is NAT64/DNS64.

Thanks!
Manu

On Fri, Jun 26, 2020 at 2:28 PM= Tommy Pauly <tpauly=3D40a= pple.com@dmarc.ietf.org> wrote:
Hello,

I want to sh= are some relevant updates with the ADD working group about encrypted DNS su= pport in iOS and macOS.

In the iOS 14 and macOS 11 betas, DoH an= d DoT are both natively supported by the system DNS resolvers. These are te= chnologies that many apps have already been using on iOS and macOS via VPN = provider APIs or by embedding application-specific DNS resolver code. Now t= hat these protocols are built into the operating system, these use cases ca= n move over to a system-provided path that provides greater efficiency and = tighter integration with built-in APIs that provide Happy Eyeballs and othe= r features.

These videos released as part of the Worldwide Devel= oper Conference cover details of how encrypted DNS can be used by app devel= opers:

Build trust through better privacy: https://developer.apple.com/videos/play/wwdc2020= /10676=C2=A0(Timestamps 11:55-13:50)

One of the key g= oals of integrating encrypted DNS into the operating system is ensuring tha= t when users get the privacy and security benefits of encrypted DNS, they d= on=E2=80=99t have to face breakages for key use cases that require interact= ion with local DNS providers and private/enterprise DNS servers. Beyond tha= t, the APIs are designed to make it easy to migrate to automatic use of enc= rypted DNS=E2=80=94the goal of the ADD working group.

=
To summari= ze the WWDC videos, there are three different ways that encrypted DNS is be= ing used in the iOS and macOS betas:
  1. Provide a s= ystem-wide encrypted DNS resolver selection, as an alternative to providing= a =E2=80=9CVPN=E2=80=9D configuration that just configures DNS
  2. Require enc= rypted DNS within an app (along with a resolver to prefer if no encrypted r= esolver is otherwise available), as an alternative to apps embedding their = own DNS resolution code
  3. Start autom= atically discovering designated resolvers for domains that advertise a DoH = URI
I=E2=80=99m including details for each of these three mechanisms below.<= /div>

Best,
Tommy



System-wide:
A system-wide DNS configuration can be provided either by a= n app that uses the NetworkExtension framework, or a configuration profile = that can be installed by the user or by an enterprise Mobile Device Managem= ent solution. These configurations can select an encrypted DNS server for a= ll domains or only a subset of domains; and can apply to all networks or a = subset of networks and network types.

System-wide configurations= require an explicit opt-in by a user through Settings, or configuration of= a managed device by an enterprise or similar organization. To this end, it= is equivalent to how a VPN applies on the operating system.
Sys= tem-wide configurations are meant to not interfere with critical services t= hat need to use the local network resolver. Captive network interaction and= cellular network services continue to use the resolver configured by the l= ocal network. Similarly, if a VPN is active, the VPN resolver takes precede= nce for whichever domains it handles. Note that VPN providers can now indic= ate that an encrypted DNS resolver should be used within the VPN tunnel as = well.

Since these system-wide configurations are based on a user= opt-in, there is no mechanism for a local network to disable them. If the = connections are blocked, resolution will fail rather than sending out in th= e clear. This is because these configurations are equivalent to using a VPN= =E2=80=94they represent a security policy that the system enforces on behal= f of the user.

App opt-in:
An app can cho= ose to opt into encrypted DNS for resolution within its process. This is co= mpatible with any system API that does name resolution, whether a connect-b= y-name API or in standard APIs like getaddrinfo().

The opt-in he= re is specifically about requiring that specific DNS resolutions use some e= ncrypted DNS protocol (DoH or DoT). Since many devices at first won=E2=80= =99t be using encrypted DNS, the app can provide a DNS resolver config to u= se as a =E2=80=9Cfallback=E2=80=9D. This config indicates a DoH or DoT serv= er to use if and only if the resolution wouldn=E2=80=99t otherwise use DoH = or DoT. If there is a system-wide configuration, or a VPN configuration, or= automatic detection of DoH or DoT, then the app will use those resolvers i= nstead.

It is important that applications can enable a policy to= require encrypted DNS without needing to rewrite their connection logic or= adopt entirely different APIs for name resolution. It is also important th= at as they require encrypted DNS, they have a path forward to be compatible= with user preferences around DNS and mechanisms for automatic use of encry= pted DNS. If the efforts of ADD are successful in defining standard ways to= make encrypted DNS more universal, any app that adopts these APIs should b= e ready.

Automatic discovery:

The iOS and macOS betas= also start going down the road of automatic discovery by implementing some= of the mechanisms described in https://tools.ietf.org/id/draft-pauly-add-resolver-disco= very-00..html. I=E2=80=99m including the details below to explai= n any traffic you see being generated by these betas, and to explain how to= interact with the system if you want to experiment. The system isn=E2=80= =99t doing any automatic use of locally-hosted DoH/DoT servers at this poin= t.

Specifically, the system:
  • Starts send= ing out requests for HTTPS(HTTPSSVC) records along with A and AAAA queries.= This is currently using the testing RR type of 65479. The plan is to use t= he official allocation once that is made after the wire format is finalized= . It parses out a DoH URI template with a key value of 7. This value will a= lso change to one in the correct first-come-first-served range when we chan= ge RR type numbers.
  • Relies on v= alidating that a given zone allows designation to a DoH server using the me= chanism described in Section 3.3, Mutual Confirmation with PvD JSON.
    • Along w= ith the client support, Apple is running a DoH server (https://doh.dns.apple.com/dns-query) for a very limited= set of names within apple.com. This is not a general-= purpose DoH resolver, but one that is only meant to be used as a designated= resolver for Apple properties. The configuration is at https://doh.dns.apple.com/.well-known/pvd/dns-que= ry, and the confirmation is performed by checking https://apple.com/.well-known/pvd.

    =
    If c= onnections to the automatically discovered DoH resolvers fail, the system c= urrently fails over to use traditional DNS.

    If the user has sele= cted a system-wide DoH resolver, that will take precedence. However, any ap= p opt-in prefers using the discovered resolver to the app-provided resolver= .

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000592a1405a90aaf4c-- From nobody Fri Jun 26 23:58:29 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D34F3A0DA2 for ; Fri, 26 Jun 2020 23:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 1Tj7pZirLxdo for ; Fri, 26 Jun 2020 23:58:25 -0700 (PDT) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 A1C703A0DA1 for ; Fri, 26 Jun 2020 23:58:25 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id g11so5519272qvs.2 for ; Fri, 26 Jun 2020 23:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ur3RJTye5GgFSPx6nR4LNSArwRWPPrPNevsIXX/2w7Y=; b=ejriazClnmbxTcLhyBdSl0TY2nO4s+OXLgjGWFtsYLJMGULlh66WkOtw4hwfo3e9oz HQQSzs4UJddru3IkDsl2cWNDq9/Y+pKku38vy/wnCjNYoH8jtUpbXGoQuvlMHG/oTq/Q vutG2IwiHAvOVujmoCyn+OVUC2bZO8bajxPu17YT6f1HOe5dvbETqGzX+RCoYyPCpRts 98s8K8X6j25xdatpA7xchQiAEr4/LAZECobufv5P7089m8flb4uhWJwQVvwY4hOZ+I9l Lrj/x2ePENKOikMoDlELrwP8A5fAsR4FwmevBKEqOuOaRYxR5KcHBvmC79u0DiMAbJ0Q U00w== 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:to:cc; bh=Ur3RJTye5GgFSPx6nR4LNSArwRWPPrPNevsIXX/2w7Y=; b=STHzYpxZDEfOfWpYmROaK5fud1cJBk3JPycdwcaSDxoO0mGUgbh3B8htkN72CdP6i1 rNqhl3UNGzwHI+wUYrA8FcZP2fTo2txRz1kv4DknkEmSeaJFv5P//dySE3FXYZb5W51q kGr0WnvfbPMgfwraSIM72juDna/M4WCkEMrCjHyIfyIJ/YCgRs044E+AkqnjPS8fV21Z a+nQsAVuqhi7A2o7lkENBgNcJ2qZpIwmLiZZV8FwYM369I1+ZdCeHYGYEnn91NeDKEO/ BcWUoKuIYw8pTJ9Hm02UUYYtW5lkOjWRPakAWmlTGaAW9GB5NJflKHMUy8F/8VVeGUBQ qT4w== X-Gm-Message-State: AOAM530yoeAzR/r8yvRkRTbYieAzJzfdVKSbQASK8r1w7sYljdovwJYH XFO24XQK3Om+cZYD1lPBHan83jbxQg7yKhkDjdc= X-Google-Smtp-Source: ABdhPJwDn8yqFjwQvSsbBs/rBhHlRtyCpOP9vu1CWH6iZLEFPw1LEET7DZhuqRIPyC1TV1z3nuyDrJ6yaVPmch2wMCU= X-Received: by 2002:a0c:f014:: with SMTP id z20mr6241878qvk.136.1593241104649; Fri, 26 Jun 2020 23:58:24 -0700 (PDT) MIME-Version: 1.0 References: <637E7D0A-AF96-4D7D-B7CB-69E04F995F6F@apple.com> In-Reply-To: <637E7D0A-AF96-4D7D-B7CB-69E04F995F6F@apple.com> From: "Chris Box (BT)" Date: Sat, 27 Jun 2020 07:58:13 +0100 Message-ID: To: Tommy Pauly Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000015980805a90b5a55" Archived-At: Subject: Re: [Add] Encrypted DNS support in iOS and macOS X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 06:58:28 -0000 --00000000000015980805a90b5a55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tommy, These details are incredibly helpful so I appreciate you sharing them. I=E2=80=99m uncertain about automatic discovery though. You say: > > The system isn=E2=80=99t doing any automatic use of locally-hosted DoH/Do= T servers > at this point. > But this would appear to conflict with: > > If connections to the automatically discovered DoH resolvers fail, the > system currently fails over to use traditional DNS. > In the beta, are automatically discovered resolvers used, or ignored? Thanks Chris --00000000000015980805a90b5a55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tommy,

These details are incredibly helpful so I appreciate you sharin= g them.

I=E2=80=99m unce= rtain about automatic discovery though. You say:

The system isn=E2=80=99t doing any automatic us= e of locally-hosted DoH/DoT servers at this point.

But this would appear t= o conflict with:

If connections to the automatically = discovered DoH resolvers fail, the system currently fails over to use tradi= tional DNS.

In the beta, are automatically discovered resolvers used, or i= gnored?

Thanks
Chris
--00000000000015980805a90b5a55-- From nobody Sat Jun 27 08:05:02 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812633A02C1 for ; Sat, 27 Jun 2020 08:05:00 -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, SPF_HELO_NONE=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 d0HK9Q_SEYoo for ; Sat, 27 Jun 2020 08:04:58 -0700 (PDT) Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 F10463A0112 for ; Sat, 27 Jun 2020 08:04:57 -0700 (PDT) Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 05RF4v0f005109 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 27 Jun 2020 15:04:57 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 27 Jun 2020 08:04:55 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Sat, 27 Jun 2020 08:04:55 -0700 From: Paul Hoffman To: Eric Rescorla CC: ADD Mailing list Thread-Topic: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers Thread-Index: AQHWTBsN3/DLN2hcME+JF5GYFgXFVajtBcSA Date: Sat, 27 Jun 2020 15:04:55 +0000 Message-ID: <8FC68464-A7B8-48C9-BDDC-333207C16FD4@icann.org> References: <0478F516-47AE-419E-B95D-F546A2F12ABB@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_C26EE232-EDB8-4298-BCAC-80AE817AE054"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_04:2020-06-26, 2020-06-27 signatures=0 Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 15:05:01 -0000 --Apple-Mail=_C26EE232-EDB8-4298-BCAC-80AE817AE054 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 26, 2020, at 5:36 PM, Eric Rescorla wrote: >> Point 1 feels overstated. The clients we are talking about here are = modern web browsers, which can clearly write whatever they want in their = DNS queries. >>=20 > "clearly" is doing a lot of work here. Sure, it's just software so we = could do this. However, Firefox uses the system resolver and in = particular calls getaddrinfo(). So while yes, we could in theory write = our own resolver or plumb to the OS-specific more flexible interfaces = (e.g. res_query()) up to the part of the code that needs this = information. Hence, as I said, "somewhat more difficult (though not = impossible)". I assumed that Firefox was using an internal mechanism for creating the = DNS queries in the draft. How can Firefox send a CNAME query if it "uses = the system resolver and in particular calls getaddrinfo()"? I admit = weakness here, but I thought that getaddrinfo() doesn't let you specify = the RRtype, just "give me an address" where "address" is defintely not = "a domain name". If Firefox has the means of sending a constructed CNAME query and = process the response, shouldn't it also (ahem) clearly have the means of = sending a constructed TBD1 query and process the response? --Paul Hoffman= --Apple-Mail=_C26EE232-EDB8-4298-BCAC-80AE817AE054 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwNjI3MTUwNDU1WjAvBgkqhkiG9w0BCQQxIgQgAFwP1vz8kfUu2E46lF+Hxwbx0yNr E0Yp3dkmg/hkLWgwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAFvTz9fcRYZqzHR6Zcg6cEDTqVe2RP3uMjN4GB9F7A6M OvzgftOIQhG7ORSOAnYwMd1JRo31MVv/3WMLEhrDj4qxP3Q5gwiHIPgFCAW1M6ZtTOrviiULnaOt n/uzOSfMtgvErb1tJrSSKF4EOv/M+Imqk1rNjp+CtZE9M/ohu3iALsvaKM9d3pfZs4/gZ1bSX36h SBq3qcfxPKgFlllCEKlBMtCktHuGJAP+BOQmWIw/UzLtKO2pyk2+7qaqjPf/B2feS6Af4lm5uTvW EJNYrSUqQ0q+SBLl1N/Ce1ALDeO4vTPUsOr5vTrANnqkkEfYzqFcpVabsDW5WM7Cp8AQD98AAAAA AAA= --Apple-Mail=_C26EE232-EDB8-4298-BCAC-80AE817AE054-- From nobody Sat Jun 27 08:36:04 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94433A079D for ; Sat, 27 Jun 2020 08:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=apple.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 tDiF7uwr6m0Z for ; Sat, 27 Jun 2020 08:35:59 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 6A6BF3A0795 for ; Sat, 27 Jun 2020 08:35:59 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 05RFZWYV014340; Sat, 27 Jun 2020 08:35:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=MtWyXaH42FK1IrVtGtQRitQ0pEy+Mcfl0xmEiznpS9o=; b=wQ0X/mV0GIEWPWk/2mf+5OdR9BOPoXTlJ2k/7BRSjfzr/ziOVCJX7vUZu93n2+FWXs+u wSOWO9O4p6xaeU4tdU2jRVjx3nT0y1XxijpQ5QjOypRYf2vyrMghFbA1EeBsTGFhB2m2 Lesa4toHXAHLRWfjktrTl8AuuAFMLmV8wZQITokTUCp+vQAKa4v562gC9ZpdMAqDWaC4 fuyRX1doITGz137D7nzehT/TmxTrvwK9kgTTSyThdD0vrLnC33IyCUOB6sLbhL0XQdlX NWdFtD0rT85mLwzTnT3CxnkJwgb1CBY45U52S1wJj+P0HORYJy1IPdY6YnMz5GcLB6nd VA== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 31x53ub16e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 27 Jun 2020 08:35:57 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QCL00ZLXCNX9S30@rn-mailsvcp-mta-lapp02.rno.apple.com>; Sat, 27 Jun 2020 08:35:57 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QCL00Z00BQSDK00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 27 Jun 2020 08:35:57 -0700 (PDT) X-Va-A: X-Va-T-CD: 40c73510d5f02ab596d60751b7a5285e X-Va-E-CD: 8d219af0f322673eb814e7f9156c80e8 X-Va-R-CD: 414100da242e1445641903909a2349ad X-Va-CD: 0 X-Va-ID: 20b4d244-6814-4c1b-804c-c4ec6e4931e3 X-V-A: X-V-T-CD: 40c73510d5f02ab596d60751b7a5285e X-V-E-CD: 8d219af0f322673eb814e7f9156c80e8 X-V-R-CD: 414100da242e1445641903909a2349ad X-V-CD: 0 X-V-ID: fd43ccce-51fb-4154-9e4c-6d0385b129eb X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_05:2020-06-26, 2020-06-27 signatures=0 Received: from [10.104.236.129] (unknown [10.104.236.129]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QCL00M74CNUEZ00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 27 Jun 2020 08:35:55 -0700 (PDT) Content-type: multipart/alternative; boundary=Apple-Mail-F013FEE7-9DD2-4FBE-98B6-73A447C00978 Content-transfer-encoding: 7bit From: Tommy Pauly MIME-version: 1.0 (1.0) Date: Sat, 27 Jun 2020 08:35:53 -0700 Message-id: References: Cc: ADD Mailing list In-reply-to: To: Manu Bretelle X-Mailer: iPhone Mail (18A316a) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_05:2020-06-26, 2020-06-27 signatures=0 Archived-At: Subject: Re: [Add] Encrypted DNS support in iOS and macOS X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 15:36:02 -0000 --Apple-Mail-F013FEE7-9DD2-4FBE-98B6-73A447C00978 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jun 26, 2020, at 11:11 PM, Manu Bretelle wrote: >=20 > =EF=BB=BF > Thanks Tommy for providing more on the technical details behind the implem= entation. > The implementation looks solid and will take care of a lot of the edge cas= es (captive portal, administered device, vpn, happy eyeball), lifting a lot f= rom the application developpers. >=20 > There is one case that I did not see mentioned yet and I wonder if it is a= lready supported or if there is any plan in supporting/detecting it, which i= s NAT64/DNS64. Good point, I should have mentioned this! When the local network is NAT64, w= e will still request A and AAAA from any DoH/DoT server, and if we get only A= answers, we synthesize an IPv6 address using the NAT64 prefix before using i= t.=20 Thanks, Tommy >=20 > Thanks! > Manu >=20 >> On Fri, Jun 26, 2020 at 2:28 PM Tommy Pauly wrote: >> Hello, >>=20 >> I want to share some relevant updates with the ADD working group about en= crypted DNS support in iOS and macOS. >>=20 >> In the iOS 14 and macOS 11 betas, DoH and DoT are both natively supported= by the system DNS resolvers. These are technologies that many apps have alr= eady been using on iOS and macOS via VPN provider APIs or by embedding appli= cation-specific DNS resolver code. Now that these protocols are built into t= he operating system, these use cases can move over to a system-provided path= that provides greater efficiency and tighter integration with built-in APIs= that provide Happy Eyeballs and other features. >>=20 >> These videos released as part of the Worldwide Developer Conference cover= details of how encrypted DNS can be used by app developers: >>=20 >> Build trust through better privacy: https://developer.apple.com/videos/pl= ay/wwdc2020/10676 (Timestamps 11:55-13:50) >> Enable encrypted DNS: https://developer.apple.com/videos/play/wwdc2020/10= 047/ >>=20 >> One of the key goals of integrating encrypted DNS into the operating syst= em is ensuring that when users get the privacy and security benefits of encr= ypted DNS, they don=E2=80=99t have to face breakages for key use cases that r= equire interaction with local DNS providers and private/enterprise DNS serve= rs. Beyond that, the APIs are designed to make it easy to migrate to automat= ic use of encrypted DNS=E2=80=94the goal of the ADD working group. >>=20 >> To summarize the WWDC videos, there are three different ways that encrypt= ed DNS is being used in the iOS and macOS betas: >> Provide a system-wide encrypted DNS resolver selection, as an alternative= to providing a =E2=80=9CVPN=E2=80=9D configuration that just configures DNS= >> Require encrypted DNS within an app (along with a resolver to prefer if n= o encrypted resolver is otherwise available), as an alternative to apps embe= dding their own DNS resolution code >> Start automatically discovering designated resolvers for domains that adv= ertise a DoH URI >> I=E2=80=99m including details for each of these three mechanisms below. >>=20 >> Best, >> Tommy >>=20 >>=20 >>=20 >> System-wide: >> (https://developer.apple.com/documentation/networkextension/dns_settings)= >> (https://developer.apple.com/documentation/devicemanagement/dnssettings) >> A system-wide DNS configuration can be provided either by an app that use= s the NetworkExtension framework, or a configuration profile that can be ins= talled by the user or by an enterprise Mobile Device Management solution. Th= ese configurations can select an encrypted DNS server for all domains or onl= y a subset of domains; and can apply to all networks or a subset of networks= and network types. >>=20 >> System-wide configurations require an explicit opt-in by a user through S= ettings, or configuration of a managed device by an enterprise or similar or= ganization. To this end, it is equivalent to how a VPN applies on the operat= ing system. >>=20 >> System-wide configurations are meant to not interfere with critical servi= ces that need to use the local network resolver. Captive network interaction= and cellular network services continue to use the resolver configured by th= e local network. Similarly, if a VPN is active, the VPN resolver takes prece= dence for whichever domains it handles. Note that VPN providers can now indi= cate that an encrypted DNS resolver should be used within the VPN tunnel as w= ell. >>=20 >> Since these system-wide configurations are based on a user opt-in, there i= s no mechanism for a local network to disable them. If the connections are b= locked, resolution will fail rather than sending out in the clear. This is b= ecause these configurations are equivalent to using a VPN=E2=80=94they repre= sent a security policy that the system enforces on behalf of the user. >>=20 >> App opt-in: >> (https://developer.apple.com/documentation/network/nwparameters/privacyco= ntext/3548851-requireencryptednameresolution) >> An app can choose to opt into encrypted DNS for resolution within its pro= cess. This is compatible with any system API that does name resolution, whet= her a connect-by-name API or in standard APIs like getaddrinfo(). >>=20 >> The opt-in here is specifically about requiring that specific DNS resolut= ions use some encrypted DNS protocol (DoH or DoT). Since many devices at fir= st won=E2=80=99t be using encrypted DNS, the app can provide a DNS resolver c= onfig to use as a =E2=80=9Cfallback=E2=80=9D. This config indicates a DoH or= DoT server to use if and only if the resolution wouldn=E2=80=99t otherwise u= se DoH or DoT. If there is a system-wide configuration, or a VPN configurati= on, or automatic detection of DoH or DoT, then the app will use those resolv= ers instead. >>=20 >> It is important that applications can enable a policy to require encrypte= d DNS without needing to rewrite their connection logic or adopt entirely di= fferent APIs for name resolution. It is also important that as they require e= ncrypted DNS, they have a path forward to be compatible with user preference= s around DNS and mechanisms for automatic use of encrypted DNS. If the effor= ts of ADD are successful in defining standard ways to make encrypted DNS mor= e universal, any app that adopts these APIs should be ready. >>=20 >> Automatic discovery: >>=20 >> The iOS and macOS betas also start going down the road of automatic disco= very by implementing some of the mechanisms described in https://tools.ietf.= org/id/draft-pauly-add-resolver-discovery-00..html. I=E2=80=99m including th= e details below to explain any traffic you see being generated by these beta= s, and to explain how to interact with the system if you want to experiment.= The system isn=E2=80=99t doing any automatic use of locally-hosted DoH/DoT s= ervers at this point. >>=20 >> Specifically, the system: >> Starts sending out requests for HTTPS(HTTPSSVC) records along with A and A= AAA queries. This is currently using the testing RR type of 65479. The plan i= s to use the official allocation once that is made after the wire format is f= inalized.. It parses out a DoH URI template with a key value of 7. This valu= e will also change to one in the correct first-come-first-served range when w= e change RR type numbers. >> Relies on validating that a given zone allows designation to a DoH server= using the mechanism described in Section 3.3, Mutual Confirmation with PvD J= SON. >> Along with the client support, Apple is running a DoH server (https://doh= .dns.apple.com/dns-query) for a very limited set of names within apple.com. T= his is not a general-purpose DoH resolver, but one that is only meant to be u= sed as a designated resolver for Apple properties. The configuration is at h= ttps://doh.dns.apple.com/.well-known/pvd/dns-query, and the confirmation is p= erformed by checking https://apple.com/.well-known/pvd. >>=20 >> If connections to the automatically discovered DoH resolvers fail, the sy= stem currently fails over to use traditional DNS. >>=20 >> If the user has selected a system-wide DoH resolver, that will take prece= dence. However, any app opt-in prefers using the discovered resolver to the a= pp-provided resolver.. >>=20 >> --=20 >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add --Apple-Mail-F013FEE7-9DD2-4FBE-98B6-73A447C00978 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Jun 26, 2020, at 11:11 PM, Manu Bretelle &= lt;chantr4@gmail.com> wrote:

=EF=BB=BF
Thanks Tommy for providing= more on the technical details behind the implementation.
The implementa= tion looks solid and will take care of a lot of the edge cases (captive= portal, administered device, vpn, happy eyeball), lifting a lot from the ap= plication developpers.

There is one case that I did not see mentioned= yet and I wonder if it is already supported or if there is any plan in supp= orting/detecting it, which is NAT64/DNS64.

Good point, I should have mentioned this! When the local net= work is NAT64, we will still request A and AAAA from any DoH/DoT server, and= if we get only A answers, we synthesize an IPv6 address using the NAT64 pre= fix before using it. 

Thanks,
Tommy

Thanks!Manu

On Fri, Jun 26, 2020 at 2:28 PM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote= :
Hello,

I want to share some relevant updates with the ADD worki= ng group about encrypted DNS support in iOS and macOS.

<= div style=3D"margin:0px;font-stretch:normal;line-height:normal">In the iOS 1= 4 and macOS 11 betas, DoH and DoT are both natively supported by the system D= NS resolvers. These are technologies that many apps have already been using o= n iOS and macOS via VPN provider APIs or by embedding application-specific D= NS resolver code. Now that these protocols are built into the operating syst= em, these use cases can move over to a system-provided path that provides gr= eater efficiency and tighter integration with built-in APIs that provide Hap= py Eyeballs and other features.

These videos released as part of th= e Worldwide Developer Conference cover details of how encrypted DNS can be u= sed by app developers:

Build trust through better privacy: https://developer.apple.com/videos/pl= ay/wwdc2020/10676 (Timestamps 11:55-13:50)

One of the ke= y goals of integrating encrypted DNS into the operating system is ensuring t= hat when users get the privacy and security benefits of encrypted DNS, they d= on=E2=80=99t have to face breakages for key use cases that require interacti= on with local DNS providers and private/enterprise DNS servers. Beyond that,= the APIs are designed to make it easy to migrate to automatic use of encryp= ted DNS=E2=80=94the goal of the ADD working group.

To summarize the W= WDC videos, there are three different ways that encrypted DNS is being used i= n the iOS and macOS betas:
  1. Provide a sy= stem-wide encrypted DNS resolver selection, as an alternative to providing a= =E2=80=9CVPN=E2=80=9D configuration that just configures DNS
  2. Require encr= ypted DNS within an app (along with a resolver to prefer if no encrypted res= olver is otherwise available), as an alternative to apps embedding their own= DNS resolution code
  3. Start automa= tically discovering designated resolvers for domains that advertise a DoH UR= I
= I=E2=80=99m including details for each of these three mechanisms below.

Best,
Tommy



System-wide:
=
A sys= tem-wide DNS configuration can be provided either by an app that uses the Ne= tworkExtension framework, or a configuration profile that can be installed b= y the user or by an enterprise Mobile Device Management solution. These conf= igurations can select an encrypted DNS server for all domains or only a subs= et of domains; and can apply to all networks or a subset of networks and net= work types.

System-wide configurations require an explicit opt-in b= y a user through Settings, or configuration of a managed device by an enterp= rise or similar organization. To this end, it is equivalent to how a VPN app= lies on the operating system.

System-wide configurations are meant t= o not interfere with critical services that need to use the local network re= solver. Captive network interaction and cellular network services continue t= o use the resolver configured by the local network. Similarly, if a VPN is a= ctive, the VPN resolver takes precedence for whichever domains it handles. N= ote that VPN providers can now indicate that an encrypted DNS resolver shoul= d be used within the VPN tunnel as well.

Since these system-wide co= nfigurations are based on a user opt-in, there is no mechanism for a local n= etwork to disable them. If the connections are blocked, resolution will fail= rather than sending out in the clear. This is because these configurations a= re equivalent to using a VPN=E2=80=94they represent a security policy that t= he system enforces on behalf of the user.

App opt-in:
An app can choose to opt into encrypted DNS for resolution within its pro= cess. This is compatible with any system API that does name resolution, whet= her a connect-by-name API or in standard APIs like getaddrinfo().
<= br>
Th= e opt-in here is specifically about requiring that specific DNS resolutions u= se some encrypted DNS protocol (DoH or DoT). Since many devices at first won= =E2=80=99t be using encrypted DNS, the app can provide a DNS resolver config= to use as a =E2=80=9Cfallback=E2=80=9D. This config indicates a DoH or DoT s= erver to use if and only if the resolution wouldn=E2=80=99t otherwise use Do= H or DoT. If there is a system-wide configuration, or a VPN configuration, o= r automatic detection of DoH or DoT, then the app will use those resolvers i= nstead.

It is important that applications can enable a policy to re= quire encrypted DNS without needing to rewrite their connection logic or ado= pt entirely different APIs for name resolution. It is also important that as= they require encrypted DNS, they have a path forward to be compatible with u= ser preferences around DNS and mechanisms for automatic use of encrypted DNS= . If the efforts of ADD are successful in defining standard ways to make enc= rypted DNS more universal, any app that adopts these APIs should be ready.

Automatic discovery:

The iOS and macOS betas also start goi= ng down the road of automatic discovery by implementing some of the mechanis= ms described in https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00..html. I=E2=80=99m including the details below to explain any traffic you se= e being generated by these betas, and to explain how to interact with the sy= stem if you want to experiment. The system isn=E2=80=99t doing any automatic= use of locally-hosted DoH/DoT servers at this point.

Specifically,= the system:
  • Starts sendi= ng out requests for HTTPS(HTTPSSVC) records along with A and AAAA queries. T= his is currently using the testing RR type of 65479. The plan is to use the o= fficial allocation once that is made after the wire format is finalized.. It= parses out a DoH URI template with a key value of 7. This value will also c= hange to one in the correct first-come-first-served range when we change RR t= ype numbers.
  • Relies on va= lidating that a given zone allows designation to a DoH server using the mech= anism described in Section 3.3, Mutual Confirmation with PvD JSON.
=
Along with t= he client support, Apple is running a DoH server (https://doh.dns.apple.com/dns-query) for a very limited set of n= ames within apple.com. This is not a general-purpose DoH= resolver, but one that is only meant to be used as a designated resolver fo= r Apple properties. The configuration is at https://doh.dns.apple.com/.well-known/pvd/dns-query, a= nd the confirmation is performed by checking https= ://apple.com/.well-known/pvd.

If connections to the auto= matically discovered DoH resolvers fail, the system currently fails over to u= se traditional DNS.

If the user has selected a system-wide DoH reso= lver, that will take precedence. However, any app opt-in prefers using the d= iscovered resolver to the app-provided resolver..

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
= --Apple-Mail-F013FEE7-9DD2-4FBE-98B6-73A447C00978-- From nobody Sat Jun 27 08:40:49 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C4D3A07AB for ; Sat, 27 Jun 2020 08:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 xvAj3SB8c0yC for ; Sat, 27 Jun 2020 08:40:46 -0700 (PDT) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 42D773A07AA for ; Sat, 27 Jun 2020 08:40:46 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 05RFaNil015036; Sat, 27 Jun 2020 08:40:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=Oemyt/7CY2GC0vlaxvxiSpH2I0vhQ3dTKUOT+9uKD34=; b=rTnHP/VhY2/1n7ZIbaP5/0jZ2yY3InmhwClLAmtzIGICTrSkbsKA23x5W2GLNiXLBn+R nfFUl5mWnW6R4TDmTb7WOXyn4z/091XSKjdBnXRu/45ItfzW6RGPKhKELDvgzdMU4hw2 ibBOxJL/y7GKgmCngwxz92DxXpvomJeNXYcebx29kfeU6bLf4Q6/8UqF8c72KwClJd00 UgEvWZuVQxZmdlsrjrR56jR+ZJ+k0Kghn1PQzI6y+pG7xXupv5GVDumCKkHmtT67bf2b c39T4fUyd77zszF4hYRArEXKCAXcE7PiHpKyaArRGx2N+F1peSZ7M7xCr61pH1Eqe+g2 FA== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by nwk-aaemail-lapp01.apple.com with ESMTP id 31x51wk6q1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 27 Jun 2020 08:40:43 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QCL00PV7CVVM490@rn-mailsvcp-mta-lapp03.rno.apple.com>; Sat, 27 Jun 2020 08:40:43 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QCL00400CV4JC00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 27 Jun 2020 08:40:43 -0700 (PDT) X-Va-A: X-Va-T-CD: 5e556cc4695c8eea5ebba601e8c34836 X-Va-E-CD: 8d219af0f322673eb814e7f9156c80e8 X-Va-R-CD: 414100da242e1445641903909a2349ad X-Va-CD: 0 X-Va-ID: 169ef601-d682-4e12-88e2-fff6adb80957 X-V-A: X-V-T-CD: 5e556cc4695c8eea5ebba601e8c34836 X-V-E-CD: 8d219af0f322673eb814e7f9156c80e8 X-V-R-CD: 414100da242e1445641903909a2349ad X-V-CD: 0 X-V-ID: 9f251150-1065-4677-86a9-4e1890eed754 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_05:2020-06-26, 2020-06-27 signatures=0 Received: from [10.104.189.9] (unknown [10.104.189.9]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QCL00MD9CVOEZ00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 27 Jun 2020 08:40:38 -0700 (PDT) Content-type: multipart/alternative; boundary=Apple-Mail-16B42A5A-4ECD-4C54-AD92-082178D08413 Content-transfer-encoding: 7bit From: Tommy Pauly MIME-version: 1.0 (1.0) Date: Sat, 27 Jun 2020 08:40:33 -0700 Message-id: <178C62F1-3DFE-48F3-8F38-65EBCDF6EBDA@apple.com> References: Cc: Tommy Pauly , ADD Mailing list In-reply-to: To: "Chris Box (BT)" X-Mailer: iPhone Mail (18A316a) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_05:2020-06-26, 2020-06-27 signatures=0 Archived-At: Subject: Re: [Add] Encrypted DNS support in iOS and macOS X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 15:40:48 -0000 --Apple-Mail-16B42A5A-4ECD-4C54-AD92-082178D08413 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jun 26, 2020, at 11:58 PM, Chris Box (BT) wr= ote: >=20 > =EF=BB=BF > Tommy, >=20 > These details are incredibly helpful so I appreciate you sharing them. >=20 > I=E2=80=99m uncertain about automatic discovery though. You say: >>=20 >> The system isn=E2=80=99t doing any automatic use of locally-hosted DoH/Do= T servers at this point. >=20 > But this would appear to conflict with: >>=20 >> If connections to the automatically discovered DoH resolvers fail, the sy= stem currently fails over to use traditional DNS. >=20 > In the beta, are automatically discovered resolvers used, or ignored? The system doesn=E2=80=99t yet do any automatic DoH for *local* resolvers, s= uch as upgrading from the ISP UDP resolver to an ISP DoH resolver.=20 The automatic behavior the betas do have is for designating resolvers for sp= ecific domains using HTTPS RR.=20 However, I=E2=80=99d expect that behavior for local discovery would be simil= ar. Based on our draft, we=E2=80=99d like to explore using the same HTTPS RR= format for local resolver upgrade.=20 Best, Tommy >=20 > Thanks > Chris > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add --Apple-Mail-16B42A5A-4ECD-4C54-AD92-082178D08413 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Jun 26, 2020, at 11:58 PM, Chris Box (BT) <= chris.box.ietf@gmail.com> wrote:

=EF=BB=BF
Tommy,

These details are incredibl= y helpful so I appreciate you sharing them.

I=E2=80=99m uncertain about automatic discovery though. Y= ou say:
<= div style=3D"word-wrap:break-word;line-break:after-white-space">

The system isn=E2=80= =99t doing any automatic use of locally-hosted DoH/DoT servers at this point= .

But this would appear to conflict with:

If connections to= the automatically discovered DoH resolvers fail, the system currently fails= over to use traditional DNS.

In the beta, are automatically discovered reso= lvers used, or ignored?

<= div>The system doesn=E2=80=99t yet do any automatic DoH for *local* resolver= s, such as upgrading from the ISP UDP resolver to an ISP DoH resolver. =

The automatic behavior the betas do have is for de= signating resolvers for specific domains using HTTPS RR. 
However, I=E2=80=99d expect that behavior for local discovery wo= uld be similar. Based on our draft, we=E2=80=99d like to explore using the s= ame HTTPS RR format for local resolver upgrade. 

Best,
Tommy


Thanks
Chris
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
= --Apple-Mail-16B42A5A-4ECD-4C54-AD92-082178D08413-- From nobody Sat Jun 27 08:50:20 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556843A079D for ; Sat, 27 Jun 2020 08:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoRvdxQpgFoh for ; Sat, 27 Jun 2020 08:50:16 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 849983A0796 for ; Sat, 27 Jun 2020 08:50:16 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id n23so13397468ljh.7 for ; Sat, 27 Jun 2020 08:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rFh0g5oho7Bt9pzVDEZ+0bfVNleRkVhwR+ZqAJQ7yrc=; b=OEFE39SGXaMe0OvdAH/R706O9a56+YFkNK4EGMGqSsdcogHGsiCizD4tRCi1958PXO Ye3T8SSZw4STXNUjgm3BTSnCvkkdAsKhx65u5laplj/WElPjEZMymBnUHcdBPowmoUsv A71P6IJfhrbh+cLaagu7I5z5YwGSuWKNzvQBsHwb9Qf1a4XP3lTaVmJwfjS6lAJLuKyC LhHEI12SVn+aoMgjhRAkY32nOw3wwfi/GAebpINjh3yTKjeB4GvIx6MQ16w39Ton6Yi1 phEAmA8LQfDphdTHFCVoelQSnWTvA3aFRw7nzSt+sPusjVyhmN+vk6ujHalNSZNesqO6 Jthw== 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:to:cc; bh=rFh0g5oho7Bt9pzVDEZ+0bfVNleRkVhwR+ZqAJQ7yrc=; b=Itis+9+PNou58LDd0WkZ+ZYybosSnY3WRnIdKiJObCj6AqxmRdUzyW6/a0RH/tzepe U80m4/E8/gy360sPd5wJ0luUK3oKDVmwKyoi7LUEfdCWicllyagSuyQFrUChoY9ymspx ButeyW++WtmLZEJGJ/s5MAgvenbfh1A07HJtvkqjNrmZvgkt+A7aWWVJyTNTnwVet1lL XTmWSoMlwbfiKruF/tgcsSQTclVEB9lUDMWgHvTCF+oO2KM1kKdf2VXLOxQvhwUiZf20 g8r4FPA2otTDmCca5viAlNgNjLYNdK/PeXx9gLM1PUMpDBAsIjGm4OU6GIqBu0jGYM/X Yf/g== X-Gm-Message-State: AOAM531C2GoCzqV6MtOJATZW40867q0qeVUyqzw3Y8iPRbneV5mPLq4V feLBib6LT39cLH9Ys6AWgChf0tP0WqM3qcAu1ZbtOAFY9RE= X-Google-Smtp-Source: ABdhPJxN+OH7envfQiGgvXT8x1kO+dcTDydyE+d8bdvtD87HMbjoPSiXzBwXkbZjNw9JpyOosO30mlls/C2PhyO+js4= X-Received: by 2002:a2e:3311:: with SMTP id d17mr1761746ljc.13.1593273014617; Sat, 27 Jun 2020 08:50:14 -0700 (PDT) MIME-Version: 1.0 References: <0478F516-47AE-419E-B95D-F546A2F12ABB@icann.org> <8FC68464-A7B8-48C9-BDDC-333207C16FD4@icann.org> In-Reply-To: <8FC68464-A7B8-48C9-BDDC-333207C16FD4@icann.org> From: Eric Rescorla Date: Sat, 27 Jun 2020 08:49:38 -0700 Message-ID: To: Paul Hoffman Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000111fa705a912c8d3" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 15:50:18 -0000 --000000000000111fa705a912c8d3 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 27, 2020 at 8:04 AM Paul Hoffman wrote: > On Jun 26, 2020, at 5:36 PM, Eric Rescorla wrote: > >> Point 1 feels overstated. The clients we are talking about here are > modern web browsers, which can clearly write whatever they want in their > DNS queries. > >> > > "clearly" is doing a lot of work here. Sure, it's just software so we > could do this. However, Firefox uses the system resolver and in particular > calls getaddrinfo(). So while yes, we could in theory write our own > resolver or plumb to the OS-specific more flexible interfaces (e.g. > res_query()) up to the part of the code that needs this information. Hence, > as I said, "somewhat more difficult (though not impossible)". > > I assumed that Firefox was using an internal mechanism for creating the > DNS queries in the draft. No. How can Firefox send a CNAME query if it "uses the system resolver and in > particular calls getaddrinfo()"? I admit weakness here, but I thought that > getaddrinfo() doesn't let you specify the RRtype, just "give me an address" > where "address" is defintely not "a domain name". > https://linux.die.net/man/3/getaddrinfo "If *hints.ai_flags* includes the *AI_CANONNAME* flag, then the *ai_canonname* field of the first of the *addrinfo* structures in the returned list is set to point to the official name of the host." > If Firefox has the means of sending a constructed CNAME query and process > the response, shouldn't it also (ahem) clearly have the means of sending a > constructed TBD1 query and process the response?''' > We do not send a raw query. -Ekr > --Paul Hoffman --000000000000111fa705a912c8d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jun 27, 2020 at 8:04 AM Paul = Hoffman <pau= l.hoffman@icann.org> wrote:
On Jun 26, 2020, at 5:36 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>> Point 1 feels overstated. The clients we are talking about here ar= e modern web browsers, which can clearly write whatever they want in their = DNS queries.
>>
> "clearly" is doing a lot of work here. Sure, it's just s= oftware so we could do this. However, Firefox uses the system resolver and = in particular calls getaddrinfo(). So while yes, we could in theory write o= ur own resolver or plumb to the OS-specific more flexible interfaces (e.g. = res_query()) up to the part of the code that needs this information. Hence,= as I said, "somewhat more difficult (though not impossible)".
I assumed that Firefox was using an internal mechanism for creating the DNS= queries in the draft.

No.

<= /div>

How c= an Firefox send a CNAME query if it "uses the system resolver and in p= articular calls getaddrinfo()"? I admit weakness here, but I thought t= hat getaddrinfo() doesn't let you specify the RRtype, just "give m= e an address" where "address" is defintely not "a domai= n name".

=C2=A0

"If hints.= ai_flags includes the AI_CANONNAME flag, then the ai_canonnam= e field of the first of the addrinfo structures in the returned list is set to point to the official name of the host."
=

=C2=A0
=C2=A0
If Firefox has the means of sending a constructed CNAME query and process t= he response, shouldn't it also (ahem) clearly have the means of sending= a constructed TBD1 query and process the response?'''

We do not send a raw query.

-Ekr



--Paul Hoffman
--000000000000111fa705a912c8d3-- From nobody Sat Jun 27 11:59:06 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156AF3A08CB for ; Sat, 27 Jun 2020 11:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=a4Ikdrz7; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=RdEURrAZ 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 zcNyiCcsJeFR for ; Sat, 27 Jun 2020 11:59:02 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 09B643A08C9 for ; Sat, 27 Jun 2020 11:59:01 -0700 (PDT) Received: (qmail 61923 invoked by uid 100); 27 Jun 2020 18:58:59 -0000 Date: 27 Jun 2020 18:58:59 -0000 Message-ID: From: "John Levine" To: add@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=f1d8.5ef796f3.k2006; i=news@user.iecc.com; bh=xI3GkWwj+R5gw0bkLpT2jM3l7CeTifxGcfGQKl+VIxs=; b=a4Ikdrz7RCtXCdywnMwgdI4fwBiKuxpYyON8qkPMTAVnXGnkptedravkSfT3PzMdgdUKhz0zSGzKMagJI4sx3sEW/xS0rfZivdjUYBJ6jDDSt5+bL1eFioKNkXckexViMiterCdzGKLIh15l9MHFtDOfX6/te0iSKzPZBSAID1UAphhKcUrLetBWcKscgUjaV9JyG5hvy0WDazSsJQ8+hztOcPTa9vIgVMilhFh7C7NuBNgw/vWDnHcS/leQaFwG DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=f1d8.5ef796f3.k2006; olt=news@user.iecc.com; bh=xI3GkWwj+R5gw0bkLpT2jM3l7CeTifxGcfGQKl+VIxs=; b=RdEURrAZTa4QjBHLAd0ZlsMddXd4V/3yi0CtCzVVymY1d/2U4mJXtZ1dZX2rXHvpZpk4ywzo/aUkuWRQnrT5Ide5rGYY0U4y7lMt/4gF87xgXFbXV/g6g3dK1Q+lgGZHLZ3nCLI/N2tpCeN8vWH20/1rQTogPY4Y7eCh9eARMl6HB0vvF02196ViNag7vrt2OpknDJFyLZKWYLKZo5gyvHgceD6iU3TUShFO1BWDGfQXV/OTNKsNt82yS7/WsO9H Organization: Taughannock Networks References: <8FC68464-A7B8-48C9-BDDC-333207C16FD4@icann.org> In-Reply-To: <8FC68464-A7B8-48C9-BDDC-333207C16FD4@icann.org> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 18:59:04 -0000 In article , Eric Rescorla wrote: >> If Firefox has the means of sending a constructed CNAME query and process >> the response, shouldn't it also (ahem) clearly have the means of sending a >> constructed TBD1 query and process the response?''' >> > >We do not send a raw query. Beyond that I gather there is still concern about SOHO routers with poorly implemented DNS forwarders that only handle some kinds of queries. R's, John PS: It sure would be nice to have more up to date info about how common they are. Maybe I can use some of my 64 million RIPE Atlas credits. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jun 27 12:22:23 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4933A08E2 for ; Sat, 27 Jun 2020 12:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y36cUtrrpRtz for ; Sat, 27 Jun 2020 12:22:20 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 79B4B3A08CF for ; Sat, 27 Jun 2020 12:22:20 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id m26so6855403lfo.13 for ; Sat, 27 Jun 2020 12:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ALvKr9wIxTkr16hVU48M7aZ10/Gj/ltFuWhqNMns2Yg=; b=DQtmc3DG24lojPpp/A5p6s+7Ny542BI2ngsxmgiIgD2pbbxCKn563QRr5BR/KuKT4F ctnS+XCdBJWzgrHLMBP7+PUy/bAO/oFIab67MN9w9M4A5cFMmgNCG5jC7ByBx2Cj8pfj XbGwPdXytFN41fc7gY1vVj3q8loXcLacQrbKjDDTZFWvIaNW2Zr2wOm4JiMwMISfpMGR wczFML9w/rPc3io9/zOyN9OrKjEY4We/WH6YaYxU6M7mzJJER8pNBOKUAtVSEEAB9s90 a3IIGx8BLluUl6rI8RjOsiEQWARNJO0OGFBXwt+38Xz+y7SnMNpiLL/UDshe6u8do9b7 9PaA== 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:to:cc; bh=ALvKr9wIxTkr16hVU48M7aZ10/Gj/ltFuWhqNMns2Yg=; b=lXezN7Kb05Q2EH7KHREYGIuufOT2BcgA6PGRZmQpinDfSP0hEmjPVW0+6vOO4K+bvu u4ixE56uIYZYfOz8jBq3EJfTBB8TXyw4b7g8gNjCxXfy9Jp4nDFzBH3RGPk/3iokzE60 9qEGs/mramfaiIybQdDZvhuNZlkWONl1QIHPhS99Tk75WP58nbpzPqxS/jT/5MA6xkzS OWY+eDqJlbChOv+RnfZemsx6m3HGIwW7JsrTmhNcAP0sSkNNwtFJM7Z9Z6CvLJQrHLeU eR1JPzAJo58HDHNnx5m8Nw1xm/t5tHA4XkTy0ZUhtGPjMG+p9DQoGWmDTbkg8Si47F2/ zx8g== X-Gm-Message-State: AOAM531pUzTdkRXXA8UqP3zMkzcPlQZNRNTE5Jw0M1jkB7eI/i6eD3rj wqKEflqPiCIPeyUyt/h6TToBNmXhEbesdKl67olVPdro9kI= X-Google-Smtp-Source: ABdhPJzh6pa5A60dONGHXfZgoVPeILrbBePBEe98Zs32A3yTbBKeubrgJvk2SiBM31qhAqaaD0fzqlvMEjtuLyAL1Mo= X-Received: by 2002:a19:ca48:: with SMTP id h8mr5199439lfj.161.1593285738509; Sat, 27 Jun 2020 12:22:18 -0700 (PDT) MIME-Version: 1.0 References: <8FC68464-A7B8-48C9-BDDC-333207C16FD4@icann.org> In-Reply-To: From: Eric Rescorla Date: Sat, 27 Jun 2020 12:21:42 -0700 Message-ID: To: John Levine Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000784cd905a915be4a" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 19:22:22 -0000 --000000000000784cd905a915be4a Content-Type: text/plain; charset="UTF-8" On Sat, Jun 27, 2020 at 11:59 AM John Levine wrote: > In article DxQBjhH-wzJueRykZw@mail.gmail.com>, > Eric Rescorla wrote: > >> If Firefox has the means of sending a constructed CNAME query and > process > >> the response, shouldn't it also (ahem) clearly have the means of > sending a > >> constructed TBD1 query and process the response?''' > >> > > > >We do not send a raw query. > > Beyond that I gather there is still concern about SOHO routers with > poorly implemented DNS forwarders that only handle some kinds of > queries. > > R's, > John > > PS: It sure would be nice to have more up to date info about how common > they are. Maybe I can use some of my 64 million RIPE Atlas credits. > I agree it would be nice. We are working on taking some measurements and I believe Apple is as well. -Ekr --000000000000784cd905a915be4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jun 27, 2020 at 11:59 AM John= Levine <johnl@taugh.com> wrot= e:
In article &l= t;CABcZeBNKHHO=3Dn68tj2DMGQkRaZQzbZE=3DDxQBjhH-wzJueRykZw@mail.gmail.com>= ;,
Eric Rescorla=C2=A0 <e= kr@rtfm.com> wrote:
>> If Firefox has the means of sending a constructed CNAME query and = process
>> the response, shouldn't it also (ahem) clearly have the means = of sending a
>> constructed TBD1 query and process the response?''' >>
>
>We do not send a raw query.

Beyond that I gather there is still concern about SOHO routers with
poorly implemented DNS forwarders that only handle some kinds of
queries.

R's,
John

PS: It sure would be nice to have more up to date info about how common
they are. Maybe I can use some of my 64 million RIPE Atlas credits.

I agree it would be nice. We are working on ta= king some measurements and I believe Apple is as well.

=
-Ekr
--000000000000784cd905a915be4a-- From nobody Sun Jun 28 11:06:42 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEB53A0E64 for ; Sun, 28 Jun 2020 11:06:39 -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, SPF_HELO_NONE=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 9XQYEou-tC79 for ; Sun, 28 Jun 2020 11:06:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B9F3A0E63 for ; Sun, 28 Jun 2020 11:06:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2B67A38988; Sun, 28 Jun 2020 14:03:51 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5zOZlGhRf_Kn; Sun, 28 Jun 2020 14:03:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CE64438984; Sun, 28 Jun 2020 14:03:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D790F137; Sun, 28 Jun 2020 14:06:34 -0400 (EDT) From: Michael Richardson To: "John Levine" , add@ietf.org In-Reply-To: References: <8FC68464-A7B8-48C9-BDDC-333207C16FD4@icann.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 18:06:40 -0000 --=-=-= Content-Type: text/plain John Levine wrote: >>> If Firefox has the means of sending a constructed CNAME query and process >>> the response, shouldn't it also (ahem) clearly have the means of sending a >>> constructed TBD1 query and process the response?''' >>> >> >> We do not send a raw query. > Beyond that I gather there is still concern about SOHO routers with > poorly implemented DNS forwarders that only handle some kinds of > queries. I believe that the majority of devices on the market are now based upon versions of openwrt which, even if 10 years out of date, now have only 15 year old DNS forwarding code. And that's new enough. > R's, > John > PS: It sure would be nice to have more up to date info about how common > they are. Maybe I can use some of my 64 million RIPE Atlas credits. It would be good to have some real data, and this would be a great thing to do. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl743CoACgkQgItw+93Q 3WVdwwgAlM/ErvAvW4opxqiewthrkeENTr1iXScYvMy+dM30r9dXbxwrZMRzoaNn vf7lthoaT9EcmOa+3hM7Pp4+7Y5XvMx4o4u7bUpV/nfxELXcgyR7akLFj0zFCULl +Gki+MBaGyZ/3rPBYNZw3FvCxJtEaDLnZV3HeuJGQvrzOsvtCrcsI2pw0nXAag5H coViRAH3G5xX28y4Ehn6feustL5na1i/eWDQB+FZTu0rA4MD4zrvhdLpihIiY8er 45K4jNLb86UhUbae1ulbOnIbEaHDZJWPXdFwj825e8Oru/a0esroN/ZX2CiHe531 WCe9KrIgreCChIfsiewmVLhQPQECyw== =43QV -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 28 11:29:27 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC47E3A0E84 for ; Sun, 28 Jun 2020 11:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=P0tUpU7T; dkim=pass (1536-bit key) header.d=taugh.com header.b=KVnfzBbY 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 Nl6ZVBiuhAvu for ; Sun, 28 Jun 2020 11:29:25 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 BE3DD3A0DEB for ; Sun, 28 Jun 2020 11:29:24 -0700 (PDT) Received: (qmail 31258 invoked from network); 28 Jun 2020 18:29:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=79ff.5ef8e182.k2006; i=johnl-iecc.com@submit.iecc.com; bh=Cu45cW2OtmJVNeFJZr8NR42Es+gjlEdPsI8bM1+09hU=; b=P0tUpU7TizhjMWOxEwnLWWBmBrgg4D+s7MFYKgjQNPYywjbCW7N/9OHt+6TmlOEvGt7FT7Gfh6ZJ02KiHauTLT3Dlv2B4glZE12N3rzD/NjtwdnX/qafKgzZIQ9P6CHnSr6dAmsnWMXxrmTxv18CFeyz3NnadvrMLn8McmRZbYdSXZ9Z4fq35wm/gQ9vhtt3ZZgAEFAaUszfslwhdqzi3ExBYt0Ml0BS2npVpMJD0ktn+RGfQFEzE0ZZNXQP0ISs DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=79ff.5ef8e182.k2006; olt=johnl-iecc.com@submit.iecc.com; bh=Cu45cW2OtmJVNeFJZr8NR42Es+gjlEdPsI8bM1+09hU=; b=KVnfzBbYHpIZg5pGg6iXdJyL3EucMXTXK2IHoiyQYVLyXIowM7Gtac/9bgSl54sLBPU5JE+YcWoKJuyzp+dl1bnSXo6Ae7u0m6s6DlfACacoeBFx7tTZtcaK4m4ddhdfcZEYhTsotiiq5oFXssLAJA4ZEnpRT0iAqp/8BnbvZyeANyq8pX60Ob1sb3uodV2h4A+VW6n0+BQpuSrXgrZzlX1GRv2sCA7qnCi1NFiyabORXWQWlZSdGcu5C4p38lG2 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 28 Jun 2020 18:29:22 -0000 Date: 28 Jun 2020 14:29:22 -0400 Message-ID: From: "John R Levine" To: "Michael Richardson" , add@ietf.org In-Reply-To: <14119.1593367594@localhost> References: <8FC68464-A7B8-48C9-BDDC-333207C16FD4@icann.org> <14119.1593367594@localhost> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 18:29:27 -0000 On Sun, 28 Jun 2020, Michael Richardson wrote: > > Beyond that I gather there is still concern about SOHO routers with > > poorly implemented DNS forwarders that only handle some kinds of > > queries. > > I believe that the majority of devices on the market are now based upon > versions of openwrt which, even if 10 years out of date, now have only 15 > year old DNS forwarding code. And that's new enough. It's not what's on sale now, it's what's installed. People tend to keep what they have unless it breaks in ways that are obvious to them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Jun 28 12:23:19 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D060E3A0ED3 for ; Sun, 28 Jun 2020 12:23:17 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikX-Ir7yavLl for ; Sun, 28 Jun 2020 12:23:16 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F073A0ED2 for ; Sun, 28 Jun 2020 12:23:16 -0700 (PDT) Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 5BB5FB0588; Sun, 28 Jun 2020 19:23:15 +0000 (UTC) From: Paul Vixie To: Michael Richardson , add@ietf.org Cc: John R Levine Date: Sun, 28 Jun 2020 19:20:24 +0000 Message-ID: <3615321.ADK9YsXCiF@linux-9daj> Organization: none In-Reply-To: References: <14119.1593367594@localhost> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 19:23:18 -0000 On Sunday, 28 June 2020 18:29:22 UTC John R Levine wrote: > On Sun, 28 Jun 2020, Michael Richardson wrote: > > > Beyond that I gather there is still concern about SOHO routers with > > > poorly implemented DNS forwarders that only handle some kinds of > > > queries. > > > > I believe that the majority of devices on the market are now based upon > > versions of openwrt which, even if 10 years out of date, now have only 15 > > year old DNS forwarding code. And that's new enough. > > It's not what's on sale now, it's what's installed. People tend to keep > what they have unless it breaks in ways that are obvious to them. as we learned with EDNS, we should have broken more stuff sooner. being liberal in what we accept and conservative in what we generate has not scaled and won't. -- Paul From nobody Mon Jun 29 08:37:10 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580BA3A00D6 for ; Mon, 29 Jun 2020 08:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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=comcast.com header.b=XWSQdMjT; dkim=pass (2048-bit key) header.d=comcast.com header.b=HqBdTjm1; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=OwSeD8IC 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 Une3J4mFlt6k for ; Mon, 29 Jun 2020 08:37:08 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 065D93A00D4 for ; Mon, 29 Jun 2020 08:37:07 -0700 (PDT) Received: from pps.filterd (m0156891.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05TFax8F027023 for ; Mon, 29 Jun 2020 11:37:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=6VgYryyH0ml9crHQChnixWa9oXVKHySnTADSr8Vxl1Y=; b=XWSQdMjThjqRxOCG/ZDzVaB6K4BNYA2Exe+gs0Q9fepyNZJkDlaBtfi+t7OnUVGzFSxz qqwUn2VxVaBvuwnz5vlgmXEbvMqmrtrj8H3cOeSx7ksOHYAqgqEid90VL1d1/TEyJ3AI 7gU8LIlxSaZ+/sKwXZlfZinx/PxGXZbTQtvPVm9cO3vt79zYv/v6cmnEgobiKwgAshGN LovgAj6172Hgk8sYvCHOucY4e5tLKDBmy9+FZMxvNwxvnVs5I/FE7+ryXE30Xf61oqjg 5Hiy805v5mCgcezT+X3e7/A59WyoMbDi49Qpa5rlS6QthGq38NoU4xVqcvyeFj3AzieT 8g== Received: from pacdcmhout02.cable.comcast.com (pacdcmhout02.cable.comcast.com [68.87.96.15]) by mx0a-00143702.pphosted.com with ESMTP id 31x2xvawt1-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 29 Jun 2020 11:37:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1593445027; x=2457358627; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6VgYryyH0ml9crHQChnixWa9oXVKHySnTADSr8Vxl1Y=; b=HqBdTjm1vl158lr3JwgmujB9BejPEAh/iS3BDfv4gyMkD4ULC1KNmcDi/z+xocH3 Pq1vLYqSwwBn1coItOJqLYNiGyPAeGMVwsmcIi7fkNpEjX8v3jK629xnIntRgTlb bppTnTmKTep8XoFi+Kyi7IL9QAiW15DNSWnmTJJU37A//YwauKwOBsIrGRHwebBy IeIosRfMuA2VtHKett+KM9JMxyzAnZnTSvMr3/Ca6h547ot4JuDs3IusA7lT+eeP cB3OdStr1ph1rjVuYMxHMC7+dmerDQrDumpPG0QkHUcqWw09sSOy3ZPxUTiIBIre W8cbwh6ef8Z/3QL5T3xW8Q==; X-AuditID: 4457600f-4b8c69e000005543-24-5efa0aa3f58f Received: from PACDCEX39.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by pacdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id F5.40.21827.3AA0AFE5; Mon, 29 Jun 2020 11:37:07 -0400 (EDT) Received: from PACDCEX50.cable.comcast.com (24.40.2.149) by PACDCEX39.cable.comcast.com (24.40.2.138) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Jun 2020 11:36:45 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX50.cable.comcast.com (24.40.2.149) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 29 Jun 2020 11:36:46 -0400 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.169) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Jun 2020 11:36:43 -0400 Received: from MN2PR11MB4287.namprd11.prod.outlook.com (2603:10b6:208:189::17) by MN2PR11MB4582.namprd11.prod.outlook.com (2603:10b6:208:265::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24; Mon, 29 Jun 2020 15:36:43 +0000 Received: from MN2PR11MB4287.namprd11.prod.outlook.com ([fe80::a8bd:6861:d1e5:e613]) by MN2PR11MB4287.namprd11.prod.outlook.com ([fe80::a8bd:6861:d1e5:e613%3]) with mapi id 15.20.3131.027; Mon, 29 Jun 2020 15:36:43 +0000 From: "Livingood, Jason" To: ADD Mailing list Thread-Topic: Comparative DoH Discovery DNS RR Types Thread-Index: AQHWTisWfwz/kDkozE6eKudnPQ6ULA== Date: Mon, 29 Jun 2020 15:36:42 +0000 Message-ID: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=cable.comcast.com; x-originating-ip: [2601:87:4280:7190:ecc1:e3e6:280d:6e85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0be73464-af75-42b8-eb6e-08d81c423977 x-ms-traffictypediagnostic: MN2PR11MB4582: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /cmbNjf5seFkrmyt5Z+yKUiINSLfFkgkx3ocNhG/sb9bUQNiO3uqeHFfKns284Cpy6Z/8JKVEMFNKgD5ssL8n2fQ3ruKS9zRlJ1v6HqleSX4VK/JJJSiqjqIWLQKlttTMdWA7nReyBwizOQ37LzDnMI4lJbNdIDRUEDwFDgk+69XozOXuIBGlY6SSe491li38uGH+2/aaSH8TcLZgmbQhqukpuYwp/bp/zc5oNaSyTNrwZRXbk271p28NGbvDcFgcOY/gUCzfDiw4Op4LYxYPamn5pPjjcAbPfVJy9yGT4nc02x214mgzAHxDaDqtJXxod6F+xDdRKB5E1qev7/zVA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4287.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(39860400002)(376002)(396003)(346002)(6512007)(186003)(5660300002)(2906002)(86362001)(83380400001)(4744005)(478600001)(33656002)(6506007)(6486002)(8936002)(2616005)(8676002)(316002)(71200400001)(66946007)(6916009)(66476007)(76116006)(66446008)(66556008)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: RIyoXqMY6srE1SkZKbanicfvhdh1/scSxHrmbCpyjoTpezbbD/K0tV95HtxDGKBOU5UfL8eSFsmF3ZCzKHa5RgZTmHR/piOHLvya5QDkp/JvEdW0ftZ3hmAawnuQ65x2Gxj1OIT76BY+nYvXskxgY9M66VVC0kSS2t8P/YFOFeXqUK9NNgP+7HgVejw98j0mFe7qfpE0QUYj3qDfWo3kLPIwDo7AmHtsUJMb1+pwSXqqr51AVJesNnReocnDrwQKEy2FUNk9iLuxYID+TNKO6ghGZvQfnr6vi24JX9rJQA+Epqx5ie+18db78/0zrrKHc5I0CkuSonjrkfJztfJQtMI0Ouq/veul1MXDJhfjFhw44Icq3rt0y3fTly3JcUva7HhmW2jGUBcmbV8Yr40VZBe6P1OXhXDnjsXO3l/f2MGF02q1n6lcrxw2hbgQw69RVGP2PwAE6G6ZvBFuOeZxBFeQjvgBhC8tJuOKAQWN1g45U06BfNqjvuNe3NTlLRRY43ZBfEkVGAWFjbm36jgYGz9oUlLfMuqtxtHlB0BBVNo= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X42uhUfDg1Z8KKtnPFS1nt5ICF39e4MyVKxET8AlYqcG3FHFyppB47oXtmF4IfjfDuHmXp9Tju+CICBw9GHnJ5Djp3VJj+aOlEfS8yXKN7lPOVyQSA4M8hC6YqaUAUo40sMSJmEFtcGnChpaqcS9ljWXaiB3OTMUCeg6xEdcYqfoUV29rZc5K1V75KGPj4+tc0SBcUcaDKbWKiKUjM4HwJ3bsjLoQw2legUUfPSAfXMcm5c281UWFXiOmqJYCJiqnYx1jzVbN9vGWnTiIXYlz9XgRlqZt/iM1HyyNEvjQCSBeAeYLr2QNAk4kHuT1Y/ufprv90DliqIapGYqNgX8dg== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mG7IrkUSUrcmabJ59QAvm5EZVngvAfBMwevXFMrysy4=; b=NhChnOowW7qS0Xo95y57nXZRjqwKfNBGTx1qav8qv1QOzodtFhxvehmi1lk6W6zGbiC7AyZM7HlGqj2no8FvSokWvNP5UM3BfGKIWpdFp5HucLC97b6sVDcobyjLIjq7fy+RZvN0Mzk/LGC/dOcGNheEavD5RPKCQvGlyVvpyht3Z5F3vIWud2PVRNT0v07rSgN6DLmiB+NHn7WqO1jmWvovggLgxg3ejYX1QvKVZpyoxxaO/jfldsnEfsy5q7L5LHkpyBrGnDXXJWR0OfL3YamsVglDMeWNm4YDb/woZQP/Y56mUCBeZC5eI+16qhzIb2MuNYnHpR3XKOgo/RgaEA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mG7IrkUSUrcmabJ59QAvm5EZVngvAfBMwevXFMrysy4=; b=OwSeD8ICWQFVpPCYjsFlmzhZRAsyoyRpTQohhjHT9L/c4w+UsPlJISYgeTqhB81cgBusdg7rN0B16pqaNZzAsMus04qwexET9HLDm6UjvRtiWfqYylTzfENTE1s289v1yTnZQ0ql9KEVlB4v8nH/+R+N7Rb4YrYeLAvij7AJ9UI= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4287.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 0be73464-af75-42b8-eb6e-08d81c423977 x-ms-exchange-crosstenant-originalarrivaltime: 29 Jun 2020 15:36:42.9185 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: WnTA7TFEr9kZmaQRndagKs5dvlyL1BqtGA2SEaBDAkOa2Q1JBrHxpMNgDzbXT1KpA2Co/UtEAh04y2l+KadIUX/iRzL9YApyJfs94n+Q+xY= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4582 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <977451EFE17F9847AA15BB3E9642B7DC@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsXiEq4ko7uY61ecwaXPQhb/T69jc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuPJp+wFh9gqtvz5z97AuIati5GDQ0LARGL7TOMuRk4OIYEj TBKTNgd1MXIB2bsYJdZ3XmeBcK4ySrxes5URwjnGKDG5cyULRMtSJokbm5kgEo8YJTpvnGcD SbAJmEncXXiFGcQWEVCWWHp3OxOILSygL/G+4SAjyGoRoNVz5vFAlOhJTO/dzApiswioSsw/ 9oUdxOYVcJHYsucpmM0oICbx/dQasDHMAuISt57MB7MlBAQkluw5zwxhi0q8fPwPbI4o0Kov uxrAjmYUmMAo0d/yAarIUuL6lRtQtqzEpfndjJCg8JVYdksMIqwlca1rMRuEnS2x8Fgv1C41 iRtvOqBaZSQu9yxkgbDlJFb1PmSBiT+4sZ0NZK+EwG8miaPNvSwQznlmiQ3bH7JCOBdYJHas eccygdFkFpKPZgEdwiygKbF+lz5E2EPixdeprBC2osSU7ofss8ABIyhxcuYTlgWMrKsYuc0s 9CzM9SzN9AxNNzGCk0QC/w7Go9M9DjEKcDAq8fAeYPoVJ8SaWFZcmXuIUYKDWUmE97P1tzgh 3pTEyqrUovz4otKc1OJDjNIcLErivP1XX8QJCaQnlqRmp6YWpBbBZJk4OKUaGIsUFQT33jxX u9HzeLik2pf8vS+vPjugx2gf1i9TtXGul8PcTHlPtsUOs2yvPzpZ2T9NZ35+pfAFVc77Xcl+ t4Svpc6ZL306+kFpWMSFyaY7fKc/bz16+qvI/nL9Bx0rJX79Ot72c1O2/mr/puPXEg3tnt7/ KD59evBsgS3y3xpafkzYL3Hu1WwlluKMREMt5qLiRAAeiJ6lDgMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-29_15:2020-06-29, 2020-06-29 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 15:37:10 -0000 SnVzdCBub3RpbmcgZmFyIHdlIGhhdmUgYSB2YXJpZXR5IG9mIHN1Z2dlc3Rpb25zIG9uIENOQU1F LCBVUkksIFRYVCwgUkVTSU5GTyBhbmQgSFRUUFNTVkMgKHRob3VnaCBJIGRvbuKAmXQgdGhpbmsg YWxsIGhhdmUgSS1EcyBhcyB5ZXQpIC0gYWx3YXlzIG5pY2UgdG8gc2VlIHRoZSBpZGVhcyBmbG93 aW5nLiA6LSkgQXMgYSBwcmFjdGljYWwgcGVyc29uIHRoYXQgaW4gSUVURiBsYW5kIGlzIGNvbnNp ZGVyZWQgYW4gaW1wbGVtZW50ZXIsIEkgbmF0dXJhbGx5IGZlZWwgaW5jbGluZWQgdG93YXJkcyBS UiB0eXBlcyB0aGF0IGFscmVhZHkgZXhpc3QgYXMgdGhpcyBlbmFibGVzIHNvbWV0aGluZyB0byBi ZSByYXBpZGx5IGRlcGxveWVkLg0KDQpBcyBhbGwgb2YgdGhlc2UgYmVjb21lIGRvY3VtZW50ZWQg YSBkaXNjdXNzZWQgYSBiaXQgZnVydGhlciAtIG9yIGV2ZW4gdGVzdGVkIGV4cGVyaW1lbnRhbGx5 IC0gbXkgaHVtYmxlIHN1Z2dlc3Rpb24gaXMgdGhhdCBpdCBtYXkgYmUgaGVscGZ1bCBmb3IgdGhl IFdHIHRvIGRldmVsb3AgYSBncmlkIG9mIGFsbCB0aGUgb3B0aW9ucyB3aXRoIHRoZWlyIGFzc29j aWF0ZWQgcHJvcyAmIGNvbnMuDQoNClRoYW5rcw0KSmFzb24NCg0K From nobody Mon Jun 29 08:49:03 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D3A3A0121 for ; Mon, 29 Jun 2020 08:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.599 X-Spam-Level: X-Spam-Status: No, score=-14.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=H1VRaBPg; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=LlH+68Vs 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 UmZrzbiFMuVZ for ; Mon, 29 Jun 2020 08:49:01 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3696B3A011B for ; Mon, 29 Jun 2020 08:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6565; q=dns/txt; s=iport; t=1593445741; x=1594655341; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gdRC1H75H6C85huHZy9v38T+8aeUJ8gcNrVQ0vcUYGE=; b=H1VRaBPgEyjxkOx3LEnv+0jhZM+S3vvOTMlIDakZBStkHN81TXII4JUn xf368CNfJDMu7SejnAa52w/Z9BBqshEvmPNeTQhgJAChqEsGq5DH4HWuJ ECle+Y/TxNpRXUjcI6MmjEtgtYXPDpJnXgSF/j6IemWAwmQY8/4d8KFhO o=; X-Files: smime.p7s : 3980 IronPort-PHdr: =?us-ascii?q?9a23=3ATrEq/RYzQFg6298JFa61s1L/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QWVD4ne4uhPzevbr66mXnYPst6Ns3EHJZpLUR?= =?us-ascii?q?JNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8XG35CQZXB?= =?us-ascii?q?TyKQQzIf76Scbeis2t3LW0/JveKwxDmDu6Z+Z0KxO75QXcv8Ubm81sMKE0nx?= =?us-ascii?q?DIuXBPPe9RwDBl?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaCACZDPpe/5NdJa1gglOBUlEHbys?= =?us-ascii?q?tLywKhCeDRgOmJIEugSQDVQQHAQEBCQMBASUIAgQBAYQCRQKCKgIkNgcOAgM?= =?us-ascii?q?BAQsBAQUBAQECAQYEbYVbDIVvAgEDEhEdAQE3AQ8CAQhCAgICMCUCBA4NBhS?= =?us-ascii?q?DBYF+TQMfDwEOoXUCgTmIYXaBMoMBAQEFgUZBgygYggcHAwaBOIESQYEUiWI?= =?us-ascii?q?dGoFBP4FUgh8uPoJcAoFhgxQzgi2SNId6mk4KglyEK4JWgUaRFZ8Um2eDSJB?= =?us-ascii?q?0AgQCBAUCDgEBBYFaAy8pgS1wFYMkUBcCDY4uEoNOilZ0NwIGCAEBAwl8jnU?= =?us-ascii?q?BgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,295,1589241600"; d="p7s'?scan'208";a="504800752" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jun 2020 15:49:00 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 05TFn0kB032280 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Jun 2020 15:49:00 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 29 Jun 2020 10:48:59 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 29 Jun 2020 10:48:59 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 29 Jun 2020 10:48:59 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y5krwYsuDBA3IDHgamsHkx3MVkQbhr07jIOdyG8h15QOSPlHU/8rigGCaZUuSrqUZMJr9Bvmq6mj3d0Kz8CPOWiXJpoutVDlZODOH/1+A22jLA3Mj0f9juMFjn1ydYTh1ePkuydy9ncgD1LboMWhn7Iobv3/yJGY8hAqkMod8TERrDhOHpSpl5bv/3zlNycjsyQK93WP2hd6F9+s8SczwpirUFzBOkUEYSM4AJU7dFfzFXeNRs3bygqB/Lj5FmaOn3NTejoE1pEWB5HMnCbimU7VG8cfFFR+o29jxIXk+CioUdmQH1AgdxierTeukWS1Hw1+2aGMBup6ztyTmmUnSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a/pVZiywVhuRZjcBR7/n5KzWZbhxlvaDo085MGT4Nlg=; b=n4YRSLOqBE+svl0M/g7vTob6xJ+mKC308A5so0Ln0w+KDkvB1wVhzz+ecJnoJhPIOeRTj950d11lc0deO+ZvxnfXjGzDbqmBVsfwXrHx5ORJMOJJzoPyFuMbIl/6lhEcdwzf2NSojO78I70rWLYkPqTSmgjNG8LRGOUaH/RDWyg1UYSvS3hnabhRAYKTEDCUKJRk72APpbS2Vk+tBkJ5G7lQwZp9Q7UOOCLjW3xWCOa8FAJfKwvALKH6Zk7JVDyjhdrWIIJUhzPcAVsFMPq36avzwrA8YGaSpfKp5elwJ2JlcIBViM8yfXjf+s0l1j7x/OKeKWsc5MSUfZGam89ZKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a/pVZiywVhuRZjcBR7/n5KzWZbhxlvaDo085MGT4Nlg=; b=LlH+68VsDIbq+/1RVtZqL43DT4L6+W5c8dMfpTFpDVutpX+xHeAamUHlb1KYiF6dl0zjtRpDnpvwTUfssRjrJKELjkKnXxzvDGVmdWBlmuCW/7zycs7DEhb91j7/xB+eTEgL/dOT4/wGIpx7k4Oxk+z54gCV1uOs/QFrwrbVfBo= Received: from SA0PR11MB4768.namprd11.prod.outlook.com (2603:10b6:806:71::7) by SA0PR11MB4590.namprd11.prod.outlook.com (2603:10b6:806:96::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23; Mon, 29 Jun 2020 15:48:59 +0000 Received: from SA0PR11MB4768.namprd11.prod.outlook.com ([fe80::4517:e44a:590a:8967]) by SA0PR11MB4768.namprd11.prod.outlook.com ([fe80::4517:e44a:590a:8967%3]) with mapi id 15.20.3131.027; Mon, 29 Jun 2020 15:48:58 +0000 From: "Vinny Parla (vparla)" To: Tommy Pauly CC: ADD Mailing list Thread-Topic: [Add] Encrypted DNS support in iOS and macOS Thread-Index: AQHWTADYBlaAS56gmEed6GBF9KU+1qjr+06AgACd+YCAAfNb8A== Date: Mon, 29 Jun 2020 15:48:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.71] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9227fcbd-4725-4656-f8b0-08d81c43f01f x-ms-traffictypediagnostic: SA0PR11MB4590: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: b4pN+RAT3styWlRplZxOxU/gQLAA1O+dskj/gxW80IQiAaMV/l0iAJHVHn9gIFJHW2s5fG6EZoT8X4Ag3Xj4wU0Y8aJkXyO3s7GYkZBoP8dvOHFcozqhrBwLohcSNa70tIPsajcxLsiQ9dUAJi+wfAJ2ReJ5uet7/AeJl+clU383G3qH9w3v/vkRDwYqupLF5O7uyVZ13TWTtF8uf+MEpk4lGZnS6cx2vH79A2zRCWGOJcK5ubGKDqSi1TLoplnd6YDy7e9ypgd+/JbWcmVpLPv2tztcp8FgGsc46LTHIzittq3rAtb7Pd0GFoD6j984LWyXcNh0dQT8YIkVCiwnwWJRkxKQeFGOzTt8cOKT25dQdCMpBu1iDl08rzS/Ij/nvZQZV7jhBc5+HoI0lS2ZyQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR11MB4768.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(376002)(136003)(39860400002)(396003)(33656002)(6506007)(186003)(26005)(7696005)(9686003)(52536014)(966005)(86362001)(55016002)(76116006)(66446008)(64756008)(66556008)(66476007)(66616009)(66946007)(71200400001)(316002)(2906002)(8676002)(4326008)(4744005)(478600001)(8936002)(5660300002)(99936003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: iUOPr0LtJkw8AdKcYG4ldBcYHl+aMtxxaNDO4S31/OMP50eWIc0WWx4/PThymf19Yq/NZ4RzI082Sb9EidVfR20pd1mSS0J2LkA7MCayWHcpZM2kpE7F5o0Iz6MW44KDgvGvav9MvFJbnt1e8MVZhdEY51XWgO4MmpC/8W6mtSIdAGErx9s7vAfovKsrELJPyZdmcKfiigZBMznOnw1X9+daBOJnLJE8odvGiEa7Esm1gpPhyZvRJ+M0ih8MRAm4ztrFqpzsis2TUz9AGSAKjmwQ1bN8wVBY/buZyxIztCzEXtm7B0RGXgIdLdDwpFz1aOdcKzl2GOBIBy4pEkp80nOKCOGFiuQvtd0EY/i8qNt5GaZQ26xvqEb/Pu5XQJ2UNkZgc7eddPbjHmSYc+4C88Lfm22GF0qdNXmq5DliAZTKJvxEokRfh3xPY2tjXOIw/IY1CAXw6rmUydUk9GPjrrloF6kh0rIGLGhTbpU1EZIRUhkNqezThmS06YQXy+aF x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_017C_01D64E0B.4469CEC0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR11MB4768.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9227fcbd-4725-4656-f8b0-08d81c43f01f X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 15:48:58.8475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: x7LiPv0fj8ps4xeUfVhpFLpVwJSclZ3u7psOdOez31AyuPPooYnoAoKuLXXJulPj795LrHxZsshZF7MjbLhIUQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4590 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Add] Encrypted DNS support in iOS and macOS X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 15:49:03 -0000 ------=_NextPart_000_017C_01D64E0B.4469CEC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, Thanks for the excellent video explaining the new capabilities. One thing that was unclear - I understand that VPN and Captive Portal settings take precedence. Does this mean that if VPN intentionally sets Do53 configuration for the tunnel DNS-settings that legacy DNS will be used over that interface in all cases? Will per-app secure-DNS settings be used in that case or not? I looked at various documentation, but was not clear to me what the behavior was. https://developer.apple.com/documentation/devicemanagement/dnssettings/dnssettings https://developer.apple.com/documentation/networkextension/nednssettingsmanager https://developer.apple.com/documentation/networkextension/nednssettings Thx -Vinny ------=_NextPart_000_017C_01D64E0B.4469CEC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXjCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBKEwggOJoAMCAQICCgGGGmG8CetC JFAwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTIwMDYwOTE4MTEzOFoXDTIyMDYwOTE4MjEzOFowgZYxHTAbBgNVBAMTFFZpbm55 IFBhcmxhICh2cGFybGEpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVz MRMwEQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHzAdBgkqhkiG9w0B CQEMEHZwYXJsYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg5zG6 WUz2eLCtkokcmka2wwjH6DXR8dfR2VqJ3szmqqmiZLHtOZQ7/3+/ztkZk0iM3yQQc2l9KsQ2jzHU rkOZpqMpYCv43rxL2uAM0gQfpIxWGoHN5L3kW7gVpXuPmgGgF6TpMI9vytRh1gl4SHJD8f9QTvTU JynVycwV0KCQfjrJ77AGHX+7+Jwt7vkY64UtJmM7gCoJj7CU7eO+PAJc2qAJMaljtK4XI6InXFPB 7meUpm8k1TBtUuOpe25WYdUcbeipNtqjTFDtYNtXSXwHn1JRWr14CMWI2iTUu69D6M5p8KxXMStS F197vWn7QrFJ1PaK366O/LgsHumVQxAHAgMBAAGjggFYMIIBVDAOBgNVHQ8BAf8EBAMCBPAwDAYD VR0TAQH/BAIwADB6BggrBgEFBQcBAQRuMGwwPAYIKwYBBQUHMAKGMGh0dHA6Ly93d3cuY2lzY28u Y29tL3NlY3VyaXR5L3BraS9jZXJ0cy9jZWNhLmNlcjAsBggrBgEFBQcwAYYgaHR0cDovL3BraWN2 cy5jaXNjby5jb20vcGtpL29jc3AwHwYDVR0jBBgwFoAUn5U2tI5d1UvDCsGnKZNDUQb9iVEwOgYD VR0fBDMwMTAvoC2gK4YpaHR0cDovL2Npc2NvY2VydHMuY2lzY28uY29tL2ZpbGUvY2VjYS5jcmww GwYDVR0RBBQwEoEQdnBhcmxhQGNpc2NvLmNvbTAdBgNVHQ4EFgQU77mvrtX1ZwgDCBrBz254abit a7kwHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJ0C qW6utEOTvSb85ZBZel2OgSpFDDjaLWIEceNr23m4NkhjweswzFPJY4nnKgD40Ryv5WVW4KdpmbZx NBZl4Ypd5XlwleoU9jHuSwp6kaYCEJ7YfOIKVBcF1rYclNL0J0nJ2/fnaxGoYylNfW99vu4UaqEl BWU66VkGfsg5hWPRg90fuge1zZhlwI2AE6xq7pV8C2302ag94ti465IhjnHswtA4Q+r39Tc+me1o b2s1g8WKyds2DPI0PAjWnNpsEvYYOXU8MeMv9p6jPbFG9uaCpt8kCGcYytt8FD285Rmq77FRMEBe ptFCTJh5yr5hIaMVoqBUydvZmQAYKnRX8zMxggLwMIIC7AIBATA6MCwxDjAMBgNVBAoTBUNpc2Nv MRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYaYbwJ60IkUDAJBgUrDgMCGgUAoIIBizAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA2MjkxNTQ4NTVaMCMG CSqGSIb3DQEJBDEWBBT+L9TTH3Pn9pISU4Th+pWoGicTsTBJBgkrBgEEAYI3EAQxPDA6MCwxDjAM BgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYaYbwJ60IkUDBLBgsq hkiG9w0BCRACCzE8oDowLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVl IENBAgoBhhphvAnrQiRQMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAEOyf/KVtcl3TP3HoynnTWhfAYIaNWd/wxrJMBerg6UA34YL04GbYdxZ87Bs 5q4tRP8HyrDDyt/QBkr9tHx3qOkWnU0TvQA/OLurCy30MUj+9TZ6nDrH8qnt9iW0wU24MewA+DwF IqGXwOF+LLkimxgnk1iVbSK5YpVx/TtbTRsL8ACAxoF8zGmX2vf5BXi1ItL9qBQlV8E/hJAS9bot ERci+ZTudzUlzHFYhcutO+c/6aWLltqo5Nl5Bei6a3Z8fGVOxtCWPKQrKuhMCJAg3147E4Ueo201 Pweya11IEcgtiRO/a+cE5Fp07P+Q4DDTifKX4IdgI1LIlGFf0bT9JtkAAAAAAAA= ------=_NextPart_000_017C_01D64E0B.4469CEC0-- From nobody Mon Jun 29 14:02:01 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1313E3A0C47 for ; Mon, 29 Jun 2020 14:01:59 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soGTuv500FiM for ; Mon, 29 Jun 2020 14:01:56 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EDA23A0C5C for ; Mon, 29 Jun 2020 14:01:54 -0700 (PDT) Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 18000B0588 for ; Mon, 29 Jun 2020 21:01:50 +0000 (UTC) From: Paul Vixie To: ADD Mailing list Date: Mon, 29 Jun 2020 21:01:49 +0000 Message-ID: <26559974.PdTMpzyJZD@linux-9daj> Organization: none In-Reply-To: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1784631.GPElSuburT" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 21:01:59 -0000 This is a multi-part message in MIME format. --nextPart1784631.GPElSuburT Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 29 June 2020 15:36:42 UTC Livingood, Jason wrote: > Just noting far we have a variety of suggestions on CNAME, URI, TXT, RESI= NFO > and HTTPSSVC (though I don=E2=80=99t think all have I-Ds as yet) - always= nice to > see the ideas flowing. :-) As a practical person that in IETF land is > considered an implementer, I naturally feel inclined towards RR types that > already exist as this enables something to be rapidly deployed. the community apparently lacks coherence on the importance of rapid deploym= ent=20 as compared to the importance of technical excellence. if we're not going t= o=20 add any more new RR types because they take ten years to become usable (see= =20 the SPF RR vs. the later _spf TXT RR), we should say that, and close the RR= =20 type registry, so as to avoid confusing newcomers. if on the other hand we're going to continue to evolve DNS in ways that=20 include adding new RR types, and all the initiators who are stuck behind=20 dumbass middleboxes who reject or butcher unknown RR types are going to fai= l=20 hard and be excluded from the new applications and protocols in order to pu= t=20 more pressure on middlebox users/makers/distributors, we should say that. either way, nothing is temporary. whatever we use for resolver discovery wi= ll=20 be present as a data pattern and code path in all future software. improved= =20 signal patterns and associated logic will live alongside the unimproved one= s,=20 raising the bar for both short-term expedients and later improvement to be= =20 "worthy of its coexistence cost". for clarity, that's a _very_ high bar. =20 > As all of these become documented a discussed a bit further - or even tes= ted > experimentally - my humble suggestion is that it may be helpful for the WG > to develop a grid of all the options with their associated pros & cons. such grid would be well informed by the attached graphic. =2D-=20 Paul --nextPart1784631.GPElSuburT Content-Disposition: attachment; filename="complexity.png" Content-Transfer-Encoding: base64 Content-Type: image/png; name="complexity.png" iVBORw0KGgoAAAANSUhEUgAAA+wAAAJGCAYAAADBKQ+0AAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAKZiSURBVHhe7f1r0CRVme/9J//nlWBAyMmwbYQX goAGh8GtdiO65SCnLbBt5LAZh7CRHQ8ONDjAiBHS/GmM0BlgOAoRgzSBSEDTtBt0Nwc5hSI0OjLY hHLo5oUINiGnCQwbXvZTv7zzqr7uda88VlbdWVXfT8SKyqrKyspcuXJlXpkrV26TJMmWXgIAAAAA AB3y/8teAQAAAABAhxCwAwAAAADQQQTsAAAAAAB0EAE7AAAAAAAdRMAOAAAAAEAHEbADAAAAANBB BOwAAAAAAHQQATsAAAAAAB1EwA4AAAAAQAcRsAMAAAAA0EEE7AAAAAAAdBABOwAAAAAAHUTADgAA AABABxGwAwAAAADQQQTsAAAAAAB0EAE7AAAAAAAdRMAOAAAAAEAHEbADAAAAANBBBOwAAAAAAHQQ ATsAAAAAAB1EwA4AAAAAQAcRsAMAAAAA0EEE7GjdK6+8kmzZsiXZvHlzsvvuu2efAgAAAADqIGBH 6xYuXJi+brvttsnxxx+fDgMAAAAA6iFgBwAAAACgg+Y9YD/kkEOS2267LdmwYUPy5ptvpk2pLem9 Pr/33nuTZcuWZb8AumHFihVps38rqzT/BwAAANC2LfORegH4ll4w3ot1qusFRVt6wfuWXmAUnSap G8nTeo6NMwlp/fr12VLOmORlJZFIJBKJRCKRSKNP83KF/eGHH06uueaaZM8998w+qWannXZKjjvu uOS5555Lr24CAAAAADCpRhqwq8mwehA/7LDDsk9mPPvss8n111+fnHLKKck222zTT5/73OeSyy67 LHnqqaeSd999Nxt7pjOz888/P3sHzA/dqmHl8q233krfl7nuuuv6t3zoxBUAAAAAFIleeh9G6gXr adNho/cnn3xydNxY6gU7WzZv3pz9uhfxRMYhzX/yaCY+O+mWDqNbQmLjkEgkEolEIpFIJJLSyK6w 62qiPe5LdNV8t912S1atWpV9Uu6cc85J9t133+SRRx6ZdcUdAAAAAIBJM5KAXT28+2bwagK/aNGi 7F09L7/8cnL44Ycn2223XfYJAAAAAACTZyQB+9lnn50NJemVcXUcBwAAAAAA8g09YD/55JNn9Qa/ cuXK9Co5AAAAAADIN/SA/bzzzsuGZq6u6z70UVPv9Lfddluyfv365M033+z30q20efPmZMOGDWkP 34ccckj2i+rWrVvXn45OTni6FUD/qe/s//T/+o2+K6JpaTw/v1V/G9K0bB5iPZmr5/JwPjWsz/Td qGk9aD61Xvw8Kekz9YcQ5nWMpmG/09MJ6tJ/2e9jjxH0+apxYzSvNg0l37pEJ7L8dz4p743Krn0+ SM/yWobY9AEAAAB0V7Q3urZSL6DpxQczesFmdJxhpV6gvqUX4GT/Xk0vkNnSCxij04ulXqCW/XJr j+i9QG7W53n0X5pHPz29Vz6Vif02L2m+jObLPu8FcFvefPPN7Jt8GseWrUry6vyu6rIbLUvRutJ6 8NRDe2y8WNK4Rssfy2ufrxJ+r1SlHMT49RQuR9X1HiaVGVMnL0gkEolEIpFIJNK8peiHraQw0FCA GBtvGEn/XSUYjdFJBv0+Nt0w+YBMAVz46LkyYWBWZ571WDw/L3kpFrDXPZEhWrZw2rHkVQ3Ytex1 8s2UrSsfeEuV9apxvLxlqBKwN8lnUXDtp+MfiVh1PfikIN+rc1KKRCKRSCQSiUQizVuKfthKUmDh Nb0yWDcpGAmDPwXCmp8wYNP72267bU6gXDVo9wF7eHXY/tOWW/Ol9+G8KajUyQz/uYb1uQVWmoZ+ G85nlSulYcAezqc+0//79aPfxK52V8kTr0rArmmGeaL/DudJw/osnC/9tigA9cGu8s9PM0z6zudx Uf5WCdjD5E8g+JM1ZUll1FQ9UeOT/32d/yWRSCQSiUQikUjzmqIftpJ8cKKgKjbOMJIP0ETBSmy8 MPn5lSqBkQ/YPQWVsfGVwgA1DFY1zbygUp+HAWhsPJ/CwNLot2UBtb7381cl2POqBOx+eTRc5eqv xvG/C69I+6Rx/TLoqndsPCV/Rbxs/Y8yYNd696rkkU8+r3TiJzYOiUQikUgkEolE6lyKfthK8vfM juqqnoIRr25wEgbtZb+PBexV/jOcT1MU6FsKA8UqQXdI/1N0pdknf3VWyq6ye2Xz5vNBQWXVeVLS uD4QLwpiw2WIzZeu3htNt2w5w3yNjROmpgG7km9ZUHTSIUzKF6Plio1DIpFIJBKJRCKROpmiH7aS fDA7qoDdN2cuuupalPw0yq6yhgF7nRMEPtiUKsG6JX/FVEFgbBxLYWBZ538s+TwpCxa9soDdT7ds 3FjyV8TL8sGvK/2vPzkQBv9VWmWMOmD3JxQ0/7FxYsnnUZN1TyKRSCQSiUQikeYnDf2xbqN08skn JzvttFP2LknOPvvsbKieO+64IxtKkoULF1Z+3NtTTz1V67F1f/7zn7OhJHn22WeTRYsWZe/Kvfji i9lQkmy33XbZUDV1/sfcf//92VCSfOxjH8uGBuPX16uvvppce+216XAdP/3pT7OhJNlnn32yobgz zjgjfbSg6H9vvvnmdFg0nW233TYd3rhxY/LVr341He6S5cuXJ2+99VY6rPnvBfDpcJkDDjggG0qS q6++OhsCAAAA0HUTFbD/r//1v7KhmQDw8ccfz97Vc8UVV2RDM4444ohsqNjrr7+eDVXz/PPPZ0NJ 8sc//jEbqmbz5s3ZUJJ85CMfyYaG5//+3/+bDc2cxGiDX1//+Z//mQ3V88wzz2RDSbLjjjtmQ3Eq D1deeWX2LkkOO+yw9Jn2t912W7LffvulnymgV2DfVU888UQ2lCTHH398NpRPy2cnRRTsr1q1Kh0G AAAA0H0TFbDvscce2dDsK9B1vfzyy2nAb/bff/9saHqFgZ6ujg9q1113zYaS5LjjjlNb+trpl7/8 ZTaFmavOZXSVWq0ZjN5/+ctfzt4laUDf9ETPKPiTSTrJsPvuu2fv4k499dRsaHYrCQAAAADdN9SA 3Zrvyvve975saHj8f/gr0E2899572RCMX58f/OAHs6HmqgTYw6CTA75pvDWFVyCvAL7LdDJBTfbN d7/73WwozloOyHe+851sCAAAAMA4GGrA7puIt9WMGvPn7bffzoa6yd/PXkQtKHzTeNHJCAXy4+DB Bx/MhpLkv//3/54NzXXdddfNOhmh5QYAAAAwPoYasP/pT3/Khma00Ywak0nB9jbbbDNQqnJPtwlv c9CV9jq/n09qFm8tBHQiLG+7+tznPpcNJcm9996bDQEAAAAYF0MN2O+6665saMb/+B//IxvCOCrr 1G1cKMCNXU3/3ve+V3pPeBfoSrm/D//MM8/MhrbScviO9Lre1B8AAADAXEMN2HW/rb/vuaj5btvq Puos5O+H/+tf/5oNTTd/z3mTR7CFfD8BZY9ka4sC2R/84AfZuyT58Y9/3O9gUM3Hqzarn2/+8Wyx x/T5e9vXrVuXDQEAAAAYJ0MN2OV3v/tdNjTTfFePmRoW3wR/kGeFK6jz99z/x3/8RzY0vfx6s+bY g/KPshvV1fs777yzf+LBnrd+wQUXpO9FV6WrPt98PqnXfjsZphMN4Tz7k2OXXnppNgQAAABgnAw9 YA+DhbPPPjsbap9/rrkC7kMOOSR7V48P4BSctnE1edz5JuQvvfRSNjSY9evXZ0MzV++H3ceBgtrP fOYz6bDWqz1vXcGvv7J+/vnnNy47o+Qf0+bvv9e82wkntR7o8mPqAAAAAOQbesCuYOGpp57K3iXJ nnvuObQOsPwzqsUH3nX4Z1f7e4UnRd38V4sD3+zaP/t8ELqv2l+tP++887Kh9mkZFIibn/zkJ7MC WQW8vmn8zTffnA53mX9Mm38m+yWXXJK+yj333JMNAQAAABg3Qw/Y5ZRTTpkVmOlqrR451dRtt92W Pmc9vCKrzrj8yQH9T92rtrrf19+r/c///M/Z0ORQvtS5r1nNyO3xYFqP55xzTjrchocffjgbStKr 34OUiyIPPfRQfxmsKXzIn+DRiSWVs7b5VgWD3gYQdj5n960fcMAB6auEJ7EAAAAAjI+RBOyx516r abyClzpNjxXMvfnmm8nf//3fp8HXBz/4weybrRRg+5MDK1eurHRPsq5OKoi1JtOiZtKT2pxYy/nK K6+UntAI80RXptuke+P9+lK5qBMoa/41jzqBk0fTUwAu+i9rCh8Km8Z/+ctfbr2Z/h/+8IdsaOY2 gEH7dPCtJXTfuqZnJ5x08opnrwMAAADjbcuoUi/g3hLTC7jS73rB0azxe8H8ll6wveXhhx/e0gvI srG3Cse3FPufDRs2pJ9rmn7cXoCzpRf0zJm+xvfj5SWNZzSd2Dh5SeObQX5bNq9aRi9cVuW/8tnG 33333dP3ftmkap54+u/YOD7pv0KvvPLKll6gPef3mjdbZxrH8+NZUhnxy6tpxsbzyU9Xw7FxlMJ8 jY0TS35+NOzzXvOr8q7kf1OU3nzzzWxqM/NrquQ9iUQikUgkEolE6nSKfji0pCAiDBjr0u8VfMem bynv5EAV69evTwPD2HTDNI4Bu05ahMFuGY1fNU+8qkGj1tcg5UJBa2y6fjmrnnBQ0OzlrZumAbtf d3mKThSEScF9KC8/SCQSiUQikUgk0vikkTSJ99Tj+r777ps2PfZNoavQY6z0O/2+7D5qfX/uueem 9ytXpelff/31yf777z/RTYnVzP+zn/1s8sgjj2SfFNN4Gn+YeaL1tXTp0lrrS1SGVCYOOuig7JOt eoFxv7f0oqbwobBpfJO+EIqogzvf10LM22+/nQ2Viz227YknnsiGAAAAAIyzaCQ/iqQrtrqyqibZ YfNr0VVGXe3WFcm85u9Vkq6E6ipk3n+ETcLrJP3W1J2GbwVQ1mIgTL4ZeVnz6aIrwbrarmXwV6JF eaV8D28hqJJsWrpiXvWqvE9a1/pvzUN41V1Xjm3eyq7eW1PxKi0yYsmXl1geaz5t/jRu+H1Z0jyp fPtl1DxrfdTNNz+v0mS9kUgkEolEIpFIpG6lbbIBTLBeYJtcc8012bsk2WYbrXZMEnWsp84YRT3H q5UIAAAAgPE28ibxANp39NFHZ0P1n7MPAAAAoJsI2IExt2LFiv6j3NQPw/Lly9NhAAAAAOONgB0Y c+rEztDZHAAAADA5CNiBMXbIIYck++23X/YuSa644opsCAAAAMC4I2AHxtgll1ySDSXpo+L0yD4A AAAAk4GAHRhjixYtyoaS5I477siGAAAAAEwCAnZgTF133XXJtttumw6rs7lrr702HQYAAAAwGQjY p8Bf/vKX5N13302HN27cmL5i/O2zzz7pq9btDTfckA4DAAAAmBzb9NKWmUEAAAAAANAVXGEHAAAA AKCDCNgBAAAAAOggAnYAAAAAADqIgB0AAAAAgA4iYAcAAAAAoIMI2AEAAAAA6CACdgAAAAAAOoiA HQAAAACADiJgBwAAAACggwjYAQAAAADoIAJ2AAAAAAA6iIAdAAAAAIAOImAHAAAAAKCDCNgBAAAA AOggAnYAAAAAADqIgB0AAAAAgA4iYAcAAAAAoIMI2AEAAAAA6CACdgAAAAAAOoiAHQAAAACADiJg BwAAAACggwjYAQAAAADoIAJ2AAAAAAA6iIAdAAAAAIAOImAHAAAAAKCDCNgBAAAAAOggAnYAAAAA ADqIgB0AAAAAgA4iYAcAAAAAoIMI2AEAAAAA6CACdgAAAAAAOoiAHQAAAACADiJgBwAAAACggwjY AQAAAADoIAJ2AAAAAAA6iIAdAAAAAIAOImAHAAAAAKCDCNgBAAAAAOggAnYAAAAAADqIgB0AAAAA gA4iYAcAAAAAoIMI2AEAAAAA6CACdgAAAAAAOoiAHQAAAACADiJgBwAAAACggwjYAQAAAADoIAJ2 AAAAAAA6iIAdAAAAAIAOImAHADSy2267JSefdFL2DpPi/PPPz4YAAMB8I2AHANT28Y9/PFlz993J 1VdfnQbumAxHHXVUckEvYH/4oYeyTwAAwHwiYAcA1KJg/ZaVK9NA/aabbkreeeed7BuMuyeffDL5 wx/+kK5jgnYAAObfNr20ZWYQAIBiCtJ1ZV2vCuy+vGRJ8te//jX7FpNg++23T4N1rWMF8EtOPDH7 BgAAjBpX2AEAlSiQu/qqq9JA7pVXXiFYn1Bap19bujQdXrx4cdqaAgAAzA8CdgBAJStWrEgDOAV0 5513HsH6BFPrCQvadV87nQsCADA/CNgBAKXOPPPMftD27zfdlDy5bl06jMn1wAMPpEnUuaDuawcA AKPFPewAgEIK1H6yZk3aJF73NOvKK1fXp4PW+X/85jfpq9b5x/beO/sGAACMAlfYAQC5FKituPTS fsB25ZVXEqxPEa3r5cuXp8MqA7rSDgAARoeAHQCQ6+STT07vW5dVq1bRFH4KrbrrrvSedtFtETSN BwBgdGgSDwCIUm/weryXXV3/b5/6FFfXp5R/LrueEPCpT386HQYAAMPFFXYAQNSZX/96GqyLOpoj WJ9eusJuHdDpRA69xgMAMBpcYQcAzOE7muPqOkSB+m9+/et0WGWBDugAABg+rrADAObQY9y4ug5P TeH1lABR2VAZAQAAw8UVdgDALP5+ZQXqhx9xRBqsTTJdPT7ppJPS17++805y0w9/GF1mBarqhG/x okXJ9jvskI5z1113TXz+GC33mjVr0mGusjcTlqF1Tz6ZduwXo3EW9cZVuZy2sgYA2EoBO4lEIpFI abr66qu3vLZpU5puWbkyOs4kpfPPP3/Liy+80F9mJb3vBUmzxusFT1t+8+tfzxrPxv34xz8+a9xJ Tj4PzjzzzOg4pHjKK0Mnn3TSrPFUnrTtheMpkeckEok0XYkm8QCAPl3JO/qoo7J3SXLTTTdlQ5NH Vzr1XPELzj8/fW+PLhN9pyvuphfUp1eWd8iuqnsatxdcZe8mn57FbyzvUE63ENxyyy1pGfJlTVas WJENbe0/4qjedqiyFt6OsuLSS9PtFAAwHQjYAQB9ClIVgIqCikl97rqW8ZpesK7eznVSQp3qqem/ 3aMtn8ieN65AS4Gpmi1rHD3STE3BfeCuAGpagqj7s97iRflIj/HlrAypzHx5yZK0HJ133nnZtzP5 qGTBusb72tKl/bIWNplXMA8AmA4E7ACAVBh8+cBsEinAVrC+/JJL+lcxX3n11fRVFDQp0NIVTY2n AMuCdI0fBlG7LVyYDU22cNl9SwTke+edd9Ig3K6u+xM+ylNdebdgXUG9PUZPli9fng3NmJayBgAg YAcAZNQRlr9KrA6uJpUCJF3lvMI175Ydtp9pXSDv9MbRVVEL6kOvuoBLfLA/6XwwGZYbzKUytOTE E2cF6T7Pfv/73ydXX3VVGtQrWLcTSAAAELADAFL+6rquAvrgYlKFgZGaJBtrwhwG9UY9fHsKtqaF v3VAaKJdLtyefPnRSY9PfOITaSuOWLCuq+9eeA88AGByEbADANLm8D7omvTm8DHKA3/VU4GTmiLn Xe3UI7eMAqhpuiqqZfXN4ul8rj5ffuTfb7opt8+IsAn8pPYtAQCYi4AdAJCcfPLJ2dCMSW4On0dX OT2dtCgKjPzV+PCK8zTQ88NNeLID5Xz50QkQNZvP8/FPfCIbmhl3Glq/AABmELADAJKjjjwyG5qe 5vAhH0BJUQAVBqjTeMUzbIWhR9+hGpU1X350db2ohYa/Gj+NJ4cAYJoRsAPAlFPg4K8uT2tAYI9x E520KLpPOLwaP433FIdXev3z+1EsLD++E7+QTg758X8/hWUNAKYZATsATLmww7BpvT+2zkkLn2fT 2iJBfKBJs/jq/BVzlZ2iEz46kaS8Nf5WBADA5CNgB4ApF3Z+NY1Xi9VE2QdFZSctaKI8I8wneouv xt9+Uba9hfevT+sJNQCYVgTsADDFwua203q1uE4Td11Fnvb71014siI8+YO5wpYIZU3cOTkEANON gB0ApljY3HZaA4KwiXLRSYuwc7ppbJFgdMXXL7+usPvyhLnqnBwKT6hx/zoATB8CdgCYYouC4GFa rxbXaaLsm32XBffTIDzJ4zvvw1zhCZ+ik2S6Eu9PgEzzySEAmFYE7AAwxcLgahoDAgVQdZoo7+AC qDBY17TOPPPM7N10CE/yhCeBMFv4NIKix7kVbZ8K5HmUHgBMPgJ2AJhivrlt+JiuaVH3pIUP7n2w pWD9lpUrkwt6QZQfZ9Jxhb26sIl72S0o2++wQzY045133klfNZ0VK1akZW3aThABwLQhYAeAKaUA 0ze3/f3vf58NTZc5twWUBFEWNImCLwVMutL5kzVrkh16Adby5cun6sSHTlr4ExfhPdrYSicz/DZX dgtKWI4UpOuWDJW1k086KbnpppuSVatWZd8CACYRATsATKkwsJrW+2N9h3NlTZTlrrvuyoayK52X Xppe6ZRzzzsvWeW+nxY+sFSehPdpY4Z/RJuUbXPhySMF6WrFofxVsH7FlVeWllcAwHgjYAeAKRUG VdMasCvg0bIr3f/AA9mn+RSQK1gy+r0Cq8OPOCJ5oMLvJ1EYWHKVPU4nM6ysKZW1xFDZWrJkSfZu hvL6a0uXJssvuYRgHQCmwDa9tGVmEAAwTXSlzvd4riBgWgPOpnSvuprIT3vgpFsCrJWB6ISGAkq0 h7IGANOJK+wAMKW4wj44XSElgJpbdqap071RoawBwHQiYAeAKaSAygdVCgTKmucCeWgSDwDAcBCw A8AU2m3hwmxoBsE62qR7tX1v6AAAoBkCdgCYQmFv1QTsGIRaaITNtWkWDwDA4AjYAWAKhVc/Cdgx qLAM6ZnjAABgMATsADCFwmDqHTqzwoB+H3Q8t/0OO2RDAACgKQJ2AJhC4RX2V7nCjgH99Z13sqEZ YT8JXabt4cwzz0yuvvrq7BMAALqBgB0AplB4fzFX2DGosAyNwz3sCtRXXHpp8h+/+U36SjN+AEDX ELADwBQKgynuYcegwlYaXe4lfvGiRf1AXVfWuzyvAIDpRsAOAFMmFpyEPXwDdY3DFXYF6g8/9FCy Zs2aOYG6niW/fPny7B0AAN1AwA4AU2YHOgPDEIT3sHelnCkoP/mkk/qB+sdds3edqFp1113J4Ucc kSw58cTkyXXrsm8AAOiGbXppy8wgAGAaKGBR8OJ9aMGCbAhopmvlSoG6rqL/70iTd90CctMPf5is WrWK1iUAgE7jCjsATJkdIk3igUHFAt/Y7RfD5u9Pv+D88+c0ez/vvPPSK+o33XQTwToAoPMI2AFg yoTPx6bDOUyCvPvTw2bvGiZQBwCMCwJ2AJgyXGHHMLwT3MMuw+54TkF50f3pV1x5ZRqo66r6H/7w h+wbAADGBwE7AAAYKwrUzz///DRQv/rqq2cF6mlv75dckvy3T30qubIXsNOCBAAwzgjYAWDK0TwY 4yK8P92u4KsMK1C3Zu/cnw4AmBT0Eg8AU0b39yroMWoqrEBnUK9t2pQNYRy10aN7WAaWLFnSyqPS FJhffdVVyeLFi7NPZigo//decH7XXXd14kp6F7cBngABAOONK+wAAKDT1ATeB+s0ewcATAsCdgAA MFZ0Zf2v77xDs3cAwMSjSTwATJlhNYkHhtUkXlfY1cFc2Ou8yq7uV9ej2gAAmERcYQeAKaMrk8Ao vNPSFXBdSf/Upz+dfG3p0lnBuXqHVy/xOlGgk1DDfowcAACjRsAOAFNOVy+BQY2iHD3wwAPpM9XV IiS8qq6WI7/59a+TW1auTHuTBwBgEhCwA8CUaeuqJ+DtsMMO2dBWw7rHXE3hFbirB3R1Puf/56ij jkrWrFmTNqE/+aSTsk8BABhPBOwAMOVigRYwLnQP+8f23jsN3H1v8TSXBwBMAgJ2AJgy3MOOYYg1 iX9nhGVNgbvd566m8541l1cAr0AeAIBxQcAOAFMmbBLPPewYlvl47JqCdQXtsfvc1UReTeXX3H03 zeUBAGOBgB0ApoxvNmwI2jGoHYIyFCtnoxTe5+4tXrw4vdquq+7+EYcAAHQNATsAgPt7MbCwDM3H 1fU8ai5vgbs/kaB5VnN57nMHAHQVATsATBkFUl0KpjAZtg86Lxzl/etV+fvcn3zyyezTGQrc9Ug4 AAC6hIAdAKZQGEyFzZmBQb3y6qvZUPfoPvclJ54Yvc8dAIAuIWAHgCkU3l/88U98IhsCmgl7Xx+H pxHYfe72WDgAALqGgB0AplB49ZNO5zCoOZ3OdfgKe0i3iKi5vK64AwDQJQTsADCFwqufdLaFQYVl aL57iQcAYBIQsAPAFHpy3bpsaAb3sNd31FFHpZ2UKfFM77mtNNTcHAAADIaAHQAw5/5jlNMVZQXt StOefwrWaaUBAED7CNgBYAqFj7TaIXgkF1BHrDk8TeIBABgcATsATKHwWexcIcUguH8dAIDhIGAH gCn1+9//PhuasdvChdkQUE8YsHP/OgAA7SBgB4ApFQZVbT+LXVftFy9alN7jXfbYON0DrvE0fhlN y8Ytm+408vmu19j99fqszbwL/yPs1HBa+XVR1oKl7jag8fLWLwBgsmwhkUgk0vSlXnCw5bVNm/rp lpUro+PVTb1gYsuKSy/d8uILL8yavv4vHPfkk07a8vBDD80aT0mfh+P2ApMta+6+e850r7766jnj jiKdeeaZ/XnQ8sbGGWXqBW9pXob54+fR1o3eKy9j02mSfvPrX8/6r15wGh1vmpLKcJgv559//pzx bL358fLGzdu29Ht9F45PIpFIpPFP22QDAIApo6t0vQP/7N1MR3RLTjwxe9eMpnnN1VenVwpDumf+ Y3vvnQ5rvBUrVhQ+Du1Tn/50/17oXnCcXHD++envYlbddVdy3nnnZe9GQ/PUC57S4ZtuuilZfskl 6fCohXmpfF61alXyyquvps/bX7jbbmnehdqcZ5UjWzd+PU+jsrLty7XKj8pRnq8tXZo88MAD6bCu pt9yyy2520Ab2y8AoHtoEg8AUyrseO4TAzaJVyDxkzVr0mBdAfThRxyRXHHlldm3M99bU2wF9Uf3 xlPQqPEUmIQ915+fBZkWGCvI0XgaPww0Na1pZHlpwaHy0PJHeav1cGVvHcROZrTVbN3WqQn7Rpgm fn3YuliyZEn27QwF3nJ1bzyVbRtPZVvry7P1asG6aN3a+H77Xbx4MR1HAsCEmnPZnUQikUjTkdQs 2jetHaQps5rwahq9IKP/maYXTl9N79WkN2wi3wt2Zo2redO0NK6aAet7P76m48cPvx926gVb/f/W /MXGGWbS8vo8KGoWHeatUlvN1rWO/HTnIy+6kuw2k7C8+ibsGsfKjt9WLPlm9PqdbgXRa2z96n9s XCU1r/ffk0gkEmn8E1fYAWCKhVdZY03Zq9KV3PAqYS/AyIZmruhr+roSeO555/Wb+prwir+uFqpp 8f298XSl3n8n4aPDpu1Z8ro6a+tLeaM8DfPIhHmrDgfbevTaot769Ka5wzmVaW0Dugqety7Scn3p pek44RV1CdeLrtjrsy8vWTJnmmFebz9l2wAATAMCdgCYYmo27Q3a43QYhCs48XQv9b/3/jMcz7zz zjvZ0Mxv9X758uXR4McHJ/q+rQB0HChv/re791l5WvYoNX/y5Pcl49ZhTbxF6yG8tWHaxLYBy3vl j7YBbXfhthej3+n3eSdjdnDrVHicHgBMHjqdA4Ap9+IQOwyz+8+Ngrnw3lujedC8eLr/N++K7S0r V/avMCtQ0X29g9J982EQlEeBlP2/ThbknYSICe/Br0vzaR3JKS//26c+Fc1To3n9za9/nb1L0nva Y1d36wrXmV1hxlYqIyqrRmVFZTVvfWk9aX0Z648gxm9fbW+7AIBuIGAHgCmnzq+scyvRQX9R8FeH D6qlKADXldo1a9Zk78qDPx/YKKAZNAiWMFgalg8tWJAN1acg+T9+85v+SRYF3mU95IdBo++pfBDh dHXrgm6NwFb+5IoUBeDhCRCdiIo1hTd+++JkCQBMJprEA8CUWxc0YW6zx3XfxF4BRdH9zR8Peqkv ajKs6frAeprum1YfABasS5Ur+z6vFPy1dftAeAvFXS1ctZ80n3B5pLzXI/fy+HFF20DRyTOf/23e 5gAA6A4CdgCYcurUzQs7EWuqblDt74XWlcWi8RW0em3du6vnWKu5cpXkm5QrsIqNk5cG4VtDSJVl 93nb5mPXwnU2Tf0IVKETK76sKlgvDMDdSSuNF26bXrh9tbUNAAC6hYAdAKacAgPfUVhbV9jDoLrs SrC/WljWcdmwAkVNR9OrmrzY93lpED6fNK2yZQ+DxkH/34TTnfbO5mIUUPvWEHVOWunESlFw7/M+ 3IYBAJODgB0AMKspswIMf+WuKR98KKgsCizrXo2vE9xPGp9Pvlf9PCeffHKtoLGq8MROlab50yY8 aVV2siQ8GVOkTnAPABhfBOwAgDlNb31HcU3VCT7Ce3eLxq8b3E+S8ETKK6++mg3FKVBv0oS+Cl9G NM1pWg9V1WkJMtBJK/IeACYWATsAIL065+/JPvPrX8+GmlHg4YOPsg6x/H3zmpeiwKbuVctJ9teS K+x67Fd44qSsCX0VYXP4onutp5nP+7JtoE65DoP7ad4GAGDSEbADAFK+t/gw4K7LBypSFlD4K+xl naIN6/71cbT9DjtkQ3NpHfzvXsDutXX7gIJL38ye3uHnCoPq8GkMIb/NqEzXOWnF/esAMLkI2AEA KV1h90HCIM3iw4C9KKBQ4OfHLwvu/bjhVUtNa5ATDV0X3rO+gwuaPeXDNVdfna5Pn59tXYn1zex1 7/o0nzTJE97mUZZH4YmoIuH24u9fD7cnAMB4I2AHAPT5jsMuOP/8bKi+MPgo6hArDGzq3I/rm4Rb kPrwQw9NbNAe3i4QXmkVywflwbnnnZe+N23c66zp+f/1t1Jgq/A2j6K8V576MlsW3O+2cGE2NPsk jqazYsWKdBsgaAeAyUDADgDou+LKK7OhuUFEVWFAV9Zc1z97WsquLu7gmoHb/+gEwU/WrElbBfz7 TTdN9BVff1JFeb3m7rvT4EzDWn4Fa8oXBeti67Csb4CqfK/zmh7NseP8SavS2zzc9iJ1Tqx8Itt+ tJ51okatH26a8G0AAKYJATsAoE9Bnb9ien6Dq+x1r5j7wEZBRlmg4Ts4U6D62qZNyZpesK6AZfkl lyRXupMOk0gnVXyLBQV7CtJffOGF5JaVK9MTGgrWFdjXOXFS1VFHHpkNzVxd9/OCGeHJrjpN3KVs fP+9/kvbwG9+/ev0hI2C9bCMAADGFwE7AGAWH/DqWdt1r7LXvWLug5WycUXzFwYj+p2CVAUrk07L /uUlS+ac2NDnCtL/26c+1b8KP+sqb4W8LaOA0E4C6P+mIb+bqHvF3J/kUlkuO2mlgDzcVrQ+dMJK Kdw+AADja5te2jIzCADADF2ptU7nFADUCcx0xc83Wy8LPsITAmXjGzX9VS/punKs34w6SNEj01Zc emk6rPxRPo2a1pE6nnunt+xhoKf18B+/+U2/+frXli6d1Zy+CV8uFDROemuGQfhyrfvMi8pn3W3G aF3of/7w+9+nJ2QI1AFg8hCwAwDmUBCgJraiIOBje++dDmMr5ZG1DlCAVaV1wCgpmFOAbbQOBwno tKxqei+ajq7kEyACADBcNIkHAMyhANTuZdfVP11NxmzKI12xVupasC7hrQaDBte+DKhjP4J1AACG j4AdABC1fPnybGiwR7xhfvj71wftcE7Tsmev60QF964DADAaBOwAgChdQbXHvOkqe5Me4zE/tL5m 9RA/4PPX/bo/77zzuLoOAMCIELADAHKpUzFr7q2r7GEHceimsJfyqp2YxeheeJuebpMYNPgHAADV EbADAAqpd3Fz9VVXZUPoMuvJfVC6Um+3Qyjo97dJAACA4SNgBwAU8vcs60prW8Eghsffvy5NOw1U sG6d1/F8bwAARo+AHQBQSsGadVx2zdVXz+qBHN2idRPeuqAO417btKnWyRb9xgJ9nbAZ9BnuAACg Pp7DDgCoRM2j9RxuBYO66v6pT386+wZdk9fXwDvvvFPpKrl+r3Wtda771tUUnqvrAACMHgE7AKAy H8jpivuSE0/MvsGk0Lr9yZo16ZV6dTj45SVLCNYBAJgnNIkHAFSmK+sK4ET3s6+49NJ0GJNBwbrd 8qBgXR0OEqwDADB/uMIOAKhNAZ2utIuaxg/y2DB0h+5xv2Xlyn6wznoFAGB+/T+99P+fGQQAoJo3 3ngj7YTs9ewVk+Gll15Kb3v4f886K13HAABgfnGFHQAAAACADuIedgAAAAAAOoiAHQAAAACADiJg BwAAAACggwjYAQAAAADoIAJ2AAAAAAA6iIAdAAAAAIAOImAHAAAAAKCDCNgBAAAAAOggAnYAAAAA ADqIgB0AAAAAgA4iYAcAAAAAoIMI2AEAAAAA6CACdgAAAAAAOoiAHQAAAACADiJgBwAAAACggwjY AQAAAADoIAJ2AAAAAAA6iIAdAAAAAIAOImAHAAAAAKCDCNgBAAAAAOggAnYAAAAAADqIgB0AAAAA gA4iYAcAAAAAoIMI2AEAAAAA6CACdgAAAAAAOoiAHQAAAACADiJgBwAAAACggwjYAQAAAADoIAJ2 AAAAAAA6iIAdAAAAAIAOImAHAAAAAKCDCNgBAAAAAOggAnYAAAAAADqIgB0AAAAAgA4iYAcAAAAA oIMI2AEAAAAA6CACdgAAAAAAOoiAHQAAAACADiJgBwAAAACggwjYAQAAAADoIAJ2AAAAAAA6iIAd AAAAAIAOImAHAAAAAKCDCNgBAAAAAOggAnYAAAAAADqIgB0AAAAAgA4iYAcAAAAAoIMI2AEAAAAA 6CACdgAAAAAAOoiAHQAAAACADiJgBwAAAACggwjYAQAAAADoIAJ2AAAAAAA6iIAdAAAAAIAOImAH AAAAAKCDCNgBAAAAAOggAnYAAAAAADqIgB0AAAAAgA4iYAcAAAAAoIMI2AEAAAAA6CACdgAAAAAA OoiAHQAAAACADiJgBwAAAACggwjYAQAAAADoIAJ2AAAAAAA6iIAdAAAAAIAOImAHAAAAAKCDCNgB AAAAAOggAnYAAAAAADqIgB0AAAAAgA4iYAcAAAAAoIMI2AEAAAAA6CACdgAAAAAAOoiAHQAAAACA DiJgBwAAAACggwjYAQAAAADoIAJ2AAAAAAA6iIAdnXHusmXJa5s2pemYY47JPgW670e33pqW25c2 bsw+AQAAAAZHwI7OOPLII9PXzZs3J/fdd186DIyDxYsXp68bNmxIXwEAAIA2ELCjExYsWJAceOCB 6fDvfve79LUuXd3UVU5d7QRGRS1Dtttuu3R43bp16es4ueLyy/utAz550EHZp+NtEpcJGDX2qRgF 6uvuog7oDgL2MaVKzTak+9auzT4dDTVX1/8qhU3X/Xd1nLF0aTaUJI8//ng2VI8FTbvttlv62iVP 9QI55cmz69enJycwP/yBQci+e+zRR7NPqjnkkEOyoSS5eeXKbGh8bPf+98+89rafffbdNx0ed+Ow TNQJ6Lou71MxOSZxHzQpqAO6g4B9TKlSsw3JrkyPyk477ZQNJcnrf/lLNjTjS1/6UjZUz6GHHpq+ vvHGG8k1116bDk+S3XffPX3dZZddksMOOywdxujZgcG7776bvnoHNTizr0DrgAMOSIefeOKJZFPN E1WYXtQJAACgCgL2MfX8c8+l93qLAoVR2n+//bKhJPnt009nQ7O9/PLL2VA5tRbYe++90+GmzeG7 zvJDJyRuu+22dBijt/tHPpK+vvXWW+lrzCuvvJINlVPLEDtxFmsZcvF3vpNeRVWiI0V41AmYD3ev Xp3byqiLVG9aa0K1ggK6aNy2K4wfAvYxpUD5o3vumXxowYLkxK98Jft0NOwqpQ40QxYQvffee+lr Faeccko2lCR3rlqVDU2WzyxalK6r/fbfP/sE8+F973tf+hoL2K3J1+bI1fc8i3rrVXTyLNYyZMGH P5wNzW6ZAlAnYD5YPWQnGrtO82vzasceQNeM23aF8UPAjtp22Xnn9DUW9BQFRHk++9nPpq86AUDv 8Bgm26m+8eab6atnO9pNf/5z+lqmjY4SAQAAgCIE7KjNgp6iq5SxgChGzd3sXs4nnnwyfQWGRfcL SxiU++bqf6x4O8c/ffOb2VCS3PvTn2ZDAAAAQHsI2IdIj3vy97ToipzuwbLegZU0rPGasPu68h63 oP+78cYbZ/2feiTWvTZf/epXs7GqsR60lex+84MPPrj/mSW7SnnC8cen78t6sD/l5JOzoSS5+Yc/ zIbiNM+ani23XrUsdR8DovuK/XSUlEfKq1hvzf7epLL/0rqwaXr6P/ufPFY+1Eu5TUP/qd+WrS99 r/nU+rXf2roum2d9H/5W86llqZu3Xmx56kzb1o8tu9aPfaZ5rVqGLe+VzDe+8Y3+Z0q+7P3rv/xL +lnZ/ZK+ZUh4D7LlpbYDY9O1lDf9uuUzFCsLdX6vccJ6Q8OaryKWz/qtWLnyy1GlLJvYctj2UDYv VWkeVRb9siqpzGr9VM3vcH3FksbxLL/030Vi+aBhfVa2Ddk6CMtC3W1b09BvtYxlv8urA80gea7v Na7mo0jVvI3xTzop6nfCz0tenjTNf+WBph/WnXrfpOzrv2watv8WP22louWVsKzrtawcapoaR/Nu v7NUVI6tzKneNHZcYSncpvJY/lcpD1YuNb8xg9RLVi7L5tvySeWkrra2Efu+jfq86T4lNMh2YfNt 86v5sc+0LsPl0PT8/2hcLa//nybbVdPtwdj6tfJpeevLY528bbJNY34QsA+R9TqtTqy0kT5w//3J aaed1r+iLBq+6KKLaldcYsFx7HEL+r9f/uIX6Q7O/5+uMCrQ9jvB+WQ9bKsDprwO7EQViOZZTZD7 97P1XrUsd955Z6X8U8WmSk7Bmp+OKI+UV8ozX7nK+l5FKBp/WcnJlcWLF6ev4f39dquAXxee/vMn a9ak5cNX/PpPzauWPW/nrc/1vfLCriCLreuf/exnufmjz/V9+FvN5xFHHJFc3ts5NKGTUMrLcHnE pl00X+LXj9a/1o99pnm1vJ4P2pnZuow1h992222zoXzh/ZhNy6enHXesLNjvVQcV/V4dSqochvWG hjVfWg95rIyLDiqsXPnlsLJctN6VDzqAiC2HbQ+aFx2UaNymlFeaR5VFv6yiMquyW5bfsXopj88f KasTpCvbdpM6MNbx6KB57h//VKRK3uaxFmTih0N+XmKPomqa/1p2O1YI6069b1L2d/3gB7OhYkXL a3WLL+t61fJpH5y3zi684IJ0HM17uN6sHOv34YWLKnVouE3l2bBhQ/qqvC+6QKJlsDITdj7aRr1k 81s235ZPTR6l1dY24udxkPpceaptOm+fon3edhXW9aDbhZ/vouMJ/V7T0fT8/2hcW8cW3DfZrppu D8YfN2g+LG/DOkbzWbS/ltj+S682D0XrFaNHwD5EvrK99ppr0g3qhRdeSG644Ybkn7/1rVm9ux97 7LHZUDtUKWjDU2dY3//+99POjZT02LV77r2338N8VRdceGH/90bLYNNV0nuj8fTZMQXLpQrYKplf /epX6WuMdhaqQETzrfnXf2m5nnnmmXQ5VTmVuf3HP+5XwJqGzeNBn/xkuk40bU1L68qfXfTP1rYT DDGqYK3S+/nPf56+VqEdxPKLL+7vzFRGtGxaRs2X3osO8kI6iLLPlRdnfP3r/fWhadhBs/In3AHo f08//fR0WOP532q46dMHtBPRSSjLC03Hlkevfrqx+Qr9Y28cW//6rdad5rfqveYqg1om5aWx5bSk aYpOtNhnKvN5yjpKXHbuueny+mW9/fbb088sXXbZZdk3M5qWT6Odq3bc4rcTpYceeij9TNub34ZD OhhSOfRlUNPRb0XrIbwSETri8MPT6YiW3+bB54XKXd6BlfJBBxCi9eHzTcN2MkzzqZMLTWi78Xml /LH/8NtcWX5budS259eXlSexPLiwoDzFdGnbVh1oZaBqHRjW6W3k+bhomv/6nR0rKI+ULypP+p3K l5WrumVffcNYXlu5EfvMUthSyKhe0rrTPFm9ojLo15mOOWLUAa3+U+tby2P/5fcF+v0ZZ5yRDpvl y5en42mbN7YtWaq6Tflblg455JBsaC7f4i+s10dRL3XRIPW5Pvv+977XrxP8fkV5pvKkshU7tvHa 3C7Kjicudsdimkf7H9sP23qWJttV0+0hpPhCwbbGbbK/buu4GqO1hTSc9NqmTbNSbwOZM85LGzf2 vw+/K0v2u8cefTT3ux/deuuc7wZJvY2/P+3eAdWs73oHsP3v/Od56e7Vq/vj9yrk6DhKPo96Qf6c 7/W/fpxYfvh5i60HJU3bxgnzzc9rbB7CccK80TzZd/5zpd6BbP87TSP8XknzHP5W/2G/u2/t2lnf WVK+Prt+fTrOU+vWzfrOr8vegfas7wZJ9n9F0/XrQ+suNo59b+Pk5XvVZPms+Qu/s3UXKzuxlJen YfLrVvkdG0dp0PKp9WzbQF5eqbxofjVP/nM/j0qx//fzl1fWfBnXPMSW128jZf+j6cXqBX2m5Sia TlG+++1G8xluq5b8vMaW2eYhVp6U7Pf6j9j3RXVCF7dtnx95ZdmP4/O1rTz36zX8zqeivC1LPu/y llOpqIw1zX+//Hn1ne0L6k7bUp28sfGUVMZi683X903q6LJy5fMyrLvqJJtPlb9YveLHCbfptuol y3u9ht/55P8r9n1Ramsb8d83rc99WY1tz8oz/z9KZf/TdLuw75S0PHnTsfkJ69SyVJafVVPZ9uDX r1Is36vsr5UHNk4sLzQNP46WLxyHNNrEFfYh6W0A2dAMnamLXbGr88znLtgjO/MoYRN2e4SVPwNZ xK7U6Gzepk3x+x17FW//7KzOPsZ6kb/su99NLl2xInsXZy0YNG95V041bbtiEF5F8s/Y9mfhTW/H M2t5ipr3hw7OmmLpLKeuzMZonsMro75pqq5GxChfrTM/nTXuHXClw8Oi9WWtJrS+Yo86E60zfzZZ vyuifBn0CQJFTzco6kgxpG27SsuQOgYtn/558A89/HA0r1Qmv7xkyZwr+15ePaX1ZWftFy5cmL4W 0fqKXa1becst2VCvLtljj2xoK9/SSFfPYvWCPjv77LOzd1v7EqjKbze33npr7raqx2VaXaYra9rG PbsKk9dZptUZWi+9A690uKoubtv+KuXxxx2XDW1VVAe2leeTTMvqr/zl1Xd++yy6WtwmrRPVHbH1 5luTHfR3f5cNVefL1Y4f+EA21D7bVrQ9qr4MaRu1ej1sITeKeqnLmtbnPg9i9Zjy7AuHHtrfr8UM Y7to43hiWOpsD033120dV2O0CNiHxO+4VBnlHYRbE9iiCqsJO+hRU6Mbb6zW2VQVRUG5PYO9StDj K4x16/I7gtl7n32yoeKeuPOa8omW3Q6uyx6/9cKLL6avtuM2CjxtmRdH7p32AVPR8oR0kG3/pfvs YgcCJjxY2muvvdJXNa/KOwCWJ11A4e+1fP6557KhJDnnnHNauV/J+m2QovUl/iSIX88hbRtt7FyL gvI6TzeY1WzyzjuzoebaKJ/7u2d5617DPCpfRWVs/bPPZkNz2cnF8L9j8taX/zy8X9bng9Z5UZnW d9YE0X5TlW03ooOSIn59HHbYYdlQNdtvv302VF8Xt23VsVYHKjAP9ylFdeCo8rwrmuT/V048MRua XTfG2PFC0T3nbVKdmVdv+DrDjg+aKtoPDMp3LHpoL0gM+ZNQvl4fVb3UZU3qc6mab7Zfi2l7u9A4 RccTdnygeb9v7dp5vTWnbHtour9u47gao0fAPiR77rlnNjT7LKTnK4IqQW4dF3372/0zbLr3TB1T 3L169Zwr/3UVBeXWSUmVVgP+DKi/Rzxk/yePPPJINlSPP+jTCYzXegceecnusYyxA0kdlIZXhBct WpS+Ks/LDkg9f5D98p/+lA1VYztDvcaWxZLuc4rRDlT3UImWSfcrPbt+fXqCp+lOyvfbUFbZb3zp pWyotwP52MeyoeEpCsot0Hjh+efT1yJ2FbEsmKqqjfLpD1CKDka6zOdD0QGcefvtt7OhmatjVfmD yDKvv/56NjT3RJ0FrwcGrR2M1QlS98Cni9u22JVHTTO8SllUB7aV5+OiSf77g2j1ARJb35bsRP84 0UkLBUBPrZv9dIC8Mtw2rRO1/BDlX7ge8lqHjKpemjT+WHOQlqSj3i509d1OuqiVj06Aq9yWtQKs az63hzaOqzF6BOxD0g8Oegd1eQdr1sxHrBfetuigXR1j+WbH+j+dZX7s0UdrBe6qWKwysU5XVDH6 SkbJKksLOnSAEqMz1r6JU9EVP99TadF4bYu1IPCd0PgTDloey5eyK6TzSQfS4YkWHViroxE7kNbZ WAWF2knpBE94Fa1NowgstQxWPi0o1/LZZ5aMHRDodzHaadsZ67W9ne18iZXPaVP3BFcTRVcwVmdl RMGoyosFANpmFJhZnWB18DCNatv2Vx79CYk268CiPB8no6hb2z7RPww61tCxgE5aqIzYyZv54Ft+ +I5Dq7b4q2IU9dI48CeRN7/7bjY0GoNsFzrO1O0fvvM2lVsdG6gcDxq4d2F7mK/jagyGgH1ILHh9 9dVX09cYf+bw6f/8z2yoPTpLrHsCde+z7nWxg3zNm3rcHPRqe1P+ykxZEyevjQMcVcLWW29R2s81 MTYKMO3Mq7+H2C9PWTPwYdABYWwZwvTRPfeMBsk6oaT7yNR7sfUmLjqpoh5X28j3GF/+1HPqOKja MqSpQcrntPFXCYYVuOgxd2bz3/6WDc3461//mg3NbCsKxHSy5+nf/rbfEkL1ha7YNNW1bdtfpdTB pp2k8HVgXouyqoryfNw0zX8F+rH1HCbt37tMy6dewu0kp/LA95ivpGUdFZ1EsXXwxS9+MX0Vq9f1 Xdg6pK5R1Evjpspj26oY1XahIPass85KPvf5z6ctZfxJNwXuTW8x6tr2IMM6vkP7CNiHwAciRWdb fTPgYV5t1EGW7qHXQb4Cd9HZ5KVf+1o6XEY7MKtMjB79kFfJWKWaF1T4ppN5nZIZ3wSt6f2MvsmP 35k2YZ2MKf+s0rb74YpaU+TxO/S682YnD3wz9EGoDP7D6aenOym7Kqizv2HT1yI+8C47IbTnRz+a DQ3vqoR23GH5tMe0WFKQbOyzvB2+bzbZ1pnpNspnnXzvqrrbwo477pgN1as/7YC9ynaz6667ZkNz r/zaY3dUfrS92HRFB3g60PtMr65rUk66uG2bBx98MBvaepXS14GxddFWnnujONBsqxO0Kvnvb8fx Jy3GmZbPghNtJ8qDOtvqMFi/D5ov1ZUqR1avx1qHDKNe8lc4h2k+gzF/LDRIPTaf24Xqbh3/6qSb jiGsHvtKwxMCXdke2jiuxugRsA+B73DOdwoUskrMzt6NggJ3Oxis22GNvx/r7f/6r2xorqJ7YrQD qdN00j9rW88DzVN0xlOVrrUuUOdHg+zE/u2qq7KhmRMPusJkrSnyeosuosradgJl8xbec2etN3Ty oM175ZRf/qpgnY6EnnOdLcV60/f81WpdnRymxe5e2LwAyraLPG02m/TaKJ8+38OnCYTCctQVfltQ HVG2LVhTQrviW5U6dxSty7LmjXYgr/nyB6C+R2ldidEJHl3lthM+OsAb5EpdF7dto5Ostp7UC3SV OrCNPA/5zqg8lZu6+7Y8vhPNUJOTa0X572+dKPrfceKXr+hYaJT8rW3aRymIsno91kJuGPWSxsmb TpsnXEexjRTxrTrzllef5/UDIl3ZLlQX+ZM9TXRle2jjuBqjR8A+BL7DubzgVRW77STafrSbNjLd px47MFfluHP2eKtBhMtVJSCSf/rmN7Ohak0nfbNj/UdsZ6bl1f1ARfwjXXQ7QBHlW97ORcvmm4Sq OZPxvdDW4Tuzy5u3Ky6/PA1q/Tr1Bxf/2Fv+vHkWfReWB91H+aNbb43+rulZV53QsIMb9WWQd/Ch dWb9GOiE1ajOMseCcmvpUtYs/8gjj0xftXxVg7GqVwcGLZ/+3mLtgGP5rt+pgxs16esqPZLO/PCm m7Kh2bTs119/ffYuSe6o2VO/H19XyfO2G20fdmDm5yukbbNtXdy2PTvYVODhy1NeHdhWnvvtybZH T+X+gfvvb3xALX7fppMH4bzqvfavduI5pkn+qyWcnbxXgFN2sNw0sPPHG02n0YR/JKxR/qh8F2mj BZKnfY3tB3RMYS3+ilrItVUv+bz3x0JG67ys/i8zim2kKn9RJrZcyjPdGmInOWJGtV2I6lHdX553 krSopUDd7arp9tCGto6rMVrb9JIeyI4WaWeuikU7gLxm4brKYAc6al5e1jQ8xjrLUmWmKzpGHR7p HkoFFjqwsp2NKgg9T9QqRzXZrHMVSAemp512Wjqsq0ie/ad2hGoGmkcBg/6/KG9COvBR8Cdapnvu uSdtKqnmiieccEL/6o6+U8AT5oeoIvQ7Kf2/ejz2TS5VcSl40/TUXElXzmL8ujOx//SsTEiYd9pJ KOCyEzia1qO98f/Yy0utMzU3td/q6ql2YEa9jNqBY7i+RUHivvvum1651Q7Fz6Mvpz4v9Bvlq81P +J9lrCwYnSFXXwVqlaF1pivrFqxrnnXFKRaw55XvJiyfYtOyfND9ZGqiFqPyo3uTRctT9R45rVtr PaBl1TOotV5V1nRgZdt9G+Uz3E58WVAQr99rnYbz79eXmv3dlnPQWlSGpex7U7RelQ96ooWVvVjZ 1L2nlk9566Jsmfy8hnkVbnOq09QJkT8RGc5nSMsmak6r4DuWp2X51cVt2/hybcq200HzXMJ818lT NdFX3aIy7su/jVNUFvP4edW8qINJbbc+//x/hGWsaf7rwNmf9FCe2r5AVH/qKqPWufajRdtrHn8g rmW744470vzTY810LOLnp0odrODGerYO66Ww/rvuuuv6dZ7mQ02LfeCYt99VEGXjaRyVHZUZXbHM 208XiQUjRfv8tuoln1eifY62Aa1XBdd+e9d/lW1TMW1tI2X1kykqI+GxjZ+Xxb39keZH3xVtS9LG dlG3LIfHLX79xNZvle2qje2hrf11G8fVGD0F7KQWU69iSFPvgCv6vVJvo+uP19uIo+OUJft9b8Oc 9bmm99LGjf3vY+nu1atn/aZKsnnuBd1zvtOy6rtwXnzSfNn/9yqL6Dix1NsBpdO134ZJy9qraPvj 5M1Dr9JP5z38fSxdcfnl0WlYCvO3V9lGx7Pk5z/2veatbJ3F8kx5Y3lflsLyeO6yZdHxfCpbrryk eY1Nz6feQVi63LHfK9l4RWWqarL8j+Wh5bvKd/idJeWDzY/yLTZOXspbP+H/tVE+tV3HxrcUy3Nf F2k78t/5VFaGy763ZOPkrVfNn+bTxstLRXVI2TKV1SmWNI7GDX+vpOmWbbOWYvVtWX51ddu2FJbV sum1kedKZcumde/Xf2waZalsH6r89vMRlrFB8l+/rVquiurPvKS8zdu+wuWwz7VO/Oc+6Tc2Xlin KZXtC3ydFfu9kuo7/xtLRfNVlJQH4bTKjsPaqJeUivJD613r37aTpsvXxjZi85D3vSUbJ29eVc6L yrPWf9G2ZGnQ7cK+K8vTsn2wvo/VT1W3q0G3B7/e8vJKqWz9aX79OGFSXmv6Nk5ZvpGGn2gS37Je pZ8NFd/nak27dKa2yRUO0Zkv8U1xRNNT5zY6O6czfUbj6wynzspVvULo7ZI1pffPGTVVnsHum4/7 +8jK6CqLzuypRYBfHuWdllHLqrOM1qQ5r2mzruLq6r+mo3yw/BMN6wyizngrf3SvfxF/pUvzUdZj uM2Tn39P86YOnPT/4TLqbK7mKXb1V3lzzLHHpt9rPI3vaZn0uZZZ43k6s6srPOHv7D/1XdP7cDWv RfOkzg+POvrowqbweeW7Cbtfzz/j2diZfd+UMGSdamme6raG+fqZZ6bl1OeD8iC8QtlG+dR2Hft9 UZ5bT9wa/3l3L3zIyrCfrldWxo39vmg71XxqfjXfnpXNvO3BlC2Tr1Niea3P9J3GCa/yGjVdtKtD uoKiebKkede6sumqRUnvwDUdNmX51dVt2/jHGmo5y+rANvJctGzal/hp6FXLpc91Rcqv/yZsHxrm n/5T61r5vfGll7JP5/YGPkj+67f677zyr89Un2gaRfVnHuXt0qVL0/nw+adlC291s++L6mC/7LFe /bWdKs80fWP/p7KtOqs/HzlPBVB9p7LhtxUN6yprE8oDLb9RnpYdh7VRL4nlh5+Gfq/6Qutd69/q hrw6skwb20hb9bnKuT1i2P+XX/9F25IZdLuw/y47nrB9cPgfeq/P8zoSrbpdDbo9+PU2yP5a89vG cTVGKxrJk0htJzv7qDOUse9JpC6mpi1DSJOb/FWOoquc+s7Gi11lH+fkt4tJWzbS5Cdd+bXyW9Y6 hEQikeY7cYUdI9E7cO3fm2OPRgPGgT26Suq0DMHksl6NddWl6Cqn/27blp5F3BXLXG/vutcTGCfq z8eUtQ4BgPlGwI6R8I/48j1aA12nR1eJmoo1aYKKyWPBd9nzlH0zeP/ovUngH7+m5qrAuNCti9b5 rpoix5o4A0CXELBjJOzgTlekmt6zD4yaP7Br8px9TCZ7rrjKxn1r1855trhaFN14443J6dn9rDrZ o0ceTgotr7WY8o9uAsaBbx1S1NcQAHQFATuGTgevdkVKj44AxsXRRx+dvuoqYtPn7GPy6FGE1lGP HvWjxzy+tmlTP6ms6NE76pRO41307W9P1FU8/3znlbfckg0B42Hx4sXpq+r1QTtfBIBR4DnsAAA0 oCbvixYtShYuXDjr+bm6ov7qq6+mV+8mMSB4aeNGns2LsaQLCHbyVb1hN3mOOwCMGgE7AAAAAAAd RJN4AAAAAAA6iIAdAAAAAIAOImAHAAAAAKCDCNgBAAAAAOggAnYAAAAAADqIgB0AAAAAgA4iYAcA AAAAoIMI2AEAAAAA6CACdgAAAAAAOoiAHWPlkwcdlLy0cWPy2qZNyRWXX559CnTfucuWpeVW6Zhj jsk+BQAAAPIRsGOsnHLKKcl2222XDj/62GPpKzAOjjzyyPR18+bNyX333ZcOAwAAAEUI2DFWPvvZ z6avb7zxRqOg5761a9MrnE+tW5d9AgzfggULkgMPPDAd/t3vfpe+jhO1CLDWAWopMAkmcZkwPqyl 2I9uvTX7ZPLN1/6XbR3AuCNgn3DaMWon9ez69WnQMEpFTdftu69+9avZJ+XUHH733XdPh5sGPe97 3/vSV5tOl+jATXmivKmTL2iXP7gLm6777+o4Y+nSbChJHn/88WxofOy0007ZUJLsvc8+2dB4G4dl ok6YXNZSbLfddktfp8F87X8nsf4CMF0I2Cec7Rh32WWX5LDDDkuHR8UOSN5555301ejA076r44yv fz0bSpJrr702G5ocduCmvFm8eHE6jNHzB3ev/+Uv2dCML33pS9lQPYceemj6qpYh10xg2cVwUCcA AAAC9gn38ssvp68KFG677bZ0eBT8lck/ZvMQ88gjj2RD5Q7ODli1TL99+ul0eJK88sor6avucf7Z z36WDmP09t9vv2woyS1ntl1VoZYhe++9dzocaxmibaWoNQqmF3UCAAAgYJ9wn1m0KPnQggXJfvvv n30yGv4q5fPPPZcNzfAB0aaKTYsV1KiVgPzqV79KXyfNP5x+erquPrrnnnRKNo+2e//701ed5Art /pGPpK/vvfde+lqFOko0d65alQ1tpW3FWpzYfwNCnQAAAAjYMRR7uHvUwquURQFRnlNOPjkb6gU9 d96ZDQHt22XnndPXt956K3317B7M2Hd5Bu0oEQAAANOLgB1DseDDH05fi65S1gl67P7NF154YSKb w6M7rHVIrHzaPcVvvPlm+lpGLUOsH4knnnwyfQUAAACqImAfIj0+xHr4FfXSrntUred2JQ2Hvf/q vT3+REk9vN94443Zt/VUeYzKxd/5TvLYo4/2/0/zq9/p8zp8D9onHH98+pmasdtnluzxVrqvV+8t f/IoH63J8KO9+Syi+4XvXr06zTP7Py1L3R6WNX44HQ3rM/1HSHll45U9NsbKhZKfL5UNfab8iP2H 0X9pmey+ZyWtv7L1pWmq12lf/mxdl+WPyq7KoP+t5UfdvA3FlqfqtPU7jW/bh/LW1pmmV/WecMt7 Jbvf/OCDD+5/ZsnKocq33uv/i/iWITf/8IfZ0Awtn6bxr//yL9knW6drKW/6dctnKFYW6vxetN58 vaHfaz0UPY3C8lm/EytXfjk0T2Vl2cSWw6av/2rjyRhWb/tlVdJ/6r+r5ne4vmJJZdaz/NLnRf8T y4dRb9taZ/b7pnWgGSTP/X5Iw3mq5m0em7+w7Cnp86plOMYvgyg/tD7sM/1nrGzH6lKNW7Zd6v80 fc23/61SnXpB44TlvEoZtPE1r2UsvzWvg2hSf6ncann87yzl5bPyxMZR2S2icS3/Na2Qph3bLvR+ kPIGoPsI2IfooGwHp46DtEN84P77k9NOO23WI000rAN27dBUGavi1XsLakVBrw7kYxV4maLHqOj/ tJP5xje+0Q9SREGJ/l+f1zlgG5ZDDjkkG+oFPStXZkNzaYeljpkUaNn97qJlUZ6W7SyNxtP44XQ0 rM/0H+HO8f7eujWnnnpqNhR35JFHZkOz7++3WwWU//vsu2867Gl96WBB60XLZMGjaP3pc5Wf8IBB NL+6leCII46YVRZsXWt5daAVo7L7y1/8Ii2D/reWH/ptE5qulb9wefy08+ZLrHyLlvGiiy7qrzNN z7bB+XLAAQekr7GOErfddttsKJ9fPtOkfHo66IyVBfu9viv6/Xa9+bZy6OsN/V5l5Cdr1kTLoPh7 9FW3WLnyy6F50rSL1ruoPtSyhsshmi/VtZq+yllTyitNQ9Pyyyr6T/13WX7ru1i9FOO3ASmrE0TT 78K23bQODDseHTTPff8pfjhUJW/zqOza/IVlT/S51cdN+PnWtqRtSuvD6D/9U180jv4rVpdqXK3f om3hwgsuSKev+Q7LoK8XtG7y5JVzK4NF+98NGzakr5rXov/Q/Ft+W4eMdQ1Sf2n/ouUJy6VYPus4 z5/cUL1vLQ1VdvOmLervxPJ/05//nL4aLbsdQ4b/b+VN+9Oi6QMYXwTsQ+Sfr3rtNdekOwQ16f7+ 97+f/PO3vpU888wz2be9ivzww9MdhSpeVe433HBDOs49996bjTEzTpsuvvji/s7v9ttvTw765CfT Do70qv+vc4+56P5c/V7Jfqv5t88sGf2H3qtDpSIW9Ci/8jqp085MOyzzxBNPpPmn9NBDD6WfaWcZ 29F6CgI0nuj/9Cg5m2+tN+sdXP/lDyy0U7bvlKd5VyO0M9UOXzT9Os37VYbst76MaL60vKLlCx/f p4NLza8OBDSPGt+WSctn5VAHWrGDKh3M6bfqqdr/Vo840/rV53UpH7Q8Vv60Xdjy2Dqz6ebNl3dg r4zY+te0NF9arqq3XVxw4YX9ZTKaD1tWJb03Gk+fHXPssdknc6lM2oFrrKPE5cuXp9PUtmd8uVW6 sDdfXtPyaTRP55xzTv+g0P+f5kPlSt/ZY+hi9P8qh74M+vpC61R1SxHVjTqI13/5OtGXJ633vBOG ygcdHIvGV3mx5dC8aJqi6auc5W2PRfTfOkD3eWXzqVfb5iQvv/W/Vi61bvRbW1+aT1tW+84/urKK Lm3bqsss3+vUgb5ObyPPR0H1ivJG86980vxZsu1IVB8XncypQscFyk8r50qavj/Ze/uPf9zft2l+ rH6yfbl+W7QtqBNNlR9N27bpMM/1+zPOOCMdDg26/733pz/NhmafoA/N6ssm0oFnFYPUX8pH279Y ubTfW9lXna8y7Pmng5yxdGk2NJf1d6L/uey7302HxfaXmra+0//Z8Zptq6J5V3kBMJm2kIaTXtu0 aVbq7bhnfd+rhOeMc/fq1ennfryn1q3rf+8/r5Iee/TR3N/ad5p++N2gyf4zXObewUL/u97B2azv Ykm/t/F7B2fRcZTuW7u2P94Vl18+5/veAcWWZ9ev74+jFI7j503TC79X0rqx6YT55uc1Ng/hOGHe 9IKQ/ndh3ui9faf/DcuIjfPSxo1zfmvzq9fY75R8/oXj2Oe9A/5Znw+SVM7Lpqt1puWx8fQ+HMeX b6UwT+smn88qD/47v+7853nJL2Neviv5/1QZiI2jNGj5VPL5Fcsr/V7zrfH8534elWL1lJ8/rTf/ nSVfxpVi24nP59hyhv8TridLPv9j0ynLd19f5NU9fl5jy6yybd/H5tP/Pla+i+oEpa5t23558sqy H0fD/rs28tyv11ieWSrL20GSL6PhtmSp6Hu/DEp5db6Sz4+8/Y7Klo3TZF37bSmWV76MNd3/2vda p3nL6st77Pu8FOZn0/qrLPll9J/7aefV3X4czZ//zud/rJ5QUr7bOEXHSiQSaTwTV9iHpFepZkMz dNbdnzGV8GqxztCe+JWvzPm8ziOkuqC348mG5j6D3Tc9DB/3FrNo0aL0VWeVr7n22nQ41Nvxzrry rKulIV39P+roo9Pp5Fnmrtbo6meM1o11HhZeRfLN9e1MeciuXIZn0Mscf9xx2VCS/OCGG6ItDfSc fTWp88/b1xUou8q7evXq6O/kjju39rxfdAWgDVpfuuInWl96dFWM1tmt7qqgv7oSE9vG6ip6ukFR R4oxVVqG1DFo+dSwXeFSXRPLK/1edVB4Zd/T8sTqKeWXXdHV1Tj/3zFaX7FtVfNl2+nChQvTV8/n g8pHXisVzaOtK9UPKndV+e1GVwvz6h7Nq78Cqd951spK+R2bT19n+NYdVXRx29by2Lo7OOsoNJRX B7aV513gWxvEbmupQ2X4y0uW5K7fY7NWPnn7PlFdavNj9VId/gr4jh/4QDY0o639r9Vb6ZX8SDnt Bd398vHzn/88fW2irforxncs6usbTdtaP+XVRb51zcpbbsmGZu8vVe6VlzE+34taKQAYTwTsQ3LQ 3/1dNjRzsBbbiflKWzuyvINk2+FXDRSqsubCOrC/b+3aRjuomKKg3D+DPe9A2/gDAd+kLOSbgBf1 xK0ddNF9b3vttVf6qh1r0bw96f7DL6umbweSytPwpI0PmIqWJ8bmTeXEB+ShcL79PdxF9//7aVpg aqzcqSnhjTcWd8pTxVdOPDEbKl5f4ufZ32ISk3ewWkdRUF7n6QYKInTQJ+vWlXekVMWg5fPo3gGz ebpk2yua/st/+lM2NJf/ruy+4PXPPpsNzWXbqR2ge5YPEjvp4PntLLxVpIjfbnywEvP4449nQ0my 9z77ZEPVLPjQh7Kh+rq4basOtDzXulOQ5RXVgaPK81HTvmAQqiPzgnWtL5t+2T7lhRdfTF9j21Qd YX63tf/1nXLGbsnxJ611P31TbdVfZcL6Zm3vGMv80ze/mQ1tZSe4tE36oNzvL325j7GTMkV9NwAY TwTsQ7Knuy/bny31fEWsg+y8g2TbIb/66qvpa1uWnXvurLO+6jBGgfugVyyKgnLr6Mf+t4g/y160 o/L/98Lzz2dD9Vk+6/W13sFFXirqiMnPZ3hFWFe/TV6ZyGMHWXU72vFB7tO//W10eSzluejb3+5f GbHOi+5evXrOCYmq/AGfDy5jdJBn/513/2ObioJyO3FWZR1U7SixjkHLpw/WioLlrrN8sIPTIq+/ /no2tPXRkFX47aboBJlsfOmlbKhXRj/2sWxohpUjld1YMOzrhLJtIdTFbVt83eaDLCmqA9vK81HS CYgf3Xpr2uHbS0Hv6qOor3xQqJMu/v/DZH0+FLn4O99JjwGeWje75/uifV5b+18dK9gVbuVdeAHB t1gqOqE4bNqOr8h6an/W9YavVJTHfj8QtsDT9pbXesDvL3VvvP+/MI2izAGYHwTsQ2IHHzpbmnfw 4SvivA5U/BWKojPDTSgYUlM737mQAnftFLQjqhO4a+dqOw31Ymr8zkTJdmg+6Ah3zMY39ctrHim+ 5+m3/+u/sqHhU56FgZ3m0/IybHpoO+nwDHrXhL3Tal51oO2boaqJnq6I6KBlkIP7KuqepKhLB6lW Fq1Fhw587DNLdjBkB8baRmJ0QOebMOZdHRu2WPmcNqM4MVG0LatjKqPOoPy2onJ3wgknpMNF+4k2 jWLb1jS1PDKsOnCQ37ZFgbpOcqs+UN1gLWq6ztaNp/Ws+kwdx6kOtJNiVbS5//WtkfzJnWG0WGpC 26x/gkGd1graD9gJCeWvP+6Z1ZneAK0HzLTX+8AkImAfEju4L7oq7q8M5B2A+LPXda/AVKGdyFln nZV87vOfj/Z0qh3UfNDOzA4a6jQfD++va0J5YL0lFyX1bh9bb7aelId2wOuXp6wZ+LDEliGWYs2M dUVD9/3pPtuwF2T1XjvMoN1OftmJkK6r2jKkqUHL5zTx9efmv/0tG2qXL/ux/kas3Gr7VyBsJ4Cs d3d9ryvdg4it/1ga1bZtVwm1fLYP8XXgIPcgS1meD5uusCpQF7UW8712W6rSAqRNOvHu/z8v7bf/ /tkvZugE4/e/971+8Kle3f3TJ5TUE3oVg+5/VT5te/niF7+Yvoq1WNJ3ZbfBDIvKnN9mta1Yb/yW rLf2PA8++GA2NPuEhJ3YUpkpaj2g9eD/Ly9pewYwWQjYh8AfTBRdFbdApGjHvscee2RDc59X2yYF 7toRfuHQQ9Odgu00v1Kx4tdOxnYWtjza8fudiJLxBxexHZTfmZU9vsWfyBjkfkZrpu+bZjbh53fp 176WvvoOZfy9elXZ+qg7b/7qdJMD75DWle4V10GfDlhEBzC2nFX4wMkHVDE6mLQrK8O60q5yH5ZP XRm1z5T8AasdNIUHvqZKR4lNDFo+6+R7l9XZFnbddddsqN7Vdh8Elm03e370o9nQ3PreHlGmK2uq 8/zVTa1PfaaTpU1OrHRx2zb/dtVV2dDW7cHXgbGriG3ludfGCdwYCyZVFtVKTXXIfLSk8ccEdjtP XTrBaMG6yqM6Aa1THtva/5rwhLf2ARbQ1jl53za/HVy6YkW6rRQF1zG+BZ6VId+Z3qOPzn1uv7/N YJzrbQCDIWAfAt/hXN5VcV1tqBKIWC/JOtAb1QGBmmb6nWZd1rpg87vvpq8xZfe61Wk66Tu20/O4 82jnX3SQb60htF7CzpLq0PxacGUHGtahTNkZ9DwbNmxIX8vmTQc3Smbjxo3ZUP1eqMvogMWWs04n N48+9lg2lN+bvvFXq8s6ShuUz9eipp1FJ86U91U6Smxi0PLp89138BXjm2t2jd8Wym7bse1PB8l1 mpw/5+qUsqcT+P4K1ETas1sj1FO7WjIpGLaTQJ/pBbL6rGm93sVt22iZrPmvtgdtF2V1YFt57hWV 86YBrth+Ufvu+QjUjf7bTgKpM0Zf91fl+7bIO14p0tb+1/gT3ioH2gfYsVJZZ4TD5LeDQW5fCU9I WD8PqqNi/Z3Y7SpSVm8DmFwE7EPgO5zLO7i3AznxB14ha0LYdodzOiDXPWt5B/5Nr+J5YVBeNSDS TqxO00kd/NnBpX4Xa8avaap5p+34Y/zBwD9+4xuFBz/6riio+dWvfpW+6v/U+3LRGfQq/H17efOm /NX9dT7I1QGAndE/4vDD03woEn6vvNS9rLFl1TzsvPPO2bvqdELDWmFofal5aYzm5fTskW9aBn/V btjC7Xax67Cs6ADd9/5btWPBqlfJBi2fynff3Dm2neh36nRsZUsd5Q3DrMeUnXFGbj5oOWy7e+jh h9PXqlTW+tvNEUfkbjfKQ6vLVabzTi7qoLxofTXRxW3b881/VfeW1YFt5bnfnnTCJsx3vddy24m1 QeSdzNA82onrYbNbrLSvUT4X0bouKof+sZZG46u+ydPW/tf4E96qd62FhuquQQLlNsW2GS2jtsMy 4QkJ33ogtm9R/tr+Mq/e9srqAQDjiYB9CCzYLboq7puOPf2f/5kNzeYD3LY7nNMjS3QApd5fdWCr K1X6P72ql1g72PBnd6vwO4umVymbdMByxx13ZENJep+ZOgTS8ihp+dQMXQcLdkAYo4MB3ymMgl8/ HSUFl8offXd5TqApPri0jvb03017DFeTS39Q9MD996fzonnSOtMyal2GB0Qqf/fcc086rO+UD359 K+kAQJ/pBE7YXF9XX1QWtB58Xug36kTL/q/uiQgfzKoDHx1Aa5o2ff2XP8DT87aLAuU2+OaGef9l 6yBPk0619F8WSCuI0Akey2MNmzbK580335wNzWwnvizotypX/mRiFykf7ABWdViYD8o3lSdbDq2z yy67LB2uSuvEB/nhdmPbnPJQtG1ffsUV6bBn86l5CXtyV0/cmk+tL81zXV3dto2a/1q5tnVRVAe2 leeaji8fWhYtk6ahMq7youUu2heUsf2ipq95sgBOr34eR0Fl2+ez1rXtGyypHlFZU2uEiy++OB3X +HKhE6TKZ6N8U52g+qZIG/tfzx6Bpt/YiZX56vvF+O3g+uuv7x/r6ISG8rfJCQmdmLLfFLUe8OVc +RvuL7XOlOeqU5TX+gzA5NlCajf1DsbS1DsQi36v1Ktw++PFvlfq7XT74/Qq4Og4Zanof3qVe/+7 WNL3vZ3RnN8VJc2n/T78rV8e/3mYegcc/f+PfZ+Xejus/vRjSf/f27H238emoXnWevO/y0tF61cp nE7vwCU6niU/b7H1rXkrW2da37F15qddlF7auHHW73oHoOlnsXEtlS1XXuodcJROW99rvNjvlaps R1WT5VGs3Nm61P+F31lSXtm8qCzGxslLftvwKfy/Nsqn8jM2vqVYnvvtWvnkv/OprAyXfW+pbL0q H/w4eUnjxLYHpSrLVFanKKm+6h28R3+v/7b6rCzF6tsq+eXHKUqj3LYthflXZXqD5rlS2bJp2+gF Of33RWUxlsqmr+/8dhqbhn0Xq1OqlE2flBdl+wZLqmvC35fludabDTfdVqrsfy1pO/C/VVKex8at kqrmp5+/WJkoy2OfT0VlKqzvVZ5j4/mk8lq2vVoq2jZIJNJ4Jq6wt6y3U8mGih8/Yk3p7IpZjD0u RWeli65IF7GOfGJXBnUPpe8Z3ui9Ptf3ulpRhzWp0zyHv63yDPbeTq7fdNKalVelznLUIZjPU82H roboHk/dl2kdb+Wd6dc8H3Pssel09Du7cmGUN/pc+aPxiqhJqP2PXsvuv/Pz5u8LNJo3dXCkDqH8 OtP4WmbNkzoNjK0z3SurPFBHgGH+671+r+mqAyxPzfH0mToj8r+z/1Q+Ne2RVq0G1Llg3jzpc32v 8fIUle+6dsmaAL/99tvpq1flGeyzOtUq6SgxpLKp9eeXQ8Ph1c02yqfyM/b7ojz3jwkq6n/Cd2wX e7RQWRk3tl41XozyQWVdy6ly6Mersj1IlWWyOiUvr7XNHHX00bmtKXzv2xpX07Kk+fMd0ekqZtik uUp+dXHbNtcGnS5WuQd50DwXW7ZwGloudSipbcM/y73uY7Bs+srzcBuyjgTtnvy8Mmyfx+qUqtub UV7Y/jy2PSjfNK/KV9U1IeW58kW/NWE5sGn6bdxrY/9rtM3qd0bzrzxvqq36S3ms8ue3F61/W0bf cqyoTKlViy83VW79U4sVlSv9v/LD07T0mcqe5qNq6y4A4yUayZNI85H8Geq8K2MkUhdT05YhpMlM /qpe7KqmJX8VvsqVtnFLk7xspOEl3xKoqJUViUQiTUPiCjs6xTpg0Vn6vCtjQNfofsamLUMwmXwH VLGrmkb1nF2N23bbbdPXSaF7a227mM9HcmH8HOtaCDXt+wUAJgUBOzpDB3fWAUvR7QRA1zTpKBGT zQffCwp65tZtVNbJpz2yblL4x6/VvU0E00vbhHV0x8l7ACBgR4fYwZ3ub+OMOsaJtQwZ9F5LTI71 69dnQ0m/p3IfuCso0Wf+EXrX/+AH2dD407Ja7/C6x5b7alHVMtdTPSfvAYCAHR2y1157pa9PPvkk Z9QxNtQc3q6m2mO2AHXcZx1n6WqhHsfkH+2mR2zpMzUZ10lKdfo1SUHtP33zm9lQtU61AKPnr4u2 i6JORwFgWmzTS7qZHQAAtExPvjj+uOOShQsXznqetYIR9RD+9NNPJ/921VUTd5LyvrVr02do6+r6 0qVLaXmCSnQC1J4Nr17P9RQEAJh2BOwAAAAAAHQQTeIBAAAAAOggAnYAAAAAADqIgB0AAAAAgA4i YAcAAAAAoIMI2AEAAAAA6CACdgAAAAAAOoiAHQAAAACADiJgBwAAAACggwjYAQAAAADoIAJ2AAAA AAA6iIAdnXHusmXJa5s2pemYY47JPgW670e33pqW25c2bsw+AQAAAAZHwI7OOPLII9PXzZs3J/fd d186DIyDxYsXp68bNmxIXwEAAIA2ELCjExYsWJAceOCB6fDvfve79LUuXd3UVU5d7QRGRS1Dtttu u3R43bp16es4ueLyy/utAz550EHZp+NtEpcJQHfct3ZtWsc8NUCdr5aEmoaS9iMAkIeAfUzpINQC VO04RsnvZMKm6/67Os5YujQbSpLHH388G6rHgqbddtstfe0S7dSVJ8+uX5+enMD88IFcyL577NFH s0+qOeSQQ7KhJLl55cpsaHxs9/73z7z2tp999t03HR5347BM1AnA+Hrf+96Xvu6+++7paxM77bRT NpQke++zTzYEAHMRsI8pHYRagGpXpkfF72Re/8tfsqEZX/rSl7Kheg499ND09Y033kiuufbadHiS 2E59l112SQ477LB0GKNngdy7776bvnoHNbgSq0DrgAMOSIefeOKJZFPNE1WYXtQJAACgCgL2MfX8 c8+l93qLAoVR2n+//bKhJPnt009nQ7O9/PLL2VA5tRbYe++90+GmzeG7zvJDJyRuu+22dBijt/tH PpK+vvXWW+lrzCuvvJINlVPLEDtxFmsZcvF3vpNeRVWiI0V41AmYT2rZoXqpjRZ6bU4LADAXAfuY UqD80T33TD60YEFy4le+kn06GnaVUgeaIQuI3nvvvfS1ilNOOSUbSpI7V63KhibLZxYtStfVfvvv n32C+WDNGGMBu91KsTly9T3Pot56FZ08i7UMWfDhD2dDs1umANQJmE9q2SFWJw6izWkBAOYiYEdt u+y8c/oaC3qKAqI8n/3sZ9NXnQCgd3gMkwXNb7z5Zvrq2ZXyTX/+c/papo2OEgEAAIAiBOyozYKe oquUsYAoRs2E7V7OJ558Mn0FhsWuBIVBuW+u/seKt3P80ze/mQ0lyb0//Wk2BAAAALSHgH0EdI/2 3atX93t1t3u9vvrVr6bf2+NB6j6OzKaX9ztdAbzxxhv7vREr6V4zzYv9d1XWg7aS3W9+8MEH9z+z ZFcpTzj++PR92T1tp5x8cjaUJDf/8IfZUJzmWdOz5darlqXuY5t0X7GfjpLySHkV661Z/2H/V/Zf Whc2Tc/WcdEjYPTfymf1Um7T0H/qt2XrS99rPu1eQiVb12XzbOXT/1bzqWWpm7debHnqTNvWjy27 1o99pnmtWoYt75XMN77xjf5nSr7s/eu//Ev6mea9iG8ZEt6DbHmp7cDYdC3lTb9u+QzFykKd32uc sN7QsOariOWzfitWrvxyVCnLJrYctj2UzUtVmkeVRb+sSiqzWj9V8ztcX7GkcTzLL/13kVg+aFif lW1Dtg7CslB329Y09FstY9nv8upAM0ie63uNq/koUjVvQ5ZPes2jx2/ZPBc9isvmIZxX/UbfhfWi kua3bDu16TbZznyfGkb7c/tMqSxvzSDT0vJpXTbdNxTRyVflh6bt80Sp6nYjlq9+28nL1yLKJ7+c ml7VuhgADAH7kKmyvvPOO9Pg1oJZUVNaHcDr+7322iv97PXXX09fq7LpxR5jpp3WL3/xizRg8I8d 0RVGzYv+uwush211wJTXgZ1ox6l5Vr7ZcutVy6L8VT6W0Q5SO04Fa346ojxSXinPws7B1mcHbxp/ WcmzUhcvXpy+hvf3lz0CRv/5kzVrktNOO61/QkT0n1ZWdCATo8/1vfLCriCLreuf/exnufmjz/V9 +FvN5xFHHJFcnhNUltFBqfIyXB6xaRfNl/j1o/Wv9WOfaV4tr+eDDuZsXcaaw2+77bbZUD7rC8I0 LZ+eDgRjZcF+/8D99xf+Xh1KqhyG9YaGNV9aD3n8/as6GLdy5ZfD13t5lA86MI4th20Pmhcd3A9y 0Ku80jyqLPplFZVZld2y/I7VS3nC+3vL6gTpyrbdpA6MdTw6aJ77x/UVqZK3MRs2bEhflV958+Af 43jkkUdmQ3PZft2maS666KK0vIT1omh+bTvNCyoH2c522GGHbChfWd6aptNqY99Q5MILLkjzQ9MO /9+2Gx0zFJ1sydt2LF/z9sWe6ibVUaqr/HJqeraOfQe+AFBkm17aMjOItmmHoJ2zqFOqe+65J1n/ 7LPJjh/4QHLCCSfM2Vn987e+Vau3YJ2tlRdeeCH5QvZYNKMDf01f/3vdddf1O8TSQcAZX/96csTh h6ed1tWl32tHJuH86syzdmaix7sVBeCiAyK7snn77bcnF1x4YToc0kGJdu6i5Xno4YeTJ598Ms1H HTBpJ+rF8kMsT+See+9N/1vzqB2revs+/fTT0x28/kMd4dn86/unf/vbdFiBeF4nUX59h8vj/1sd TXmavoIkO7jU/KusvP1f/5Xs0ftMj7zL+60OgLXzl2eeeSa5/gc/6PcDoPk59dRT+9P9/ve/P6tj NP2vDpy0zDq4XnHZZf3fat0s/drX0tsfYnlZxJcD0VMM1IO6lkfrTAe8OhAy4XwZK9+aN1sGTUu3 Wxx4wAHJ2l5Qd9l3v5t+XoUOwnTwJHn5WLR+PV8mtT2FfS8o/5R3xx93XH9ZVSa0/ZtHHnlk1mPg mpZP45fPbyei7V2BlH6vaZ911lnp5+LLkPFlUL/T7+3gN6+e8nWOjav1ZbcL+LzQOJ/7/Oejj8Hz +aD18fOf/7yfbzrA/eIXv9g/iFbZUOdtIb9Msfn132telE/KLwm3uSr5rW1v+fLl/fV18cUX96dv eaAne/hpFNUJ0qVt20+vaR3YRp77acTyzJTlbR4//w899FDyD71tLqSrtla+NZ+x/aifzg033DCr ntLv9SSKF158MXnh+efTbUzCPFC5iXUoO8h2pvVojxC0Olrl4we9eTS61S2sz2KaTKutfUMRnezb cccd0xMlG3t5bbc4hdPPK8f+uER83qoe1AmFUKyMaT7s2ET/tXr16nRetJ6PPfbY/rZrwnoZAEIK 2Ektp97ObEtvx7ylF3Skr72dwJxxegd86feWwu/Lkv2utwPP/e5Ht94657tBUm+H2592L3if9Z1f Hv95Xrp79er++Mqv2DhKlo9Kefnox4nlh5+3XrA153slTdvGCfPNz2tsHsJxwrzRPNl3/nOl3kFo /ztNI/xeSfMc/lb/Yb/rHRzM+s6S8vXZ9evTcZ5at27Wd35d9g4wZ303SLL/K5quXx9ad7Fx7Hsb Jy/fqybLZ81f+J2tu1jZiaW8PA2TX7fK79g4SoOWzyr1jcqL5lfz5D/386gU+38/f3llzZdxzUNs ef02UvY/ml6sXtBnWo6i6RTlu99uNJ/htmrJz2tsmW0eYuVJyX6v/4h9X1QndHHb9vmRV5b9OD5f 28pzv17D73wqytuypPnT72Lbtt8GLcXyNy8fqiRff8a+b2M7U7LvNb3Y93VS1Wn5ZRtk3zBIKivH Knf2fSzvVAb8cijFxrHvNG6sHlMd7qcR1sskEonkE03ih0RXWOzs96233ho9Y62z7jojLfbadTo7 bMKrH/YIK51NrsKaw+vqUexKm/R26rOuIuTl46UrVmTv4nRGWzRveVfyNW1dWRSbN+Ofse3vuze9 HfKs5QnzpsjBWRNSXQ1Zdu656XBI86xWC55vmqqrezHKV+vMT2f0eweP6fCwaH3Z1U+tr7yrI1pn +l60fvW7IsqXKld9ihQ93aCoI8VQ72Csv4y/+tWv0tdBDVo+/fPgddUyllcqk19esiS57LLLsk/m ymvpovWl8ikLFy5MX4tofcWuwq+85ZZsqFeX7LFHNrSV5YNc2JuPWL2gz84+++zs3da+BKry243q 5rxtVVc3rS7TlTJt416/1Ue2fYWsztB66QUG6XBVXdy2fceKuoobKqoD28rzUbAm7LE8PfQLX0hf tb+27cE3kTfWHF7j1dkXiC9PZcvfdDubD8PaN9Tly7GuunvKb39VPFYXqm496uij++s/xh8j6Mp6 rB5T6w1dVQeAKgjYh0CVvppOiSp97YDy2EHfq6++mr62xQ561Hzrxhvb6+CkKCi3Z7BXCXp8IL6u oGOgvffZJxsq7ok7dtBitOyWz2WP31IzRbEDC6ODC1vmxZF7p33AVLQ8IR0Q2n/pQDG2YzfhgV/V g0JrFi377LtvNpSkTXTNOeec0/ieQe8gd4BbtL7EnwTx6zmkIHXQYF3aerqBPxjTvZCDaqN87u+a dtotKzEqX0VlzDfZD6kZr4T/HZO3vvzntj6Mzwet86Iyre/sJKf9pirbbqSobha/Pqz5b1Xbb799 NlRfF7dt1bFWByowD/cpRXXgqPK8DX7e1Szfs/pNdbXNp182afOEXtnyN9nO5ssw9g2DCqft87vo qTWqQ60+jPH9ChWVd7/9AkARAvYh+MqJJ/YPXHT/ZR5/1eWPf/xjNtSOi7797f4ZYN3zp/sP7169 Oj2YGERRUG6d4RTtyIy/KnHzypXZ0Fz2f6J7fpvwO2GdwHitt7PNS3Z/ZIwdoMXO+i/K7qNVnpcd kHr+IPvlP/0pG6rGAhW9xpbFkr9n0FMgoPsrRcuk+3GfzXqwbXq1zh+oFJ1EkY0vvZQN9Q6cPvax bGh4ioJy2151T2kZu4rY5OpZTBvl0x+Ut3FyYz74fLATE0XefvvtbGh2XVrGnxQo4zsCDU/UWfCq /hRirE6Qsm0h1MVtW2x/pmkqQPeK6sC28nwU/P7IB5k6QWH3l6sViwWVCs79ftW3hMo7oadpXXH5 TC/pWi9+nRbtg8bZqPcNOkl139q1acdvPn/zthnxncBV2RfksWW1k4oAMCgC9iHwO/lHH3ssG5rL 7xyKrmw1oYN2XR3wTcvU2Yo6U9FBQp3AXTs+29lZczEduPidoJIdzFjQoQORGB2sWMcvmr+iK36+ R9yi8doWa0Fw56pV2dDsEw5aHsuXsiuk80kH0uGJFh1Yq1MuO5DWwacOGHWVVid4wqtobRpFYKll sPJpQbmWzz6zZNRRlN7rdzG+Wac6vZsvsfI5beqe4GqiqF5WU1dRMKryYoGwthkFxlYnWB08TKPa tn0A6k9ItFkHtr0vrEv7GTXpF+3TLJ90It4o4Fx9993Zu9lBup3AyTuhp/2p7yXd6hNsNci+Qcc2 OvbQSSqVSTtZVIV/cod1BtiE7Wvee++99BUABkXAPgT+THLRjke9HZu6V2Cq0MGC7gnUwYTuTbWD fB0kXHvNNQNfbW/KX5nxTd/KtBE86p4x9ehalmK9x2pd2hlzfw+xX56ypn7DoAPy2DKESb0Zx8qj yp56i1Zv5+oZ2Vpm6KSKeq9vI99jfPkblwObqi1DmhqkfE4b3/qmym04TfiTqpv/9rdsaMZf//rX bGhmW1EgrJM9eqKEXSVVfZHXL0UVXdu2tU+xYFbBkJ2k8HWgv3+6iaI8HxXfLN6WzbZ9W34F9nYy xIJ05YcFiLHm8KrzFEgqoNO60H5Z+2e/Lrmvufm+QeX5+9/7Xv8kiMq8yr7PX53EqiK8v70Jf8EB AAZBwD5P/JW6YTeb0kGWOk/RQb4OEEQHDHq0TxW6UmM7O6PHreTtBDWsz/KCCt90suyRLb5pbNn9 fHl8U3p/kN+EHYQp/+y+UD2KR3RCpO6JFx9o1J03Kzf+BNEgdMCvjnD0GCC7KqiDz7DpaxF/cFV2 QmjPj340Gxre1VKdsArL50Gf/OSssusPkO2z2OOUxHeq1VaLjzbKZ51876q628KOO+6YDdW7ImdB a5XtZtddd82G5l75PeOMM9JXlR9tLzZdUSCnJul65FyTctLFbds8+OCD2dDWe7x9HRhbF23luTes E4niT8bZ/sruVX/O9Q/wdHYFXXmpYP3oo49O30usdZ3f56qjVO2XY1fhJ9Eo9g0qz3Zcpe1SZb5O 3eDvKR/k3nk7kVPn6j4AFCFgnwc60FBHQKbtDueK6ADBDgbrdkbj7xMtai5WdK+5lr1O08lNf/5z NjTzDNQ8RZ0q6YDZWhfooGuQA71/u+qqbGjmQE4HaXYrQFEnNXl0MGEHs2XzZlezjJUbnTyo2wt1 EeWXvypoHQ1W4Q9mY73pe/5qdVFHaW1Y7O6FzQugyk6cVe0osa42yqfP9/BpAqGwHHWF3xZUR5Rt C3YwbFc8q7JewLUuw74oQnaCRvPlT8Zpe7PAQM9O1gkeXeW2Ez66ql2nL4tQF7dto5Ostp7UQ3+V OrCNPA/5Juqeys2gHa0pn6w+0DapANPWtw/E/S0COnlhwX3eiQs/X3VP7o67UewbfHlu0qGb76wx r28KUXkoOvnkTz4WlffY0xYAIIaAfcjCM8k6uFFTRDvwl7Y7nFPwqvvUYwfmOpjZOXu81SDCoLxK QCT/9M1vZkPVmk76Kx36j9iZeS2vmhkWsQNJ5btuByiifMsLFrRsvkmomtsZ9Q/QhO/MLm/e1EGR Dlz8OvXN7/+xt/xFAY6+C8uD7mP90a23Rn/XtDWDTmjYwbz6Msi7kqJ1Zv0Y6GpEnasgg4gF5dap UVnTyyOPPDJ91fJVDcZ8x0W+qW9o0PLpAwed2Irlu36nDph0n35XqTMv88ObbsqGZtOyX3/99dm7 JLmjZk/9fnxdJc/bbrR99JvWuvkKadtsWxe3bc+CIZ008eUprw5sK8/99mTbo6dy/8D99/enMQjf murCCy5Ih8NAXFfH7WSb+q6pczI6XGei+S86Md2mNltxVJnWqPcN/hG0RuVO21MerU9bFpXt2IUA zbfqaH8MF/K3+p166qnR8q6ybssJAGW26SU9kB0t0gGcOpQRVf533HFHekVaO2IFnarotSOyqxJq rtvkbLt1lqVp6YqOUYdHuodSO0cdWNmBj3Zges6xXZlSk806V4H8cukqkmf/qeVVM9A8Chj0/zrI qXofrg48tYMXLdM999yTNpXUPWYnnHBCPx/1neWtzw/RDtMfyOn/1eOxb3KpdaPgTdNTczpdOYvR GfMw6In9p6cTKDafYd7pwE0Blx0AaFqP9sb/Yy8vtc7U3NR+q6unvgmlesG1g8RwfYuCxH333Te9 SqTe+/082jyFeaHfKF9tfsL/LGNlwagJrg5gtA1onenqiR2oaJ51xS92UJZXvpuwfIpNy/JB9zuq CWWMyo/uTRYtT16T+ZDWrV0h0rLqGdRaryprCj7slpA2yme4nfiy4OuecP79+iqqi4rKsJR9b4rW q/JBHXJZ2YuVTfX9YfmUty7KlsnPa5hX4TanOk3Pr/cnIsP5DGnZRFfaFHzH8rQsv7q4bRtfrk3Z djponkuY7zp5qib6tn/15d/GKSqLRWLLGCtvfrszOpEbq9P8yWUt44rLLkvH03JdfPHF6TL4MlVW dptuZ+IDRuWjTqpY/Vy1fjNVp9XWviFPWN9ed911/TpWef+V3rz4kzmxejTcv2u/YOVUV8T9/BWV MTvWEa1rdVJq+3SbDz+NomMOACBgH4Lw4Dukinm7bbft7+SbHlDk7ZDDADCmTtBhioLyooDI+J1p UXAUUn7e/uMf9w9SQtrp6X5A3R+ocfLmQWfGl/cOimwnWkT3+uv2gTwvbdw4K3/LTn6UHWRVOWsf yzPlja5E2oF9ER1IHXPssdm7+ImHUN2TOiZ2EBtSMKHHD+YdkLUZsFv+x/LQ1mXRAZM/0Fb/DWV9 L3g+8PLC/2ujfJZdtYnleZcCdlE++I6j8hTVIWXLVFanGM3jaX//99FWQ2qqfsny5YXbrInVt2X5 1dVt2/iARMqm10aeS9myabsSW/9N968SLmNs21c58I8K0zZWdDI6nGZIZcW24WEG7NrO8lpE1M2z OtNqY99QpGz6Pn/z6vyyaaj+VY/yRWWsrB7TcdTZZ5/dPyYq2v8AAE3ih0AHGkuXLk13DAomRTsg vdcVDVXKuioiqrSbsmmHzz3XFRN1LqQdgJ++xteBnQ4C6gbrskvWlN4//9hUeQa7bz7uH5FWRvmp Aw4dEPrlUZ5qGbWsOqixJs15TZu189eJBk1H+WD5JxrWgY2CAOVPUbAu/kqX5qOsx3Cbp7z1rXnT PZD6/3AZVW40T7HgRHmjA3V9r/E0vqdl0udaZn9ALzrwVHkMf2f/qe+aHtBrXovmSQc8Rx19dOEB WV75bsLuHfXPeDYWcBU9d9c61dI81QnW5etnnpmWU58PyoPw6l0b5VPbdez3RXluPXFrfH8PZ8jK sJ+uV1bGjf2+aDvVfGp+Nd+elc287cGULZOvU2J5rc/0ncbJCxzVtFZlR+MrkNM8WdK8a13ZdBUg hM1ry/Krq9u28Y811HKW1YFt5Llo2bQv8dPQq5ZLn2v/6tf/IMJl9I9yM9r3+Dwu68tE27jKR6ye 13rxt4rFnn7Q5namsqV8NJoPldu66kyrjX1DEU1f26OfF+WF3ut/VUda3lg5Cdk8htOwdaT6t6yM WT0W1v1abyrnKgc6ViubFwAwusJOGnF6bdOmNN23dm30+0lMz65fny7zU+vWRb8nkbqYPnnQQf3t 9Ue33hodhzRd6cYbb+yXiWOOOSY6jpK+s/HuXr06Os64Jr9dTNqykUgkEonUpcQV9nnge/0d1uOs ukbNw6xpWOz5tEBX2aOrpE7LEEwu60FaVwSLrgT677bddttsaDIsW7a192vfyRYAAGgXAfs8UMc/ Rh3vTAP/GBffozXQdXp0lahZY9NmmpgsFnzbrUB5fDN4/1irSeAfv1b3NhEAAFAdAfs82GOPPbKh 4meWTxI7uNMVqSa9EgPzQR0lWgdRTZ6zj8lkzxVX2VCnguoIzVOLInV8d3p2n71O9uixVpNCy2st pqo8wgwAADRHwD4PFi5cmL7qIK6oc51JoYNXuyKlR7IB4+Loo49OX3UVselz9jF59Lgp6/RLvbir 1/LXenW5JZUV9SCtTuk0nnq8nqS63j8D3XeSBgAA2sdj3eaBPUZKPagW9XQMAOguNXlftGhRehLW P75JJ2NfffXVZN26dQP3xt5Ftg9Tiyn16g4AAIaHgB0AAAAAgA6iSTwAAAAAAB1EwA4AAAAAQAcR sAMAAAAA0EEE7AAAAAAAdBABOwAAAAAAHUTADgAAAABABxGwAwAAAADQQQTsAAAAAAB0EAE7AAAA AAAdRMAOAAAAAEAHEbADAAAAANBBBOwAAAAAAHQQATsAAAAAAB1EwA4AAAAAQAcRsAMAAAAA0EEE 7AAAAAAAdBABOwAAAAAAHUTADgAAAABABxGwAwAAAADQQQTsAAAAAAB0EAE7AAAAAAAdRMAOAAAA AEAHEbADAAAAANBBBOwAAAAAAHQQATsAAAAAAB1EwA4AAAAAQAcRsAMAAAAA0EEE7AAAAAAAdBAB OwAAAAAAHUTADgAAAABABxGwAwAAAADQQQTsAAAAAAB0EAE7AAAAAAAdRMAOAAAAAEAHEbADAAAA ANBBBOwAAAAAAHQQATsAAAAAAB1EwA4AAAAAQAcRsAMAAAAA0EEE7AAAAAAAdBABOwAAAAAAHUTA DgAAAABABxGwAwAAAADQQQTsAAAAAAB0EAE7AAAAAAAdRMAOAAAAAEAHEbADAAAAANBBBOwAAAAA AHQQATsAAAAAAB1EwA4AAAAAQAcRsAMAAAAA0EEE7B11xeWXJ69t2pS8tHFj8smDDso+HR8LFixI 7l69Onl2/fp0OZTuW7t2LJcFGDVtK9pmnlq3LvsEgzrmmGP6ddG5y5ZlnwIoQ300nsb9OLIJLauW +Ue33pp9Mj7YR6EIAXvLrLJoklS5mu3e//6Z1+22S/bZd990uAntYDVtBc4KokflJ2vWJAcffHCy yy67ZJ8kyYEHHpic8fWvZ+8mi3aGtu51cDPOtKPTcmh5vvrVr2afYpTe9773pa+77757+orB7bTT TtlQkuy9zz7Z0FaUeyCuq/UR22yxto4jx4mWVXbbbbf0dViGccxXto/CdCNgb5lVFk1Y5dom28Eq cD7ssMPS4WG7+Dvf6f/vyy+/nHz/+99P/vlb30oeeuih5Mknn0w/nzTaGdq614mJcWY7Oi3P4sWL 02Fg0lHugfHCNov5MknHfBgPBOwtu/3225N77r13TnrhhReyMZLkiSeeiI7zs5/9LBujPQqY5Y03 3khuu+22dHjYFi1alA0lydlnn51cc+216X//w+mnj2we2qJm/XYGv8jzzz2XbN68OR3W+h1nr7zy Svqq5RlGmQS6aFjlXs0c7UqMb0UFYDBl2yzb3nBVPT6aRJN0zIfxQMDesgsuvDA566yz5qQXXnwx GyNJ7v3pT6Pj3HfffdkY7flML3j+0IIFyX777599MnzWfE4nCX779NPp8LiyJkp2JjWPlvOje+6Z 5vWJX/lK9ul40okVLYeWZxhlEuiiYZV71SFWfwyjFRUwrcq2Wba94ap6fDSJJumYD+OBgB1D89Zb b2VDAAAAAIC6CNgBAAAAAOggAvYxoR7eb7zxxn6v70oaVgdvRcoexxKbrnqU171JdXpd1XzY7/fe e+/0M73aZ0r+HjL/+Aqxx8DZZ5of69Ver+oN9rFHH531mDgl3TulZawyr+rVU9OJLat/5ImG7Xtb FrHPLGkZPLtXTv9RRHmlebbxlarmua1PrTPRvOp3flpV8yNP2aNg7L/sP/Rq82W/C/PU2DrOm7Zn PQArxeh/NT1fJmLrM2TLp/IkWo8atmno957lsf8flSHNX9kyxNa1fqv1Z+W7Kv2XTaOsjGlc+08r K1VY3mieJVY/VJn/sJzqETWWf5qv2P2kmudw+9S4dcqz8tuvS/1n1bwuK/cmVu5ieaJx9N2//su/ ZJ8kyQnHH9//jZLls6f/blrePPv/suWRsm0ttm6UlNfKt6L89flaxMqM/iOmSZkqE1suTVN5V5Zn g9Tj9hsbT8tiy2fTCcuThjWvfpn1m3A/5Nl+1ud9bBupsrxV1K2TrWwo2XoNablt/YRlI2+b1f/p 8yrbno0bTiOmbDspU+e4x6ubr1Up/1QWfPm3pM9VVkL6PxunzvGRaNnsP/24ef8Vo7zw251eB80H Y+VJ8yNlxwY2DyoXMVpeletY/VJWR8RofqwM6L8xXQjYx8D+++2XPiZNOxz/WBUNf+Mb35hTiXhF j2PRxv/LX/xiznTVo7weyeZ3dmV22GGHbCifv4fMP75ClZo9Bs5ofqxX+4svvjg54ogj0p2Df0yc 6N4p9dCpec3b4YsOiO688850OrFl1Xe2w9j1gx9MX8v4ZRC7jyvvcSLKb1XcWmeaZ3/fl8/zKutT tHNRRzv6nZ+W5UfVHWCo7FEw9l87fuAD6bzqv3wvqfre8jTcaa/v7WxE4ywrec6o9fqrvhBC2kHq f/U/vkxYPipf8pbfl0PN37XXXDPrwEO/N5qG5bH/H5UhlaXLe+sgRmVaO/rYutZvtc1p2wvzp4ju mbO80H/HDuzMKaec0v/PF55/Pn2twvJG5Uzz9sD990frHX2mbTZvHnw5VR5edNFF/fzTfB0UHFxp nNj2qXGtPBdtF5oP27b8utR/al61HKpHi5SVe1EdEyt3lif6H1un2267bfpaxOeTNC1vMU22Neuk 1NMya57CdSPK69NOO62wLPt8LVK0r5K6ZapMnX2Cp+UctB6331gdqmXxdaim47cxzavyWPPql1m/ Uf2Vl/f+HmNfJ4XbiC1v3nSqaFIn/9tVV/U77tLyxv7/+9/7Xn/9/OCGG9JXk7fN1tn22tpOqqhz 3GMG2dcVUcCobVdlIbbN6XOVFQteTdPjI61b1Y/2n579l7arvH2K+OMN24b0qnzI217rqHNsIDYP sWM+/b6t42ux+bEycGvOSQJMLgL2MaAKThu8epq3R6SpV3nb0Wnjb3K27sILLkgrHE1H01XnGUpf +tKXZk2/Cu14NV9KtjPTq32mdNlll6Wfh7TT0vLp//ToNyUFJuqFUzb/7W/pe/XEqV74/TQ1rt/h x86yqqI755xz+pWrpmO/1/Q0bX136KGHpt+r8xr73u+Y7TNLdXq8105Ila1V3FqXN/QOPmxafjm0 PvPO2JojDj88LRfil8f3Vnr66acX7vwGpTzVvGq+VV70/ypH9kQE5anKmHfzypXZUJIccMAB2dBc OkC19fXzn/88fTUKIHTgKs8880z6bH8ru/p/W2c6ANB08uiAQutE/6MyoGVQ/tnvlXfKQ9Fn/n80 7PM6dPuPf9zf0Wu62qb0u4M++cl0vSvP9L/6/zpXBp5wj0U8Y+nSbGiuz372s+mr/kdPaajL8kYH B76s6tVOGqgs//Cmm9LhPAf21rHWg2g6ygutM9+/heoujaP8UD77ukj5rPGlaLvQfNi2pfnz86tp ajlse2lKB4OqY8SXeSXbfvU/WteyfPny9DvVMcZvq0oXXnhh9s1g5S1G25rmSapua7/61a/SV6Nt zS+zltPmXXnrt/W6ZbmpKmWqTN19gmm7Ho/VoZqeTUP/o7pEAb3mR8up7UPJtgt9rqC2jPazqpO0 bLYfDetrTafJPqNpnbxp06bkuuuuy97NHJN4qhtsusrbqvvcOtteG9tJE2XHPdLWvi5G24v+W9P1 dZmSbQOiMuMD4SbHR7bdqH7Uf6qMa1+o5bDjTVF+KF9idIFC24poGjbPti1o3Vi9MKiyY4Mq2jy+ Vv5p27Typ/y77LvfTYcxXbaQhp96Fe+W1zZtSlNvJxQdxyc/vlKvspozTq8S7X9/39q1c75XeuzR R/vjhN/Z572DijnfDZLsP/Ua+15JeWD/r/TUunVbepVSdNyy5PNB+RZ+7/NA44bf63/vXr06Or9F +RcmGy82HU3fvs/L795B5JaXNm7sj6f34Th+fjRurCz5/4qVm7JUVlbtOyWtt95B+pxxnl2/vj9O uBx+/mLLGI7jp69h+zyvzGt92v9r/sLvw21L/xWOo+TLaO9gKDpOLPnymJf/Wm4bJ1Ye8sqdX/5Y OQvHyVu2vFSl3lH++nIaW/9+/pVi250lW1d6zasDtK5tWuE4Pi/zpqE8tnGUYvVEUbn3y6zXWLlV Pqi8hdP25Sj2v5aalrei5Lej2LYcjuPXpS9HWubYelbyv49tkz5fw+98yivzse+VispUWfLTqrNP 8Ms6SD1u3ynF6lBfFizF5tMvR+x/wulo/mPbR1l++O/D73w5aVon++3b1zlldUPRNqvkl79o2/Pr te52UieF60N5EVsupTbytSx/ipL//3A7sFRULnzyeRcrp0pa7zZOrP4r26ZUbv04efNclHx+KWm+ Y+NZKvov+67O8XWsvGoda93a54PUe6TxTlxhHwM626nHxYV0hs3O0i1cuDB9HUc6g/nlJUvSs+1N +DON2wVN4Xo7nf6VTl1JiJ2V1P/qsRz+alebehVu/8ywlvUfsqtoIZ259s2cTjn55Gwobtm550av OKy85ZZsKEn22GOPbKh9tt5ij+7zV8UP+ru/y4ZmPP7449lQfBmVX3alQ2fO/fR9k0VdRYnR+rQr 0TpjrzKQR9Nv+5Esxx57bPqq/Iltt6J1bVe2iq7qhJQX9juV69iy6SqM8WWhrrx6R/l7zz33ZO9m /1+MppN3NUBXhayJ3+rVq3PrgDvuvDMbmtuywJehvGlom7OrOE3oP+3qxkMPPxx9hJTWjbaHvJZE 80GPEDXHH3dcNrRV1W1N9VJsOxdtPyrroqaqmuawFZWpMk33CcOox/PqUNXr/mpe3hW1R11z5UO/ 8IVsKM7qutj2cfkVV2RDvekErQrKtFEnf/3MM/vHMieccEKa172ApV83aP7y6oY2DLKdNGXrPm+5 2t7X1aVltH1NeOtOHX670VXqWN0pfl9zyCGHZEMztJ+w+jdvGto+Ll2xIns3uGEcG9SlvLOWGMKV 9elGwD4G1j/7bDY01yuvvJK+2o6tDjvIUpMr7RxVOcwH7XDa2hmH9xIdffTR2VCSPF2yk21jJxzz lRNPzIZmlrWIbzKedy+8ydvx+c/D+8japCZ1eevNl9kFH/5wNjRDTbSt7C3O7gn0fHC0bt3sTob2 2muv9FUHs0Xr60mXz3n3I4sPBEO+aaKarl5c4f44bUO2c/3d736XvuZ54cUX09e6264/SI8Fywe7 e//zykgVRfXOo489lg31DhQ/8pFsKC7vpIX4+4592Q/Nal4ZlCe/nRQdzPgyUdf++++fDSXpPaN5 tD00rcualLcyyjfb1hRwhHV8lW1Nyg4SfVkP78EdhqIyVabpPmEY9XhRHfr2229nQ/n5/0cX1Pv7 b2Ne/tOfsqG5VE9YwFy23wm1UScrD+wkoMqjbgOwWzEUOMVOTLdpkO3kmGOOSZvux5K+y1N23NP2 vm4Qtk9rwm83/mR9jJ0gCI9b9t5nn2xo9smVUJvlpOjYoIpBj6918cnfNqF9PcH6dCNgn2IXffvb W89q93aO6iDj7tWrC3cy80k7QM3fY72A5bXejs6nPP7gvigAGSa/sykLGrQDt3ViV4EmkR3g6yBI Z8+9RYsWpa/Kh3AHZQcOeg3LgE91O3SJ0UGSzmiL5lP3xz27fqb35rwrGT5Y0Y46Nm+W7IC0LuWJ lRELzo22XTsBEN773yZ/ImCQqy8+OHj6t7+N5pOlPDaNOvcX1uUPIAc5CVKkSXmrwsqBphm2Tqiy rdlBdJHXX389G4qfhOuSpvuEUdfjRQH2MNjJfwtMq2qrTtZJGN96SJSHuvo+Ck23E91brGWLpZt/ +MNsrPpGta9T3fKjW2eewvNS1uu5pTaOQfx2o74Y/PTDlPd//qTwI488kg1126DH1zp+sDKQ16oL 04WAfYqpAlBv0mpiJNpRqemSdjKqvLsSuOvMpOZHOybN3yQHsmIHTpPszlWrsqHZzd+0rq235LIr 1FVoh1mnM6qQDs7UsY0dSCoY1s5XV1m186171jzGzsTXYXmj+fHbqW9+q15zJ9GmP/85G5phAcZ7 772Xvo6zYZQ3Xw4s8JA2t7X5OhnaZdNQjzdRVCf7W21E5bLoKnSbmm4n7777bjY0lwVso9BkX6dA XXWLgkMdV9U9WTMs4XL4k8KjKg+DGvT42ndgqX2ALlhhuhGwTzld1dF9Ouq5MuwZVL1kdiFoVw/Q FqSreZzvcdPSJLErhqPc2Y+admZ2RdTfw+2vbBQ1fVNAE5aBWPronnsOfGZazey+cOihaZO0sBdo NVnLC6J0z3RsnsK0n2tuXZW/N33p176WDW3Ny7busxylWN7EUniFywxypb9Lmpa3PCoHKg+iwMOu 1vttbZC+DsQ/Mk9P9cB01OPeoHWyyvUZZ5yRvZuhMj+qQKXpdvKZXnAfW04lLeughrWvu+Lyy9NA XbQvVuse67ndkp04bItORvrp56Wie8fr1n/zaZDj683vvjvrnvxLli8fqKUVxh8BO1KqWNQkTcGD KhbRGUEfDMwHVVB2dls7j2OOPbbWY6r8wWPZc5iHpc48aGdkZ7kn/QqNPRpHy2v361qHR9qxxe5H syC/7n2WbdDBkDqa+tznP98/a64ma/6AzjfXK7u3exCxEx46sLXm8OF9lm3zB9GDtGDwZbzpyUE7 qLTmg8Pgr96P6iRmlfJW1YMPPpgNJelVH/HbWuxA3wLNKtvarrvumg0VX23vwsF2033CpNfjdlK8 bouftupkNS23+suOQUSPxxpVuWmynQzLsPd1X/ziF9NXbedpZ5nf/e5Qrl6/8Pzz2VDzYzDr70VG 0UdG25oeX+sYyI9//fXXj9UJC7SLgB1zqGKxncUwOy2rwnei4ivtqnznWL6Dq5hhnb3082DPx87j D8bLOkQad3p2v1ETROW/HTTmder06quvpq/aec1XEzEd1KiHfuPvidV3dsCrToOGuXP1JzzUD4D1 bqwDsKIO3KoqOrg64vDDs6FegLZ+fTZU38aNG7OhpP/88rr8CYOwPwQv1vtzVc+5DuHK5rPteqSo vFWlk5wWgKsOqrKtbdiwIX218lXEThrpP2In2ozvgMrTdjKqfU3TfcK41+NFJxD9+rX1XlUbdbJ+ Z1d7dXJKxyD2VAcF8RdffHE6PGxNtpNhGfa+zk6O6ITSMJuZ28lGKdve8vjboPy+J9RGR53DVvf4 WuP7E7a6Mo/pRMA+pVSx6T6a2MGlDp523nnn7F137JIzT7q3M4/OiFsApR1vrELX8moaKyNBThtX ADUP/iqgmqLFaPqnZ48K0kGDD2gnkQ4SfBNE3+N5Xmc9vpn8P37jG4UBsb4bJHhSmdA9frH/KDrL bwd2OtAq27lq/oqWoYgvH0ceeWQ/aGrrvs/TTjstur2onC7OOhYb9OSAfmsHyDoQK9vGYt/7nodP PfXUaH5qXap5bVP+/ta8+dS6fGrdurRjJa9qq4um5a0q6yhNdZCfx7xtbdaj9M44I7ecar7t4F+d I4X8FTaV05Dy8oH77+9PY9ia7hPGvR5XHatlCmlZtd2YoluRYgatk/WZrqKL8stOTunxiLaedA9v Wd0Q06TFU93tZFhGta/LCxq1XdjJijxVjo90ddm2m7ztzYtNx+9jtO+JjaPpqqPOLtC8tHl8rW3C gnztx/LqHkw2AvYppas0qjx1IKqDRJ3BVVJFo/skFWyIf4TUfNDVGttpW0VlOy7NryrFsgPxm2++ ORtK0gpdBy26oqDfa3o6WMybhr8CuPzii/u/0zTq7CD9vW8KhDTfymvLd60DBXeW73qO7zDPeneF b4KogzLRzl07+RiVBwvydUClnld9+VXSOr1v7dr0u8sH2LHpQEZXfVQ+NE0/fd1PZsIDOX+gqXKl nr7975XU87fKgDr8aXr1SOXDzrzrYNzKTt0D7iLaXjSfVu41376cKkAbpJzqt/5xTspLv30qaTvR Z8rH2EGzrorZwYzKhOov27b0qt9pPdiJgSZUHnU/uWg+lQe+3GlYdan+P6RltPKg9aQ8tHnTsGla 3qq61t1KZPVd2bZmB9oKpsNtTfPv61+tg9gz6FfffXc/77X82jZt/Wp6Wh5Nf5D1U1fTfcK41+NW H/ntQ8tq5VbrW+u9jkHrZNV/drLG55de/fPhtf+tq+q259XdToZl2Ps623co7/3xjF71vkrwW/X4 yK9H26f47Ua/07LphKfqA33maT2G9a/VkfqtpmfzO8p6JE/bx9da/rPPPru/bKp7wjzCdNhCGn7q 7Ry2vLZpU5p6G1p0HJ+qjt+rqPrj1fm+V5lueWnjxv53sdSrdGf9pmqy/9Rr7HslLZP9j5Y1No6l XoXcHzeWepV8mjSc95+9inLO73xSXmic8HcLFizY0jvAif4mXC/2edE8lOV53nxYylufYbJxitZB Xiore1WmXWf9hnlStPxKWie9g5RZv8lLGi/8fdVtq6zcKeXN6zHHHNMvk2Wpd+Ax5/dV13M4jyqr sfGqJp83Gi4qr0X1Q9X5t+T/tyhpfmK/V37nbadKWheq8+x9rExWKRdaZhsnljQPmpfwd1rHsfH9 NjRIeauawjJZZVvz6zIvaRyNG5uGUtmyKe99/semUbdMlSUtu00vlvLqYn1WtF0o5f3Wko3n13+Y yvJDqaye9d+r7BbVSfoubx2W5X3TOlnbin2elxd+uuEy+jzK22arbHthqrudVE1l6ytMw9zXlR0D 6jv/3/63ljR/VY+PVAeUbTeWYnWo/suXwzBp2vpPG6do/ealKuXJJxs3/K+mx9dl5cPXo5p+3vZK mszEFfYRsQ5rdIasSidNfvzn3f2TIesMKe+son1vV6CMzharMyPdJ+a/03R0Vle9eRb11FnE/rPo MUs+D3yTyRhdQVNzaZ0R9sups97q2VS9tL799tvpZ3n/aY9L0jTsjLto2XXmVh3MxHqf1pnNpUuX zvpvy6PweaD2fV4nQ5q+/kf/F66PsvkweeszZPNStA7ylJW9suUUv359Z00xvhmt1k1ZE2utE3U+ GFufonKhz1U2NF6o6ralcqf7lcP/0LA+03d560rNZ1UuNQ8qK5ZnomHNo9a3lkH3qIWqrmfNo5+3 Nu+zVNNQlUdf9kXLoyc1FNUPVeffnHXWWWl+5m0b+k91vqM6K0b5fdTRR6f1mc8P/dbqCNV5thyx MlmlXGiZY+tU61Pzp3nQvIS0jvU7v2wa9ldYBilvVa1duzYbmlnOKtuaeqzPK8f6TN9pHI2bx+pw Pw29arn0uda/z/+YumWqjPKyyT5Bnw1aj9syFtWhZfkhderZN958M+1cLLaNqOxqG8lbh2V537RO Xpp1uqVlvDBSD4qew255EN6/XGWbrbLthepuJ1XVOe6RYe7r7BhQ5TUsDyoj+s767rD8D2n+qh4f qQ7QNFXWNN+e/l+f6X9Vz8XqUP2X1UV+Xeq3Nr9qlWBl1V7rqFKePFvmcDtuenxdVj6Uh74Tun/6 5jfTYUyPaCRPIpFIpO4nf9VXZ/Zj41RNda8wkMYr+VYGRS0kSJORyq7YkeKJ7YREInUtcYUdAMbU ggULZt1DPOr7LDFeli3b2hu476wPwFZsJwC6hoAdAMaUf3yUPeYNyOMfv6bmlQDmYjsB0DUE7AAw po519y36R48BoXOXLev3xq1H/wGYi+0EQBcRsAPAGDrmmGP6j2NSRzY0h0cR/wx0/3gyAFuxnQDo IgJ2ABhDh37hC+mrmm3659kPom4vuRgfe+21V/qq3phjvTBj8tTtlRxsJwC6aZteUu9zAAAAAACg Q7jCDgAAAABABxGwAwAAAADQQQTsAAAAAAB0EAE7AAAAAAAdRMAOAAAAAEAHEbADAAAAANBBBOwA AAAAAHQQATsAAAAAAB1EwA4AAAAAQAcRsAMAAAAA0EEE7AAAAAAAdBABOwAAAAAAHUTADgAAAABA BxGwAwAAAADQQQTsAAAAAAB0EAE7AAAAAAAdRMAOAAAAAEAHEbADAAAAANBBBOwAAAAAAHQQATsA AAAAAB1EwA4AAAAAQAcRsAMAAAAA0EEE7AAAAAAAdBABOwAAAAAAHUTADgAAAABABxGwAwAAAADQ QQTsAAAAAAB0EAE7AAAAAAAdRMAOAAAAAEAHEbADAAAAANBBBOwAAAAAAHQQATsAAAAAAB1EwA4A AAAAQAcRsAMAAAAA0EEE7AAAAAAAdBABOwAAAAAAHUTADgAAAABABxGwAwAAAADQQQTsAAAAAAB0 EAE7AAAAAAAdRMAOAAAAAEAHEbADAAAAANBBBOwAAAAAAHQQATsAAAAAAB1EwA4AAAAAQAcRsAMA AAAA0EEE7AAAAAAAdBABOwAAAAAAHUTADgAAAABABxGwAwAAAADQQQTsAAAAAAB0EAE7AAAAAAAd RMAOAAAAAEAHEbADAAAAANBBBOwAAAAAAHQQATsAAAAAAB1EwA4AAAAAQAcRsAMAAAAA0EEE7AAA AAAAdBABOwAAAAAAHUTADgAT6pBDDkm2bNkyK7355pvZt922YcOG5N57783eYRKo/C1btiwdHsb6 1bT1H9hq3bp1bEcAMOaGFrD7A8RwZ3HdddfN+l4HlcZ2uJZs5260k7fvNFwkPFjV/5rwO3ZoACaJ 6s5f/vKXyec+97lkm2226acnnngirfN8vevFgnwd9LdF0xu0vq0SmPl9xajrd5s/238p/5rmYdE+ z/7Hkv2fFO3/RPNj37V5Esfmqc08t2OGvDJb1SDrAQCAGO1DbX8a7mOKYt66dNTTaurN7JbeTjsd 7s1Yb/629N/rVfS53vd26lt6C9r/rR/uLWQ6rr3XdHsHLP33Gle/t/dhEk1Dw+H/+nkMvyORSKRx T6ofVadZHSxWv6peVB0Y/kbJxp/v+lB1fV79bnV27Dsl/c7vK/zwfCTldV5+FyWtJ58Hfp9n68n2 Y+H+Usts6zDcx2kafl+rcZvMXyxpOpqen74lsfnVOHnrt2kqKxdN18M4Jy1v2/lMIpFIpJmk+tVi TSXJiz3DfW/NFP2w1aSZs5nXzIY7TLGduE92QGILqun48TTNvAXXeOF3RQcIEpsHEolEGrekOlP1 nYbD+tfquby6M6x3fdJvPfvcfqPpi+p4+8zY9Pz82HvP5tvqa/ve5le/9Wx8n8oCM8/Pi5KmZ3y+ +enpc5ufomXXq5+e2G/9/8b2V7Hkl0u/D5c9nK5PYutevwv/X+z9IEnzoOXWq/2fJfHzoDzz3yvF 8jOcP817SOPYeP57W87Yegg/rzo/+lyvJrYejM9n/182HSWNo+/s+zVr1qSv+m8bR/9vv7HlNH48 m1/RfOg3seUikUgkUvtJ9bjVub7etiS2H6yTRnIP+0477ZRs3LgxHd5nn32S119/PR02b731VrLn nntm77Y68MAD09fHH388bUKg6TzzzDPpZ6Jp6rOYww47LHn77bezdzP0P7vuumv2bqvezjL97tpr r80+AYDxpbpTdZrVm+ecc076+fHHHz9QPbd8+fJ+0/qnnnpqTtMv1e/6btGiRcnNN9+cXH/99f3x VY+H9HvV4/pe42qe99prr+zbJDnuuOOS//k//2f6vfR2fumynHvuuel7fe7HN3fccUfymc98Jtos uxfEJD/96U/T3+p2gbPPPrvfRM2WR98pnXrqqen7Kvyye5o/5ZWSvtf867aEI488MhsjSf/H9pFF tC5t//nJT34yzS9P+7yPfOQj2butbPls/6n9rf8/+9zGa6p3EJK+al1r+nXyL5SXn5pHrTO71UN5 oLLjy7XyRt/pc40rsfWgfb/ovZK2jzx+flSulIf2O7Gyplcr00q27YVlS7+3/xe9f/7559PvlixZ kk7jggsuyL5NkoMPPjgt11r+a665Jt0GNK6W8f/8n/+TjZWk252V7xUrVqTbAQBgNHbcccfkT3/6 UzpcJ+YtM/SA3XZeTQ4StaPVjmdYtmyZuZ9A/6ODQgCYFnknO43uf7c60oKRnXfeOX0V7YTCaZxx xhnZ0MxOSYFTEf3+t7/9bTp81113zZme6n8L9BXkxk64xmh/o4BOAb+ffwU7+g8LzCywPOmkk9L3 2okqADJ+ecv4ZS9zxRVXpP9lAbKGFYwVUTCs8YqCyjz/+q//mgaqsZMmbVKArvUkdtKkqbz8tJNR tixaf+FJCgvyLVjOOxGh31Y9cPLzo4Mwv74efPDB9DPRgVpsmvrMly3lk98+tEx+3fppWrlVuVZZ 9cdUWkZ9p3GU9D8qX6JxtN4BAMNnJ2Ft39OmoQbsOsDQAVPsCkgZO8CqenCywXXME171yWNnunVg p4NTf7YbAMaZDuIV1CgQsLpNr6qXdWCvz4v4zuqsHla9bPWs6vYiCpoUPBTVyT6oVyBSNk91aNmt fte8atmt1ZYtg5IPrpRnvhXXsPgTBXZVuuyktl1VrUvLrWUMr1RX4fMpTLEgWAH6I488kg7b8rS9 X9X6sQBVtGx2NaMuzaNOCtkyVaUrKDrRb7+zq/iiAzWtW32u1hxG86x1aL8p237uuuuudNm0nLrS boG3Tk7YdmUpNOwTMwCA2VRXD/MC8NACdh2EaOekgyVPB2ThVRLtyLRzMjooVPMvH+jbDsgOuEQ7 Le0YRePawaUOTLQD107V0//Y1RxP09bOsOxqEACMAwUiqv+0A1GzWAsudAVU3ykAsCuhVdkJWKtn q7R+0hVqjau6Oi9wU5CneRvWjs7qdwU6FozbMliys+HaP/l9zDDpCqqaxev2LduP5VH+hM2+Yy0c tM4tYBblufI1bCmg5dQ6MeFVaxPmk0/huLZ+fVAqw9qvWgsQ5d0gVzN0MkrLo/KsE/9V6NYDrQ+f H/54Rccg+kzzZierlL/WjN1S0UkU5a9+r5M6/oq+jm30uZ+OUrg+AACjoWMt7ZNUx/u6uErMW9VQ AnYfrIc7EWsmZ2fHFZz7AwUL1mNNEXXQ5c9k6+BT93zFWDMxO4jQPOkAxTLJn/kWzVMsmAeAcaS6 VjsQBal2UK96VXWsAu+6TatVf6quNqqnB6Vp+iv5VYOOsnuuVb/771S/K9DR9LUMeScPFAj5fYwF cPqtpmH8OFXEgmvti7T8Whe+eXXIgvUwKLVm9XaFXsuk//BXtjWfyteQTtb4+8s1npZ9EDr5oH20 rUslzbfPtzYogPX/U6flQGw9NKHjDt8HQRXK37r39Oukjn6j9Wzr1cpNrOxb+dY2LioDPv/13k6k AAAG54N1f1JdymLeutLe59pM1tOpp8/s+94MZ5/O8L+N0fj2vXo9NeuCnvfC1DuQycacoff2XTgP /j9IJBJpElJvJ5HVcFv5ujiW7Dd6Db/zdbvqX5tW7Dee/0/V4b3AIR0O62ix8fQbXy9r2Nf5Ni9+ 2pbC6Yb1e8jPt9/H2Hwq2f+JPtd4+jy27OFn9l7Cadp0YincTxn7XtPy/Dz45TCx/JNYHtZN4v/f kl/fYvth/WdsvxvmnZKtT3vv511sOuF4SmLTsmmL5kn54cXmPzY/SuFvbR7CefO/Cb+zfNFrrBzY f/v1phSWb/9bv4yWxzZvVl5sXBKJRCINlsJ9gfg6WfWv539bJ+nUuwYAABgp7bv8Weneji99bXK/ 9TiatuVtQ+/gJ20ibk3QewFqenUj1qIPAIBJMJLHugEA4CnQEt/Jm5orh49AmWRqKlfUHB5z6X5A f2uG9TlAsA4AmFRcYQcAzAtdLfW9Zes+3yZPFRlHy7K+XnQfNuqZaVW4VezeQQAAJgUBOwAAAAAA HUSTeAAAAAAAOoiAHQAAAACADiJgBwAAAACggwjYAQAAAADoIAJ2AAAAAAA6iIAdAAAAAIAOImAH AAAAAKCDCNgBAAAAAOggAnYAAAAAADqIgB0AAAAAgA4iYAcAAAAAoHOS5P8DgNZH3evWNPQAAAAA SUVORK5CYII= --nextPart1784631.GPElSuburT-- From nobody Mon Jun 29 14:38:33 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183D23A0D6D for ; Mon, 29 Jun 2020 14:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 KoXcXEmBZMqL for ; Mon, 29 Jun 2020 14:38:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::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 B309D3A0D66 for ; Mon, 29 Jun 2020 14:38:30 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 05TLcRZh017535 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 29 Jun 2020 16:38:28 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1593466709; bh=kq9p5Pqulwy0oGAKht7KebeUbWEbfm2ijNiECRlgnp8=; h=Subject:To:References:From:Date:In-Reply-To; b=ZXfxbebvqHkLG7P+yJcejEiWbR3CMMVLA1p+E/7fD+KOt3swizrKGCgOioXqxWiPz ZIvNFejHFgs13BNej78T7MQTfDoxiF/NISXM3lWDCTNWjahijrTzlcV54O2njOge+F XKP8kFGfFkXo1ADpbTm+XblIMJd5cmSwADxnfaaM= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Paul Vixie , ADD Mailing list References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> <26559974.PdTMpzyJZD@linux-9daj> From: Adam Roach Message-ID: Date: Mon, 29 Jun 2020 16:38:20 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <26559974.PdTMpzyJZD@linux-9daj> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Add] DNS and middleboxes (was Re: Comparative DoH Discovery DNS RR Types) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 21:38:32 -0000 On 6/29/2020 4:01 PM, Paul Vixie wrote: > if on the other hand we're going to continue to evolve DNS in ways that > include adding new RR types, and all the initiators who are stuck behind > dumbass middleboxes who reject or butcher unknown RR types are going to fail > hard and be excluded from the new applications and protocols in order to put > more pressure on middlebox users/makers/distributors, we should say that. Perhaps it would be worthwhile for the DNS community to consider putting together concrete guidance for middleboxes, similar to what https://datatracker.ietf.org/wg/straw/about/ did for SIP. I suggest follow-ups on this topic are probably more on-charter for DNSOP than ADD. /a From nobody Mon Jun 29 14:40:31 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D583A0D7F for ; Mon, 29 Jun 2020 14:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 P2rDt5KgYm6g for ; Mon, 29 Jun 2020 14:40:28 -0700 (PDT) Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (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 DBF943A0D7E for ; Mon, 29 Jun 2020 14:40:27 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id k7so8720166vso.2 for ; Mon, 29 Jun 2020 14:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=95U2/rN/Xdhb/BUY7nkqVeIOP9mRM6UI+o7chR8Smdo=; b=T30WXi7R8AHJNKFNgh82enImPkNMiIY8hpGHy+ZSUWZQWBy0X1zQeKY9JnmSfyRi8R 8KoMWkkVhCY6cUFLBNDwkwAV7DaQAD4pLsVnvLQnl2qk57rYzCwykIEFNwhJZSRsm22D 3JUf7KPSgPtxU/GrQ9JFxPze8+H4rA88AOhMK6a/VCxbKfauKj7AvnzUrJjW5dahQ9wK 0YgHXvINMgYDl+Jth61R7VDFuECcCpru6xsuTKaYLFeTaSTw6CiGYNqjypcA1z0nRa03 +RV2lLoI/7+Q2wpsDsIgE/oFXh48RNQJh6B1XC61DzS+9Ns8rNiz69EB8dOUYMb7xPxw wXMA== 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:to:cc; bh=95U2/rN/Xdhb/BUY7nkqVeIOP9mRM6UI+o7chR8Smdo=; b=kzZ7qIOXxytEo6a7UEAaABg1eBAod5Vtue+0OGnih/+BPsE5Dn6J058ymy+C/UxjgW XGmaGofeQsBNxdvdcj4IzFewrc9mWjOZz3LfD4t3qZcsEbTUAaCBZfrj8caYN3cWa404 jd8Lt9kMKP+8MV8y5ePJKx1VP0ESu+7uKEtzvDTGPoaH32OCl0379QycP9dp88etRhr8 /DGFKoRNCjugdDbOK9SwMpDnzKQNlB7yGOjfRwv6RYJBW6di26p0g2ItD96+nzT5eMCG 2Jix0WqclH9t8X1r0sJU73PQOR/nZiUgsknfdUL7nCWQsrsLfyaP8pcDy4R44V16zvvr TQQQ== X-Gm-Message-State: AOAM532STp6Rnjwc6IB9kHCKYoQqQN/dfaHLq1D95isnd3LMkLkNaV4N HNqTO+H6jlydURNk8+k+apAq5m9yTe5cHxVW8gRThw== X-Google-Smtp-Source: ABdhPJwt09xnqmEqEg1WNMEAjTi3Hh6BZ0xeWhqdEDQcN0rDUoU3dk2xLRqePm6I/EjPPEfGmR8gACbdZ79DldFJwiE= X-Received: by 2002:a67:6546:: with SMTP id z67mr5377184vsb.169.1593466826861; Mon, 29 Jun 2020 14:40:26 -0700 (PDT) MIME-Version: 1.0 References: <14119.1593367594@localhost> <3615321.ADK9YsXCiF@linux-9daj> In-Reply-To: <3615321.ADK9YsXCiF@linux-9daj> From: Daniel Migault Date: Mon, 29 Jun 2020 17:40:16 -0400 Message-ID: To: Paul Vixie Cc: Michael Richardson , ADD Mailing list , John R Levine Content-Type: multipart/alternative; boundary="0000000000002d312805a93fe8ef" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 21:40:30 -0000 --0000000000002d312805a93fe8ef Content-Type: text/plain; charset="UTF-8" Hi, I believe the proposal presents some similarities to draft-mglt-drdp [1] that is using the DNS to proceed to the discovery. I see drdp as more generic, and would be happy to improve it. I would be happy to understand why HTTP is a better stack to perform the discover as opposed to DNS. I think that DNS is better as it is the common protocol to DoT DoH and DNS, but I might be missing something. Here are my comments regarding your proposal: I believe that CNAME is to restrictive and would not make possible for example to have multiple resolvers. I believe the ISP should be able to provide multiple resolvers. Some resolver may implement DoH, DoT in combination with multiple additional services. So in short CNAME would limit the discover of one or no resolvers. The limitation seems for both the application and the ISP as it does not provide the ability for an application to chose the service and force the ISP to make that choice. On the other hand, the ISP can hardly to made a choice that fits any application or the end user. The ISP cannot propose different services for different applications. CNAME does not provide useful necessary parameters that may also be useful for a DoH resolver DRDP lists among others: alpn, ensiconfig, uri template, user display, auth_domain, filtering, ip_subnet, dnssec, .... My understanding is that BCP 17 saw SRV as a long term solution for CNAME which is now superseded by HTTPSVC/SVCB. I see SRV as very common in home networks with service discovery. I believe that using a generic is problematic as is prevents its resoltion to be secured with DNSSEC. In DRDP [1], the list of resolvers is associated to a resolving domain. In the case of an ISP the resolving domain is derive with a reverse resolution from the IP address announced by the ISP . Note that other means may be provided. With the resolving domain - in your case resolver.example, the application will retrieve the resolvers associated to the resolving domain. In your case you are exclusively focused on DoH server, so your application will them perform _443_dns.example.com. SVCB. Note that an early version of DRDP was using SRV/TXT instead of SVCB. Yours, Daniel [1] https://github.com/mglt/draft-mglt-abcd-dofoo-discovery/blob/master/draft-mglt-add-rdp.mkd On Sun, Jun 28, 2020 at 3:23 PM Paul Vixie wrote: > On Sunday, 28 June 2020 18:29:22 UTC John R Levine wrote: > > On Sun, 28 Jun 2020, Michael Richardson wrote: > > > > Beyond that I gather there is still concern about SOHO routers > with > > > > poorly implemented DNS forwarders that only handle some kinds of > > > > queries. > > > > > > I believe that the majority of devices on the market are now based upon > > > versions of openwrt which, even if 10 years out of date, now have only > 15 > > > year old DNS forwarding code. And that's new enough. > > > > It's not what's on sale now, it's what's installed. People tend to keep > > what they have unless it breaks in ways that are obvious to them. > > as we learned with EDNS, we should have broken more stuff sooner. being > liberal in what we accept and conservative in what we generate has not > scaled > and won't. > > -- > Paul > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > -- Daniel Migault Ericsson --0000000000002d312805a93fe8ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I bel= ieve the proposal presents some
similarities to draft-mglt-drdp [1] that= is
using the DNS to proceed to the
discovery. I see drdp as more gen= eric,
and would be happy to improve it.

I would be happy to unde= rstand why HTTP
is a better stack to perform the
discover as opposed = to DNS. I think that
DNS is better as it is the common
protocol to Do= T DoH and DNS, but I might
be missing something. =C2=A0

Here are = my comments regarding your
proposal:

I believe that CNAME is to r= estrictive
and would not make possible for example
to have multiple r= esolvers. I believe
the ISP should be able to provide
multiple resolv= ers. Some resolver may
implement DoH, DoT in combination with
multipl= e additional services. So in
short CNAME would limit the discover of
= one or no resolvers.=C2=A0 The limitation
seems for both the application= and the
ISP as it does not provide the ability
for an application to= chose the service
and force the ISP to make that choice.
On the othe= r hand, the ISP can hardly to
made a choice that fits any applicationor the end user. The ISP cannot propose
different services for differen= t
applications. =C2=A0 =C2=A0

CNAME does not provide useful neces= sary
parameters that may also be useful for a
DoH resolver DRDP lists= among others:
alpn, ensiconfig, uri template, user
display, auth_dom= ain, filtering,
ip_subnet, dnssec, ....

My understanding is that= BCP 17 saw SRV
as a long term solution for CNAME which
is now supers= eded by HTTPSVC/SVCB. I see
SRV as very common in home networks with
= service discovery. =C2=A0

I believe that using a generic is
prob= lematic as is prevents its resoltion
to be secured with DNSSEC.

I= n DRDP [1], the list of resolvers is
associated to a resolving domain. I= n the
case of an ISP the resolving domain is
derive with a reverse re= solution from
the IP address announced by the ISP .
Note that other m= eans may be provided.
With the resolving domain - in your case
resolv= er.example, the application will
retrieve the resolvers associated to th= e
resolving domain.=C2=A0 In your case you are
exclusively focused on= DoH server, so
your application will them perform
_443_dns.example.com. SVCB. =C2=A0

Note tha= t an early version of DRDP was
using SRV/TXT instead of SVCB. =C2=A0
=
Yours,=C2=A0
Daniel

On Sun, Jun 28, 2020 at 3:23 PM Paul Vixie= <paul@redbarn.org> wrote:
On Sunday, 28 June= 2020 18:29:22 UTC John R Levine wrote:
> On Sun, 28 Jun 2020, Michael Richardson wrote:
> >=C2=A0 =C2=A0 > Beyond that I gather there is still concern abo= ut SOHO routers with
> >=C2=A0 =C2=A0 > poorly implemented DNS forwarders that only han= dle some kinds of
> >=C2=A0 =C2=A0 > queries.
> >
> > I believe that the majority of devices on the market are now base= d upon
> > versions of openwrt which, even if 10 years out of date, now have= only 15
> > year old DNS forwarding code.=C2=A0 And that's new enough. >
> It's not what's on sale now, it's what's installed.=C2= =A0 People tend to keep
> what they have unless it breaks in ways that are obvious to them.

as we learned with EDNS, we should have broken more stuff sooner. being liberal in what we accept and conservative in what we generate has not scal= ed
and won't.

--
Paul


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add


--
Daniel Migault
Ericsson
--0000000000002d312805a93fe8ef-- From nobody Mon Jun 29 15:22:35 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC243A0D88 for ; Mon, 29 Jun 2020 15:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=apple.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 QuM6iyxY0SpI for ; Mon, 29 Jun 2020 15:22:31 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 DDB873A0D83 for ; Mon, 29 Jun 2020 15:22:26 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 05TMMCu9003809; Mon, 29 Jun 2020 15:22:25 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=bx2xhrB1iEEctond4pzcLITEL7CTtuMp4xTsSx/plJk=; b=GMGD4Y/4edvfMSKEy4I9gU1bqdrVRIpE2jSVu7U3WesnWBYyr0uU8OuOjmb7bc2+zVBv hmt3NVx8HISk6LoUlVoq/Sq/L6iZJjrNVzaqRaaRfdWUNoHc70wUu/NQG94HzCK0uRIj 3pEao8AnekyEhLc8IDP73ubnzGjH3BvrDIBI1Re0N4OmiIwxKSdCJXQtNNTu1pAHOFxV yDGSQ1rjTibtIUInIPP33Trwe2WhDpsRePzZ6K4JSSlyS0wZEf8st6zRBwf5OtQb6Asl 9QC7lapLRFXHsi7EGhgbHCCMX4jxvqE/Mj7feAWUaMPLDX9hoctmck3hXm142dc4Xaoy Uw== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by nwk-aaemail-lapp02.apple.com with ESMTP id 31x2ph38d9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 29 Jun 2020 15:22:25 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QCP009WNKTDCVI0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Mon, 29 Jun 2020 15:22:25 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QCP00U00KRLDU00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Mon, 29 Jun 2020 15:22:25 -0700 (PDT) X-Va-A: X-Va-T-CD: 7e7bcd67fbc9a0a620034c2bd87f55e5 X-Va-E-CD: bb95b336d3f7616b03bf913e46b62926 X-Va-R-CD: 24e8aabca2796a6e72c0139df6f009e8 X-Va-CD: 0 X-Va-ID: 11e068a0-ad9d-4a8a-93bc-b93194b79d27 X-V-A: X-V-T-CD: 7e7bcd67fbc9a0a620034c2bd87f55e5 X-V-E-CD: bb95b336d3f7616b03bf913e46b62926 X-V-R-CD: 24e8aabca2796a6e72c0139df6f009e8 X-V-CD: 0 X-V-ID: 466b375b-27c1-4dc9-9189-4c281cc1d27b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-29_21:2020-06-29, 2020-06-29 signatures=0 Received: from [17.232.189.109] (unknown [17.232.189.109]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QCP00H8RKTCAM00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Mon, 29 Jun 2020 15:22:25 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) From: Tommy Pauly In-reply-to: <26559974.PdTMpzyJZD@linux-9daj> Date: Mon, 29 Jun 2020 15:22:23 -0700 Cc: ADD Mailing list Content-transfer-encoding: quoted-printable Message-id: References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> <26559974.PdTMpzyJZD@linux-9daj> To: Paul Vixie X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-29_21:2020-06-29, 2020-06-29 signatures=0 Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 22:22:33 -0000 > On Jun 29, 2020, at 2:01 PM, Paul Vixie wrote: >=20 > On Monday, 29 June 2020 15:36:42 UTC Livingood, Jason wrote: >> Just noting far we have a variety of suggestions on CNAME, URI, TXT, = RESINFO >> and HTTPSSVC (though I don=E2=80=99t think all have I-Ds as yet) - = always nice to >> see the ideas flowing. :-) As a practical person that in IETF land is >> considered an implementer, I naturally feel inclined towards RR types = that >> already exist as this enables something to be rapidly deployed. >=20 > the community apparently lacks coherence on the importance of rapid = deployment=20 > as compared to the importance of technical excellence. if we're not = going to=20 > add any more new RR types because they take ten years to become usable = (see=20 > the SPF RR vs. the later _spf TXT RR), we should say that, and close = the RR=20 > type registry, so as to avoid confusing newcomers. >=20 > if on the other hand we're going to continue to evolve DNS in ways = that=20 > include adding new RR types, and all the initiators who are stuck = behind=20 > dumbass middleboxes who reject or butcher unknown RR types are going = to fail=20 > hard and be excluded from the new applications and protocols in order = to put=20 > more pressure on middlebox users/makers/distributors, we should say = that. Agreed on both points. To that end, one of the reasons I like using HTTPS RR (aka HTTPSSVC) for = the ADD information is that this RR type, while new, is tied directly to = the deployment of TLS Encrypted Client Hello (ECH). Improving the = privacy of names on a network requires, ultimately, both encrypted DNS = *and* encrypted SNIs in the client hello. Of course, a client could only expect to do ECH when it already has = encrypted DNS set up, but I=E2=80=99d prefer that the architecture not = design for that case. We should have a system that allows to discover = local encrypted resolver support, and even do ECH to hosts private to a = local-network. There will indeed be networks or middle boxes that = butcher this, but they also could be butchering other aspects that would = stop the local network from upgrading from Do53 to DoT/DoH. Tommy >=20 > either way, nothing is temporary. whatever we use for resolver = discovery will=20 > be present as a data pattern and code path in all future software. = improved=20 > signal patterns and associated logic will live alongside the = unimproved ones,=20 > raising the bar for both short-term expedients and later improvement = to be=20 > "worthy of its coexistence cost". for clarity, that's a _very_ high = bar. >=20 >> As all of these become documented a discussed a bit further - or even = tested >> experimentally - my humble suggestion is that it may be helpful for = the WG >> to develop a grid of all the options with their associated pros & = cons. >=20 > such grid would be well informed by the attached graphic. >=20 > --=20 > Paul--=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Mon Jun 29 16:16:09 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87EE3A0E19 for ; Mon, 29 Jun 2020 16:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lduTQWJt1cqm for ; Mon, 29 Jun 2020 16:16:00 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 C14653A0E18 for ; Mon, 29 Jun 2020 16:15:59 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id c21so10210248lfb.3 for ; Mon, 29 Jun 2020 16:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dez+s9Lf4oGn/cajkfFD7edkyecUJt5E2M+ye+5S/Is=; b=yxyxI7MsXmfOX0U1svBi948v3KpUXsUo1a9bDkFoqHoxh/imYV7vtWNnFz6x06sfv4 fHJ0xVnDWONNKRzSkvrmu1fNyWMXl2E2OyU7S3Rj3yYLBNy+PEGGbhWtAYDUrKuX3MYW BYRZ3l3OYZHjwgys4Xlat05fHtbAgLVT3OEqtxN0iGLg9N97Aaa2C3lFKgrJCZjR421f zb7bY8S1BBO8LNWSyEjYAWDveuk6PPjUQ9PS8sHFr+FIek90MlIOBET8zYaST8Zuf3P6 V8OQd+6chPjs+/BMpcVbAD1v77h7ShM4xdXWKA+UH6PqkUR4O4zxKo0iAlpqHWlPTXaa D2Nw== 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:to:cc; bh=Dez+s9Lf4oGn/cajkfFD7edkyecUJt5E2M+ye+5S/Is=; b=G8ER3GpQ7604qxmmfznajDLGpkR4vBy1QZ0ukIfflSBAwJE/TL5QYh3hExml/LAlBZ EgaG9w6xZ8a+xbKovxPJdVFPyq52oQzrTSsaXLV23DvTWgBlnlqxDwqXBeRyj+LiRAIH iGMykUPRqB8XBtNwV5+HGRWwutnUa3a2rVQXDNecpvFzzO3v0HaiQU0xFFqE3iH1F4Vu Jh46jGgJAmj0E5e3LU02Qfv/B0tl9pHtjU/uBbIcYuDzYJ3b1V/F4OI7M3C/Z27B33q1 ORglMqXdcunxE5LKig9X7Uzw3LoLILsmksJ7SD770Tc7FGnH0Il5phWvXpF2B5K/k1ft L1zQ== X-Gm-Message-State: AOAM532JVMcvTcTO+oFg/ladV7lC9Yx7+xNRbbIIqV+c+J0SdVwQ/o3U fk6K+7ySW4gCwX5rFI2vw0AELiA3VRHKXDIcZt+9VQ== X-Google-Smtp-Source: ABdhPJxtRMvcGUykAmZNeMw0fI/ueGXMQsYmJRLEGL+tZYz8PtCZ+ZZlftZjO4ATQuX4CmO6TG5JZsvNtc8ejWcldzc= X-Received: by 2002:a19:ca48:: with SMTP id h8mr10429533lfj.161.1593472557519; Mon, 29 Jun 2020 16:15:57 -0700 (PDT) MIME-Version: 1.0 References: <14119.1593367594@localhost> <3615321.ADK9YsXCiF@linux-9daj> In-Reply-To: From: Eric Rescorla Date: Mon, 29 Jun 2020 16:15:21 -0700 Message-ID: To: Daniel Migault Cc: Paul Vixie , Michael Richardson , ADD Mailing list , John R Levine Content-Type: multipart/alternative; boundary="000000000000c0290805a9413dbb" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 23:16:07 -0000 --000000000000c0290805a9413dbb Content-Type: text/plain; charset="UTF-8" On Mon, Jun 29, 2020 at 2:40 PM Daniel Migault wrote: > Hi, > > I believe the proposal presents some > similarities to draft-mglt-drdp [1] that is > using the DNS to proceed to the > discovery. I see drdp as more generic, > and would be happy to improve it. > > I would be happy to understand why HTTP > is a better stack to perform the > discover as opposed to DNS. I think that > DNS is better as it is the common > protocol to DoT DoH and DNS, but I might > be missing something. > I don't quite follow this, as we do not use HTTP. > > I believe that CNAME is to restrictive > and would not make possible for example > to have multiple resolvers > This goes back to use case. In our use case, the multiple resolvers would be supplied by manual configuration of the client. the CNAME is just a lookup key. > > CNAME does not provide useful necessary > parameters that may also be useful for a > DoH resolver DRDP lists among others: > alpn, ensiconfig, uri template, user > display, auth_domain, filtering, > ip_subnet, dnssec, .... > > My understanding is that BCP 17 saw SRV > as a long term solution for CNAME which > is now superseded by HTTPSVC/SVCB. I see > SRV as very common in home networks with > service discovery. > > I believe that using a generic is > problematic as is prevents its resoltion > to be secured with DNSSEC. > As I said earlier, this goes back to threat model. Please describe the thrat model where you think DNSSEC helps. -Ekr > In DRDP [1], the list of resolvers is > associated to a resolving domain. In the > case of an ISP the resolving domain is > derive with a reverse resolution from > the IP address announced by the ISP . > Note that other means may be provided. > With the resolving domain - in your case > resolver.example, the application will > retrieve the resolvers associated to the > resolving domain. In your case you are > exclusively focused on DoH server, so > your application will them perform > _443_dns.example.com. SVCB. > > Note that an early version of DRDP was > using SRV/TXT instead of SVCB. > > Yours, > Daniel > > [1] > https://github.com/mglt/draft-mglt-abcd-dofoo-discovery/blob/master/draft-mglt-add-rdp.mkd > > On Sun, Jun 28, 2020 at 3:23 PM Paul Vixie wrote: > >> On Sunday, 28 June 2020 18:29:22 UTC John R Levine wrote: >> > On Sun, 28 Jun 2020, Michael Richardson wrote: >> > > > Beyond that I gather there is still concern about SOHO routers >> with >> > > > poorly implemented DNS forwarders that only handle some kinds of >> > > > queries. >> > > >> > > I believe that the majority of devices on the market are now based >> upon >> > > versions of openwrt which, even if 10 years out of date, now have >> only 15 >> > > year old DNS forwarding code. And that's new enough. >> > >> > It's not what's on sale now, it's what's installed. People tend to keep >> > what they have unless it breaks in ways that are obvious to them. >> >> as we learned with EDNS, we should have broken more stuff sooner. being >> liberal in what we accept and conservative in what we generate has not >> scaled >> and won't. >> >> -- >> Paul >> >> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > > > -- > Daniel Migault > Ericsson > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000c0290805a9413dbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 29, 2020 at 2:40 PM Danie= l Migault <mglt= .ietf@gmail.com> wrote:
Hi,=C2=A0

I believe the proposal presents some
similarities to draft-mgl= t-drdp [1] that is
using the DNS to proceed to the
discovery. I see d= rdp as more generic,
and would be happy to improve it.

I would b= e happy to understand why HTTP
is a better stack to perform the
disco= ver as opposed to DNS. I think that
DNS is better as it is the commonprotocol to DoT DoH and DNS, but I might
be missing something. =C2=A0

I don't quite follow thi= s, as we do not use HTTP.
=C2=A0

I believe = that CNAME is to restrictive
and would not make possible for example
= to have multiple resolvers

This= goes back to use case. In our use case, the multiple resolvers would be su= pplied by manual configuration of the client. the CNAME is just a lookup ke= y.
=

CNAME does not provide useful necessary
parameters = that may also be useful for a
DoH resolver DRDP lists among others:
a= lpn, ensiconfig, uri template, user
display, auth_domain, filtering,
= ip_subnet, dnssec, ....

My understanding is that BCP 17 saw SRV
= as a long term solution for CNAME which
is now superseded by HTTPSVC/SVC= B. I see
SRV as very common in home networks with
service discovery. = =C2=A0

I believe that using a generic is
problematic as is preve= nts its resoltion
to be secured with DNSSEC.

As I said earlier, this goes back to threat model. Ple= ase describe the thrat model where you think DNSSEC helps.

-Ekr



In DRDP [1], the list of resolvers is
associated to a resolving domain= . In the
case of an ISP the resolving domain is
derive with a reverse= resolution from
the IP address announced by the ISP .
Note that othe= r means may be provided.
With the resolving domain - in your case
res= olver.example, the application will
retrieve the resolvers associated to= the
resolving domain.=C2=A0 In your case you are
exclusively focused= on DoH server, so
your application will them perform
_443_dns.example.com. SVCB. = =C2=A0

Note that an early version of DRDP was
using SRV/TXT inste= ad of SVCB. =C2=A0

Yours,=C2=A0
Daniel

= [1] https://github.com/mglt/d= raft-mglt-abcd-dofoo-discovery/blob/master/draft-mglt-add-rdp.mkd

On= Sun, Jun 28, 2020 at 3:23 PM Paul Vixie <paul@redbarn.org> wrote:
On Sunday, 28 June 2020 18:29:22 UT= C John R Levine wrote:
> On Sun, 28 Jun 2020, Michael Richardson wrote:
> >=C2=A0 =C2=A0 > Beyond that I gather there is still concern abo= ut SOHO routers with
> >=C2=A0 =C2=A0 > poorly implemented DNS forwarders that only han= dle some kinds of
> >=C2=A0 =C2=A0 > queries.
> >
> > I believe that the majority of devices on the market are now base= d upon
> > versions of openwrt which, even if 10 years out of date, now have= only 15
> > year old DNS forwarding code.=C2=A0 And that's new enough. >
> It's not what's on sale now, it's what's installed.=C2= =A0 People tend to keep
> what they have unless it breaks in ways that are obvious to them.

as we learned with EDNS, we should have broken more stuff sooner. being liberal in what we accept and conservative in what we generate has not scal= ed
and won't.

--
Paul


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add


--
Daniel Migault
Ericsson
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000c0290805a9413dbb-- From nobody Mon Jun 29 16:57:57 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E633A0E6B for ; Mon, 29 Jun 2020 16:57:55 -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, SPF_HELO_NONE=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 aZoZFX5h83Mg for ; Mon, 29 Jun 2020 16:57:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A383A0E6D for ; Mon, 29 Jun 2020 16:57:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9908C389A8; Mon, 29 Jun 2020 19:55:04 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5FoXtq4mfVsA; Mon, 29 Jun 2020 19:55:03 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AFE54389A7; Mon, 29 Jun 2020 19:55:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D9C77111E; Mon, 29 Jun 2020 19:57:49 -0400 (EDT) From: Michael Richardson To: Paul Vixie , ADD Mailing list In-Reply-To: <26559974.PdTMpzyJZD@linux-9daj> References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> <26559974.PdTMpzyJZD@linux-9daj> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 23:57:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Vixie wrote: >> Just noting far we have a variety of suggestions on CNAME, URI, TXT,= RESINFO >> and HTTPSSVC (though I don=E2=80=99t think all have I-Ds as yet) - a= lways nice to >> see the ideas flowing. :-) As a practical person that in IETF land is >> considered an implementer, I naturally feel inclined towards RR type= s that >> already exist as this enables something to be rapidly deployed. > the community apparently lacks coherence on the importance of rapid d= eployment > as compared to the importance of technical excellence. if we're not g= oing to > add any more new RR types because they take ten years to become usabl= e (see > the SPF RR vs. the later _spf TXT RR), we should say that, and close = the RR > type registry, so as to avoid confusing newcomers. > if on the other hand we're going to continue to evolve DNS in ways th= at > include adding new RR types, and all the initiators who are stuck beh= ind > dumbass middleboxes who reject or butcher unknown RR types are going = to fail > hard and be excluded from the new applications and protocols in order= to put > more pressure on middlebox users/makers/distributors, we should say t= hat. > either way, nothing is temporary. whatever we use for resolver > discovery will I'm with Paul. I prefer creating new RR types. There aren't that many dumbass middleboxes around, and those that are there, are usually put there intentionally, and they deserve what they get. I was among the first who did that back in 2002, and it wasn't that hard. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl76f/0ACgkQgItw+93Q 3WUzCggAvQKcz6LqOglmOy5KT98Pp9kBrV9VCboElOfHV1jAr1phoiN45A4iRbIN 5fOcbZO8QoaL6nbZHComFk2i3ai+8m0VTRD0HLAUTJ9itxYnGYUMOxdOTgaQCt9i C54ifbzQeIuhxgCljOc3EgZ511/0VK+WaLAOb+mcxmhVRN32ne1c/DoGb8x2nXxI dOkNs/8vEZEOBcjA/7/ld1qz+Od2xzsjVp3VDcwU+3CuyKtrAEtQ+Ll7vfYYQW1g ri7g3F/UgepH+a69H2+uLJN1hye9yr6ET/Lhf9aZCa6vH4y06Bt+swUG3GYHkEjC wIA2vJQDzo/1LswiR4jtmSc6uXD19w== =vLpe -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 29 17:43:24 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11A43A0ED3 for ; Mon, 29 Jun 2020 17:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 Vurev1Z4Vuyl for ; Mon, 29 Jun 2020 17:43:21 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 D3F433A0ED1 for ; Mon, 29 Jun 2020 17:43:20 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id r9so5944205ual.1 for ; Mon, 29 Jun 2020 17:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JFqk3G5s6wXvPgWKcbwjREMjlKM2MA2+834aRUYVoQE=; b=V72jGN5fsbMJtONjAhYwVgY/wqo3wH4kv/OetbGlLmOkVCzi/XA2eZv6DFuTk9D30G vu+VXmM5CNTpEgdxc8/GJgk2Np8sCS9risZmQY9H3i0izF/S7IcIsvHlqkp3iBkQyJvW Y20XuEFqCuTqgzeQuTtV43UV9cVAZG4kDk5ntpfuGLRzf+lHgys/t6YoAfgUsiAbuEPa g1sSbr2eUcqLYcwAE4YI6Gz/rd7FEYXlryZfdheT/V9T8J2nZ+ZHDEBWNDQLUlqOcXRd wBfyy0h68urYPg0RA/NN6c9H35xapzCc7rQmUTiFmaCbxeRTV4RJymOLx7vB4Knxqs3N jqGg== 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:to:cc; bh=JFqk3G5s6wXvPgWKcbwjREMjlKM2MA2+834aRUYVoQE=; b=fK7EsOj3NEZ5Mm5+iuAvqTIqfn7rL/y5saodrLOuxeroIvPHfpt59PFS2B4k44gH+N pABu19mlbuwuwy8hotxV8N2QLo2aesfs0d6RiRzAsuirl88vIP2X0ZUHVkfWQaTk/HlP zdbTzOEOY0PPk31gxi7zMtUvZsB27+qrxCS0L/1jHv1m9L/CRucdhBYRRHXUN7PZfAbb FC9RZA3FzU3vyMGraGlszt+L/Of1UEUaTmMxvK00+i38+kQUDF00//g0hT7vqaaHkPoN h8E2GzPt/IgFqTuk7t+rn/Yv25MV2v3T3/52CFQyyArRItiwBe+k6DzR8Mv0cAJSEjik PPew== X-Gm-Message-State: AOAM530zZTOdkXRmwPVzXeMYUZGcSouX+jdagzig9MIa7PONmwJXbV3u +FkG4aOJ1y3TqRNh2t8B/VvrPSEDOZjMkPKLGWQ= X-Google-Smtp-Source: ABdhPJyVZR4fOZPIIHaXNIspg5ePpBM1FFpRr08uP9eajNgdfjEjkW4IfNkZj6oK1RsrW2KNsrPNK3CbPDq0Z8hgmJA= X-Received: by 2002:ab0:6f57:: with SMTP id r23mr13124663uat.23.1593477799764; Mon, 29 Jun 2020 17:43:19 -0700 (PDT) MIME-Version: 1.0 References: <14119.1593367594@localhost> <3615321.ADK9YsXCiF@linux-9daj> In-Reply-To: From: Daniel Migault Date: Mon, 29 Jun 2020 20:43:08 -0400 Message-ID: To: Eric Rescorla Cc: Paul Vixie , Michael Richardson , ADD Mailing list , John R Levine Content-Type: multipart/alternative; boundary="0000000000003668ca05a9427626" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 00:43:23 -0000 --0000000000003668ca05a9427626 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 29, 2020 at 7:15 PM Eric Rescorla wrote: > > > On Mon, Jun 29, 2020 at 2:40 PM Daniel Migault > wrote: > >> Hi, >> >> I believe the proposal presents some >> similarities to draft-mglt-drdp [1] that is >> using the DNS to proceed to the >> discovery. I see drdp as more generic, >> and would be happy to improve it. >> >> I would be happy to understand why HTTP >> is a better stack to perform the >> discover as opposed to DNS. I think that >> DNS is better as it is the common >> protocol to DoT DoH and DNS, but I might >> be missing something. >> > > I don't quite follow this, as we do not use HTTP. > I thought you were saying using HTTPSSVC was architecturally better - that was section 5 not 4. > > >> >> I believe that CNAME is to restrictive >> and would not make possible for example >> to have multiple resolvers >> > > This goes back to use case. In our use case, the multiple resolvers would > be supplied by manual configuration of the client. the CNAME is just a > lookup key. > Unless I am missing something, I do not see how the ISP could respond saying and provide the application a resolver that implements DoH, a resolver that implement DoTs, a resolver that implements DoH and DNSSEC validation and let the application pick the one it prefers. > >> CNAME does not provide useful necessary >> parameters that may also be useful for a >> DoH resolver DRDP lists among others: >> alpn, ensiconfig, uri template, user >> display, auth_domain, filtering, >> ip_subnet, dnssec, .... >> >> My understanding is that BCP 17 saw SRV >> as a long term solution for CNAME which >> is now superseded by HTTPSVC/SVCB. I see >> SRV as very common in home networks with >> service discovery. >> >> I believe that using a generic is >> problematic as is prevents its resoltion >> to be secured with DNSSEC. >> > > As I said earlier, this goes back to threat model. Please describe the > thrat model where you think DNSSEC helps. > The threat model seems for Comcast and the end user having the traffic of its end users being redirected to Cloudflare instead of the local resolver. Both resolvers are trusted according to Firefox but the end user and the ISP may have a different view. It also means that any information that is not preconfigured cannot be trusted. > -Ekr > > > > >> In DRDP [1], the list of resolvers is >> associated to a resolving domain. In the >> case of an ISP the resolving domain is >> derive with a reverse resolution from >> the IP address announced by the ISP . >> Note that other means may be provided. >> With the resolving domain - in your case >> resolver.example, the application will >> retrieve the resolvers associated to the >> resolving domain. In your case you are >> exclusively focused on DoH server, so >> your application will them perform >> _443_dns.example.com. SVCB. >> >> Note that an early version of DRDP was >> using SRV/TXT instead of SVCB. >> >> Yours, >> Daniel >> >> [1] >> https://github.com/mglt/draft-mglt-abcd-dofoo-discovery/blob/master/draft-mglt-add-rdp.mkd >> >> On Sun, Jun 28, 2020 at 3:23 PM Paul Vixie wrote: >> >>> On Sunday, 28 June 2020 18:29:22 UTC John R Levine wrote: >>> > On Sun, 28 Jun 2020, Michael Richardson wrote: >>> > > > Beyond that I gather there is still concern about SOHO routers >>> with >>> > > > poorly implemented DNS forwarders that only handle some kinds of >>> > > > queries. >>> > > >>> > > I believe that the majority of devices on the market are now based >>> upon >>> > > versions of openwrt which, even if 10 years out of date, now have >>> only 15 >>> > > year old DNS forwarding code. And that's new enough. >>> > >>> > It's not what's on sale now, it's what's installed. People tend to >>> keep >>> > what they have unless it breaks in ways that are obvious to them. >>> >>> as we learned with EDNS, we should have broken more stuff sooner. being >>> liberal in what we accept and conservative in what we generate has not >>> scaled >>> and won't. >>> >>> -- >>> Paul >>> >>> >>> -- >>> Add mailing list >>> Add@ietf.org >>> https://www.ietf.org/mailman/listinfo/add >>> >> >> >> -- >> Daniel Migault >> Ericsson >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > -- Daniel Migault Ericsson --0000000000003668ca05a9427626 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0
I believe that CNAME is to restrictive
and would not make possible for = example
to have multiple resolvers

This goes back to use case. In our use case, the multiple resolvers = would be supplied by manual configuration of the client. the CNAME is just = a lookup key.


CNAME does not provide useful necessary
parameter= s that may also be useful for a
DoH resolver DRDP lists among others:alpn, ensiconfig, uri template, user
display, auth_domain, filtering,ip_subnet, dnssec, ....

My understanding is that BCP 17 saw SRVas a long term solution for CNAME which
is now superseded by HTTPSVC/S= VCB. I see
SRV as very common in home networks with
service discovery= . =C2=A0

I believe that using a generic is
problematic as is pre= vents its resoltion
to be secured with DNSSEC.

As I said earlier, this goes back to threat model. P= lease describe the thrat model where you think DNSSEC helps.

The threat model seems for Comcast and = the end user having the traffic of its end users being redirected to Cloudf= lare instead of the local resolver. Both resolvers are trusted according to= Firefox but the=C2=A0end user and the ISP may have a different=C2=A0view. = It also means that any information that is not preconfigured cannot be trus= ted.=C2=A0



<= /div>
-Ekr




= [1] https://github.com/mglt/d= raft-mglt-abcd-dofoo-discovery/blob/master/draft-mglt-add-rdp.mkd

On= Sun, Jun 28, 2020 at 3:23 PM Paul Vixie <paul@redbarn.org> wrote:
On Sunday, 28 June 2020 18:29:22 UT= C John R Levine wrote:
> On Sun, 28 Jun 2020, Michael Richardson wrote:
> >=C2=A0 =C2=A0 > Beyond that I gather there is still concern abo= ut SOHO routers with
> >=C2=A0 =C2=A0 > poorly implemented DNS forwarders that only han= dle some kinds of
> >=C2=A0 =C2=A0 > queries.
> >
> > I believe that the majority of devices on the market are now base= d upon
> > versions of openwrt which, even if 10 years out of date, now have= only 15
> > year old DNS forwarding code.=C2=A0 And that's new enough. >
> It's not what's on sale now, it's what's installed.=C2= =A0 People tend to keep
> what they have unless it breaks in ways that are obvious to them.

as we learned with EDNS, we should have broken more stuff sooner. being liberal in what we accept and conservative in what we generate has not scal= ed
and won't.

--
Paul


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add


--
Daniel Migault
Ericsson
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add


--
Daniel Migault
Ericsson
--0000000000003668ca05a9427626-- From nobody Mon Jun 29 18:14:27 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421063A0EFA for ; Mon, 29 Jun 2020 18:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 i2pwIunDtSA0 for ; Mon, 29 Jun 2020 18:14:23 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 197603A0EF8 for ; Mon, 29 Jun 2020 18:14:23 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id s20so2921109vsq.5 for ; Mon, 29 Jun 2020 18:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CLshK/wd2GUUj3J0BNMklcJjg5VrU5yOLs4R9FeJ2nY=; b=JLYTnDMZJXfKXiMd/fOHavMHC0OwQxV+QIPrqG8FaBVELI1QY+YSTHiuBAC77ijQfe 7yfWD3ewm+V2JnCcEN/3TL6LoZQFzRwT8jVrO5ghcCwQK/CEsu58SQ3meQRhKp7X5XBo QRAJQZXEOjufuFOxXdaq7ingR1zeR6rpEETA2CrjaO2pzeYA4Q6AbKZjod2K6H4cs7bX oGlm69QgT+oDplY6TYLeH79lzr220n036bdP96oaVDBNG+bKs+X2kER+6ZUN4TYJun9t k4vcPTVf30VFZNDT8GJFpMR90FeUsrWj41ATjJKU77bykWswBvKhD0o3rjSH0PkDyqYY 7tFg== 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:to:cc; bh=CLshK/wd2GUUj3J0BNMklcJjg5VrU5yOLs4R9FeJ2nY=; b=JjpGiY3Od5sFJEDCxwdlRrGSdepVGH7QYEIzD/j7qFobq6k0wWsASKdlhVQPhdcb3u JOA7k1tIpLlYHgbuGvf2yhHd5QHIUUCTN3NbaEceJHQXpE+BXUniufPsHhrm+6211SMF X2skl33jugdalJpdUxQTG1VvBFviPpgJL1DeEOc51pmbEk1gFK+yNb5vdpvcr9LVSP9T drNGdwfVyOoa3Pi16OmjHFkhO5uGHgoub+z6But26f9NTz7tPqptp/Yph1WAEpWwXtDj RsfHz07nsFHCmv0xx+/9fMBElrnl4dh8ViC9siSBY5lKqYYlHr4C5tMpHb1hjOBEhva9 QOiQ== X-Gm-Message-State: AOAM530YNBjY6/3RdQpYRn/avhjDs7w576f0DfpKdu4rn4aTdMFeHMO4 ygqtHAEGfVDp++kmpMlAPqva9ZXBcLB9yiOCcnU= X-Google-Smtp-Source: ABdhPJyjE4hpcA08M7U6MtA+gmBqEFegAK2gJGZILdbcrLNomFVhP5rxp4NFgETIGG3WnhcGeO/iVf9Y3KIhHW7gicI= X-Received: by 2002:a05:6102:38c:: with SMTP id m12mr12516010vsq.31.1593479661998; Mon, 29 Jun 2020 18:14:21 -0700 (PDT) MIME-Version: 1.0 References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> <26559974.PdTMpzyJZD@linux-9daj> <18350.1593475069@localhost> In-Reply-To: <18350.1593475069@localhost> From: Daniel Migault Date: Mon, 29 Jun 2020 21:14:11 -0400 Message-ID: To: Michael Richardson Cc: Paul Vixie , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000035d7d705a942e562" Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 01:14:26 -0000 --00000000000035d7d705a942e562 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that new RRtypes can be added but I am not convinced we need new ones for the discovery. What is unclear to me is the use of HTTPS as opposed to SVCB for the DNS optionally over HTTP and most of the time over TLS. I have the feeling that alpn could be used to determine HTTP. That said RRtype are one aspect but I believe that we should also agree/discuss what we expect from the discovery. Here are my thoughts on what the discovery should achieve: REQ 1: DRDP MUST enable a DNS client to discover the available resolving services with their associated characteristics in order to proceed to a selection process. The selection process takes resolving services identities and associated parameters and proceeds to the selection. Any sort of resolving service selection is outside the scope of DRDP. REQ 2: While the discovery process is triggered by the DNS client, a third party MUST be able to provide necessary input information so a resolving service discovery process can be triggered within a specific context. Provisioning protocols to provide this information is not as per say in scope of DRDP. DRDP defines the format of the format for such input as well as a set of such inputs. REQ 3: Any information used in DRDP MUST be authenticated by its owner. In particular, the characteristics associated to the resolving service MUST be certified by the resolving service operator / owner and MUST be associated a validity period. In addition, a third party providing a set of inputs MUST authenticate that set. REQ 4: Information associated to the resolving services is intended to enable the selection process that is assumed to match the end user or application policy. The selection process is out of scope of DRDP. Information may carry some characteristics of a resolving service or hints that will help the selection. In particular an operator of multiple resolving service MUST be able to associate a preference to the proposed resolving services. To ease automation of the selection as well as to make multiple applications benefit from DRDP the information MUST be carried over a standardized format. REQ 5: DRDP MUST be designed to be used indifferently by a DNS client using any DNS transport protocol (Do53, DoT, DoH, ...). However, DRDP SHOULD be able to restrict the information retrieved to a certain type of resolving service, i.e. Do53, DoT, DoH. REQ 6: DRDP deployment MUST NOT be disruptive for the legacy DNS client or infrastructure and legacy client SHOULD be able to incrementally include DRDP. [1] https://datatracker.ietf.org/doc/draft-mglt-add-rdp/ Yours, Daniel On Mon, Jun 29, 2020 at 7:58 PM Michael Richardson wrote= : > > Paul Vixie wrote: > >> Just noting far we have a variety of suggestions on CNAME, URI, > TXT, RESINFO > >> and HTTPSSVC (though I don=E2=80=99t think all have I-Ds as yet) -= always > nice to > >> see the ideas flowing. :-) As a practical person that in IETF land > is > >> considered an implementer, I naturally feel inclined towards RR > types that > >> already exist as this enables something to be rapidly deployed. > > > the community apparently lacks coherence on the importance of rapid > deployment > > as compared to the importance of technical excellence. if we're not > going to > > add any more new RR types because they take ten years to become > usable (see > > the SPF RR vs. the later _spf TXT RR), we should say that, and clos= e > the RR > > type registry, so as to avoid confusing newcomers. > > > if on the other hand we're going to continue to evolve DNS in ways > that > > include adding new RR types, and all the initiators who are stuck > behind > > dumbass middleboxes who reject or butcher unknown RR types are goin= g > to fail > > hard and be excluded from the new applications and protocols in > order to put > > more pressure on middlebox users/makers/distributors, we should say > that. > > > either way, nothing is temporary. whatever we use for resolver > > discovery will > > I'm with Paul. I prefer creating new RR types. > There aren't that many dumbass middleboxes around, and those that are > there, > are usually put there intentionally, and they deserve what they get. > > I was among the first who did that back in 2002, and it wasn't that hard. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --=20 Daniel Migault Ericsson --00000000000035d7d705a942e562 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that new RRtypes=C2=A0can be added but I am not co= nvinced we need new ones for the discovery. What is unclear to me is the us= e of=C2=A0 HTTPS as opposed to SVCB for the DNS optionally over HTTP and mo= st of the time over TLS. I have the feeling that alpn could=C2=A0be used to= determine HTTP.=C2=A0

That said RRtype are one aspect b= ut I believe that we should=C2=A0also agree/discuss what we expect from the= discovery. Here are my thoughts=C2=A0on what the discovery should=C2=A0ach= ieve:

   REQ 1: DRDP MUST enable a DNS client to discover the available
   resolving services with their associated characteristics in order to
   proceed to a selection process.  The selection process takes
   resolving services identities and associated parameters and proceeds
   to the selection.
   Any sort of resolving service selection is outside the scope of DRDP.

   REQ 2: While the discovery process is triggered by the DNS client, a
   third party MUST be able to provide necessary input information so a
   resolving service discovery process can be triggered within a
   specific context.
   Provisioning protocols to provide this information is not as per say
   in scope of DRDP.  DRDP defines the format of the format for such
   input as well as a set of such inputs.

   REQ 3: Any information used in DRDP MUST be authenticated by its
   owner.  In particular, the characteristics associated to the
   resolving service MUST be certified by the resolving service operator
   / owner and MUST be associated a validity period.  In addition, a
   third party providing a set of inputs MUST authenticate that set.

   REQ 4: Information associated to the resolving services is intended
   to enable the selection process that is assumed to match the end user
   or application policy.  The selection process is out of scope of
   DRDP.  Information may carry some characteristics of a resolving
   service or hints that will help the selection.  In particular an
   operator of multiple resolving service MUST be able to associate a
   preference to the proposed resolving services.  To ease automation of
   the selection as well as to make multiple applications benefit from
   DRDP the information MUST be carried over a standardized format.


   REQ 5: DRDP MU=
ST be designed to be used indifferently by a DNS client
   using any DNS transport protocol (Do53, DoT, DoH, ...).  However,
   DRDP SHOULD be able to restrict the information retrieved to a
   certain type of resolving service, i.e. Do53, DoT, DoH.

   REQ 6: DRDP deployment MUST NOT be disruptive for the legacy DNS
   client or infrastructure and legacy client SHOULD be able to
   incrementally include DRDP.


On Mon, Jun 29, 2020 at 7:58 PM Michael Richardson= <mcr@sandelman.ca> wrote:

Paul Vixie <paul@r= edbarn.org> wrote:
=C2=A0 =C2=A0 >> Just noting far we have a variety of suggestions on = CNAME, URI, TXT, RESINFO
=C2=A0 =C2=A0 >> and HTTPSSVC (though I don=E2=80=99t think all have = I-Ds as yet) - always nice to
=C2=A0 =C2=A0 >> see the ideas flowing. :-) As a practical person tha= t in IETF land is
=C2=A0 =C2=A0 >> considered an implementer, I naturally feel inclined= towards RR types that
=C2=A0 =C2=A0 >> already exist as this enables something to be rapidl= y deployed.

=C2=A0 =C2=A0 > the community apparently lacks coherence on the importan= ce of rapid deployment
=C2=A0 =C2=A0 > as compared to the importance of technical excellence. i= f we're not going to
=C2=A0 =C2=A0 > add any more new RR types because they take ten years to= become usable (see
=C2=A0 =C2=A0 > the SPF RR vs. the later _spf TXT RR), we should say tha= t, and close the RR
=C2=A0 =C2=A0 > type registry, so as to avoid confusing newcomers.

=C2=A0 =C2=A0 > if on the other hand we're going to continue to evol= ve DNS in ways that
=C2=A0 =C2=A0 > include adding new RR types, and all the initiators who = are stuck behind
=C2=A0 =C2=A0 > dumbass middleboxes who reject or butcher unknown RR typ= es are going to fail
=C2=A0 =C2=A0 > hard and be excluded from the new applications and proto= cols in order to put
=C2=A0 =C2=A0 > more pressure on middlebox users/makers/distributors, we= should say that.

=C2=A0 =C2=A0 > either way, nothing is temporary. whatever we use for re= solver
=C2=A0 =C2=A0 > discovery will

I'm with Paul. I prefer creating new RR types.
There aren't that many dumbass middleboxes around, and those that are t= here,
are usually put there intentionally, and they deserve what they get.

I was among the first who did that back in 2002, and it wasn't that har= d.

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add


--
Daniel Migault
Ericsson
--00000000000035d7d705a942e562-- From nobody Mon Jun 29 18:15:48 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAF23A0EFD for ; Mon, 29 Jun 2020 18:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdEBcS7WNB1e for ; Mon, 29 Jun 2020 18:15:46 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 8BE833A0EFB for ; Mon, 29 Jun 2020 18:15:45 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id g139so10344351lfd.10 for ; Mon, 29 Jun 2020 18:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cKSN3BCspMQNSp0jThys/4xG+Yb7+eR69rl5qCJIiV8=; b=KXhWf2/RiB9f9Xx1uep+qJ900nL7vr8aDU24Np9ccGlg5duGqG8bZjFO4l4PpVMZs5 otA4t7+cCmPwAf0+HZ38T5XpnvdR3BgRFuMVI6KupE0oYsXOcCXrXIvTobsBSYYJGE/Q AP1UqqtUJplyAWuOfh1ZHNCuGL6opgyYFOHPTcwsZLw7tL7zZGTxQeLKm/8sfrmTfrmR FsSaa0zs9lm+MImxRH1fbCj3uEA6kFJAHrQM+Tcbv2tZ2jO/tpsjR5F/35WpOikJTkx3 pA+YjsZTpE0IhQlvTMJFgdso2k/G9C5auorG2qSM4++xZXEuQKDRVyPFDzKO2b4tW58d NQYg== 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:to:cc; bh=cKSN3BCspMQNSp0jThys/4xG+Yb7+eR69rl5qCJIiV8=; b=nD/AavsBWF4YSm9pdC8neWeonIXk9TZnrqCcNB4hc3SbIKG5v6gCt+neZ78rnGq8Uw xcvMPXhB1F8s2VDd/mvo+QN34PHdI3H8pcBg+DGUwP9oZdLvmsXF1o+BABceBUUnvAbW uVSTI8GzfMjHSOno6poetfq66CVjblubljyJ5p2pFwL0ebrgikzb4+r50KweU7wEjTh8 928dC75QP4woV+68dc7G42qylFclw9bJzpeUtAAx4cJBRMsztJNnVwJEAmptV3f/Ompr HZso/hm2wjH4wFMIj1JoXOVA3/7hD/g8Hagy9bUdmL7tTCN/ROewFgkSpacL8oOd6BQ+ 4A6w== X-Gm-Message-State: AOAM5318tPJGbXrXuQvXYDfvd1Zpv8yjlDrk/aP7Uh3iZ8qw6pIsUUR8 2yjJHhTVdzHSMOofaGD0eisRD5B+VXO37z6Zzn1kow== X-Google-Smtp-Source: ABdhPJy9O37ojpqsty0/aBfmuZzIHtjOeKDlpkYy81tqAQkyQka8xGZDwXJrieq4uuyy6HPbWYw8jQjpxq7wZpKY+dg= X-Received: by 2002:ac2:4c2a:: with SMTP id u10mr10488366lfq.168.1593479743597; Mon, 29 Jun 2020 18:15:43 -0700 (PDT) MIME-Version: 1.0 References: <14119.1593367594@localhost> <3615321.ADK9YsXCiF@linux-9daj> In-Reply-To: From: Eric Rescorla Date: Mon, 29 Jun 2020 18:15:07 -0700 Message-ID: To: Daniel Migault Cc: Paul Vixie , Michael Richardson , ADD Mailing list , John R Levine Content-Type: multipart/alternative; boundary="00000000000013a97505a942ea05" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 01:15:48 -0000 --00000000000013a97505a942ea05 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 29, 2020 at 5:43 PM Daniel Migault wrote: > > > On Mon, Jun 29, 2020 at 7:15 PM Eric Rescorla wrote: > >> >> >> On Mon, Jun 29, 2020 at 2:40 PM Daniel Migault >> wrote: >> >>> Hi, >>> >>> I believe the proposal presents some >>> similarities to draft-mglt-drdp [1] that is >>> using the DNS to proceed to the >>> discovery. I see drdp as more generic, >>> and would be happy to improve it. >>> >>> I would be happy to understand why HTTP >>> is a better stack to perform the >>> discover as opposed to DNS. I think that >>> DNS is better as it is the common >>> protocol to DoT DoH and DNS, but I might >>> be missing something. >>> >> >> I don't quite follow this, as we do not use HTTP. >> > I thought you were saying using HTTPSSVC was architecturally better - that > was section 5 not 4. > Well, S 5 is an empty IANA Considerations section. In any case, I don't really have a position on whether HTTPSVC is better. The text says it "may be" the right answer eventually. I believe that CNAME is to restrictive >>> and would not make possible for example >>> to have multiple resolvers >>> >> >> This goes back to use case. In our use case, the multiple resolvers would >> be supplied by manual configuration of the client. the CNAME is just a >> lookup key. >> > > Unless I am missing something, I do not see how the ISP could respond > saying and provide the application a resolver that implements DoH, a > resolver that implement DoTs, a resolver that implements DoH and DNSSEC > validation and let the application pick the one it prefers. > That's correct. As I said, that's not part of our use case, because we're only trying to determine which network you are on and then look up the resolvers in our TRR list. If we expected ISPs to have >1 kind of resolver we'd probably just have them register them all with us and then incorporate the list into the binary. I appreciate that this won't work well for many, but as I said, this mechanism is targeted at quite a narrow use case. > >> >>> CNAME does not provide useful necessary >>> parameters that may also be useful for a >>> DoH resolver DRDP lists among others: >>> alpn, ensiconfig, uri template, user >>> display, auth_domain, filtering, >>> ip_subnet, dnssec, .... >>> >>> My understanding is that BCP 17 saw SRV >>> as a long term solution for CNAME which >>> is now superseded by HTTPSVC/SVCB. I see >>> SRV as very common in home networks with >>> service discovery. >>> >>> I believe that using a generic is >>> problematic as is prevents its resoltion >>> to be secured with DNSSEC. >>> >> >> As I said earlier, this goes back to threat model. Please describe the >> thrat model where you think DNSSEC helps. >> > > The threat model seems for Comcast and the end user having the traffic of > its end users being redirected to Cloudflare instead of the local resolver. > Both resolvers are trusted according to Firefox but the end user and the > ISP may have a different view. It also means that any information that is > not preconfigured cannot be trusted. > Well, I agree that this attack is possible (and is described in S 4) but I don't see how DNSSEC prevents it. It's true that if the user is on a network operated by "example.com" DNSSEC could be used to secure the information that "example.com" wants you to use a given resolver, but the problem is that the user has no secure way of discovering that they are on " example.com", and therefore the attacker can just substitute in their own domain there. I could of course be wrong about this. If you believe I am, I would encourage you to describe the entire discovery chain and where you believe DNSSEC acts to prevent attack. -Ekr --00000000000013a97505a942ea05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 29, 2020 at 5:43 PM Danie= l Migault <mglt.ietf@gmail.com> wrote:


On Mon, Jun 29, 2020 at 7:15 PM Eric Res= corla <ekr@rtfm.com> wrote:


On Mon, Jun 29, 2020 at 2:40 PM Daniel M= igault <mglt.ie= tf@gmail.com> wrote:
Hi,=C2=A0

I believe the proposal presents some
similarities to draft-mglt-d= rdp [1] that is
using the DNS to proceed to the
discovery. I see drdp= as more generic,
and would be happy to improve it.

I would be h= appy to understand why HTTP
is a better stack to perform the
discover= as opposed to DNS. I think that
DNS is better as it is the common
pr= otocol to DoT DoH and DNS, but I might
be missing something. =C2=A0
<= /div>

I don't quite follow this, = as we do not use HTTP.
I thought you wer= e saying using HTTPSSVC=C2=A0was architecturally better -=C2=A0that was sec= tion 5 not=C2=A04.=C2=A0=C2=A0

Well, S 5 is an empty IANA Considerations section.

In any case, I don't really have a position on whether HTTPSVC i= s better. The text says it "may be" the right answer eventually.<= /div>


<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I believe that CNAME is to restrictive
and would not make possi= ble for example
to have multiple resolvers
=
This goes back to use case. In our use case, the multiple re= solvers would be supplied by manual configuration of the client. the CNAME = is just a lookup key.

Unl= ess=C2=A0I am missing something, I do not see how the ISP could respond say= ing and provide the application a resolver that implements DoH, a resolver = that implement DoTs, a resolver that implements DoH and DNSSEC validation a= nd let the application pick the one it prefers.=C2=A0

That's correct. As I said, that's not= part of our use case, because we're only trying to determine which net= work you are on and then look up the resolvers in our TRR list. If we expec= ted ISPs to have >1 kind of resolver we'd probably just have them re= gister them all with us and then incorporate the list into the binary. I ap= preciate that this won't work well for many, but as I said, this mechan= ism is targeted at quite a narrow use case.

=C2=A0=C2=A0

CNAME d= oes not provide useful necessary
parameters that may also be useful for = a
DoH resolver DRDP lists among others:
alpn, ensiconfig, uri templat= e, user
display, auth_domain, filtering,
ip_subnet, dnssec, ....
=
My understanding is that BCP 17 saw SRV
as a long term solution for = CNAME which
is now superseded by HTTPSVC/SVCB. I see
SRV as very comm= on in home networks with
service discovery. =C2=A0

I believe tha= t using a generic is
problematic as is prevents its resoltion
to be s= ecured with DNSSEC.

As I sa= id earlier, this goes back to threat model. Please describe the thrat model= where you think DNSSEC helps.

The threat model seems for Comcast and the end user having the traffi= c of its end users being redirected to Cloudflare instead of the local reso= lver. Both resolvers are trusted according to Firefox but the=C2=A0end user= and the ISP may have a different=C2=A0view. It also means that any informa= tion that is not preconfigured cannot be trusted.

Well, I agree that this attack is possible (a= nd is described in S 4) but I don't see how DNSSEC prevents it. It'= s true that if the user is on a network operated by "example.com" DNSSEC could be used to secure the info= rmation that "example.com" wan= ts you to use a given resolver, but the problem is that the user has no sec= ure way of discovering that they are on "example.com", and therefore the attacker can just substitute in = their own domain there.

I could of course be wrong= about this. If you believe I am, I would encourage you to describe the ent= ire discovery chain and where you believe DNSSEC acts to prevent attack.

-Ekr

--00000000000013a97505a942ea05-- From nobody Mon Jun 29 19:14:50 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58933A09D4 for ; Mon, 29 Jun 2020 19:14:48 -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, SPF_HELO_NONE=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 a7dGP4LbvhYg for ; Mon, 29 Jun 2020 19:14:47 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 5BB843A09CF for ; Mon, 29 Jun 2020 19:14:47 -0700 (PDT) Received: from xse327.mail2web.com ([66.113.197.73] helo=xse.mail2web.com) by mx37.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jq5nD-0000yl-HH for add@ietf.org; Tue, 30 Jun 2020 04:14:44 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 49wnx76m3Kz28LS for ; Mon, 29 Jun 2020 19:14:35 -0700 (PDT) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jq5n9-0001B0-R2 for add@ietf.org; Mon, 29 Jun 2020 19:14:35 -0700 Received: (qmail 10811 invoked from network); 30 Jun 2020 02:14:35 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.46.187]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Jun 2020 02:14:35 -0000 To: Michael Richardson , Paul Vixie , ADD Mailing list References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> <26559974.PdTMpzyJZD@linux-9daj> <18350.1593475069@localhost> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <516fcd85-2d67-e853-03b5-49220df9d878@huitema.net> Date: Mon, 29 Jun 2020 19:14:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <18350.1593475069@localhost> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.197.73 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0f6LF1GdvkEexklpcFpSF5apSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDNzOpszOkW3faMySFwG163+fH zJ6mVE7ewsipSVIfs4bkPGNfjOeg7Wmc4+9EpxPHgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cBN5HyO9svXODFfKDo2spNmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdLn4jABaJqtNDIuGYj2WGeveXgFMyx0sD4hRS2uyMFprER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnO2X76nqcCdg D2squdONfBVX+Q7VeOCtH6kQ2ZC0Cwty9+p8wjtuWdklZXtgWefapbjbuiqoegAUIkqF7XCkxWV8 g2fGU86cSswil+kDetUfttbLHdNhiUq2jBEvMVLlZ4GThCScvU0cCIiHSQbmcVLe+meYQ7YgoVMw qCHlZKp9N+qh3YF7t/lvtNmPz3Nh3ivbCQzj+ao5nt2WFszkVvXucztg7IQIIFh/QeCcs28yXPWl FdaGOH191uXjgjQN/bk/tOvsMDZmQNfeGxdXg4EpIz6IgkDXGchs0sZ5voms83g9ueTJOU6a76yp yxjdeg8YhWenlMfuvb1mNY5/IPiuedK/Z3MvnAyDmuOaA5CGZRWsGw8ac2InzcAP/gmxwNpms+rB 6wJM+NNhN3aT35NSU/fjw6KbqLw80r1gDO3m6U0LjBzYuQztdAThgtWSU3qCINKqlAdh+ePAcEwD s/8= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 02:14:49 -0000 On 6/29/2020 4:57 PM, Michael Richardson wrote: > Paul Vixie wrote: > >> Just noting far we have a variety of suggestions on CNAME, URI, = TXT, RESINFO > >> and HTTPSSVC (though I don=E2=80=99t think all have I-Ds as yet)= - always nice to > >> see the ideas flowing. :-) As a practical person that in IETF la= nd is > >> considered an implementer, I naturally feel inclined towards RR = types that > >> already exist as this enables something to be rapidly deployed. > > > the community apparently lacks coherence on the importance of rap= id deployment > > as compared to the importance of technical excellence. if we're n= ot going to > > add any more new RR types because they take ten years to become u= sable (see > > the SPF RR vs. the later _spf TXT RR), we should say that, and cl= ose the RR > > type registry, so as to avoid confusing newcomers. > > > if on the other hand we're going to continue to evolve DNS in way= s that > > include adding new RR types, and all the initiators who are stuck= behind > > dumbass middleboxes who reject or butcher unknown RR types are go= ing to fail > > hard and be excluded from the new applications and protocols in o= rder to put > > more pressure on middlebox users/makers/distributors, we should s= ay that. > > > either way, nothing is temporary. whatever we use for resolver > > discovery will > > I'm with Paul. I prefer creating new RR types. > There aren't that many dumbass middleboxes around, and those that are t= here, > are usually put there intentionally, and they deserve what they get. I heard EKR make two arguments for using CNAME: not just middlebox compatibility, but also software simplicity. The latter is interesting, and might be worth explaining a bit. The way I understand it, Mozilla would rather use a well known API like getaddrinfo(), rather than a more capable API that supports different record types. I can guess that this is a software simplicity/complexity trade-off. I suppose that the more capable API tend to be implemented slightly differently on different OSes, which leads to more complex code with a variety of #ifdef to accommodate the different platform, more tests, and probably more bugs. But I may be getting it wrong, and I would rather hear what Mozilla actually thinks... -- Christian Huitema From nobody Mon Jun 29 19:25:28 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696863A09F9 for ; Mon, 29 Jun 2020 19:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=lowentropy.net header.b=mJ3q7ZC3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eo/QMxKD 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 1V4IxoYASaQM for ; Mon, 29 Jun 2020 19:25:25 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B543A09F8 for ; Mon, 29 Jun 2020 19:25:25 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 584E45C00CC for ; Mon, 29 Jun 2020 22:25:24 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 29 Jun 2020 22:25:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=VJ7Y3o85MQMbKBsPfx4Sx8vWNEeP/A7 QrbTo315z0js=; b=mJ3q7ZC34JMQioZZdbqLf7rEE/D9idMuDs/WebHvL517arZ jwk9vEyOEjr+2ugPYJtRK28Df2T1qU6gMpw4MMWujj8Vo2/5K8uHRljwkYWGL5t+ 1M91xOFeJw3vIY47VN/ZyWZSbnu54gOHNpAT3yp4yMePP1aeqS/IKq2nGgPWqI+o qhR0P1Hf7NH4ePBWMrd7FgltWyyEgkhbTJS8zeV6eleeJodcBRx6Ii3/fwxlsB2x KfSeWEGFbPVhAlqwI4m+rDr5KS9gcVdHRQuhkaS6qqoLSYqpunaxtCC8+Ow6LrUG EvwIFhWuqQmeoq0xOPPI++Q09P0phR7HjUWt51Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=VJ7Y3o 85MQMbKBsPfx4Sx8vWNEeP/A7QrbTo315z0js=; b=eo/QMxKDc0DyD1xZwqqrbv nlCAOLBWCjD6m9WifDmOa36u4Sn3HMYrZbMfR5WhbL69lgxKTkxPu3k6Nj776jOe VXBLKsSp8pMj9Sn/P8aUDeDDjAPJlP4exG7871QbrseQOo7KCnspE8QFvfFiJhot n6Lg7t64K21clJccJmIz79r96UxCCgUUhBNb7ALJSsmMHN2eavTLT4quyNSGtNTs SbC3XEdvalPl+p2ETf8Obvqe4hP9WYLTFAANh1cLFoex0mK7pgL03B8p++A+mDm4 umAhR2Zs1Ds4I2sZo9+ecJN/fmMzDgXUKrP89frZzVPJVY78CRsGFtkG+mO0cn5g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvddttddgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EAB01E00B3; Mon, 29 Jun 2020 22:25:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668 Mime-Version: 1.0 Message-Id: <10fa5a67-1894-4bc5-9090-4d4f5aeb2242@www.fastmail.com> In-Reply-To: <516fcd85-2d67-e853-03b5-49220df9d878@huitema.net> References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> <26559974.PdTMpzyJZD@linux-9daj> <18350.1593475069@localhost> <516fcd85-2d67-e853-03b5-49220df9d878@huitema.net> Date: Tue, 30 Jun 2020 12:25:05 +1000 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 02:25:26 -0000 On Tue, Jun 30, 2020, at 12:14, Christian Huitema wrote: > I heard EKR make two arguments for using CNAME: not just middlebox > compatibility, but also software simplicity. The latter is interesting, > and might be worth explaining a bit. The way I understand it, Mozilla > would rather use a well known API like getaddrinfo(), rather than a more > capable API that supports different record types. I can guess that this > is a software simplicity/complexity trade-off. I suppose that the more > capable API tend to be implemented slightly differently on different > OSes, which leads to more complex code with a variety of #ifdef to > accommodate the different platform, more tests, and probably more bugs. > But I may be getting it wrong, and I would rather hear what Mozilla > actually thinks... I'm not super close to this, but my understanding is that we now have two resolution paths: one native and one for DoH. On the DoH path, we have greater ability to manage new RRtypes and queries. However, this specific case cannot follow that path. As this has to be cross-platform, there is a non-trivial amount of plumbing required to support doing anything other than the getaddrinfo() call. Our abstractions are pretty old and have never had to grow the ability grow features like the ability to handle new RRtypes. In other words, Christian, your guess is spot on. As this is (currently) driven by a need for expediency, and CNAME works, it wasn't worth investing a whole lot of effort in finding something better, especially when it is clear that the matter was not settled. If presented with an IETF consensus position on the topic, that would likely be a different story. From nobody Mon Jun 29 19:25:52 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66B73A09F9 for ; Mon, 29 Jun 2020 19:25:50 -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, SPF_HELO_NONE=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 3L8sv9Z5gZPJ for ; Mon, 29 Jun 2020 19:25:48 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A913A09F7 for ; Mon, 29 Jun 2020 19:25:48 -0700 (PDT) Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 5811FB0588 for ; Tue, 30 Jun 2020 02:25:46 +0000 (UTC) From: Paul Vixie To: ADD Mailing list Date: Tue, 30 Jun 2020 02:25:45 +0000 Message-ID: <2627412.DIRKxXNHPS@linux-9daj> Organization: none In-Reply-To: <516fcd85-2d67-e853-03b5-49220df9d878@huitema.net> References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> <18350.1593475069@localhost> <516fcd85-2d67-e853-03b5-49220df9d878@huitema.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 02:25:51 -0000 On Tuesday, 30 June 2020 02:14:36 UTC Christian Huitema wrote: > ... The way I understand it, Mozilla > would rather use a well known API like getaddrinfo(), rather than a more > capable API that supports different record types. I can guess that this > is a software simplicity/complexity trade-off. i don't like seeing evidence that the getdnsapi.net people wasted a decade building something that ended up being too complicated to go into the MPR. in case it's not obvious: i do not think we should make "forever" decisions based on what programming language or system library happens to be convenient at this decade. (nor upon what dumbass middleboxes we're often stuck behind.) > ... > But I may be getting it wrong, and I would rather hear what Mozilla > actually thinks... i hope you're getting it wrong too, because then i would be getting it wrong, since i understood the mozilla corporation's comments here the same way you describe. -- Paul From nobody Mon Jun 29 20:05:36 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E693A0063 for ; Mon, 29 Jun 2020 20:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 lDpWBKE-g0E6 for ; Mon, 29 Jun 2020 20:05:24 -0700 (PDT) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 0337E3A0A96 for ; Mon, 29 Jun 2020 20:05:24 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id o10so1790479uab.10 for ; Mon, 29 Jun 2020 20:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8CRy1qXC6YbaBzm2TgkwneL3GPFZW2KpT+tEPBSmDkQ=; b=bnGYriKyohGk4z7nRAr53e9Xs6ha9RtVAbiST9gGoJNBzEbaa+TQP7yrIV4ch5JOK4 zPsmav0i30YuYtgg6YR8vQdNy2TX+lzgyL1+sGCz3Fh1EMPxwBvjV7An8/S9jrrLhJhX PPeCPxywNSmvKYWBpECCGiJFX0O4XCK3ZBcDeGVO2Skx/r2wgx97DMBpxawXok3EadXh FfIJgHGhn5ZNqntLPaH2ANoo6pi1P7lZJj2KL+HoVp0LKANpwLmggCvNJeuOpZP/RE3w 62h+pyhBNbvLn8NDpqHhdxhtmK4xHsMaCLoRMH8u/dDAXst+2S9Xl/hjaR1QZaCz+kv2 Wuyg== 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:to:cc; bh=8CRy1qXC6YbaBzm2TgkwneL3GPFZW2KpT+tEPBSmDkQ=; b=ieeHAB6Bu4mvQWArjrNO4AOoPGBcZBIeePqomWHonr+oRluLZoNkASRUFrHPu68RRq LoOEqIM+x9jg6knghVpQtGvtxllSlbVMo4BdQIzMEzSalYGRKeq0xHBuk7U3E4QYIY3M 4lof+5AiMqbLHjYtSGl9jkYtxsafavnu137tOr2gC/e+8pGHn+/FCgC8XGU3LL8DmCF0 HyrTrVuIMSQv5T5ybSGgTAv/bNUDW668bOtQ5bKhyVzLMVFnVByxfpX12HU1WUHVOuqJ sAIVt9i6I61p+5IBwBVS6twaax0ssTDK5OAUMKZCnXeYDSZmvwTOwyhvQD+046GGqvim CEfw== X-Gm-Message-State: AOAM530+T5yvaYOwOXmFjPnRjHyRAWxQEzeB2UcTKEMobYamahRzZspU Q0F3W2/iZnAG1iBWCXLNzb+RpEAUOyrCjNLX0TE= X-Google-Smtp-Source: ABdhPJzBY4Me3MMZMQ58+o+qAuJs5OC+0HteKvgNgjt2lJaUHyaYqSrJvgSpcLAxFdUpdRGwVBYeEdKONYVS3jUgEbQ= X-Received: by 2002:ab0:2b08:: with SMTP id e8mr3104700uar.119.1593486323034; Mon, 29 Jun 2020 20:05:23 -0700 (PDT) MIME-Version: 1.0 References: <14119.1593367594@localhost> <3615321.ADK9YsXCiF@linux-9daj> In-Reply-To: From: Daniel Migault Date: Mon, 29 Jun 2020 23:05:11 -0400 Message-ID: To: Eric Rescorla Cc: Paul Vixie , Michael Richardson , ADD Mailing list , John R Levine Content-Type: multipart/alternative; boundary="0000000000003d2de105a9447269" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 03:05:35 -0000 --0000000000003d2de105a9447269 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 29, 2020 at 9:15 PM Eric Rescorla wrote: > > > On Mon, Jun 29, 2020 at 5:43 PM Daniel Migault > wrote: > >> >> >> On Mon, Jun 29, 2020 at 7:15 PM Eric Rescorla wrote: >> >>> >>> >>> On Mon, Jun 29, 2020 at 2:40 PM Daniel Migault >>> wrote: >>> >>>> Hi, >>>> >>>> I believe the proposal presents some >>>> similarities to draft-mglt-drdp [1] that is >>>> using the DNS to proceed to the >>>> discovery. I see drdp as more generic, >>>> and would be happy to improve it. >>>> >>>> I would be happy to understand why HTTP >>>> is a better stack to perform the >>>> discover as opposed to DNS. I think that >>>> DNS is better as it is the common >>>> protocol to DoT DoH and DNS, but I might >>>> be missing something. >>>> >>> >>> I don't quite follow this, as we do not use HTTP. >>> >> I thought you were saying using HTTPSSVC was architecturally better >> - that was section 5 not 4. >> > > Well, S 5 is an empty IANA Considerations section. > that was section 5 of adns > > In any case, I don't really have a position on whether HTTPSVC is better. > The text says it "may be" the right answer eventually. > > > I believe that CNAME is to restrictive >>>> and would not make possible for example >>>> to have multiple resolvers >>>> >>> >>> This goes back to use case. In our use case, the multiple resolvers >>> would be supplied by manual configuration of the client. the CNAME is just >>> a lookup key. >>> >> >> Unless I am missing something, I do not see how the ISP could respond >> saying and provide the application a resolver that implements DoH, a >> resolver that implement DoTs, a resolver that implements DoH and DNSSEC >> validation and let the application pick the one it prefers. >> > > That's correct. As I said, that's not part of our use case, because we're > only trying to determine which network you are on and then look up the > resolvers in our TRR list. If we expected ISPs to have >1 kind of resolver > we'd probably just have them register them all with us and then incorporate > the list into the binary. I appreciate that this won't work well for many, > but as I said, this mechanism is targeted at quite a narrow use case. > > >> >>> >>>> CNAME does not provide useful necessary >>>> parameters that may also be useful for a >>>> DoH resolver DRDP lists among others: >>>> alpn, ensiconfig, uri template, user >>>> display, auth_domain, filtering, >>>> ip_subnet, dnssec, .... >>>> >>>> My understanding is that BCP 17 saw SRV >>>> as a long term solution for CNAME which >>>> is now superseded by HTTPSVC/SVCB. I see >>>> SRV as very common in home networks with >>>> service discovery. >>>> >>>> I believe that using a generic is >>>> problematic as is prevents its resoltion >>>> to be secured with DNSSEC. >>>> >>> >>> As I said earlier, this goes back to threat model. Please describe the >>> thrat model where you think DNSSEC helps. >>> >> >> The threat model seems for Comcast and the end user having the traffic of >> its end users being redirected to Cloudflare instead of the local resolver. >> Both resolvers are trusted according to Firefox but the end user and the >> ISP may have a different view. It also means that any information that is >> not preconfigured cannot be trusted. >> > > Well, I agree that this attack is possible (and is described in S 4) but I > don't see how DNSSEC prevents it. It's true that if the user is on a > network operated by "example.com" DNSSEC could be used to secure the > information that "example.com" wants you to use a given resolver, but the > problem is that the user has no secure way of discovering that they are on " > example.com", and therefore the attacker can just substitute in their own > domain there. > If the lookup takes as input the IP addresses or something provided by the ISP (like the local resolver IP address), the resulting chain is likely to be from the ISP. DNSSEC is needed to assert it. Another way would be to be able to display example.com. The user should be able to see how the domain is associated to the ISP it has subscribed to or if it is being redirected to a cloud provider. DNSSEC would make sur the corresponding IP address - as well as other information - are bound to the displayed domain. > > I could of course be wrong about this. If you believe I am, I would > encourage you to describe the entire discovery chain and where you believe > DNSSEC acts to prevent attack. > > -Ekr > > -- Daniel Migault Ericsson --0000000000003d2de105a9447269 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 29, 2020 at 9:15 PM Eric = Rescorla <ekr@rtfm.com> wrote:
<= div dir=3D"ltr">

On Mon, Jun 29, 2020 at 5:43 PM Daniel Migault <mglt.ietf@gmail.com> wrote:


On Mon, Jun 29, 2020 at 7:15 PM Eric Res= corla <ekr@rtfm.com> wrote:


On Mon, Jun 29, 2020 at 2:40 PM Daniel M= igault <mglt.ie= tf@gmail.com> wrote:
Hi,=C2=A0

I believe the proposal presents some
similarities to draft-mglt-d= rdp [1] that is
using the DNS to proceed to the
discovery. I see drdp= as more generic,
and would be happy to improve it.

I would be h= appy to understand why HTTP
is a better stack to perform the
discover= as opposed to DNS. I think that
DNS is better as it is the common
pr= otocol to DoT DoH and DNS, but I might
be missing something. =C2=A0
<= /div>

I don't quite follow this, = as we do not use HTTP.
I thought you wer= e saying using HTTPSSVC=C2=A0was architecturally better -=C2=A0that was sec= tion 5 not=C2=A04.=C2=A0=C2=A0

Well, S 5 is an empty IANA Considerations section.
<= /blockquote>
that was section 5 of adns=C2=A0
<= div>
In any case, I don't really have a position on wheth= er HTTPSVC is better. The text says it "may be" the right answer = eventually.


I believe that CNAME is to restrictive
and would not = make possible for example
to have multiple resolvers

This goes back to use case. In our use case, the m= ultiple resolvers would be supplied by manual configuration of the client. = the CNAME is just a lookup key.

Unless=C2=A0I am missing something, I do not see how the ISP could r= espond saying and provide the application a resolver that implements DoH, a= resolver that implement DoTs, a resolver that implements DoH and DNSSEC va= lidation and let the application pick the one it prefers.=C2=A0

That's correct. As I said, that= 's not part of our use case, because we're only trying to determine= which network you are on and then look up the resolvers in our TRR list. I= f we expected ISPs to have >1 kind of resolver we'd probably just ha= ve them register them all with us and then incorporate the list into the bi= nary. I appreciate that this won't work well for many, but as I said, t= his mechanism is targeted at quite a narrow use case.

=C2=A0=C2=A0
CNAME does not provide useful necessary
parameters that may also be us= eful for a
DoH resolver DRDP lists among others:
alpn, ensiconfig, ur= i template, user
display, auth_domain, filtering,
ip_subnet, dnssec, = ....

My understanding is that BCP 17 saw SRV
as a long term solu= tion for CNAME which
is now superseded by HTTPSVC/SVCB. I see
SRV as = very common in home networks with
service discovery. =C2=A0

I be= lieve that using a generic is
problematic as is prevents its resoltionto be secured with DNSSEC.

As I said earlier, this goes back to threat model. Please describe the th= rat model where you think DNSSEC helps.
=
The threat model seems for Comcast and the end user having t= he traffic of its end users being redirected to Cloudflare instead of the l= ocal resolver. Both resolvers are trusted according to Firefox but the=C2= =A0end user and the ISP may have a different=C2=A0view. It also means that = any information that is not preconfigured cannot be trusted.

Well, I agree that this attack is = possible (and is described in S 4) but I don't see how DNSSEC prevents = it. It's true that if the user is on a network operated by "example.com" DNSSEC cou= ld be used to secure the information that "example.com" wants you to use a given resolv= er, but the problem is that the user has no secure way of discovering that = they are on "example.= com", and therefore the attacker can just substitute in their own = domain there.
If the lookup takes as inp= ut the IP addresses or something provided by the ISP (like the local resolv= er IP address), the=C2=A0resulting chain is likely to be from the ISP. DNSS= EC is needed to assert it. Another way would be to be able to display example.com. The user should be able to see h= ow the domain is associated to the=C2=A0ISP it has subscribed to or if it i= s being redirected to a cloud provider.=C2=A0 DNSSEC would make sur the=C2= =A0corresponding IP address - as well as other=C2=A0information - are bound= to the displayed domain.=C2=A0 =C2=A0 =C2=A0 =C2=A0

I could of course be wrong about this. If you believe= I am, I would encourage you to describe the entire discovery chain and whe= re you believe DNSSEC acts to prevent attack.

-Ekr=



--
Daniel Migault
Ericsson
--0000000000003d2de105a9447269-- From nobody Mon Jun 29 20:08:45 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF463A00B0 for ; Mon, 29 Jun 2020 20:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1VNA-XFV_Jp for ; Mon, 29 Jun 2020 20:08:41 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 D089F3A0064 for ; Mon, 29 Jun 2020 20:08:40 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id n23so20749644ljh.7 for ; Mon, 29 Jun 2020 20:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H6kd3bDj89/hWh+7wCgu/qudXUHaQRm4/5YhMrai7w0=; b=G5iLgap8hKnPkIZZaWs7aFBSPtgz0h1+SADSD7E3ufhvU8Jlby531Q+E3+P3/PZDJq 4mjtLwqZc429XGujPrf6jwuHf5ItIFLsUST57O8WBXrLPVuhwvvWZ2bvMDNiCwstoOwq ZI3mKEOOnVP+gsmcN0OA5T2Qs/FZATJeRasJf/wmBCKAZQPSuPkgyqt0ocqaak3SAL3/ 5lgeoWHzNaKzBmzB6OGVDX/4Zm7xJRpmuFbgfKTL1cVgklRWUEdpQnRdGpRCCmhPnDTl qaTiaRE0/Nc2OcIpfHgIkMlI5arnPbqMmLhVolLsz1J6IX90a/NrvWAAYWsYwT5mW4hA zBGw== 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:to:cc; bh=H6kd3bDj89/hWh+7wCgu/qudXUHaQRm4/5YhMrai7w0=; b=ldLxk3Fy7NeoCmRVEjP8OLVfjNdLdWKSxeq9T6YoXyLd24kQRzufWqpbKZLmSDeAVw mQcAKoVs+dSijY9wf/bRorQqKz/f1KqnL2gfsencTtZsaHA4gVSt2hgIDV+gjIaojzx4 IdGpk72Dh/TkekhadqcorGEMTx3llCOE0m2tpu2OHSAj87GrBqtm51jORPyFBOA1aLvW Nhf//dwdjPw49gHCiZV3erzNsjhLhAukM/F8CoX1KoOHYGMJs+63OrJsOQOrmk0fmfqo KHh8MEEaUaFTDQfAo1HYfI0rQ2dBGagXnEpuYrbb6mTpeBPSaFwChUwHGdKGWeCqkIzO jDcg== X-Gm-Message-State: AOAM532E9h4pnOUdITz8ZaDFoxlf+LbSZ45c6VucSQakD63d5XVGuC5r robUDkwZKRq75mc4mZb4OPBLVgqbaoRNPQFN76yYww== X-Google-Smtp-Source: ABdhPJwNzYuSVnITMggNlKwOKczOEQavUe+K6awpyHT7oIUUPtBllaPoKIrs8u6ykJbMQWywphE+IJ6HgaFUQl3IfGk= X-Received: by 2002:a05:651c:1044:: with SMTP id x4mr8975214ljm.409.1593486519084; Mon, 29 Jun 2020 20:08:39 -0700 (PDT) MIME-Version: 1.0 References: <14119.1593367594@localhost> <3615321.ADK9YsXCiF@linux-9daj> In-Reply-To: From: Eric Rescorla Date: Mon, 29 Jun 2020 20:08:02 -0700 Message-ID: To: Daniel Migault Cc: Paul Vixie , Michael Richardson , ADD Mailing list , John R Levine Content-Type: multipart/alternative; boundary="000000000000ecb73405a9447dcd" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 03:08:44 -0000 --000000000000ecb73405a9447dcd Content-Type: text/plain; charset="UTF-8" On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault wrote: > If the lookup takes as input the IP addresses or something provided by the > ISP (like the local resolver IP address), the resulting chain is likely to > be from the ISP. DNSSEC is needed to assert it. > Why do you assume that the IP is delivered securely? Another way would be to be able to display example.com. The user should be > able to see how the domain is associated to the ISP it has subscribed to or > if it is being redirected to a cloud provider. DNSSEC would make sur > the corresponding IP address - as well as other information - are bound to > the displayed domain. > At this point, why would I need DNSSEC? I could just use the WebPKI. -Ekr >> I could of course be wrong about this. If you believe I am, I would >> encourage you to describe the entire discovery chain and where you believe >> DNSSEC acts to prevent attack. >> >> -Ekr >> >> > > -- > Daniel Migault > Ericsson > --000000000000ecb73405a9447dcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 29, 2020 at 8:05 PM Danie= l Migault <mglt.ietf@gmail.com> wrote:
If the lookup takes as input = the IP addresses or something provided by the ISP (like the local resolver = IP address), the=C2=A0resulting chain is likely to be from the ISP. DNSSEC = is needed to assert it.



Another way would be to be able to= display example.com. = The user should be able to see how the domain is associated to the=C2=A0ISP= it has subscribed to or if it is being redirected to a cloud provider.=C2= =A0 DNSSEC would make sur the=C2=A0corresponding IP address - as well as ot= her=C2=A0information - are bound to the displayed domain.=C2=A0=C2=A0
<= /div>

At this point, why would = I need DNSSEC? I could just use the WebPKI.

-E= kr


I could of course be wrong about this. If you believe I am= , I would encourage you to describe the entire discovery chain and where yo= u believe DNSSEC acts to prevent attack.

-Ekr



--
Daniel Migault
Ericsson
--000000000000ecb73405a9447dcd-- From nobody Mon Jun 29 20:34:22 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E143A0A83 for ; Mon, 29 Jun 2020 20:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 szLab-IrLNIR for ; Mon, 29 Jun 2020 20:34:19 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 83E783A0A85 for ; Mon, 29 Jun 2020 20:34:19 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id w73so4581362ila.11 for ; Mon, 29 Jun 2020 20:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3LGrFves74LonerP75dHdSQGMb1jaFUrlwBCyKi4Vtw=; b=j8MxIlMKzlzDB4VW01tU5KGh3zKd4odZICudj7IK+eWcM3zwynL4KYCr/BgymJQw+t IvE50KpWEF4uukG3hKVV8u1D9KJI5uKz60KDv1TmaD6rL/RrC57DuzwuGEQnfs4cHj6m ei9s0xcXm91G6dfAKpyOwYt8Vi2Pxoroi47elOd+wqYzjJkSo4tMFPzCvqAm8a25C/mM jr7GRyyhXWKyeZdaSX1ZOaU8LjnThj2eEu/2RpXyzlqD1Uo33AE6m6spKiZAJzh9y7Cd HaIos8o6l40L49NO0Q5BRY0zC3WBTEMDsAqm1tV6UFR+rmOXoXOByY6+fiKRWtx64yuZ ioaA== 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:to:cc; bh=3LGrFves74LonerP75dHdSQGMb1jaFUrlwBCyKi4Vtw=; b=DJiU3J5zSHwUsvHQQ56QIHyG4LoQxyzPLVwYCaxC+LPu1hzjAHYoqzqkdW6xsUk/f5 otZYqsTTDb78X1FEkWC+O9w7JXgJehm6/o0NkpxMXoqk1r7oXUzJlc34L5aLMp6bDu47 Hp5sZBl+RznFaKyWMG/MW+BdzKwYhlnez39PvLjHmjFKvmthkjImgdLbxj/O6Wp1WJNg RV20hwJ+tkMsCH5ykjmMNdhAYIiz49NShrhlbzU6JCLeR3OMyi8x+s6FLofeDjDLPLFA IPhOPhYY4eEp67Aqtb88OsUQrrjpy/onWQhBdt1PcBPS2BFmLFDIfwv+d/f6ycihNQ+D 1/ng== X-Gm-Message-State: AOAM530AKq71BTzxJAmMJPh/GzO7hx9CPwjrkDuNnGBLPGuKlYr8ScKp wNMku4y3ozph4PrLpHyKSng37NuCURVNJ3vUJuFhtH4ool4= X-Google-Smtp-Source: ABdhPJxb9OcY9qPHc8wV/mCT6L75L6k0Owk+x1ozDIrWUBUN00sAmk3wUmIzXuOur5MlJlG7oKRa2HKCNp07SwRV4e0= X-Received: by 2002:a05:6e02:8b4:: with SMTP id a20mr688076ilt.254.1593488058472; Mon, 29 Jun 2020 20:34:18 -0700 (PDT) MIME-Version: 1.0 References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> In-Reply-To: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> From: Rob Sayre Date: Mon, 29 Jun 2020 20:34:04 -0700 Message-ID: To: "Livingood, Jason" Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000addc1105a944d9b2" Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 03:34:21 -0000 --000000000000addc1105a944d9b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2020 at 8:37 AM Livingood, Jason < Jason_Livingood@comcast.com> wrote: > Just noting far we have a variety of suggestions on CNAME, URI, TXT, > RESINFO and HTTPSSVC (though I don=E2=80=99t think all have I-Ds as yet) = - always > nice to see the ideas flowing. :-) As a practical person that in IETF lan= d > is considered an implementer, I naturally feel inclined towards RR types > that already exist as this enables something to be rapidly deployed. > TXT was used for ESNI/ECH draft -02. It only took ten or twelve lines of code to get the value out of a DNS response, but it felt hacky, in the pejorative sense. It seemed unlikely that a large number of server implementations would encode the data in the same way. thanks, Rob --000000000000addc1105a944d9b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 29, 2020 at 8:37 AM Livingood= , Jason <Jason_Livingood@comcast.com> wrote:
Ju= st noting far we have a variety of suggestions on CNAME, URI, TXT, RESINFO = and HTTPSSVC (though I don=E2=80=99t think all have I-Ds as yet) - always n= ice to see the ideas flowing. :-) As a practical person that in IETF land i= s considered an implementer, I naturally feel inclined towards RR types tha= t already exist as this enables something to be rapidly deployed.

TXT was used for ESNI/ECH draft -02. It only too= k ten or twelve lines of code to get the value out of a DNS response, but i= t felt hacky, in the pejorative=C2=A0sense.

It see= med unlikely that a large number of server=C2=A0implementations would encod= e the data in the same way.

thanks,
Rob<= /div>

--000000000000addc1105a944d9b2-- From nobody Mon Jun 29 23:02:26 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E56A3A0B4C for ; Mon, 29 Jun 2020 23:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 SfGQ7vTTFzO7 for ; Mon, 29 Jun 2020 23:02:24 -0700 (PDT) Received: from hexakaideca.sudo.sh (hexakaideca.sudo.sh [198.177.251.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9AE3A0B47 for ; Mon, 29 Jun 2020 23:02:23 -0700 (PDT) Received: by hexakaideca.sudo.sh (Postfix, from userid 1000) id 1E8E9EFE7F; Tue, 30 Jun 2020 06:02:23 +0000 (UTC) Date: Tue, 30 Jun 2020 06:02:23 +0000 From: dagon To: Michael Richardson Cc: Paul Vixie , ADD Mailing list Message-ID: <20200630060223.GA31540@sudo.sh> References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> <26559974.PdTMpzyJZD@linux-9daj> <18350.1593475069@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18350.1593475069@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 06:02:25 -0000 On Mon, Jun 29, 2020 at 07:57:49PM -0400, Michael Richardson wrote: > I'm with Paul. I prefer creating new RR types. > There aren't that many dumbass middleboxes around, and those that are there, > are usually put there intentionally, and they deserve what they get. +1 Middleware ignoring RFC 3597 has a privacy benefit: it won't leak the local DNS discovery details. A marginal DNS appliance, unable to process RESINFO and other inherently local, policy-based novel types, won't pass such traffic to 3d parties. E.g., ancient Cisco PIX will drop IN RESINFO?, failing the user back to udp/53. But such middleware could pass TXT-based discovery, sharing the local DoH policies. It also announces to the outside "oh look, someone just started a browser". Further, firewall operators must parse and ponder the global vs. local significance of such TXT records. Their solutions won't be consistent, creating a new generation of quirked gear. Could the draft (perhaps off the ADD list) provide advice for transit, firewalls and middleware witnessing such local discovery? Silently drop? ICMP? SERVFAIL? This is in contrast to DNSSEC, often dropped by broken middleware. DNSSEC conversations generally have global and e2e utility, since each hop and even appliances can validate. DoH discovery is local, and best dropped by non-speakers. -- David Dagon dagon@sudo.sh D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 From nobody Tue Jun 30 00:51:47 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7D13A10DA for ; Tue, 30 Jun 2020 00:51:46 -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, SPF_HELO_NONE=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 my3ScvhB3RD9 for ; Tue, 30 Jun 2020 00:51:45 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C903A0FD8 for ; Tue, 30 Jun 2020 00:51:45 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:5d52:d153:4eaa:f6b] (unknown [IPv6:2001:559:8000:c9:5d52:d153:4eaa:f6b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C399FB0588; Tue, 30 Jun 2020 07:51:42 +0000 (UTC) To: Eric Rescorla Cc: Daniel Migault , Michael Richardson , ADD Mailing list , John R Levine References: <14119.1593367594@localhost> <3615321.ADK9YsXCiF@linux-9daj> From: Paul Vixie Message-ID: Date: Tue, 30 Jun 2020 00:51:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.21 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 07:51:46 -0000 i wasn't speaking, but i was addressed, so i will attempt an answer. Eric Rescorla wrote on 2020-06-29 20:08: > > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault > wrote: > > If the lookup takes as input the IP addresses or something provided > by the ISP (like the local resolver IP address), the resulting chain > is likely to be from the ISP. DNSSEC is needed to assert it. > > Why do you assume that the IP is delivered securely? because dnssec allows me to verify end-to-end authenticity of name/address bindings (and other dns content.) while tls and ssh and gssapi add a useful second layer of end-to-end identify verification, those are not the only protocols i use. > Another way would be to be able to display example.com > . The user should be able to see how the domain > is associated to the ISP it has subscribed to or if it is being > redirected to a cloud provider.  DNSSEC would make sur > the corresponding IP address - as well as other information - are > bound to the displayed domain. > > At this point, why would I need DNSSEC? I could just use the WebPKI. dns has always been used by protocols outside the web, and will always be used by protocols outside the web. but even in your web use case, there will always be uri schemes which lack end-to-end identity verification. some current examples can be found here: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml the web is a fish. the internet is a pond. -- P Vixie From nobody Tue Jun 30 02:08:09 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746863A111A for ; Tue, 30 Jun 2020 02:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=lowentropy.net header.b=EfJP4WOV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nbdedrjf 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 oF1qF-Mf1pyL for ; Tue, 30 Jun 2020 02:08:06 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD3E3A10D9 for ; Tue, 30 Jun 2020 02:08:06 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 95F24825 for ; Tue, 30 Jun 2020 05:08:04 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 30 Jun 2020 05:08:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=oMS3a gvWtanOeLuBM1Jni2cfRi26S9k5eT/1gpXx0E0=; b=EfJP4WOVuQN7CR412WGPL D6M7ufPrMiG7Z8WfqIoW3SLSdYiTLROGqO8Vy+jW2YV26Z7UyemfswsmUYkRV6Du qGaJ2u5yrT4wf6cf7H6ZAx/oMytzK2LGV/RLKVOOWQMowUQGso7MM73jUoNDkCvb QKdvnAVRd8AEMehpvWUXYs3xoZ76Xk5V/pLSVljJu+X0d0Ky97eKHOLpGZ+b95O8 TJOkkP54vSKRjZGggQ22nIbAWFhyGpH9nbfu8aj0MyVxmXCJXn5M0oU40ILFaxad RYVqtqm3VyvY9IcuwqpxZPmXHG51zbdt/m6kTPwWZwm4f1J/72WXlNYCAlgKU3jD w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=oMS3agvWtanOeLuBM1Jni2cfRi26S9k5eT/1gpXx0 E0=; b=nbdedrjfvJvDvLK9VYjCvJm/4Twz8mFSvZlv17z+DDF5U5S7ghmaILuMR AA2gFiTAMXKTFbbwW1jTkiTIZIvSxS9Or4x27BawPBFnX+OP32LMXuP7yxRN1Qbs Tc7178K/nC1seXLEAK79nOzQHTVfkxBL26d+nRLFe+SVC+tQtqi6uXAG+x/rtwKM gUwmdka913fopd/81qGFBdpWz9CGjk9BcAdUlK9bpwLXwFHv25yzCmyGxPcmYsBW qjzFGdou3+Qx9n0fVGu5WaFSrpcR7vLbINx9Y6v7x/mHsyfkxyOG171tshc1ryaz z5cH2DK1muWMQtJvDlADAF7+CvEqg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvddtuddgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgfejueduieffledtge elheejvdettdejudduhefggeefgfekgfeuieetgefftddtnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F2131E00E3; Tue, 30 Jun 2020 05:08:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668 Mime-Version: 1.0 Message-Id: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> In-Reply-To: References: <14119.1593367594@localhost> <3615321.ADK9YsXCiF@linux-9daj> Date: Tue, 30 Jun 2020 19:07:43 +1000 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 09:08:07 -0000 Hi Paul, On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote: > Eric Rescorla wrote on 2020-06-29 20:08: > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault > > wrote: > >=20 > > If the lookup takes as input the IP addresses or something provi= ded > > by the ISP (like the local resolver IP address), the=C2=A0result= ing chain > > is likely to be from the ISP. DNSSEC is needed to assert it.=20 > >=20 > > Why do you assume that the IP is delivered securely? >=20 > because dnssec allows me to verify end-to-end authenticity of=20 > name/address bindings (and other dns content.)=20 DNSSEC allows you to be sure of the veracity of what comes from DNSSEC, = but in this case the IP address didn't come from DNSSEC. It's not DNS c= ontent. From nobody Tue Jun 30 02:19:24 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B533A1129 for ; Tue, 30 Jun 2020 02:19:23 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrAkZ5IM-FO7 for ; Tue, 30 Jun 2020 02:19:21 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11FF3A112B for ; Tue, 30 Jun 2020 02:19:21 -0700 (PDT) Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 881C4B0588 for ; Tue, 30 Jun 2020 09:19:19 +0000 (UTC) From: Paul Vixie To: add@ietf.org Date: Tue, 30 Jun 2020 09:19:18 +0000 Message-ID: <3421779.8U4dVgcHlH@linux-9daj> Organization: none In-Reply-To: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 09:19:23 -0000 On Tuesday, 30 June 2020 09:07:43 UTC Martin Thomson wrote: > Hi Paul, > > On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote: > > Eric Rescorla wrote on 2020-06-29 20:08: > > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault > > > > > > wrote: > > > If the lookup takes as input the IP addresses or something provided > > > by the ISP (like the local resolver IP address), the resulting chain > > > is likely to be from the ISP. DNSSEC is needed to assert it. > > > > > > Why do you assume that the IP is delivered securely? > > > > because dnssec allows me to verify end-to-end authenticity of > > name/address bindings (and other dns content.) > > DNSSEC allows you to be sure of the veracity of what comes from DNSSEC, but > in this case the IP address didn't come from DNSSEC. It's not DNS content. i have badly misunderstood. the way i know that the ip address provided by the isp was delivered securely today is because off-net DHCP forgery is hard, or because their technician programmed it into my edge gateway, or their customer service department printed it on my welcome letter. but i didn't want to interpret the question in that way because my answer would sound silly, even to me. i apologize for my confusion. --- moving on, what i'd love to have is SDNCP rather than DHCP. S=secure, N=network. because i want to know i'm getting what the operator of the network wants me to get, and because there are other parameters besides RDNS that i care about, such as whether there's a mandatory HTTPS or HTTP/3 proxy i will have to talk to. because, IoT. if DHCP isn't useful because it's not secure, we should stop using it. but before we could do that, we'd have to meet its functionality in another way. i realize that i've identified an unmarketable general case which has got to sound like i want to boil the ocean, or boil frogs, or something. but i figure if i don't say something, then after we've consensed around a secure RDNS discovery protocol, and somebody says what about all these other parameters that also have to be set by the network operator and have to be authenticated, we won't know how we got there. i'd like setting up an IoT device to be like bluetooth pairing, only, secure. like, enter a four-digit PIN or something. getting secure RDNS configuration should be like that. right now it's a welcome letter printed by my ISP, and that seems outdated. -- Paul From nobody Tue Jun 30 04:10:12 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BB63A11A4 for ; Tue, 30 Jun 2020 04:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 N-1ED-IdbVsK for ; Tue, 30 Jun 2020 04:10:09 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 A04B63A11A2 for ; Tue, 30 Jun 2020 04:10:09 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id x9so17346901ila.3 for ; Tue, 30 Jun 2020 04:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r5+D1tkzXfYgZgzBzazfzj0CH9XCya3bMbM+cyv8Igg=; b=bb7hM9RkxwiQ5HOWyQkBxubssLZjfn4/Tn6YOQe+QqFpNqBY1tTlCmcIO3rJeSCgta 4sXgI6gI97NLjVc1PnUg4X6IzWnFIrIozWj3t0uTS0HNe7hKFMUtGBN2C7PD8kslgViC d1topRiQnLojIscl+tPXP3D5KpO/8DF0Vflrp4JutrxdwiGxiyxdVZ+hRL2dJ8JxpSbO ZUs2em/i+vjQS7lmVCsUrDcPhOpI/imYItmK1UqGkKRKOzPT10J+7Lsd/983UyxSz19H CQx5yJAq3WkOmqzOunSd1R0sRhfM/Bay+rYGblG9rCL7Uzoz10hsllKnwXpYv6FxUEfo 4iUg== 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:to:cc; bh=r5+D1tkzXfYgZgzBzazfzj0CH9XCya3bMbM+cyv8Igg=; b=Hd/PrbVKAEP9ta4lVgsSyXmhXuHDweAu1IcgVv/uoE7MywHxnon4I1BpabgtniArLY f2vTFChY9MT6PjXVObzI8UPeGHuDVhn6xWKZ2lhX08xQ4dPAwrsfcnJt1KxuSplfJD+8 8f+T4CBM6E72SfythkCfIDAsUBVAxa4Igm+qFdIOvoL1pV0KJXWYymsDqOPfXUOjtU+4 mWGMg49pkVcr2mjT0BI7W521pgCHsOr6MwZvFT3n1x8jdjiqg2PyA+bXLHicnGaMhWOs lgdUDSZ6CH4q6/UMjnMSanD+ve/erTqpWBvwqjXg1PztZS1ZdK6Q+MhICcRAuUhbog9W EvBQ== X-Gm-Message-State: AOAM5328k+ShBWg2kJKiuk/Hk8GDgmhe8TuMDzQiUKy9OZZsXA7Y9vqf zUYwybLe4jtTVESCD9HwYyo6/xKXNNblkCBmS6whyWAmh1wVLw== X-Google-Smtp-Source: ABdhPJxaFladux9NFnxgzP1Reu9AJQ7aEuQv617QVEwrASkEhOY6IQ9dIUcciXGu8UM6saz/h8BuDXlj87UJZ7GfgvA= X-Received: by 2002:a92:cf09:: with SMTP id c9mr1963421ilo.214.1593515408901; Tue, 30 Jun 2020 04:10:08 -0700 (PDT) MIME-Version: 1.0 References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> <26559974.PdTMpzyJZD@linux-9daj> <18350.1593475069@localhost> <20200630060223.GA31540@sudo.sh> In-Reply-To: <20200630060223.GA31540@sudo.sh> From: tirumal reddy Date: Tue, 30 Jun 2020 16:39:57 +0530 Message-ID: To: dagon Cc: Michael Richardson , ADD Mailing list , Paul Vixie Content-Type: multipart/alternative; boundary="000000000000e44b8705a94b37f8" Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 11:10:11 -0000 --000000000000e44b8705a94b37f8 Content-Type: text/plain; charset="UTF-8" On Tue, 30 Jun 2020 at 11:32, dagon wrote: > On Mon, Jun 29, 2020 at 07:57:49PM -0400, Michael Richardson wrote: > > > I'm with Paul. I prefer creating new RR types. > > There aren't that many dumbass middleboxes around, and those that are > there, > > are usually put there intentionally, and they deserve what they get. > > +1 > > Middleware ignoring RFC 3597 has a privacy benefit: it won't leak the > local DNS discovery details. A marginal DNS appliance, unable to > process RESINFO and other inherently local, policy-based novel types, > won't pass such traffic to 3d parties. > The BCP document https://tools.ietf.org/html/bcp152#section-4.3 says DNS forwarders on home routers MUST proxy unknown RR types. > > E.g., ancient Cisco PIX will drop IN RESINFO?, failing the user back > to udp/53. But such middleware could pass TXT-based discovery, > sharing the local DoH policies. It also announces to the outside "oh > look, someone just started a browser". > > Further, firewall operators must parse and ponder the global vs. local > significance of such TXT records. Their solutions won't be > consistent, creating a new generation of quirked gear. Could the > draft (perhaps off the ADD list) provide advice for transit, firewalls > and middleware witnessing such local discovery? Silently drop? ICMP? > SERVFAIL? > > This is in contrast to DNSSEC, often dropped by broken middleware. > DNSSEC conversations generally have global and e2e utility, since each > hop and even appliances can validate. DoH discovery is local, and > best dropped by non-speakers. > > -- > David Dagon > dagon@sudo.sh > D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000e44b8705a94b37f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 30 Jun 2020 at 11:32, dagon &= lt;dagon@sudo.sh> wrote:
On Mon, Jun 29, 2020 at 07:57:49PM -0400, Michael Richardson wr= ote:

> I'm with Paul. I prefer creating new RR types.
> There aren't that many dumbass middleboxes around, and those that = are there,
> are usually put there intentionally, and they deserve what they get.
+1

Middleware ignoring RFC 3597 has a privacy benefit: it won't leak the local DNS discovery details.=C2=A0 A marginal DNS appliance, unable to
process RESINFO and other inherently local, policy-based novel types,
won't pass such traffic to 3d parties.

<= div>The BCP document=C2=A0https://tools.ietf.org/html/bcp152#section-4.3=C2=A0says DNS = forwarders on home routers MUST proxy unknown RR types.
=C2= =A0

E.g., ancient Cisco PIX will drop IN RESINFO?, failing the user back
to udp/53.=C2=A0 But such middleware could pass TXT-based discovery,
sharing the local DoH policies.=C2=A0 It also announces to the outside &quo= t;oh
look, someone just started a browser".

Further, firewall operators must parse and ponder the global vs. local
significance of such TXT records.=C2=A0 Their solutions won't be
consistent, creating a new generation of quirked gear.=C2=A0 Could the
draft (perhaps off the ADD list) provide advice for transit, firewalls
and middleware witnessing such local discovery?=C2=A0 Silently drop? ICMP?<= br> SERVFAIL?

This is in contrast to DNSSEC, often dropped by broken middleware.
DNSSEC conversations generally have global and e2e utility, since each
hop and even appliances can validate.=C2=A0 DoH discovery is local, and
best dropped by non-speakers.

--
David Dagon
dagon@sudo.sh
D970 6D9E E500 E877 B1E3=C2=A0 D3F8 5937 48DC 0FDC E717

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000e44b8705a94b37f8-- From nobody Tue Jun 30 04:15:57 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F093A0C30 for ; Tue, 30 Jun 2020 04:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 A0Ae1nLbD_Xg for ; Tue, 30 Jun 2020 04:15:53 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 B2D913A0C1F for ; Tue, 30 Jun 2020 04:15:53 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id t27so12359883ill.9 for ; Tue, 30 Jun 2020 04:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DsVrJ1H/hOHPyRYVyv/Un9X+JmQest8CNroIrZE0mtg=; b=g1TMtp4BF1/I2uc8LBolX8F0AUkiG6hcpbpXmeqUbfr++T5ViapCHBXehypSedf+Sw v4v6H2pbxIDspZ+rxar7G9vY1uES62I03jhQDJ8RMtpccYBC3HaYSz2EiG4+VUTfyUNa 9oocDbZjFzNaXplTpxxwi2AFDTYZHnKuNfNEztqV2Cgv/Whangu/ntsTbw8PD+gwH5Lp 3RBStArojuHZ+JdmbIKEx9ZwqAG2O9CGAsVOF8o72dj3zcKYDSoae7d6GDDgQfNF3lyZ zGU68VR0pgkSFBvvjC9+AsiVyK9aRMob/p5zKSDzdY1XVnLh4aG8xvW3ynXPCxgIrQkW PrVg== 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:to:cc; bh=DsVrJ1H/hOHPyRYVyv/Un9X+JmQest8CNroIrZE0mtg=; b=dzc2fRpncpGgzaotirqHYCTn4j+ahX03MVCUL/Jca7j3C/N+JFV7t66Cr4nfczou9J JwwhvvoXegmBgs57VlguUZNhZdJmubv0I02Xn1XcXh7a5Z0riVDrNQ2lFbyrV9TGghxA hAT1Awu8Nu/IW6a5b3YWzW2RyY2FjECzblFzEXD63CEK/OvxZ3vRXpHuu+kms+dOTMnt CsIYHaaGOkt8aGk3p9dyvIwdc/fMvBKEVjTxwEK+1Cd/ZGjnEHTFpk+QmB77LNa7uYo+ sg7Q2CpSElIGQDTCJproQx1QM8I2XNAmLP0RZ4tiD38vAbLIKFOhPCGFfP696GnSql59 tmRw== X-Gm-Message-State: AOAM533dcWAQvEkEbcTdyzxuWe51RLfzVofHpJR+W9Pxfu0rGPJKos/n cCgLr5hZytnQGgU1E7hpHpJcSvpiqi6u04TK1LxaAncoeCk= X-Google-Smtp-Source: ABdhPJymtIg5zJnzzDoyC/fCvWLMpyVvh16R8fXx0VCYj6Ph3fKZBsVT41Bd+oy8J+JURY5A5Ou8ItGVS+fssRbOGgU= X-Received: by 2002:a92:15d3:: with SMTP id 80mr2068387ilv.195.1593515753008; Tue, 30 Jun 2020 04:15:53 -0700 (PDT) MIME-Version: 1.0 References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> In-Reply-To: From: tirumal reddy Date: Tue, 30 Jun 2020 16:45:41 +0530 Message-ID: To: Rob Sayre Cc: "Livingood, Jason" , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000066f2dc05a94b4ca3" Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 11:15:55 -0000 --00000000000066f2dc05a94b4ca3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 30 Jun 2020 at 09:04, Rob Sayre wrote: > On Mon, Jun 29, 2020 at 8:37 AM Livingood, Jason < > Jason_Livingood@comcast.com> wrote: > >> Just noting far we have a variety of suggestions on CNAME, URI, TXT, >> RESINFO and HTTPSSVC (though I don=E2=80=99t think all have I-Ds as yet)= - always >> nice to see the ideas flowing. :-) As a practical person that in IETF la= nd >> is considered an implementer, I naturally feel inclined towards RR types >> that already exist as this enables something to be rapidly deployed. >> > > TXT was used for ESNI/ECH draft -02. It only took ten or twelve lines of > code to get the value out of a DNS response, but it felt hacky, in the > pejorative sense. > TXT has been misused by malware to exfiltrate data and to send C&C traffic. -Tiru > > It seemed unlikely that a large number of server implementations would > encode the data in the same way. > > thanks, > Rob > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000066f2dc05a94b4ca3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 30 Jun 2020 at 09:04, Rob Sayre &= lt;sayrer@gmail.com> wrote:
<= /div>
On Mon, Jun 29, 2020 at 8:37 AM Li= vingood, Jason <Jason_Livingood@comcast.com> wrote:
Just noting far we have a variety of suggestions on CNAME, URI, TXT, R= ESINFO and HTTPSSVC (though I don=E2=80=99t think all have I-Ds as yet) - a= lways nice to see the ideas flowing. :-) As a practical person that in IETF= land is considered an implementer, I naturally feel inclined towards RR ty= pes that already exist as this enables something to be rapidly deployed.

TXT was used for ESNI/ECH draft -02. It o= nly took ten or twelve lines of code to get the value out of a DNS response= , but it felt hacky, in the pejorative=C2=A0sense.
<= /blockquote>

TXT has been misused by malware to exfiltra= te data and to send C&C traffic.

-Tiru
=C2=A0

It= seemed unlikely that a large number of server=C2=A0implementations would e= ncode the data in the same way.

thanks,
= Rob

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000066f2dc05a94b4ca3-- From nobody Tue Jun 30 05:49:44 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B71B3A07B7 for ; Tue, 30 Jun 2020 05:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 SYazGZyDa7OX for ; Tue, 30 Jun 2020 05:49:39 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 7DAE63A07B1 for ; Tue, 30 Jun 2020 05:49:39 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id m25so11109574vsp.8 for ; Tue, 30 Jun 2020 05:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/TUjJwvCU4yf0+022uaZHY4e/U0Z6L64bbkcO1w9790=; b=hTEBgnCjFMBU8efubo/cPGrTm3/XtYZfZzCLAbQFpBEQWjct2JenoXp6La5SZK8gG0 /RPiI9UcJbm9qtOI0325cxeckQmYkxvMtDVSg730OrgQeOdulpbcoIG63FpmVZXmCW/u 3O3tNoOVH7h4VLBiAWLEjjxRJNoeQrj9iZUHFK+8Os5V2FeOjvsA30pet6oWBzVTLhkD n5AYiqkDL4juFMaGRP980Hty6NdA/UnwVMxsd9PC8I+jFYYzfgA7mYcID32Sqwua2Y+W +dVSIpwg/0g0Axke2z08bAqOwmGv2cBTgK3FZFVXUgMhiqRuHInJzonwMZSezA9E9yd7 vH3Q== 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:to:cc; bh=/TUjJwvCU4yf0+022uaZHY4e/U0Z6L64bbkcO1w9790=; b=ZT0xfNd+LaQ+JhFdbu93PMK/+vZnSe6xwHR8etThmtGOcfTBdqI//vGVpKwp2MAQp1 IiZobrhcjgkb3iFwO7u2qCn0wPG38ANEvojb4gk5Uge9kvMJ2Kdn6QnAWpHBg5SrLzMC eds07X1rsGJjvWIzCxoom24ul1jrq1/4nBMrN8M8kAMeKDX6rpdxZGCM1Bq3orwVXWkK KQeNmWdFIoSNxuxqL9cf9CjnQpJI6FaC8j3y8jxS5c79uRKCDqgvNrXYWAkZhCtwF4e6 i0uq+TD+4vj/rcwlN6evMKtddJegcKV48SqonRvduQO8E5lu+QH5rG4rL6aPicZG+dYr fKlw== X-Gm-Message-State: AOAM530/kzONhBwKY+55KoCxYzMQDl0T5XJW8autHOMUj4FVO4CCXTAl wg15fUdEVK0o5p8r0ZkZK4p5JuHuax29vTfvqKO9Dg== X-Google-Smtp-Source: ABdhPJx+Au1JwfFUPfZAMsa1yjeU0jGF5IIdp+cWpDMGtS5vAIWL/iWphTw8/eiIxIvcnVlCmeGpC/YH7F9BgFcYvcI= X-Received: by 2002:a67:7fd5:: with SMTP id a204mr13180260vsd.97.1593521378367; Tue, 30 Jun 2020 05:49:38 -0700 (PDT) MIME-Version: 1.0 References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> In-Reply-To: <3421779.8U4dVgcHlH@linux-9daj> From: Daniel Migault Date: Tue, 30 Jun 2020 08:49:27 -0400 Message-ID: To: Paul Vixie Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000b31bd205a94c9baf" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 12:49:42 -0000 --000000000000b31bd205a94c9baf Content-Type: text/plain; charset="UTF-8" Hi, My responses would have been inline with those of Paul. Yours, Daniel On Tue, Jun 30, 2020 at 5:19 AM Paul Vixie wrote: > On Tuesday, 30 June 2020 09:07:43 UTC Martin Thomson wrote: > > Hi Paul, > > > > On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote: > > > Eric Rescorla wrote on 2020-06-29 20:08: > > > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault > > > > > > > > wrote: > > > > If the lookup takes as input the IP addresses or something > provided > > > > by the ISP (like the local resolver IP address), the resulting > chain > > > > is likely to be from the ISP. DNSSEC is needed to assert it. > > > > > > > > Why do you assume that the IP is delivered securely? > > > > > > because dnssec allows me to verify end-to-end authenticity of > > > name/address bindings (and other dns content.) > > > > DNSSEC allows you to be sure of the veracity of what comes from DNSSEC, > but > > in this case the IP address didn't come from DNSSEC. It's not DNS > content. > > i have badly misunderstood. > > the way i know that the ip address provided by the isp was delivered > securely > today is because off-net DHCP forgery is hard, or because their technician > programmed it into my edge gateway, or their customer service department > printed it on my welcome letter. > > but i didn't want to interpret the question in that way because my answer > would sound silly, even to me. i apologize for my confusion. > > --- > > moving on, what i'd love to have is SDNCP rather than DHCP. S=secure, > N=network. because i want to know i'm getting what the operator of the > network > wants me to get, and because there are other parameters besides RDNS that > i > care about, such as whether there's a mandatory HTTPS or HTTP/3 proxy i > will > have to talk to. because, IoT. if DHCP isn't useful because it's not > secure, > we should stop using it. but before we could do that, we'd have to meet > its > functionality in another way. > > i realize that i've identified an unmarketable general case which has got > to > sound like i want to boil the ocean, or boil frogs, or something. but i > figure > if i don't say something, then after we've consensed around a secure RDNS > discovery protocol, and somebody says what about all these other > parameters > that also have to be set by the network operator and have to be > authenticated, > we won't know how we got there. > > i'd like setting up an IoT device to be like bluetooth pairing, only, > secure. > like, enter a four-digit PIN or something. getting secure RDNS > configuration > should be like that. right now it's a welcome letter printed by my ISP, > and > that seems outdated. > > -- > Paul > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > -- Daniel Migault Ericsson --000000000000b31bd205a94c9baf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

My responses would=C2=A0have = been inline with those of Paul.=C2=A0

Yours,=C2=A0=
Daniel

On Tue, Jun 30, 2020 at 5:19 AM Paul Vixie <paul@redbarn.org> wrote:
On Tuesday, 30 June 2020 09:07:43 U= TC Martin Thomson wrote:
> Hi Paul,
>
> On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote:
> > Eric Rescorla wrote on 2020-06-29 20:08:
> > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault <mglt.ietf@gmail.com > > >
> > > <mailto:mglt.ietf@gmail.com>> wrote:
> > >=C2=A0 =C2=A0 =C2=A0If the lookup takes as input the IP addre= sses or something provided
> > >=C2=A0 =C2=A0 =C2=A0by the ISP (like the local resolver IP ad= dress), the resulting chain
> > >=C2=A0 =C2=A0 =C2=A0is likely to be from the ISP. DNSSEC is n= eeded to assert it.
> > >
> > > Why do you assume that the IP is delivered securely?
> >
> > because dnssec allows me to verify end-to-end authenticity of
> > name/address bindings (and other dns content.)
>
> DNSSEC allows you to be sure of the veracity of what comes from DNSSEC= , but
> in this case the IP address didn't come from DNSSEC.=C2=A0 It'= s not DNS content.

i have badly misunderstood.

the way i know that the ip address provided by the isp was delivered secure= ly
today is because off-net DHCP forgery is hard, or because their technician =
programmed it into my edge gateway, or their customer service department printed it on my welcome letter.

but i didn't want to interpret the question in that way because my answ= er
would sound silly, even to me. i apologize for my confusion.

---

moving on, what i'd love to have is SDNCP rather than DHCP. S=3Dsecure,=
N=3Dnetwork. because i want to know i'm getting what the operator of th= e network
wants me to get, and because there are other parameters besides RDNS that i=
care about, such as whether there's a mandatory HTTPS or HTTP/3 proxy i= will
have to talk to. because, IoT. if DHCP isn't useful because it's no= t secure,
we should stop using it. but before we could do that, we'd have to meet= its
functionality in another way.

i realize that i've identified an unmarketable general case which has g= ot to
sound like i want to boil the ocean, or boil frogs, or something. but i fig= ure
if i don't say something, then after we've consensed around a secur= e RDNS
discovery protocol, and somebody says what about all these other parameters=
that also have to be set by the network operator and have to be authenticat= ed,
we won't know how we got there.

i'd like setting up an IoT device to be like bluetooth pairing, only, s= ecure.
like, enter a four-digit PIN or something. getting secure RDNS configuratio= n
should be like that. right now it's a welcome letter printed by my ISP,= and
that seems outdated.

--
Paul


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add


--
Daniel Migault
Ericsson
--000000000000b31bd205a94c9baf-- From nobody Tue Jun 30 05:58:44 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246083A07E0 for ; Tue, 30 Jun 2020 05:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6TlWHF-hcH6 for ; Tue, 30 Jun 2020 05:58:40 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 2C3523A07D7 for ; Tue, 30 Jun 2020 05:58:40 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id k15so11283386lfc.4 for ; Tue, 30 Jun 2020 05:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VS9FSvGxPbqrBJlv2CrFRh4YE6QpTM62AASYi4X+Aw4=; b=gPGC5aIJP3jemRWdqjSeCuZJF3d6Ii6l9OIjodI1sxHDIUufu699NZF1GgDvndFDiz HVFhJQJo9/WtKoT9i3V0V4CbtxUoaww27Gixqdr+cXZJzshgkCCa6ABaX7pzKo47/euu C7+6csbhC/LQ3IIm4OcV9j1muo7F0Btjb6Zq1jJTgiq4S6Yzq56xmR6e5dD4714DW37X ryi3zRwctMKMBNYxtLXbyXzRZBxsMcqPP2Ro3pz+T8fCZEfTJSTPG2qL69fOqUxHU9+L VSM2CY3MYtxxiap6DHk/s3brkzQ3+6smFwa0ApvHZ6vWSIfBxD9QrNvacOn4QbJL1hNZ srsA== 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:to:cc; bh=VS9FSvGxPbqrBJlv2CrFRh4YE6QpTM62AASYi4X+Aw4=; b=o9hFY15PdFH4OnlMRhk8HsVreqMB9WtoNzuz10hk2GlCdjZElr6A3SELllOMxKjFa3 bKKDhjq+QX+1rGMDcPy8EsK+J1X21D2kfINf8IMQnVELA6CXauTklzU0elgQ39O63cIf 5KPwAQRSZq6TzWrc4+R8JFCXf//P+tVMsN/ThjGrXuHjJ9oU4M/N/yp+Wi42ikHZdUO4 SQS+FmedGLLkjwjJS86iwjBzGOCMjZTtktEmdsAXJ/vn29NNASE8b4XsglirqbSp15Z4 2YUEAxUGdVLKTb3+9JBxnV0HF7vG+lqKgsljy3dJBSiqcixQD2x0sXjjfOaabNE6RniA Tjeg== X-Gm-Message-State: AOAM530jPzkQgI/UJZGe9skpz70EtJRhX6BwNdOUcBCzevEnRU3JAK9H WSbtN0ATnK/f0vbtdq5xwtnp2Yh3U7uyDgs8RuEGdm2pPJM= X-Google-Smtp-Source: ABdhPJzTSq3r2b7g9upDX7qRWo4AARqANkSur7YdLNyGSOlZAbaMEA2y1HN4Hzi3wXd2tuJLXv+5GdhpRN2AXM9OZOg= X-Received: by 2002:ac2:5f04:: with SMTP id 4mr11809995lfq.140.1593521918174; Tue, 30 Jun 2020 05:58:38 -0700 (PDT) MIME-Version: 1.0 References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> In-Reply-To: <3421779.8U4dVgcHlH@linux-9daj> From: Eric Rescorla Date: Tue, 30 Jun 2020 05:58:01 -0700 Message-ID: To: Paul Vixie Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000dff9fb05a94cbbad" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 12:58:43 -0000 --000000000000dff9fb05a94cbbad Content-Type: text/plain; charset="UTF-8" On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie wrote: > On Tuesday, 30 June 2020 09:07:43 UTC Martin Thomson wrote: > > Hi Paul, > > > > On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote: > > > Eric Rescorla wrote on 2020-06-29 20:08: > > > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault > > > > > > > > wrote: > > > > If the lookup takes as input the IP addresses or something > provided > > > > by the ISP (like the local resolver IP address), the resulting > chain > > > > is likely to be from the ISP. DNSSEC is needed to assert it. > > > > > > > > Why do you assume that the IP is delivered securely? > > > > > > because dnssec allows me to verify end-to-end authenticity of > > > name/address bindings (and other dns content.) > > > > DNSSEC allows you to be sure of the veracity of what comes from DNSSEC, > but > > in this case the IP address didn't come from DNSSEC. It's not DNS > content. > > i have badly misunderstood. > > the way i know that the ip address provided by the isp was delivered > securely > today is because off-net DHCP forgery is hard, Let's start here: I agree that off-net DHCP forgery is hard. However, once you assume that you are off-path, then Do53 interception is *also* hard. So for this to be useful you need an environment in which the attacker is able to attack Do53 but *not* to attack DHCP. What I'm asking for is for someone to define that threat model precisely so that we can design protocols that match it. moving on, what i'd love to have is SDNCP rather than DHCP. S=secure, > N=network. because i want to know i'm getting what the operator of the > network > wants me to get, and because there are other parameters besides RDNS that > i > care about, such as whether there's a mandatory HTTPS or HTTP/3 proxy i > will > have to talk to. because, IoT. if DHCP isn't useful because it's not > secure, > we should stop using it. but before we could do that, we'd have to meet > its > functionality in another way. > > i realize that i've identified an unmarketable general case which has got > to > sound like i want to boil the ocean, or boil frogs, or something. but i > figure > if i don't say something, then after we've consensed around a secure RDNS > discovery protocol, and somebody says what about all these other > parameters > that also have to be set by the network operator and have to be > authenticated, > we won't know how we got there. > > i'd like setting up an IoT device to be like bluetooth pairing, only, > secure. > like, enter a four-digit PIN or something. getting secure RDNS > configuration > should be like that. right now it's a welcome letter printed by my ISP, > and > that seems outdated. > This all sounds great. And when it was available, we could also use it to indicate which Do[HT] server you ought to use. The question I am addressing is what we ought to do in the interim. -Ekr > -- > Paul > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000dff9fb05a94cbbad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 30, 2020 at 2:19 AM Paul = Vixie <paul@redbarn.org> wrot= e:
On Tuesday, 3= 0 June 2020 09:07:43 UTC Martin Thomson wrote:
> Hi Paul,
>
> On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote:
> > Eric Rescorla wrote on 2020-06-29 20:08:
> > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault <mglt.ietf@gmail.com > > >
> > > <mailto:mglt.ietf@gmail.com>> wrote:
> > >=C2=A0 =C2=A0 =C2=A0If the lookup takes as input the IP addre= sses or something provided
> > >=C2=A0 =C2=A0 =C2=A0by the ISP (like the local resolver IP ad= dress), the resulting chain
> > >=C2=A0 =C2=A0 =C2=A0is likely to be from the ISP. DNSSEC is n= eeded to assert it.
> > >
> > > Why do you assume that the IP is delivered securely?
> >
> > because dnssec allows me to verify end-to-end authenticity of
> > name/address bindings (and other dns content.)
>
> DNSSEC allows you to be sure of the veracity of what comes from DNSSEC= , but
> in this case the IP address didn't come from DNSSEC.=C2=A0 It'= s not DNS content.

i have badly misunderstood.

the way i know that the ip address provided by the isp was delivered secure= ly
today is because off-net DHCP forgery is hard,

=
Let's start here:
I agree that off-net DHCP forgery is h= ard. However, once you assume that you are off-path, then Do53 interception= is *also* hard. So for this to be useful you need an environment in which = the attacker is able to attack Do53 but *not* to attack DHCP. What I'm = asking for is for someone to define that threat model precisely so that we = can design protocols that match it.


moving on, what i'd love to have is SDNCP rather than DHCP. S=3Dsecure,=
N=3Dnetwork. because i want to know i'm getting what the operator of th= e network
wants me to get, and because there are other parameters besides RDNS that i=
care about, such as whether there's a mandatory HTTPS or HTTP/3 proxy i= will
have to talk to. because, IoT. if DHCP isn't useful because it's no= t secure,
we should stop using it. but before we could do that, we'd have to meet= its
functionality in another way.

i realize that i've identified an unmarketable general case which has g= ot to
sound like i want to boil the ocean, or boil frogs, or something. but i fig= ure
if i don't say something, then after we've consensed around a secur= e RDNS
discovery protocol, and somebody says what about all these other parameters=
that also have to be set by the network operator and have to be authenticat= ed,
we won't know how we got there.

i'd like setting up an IoT device to be like bluetooth pairing, only, s= ecure.
like, enter a four-digit PIN or something. getting secure RDNS configuratio= n
should be like that. right now it's a welcome letter printed by my ISP,= and
that seems outdated.

This all sounds gr= eat. And when it was available, we could also use it to indicate which Do[H= T] server you ought to use.

The question I am addr= essing is what we ought to do in the interim.

-Ekr=


--
Paul


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000dff9fb05a94cbbad-- From nobody Tue Jun 30 06:17:46 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009973A0820 for ; Tue, 30 Jun 2020 06:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG_K_fcYZ-68 for ; Tue, 30 Jun 2020 06:17:43 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 F3B783A082F for ; Tue, 30 Jun 2020 06:17:42 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id di5so4296058qvb.11 for ; Tue, 30 Jun 2020 06:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ieJM6/a5LVW2G09sAC5Y7ujXGSjORwRueatjsv55nWY=; b=f1FVKjkUZT1dTXDrLGwxWOdMUKKUq5Z0mUftS0lyTa6nGHdwJCGRF3h4PjLOr1EO/K ck1uFQsrOeFFaqJqdTtqttFN3J53djo9gN1D6XUNes0cHsXgcM5a9/0+Gky+ClSxJStv f7KkkpsnKE1FRBMf4qjJJydJ14qhjVfb05FSZNsfw0CzxL/EiO61ttdQuw2aV9d0LSaJ kjtS2P/X1qoV4QZEQTl6McjL2TUP1Rn/CMG2bH2DhDB3bLqKgpqpFZ2CYeF0xbKBIarG YIe2HbjSG45+zJObmfh5EMsiGC9izuHm92gg3iHsD+wqTIamOAslwMC7aGEvJq6Pm5lq ex0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ieJM6/a5LVW2G09sAC5Y7ujXGSjORwRueatjsv55nWY=; b=b7ZE5yhr4KMeN8jb1kcrvfyjRruREwtR5xbl22/MsBvPOJqBLSF2C/VKbjRI/55rs5 XAD41cW8xaWFUbOOQj3O3uSx0BfWdcoqQxj/YVytN3pfScL807OcF6c7a5ilgWMBuDIb skUggJcHjA18hAzQ8XpLYRxOOuNgv32b2sXSHA88C7/1y6XKwyzJXi+Og7fRsmH9g1oU +JxvJ2WGEJiumG37Qa0F3J31Lv1qHXgS632z5IjDeSB8YT7E3lIxHclxN4YH3OpAuyBn jeqoWkt0K2aaqayYfldnnvmu67f0FPa3wtaKhrl03TrbFGl8FMm/U7+QI4AhT9YfujK/ F5ZA== X-Gm-Message-State: AOAM531cLg+dIByPLMIFeHf5+8pDBHNADSJBuPMgmab44aew+BX6PJs8 IkQkTfJ6nuwFLb0R6V0x3PhErScr3nI= X-Google-Smtp-Source: ABdhPJyeTDF6CIg8hm/kVXnTAKRLzK1eUr2cLRdtQxejquXkGZv1N3kZVoFQDZeq4UHwyJFDXTENiA== X-Received: by 2002:a0c:f681:: with SMTP id p1mr20081363qvn.2.1593523055539; Tue, 30 Jun 2020 06:17:35 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:fc09:ab84:afa:8495? ([2601:18b:300:36ee:fc09:ab84:afa:8495]) by smtp.gmail.com with ESMTPSA id f4sm2909813qtv.59.2020.06.30.06.17.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2020 06:17:34 -0700 (PDT) From: Ted Lemon Message-Id: <6EC5A247-F873-4B0C-9773-E708D3B6AC77@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0C7E175F-BC18-40C9-AAF9-476DA97336D0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 30 Jun 2020 09:17:32 -0400 In-Reply-To: <3421779.8U4dVgcHlH@linux-9daj> Cc: add@ietf.org To: Paul Vixie References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 13:17:45 -0000 --Apple-Mail=_0C7E175F-BC18-40C9-AAF9-476DA97336D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 30, 2020, at 5:19 AM, Paul Vixie wrote: > moving on, what i'd love to have is SDNCP rather than DHCP. S=3Dsecure,=20= > N=3Dnetwork. because i want to know i'm getting what the operator of = the network=20 > wants me to get, and because there are other parameters besides RDNS = that i=20 > care about, such as whether there's a mandatory HTTPS or HTTP/3 proxy = i will=20 > have to talk to. because, IoT. if DHCP isn't useful because it's not = secure,=20 > we should stop using it. but before we could do that, we'd have to = meet its=20 > functionality in another way. We tried that. Unfortunately, what we found is that it just moves the = problem. Suppose you send out an SDNCP discovery request and get back = one or more signed responses. Which one do you choose? The answer is presumably that you choose the one you trust, but maybe = you don=E2=80=99t trust any of them. If you don=E2=80=99t trust any of = them, is it because you are on a foreign network, or because the = legitimate one(s) are being blocked? If you do trust one, why do you = trust it? How do you establish trust in something you haven=E2=80=99t = communicated with before? If you are able to set up a trust = relationship, why not just use that to authenticate 802.1x? Consider it from the other angle: suppose you just take what the network = gives you, but you want to know if it=E2=80=99s legitimate or spoofed. = How do you do _that_? Well, it turns out we know how. You validate with DNSSEC; if that = doesn=E2=80=99t work, you know your DNS server is lying to you. You = validate with PKI. If that doesn=E2=80=99t work, you know that your TLS = server is lying to you.=20 If you want to trust the network, use 802.1x. Use the fact that 802.1x = securely validated as an indication that you are on a trusted network, = and can trust what the infrastructure says to you at least enough to = bootstrap. If not, don=E2=80=99t trust anything the network tells = you=E2=80=94validate it, or don=E2=80=99t use it. And by the way, even = if 802.1x validates, that=E2=80=99s not at all a reason not to use = DNSSEC and TLS and PKI. Use them too. So all 802.1x really buys you is = that it=E2=80=99s harder for an on-link attacker to trick you into = wasting time validating stuff that won=E2=80=99t validate, which is = probably why it=E2=80=99s not more widely used. So the question is, what problem are you solving with SDNCP that isn=E2=80= =99t already solved with DNSSEC, TLS and PKI? The only answer we came up with is that it might be nice to be able to = know that we are speaking to the same operator we were last time. But we = didn=E2=80=99t actually identify a compelling use case for that, and = consequently the work was abandoned. --Apple-Mail=_0C7E175F-BC18-40C9-AAF9-476DA97336D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jun 30, 2020, at 5:19 AM, Paul Vixie <paul@redbarn.org> = wrote:
moving on, = what i'd love to have is SDNCP rather than DHCP. S=3Dsecure, 
N=3Dnetwork. = because i want to know i'm getting what the operator of the network 
wants me to = get, and because there are other parameters besides RDNS that i 
care about, = such as whether there's a mandatory HTTPS or HTTP/3 proxy i will 
have to talk = to. because, IoT. if DHCP isn't useful because it's not secure, 
we should = stop using it. but before we could do that, we'd have to meet its 
functionality = in another way.

We tried that. Unfortunately, what we found is that it just = moves the problem. Suppose you send out an SDNCP discovery request and = get back one or more signed responses. Which one do you = choose?

The = answer is presumably that you choose the one you trust, but maybe you = don=E2=80=99t trust any of them.  If you don=E2=80=99t trust any of = them, is it because you are on a foreign network, or because the = legitimate one(s) are being blocked?  If you do trust one, why do = you trust it?  How do you establish trust in something you = haven=E2=80=99t communicated with before? If you are able to set up a = trust relationship, why not just use that to authenticate = 802.1x?

Consider= it from the other angle: suppose you just take what the network gives = you, but you want to know if it=E2=80=99s legitimate or spoofed. How do = you do _that_?

Well, it turns out we know how. You validate with DNSSEC; if = that doesn=E2=80=99t work, you know your DNS server is lying to you. You = validate with PKI. If that doesn=E2=80=99t work, you know that your TLS = server is lying to you. 

If you want to trust the network, use = 802.1x. Use the fact that 802.1x securely validated as an indication = that you are on a trusted network, and can trust what the infrastructure = says to you at least enough to bootstrap. If not, don=E2=80=99t trust = anything the network tells you=E2=80=94validate it, or don=E2=80=99t use = it. And by the way, even if 802.1x validates, that=E2=80=99s not at all = a reason not to use DNSSEC and TLS and PKI. Use them too. So all 802.1x = really buys you is that it=E2=80=99s harder for an on-link attacker to = trick you into wasting time validating stuff that won=E2=80=99t = validate, which is probably why it=E2=80=99s not more widely = used.

So the = question is, what problem are you solving with SDNCP that isn=E2=80=99t = already solved with DNSSEC, TLS and PKI?

The only answer we came up with is that = it might be nice to be able to know that we are speaking to the same = operator we were last time. But we didn=E2=80=99t actually identify a = compelling use case for that, and consequently the work was = abandoned.

= --Apple-Mail=_0C7E175F-BC18-40C9-AAF9-476DA97336D0-- From nobody Tue Jun 30 06:44:12 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1703A086B for ; Tue, 30 Jun 2020 06:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 R0hckFmkdJzp for ; Tue, 30 Jun 2020 06:44:07 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 E39F43A0866 for ; Tue, 30 Jun 2020 06:44:06 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id k6so17708633ili.6 for ; Tue, 30 Jun 2020 06:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BBSc8RdB5lZnHfrHFX8ApXS9PvPuapNxWrP0Ozfq/z8=; b=JaTB7c3pgxc2+ujHy1czXhzvNcpy++uxmoGAXeR9xazTuVk61P2b4lE3sLckj44ggx 5G621tB9vQrt9l7Uc5y22sNQC7B9Zco+O4Yd6+L+3FkDVWL3PMLFJ3XkJW+oAQpKPz1G NyM08m76ke6uRqj7GmG2OPRiBMcF7YvWCZtAHG2zQrMm4jXhUm/gmJXG8VKUa3qM3kXh GVQSkCmHdnEJXYcyjz/rdJuW7SM+SeuZRuTvByY4TO6sPUyRucPUTzzKytGFbNj6mu2H xj7FyZ+WZSfQGI81eZNVRuf82zij1Y6Ar422b/61VhXXp7ORorNwvvqpg8QoOvTPJ4+0 XY7Q== 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:to:cc; bh=BBSc8RdB5lZnHfrHFX8ApXS9PvPuapNxWrP0Ozfq/z8=; b=m0d3VFS+7TMWbuHC/d51nw0tWAglMUkIq2jv81saGrp055eVlQOrYgLte6KU7SCtFM EvKIOmYEk/LCpS+dXGtzO/zU3nfqU/Ez4DLwFPrU2L3XTBR1UlV+vqksM3L+iTzeBKys HXsWiv42AsQbYX81hDbC19zLaObMfLDwgnOrB/4zajJnazLYJjLPvUj1XhmqWYASvVkF cK4szHNxXlIuSUL/cWeK0VtFl8WuDjjpcL7/UyN4/hnJILgD23tZmZM67wM4ghqAUZZM CLklq8ZT/NdtjCPKLfAWq4q+l5lf27w8/EIND6lTZwHqfyKVT+mEEaJX+eLFvEB5v0ol WzFQ== X-Gm-Message-State: AOAM530J8x21QjVpj5DhSATlhPRg5pmBmDv4PD2frf+MP0xWgW6Xj0CC IWgW5FVufh9WiCocjjTDWsoGY1fqaj0ZsyVG6zhjx3Fk1Xz4Rg== X-Google-Smtp-Source: ABdhPJzv5jNzo6kQR1YD37CNHFNod3AdJsAEP1cVL8N2FfALsnt3f8QrFFvLpZmepA+BtN7y45qIf/0JeDrhtrda0L8= X-Received: by 2002:a92:c530:: with SMTP id m16mr2750047ili.300.1593524645260; Tue, 30 Jun 2020 06:44:05 -0700 (PDT) MIME-Version: 1.0 References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> In-Reply-To: From: tirumal reddy Date: Tue, 30 Jun 2020 19:13:53 +0530 Message-ID: To: Eric Rescorla Cc: Paul Vixie , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000006bf26805a94d5eb5" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 13:44:10 -0000 --0000000000006bf26805a94d5eb5 Content-Type: text/plain; charset="UTF-8" On Tue, 30 Jun 2020 at 18:28, Eric Rescorla wrote: > > > On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie wrote: > >> On Tuesday, 30 June 2020 09:07:43 UTC Martin Thomson wrote: >> > Hi Paul, >> > >> > On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote: >> > > Eric Rescorla wrote on 2020-06-29 20:08: >> > > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault > > > > >> > > > > wrote: >> > > > If the lookup takes as input the IP addresses or something >> provided >> > > > by the ISP (like the local resolver IP address), the resulting >> chain >> > > > is likely to be from the ISP. DNSSEC is needed to assert it. >> > > > >> > > > Why do you assume that the IP is delivered securely? >> > > >> > > because dnssec allows me to verify end-to-end authenticity of >> > > name/address bindings (and other dns content.) >> > >> > DNSSEC allows you to be sure of the veracity of what comes from DNSSEC, >> but >> > in this case the IP address didn't come from DNSSEC. It's not DNS >> content. >> >> i have badly misunderstood. >> >> the way i know that the ip address provided by the isp was delivered >> securely >> today is because off-net DHCP forgery is hard, > > > Let's start here: > I agree that off-net DHCP forgery is hard. However, once you assume that > you are off-path, then Do53 interception is *also* hard. So for this to be > useful you need an environment in which the attacker is able to attack Do53 > but *not* to attack DHCP. What I'm asking for is for someone to define that > threat model precisely so that we can design protocols that match it. > The various possible attacks in a home network are discussed in https://tools.ietf.org/html/draft-btw-add-home-06#section-9 -Tiru > > > moving on, what i'd love to have is SDNCP rather than DHCP. S=secure, >> N=network. because i want to know i'm getting what the operator of the >> network >> wants me to get, and because there are other parameters besides RDNS that >> i >> care about, such as whether there's a mandatory HTTPS or HTTP/3 proxy i >> will >> have to talk to. because, IoT. if DHCP isn't useful because it's not >> secure, >> we should stop using it. but before we could do that, we'd have to meet >> its >> functionality in another way. >> > >> i realize that i've identified an unmarketable general case which has got >> to >> sound like i want to boil the ocean, or boil frogs, or something. but i >> figure >> if i don't say something, then after we've consensed around a secure RDNS >> discovery protocol, and somebody says what about all these other >> parameters >> that also have to be set by the network operator and have to be >> authenticated, >> we won't know how we got there. >> >> i'd like setting up an IoT device to be like bluetooth pairing, only, >> secure. >> like, enter a four-digit PIN or something. getting secure RDNS >> configuration >> should be like that. right now it's a welcome letter printed by my ISP, >> and >> that seems outdated. >> > > This all sounds great. And when it was available, we could also use it to > indicate which Do[HT] server you ought to use. > > The question I am addressing is what we ought to do in the interim. > > -Ekr > > >> -- >> Paul >> >> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000006bf26805a94d5eb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 30 Jun 2020 at 18:28, Eric Re= scorla <ekr@rtfm.com> wrote:
<= /div>


On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie <paul@redbarn.org> wrote:=
On Tuesday, 30 June 2020 09:07:= 43 UTC Martin Thomson wrote:
> Hi Paul,
>
> On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote:
> > Eric Rescorla wrote on 2020-06-29 20:08:
> > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault <mglt.ietf@gmail.com > > >
> > > <mailto:mglt.ietf@gmail.com>> wrote:
> > >=C2=A0 =C2=A0 =C2=A0If the lookup takes as input the IP addre= sses or something provided
> > >=C2=A0 =C2=A0 =C2=A0by the ISP (like the local resolver IP ad= dress), the resulting chain
> > >=C2=A0 =C2=A0 =C2=A0is likely to be from the ISP. DNSSEC is n= eeded to assert it.
> > >
> > > Why do you assume that the IP is delivered securely?
> >
> > because dnssec allows me to verify end-to-end authenticity of
> > name/address bindings (and other dns content.)
>
> DNSSEC allows you to be sure of the veracity of what comes from DNSSEC= , but
> in this case the IP address didn't come from DNSSEC.=C2=A0 It'= s not DNS content.

i have badly misunderstood.

the way i know that the ip address provided by the isp was delivered secure= ly
today is because off-net DHCP forgery is hard,

=
Let's start here:
I agree that off-net DHCP forgery is h= ard. However, once you assume that you are off-path, then Do53 interception= is *also* hard. So for this to be useful you need an environment in which = the attacker is able to attack Do53 but *not* to attack DHCP. What I'm = asking for is for someone to define that threat model precisely so that we = can design protocols that match it.
=
The various possible attacks in a home network are discussed= in=C2=A0https://tools.ietf.org/html/draft-btw-add-home-06#section-9
=

-Tiru
=C2=A0


moving on, what i'd love to have is SDNCP rather than DHCP. S=3Dsecure,=
N=3Dnetwork. because i want to know i'm getting what the operator of th= e network
wants me to get, and because there are other parameters besides RDNS that i=
care about, such as whether there's a mandatory HTTPS or HTTP/3 proxy i= will
have to talk to. because, IoT. if DHCP isn't useful because it's no= t secure,
we should stop using it. but before we could do that, we'd have to meet= its
functionality in another way.

i realize that i've identified an unmarketable general case which has g= ot to
sound like i want to boil the ocean, or boil frogs, or something. but i fig= ure
if i don't say something, then after we've consensed around a secur= e RDNS
discovery protocol, and somebody says what about all these other parameters=
that also have to be set by the network operator and have to be authenticat= ed,
we won't know how we got there.

i'd like setting up an IoT device to be like bluetooth pairing, only, s= ecure.
like, enter a four-digit PIN or something. getting secure RDNS configuratio= n
should be like that. right now it's a welcome letter printed by my ISP,= and
that seems outdated.

This all sounds gr= eat. And when it was available, we could also use it to indicate which Do[H= T] server you ought to use.

The question I am addr= essing is what we ought to do in the interim.

-Ekr=


--
Paul


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000006bf26805a94d5eb5-- From nobody Tue Jun 30 09:00:54 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62893A0BB5 for ; Tue, 30 Jun 2020 09:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzSgwrvdTfeF for ; Tue, 30 Jun 2020 09:00:49 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 61D813A0BAE for ; Tue, 30 Jun 2020 09:00:49 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id y18so11702469lfh.11 for ; Tue, 30 Jun 2020 09:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=woViuGH2KgcuHEAN3Y5oHxYSJhfQ/aWxkFMoeQuHWHI=; b=0YW5RPoZ98PVMS0vfvgi95d+ZoCy9dR8paaHCmXPYTlkbhR2mPLQG4TrPvCEz5wm21 YlHOY1JlFTAeZVEUFeFdU8gb1cByGoMQeQ0yvuFiX7NYckomaZjBxtKpILBKHZC4o2VH iSIU/T3AeB7ngearb/lfXQFXiOp1+jkKj/kZIddkplox7yoB4Lp0NLntyoFJm3gpKI47 eBGLpZBjhW5kBAcqzZGEp29ZjiWAIUz1ohpYHKzswA/8sZi9KIivvoLr5IhUNEZ88DI9 runq6cn9iRrPby4NfFoelVFHeIzu7/ui+mbab1Bf+QKLlsI+RvtIou7NyBxz9v1hUHC8 VQgQ== 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:to:cc; bh=woViuGH2KgcuHEAN3Y5oHxYSJhfQ/aWxkFMoeQuHWHI=; b=AINacHzLgSNM+uon9ldHFij/35O8s2o+AxbLhQqRj4ulKoDpZEQZHdRbC8heESB1RC dBUvzcL1xVm5fNBAGFEiWDH+PxnZgzafu/hM0wWV4s/zZ/oC5fBAGc525KSJUEO+0ZcR 0GbgrEJDsFxnvVGaroLs7tod1Bx1wB2/No8ioI3cWn0RA34HQdsd8FLGiYvjc6l04OGq BFHNoZKwRPGLYc+WfZet8tJEBLiwcPhYsOxQjANbl1T4+jzg7PKmL1P7B5YsKWzIig38 BhVP0qb3zZm1CXHmqVpywijFBL75FpPFgAXWtW1tXxpKnXquOk74WBVGu6L3EWfddE8p OmuA== X-Gm-Message-State: AOAM530XutO1NaMqn4Er2l1cGdnu8i7gq3K2f2Tep+zC/jRlcjzOpdYR ctNnmWEFaS/4gy8vrouuIV07+RG+Rm2uOUZ3T0sCgw== X-Google-Smtp-Source: ABdhPJwmGyiChwYPx/MMz+3BsuFiEijeDIacZrRj1/D3/9R6LCscaOk8bp3CbwTbCUW4BDBWrYpD0gTFwN60p6H+z7Y= X-Received: by 2002:a19:83c7:: with SMTP id f190mr12562534lfd.14.1593532847435; Tue, 30 Jun 2020 09:00:47 -0700 (PDT) MIME-Version: 1.0 References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> In-Reply-To: From: Eric Rescorla Date: Tue, 30 Jun 2020 09:00:11 -0700 Message-ID: To: tirumal reddy Cc: Paul Vixie , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000004f46df05a94f479c" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 16:00:52 -0000 --0000000000004f46df05a94f479c Content-Type: text/plain; charset="UTF-8" On Tue, Jun 30, 2020 at 6:44 AM tirumal reddy wrote: > > > On Tue, 30 Jun 2020 at 18:28, Eric Rescorla wrote: > >> >> >> On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie wrote: >> >>> On Tuesday, 30 June 2020 09:07:43 UTC Martin Thomson wrote: >>> > Hi Paul, >>> > >>> > On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote: >>> > > Eric Rescorla wrote on 2020-06-29 20:08: >>> > > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault < >>> mglt.ietf@gmail.com >>> > > > >>> > > > > wrote: >>> > > > If the lookup takes as input the IP addresses or something >>> provided >>> > > > by the ISP (like the local resolver IP address), the resulting >>> chain >>> > > > is likely to be from the ISP. DNSSEC is needed to assert it. >>> > > > >>> > > > Why do you assume that the IP is delivered securely? >>> > > >>> > > because dnssec allows me to verify end-to-end authenticity of >>> > > name/address bindings (and other dns content.) >>> > >>> > DNSSEC allows you to be sure of the veracity of what comes from >>> DNSSEC, but >>> > in this case the IP address didn't come from DNSSEC. It's not DNS >>> content. >>> >>> i have badly misunderstood. >>> >>> the way i know that the ip address provided by the isp was delivered >>> securely >>> today is because off-net DHCP forgery is hard, >> >> >> Let's start here: >> I agree that off-net DHCP forgery is hard. However, once you assume that >> you are off-path, then Do53 interception is *also* hard. So for this to be >> useful you need an environment in which the attacker is able to attack Do53 >> but *not* to attack DHCP. What I'm asking for is for someone to define that >> threat model precisely so that we can design protocols that match it. >> > > The various possible attacks in a home network are discussed in > https://tools.ietf.org/html/draft-btw-add-home-06#section-9 > As far as I can tell, what this text says is that authenticating the server based on information received in DHCP is not useful. -Ekr --0000000000004f46df05a94f479c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 30, 2020 at 6:44 AM tirum= al reddy <kondtir@gmail.com>= wrote:


On Tue, 30 Jun 2020 at 18:28, Eric Rescorla &= lt;ekr@rtfm.com> w= rote:


On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie &l= t;paul@redbarn.org> wrote:
On Tuesday, 30 June= 2020 09:07:43 UTC Martin Thomson wrote:
> Hi Paul,
>
> On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote:
> > Eric Rescorla wrote on 2020-06-29 20:08:
> > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault <mglt.ietf@gmail.com > > >
> > > <mailto:mglt.ietf@gmail.com>> wrote:
> > >=C2=A0 =C2=A0 =C2=A0If the lookup takes as input the IP addre= sses or something provided
> > >=C2=A0 =C2=A0 =C2=A0by the ISP (like the local resolver IP ad= dress), the resulting chain
> > >=C2=A0 =C2=A0 =C2=A0is likely to be from the ISP. DNSSEC is n= eeded to assert it.
> > >
> > > Why do you assume that the IP is delivered securely?
> >
> > because dnssec allows me to verify end-to-end authenticity of
> > name/address bindings (and other dns content.)
>
> DNSSEC allows you to be sure of the veracity of what comes from DNSSEC= , but
> in this case the IP address didn't come from DNSSEC.=C2=A0 It'= s not DNS content.

i have badly misunderstood.

the way i know that the ip address provided by the isp was delivered secure= ly
today is because off-net DHCP forgery is hard,

=
Let's start here:
I agree that off-net DHCP forgery is h= ard. However, once you assume that you are off-path, then Do53 interception= is *also* hard. So for this to be useful you need an environment in which = the attacker is able to attack Do53 but *not* to attack DHCP. What I'm = asking for is for someone to define that threat model precisely so that we = can design protocols that match it.
=
The various possible attacks in a home network are discussed= in=C2=A0https://tools.ietf.org/html/draft-btw-add-home-06#s= ection-9

As far as I = can tell, what this text says is that authenticating the server based on in= formation received in DHCP is not useful.

-Ekr
--0000000000004f46df05a94f479c-- From nobody Tue Jun 30 10:19:18 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFC13A0CEE for ; Tue, 30 Jun 2020 10:19:16 -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, SPF_HELO_NONE=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 QOpz58opPcfM for ; Tue, 30 Jun 2020 10:19:15 -0700 (PDT) Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (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 110283A0A3A for ; Tue, 30 Jun 2020 10:19:14 -0700 (PDT) Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa5.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 05UHJCah002912 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 17:19:13 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 30 Jun 2020 10:19:11 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Tue, 30 Jun 2020 10:19:10 -0700 From: Paul Hoffman To: Eric Rescorla CC: ADD Mailing list Thread-Topic: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers Thread-Index: AQHWTBsN3/DLN2hcME+JF5GYFgXFVajtBcSAgAAMfgD//7+nZoAB+PAAgAAGXwCAAA5CAIABuWkAgAAakYCAABiHAIAACO+AgAAewYCAAADMAIAATz8AgAAVP4CAAAM9AIAAPRyAgABI9wA= Date: Tue, 30 Jun 2020 17:19:09 +0000 Message-ID: <219413C9-2C0A-45A5-9310-9F044E11D5F0@icann.org> References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_BBE9B4FB-F8AA-4053-BC7E-0345F6188D34"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-30_06:2020-06-30, 2020-06-30 signatures=0 Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 17:19:16 -0000 --Apple-Mail=_BBE9B4FB-F8AA-4053-BC7E-0345F6188D34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 30, 2020, at 5:58 AM, Eric Rescorla wrote: >=20 > The question I am addressing is what we ought to do in the interim. >=20 Given that this discussion is happening on an IETF WG mailing list, the = sub-question is who you mean by "we". Earlier, you indicated that you = were not necessarily proposing this for IETF standardization, and your = draft is indeed informational, nor have you asked the WG to consider the = proposal. If all that Firefox needs is a simple way for a resolver to reply with a = key that Firefox can use to look up in its TRR list, the CNAME proposal = is fine. For that matter, so would an A record where Mozilla assigns = each TRR an arbitrary IPv4 address that is used as a key; this would = avoid any problems with middleboxes that blocked CNAME queries. There = doesn't seem to be any value to standardize such a proposal. --Paul Hoffman= --Apple-Mail=_BBE9B4FB-F8AA-4053-BC7E-0345F6188D34 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwNjMwMTcxOTEwWjAvBgkqhkiG9w0BCQQxIgQgxRHY7iZ7a3/KR5S536AG7G+W7qc+ ySc7ms8r1boytI4wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAGYaV/jsjm8jI2X5rHLivPF42+JaEButZgEugP5DO3bl OWcaJq0We9bUWFT7siyhhhQoQYjZSfg+tlK/4qm6LDEzStdoNUMLR5zdETGbngHjG3w1lVfpj1oe tlUCIr+0BA+A/qj82xqRQ8R88xANXGMb+PWHyPWfZ1Ebj3djpmwq3VdulWLckVCAsNhcWpIMNBfc N7+lC+CSq/lDfjyqDhLlteWiEEzc3KoWAbh5fDtmaFEouJxVDw6bZpEGs3EKitahz0R4jV0nIEYO 100m/TZ2SMeluSJtv7XU8Gm48ITY7SNk3BjPynfdmHqN0OCVqXRkLbgRRSvi93DLKb6v3hoAAAAA AAA= --Apple-Mail=_BBE9B4FB-F8AA-4053-BC7E-0345F6188D34-- From nobody Tue Jun 30 10:29:52 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC89F3A07D4 for ; Tue, 30 Jun 2020 10:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O2ILGxlvD1W for ; Tue, 30 Jun 2020 10:29:48 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 0399E3A0957 for ; Tue, 30 Jun 2020 10:29:23 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id 9so23540757ljv.5 for ; Tue, 30 Jun 2020 10:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RsKx5WPwZpjTWtiDpoiWi3CmMy7qlLXI1pl2C+EV1rQ=; b=EoM0t6IjQxH0AubbG4TyGxemdSwb21Srr7qUZApF6VTxanZ6P7H5EwiZ2+OdSycWVX zM30dpMJvbahU1FttDqAB4M164NYCaFKj4zwwf2oigsGM64mSDa657xW3HeJQh0vk90i HzJ5aa+Ln9YOc5etbBo13ln+jUiBGiw5lJkwTwWxz4BLlbRg403Y6INN7jBt/VEnblz4 OqXmLiv13JxLy67tCJtCn0KX7xkFL7YETFgygsOjyYc8V2gupXoDIHGqcYtF9Zk89mHU eYo9diyFGmkvTFZmFjujUGUpziBOZgahBweAcXGr9sfmi0UbgMxILEN7up54kqHJ7DLq 77Kg== 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:to:cc; bh=RsKx5WPwZpjTWtiDpoiWi3CmMy7qlLXI1pl2C+EV1rQ=; b=j1xl4wucNt3nw5VKS7wAq5ryTbK6ZHWsTjjglaheTIBkozDT7ErNyGQvXT4wUTlXOz LESqyP7K+Vx7RjKe2pwkfGrlR/I0Ba6J8ijIO4PiMIyfIvz3sJtnysf/XfWkXqDhnn7N mBc/6BncREeBM9/KK5byvmQvsvbvWrw7TTBUBgq5RZaVqhIXYSvO27oh4+NuxHiAuTxN 3tXo8itp+6dMLDNxETF1fZvbm65i9uH/aKA0mQL59noIrXWOQWD6YTkq5EyROlkn2zoX czxDnGrTkIr5k3tLyMUivfYa8EalCTs8WtW0MgdtbnQ479pR64x7sd40UpAj/ZpB6naX 3AJQ== X-Gm-Message-State: AOAM532U9iVoEFY49YpMopBbAwg64dg5KM5vSkg0Dtj7FyD3OneD6Hrc M7AOCAZzi4rNN8QsttyhBPMoiT1UOhwsM5agHIg6iVpdlYs= X-Google-Smtp-Source: ABdhPJyN4f8cxqvTKThdsfY8C8Kq5fiLqvHY250ALdm/ZQnLaGytexQbgOk9LiXpLQoHh4/686i85h2GM/lw4OgJs+k= X-Received: by 2002:a2e:9510:: with SMTP id f16mr11319921ljh.199.1593538161046; Tue, 30 Jun 2020 10:29:21 -0700 (PDT) MIME-Version: 1.0 References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> <219413C9-2C0A-45A5-9310-9F044E11D5F0@icann.org> In-Reply-To: <219413C9-2C0A-45A5-9310-9F044E11D5F0@icann.org> From: Eric Rescorla Date: Tue, 30 Jun 2020 10:28:44 -0700 Message-ID: To: Paul Hoffman Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000068c9905a95084d5" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 17:29:51 -0000 --000000000000068c9905a95084d5 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 30, 2020 at 10:19 AM Paul Hoffman wrote: > On Jun 30, 2020, at 5:58 AM, Eric Rescorla wrote: > > > > The question I am addressing is what we ought to do in the interim. > > > > Given that this discussion is happening on an IETF WG mailing list, the > sub-question is who you mean by "we". I'm talking about what this WG ought to do. Earlier, you indicated that you were not necessarily proposing this for > IETF standardization, and your draft is indeed informational, nor have you > asked the WG to consider the proposal. > > If all that Firefox needs is a simple way for a resolver to reply with a > key that Firefox can use to look up in its TRR list, the CNAME proposal is > fine. For that matter, so would an A record where Mozilla assigns each TRR > an arbitrary IPv4 address that is used as a key; this would avoid any > problems with middleboxes that blocked CNAME queries. There doesn't seem to > be any value to standardize such a proposal. > As I said before, I'm not asking for standardization of this proposal. I posted it to document what it is that we do. With that said, a number of the comments on this proposal have taken the form of "this is inflexible because we want to carry information of type X". I agree that that's technically correct, but the point that I am making (and in fact one that I made when ADD was first chartered) is that proposals that intend to carry other data (such as the URI template of the resolver, for instance) need to document the threat model that they are assuming and demonstrate that they provide some value in that threat model. That would be true even if we had never submitted this document. What I have seen so far seems insufficient. -Ekr --000000000000068c9905a95084d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 30, 2020 at 10:19 AM Paul= Hoffman <pa= ul.hoffman@icann.org> wrote:
On Jun 30, 2020, at 5:58 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> The question I am addressing is what we ought to do in the interim. >

Given that this discussion is happening on an IETF WG mailing list, the sub= -question is who you mean by "we".

I'm talking about what this WG ought to do.

=
Earlier, you indicated th= at you were not necessarily proposing this for IETF standardization, and yo= ur draft is indeed informational, nor have you asked the WG to consider the= proposal.

If all that Firefox needs is a simple way for a resolver to reply with a ke= y that Firefox can use to look up in its TRR list, the CNAME proposal is fi= ne. For that matter, so would an A record where Mozilla assigns each TRR an= arbitrary IPv4 address that is used as a key; this would avoid any problem= s with middleboxes that blocked CNAME queries. There doesn't seem to be= any value to standardize such a proposal.

<= div>As I said before, I'm not asking for standardization of this propos= al. I posted it to document what it is that we do.

With that said, a number of the comments on this proposal have taken the f= orm of "this is inflexible because we want to carry information of typ= e X". I agree that that's technically correct, but the point that = I am making (and in fact one that I made when ADD was first chartered) is t= hat proposals that intend to carry other data (such as the URI template of = the resolver, for instance) need to document the threat model that they are= assuming and demonstrate that they provide some value in that threat model= . That would be true even if we had never submitted this document. What I h= ave seen so far seems insufficient.

-Ekr


--000000000000068c9905a95084d5-- From nobody Tue Jun 30 10:47:11 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAACA3A0802 for ; Tue, 30 Jun 2020 10:47:10 -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, SPF_HELO_NONE=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 u8QXq2r-JPoU for ; Tue, 30 Jun 2020 10:47:09 -0700 (PDT) Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 277B43A07ED for ; Tue, 30 Jun 2020 10:47:09 -0700 (PDT) Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 05UHl81r001051 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 17:47:08 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 30 Jun 2020 10:47:06 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Tue, 30 Jun 2020 10:47:05 -0700 From: Paul Hoffman To: Eric Rescorla CC: ADD Mailing list Thread-Topic: Threat models Thread-Index: AQHWTwZ4yU9fX8+cxUSRtwVMq+GHUA== Date: Tue, 30 Jun 2020 17:47:05 +0000 Message-ID: <90DC36D8-6D97-4663-8172-1C7C671B5B41@icann.org> References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> <219413C9-2C0A-45A5-9310-9F044E11D5F0@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_165F0568-0255-4FDC-96DF-F53415D5417F"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-30_06:2020-06-30, 2020-06-30 signatures=0 Archived-At: Subject: [Add] Threat models X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 17:47:11 -0000 --Apple-Mail=_165F0568-0255-4FDC-96DF-F53415D5417F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 30, 2020, at 10:28 AM, Eric Rescorla wrote: > With that said, a number of the comments on this proposal have taken = the form of "this is inflexible because we want to carry information of = type X". I agree that that's technically correct, but the point that I = am making (and in fact one that I made when ADD was first chartered) is = that proposals that intend to carry other data (such as the URI template = of the resolver, for instance) need to document the threat model that = they are assuming and demonstrate that they provide some value in that = threat model.. That would be true even if we had never submitted this = document. What I have seen so far seems insufficient. Fully agree about "insufficient", including in the drafts I'm co-author = on. I don't think each draft should be doing its own threat model = because doing so has not led to any agreeemnt in the past, but it might = be good if the WG wanted to have that in general. --Paul Hoffman= --Apple-Mail=_165F0568-0255-4FDC-96DF-F53415D5417F Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwNjMwMTc0NzA2WjAvBgkqhkiG9w0BCQQxIgQgFU+PM9DHI0svaq647RwYHJeHiJnY PWGryR3WXM4pdeAwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAC2hW+4v8N8WoFAPhbs89uP8sRrRui+cGoyEosh2E+Yx e1KU3eSl13EKv+Vg9lvqvRsZDYinLVqYBGnABdYRmX7MfLVpH6tqnaSquvabp6mFrlpe+E9ELZ9O LSeAdnSCn2R6gsDBoVK4DK5uKPRhUXD3GvLfxIIuv8mTSrlY7GJhy6qFhxlsoXOuX4I7uowGYizk y/EfWK4x5MbX/j1uOTVCjX+a2L/gvobKnp7p8SSQjDwoZ+jxHdIgFVtCbhtQyDFj15e4FKhSt9rB E3NizBp9TD6tXoO8xfSrG71CKKjRAepixZJtfNE3nRVZqSow3JJBm5gyUIsJvojZi8Juj9EAAAAA AAA= --Apple-Mail=_165F0568-0255-4FDC-96DF-F53415D5417F-- From nobody Tue Jun 30 11:02:55 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428FC3A0807 for ; Tue, 30 Jun 2020 11:02:53 -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, SPF_HELO_NONE=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 gNzEwrji3zq7 for ; Tue, 30 Jun 2020 11:02:51 -0700 (PDT) Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 8E9E23A07A8 for ; Tue, 30 Jun 2020 11:02:51 -0700 (PDT) Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa4.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 05UI2nxk016369 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 30 Jun 2020 18:02:50 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 30 Jun 2020 11:02:47 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Tue, 30 Jun 2020 11:02:47 -0700 From: Paul Hoffman To: ADD Mailing list Thread-Topic: New (-02) versions of draft-pp-add-stub-upgrade and draft-pp-add-resinfo Thread-Index: AQHWTwio04yvaFgNRkmrzjzOuBTFYw== Date: Tue, 30 Jun 2020 18:02:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_55746B83-BFBB-4AD6-ADD4-3FD2C6B8BFCD"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-30_06:2020-06-30, 2020-06-30 signatures=0 Archived-At: Subject: [Add] New (-02) versions of draft-pp-add-stub-upgrade and draft-pp-add-resinfo X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 18:02:53 -0000 --Apple-Mail=_55746B83-BFBB-4AD6-ADD4-3FD2C6B8BFCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings again. Puneet and I have made a bunch of changes to = draft-pp-add-stub-upgrade and draft-pp-add-resinfo based on the traffic = from the WG, mostly from Ben Schwartz. There are many direct changes, = and some notes for future areas of discussion if these become WG drafts. = The new drafts are at: https://www.ietf.org/internet-drafts/draft-pp-add-stub-upgrade-02.txt https://www.ietf.org/internet-drafts/draft-pp-add-resinfo-02.txt We would like the WG chairs to determine if these drafts are useful for = WG adoption, possibly before the meeting in a few weeks. We know they = are incomplete (particularly noting Ekr's comments earlier today about = threat models), but we have heard enough interest in the data model and = transport where we think the WG can start with them as work items. --Paul Hoffman= --Apple-Mail=_55746B83-BFBB-4AD6-ADD4-3FD2C6B8BFCD Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwNjMwMTgwMjQ3WjAvBgkqhkiG9w0BCQQxIgQgqqAQIZ2uthKADCeCt79/yB/m/jSu V3Ty3u9jf0srzUkwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAI8qk2Z98ZD4EnSXwdZG4tbKs/33rMTksFN2WHIH85mU jTqAu3ESTDcG7M1iaaIJEXCOSEPblLpsvv4EVRyAXgLV7LwYip9lbBQNkIBTGm8PVIUO9/MFgEgd U1Rt1e/6Rnvw2uLdi6qseN3Y6Yz1Xkc050HT0IyEurEFIM4rh15gQmUl9WO1deQaaGHJCrJeTx40 FIAzDt8BQkH6P2tZZZyQh0RDtIJFvQgXt654DjMq4Dm4BbECRXJNyDTzjgiYmwvTToPGgCsu+paQ /mKiqP95YLAdLRp+ef2+ESK5M9hG4A5WBEqyJ+mrTziR3xa6gZXcgachcuv/ifC3A2pSj8IAAAAA AAA= --Apple-Mail=_55746B83-BFBB-4AD6-ADD4-3FD2C6B8BFCD-- From nobody Tue Jun 30 14:23:56 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B27D3A0870 for ; Tue, 30 Jun 2020 14:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=open-xchange.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 A8JpA85AAxdI for ; Tue, 30 Jun 2020 14:23:52 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 A09733A085D for ; Tue, 30 Jun 2020 14:23:52 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 0F2FF6A305; Tue, 30 Jun 2020 23:23:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1593552228; bh=0XSraTsHMwlIL8B133vxQxKwJs+jMXGVq81rZgMWvgw=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ukxlrAZeTh1eTvBmLsGAMWaqdGiMNJiiZs/CxOYedYUtGeVnT92tW8XbRghD4Qu9W pqffCfLdykkQljgoN9i8kg89Nf+QyW0SuwS2Y2M5KieVpRj5NTlQKOja/NyUvar4Qj 4XrD3x2dy29n9i4UXxRKx6qieAOwlTXQxDNWFEwDd0iGfzhNJ0HtYimfOzjgkCHr9Q ptKOTc1DPCfh4fgWu0EkUnpq8gg5rO56nDRgLrOf+imsTRpt+xhnDiUe0gig8pjW8t U0ilxluH8fgUWthu7PSLmxIVA2r2z5DO3b/PTEVosNV2rj1OpfIWFAKiXnERoSCcZw XON9Lo7dqi0qA== Received: from appsuite-dev-gw1.open-xchange.com (appsuite-dev-gw1.open-xchange.com [10.20.30.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id F3A7F3C0039; Tue, 30 Jun 2020 23:23:47 +0200 (CEST) Date: Tue, 30 Jun 2020 23:23:47 +0200 (CEST) From: Vittorio Bertola To: Eric Rescorla , Paul Vixie Cc: ADD Mailing list Message-ID: <493383543.2474.1593552227901@appsuite-dev-gw1.open-xchange.com> In-Reply-To: References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2472_308552848.1593552227789" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev1 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 21:23:55 -0000 ------=_Part_2472_308552848.1593552227789 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 30/06/2020 14:58 Eric Rescorla ha scritto: > > On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie wrote: > > > > i have badly misunderstood. > > > > the way i know that the ip address provided by the isp was delivered securely > > today is because off-net DHCP forgery is hard, > > > > > > Let's start here: > I agree that off-net DHCP forgery is hard. However, once you assume that you are off-path, then Do53 interception is *also* hard. So for this to be useful you need an environment in which the attacker is able to attack Do53 but *not* to attack DHCP. What I'm asking for is for someone to define that threat model precisely so that we can design protocols that match it. > I have written and deleted two or three longer replies to this, so I will just quote what Daniel Migault wrote a few messages ago: "The threat model seems for Comcast and the end user having the traffic redirected to Cloudflare instead of the local resolver." But of course the basic issue is that we seem to disagree on what a threat is. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_2472_308552848.1593552227789 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 30/06/2020 14:58 Eric Rescorla <ekr@rtfm.com> ha scritto:

On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie <paul@redbarn.org> wrote:
i have badly misunderstood.

the way i know that the ip address provided by the isp was delivered securely
today is because off-net DHCP forgery is hard,

Let's start here:
I agree that off-net DHCP forgery is hard. However, once you assume that you are off-path, then Do53 interception is *also* hard. So for this to be useful you need an environment in which the attacker is able to attack Do53 but *not* to attack DHCP. What I'm asking for is for someone to define that threat model precisely so that we can design protocols that match it.
I have written and deleted two or three longer replies to this, so I will just quote what Daniel Migault wrote a few messages ago: "The threat model seems for Comcast and the end user having the traffic redirected to Cloudflare instead of the local resolver." But of course the basic issue is that we seem to disagree on what a threat is.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_2472_308552848.1593552227789-- From nobody Tue Jun 30 15:05:31 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688933A08A5 for ; Tue, 30 Jun 2020 15:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 eVxIzu4BJs5J for ; Tue, 30 Jun 2020 15:05:29 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 2A2F63A089C for ; Tue, 30 Jun 2020 15:05:29 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id q8so22767493iow.7 for ; Tue, 30 Jun 2020 15:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RyUsJuI8ukx3bIHXWjP5FDP5sZKKKzFcv2H57dzENc4=; b=HiEEZnheN+T1wy/DbCl3mqopZ/rWVMZvaKs4QNguviEeQUzElVRN6YW4qCN5nRMNJb SoBQEsarvr0QsmAAzvc1otj2VWiq9GVL3scvNsSWbHmMFSM8tWbi/kKoDADcrWOdMByR +TAKCJtYjOdFjrrU3z7+qKT9k6dgXoVItO7dklJANaRb7K19Mr/5etPRhIBXu3TPBvGj cgPwmkCjx4SUA/hBazxxqXdd7rOv4o4ImmE/orgM60XxjlZii7gk5CW5m7V1i9/m/WZX V8PhSnvIO3utZFT2lvUrH1X2R9h1a4VqPLYublLDjP/d0HAiA3i9vnyoymS0wOy14r/B 20mQ== 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:to:cc; bh=RyUsJuI8ukx3bIHXWjP5FDP5sZKKKzFcv2H57dzENc4=; b=kQ5C97HWcRGfmSJ970u3cNV9j2/niNqppjjsT5j8oHBKHtevk66PDhiJOByXkiPsye n/pUcyc5zGtLAMLQs6lYlh4xqv9pZcIutLbSNsXzlFvH4mHCkTmz4vG+Qz3vWQ7J5+8w V93Aclq/j25IROZEqEA9Kj5u3Dm67DWkJyJmgiH9hOgFPnliEcgplTitvcdsxiZpb+cb C9MBW9ZGD6Z41Iv61bi74hKnQ8r7XzaCAOz+xZ6ZW4aw95JvfYsHgxnVUiMi0uc9Ep6W Y3G4UubZ4OxBkCl5ItZzI6zt3MWabYyIn698g9BYlv2GhQDUpQ4q1ni/OXXu4ag2Jo8F 3cFg== X-Gm-Message-State: AOAM5315deGI8TxYyCA7N+SiX06GabuO0PovskyIlrm06uDXabQGVJoX PigppUYlfCrtxzhVGZW8WMrVfpQZF/mspIKGOylAe2prkUs= X-Google-Smtp-Source: ABdhPJwJ1SZzIIJwrYz5a0kMMc4SJGSGw2kRQ9DyNNgCzcGyP6JvypzRCuBy6QrrE2Bpv7Xm6fMjkcAngCaRXhL7QOU= X-Received: by 2002:a6b:d119:: with SMTP id l25mr17173977iob.192.1593554728092; Tue, 30 Jun 2020 15:05:28 -0700 (PDT) MIME-Version: 1.0 References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> <493383543.2474.1593552227901@appsuite-dev-gw1.open-xchange.com> In-Reply-To: <493383543.2474.1593552227901@appsuite-dev-gw1.open-xchange.com> From: Rob Sayre Date: Tue, 30 Jun 2020 15:05:13 -0700 Message-ID: To: Vittorio Bertola Cc: Eric Rescorla , Paul Vixie , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000007f882405a9545fe7" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 22:05:30 -0000 --0000000000007f882405a9545fe7 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 30, 2020 at 2:24 PM Vittorio Bertola wrote: > I have written and deleted two or three longer replies to this, so I will > just quote what Daniel Migault wrote a few messages ago: "The threat model > seems for Comcast and the end user having the traffic redirected to > Cloudflare instead of the local resolver." But of course the basic issue is > that we seem to disagree on what a threat is. > Agree that there is disagreement here. thanks, Rob --0000000000007f882405a9545fe7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 30, 2020 at 2:24 PM Vittorio = Bertola <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.org> wrote:
<= blockquote type=3D"cite">
I have written and deleted two or three longer replies to this, so I wil= l just quote what Daniel Migault wrote a few messages ago: "The threat= model seems for Comcast and the end user having the traffic redirected to = Cloudflare instead of the local resolver." But of course the basic iss= ue is that we seem to disagree on what a threat is.

Agree that there is disagreement here.

<= /div>
thanks,
Rob
=C2=A0
--0000000000007f882405a9545fe7-- From nobody Tue Jun 30 15:06:37 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D933A08AD for ; Tue, 30 Jun 2020 15:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKxN0cr9vwey for ; Tue, 30 Jun 2020 15:06:34 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 BDB9A3A089C for ; Tue, 30 Jun 2020 15:06:33 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id n23so24534153ljh.7 for ; Tue, 30 Jun 2020 15:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xnHpyqtMYFjlRzQC1+44fgO2wboMSkN8fXQWOcozAm4=; b=x4njfS0PQLepnikX2GJvnJt0DGLQtfBceGTfcVCK7iWvhY7LylBJZVdW60E1lPalTx AQ2iUM01xxw/00v9ZgpC1+ikgY7eht+E99ijGokqx0gpjbg8DL0PnRms0SXx5s6MSDeu Zq6kzC8kb4XXPp0MWslXIfgZgAO8k+0kpFHC4CSh7OTrW7wJHvgkA1anTeBDYb3f8e48 h2Ourb5RcD3vQ2Ywt3bIa1GVmciomMgn/sGDJfo5QJc+iOABMgRzYKzHgZGhphs37E8I eElCEf+jrAB8OLhsXeTMfMy/bCbUDlNdjYQUEZFW13ZZwOFKg2VpeqTCSrPs6PEi86fa 445g== 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:to:cc; bh=xnHpyqtMYFjlRzQC1+44fgO2wboMSkN8fXQWOcozAm4=; b=QPzWa2jLpndCzDz+X0YEWfDgOCSRv86u5sqGpDYwF9UupcrBeoCNTztBQEyTqhoN/V Sfn0TbSQ8XBe/sueNQa6P28ntSOCe2JjdSApEZsoG16ZAeKDQDJWe2+AZApHMouJBgH6 dC/VcKdn9X/qKFWJaCbwWoHc0Z4L/g2DLc+KtOVF0DtMahMuY7SznlCxqoUAHcEk+iH7 HbXHSSXvkRYhcffdD1sPfUT0k4B+ZBjWvxANj8jVOT0SKzr5TJ+CDFOzl7zzTy0qgLPy h8IysXINnsR41TQlzcDJy/RvT3DEw9NYLHYgpDK1A/hN2lirXpKdp/qBU7pUVESMB5sM IzGg== X-Gm-Message-State: AOAM532Wxy0tuViNau2F3RLc3kPWm3tLF1dsvEhEaKV9PfKquy5zxvdf sMjCO1W0YkZlW7ucxQEyo1XP4F1G/V8Qw86zpvpGng7hckA= X-Google-Smtp-Source: ABdhPJy7lJQhC4kYBW776BOAbJcHOho7XahQdCsFeeq5CV2ikwYMSaDqNa0bTZZtll3Zkm8HLk2medUQHWTn42DtgXQ= X-Received: by 2002:a2e:8092:: with SMTP id i18mr3739603ljg.265.1593554791906; Tue, 30 Jun 2020 15:06:31 -0700 (PDT) MIME-Version: 1.0 References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> <493383543.2474.1593552227901@appsuite-dev-gw1.open-xchange.com> In-Reply-To: <493383543.2474.1593552227901@appsuite-dev-gw1.open-xchange.com> From: Eric Rescorla Date: Tue, 30 Jun 2020 15:05:55 -0700 Message-ID: To: Vittorio Bertola Cc: Paul Vixie , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000004d514e05a954636d" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 22:06:36 -0000 --0000000000004d514e05a954636d Content-Type: text/plain; charset="UTF-8" On Tue, Jun 30, 2020 at 2:24 PM Vittorio Bertola wrote: > > Il 30/06/2020 14:58 Eric Rescorla ha scritto: > > On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie wrote: > > i have badly misunderstood. > > the way i know that the ip address provided by the isp was delivered > securely > today is because off-net DHCP forgery is hard, > > > Let's start here: > I agree that off-net DHCP forgery is hard. However, once you assume that > you are off-path, then Do53 interception is *also* hard. So for this to be > useful you need an environment in which the attacker is able to attack Do53 > but *not* to attack DHCP. What I'm asking for is for someone to define that > threat model precisely so that we can design protocols that match it. > > I have written and deleted two or three longer replies to this, so I will > just quote what Daniel Migault wrote a few messages ago: "The threat model > seems for Comcast and the end user having the traffic redirected to > Cloudflare instead of the local resolver." But of course the basic issue is > that we seem to disagree on what a threat is. > No, I don't in fact that's the issue at all. To recap, this is a solution for a very specific problem. I'm not suggesting that it's a generic solution. However, there have been a number of proposals for nominally generic solutions none of which seem to come with a fully defined threat model. I'm trying to get to what that model is. Specifically, I agree that it would be a useful to allow endpoint devices to securely learn the identity of the Do[HT] server associated with their local network [0]. This would then allow you to get private resolution even if there were attackers on the network (as in classical Ethernet or unencrypted WiFi). However, even with that objective, we still need to define a realistic set of attacker capabilities and then a design which is secure given those capabilities. That is what I am asking for. -Ekr [0] Under the assumption that you are connecting to the right network, of course, which is sometimes a very thin assumption. > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000004d514e05a954636d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 30, 2020 at 2:24 PM Vitto= rio Bertola <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.org> wr= ote:
=20 =20 =20

Il 30/06/2020 14:58 Eric Rescorla <ekr@rtfm.com> ha scritto:

On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie <paul@redbarn.org> wrote:
i have badly misunderstood.

the way i know that the ip address provided by the isp was delive= red securely=20
today is because off-net DHCP forgery is hard,

Let's start here:
I agree that off-net DHCP forgery is hard. However, once you assume t= hat you are off-path, then Do53 interception is *also* hard. So for this to= be useful you need an environment in which the attacker is able to attack = Do53 but *not* to attack DHCP. What I'm asking for is for someone to de= fine that threat model precisely so that we can design protocols that match= it.
I have written and deleted two or three longer replies to this, so I wil= l just quote what Daniel Migault wrote a few messages ago: "The threat= model seems for Comcast and the end user having the traffic redirected to = Cloudflare instead of the local resolver." But of course the basic iss= ue is that we seem to disagree on what a threat is.

No, I don't in fact that= 's the issue at all. To recap, this is a solution for a very specific p= roblem. I'm not suggesting that it's a generic solution.
=
However, there have been a number of proposals for nominall= y generic solutions none of which seem to come with a fully defined threat = model. I'm trying to get to what that model is. Specifically, I agree t= hat it would be a useful to allow endpoint devices to securely learn the id= entity of the Do[HT] server associated with their local network [0]. This w= ould then allow you to get private resolution even if there were attackers = on the network (as in classical Ethernet or unencrypted WiFi). However, eve= n with that objective, we still need to define a realistic set of attacker = capabilities and then a design which is secure given those capabilities. Th= at is what I am asking for.

-Ekr
[0] Under the assumption that you are connecting to the right n= etwork, of course, which is sometimes a very thin assumption.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchangevit=
torio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torin=
o, Italy
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000004d514e05a954636d-- From nobody Tue Jun 30 16:25:15 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0CA3A02BE for ; Tue, 30 Jun 2020 16:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.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 hYzUaYodiRMs for ; Tue, 30 Jun 2020 16:25:11 -0700 (PDT) Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (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 558183A011B for ; Tue, 30 Jun 2020 16:25:11 -0700 (PDT) Received: from pps.filterd (m0047964.ppops.net [127.0.0.1]) by m0047964.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 05UNLC2n042442 for ; Tue, 30 Jun 2020 19:25:10 -0400 Received: from usecmgip001.mail.tfayd.com ([50.228.147.33]) by m0047964.ppops.net-00176a04. with ESMTP id 31x1q6j84e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 30 Jun 2020 19:25:10 -0400 IronPort-SDR: C7+j/C4zcHk5NR5A7Cep+f3j3pN2at4OlSB4a4heZ6BkrUjS0fbnvi5yFQNW5Q2QjJhadh8JsG 7031nhOuS6Bg== Received: from unknown (HELO ashemwp00001.mail.tfayd.com) ([100.126.24.25]) by USECMGIP001.mail.tfayd.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 30 Jun 2020 19:25:08 -0400 Received: from ashemwp00003.mail.tfayd.com (100.126.24.27) by ashemwp00004.mail.tfayd.com (100.126.24.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5; Tue, 30 Jun 2020 19:25:08 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.56.130.76) by ashemwp00003.mail.tfayd.com (100.126.24.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5 via Frontend Transport; Tue, 30 Jun 2020 19:25:07 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mvYW1nfTfBmYxZe5m8jShWxzg+YFxlOkmeEfHdtf9TgqoYW2oQFS1dJxdtk653zCH+zcWSB3QvHjUkdoSD2Txlpj7g+tmWkO2nkMP01j5kByjHeMFGTkHCGblKqSotM5WC9pgquKlsKwUH4uYuANrSqRbG9j7m9vhaAmVcZ6oEe+dvgkbqtAbeiUUtZLYJqKpoM/S7Eegzcsj/hJUs9ThfQo3wp8bX4VSLRORj+pfvmRne/oXqodx/raj4Tw8jUcdrCevlthz9oLYkAhDQy7RMwzaj/GvRArzeBbDqyERkv+uD5cSCiqykGqiOpf6hK/MISEl6tGTUms6OycOY+1gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gyfNgXOB6WOXdBvnKtNbauIlUKndpuP4vwLXodKe3YA=; b=fUgRDG+PWrNANaFfXNxxfyYXr9xWEbMwJbk20ReBPvYiejit65H+2wHKAfWSHnyYxySLYjywvQP/ARwK1QP04jIjuqM7tcTPfFZTpEJ8sMzzVAx7vgWVMuhAmFoagU90I4++sIZ0YX3DjYDLLZnvxBIxiDK/119tvFfZv0wAOzaPAl2nCVbRDqCG+osBwwp1rXaRKBDl1iOJCvuIafhpb9d/61VyRUVK0R0EDV5vCpsUqRTmqfAjWydTV3P40Dl+ldTNDXzsNt9OinBZ2ycxUFNEagagBnUwWd3yRq4faABuEd/Xk44U5ah4/bsa5SpgkAUKD2JiltWlHAsxT0yiPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gyfNgXOB6WOXdBvnKtNbauIlUKndpuP4vwLXodKe3YA=; b=MBzEfydR4fuh++S8R0Ujlv4pCuAG0T6FxseGDewsA+JuNPerYpxgO3EgoYY1U9RVCdq93TQuSFigJTM5z1K2D5A0fqJS1ZHLHQQZWcV0TRozNBGyeDUYIK7AevN0as9uRW/nsPysW1qfmmrinXKu+IO0fQKJxlD77b36f8b9PyU= Received: from BYAPR14MB3094.namprd14.prod.outlook.com (2603:10b6:a03:14d::30) by BYAPR14MB2679.namprd14.prod.outlook.com (2603:10b6:a03:de::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.20; Tue, 30 Jun 2020 23:25:06 +0000 Received: from BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::e074:901e:d085:be5c]) by BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::e074:901e:d085:be5c%7]) with mapi id 15.20.3131.027; Tue, 30 Jun 2020 23:25:06 +0000 From: "Deen, Glenn (NBCUniversal)" To: Eric Rescorla , Vittorio Bertola CC: ADD Mailing list , Paul Vixie , "Deen, Glenn (NBCUniversal)" Thread-Topic: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers Thread-Index: AQHWTzWwJ0NQA5XM+ka8R5HmnPNV3Q== Date: Tue, 30 Jun 2020 23:25:06 +0000 Message-ID: <39AB91D2-02F7-4618-8C5E-D3ED062A8286@nbcuni.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=nbcuni.com; x-originating-ip: [2605:e000:141b:121:d0ac:ed9d:af97:3e9c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 468f9e4c-496f-4010-2883-08d81d4cd2f5 x-ms-traffictypediagnostic: BYAPR14MB2679: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0450A714CB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kvNeE1HKr9116XE65ynCJ7CrIF5w5vK2ff7BGHjnq+K8lQWXFTq0Pxs7PxJq0GxkYXdf82apjNywHcb0VqfhH8QT4LsbK1hJhJDy1ZiDe0g0AeGZuloq198mnEFVDRcJz9NVgq02NZHmaI7Ip5HZ+XvEMXxddbNt0rJ/S9Sx7BwWeumEyPciZsvrN8juBhR43xd4alZL1eSrubIjCwpxezBX25+asu4wJj35ixSNVsFzyqbEBVR8xYhBcxgLOhkD57HuaOb44llsjBm6yoo8jgBKD0fcQi5iRzBxFAS8efsE0zC2t9kzEFj7RfiwlRKsV25/Xx72N0zHLHxzqhJ41Dn43+MrMO5qpUU4mcKX6wImt1cKUJGpSWjZFGeHLfnnD94Rb4u0r2bissLb3eYOag== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR14MB3094.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(376002)(136003)(396003)(366004)(8936002)(86362001)(2906002)(186003)(2616005)(53546011)(6506007)(5660300002)(966005)(4326008)(66476007)(66946007)(8676002)(83380400001)(478600001)(66556008)(64756008)(66446008)(76116006)(71200400001)(66574015)(54906003)(316002)(6512007)(110136005)(107886003)(33656002)(6486002)(36756003)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 5RkAHjN9cfTxwJrqUkzyq5vdqngNQDi1pNR3/UxIBf0fX35StHepdhOom83kGZMGlebT5NwoQFDV1TjJW7//HowgB6Ewto2Wk3IpZo1CHksG7ZQJ5fu2y/SgPo+6zpywotm/MKKHnh+tT5cmiXA0ISbE5vMBht3b84xy76nGYgwZPysPC73sTH4fS1PVX4GwxjlV14Y2mSnqLi87mmhI0bSIuEg1AHCnH+FiUXGoaf9UeYtcxynPeQSwz7UmdL5HuFxuMklOnL5gYnZe3JmilG8cj6DkHTaToQeymxivzcLZKwM0Mp31263/NF6U4bd8z0/kChXiLEG//FWO03YudRec9lPj6r6JTtEbQ8H+VPy/UdsmI0lDB/COte1gyn58bkxOCxoDPQskcP8phXN4caefZwgZXwZv0nTjD8hSaEmFGBFHAHjnHk7nv5rvP9nJVQPeHHq/dGV7dkR4cp7AMU1af64SH91/8Gl0Ntm6zle2CsqiXKJc3QTztbqiR6vHSDDIXGqjTwbWPu+Tc3IgPguokOQczRUIY+f+dhaECJ9it+2+xvfEGXbCdpA+zc1J Content-Type: multipart/alternative; boundary="_000_39AB91D202F746188C5ED3ED062A8286nbcunicom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR14MB3094.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 468f9e4c-496f-4010-2883-08d81d4cd2f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2020 23:25:06.5777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EOCTzNBNLJ6IzqDypraKMBjAuq0bieQg6S3ZHbpRtpq8lYYa+ezEup6cDRNuz1Zp+Gg/3hZBzLTH+KhgQyiq7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR14MB2679 X-OriginatorOrg: nbcuni.com X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-30_06:2020-06-30, 2020-06-30 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 bulkscore=0 adultscore=0 clxscore=1011 mlxlogscore=999 suspectscore=0 phishscore=0 spamscore=0 impostorscore=0 lowpriorityscore=0 mlxscore=0 cotscore=-2147483648 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006300162 Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 23:25:13 -0000 --_000_39AB91D202F746188C5ED3ED062A8286nbcunicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBhbGwgY29tZXMgYmFjayB0byB0aGUgdGhyZWUgc2xpY2VzIG9mIGFjY2VzcyB0eXBlcyB0 aGF0IGhhZCBiZWVuIGRpc2N1c3NlZCBzb21lIG1vbnRocyBhZ286DQoNCg0KICAxLiAgVHJ1c3Rl ZCAmIGtub3duIG5ldHdvcmtzIOKAkyB0aGlzIGlzIHlvdXIgZW50ZXJwcmlzZSwgeW91ciBob21l LiAgWW91IGhhdmUgYSByZWxhdGlvbnNoaXAgd2l0aCB0aGVtLg0KICAyLiAgVW5rbm93biBuZXR3 b3JrcyDigJMgVGhpcyBpcyB0aGUgY2Fmw6ksIHNjaG9vbCwgaG90ZWwgLSB5b3UgY2hvb3NlIHRo ZW0gYmVjYXVzZSB0aGV5IGFyZSBhdmFpbGFibGUsIGJ1dCB5b3Uga25vdyB2ZXJ5IGxpdHRsZSB0 byBub3RoaW5nIGFib3V0IHRoZW0uDQogIDMuICBIb3N0aWxlIG5ldHdvcmtzIOKAkyB5b3UgbWF5 IG5vdCBoYXZlIGFueSBjaG9pY2UgaW4gbmV0d29yayBhbmQgbXVzdCB1c2UgdGhpcyBpcyB5b3Ug d2FudCBhbnkgSW50ZXJuZXQgYWNjZXNzIGF0IGFsbC4gIEhvd2V2ZXIsIG5vdCBvbmx5IGRvIHlv dSBub3QgdHJ1c3QgdGhlbSwgeW91IGtub3cgdGhleSBhcmUgYWN0aXZlbHkgYWN0aW5nIGluIHdh eXMgeW91IGRvIG5vdCB3YW50Lg0KDQpBbm90aGVyIHNsaWNlIGFyb3VuZCB0aHJlYXQgbGV2ZWxz IHdvdWxkIGJlOiBHcmVlbiwgWWVsbG93LCBSZWQgbmV0d29ya3MNCg0KDQpDZXJ0YWlubHkgaW4g dGVybXMgb2YgcG9saWN5IGFuZCBzZWN1cml0eSBjb25jZXJucyBvbmUgc2l6ZSBkb2VzIG5vdCBm aXQgYWxsIDMuICBUaGUgcXVlc3Rpb24gaXMgY2FuIHdlIGZhc2hpb24gYSBkaXNjb3ZlcnkgbWVh bnMgdGhhdCB3b3JrcyBpbiBhbGwgMywgYnV0IHBlcmhhcHMgbWl0aWdhdGVzIHRoZSBwb2xpY3kg YW5kIHNlY3VyaXR5IGNvbmNlcm5zIGluIGVhY2g/DQoNCkRIQ1AgbWF5IGJlIGEgcGVyZmVjdGx5 IGZpbmUgY2hvaWNlIGluIGEgZ3JlZW4gbmV0d29yaywgYnV0IGluIGEgeWVsbG93IG5ldHdvcmsg dGhlcmUgaXMgYSBuZWVkIGZvciB2YWxpZGF0aW9uIGFuZCBhc3N1cmFuY2Ugb2YgdGhlIGNob2lj ZSwgd2hpbGUgaW4gYSByZWQgbmV0d29yayDigJMgY2FuIHlvdSB0cnVzdCBhbnl0aGluZyBhdCBh bGwsIGV2ZW4gdGhpbmdzIHlvdSBleHBsaWNpdGx5IHNwZWNpZmllZCBzdWNoIGFzIElQIGFkZHJl c3Mgb2YgcmVzb2x2ZXJzIHdpdGhvdXQgc29tZSBhZGRpdGlvbmFsIHZhbGlkYXRpb24gPw0KDQot Z2xlbm4NCg0KT24gNi8zMC8yMCwgMzowNyBQTSwgIkFkZCBvbiBiZWhhbGYgb2YgRXJpYyBSZXNj b3JsYSIgPGFkZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphZGQtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQoN Cg0KDQpPbiBUdWUsIEp1biAzMCwgMjAyMCBhdCAyOjI0IFBNIFZpdHRvcmlvIEJlcnRvbGEgPHZp dHRvcmlvLmJlcnRvbGE9NDBvcGVuLXhjaGFuZ2UuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0 MG9wZW4teGNoYW5nZS5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KSWwgMzAvMDYvMjAy MCAxNDo1OCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+ IGhhIHNjcml0dG86DQoNCk9uIFR1ZSwgSnVuIDMwLCAyMDIwIGF0IDI6MTkgQU0gUGF1bCBWaXhp ZSA8cGF1bEByZWRiYXJuLm9yZzxtYWlsdG86cGF1bEByZWRiYXJuLm9yZz4+IHdyb3RlOg0KaSBo YXZlIGJhZGx5IG1pc3VuZGVyc3Rvb2QuDQoNCnRoZSB3YXkgaSBrbm93IHRoYXQgdGhlIGlwIGFk ZHJlc3MgcHJvdmlkZWQgYnkgdGhlIGlzcCB3YXMgZGVsaXZlcmVkIHNlY3VyZWx5DQp0b2RheSBp cyBiZWNhdXNlIG9mZi1uZXQgREhDUCBmb3JnZXJ5IGlzIGhhcmQsDQoNCkxldCdzIHN0YXJ0IGhl cmU6DQpJIGFncmVlIHRoYXQgb2ZmLW5ldCBESENQIGZvcmdlcnkgaXMgaGFyZC4gSG93ZXZlciwg b25jZSB5b3UgYXNzdW1lIHRoYXQgeW91IGFyZSBvZmYtcGF0aCwgdGhlbiBEbzUzIGludGVyY2Vw dGlvbiBpcyAqYWxzbyogaGFyZC4gU28gZm9yIHRoaXMgdG8gYmUgdXNlZnVsIHlvdSBuZWVkIGFu IGVudmlyb25tZW50IGluIHdoaWNoIHRoZSBhdHRhY2tlciBpcyBhYmxlIHRvIGF0dGFjayBEbzUz IGJ1dCAqbm90KiB0byBhdHRhY2sgREhDUC4gV2hhdCBJJ20gYXNraW5nIGZvciBpcyBmb3Igc29t ZW9uZSB0byBkZWZpbmUgdGhhdCB0aHJlYXQgbW9kZWwgcHJlY2lzZWx5IHNvIHRoYXQgd2UgY2Fu IGRlc2lnbiBwcm90b2NvbHMgdGhhdCBtYXRjaCBpdC4NCkkgaGF2ZSB3cml0dGVuIGFuZCBkZWxl dGVkIHR3byBvciB0aHJlZSBsb25nZXIgcmVwbGllcyB0byB0aGlzLCBzbyBJIHdpbGwganVzdCBx dW90ZSB3aGF0IERhbmllbCBNaWdhdWx0IHdyb3RlIGEgZmV3IG1lc3NhZ2VzIGFnbzogIlRoZSB0 aHJlYXQgbW9kZWwgc2VlbXMgZm9yIENvbWNhc3QgYW5kIHRoZSBlbmQgdXNlciBoYXZpbmcgdGhl IHRyYWZmaWMgcmVkaXJlY3RlZCB0byBDbG91ZGZsYXJlIGluc3RlYWQgb2YgdGhlIGxvY2FsIHJl c29sdmVyLiIgQnV0IG9mIGNvdXJzZSB0aGUgYmFzaWMgaXNzdWUgaXMgdGhhdCB3ZSBzZWVtIHRv IGRpc2FncmVlIG9uIHdoYXQgYSB0aHJlYXQgaXMuDQoNCk5vLCBJIGRvbid0IGluIGZhY3QgdGhh dCdzIHRoZSBpc3N1ZSBhdCBhbGwuIFRvIHJlY2FwLCB0aGlzIGlzIGEgc29sdXRpb24gZm9yIGEg dmVyeSBzcGVjaWZpYyBwcm9ibGVtLiBJJ20gbm90IHN1Z2dlc3RpbmcgdGhhdCBpdCdzIGEgZ2Vu ZXJpYyBzb2x1dGlvbi4NCg0KSG93ZXZlciwgdGhlcmUgaGF2ZSBiZWVuIGEgbnVtYmVyIG9mIHBy b3Bvc2FscyBmb3Igbm9taW5hbGx5IGdlbmVyaWMgc29sdXRpb25zIG5vbmUgb2Ygd2hpY2ggc2Vl bSB0byBjb21lIHdpdGggYSBmdWxseSBkZWZpbmVkIHRocmVhdCBtb2RlbC4gSSdtIHRyeWluZyB0 byBnZXQgdG8gd2hhdCB0aGF0IG1vZGVsIGlzLiBTcGVjaWZpY2FsbHksIEkgYWdyZWUgdGhhdCBp dCB3b3VsZCBiZSBhIHVzZWZ1bCB0byBhbGxvdyBlbmRwb2ludCBkZXZpY2VzIHRvIHNlY3VyZWx5 IGxlYXJuIHRoZSBpZGVudGl0eSBvZiB0aGUgRG9bSFRdIHNlcnZlciBhc3NvY2lhdGVkIHdpdGgg dGhlaXIgbG9jYWwgbmV0d29yayBbMF0uIFRoaXMgd291bGQgdGhlbiBhbGxvdyB5b3UgdG8gZ2V0 IHByaXZhdGUgcmVzb2x1dGlvbiBldmVuIGlmIHRoZXJlIHdlcmUgYXR0YWNrZXJzIG9uIHRoZSBu ZXR3b3JrIChhcyBpbiBjbGFzc2ljYWwgRXRoZXJuZXQgb3IgdW5lbmNyeXB0ZWQgV2lGaSkuIEhv d2V2ZXIsIGV2ZW4gd2l0aCB0aGF0IG9iamVjdGl2ZSwgd2Ugc3RpbGwgbmVlZCB0byBkZWZpbmUg YSByZWFsaXN0aWMgc2V0IG9mIGF0dGFja2VyIGNhcGFiaWxpdGllcyBhbmQgdGhlbiBhIGRlc2ln biB3aGljaCBpcyBzZWN1cmUgZ2l2ZW4gdGhvc2UgY2FwYWJpbGl0aWVzLiBUaGF0IGlzIHdoYXQg SSBhbSBhc2tpbmcgZm9yLg0KDQotRWtyDQoNClswXSBVbmRlciB0aGUgYXNzdW1wdGlvbiB0aGF0 IHlvdSBhcmUgY29ubmVjdGluZyB0byB0aGUgcmlnaHQgbmV0d29yaywgb2YgY291cnNlLCB3aGlj aCBpcyBzb21ldGltZXMgYSB2ZXJ5IHRoaW4gYXNzdW1wdGlvbi4NCg0KLS0NCg0KVml0dG9yaW8g QmVydG9sYSB8IEhlYWQgb2YgUG9saWN5ICYgSW5ub3ZhdGlvbiwgT3Blbi1YY2hhbmdlDQp2aXR0 b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb208bWFpbHRvOnZpdHRvcmlvLmJlcnRvbGFAb3Bl bi14Y2hhbmdlLmNvbT4NCk9mZmljZSBAIFZpYSBUcmV2aXNvIDEyLCAxMDE0NCBUb3Jpbm8sIEl0 YWx5DQotLQ0KQWRkIG1haWxpbmcgbGlzdA0KQWRkQGlldGYub3JnPG1haWx0bzpBZGRAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FkZDxodHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fk ZF9fOyEhUElaZWVXNXdzY3luUlEhOFJkd0duZ0w3amRQYWctQWx2ZEtJSG1SYzNrSDZUX01lX3kt dEFTYlZHcVBnMjU3RVA3aGQ3RU96VjBtSVREciQ+DQo= --_000_39AB91D202F746188C5ED3ED062A8286nbcunicom_ Content-Type: text/html; charset="utf-8" Content-ID: <82D4F9899A234044A59672DF78F0328C@namprd14.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9z ZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTM5 MjMzOTQ0MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTc3MTUwMDk2OCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRoaXMgYWxsIGNvbWVzIGJhY2sgdG8g dGhlIHRocmVlIHNsaWNlcyBvZiBhY2Nlc3MgdHlwZXMgdGhhdCBoYWQgYmVlbiBkaXNjdXNzZWQg c29tZSBtb250aHMgYWdvOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIx Ij4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGlj YSI+VHJ1c3RlZCAmYW1wOyBrbm93biBuZXR3b3JrcyDigJMgdGhpcyBpcyB5b3VyIGVudGVycHJp c2UsIHlvdXIgaG9tZS4mbmJzcDsgWW91IGhhdmUgYSByZWxhdGlvbnNoaXAgd2l0aCB0aGVtLjxv OnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6SGVsdmV0aWNhIj5Vbmtub3duIG5ldHdvcmtzIOKAkyBUaGlzIGlzIHRoZSBjYWbD qSwgc2Nob29sLCBob3RlbCAtIHlvdSBjaG9vc2UgdGhlbSBiZWNhdXNlIHRoZXkgYXJlIGF2YWls YWJsZSwgYnV0IHlvdSBrbm93IHZlcnkgbGl0dGxlIHRvIG5vdGhpbmcgYWJvdXQgdGhlbS48bzpw PjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkhlbHZldGljYSI+SG9zdGlsZSBuZXR3b3JrcyDigJMgeW91IG1heSBub3QgaGF2ZSBh bnkgY2hvaWNlIGluIG5ldHdvcmsgYW5kIG11c3QgdXNlIHRoaXMgaXMgeW91IHdhbnQgYW55IElu dGVybmV0IGFjY2VzcyBhdCBhbGwuJm5ic3A7IEhvd2V2ZXIsIG5vdCBvbmx5IGRvIHlvdSBub3QN CiB0cnVzdCB0aGVtLCB5b3Uga25vdyB0aGV5IGFyZSBhY3RpdmVseSBhY3RpbmcgaW4gd2F5cyB5 b3UgZG8gbm90IHdhbnQuPG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkhlbHZldGljYSI+QW5vdGhlciBzbGljZSBhcm91bmQgdGhyZWF0IGxldmVscyB3b3Vs ZCBiZTogR3JlZW4sIFllbGxvdywgUmVkIG5ldHdvcmtzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2 ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPkNlcnRhaW5seSBpbiB0ZXJtcyBv ZiBwb2xpY3kgYW5kIHNlY3VyaXR5IGNvbmNlcm5zIG9uZSBzaXplIGRvZXMgbm90IGZpdCBhbGwg My4mbmJzcDsgVGhlIHF1ZXN0aW9uIGlzIGNhbiB3ZSBmYXNoaW9uIGEgZGlzY292ZXJ5IG1lYW5z IHRoYXQgd29ya3MgaW4gYWxsIDMsIGJ1dCBwZXJoYXBzIG1pdGlnYXRlcyB0aGUgcG9saWN5IGFu ZCBzZWN1cml0eSBjb25jZXJucw0KIGluIGVhY2g/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+REhDUCBtYXkgYmUgYSBwZXJmZWN0bHkgZmluZSBj aG9pY2UgaW4gYSBncmVlbiBuZXR3b3JrLCBidXQgaW4gYSB5ZWxsb3cgbmV0d29yayB0aGVyZSBp cyBhIG5lZWQgZm9yIHZhbGlkYXRpb24gYW5kIGFzc3VyYW5jZSBvZiB0aGUgY2hvaWNlLCB3aGls ZSBpbiBhIHJlZCBuZXR3b3JrIOKAkyBjYW4geW91IHRydXN0IGFueXRoaW5nIGF0IGFsbCwgZXZl bg0KIHRoaW5ncyB5b3UgZXhwbGljaXRseSBzcGVjaWZpZWQgc3VjaCBhcyBJUCBhZGRyZXNzIG9m IHJlc29sdmVycyB3aXRob3V0IHNvbWUgYWRkaXRpb25hbCB2YWxpZGF0aW9uID88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj4tZ2xlbm48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiA2LzMw LzIwLCAzOjA3IFBNLCAmcXVvdDtBZGQgb24gYmVoYWxmIG9mIEVyaWMgUmVzY29ybGEmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzphZGQtYm91bmNlc0BpZXRmLm9yZyI+YWRkLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ZWty QHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIFR1ZSwgSnVuIDMwLCAyMDIwIGF0IDI6MjQgUE0gVml0dG9y aW8gQmVydG9sYSAmbHQ7dml0dG9yaW8uYmVydG9sYT08YSBocmVmPSJtYWlsdG86NDBvcGVuLXhj aGFuZ2UuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBvcGVuLXhjaGFuZ2Uu Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPklsIDMwLzA2LzIw MjAgMTQ6NTggRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7IGhhIHNjcml0dG86DQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiBUdWUsIEp1biAzMCwg MjAyMCBhdCAyOjE5IEFNIFBhdWwgVml4aWUgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsQHJlZGJh cm4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF1bEByZWRiYXJuLm9yZzwvYT4mZ3Q7IHdyb3RlOg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+aSBoYXZlIGJhZGx5IG1pc3VuZGVyc3Rvb2QuIDxicj4NCjxicj4NCnRo ZSB3YXkgaSBrbm93IHRoYXQgdGhlIGlwIGFkZHJlc3MgcHJvdmlkZWQgYnkgdGhlIGlzcCB3YXMg ZGVsaXZlcmVkIHNlY3VyZWx5IDxicj4NCnRvZGF5IGlzIGJlY2F1c2Ugb2ZmLW5ldCBESENQIGZv cmdlcnkgaXMgaGFyZCwgPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPkxldCdzIHN0YXJ0IGhlcmU6IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgYWdy ZWUgdGhhdCBvZmYtbmV0IERIQ1AgZm9yZ2VyeSBpcyBoYXJkLiBIb3dldmVyLCBvbmNlIHlvdSBh c3N1bWUgdGhhdCB5b3UgYXJlIG9mZi1wYXRoLCB0aGVuIERvNTMgaW50ZXJjZXB0aW9uIGlzICph bHNvKiBoYXJkLiBTbyBmb3IgdGhpcyB0byBiZSB1c2VmdWwgeW91IG5lZWQgYW4gZW52aXJvbm1l bnQgaW4gd2hpY2ggdGhlIGF0dGFja2VyIGlzIGFibGUgdG8NCiBhdHRhY2sgRG81MyBidXQgKm5v dCogdG8gYXR0YWNrIERIQ1AuIFdoYXQgSSdtIGFza2luZyBmb3IgaXMgZm9yIHNvbWVvbmUgdG8g ZGVmaW5lIHRoYXQgdGhyZWF0IG1vZGVsIHByZWNpc2VseSBzbyB0aGF0IHdlIGNhbiBkZXNpZ24g cHJvdG9jb2xzIHRoYXQgbWF0Y2ggaXQuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBoYXZlIHdyaXR0ZW4gYW5kIGRlbGV0ZWQgdHdvIG9yIHRo cmVlIGxvbmdlciByZXBsaWVzIHRvIHRoaXMsIHNvIEkgd2lsbCBqdXN0IHF1b3RlIHdoYXQgRGFu aWVsIE1pZ2F1bHQgd3JvdGUgYSBmZXcgbWVzc2FnZXMgYWdvOiAmcXVvdDtUaGUgdGhyZWF0IG1v ZGVsIHNlZW1zIGZvciBDb21jYXN0IGFuZCB0aGUgZW5kIHVzZXIgaGF2aW5nIHRoZSB0cmFmZmlj IHJlZGlyZWN0ZWQNCiB0byBDbG91ZGZsYXJlIGluc3RlYWQgb2YgdGhlIGxvY2FsIHJlc29sdmVy LiZxdW90OyBCdXQgb2YgY291cnNlIHRoZSBiYXNpYyBpc3N1ZSBpcyB0aGF0IHdlIHNlZW0gdG8g ZGlzYWdyZWUgb24gd2hhdCBhIHRocmVhdCBpcy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Tm8sIEkgZG9uJ3Qg aW4gZmFjdCB0aGF0J3MgdGhlIGlzc3VlIGF0IGFsbC4gVG8gcmVjYXAsIHRoaXMgaXMgYSBzb2x1 dGlvbiBmb3IgYSB2ZXJ5IHNwZWNpZmljIHByb2JsZW0uIEknbSBub3Qgc3VnZ2VzdGluZyB0aGF0 IGl0J3MgYSBnZW5lcmljIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkhvd2V2ZXIsIHRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBvZiBwcm9w b3NhbHMgZm9yIG5vbWluYWxseSBnZW5lcmljIHNvbHV0aW9ucyBub25lIG9mIHdoaWNoIHNlZW0g dG8gY29tZSB3aXRoIGEgZnVsbHkgZGVmaW5lZCB0aHJlYXQgbW9kZWwuIEknbSB0cnlpbmcgdG8g Z2V0IHRvIHdoYXQgdGhhdCBtb2RlbCBpcy4gU3BlY2lmaWNhbGx5LCBJIGFncmVlIHRoYXQgaXQN CiB3b3VsZCBiZSBhIHVzZWZ1bCB0byBhbGxvdyBlbmRwb2ludCBkZXZpY2VzIHRvIHNlY3VyZWx5 IGxlYXJuIHRoZSBpZGVudGl0eSBvZiB0aGUgRG9bSFRdIHNlcnZlciBhc3NvY2lhdGVkIHdpdGgg dGhlaXIgbG9jYWwgbmV0d29yayBbMF0uIFRoaXMgd291bGQgdGhlbiBhbGxvdyB5b3UgdG8gZ2V0 IHByaXZhdGUgcmVzb2x1dGlvbiBldmVuIGlmIHRoZXJlIHdlcmUgYXR0YWNrZXJzIG9uIHRoZSBu ZXR3b3JrIChhcyBpbiBjbGFzc2ljYWwgRXRoZXJuZXQNCiBvciB1bmVuY3J5cHRlZCBXaUZpKS4g SG93ZXZlciwgZXZlbiB3aXRoIHRoYXQgb2JqZWN0aXZlLCB3ZSBzdGlsbCBuZWVkIHRvIGRlZmlu ZSBhIHJlYWxpc3RpYyBzZXQgb2YgYXR0YWNrZXIgY2FwYWJpbGl0aWVzIGFuZCB0aGVuIGEgZGVz aWduIHdoaWNoIGlzIHNlY3VyZSBnaXZlbiB0aG9zZSBjYXBhYmlsaXRpZXMuIFRoYXQgaXMgd2hh dCBJIGFtIGFza2luZyBmb3IuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPlswXSBVbmRlciB0aGUgYXNzdW1wdGlvbiB0aGF0IHlvdSBhcmUgY29ubmVjdGluZyB0byB0 aGUgcmlnaHQgbmV0d29yaywgb2YgY291cnNlLCB3aGljaCBpcyBzb21ldGltZXMgYSB2ZXJ5IHRo aW4gYXNzdW1wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0tIDxvOnA+PC9vOnA+PC9wPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Vml0dG9yaW8gQmVydG9sYSB8IEhlYWQgb2Yg UG9saWN5ICZhbXA7IElubm92YXRpb24sIE9wZW4tWGNoYW5nZTxicj48YSBocmVmPSJtYWlsdG86 dml0dG9yaW8uYmVydG9sYUBvcGVuLXhjaGFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+dml0dG9y aW8uYmVydG9sYUBvcGVuLXhjaGFuZ2UuY29tPC9hPiA8YnI+T2ZmaWNlIEAgVmlhIFRyZXZpc28g MTIsIDEwMTQ0IFRvcmlubywgSXRhbHk8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tLSA8YnI+DQpB ZGQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkFkZEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPkFkZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FkZF9fOyEh UElaZWVXNXdzY3luUlEhOFJkd0duZ0w3amRQYWctQWx2ZEtJSG1SYzNrSDZUX01lX3ktdEFTYlZH cVBnMjU3RVA3aGQ3RU96VjBtSVREciQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FkZDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_39AB91D202F746188C5ED3ED062A8286nbcunicom_-- From nobody Tue Jun 30 17:52:09 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A443A0842 for ; Tue, 30 Jun 2020 17:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnaVQ949wn6C for ; Tue, 30 Jun 2020 17:52:05 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 5A8F63A0841 for ; Tue, 30 Jun 2020 17:52:05 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id f5so9005757ljj.10 for ; Tue, 30 Jun 2020 17:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qm8OdnpLBxyRwSqlYNtIZSRdRMCATanWtJYqP4sXIHI=; b=sS43A9qsqkuP/lGUWjIk2fHQS7b+ZzIHUaCK4t9VF5A7bmSw+j0/O9Ad6EfH5FuPqR z54qP8l4YxH+qZzfNmkVFy2QYtMPpw9WMNY9XwRkC+Ykv+gOhdX/6xHB3QW/LJ/qK9Rq +xh/Vv5acmX3xa1o+Q4bgtrx/7lgx8wSR3g7NceRMQcy+8b1ZJmNnNGJx9cfQ0l77f+7 QJjojlRZKyxSiCRB0OwPI0vkoqEH+AasZXKsx9e+VJV6i2ct1Pm5dkIffG8vgpa8YS9R fwHFZsMx4Js6BlV0IlYUxr1D3jxPto/yjmeaOf8jXBC/ltc5h/qOBCX0rOzV/ifTBgH2 gdRg== 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:to:cc; bh=qm8OdnpLBxyRwSqlYNtIZSRdRMCATanWtJYqP4sXIHI=; b=JKfQ0VaCq0Z7lVkoMfACsyP3hBk6d7ok3J+fHs0tvmTt+p65pw0OmkEnPal9mKKi7+ LpIa/qmYDrzRumU8bm+bY5KYYQVxkfiehguzUL8yWHnEhdz7jAflI08O7o9AW+92NUuJ PDSQBkEZFOPrP0krUOAyfoC78bJc+mB+y4KBY6ZIMvQFUdGwAXD7HPOtAWWWFw/vTLYB TMa+0taTIUZBT2EoqlWIOnek7qsja7sMvcHDPdXddzhOSjc2JQqwcWFcndNbDD7kTdrq NYW3POptOL1545cbsP2Plb17uuasWck4Dw1askWITCIvXvEP0NagmzfMYwS/mqTQnOqQ S01g== X-Gm-Message-State: AOAM532avQKWqiibJ+1+R4+ZUKrj915B+T3LL/4sf0htsnTqlThIfZjR HahtvywHe/UTLw67ZpNixOLp0wPEo53xDrxf6+Ugew== X-Google-Smtp-Source: ABdhPJwU1vBKyu/LU5Ccyam9h73GIeV2v0F6yi8KFGayJ6xkMhcqUKYcp8uHNO4yuh34nXCOE7IC06jzgqvb8ksYk6o= X-Received: by 2002:a2e:9510:: with SMTP id f16mr12175727ljh.199.1593564723435; Tue, 30 Jun 2020 17:52:03 -0700 (PDT) MIME-Version: 1.0 References: <39AB91D2-02F7-4618-8C5E-D3ED062A8286@nbcuni.com> In-Reply-To: <39AB91D2-02F7-4618-8C5E-D3ED062A8286@nbcuni.com> From: Eric Rescorla Date: Tue, 30 Jun 2020 17:51:27 -0700 Message-ID: To: "Deen, Glenn (NBCUniversal)" Cc: Vittorio Bertola , ADD Mailing list , Paul Vixie Content-Type: multipart/alternative; boundary="00000000000044692f05a956b37b" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 00:52:08 -0000 --00000000000044692f05a956b37b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 30, 2020 at 4:25 PM Deen, Glenn (NBCUniversal) < Glenn.Deen@nbcuni.com> wrote: > This all comes back to the three slices of access types that had been > discussed some months ago: > > > > 1. Trusted & known networks =E2=80=93 this is your enterprise, your ho= me. You > have a relationship with them. > 2. Unknown networks =E2=80=93 This is the caf=C3=A9, school, hotel - y= ou choose > them because they are available, but you know very little to nothing a= bout > them. > 3. Hostile networks =E2=80=93 you may not have any choice in network a= nd must > use this is you want any Internet access at all. However, not only do= you > not trust them, you know they are actively acting in ways you do not w= ant. > > > > Another slice around threat levels would be: Green, Yellow, Red networks > > > > Certainly in terms of policy and security concerns one size does not fit > all 3. The question is can we fashion a discovery means that works in al= l > 3, but perhaps mitigates the policy and security concerns in each? > > > > DHCP may be a perfectly fine choice in a green network, but in a yellow > network there is a need for validation and assurance of the choice, while > in a red network =E2=80=93 can you trust anything at all, even things you > explicitly specified such as IP address of resolvers without some > additional validation ? > This is a great taxonomy. Thanks. I think the question I would ask is: in a green network, how much benefit do you get from Do[HT]? We can probably divide this up into the local network environment (e.g., the wireless network) and the access link from the ISP. On the local network, it seems like the fate of DHCP and Do[HT] is kind of similar, so it's not clear to me how much value you are getting here. For the access link, it seems like there is value, but it would also quite possibly be easier to just tunnel the traffic over that link from the access router, in which case you don't need discovery. -Ekr > > -glenn > > > > On 6/30/20, 3:07 PM, "Add on behalf of Eric Rescorla" < > add-bounces@ietf.org on behalf of ekr@rtfm.com> wrote: > > > > > > > > On Tue, Jun 30, 2020 at 2:24 PM Vittorio Bertola 40open-xchange.com@dmarc.ietf.org> wrote: > > > > Il 30/06/2020 14:58 Eric Rescorla ha scritto: > > > > On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie wrote: > > i have badly misunderstood. > > the way i know that the ip address provided by the isp was delivered > securely > today is because off-net DHCP forgery is hard, > > > > Let's start here: > > I agree that off-net DHCP forgery is hard. However, once you assume that > you are off-path, then Do53 interception is *also* hard. So for this to b= e > useful you need an environment in which the attacker is able to attack Do= 53 > but *not* to attack DHCP. What I'm asking for is for someone to define th= at > threat model precisely so that we can design protocols that match it. > > I have written and deleted two or three longer replies to this, so I will > just quote what Daniel Migault wrote a few messages ago: "The threat mode= l > seems for Comcast and the end user having the traffic redirected to > Cloudflare instead of the local resolver." But of course the basic issue = is > that we seem to disagree on what a threat is. > > > > No, I don't in fact that's the issue at all. To recap, this is a solution > for a very specific problem. I'm not suggesting that it's a generic > solution. > > > > However, there have been a number of proposals for nominally generic > solutions none of which seem to come with a fully defined threat model. I= 'm > trying to get to what that model is. Specifically, I agree that it would = be > a useful to allow endpoint devices to securely learn the identity of the > Do[HT] server associated with their local network [0]. This would then > allow you to get private resolution even if there were attackers on the > network (as in classical Ethernet or unencrypted WiFi). However, even wit= h > that objective, we still need to define a realistic set of attacker > capabilities and then a design which is secure given those capabilities. > That is what I am asking for. > > > > -Ekr > > > > [0] Under the assumption that you are connecting to the right network, of > course, which is sometimes a very thin assumption. > > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > > > --00000000000044692f05a956b37b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 30, 2020 at 4:25 PM Deen,= Glenn (NBCUniversal) <Glenn.De= en@nbcuni.com> wrote:

This all comes= back to the three slices of access types that had been discussed some mont= hs ago:

=C2=A0<= u>

  1. Trusted & known networks= =E2=80=93 this is your enterprise, your home.=C2=A0 You have a relationshi= p with them.
  2. Unknown networks =E2=80=93 This is the caf=C3=A9, school, hotel -= you choose them because they are available, but you know very little to no= thing about them.
  3. Hostile networks =E2=80=93 you may not have any choice in ne= twork and must use this is you want any Internet access at all.=C2=A0 Howev= er, not only do you not trust them, you know they are actively acting in ways you do not want.<= /u>

=C2=A0<= u>

Another slice = around threat levels would be: Green, Yellow, Red networks

=C2=A0

Certainly in t= erms of policy and security concerns one size does not fit all 3.=C2=A0 The= question is can we fashion a discovery means that works in all 3, but perh= aps mitigates the policy and security concerns in each?

=C2=A0<= u>

DHCP may be a = perfectly fine choice in a green network, but in a yellow network there is = a need for validation and assurance of the choice, while in a red network = =E2=80=93 can you trust anything at all, even things you explicitly specified such as IP address of resolvers without so= me additional validation ?


This is a great taxonomy. Thanks.

I think = the question I would ask is: in a green network, how much benefit do you ge= t from Do[HT]? We can probably divide this up into the local network enviro= nment (e.g., the wireless network) and the access link from the ISP.
<= div>
On the local network, it seems like the fate of DHCP and= Do[HT] is kind of similar, so it's not clear to me how much value you = are getting here.
For the access link, it seems like there is val= ue, but it would also quite possibly be easier to just tunnel the traffic o= ver that link from the access router, in which case you don't need disc= overy.

-Ekr

=C2=A0<= u>

-glenn<= u>

=C2=A0<= u>

On 6/30/20, 3:07 PM, &qu= ot;Add on behalf of Eric Rescorla" <add-bounces@ietf.org on behalf of ekr@rtfm.com> wrot= e:

=C2=A0

=C2=A0

=C2=A0

On Tue, Jun 30, 2020 at = 2:24 PM Vittorio Bertola <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.o= rg> wrote:

=C2=A0

Il 30/06/2020 14:58 Eric= Rescorla <ekr@rtfm.co= m> ha scritto:

=C2=A0

On Tue, Jun 30, 2020 at = 2:19 AM Paul Vixie <paul@redbarn.org> wrote:

i have badly misundersto= od.

the way i know that the ip address provided by the isp was delivered secure= ly
today is because off-net DHCP forgery is hard,

=C2=A0

Let's start here:

I agree that off-net DHC= P forgery is hard. However, once you assume that you are off-path, then Do5= 3 interception is *also* hard. So for this to be useful you need an environ= ment in which the attacker is able to attack Do53 but *not* to attack DHCP. What I'm asking for is for someo= ne to define that threat model precisely so that we can design protocols th= at match it.

I have written and delet= ed two or three longer replies to this, so I will just quote what Daniel Mi= gault wrote a few messages ago: "The threat model seems for Comcast an= d the end user having the traffic redirected to Cloudflare instead of the local resolver." But of course the basic= issue is that we seem to disagree on what a threat is.

=C2=A0

No, I don't in fact = that's the issue at all. To recap, this is a solution for a very specif= ic problem. I'm not suggesting that it's a generic solution.=

=C2=A0

However, there have been= a number of proposals for nominally generic solutions none of which seem t= o come with a fully defined threat model. I'm trying to get to what tha= t model is. Specifically, I agree that it would be a useful to allow endpoint devices to securely learn the identity= of the Do[HT] server associated with their local network [0]. This would t= hen allow you to get private resolution even if there were attackers on the= network (as in classical Ethernet or unencrypted WiFi). However, even with that objective, we still need to = define a realistic set of attacker capabilities and then a design which is = secure given those capabilities. That is what I am asking for.

=C2=A0

-Ekr

=C2=A0

[0] Under the assumption= that you are connecting to the right network, of course, which is sometime= s a very thin assumption.

-- 

Vittorio Bertola | Head of Policy & In=
novation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Vi=
a Treviso 12, 10144 Torino, Italy

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add=

--00000000000044692f05a956b37b-- From nobody Tue Jun 30 18:05:03 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0E23A085A for ; Tue, 30 Jun 2020 18:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 U7tayLeEUqQz for ; Tue, 30 Jun 2020 18:05:00 -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 636B03A0859 for ; Tue, 30 Jun 2020 18:05:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49xNLJ4h5YzLkX; Wed, 1 Jul 2020 03:04:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1593565496; bh=nyVrdb2WZeinMXZ6uLuR6wafAgknOxET0K5fJevJYgE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dP9gpy6QD5oMw9HxFjRvAryM05QpUO/foSC79YFFB++4Qn9YQ39xU1eRmGHV+zCrC fSFo/L51molp4zRVIULQ2FRVZEETZAs6eR/D9V/yMw7IWh1UhN8InVIWvNZPEcru2F KLyWAjqYg0erZRd/Gbz5RAR2t04POFjyeNDACiSQ= 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 hiB6AAtOAYOx; Wed, 1 Jul 2020 03:04:55 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 1 Jul 2020 03:04:55 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B9CFE6020EE7; Tue, 30 Jun 2020 01:09:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B16E666ADE; Tue, 30 Jun 2020 01:09:21 -0400 (EDT) Date: Tue, 30 Jun 2020 01:09:21 -0400 (EDT) From: Paul Wouters To: Martin Thomson cc: add@ietf.org In-Reply-To: <10fa5a67-1894-4bc5-9090-4d4f5aeb2242@www.fastmail.com> Message-ID: References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> <26559974.PdTMpzyJZD@linux-9daj> <18350.1593475069@localhost> <516fcd85-2d67-e853-03b5-49220df9d878@huitema.net> <10fa5a67-1894-4bc5-9090-4d4f5aeb2242@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 01:05:02 -0000 On Tue, 30 Jun 2020, Martin Thomson wrote: > I'm not super close to this, but my understanding is that we now have two resolution paths: one native and one for DoH. That would be unfortunate if true. Making the resolving code and results different based on the _transport_ of the same DNS data is asking for a lot of complicated bug reports and confused users. Imagine needing to tell your users for some websites you need to enable DoH and for some websites you need to disable DoH..... Paul From nobody Tue Jun 30 18:10:01 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581573A085C for ; Tue, 30 Jun 2020 18:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 eawE1AzfOsbK for ; Tue, 30 Jun 2020 18:09:59 -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 E07F33A085B for ; Tue, 30 Jun 2020 18:09:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49xNS523X2zLkS; Wed, 1 Jul 2020 03:09:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1593565797; bh=CCQJQZ6wqNqUytvkahpzv6dC+Y8LzNBfVB4wlRkdPVc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TCK3nwHl17byOjXvPv21TsEdTOL2CyEuzf0OKunHEWCDSPPaCqIsvtC54F+9rOybc /2tlVZpM0Nz2Ag4TfngfqSx0Lh3jVIGdFXuaaV0PCDrpTEnxfAwRxDb4mDC7tLNSwl odaaxWJogoW/4NZAJOH6+szdUm+fs8F8TfFjKFC4= 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 DwsWVI02SpfI; Wed, 1 Jul 2020 03:09:56 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 1 Jul 2020 03:09:56 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C15966020EC4; Mon, 29 Jun 2020 20:34:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B8A3B66ADE; Mon, 29 Jun 2020 20:34:46 -0400 (EDT) Date: Mon, 29 Jun 2020 20:34:46 -0400 (EDT) From: Paul Wouters To: Paul Vixie cc: ADD Mailing list In-Reply-To: <26559974.PdTMpzyJZD@linux-9daj> Message-ID: References: <7325C546-587D-4CD9-8059-0887C33F3503@cable.comcast.com> <26559974.PdTMpzyJZD@linux-9daj> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Add] Comparative DoH Discovery DNS RR Types X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 01:10:00 -0000 On Mon, 29 Jun 2020, Paul Vixie wrote: > if on the other hand we're going to continue to evolve DNS in ways that > include adding new RR types, and all the initiators who are stuck behind > dumbass middleboxes who reject or butcher unknown RR types are going to fail > hard and be excluded from the new applications and protocols in order to put > more pressure on middlebox users/makers/distributors, we should say that. I fully agree with Paul V here, but I do want to point out that in this case, we _might_ want an exception to this because this is a mechanism to find and get to a well working modern DNS resolver. We are specifically using some crappy old hotspot technology DNS to gain access to proper DNS. For everything else, I agree to just do the RRTYPE. And once we have the mechanism to get to a proper modern DNS resolver, never come to IETF again with proposals that hack or overload existing RRTYPEs. And even in this case, perhaps we should insist on defining both, so we can kill the hack in 10-15 years. Paul From nobody Tue Jun 30 20:31:19 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8B83A0AA3 for ; Tue, 30 Jun 2020 20:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 kNH0X8UJdmq8 for ; Tue, 30 Jun 2020 20:31:15 -0700 (PDT) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 234843A0A9D for ; Tue, 30 Jun 2020 20:31:15 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id k23so23393262iom.10 for ; Tue, 30 Jun 2020 20:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OA46arNKnn1vr5BbmQ8atogXiAc0KgiqGsyo+NPzc4w=; b=IIR+U93YDWNJIV04Ojd3zmkzzZexZwg1bXJHJLJXtqOFk9k8OIKtoAFKVM616qx+tl t9sJTk44sC0ozivhYMgKgY3JfgOBJErBLFIsjVmaXFF3j4OPyINTl/88lho+oawpM6p6 zvgdmtWdXD+N0OMTEzQ42T9F8QEw3+inv3NGWd8m60D9Z7f1LtcB3LV3qjzam5Vbkb49 6jhfn/MubjEdKRKhcv975gdyc/PpwX2kcwKX0LMajEvwQXIstlyhoVu4gV8ToJ1MeKHn igWP7Pdn5bvfOWowuV0V0GwF0eLk2EAPKRKTqBoKi7jotil9SnJTsxpF9/Hw51nAxXFn jmOA== 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:to:cc; bh=OA46arNKnn1vr5BbmQ8atogXiAc0KgiqGsyo+NPzc4w=; b=TxK4otsT1RHUFpnljW8C6prIgopV4iSRKG3BUwrI4uih59BgFqEbUJrBWecalBT4Mk pVdHs25M9mA1r9sifcBlq29JZeJED9Oq8Hq86kLkwPwXd/acrAO+PCDiigUmu6R1kc4V oomHgUXPLFFRN4aE33mEV56jCJMVrh2bgicOJhhS/XMJ2C171yY7gR2T2aEbfTbtrfal GfSFJxYzfuM7YDqOOflmA8Eb4f7izc1O4YNVrMAmrjdGNjRBYAe21JEZ1GZktdV/7Ifb fC5AZ7AQMS/CHopJ7KsstKs07FwuRaDfe1aqz6IxALgaDkmUXbk9dH4UqsFgRapxqnLw fnDg== X-Gm-Message-State: AOAM533QrGWKOAz076DU2G2KG204BnKnjbI/bxd7ewo4MvgsHs6rR3rU 70pzmLkoXl/20zrogqbqGmcLxafI058ch+z+kgg= X-Google-Smtp-Source: ABdhPJw8wEo48YfFLr+87fxUiYtLRsMFfB+vtTZuxB8zx/JBa2/FsY+/qT+eRaJdUbF1mewhXEc8n10n1Z2ufNKflCE= X-Received: by 2002:a5e:9705:: with SMTP id w5mr225697ioj.188.1593574274334; Tue, 30 Jun 2020 20:31:14 -0700 (PDT) MIME-Version: 1.0 References: <39AB91D2-02F7-4618-8C5E-D3ED062A8286@nbcuni.com> In-Reply-To: From: Rob Sayre Date: Tue, 30 Jun 2020 20:31:00 -0700 Message-ID: To: Eric Rescorla Cc: "Deen, Glenn (NBCUniversal)" , ADD Mailing list , Paul Vixie , Vittorio Bertola Content-Type: multipart/alternative; boundary="0000000000008b82fc05a958ec57" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 03:31:17 -0000 --0000000000008b82fc05a958ec57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 30, 2020 at 5:52 PM Eric Rescorla wrote: > > > On Tue, Jun 30, 2020 at 4:25 PM Deen, Glenn (NBCUniversal) < > Glenn.Deen@nbcuni.com> wrote: > >> This all comes back to the three slices of access types that had been >> discussed some months ago: >> >> >> >> 1. Trusted & known networks =E2=80=93 this is your enterprise, your h= ome. >> You have a relationship with them. >> 2. Unknown networks =E2=80=93 This is the caf=C3=A9, school, hotel - = you choose >> them because they are available, but you know very little to nothing = about >> them. >> 3. Hostile networks =E2=80=93 you may not have any choice in network = and must >> use this is you want any Internet access at all. However, not only d= o you >> not trust them, you know they are actively acting in ways you do not = want. >> >> >> >> Another slice around threat levels would be: Green, Yellow, Red networks >> >> >> >> Certainly in terms of policy and security concerns one size does not fit >> all 3. The question is can we fashion a discovery means that works in a= ll >> 3, but perhaps mitigates the policy and security concerns in each? >> >> >> >> DHCP may be a perfectly fine choice in a green network, but in a yellow >> network there is a need for validation and assurance of the choice, whil= e >> in a red network =E2=80=93 can you trust anything at all, even things yo= u >> explicitly specified such as IP address of resolvers without some >> additional validation ? >> > > This is a great taxonomy. Thanks. > > I think the question I would ask is: in a green network, how much benefit > do you get from Do[HT]? We can probably divide this up into the local > network environment (e.g., the wireless network) and the access link from > the ISP. > There are lots of attacks that create compromised "Green" networks. For example: https://www.zdnet.com/article/brazil-is-at-the-forefront-of-a-new-type-of-r= outer-attack I might categorize an "enterprise" network as something managed well enough to do an investigation in the event of a security breach. Most business and home networks do not fit this definition, so they are category 2 ("Yellow"), because people set them up and forget them. thanks, Rob --0000000000008b82fc05a958ec57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 30, 2020 at 5:52 PM Eric Resc= orla <ekr@rtfm.com> wrote:


On Tue, Jun 30, 2020 at 4:25 PM = Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com> wrote:

This all comes= back to the three slices of access types that had been discussed some mont= hs ago:

=C2=A0<= u>

  1. Trusted= & known networks =E2=80=93 this is your enterprise, your home.=C2=A0 Y= ou have a relationship with them.
  2. Unknown networks =E2=80= =93 This is the caf=C3=A9, school, hotel - you choose them because they are= available, but you know very little to nothing about them.
  3. Hostile networks =E2=80=93 you may not have any choice in network and mu= st use this is you want any Internet access at all.=C2=A0 However, not only= do you not trust them, you know they are actively acting in ways you do not want.<= /u>

=C2=A0<= u>

Another slice = around threat levels would be: Green, Yellow, Red networks

=C2=A0

Certainly in t= erms of policy and security concerns one size does not fit all 3.=C2=A0 The= question is can we fashion a discovery means that works in all 3, but perh= aps mitigates the policy and security concerns in each?

=C2=A0<= u>

DHCP may be a = perfectly fine choice in a green network, but in a yellow network there is = a need for validation and assurance of the choice, while in a red network = =E2=80=93 can you trust anything at all, even things you explicitly specified such as IP address of resolvers without so= me additional validation ?


This is a great taxonomy. Thanks.

I think = the question I would ask is: in a green network, how much benefit do you ge= t from Do[HT]? We can probably divide this up into the local network enviro= nment (e.g., the wireless network) and the access link from the ISP.=C2=A0
=

There are lots of attacks that create compromised "= ;Green" networks. For example:


I might categorize an = "enterprise" network as something managed well enough to do an in= vestigation in the event of a security breach. Most business and home netwo= rks do not fit this definition, so they are category 2 ("Yellow")= , because people set them up and forget them.

than= ks,
Rob

--0000000000008b82fc05a958ec57-- From nobody Tue Jun 30 21:01:29 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F59C3A0B45 for ; Tue, 30 Jun 2020 21:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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=nbcuni.onmicrosoft.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 R7ULA3NgqBBW for ; Tue, 30 Jun 2020 21:01:26 -0700 (PDT) Received: from mx0a-00176a04.pphosted.com (mx0b-00176a04.pphosted.com [67.231.157.49]) (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 1DC5F3A0B33 for ; Tue, 30 Jun 2020 21:01:25 -0700 (PDT) Received: from pps.filterd (m0048207.ppops.net [127.0.0.1]) by m0048207.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 0613qPFf007459 for ; Wed, 1 Jul 2020 00:01:25 -0400 Received: from usecmgip001.mail.tfayd.com ([50.228.147.33]) by m0048207.ppops.net-00176a04. with ESMTP id 31x1cfe531-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 01 Jul 2020 00:01:24 -0400 IronPort-SDR: KiGAjnIQTfLe1/VwDPkuOSz6ax6PIUlA+rFoQtnpVRo1KcpaxrhfKFZZI7Al1Tm5cbVboBbJl0 yZM5PzqUtDEw== Received: from unknown (HELO potemwp00006.mail.tfayd.com) ([100.124.56.30]) by USECMGIP001.mail.tfayd.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 01 Jul 2020 00:01:23 -0400 Received: from potemwp00001.mail.tfayd.com (100.124.56.25) by potemwp00004.mail.tfayd.com (100.124.56.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5; Tue, 30 Jun 2020 22:01:22 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (10.40.33.204) by potemwp00001.mail.tfayd.com (100.124.56.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5 via Frontend Transport; Tue, 30 Jun 2020 22:01:22 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lcGAZQrauNJR/R3PhLzcI0hlGfn8AYGTncOcQM2hO+wy4PllGW/XwiRTa7HMPLQTovyH25W8aWa1jRc1+Q/bj7rGN3ls7j+mR4zKzPkhQ+sIAR0ZderDRbaUKrC27vu4ETTiTgj08bjB1Kr5rV9ZievK5iEVYVXwG0NKZZqFOV40wQZY/D7zQt8tNm2pL6laJYJh6JSantCKVIuUrIyn5jE0roiIK/A+ziNEQmdpKq5uN6r/Y/tJhucFHUJQi8FnvrFzZKl2ruyzCReDOsXb8Lt0wp2e0O9ZvL1S5a/f0/M27DPnthWLK3GnqFSj0ZZG88anGuYsIRHmLad1S27ozw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cW+7hvj5YkYP1lmbD3S4PZB9YxFdgocUHKTbH7dGlrE=; b=X4jOKtxXydj9r4DglWApKq9fawMQOa6VPMVg2koIQTTIxc42N0PwSSYcmYkxvTOWM4qcgK3ZaI/crBUfxnHLRzvO11DKN9PQZzgDDIFut/A3QOSF3H7nZ5dLadgjI6mqyuFfvr/6MsXR0mzdDhjv0VHV+Zhzzmd8kwcVC+biRcelClrboO63MPqarnmgGGWcY1WWDBrrX47rN7eQ7iV8QUgdvy11Q+rNdCHsdyfr8yIPEGISb++QHaHYuqI/AQTEaO/YvCbeLA7NEG4itbKSW3U/jflgO2ttUhcF27gE8/pvepnOzyye1NNX1Z7aYn1rxOoBBh8oRIK5/BwYPF5pHg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cW+7hvj5YkYP1lmbD3S4PZB9YxFdgocUHKTbH7dGlrE=; b=JnrZ+SKQ7Ny8ZVFRVn6xLfws11x22Xot0ixo6EQ08dyiF+v5WF4mLynOfLa/LDo1St2/IHggLp2zqILI+mx1HBT4zz2/nMBt6iFHDprIl+XAsZROvSh3ZC7yhbbAWgkN5ZGdTWDxogc6seojs5f3pxoNFjIkh8eA1HL/gKcCTok= Received: from BYAPR14MB3094.namprd14.prod.outlook.com (20.179.154.222) by BYAPR14MB2246.namprd14.prod.outlook.com (52.135.221.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.21; Wed, 1 Jul 2020 04:01:20 +0000 Received: from BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::e074:901e:d085:be5c]) by BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::e074:901e:d085:be5c%7]) with mapi id 15.20.3131.027; Wed, 1 Jul 2020 04:01:20 +0000 From: "Deen, Glenn (NBCUniversal)" To: Rob Sayre CC: Eric Rescorla , ADD Mailing list , Paul Vixie , Vittorio Bertola Thread-Topic: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers Thread-Index: AQHWT1xH0VpuIEHuFEipTxkNL6pkCg== Date: Wed, 1 Jul 2020 04:01:20 +0000 Message-ID: <94C306DF-A9D9-4FAC-8C4B-AE3E90E29417@nbcuni.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nbcuni.com; dkim=none (message not signed) header.d=none;nbcuni.com; dmarc=none action=none header.from=nbcuni.com; x-originating-ip: [2605:e000:141b:121:c55f:110a:b52e:3b03] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4e30a166-40ad-4ea4-5fb2-08d81d7369c9 x-ms-traffictypediagnostic: BYAPR14MB2246: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04519BA941 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LqHiC4CJG/SRRYn92suO5fyMX3HHDq5R0AmNxiL+q55cTfd1BbBrsENxXFAJjCHfrymJ21yVN9vCK0U+fKyLZhVFSCJe1leqTCfiwqUns4ZGWyMZYzP9QSGFpRbjl011UPFa/EEkBVqBKl4PJrY1l5rapIYxJR7iOHMu62OahB0niiz/4+1WTPqzqbtvwZKS2Oj13GBDJwYNeOhCT+DxcV3zEl81fTDQyRfeFlIfpWLrRsFwV1juxnIfOvYVlw3k3Mn2P9WpRyoBV5kh0w4HA8k5IvEy2kcS77lFKP3R43sh3U/sr9TYs7E59h/uguioYGagcWpgcZ1pi/Rli9OXLVpvhlgx+B+PKVn3cGEmzC7IISDjO+N2U8Nz207nJJZ3YxAfLH4+rEzzeSa3jT3DHA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR14MB3094.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(346002)(376002)(136003)(396003)(966005)(478600001)(2906002)(186003)(166002)(76116006)(66946007)(66476007)(86362001)(66446008)(66556008)(33656002)(64756008)(5660300002)(316002)(71200400001)(36756003)(6916009)(66574015)(2616005)(6506007)(4326008)(53546011)(6512007)(6486002)(83380400001)(8936002)(54906003)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: mMWdvZ1Kmn5T0zk7dDLK34Xr4r3cQ6FI2Cx9wPKmb7RMkxMBnhQMOhHu0sYblDXLeIQ1e+AMbAziv20ZzZhKoJrFoCrr7Q2HcXYZ81xkAjnkVUtqgNTOsk/Mujj6Kt/vTaN+/O71vSQah9IifqstRK1VsPvCjcOZwX70CYOjm3t+rvtOdKVl/rukirk984tSVIZzqIP23rlMyxio1mz/mNKuswVLfXoFXxRvn4tTPPzgP3nIalZIv4T6f7Fu07OosYG4PpQKt0FdxhWocMs7kLysS2kXvnI56nCs2pbDiG/Lcy/u7tifsxw/beNbTAMa+EpXW/IVI53htT34MvsE9vXoY9jqqhwZjIQNtnVinwNQ8mVDWFKRc4COerQ2gWMBf3L/6Zcstd4jYO8v60DOjBziJEuKddlGJkvTicBmYHz+spsjIN21PplqzzU7qfL0OEKCu0eY/i3prJvrPeWEg5Te3ljMKtVlaDh9exHl4lj8wC7+8DZy2RjawxFvCgvPOVdOxPqHfQCKcr6MK4DQatYseJezCEcKCjaj3Cz8DX/fgztrOzQiAdCTQ/orYKia Content-Type: multipart/alternative; boundary="_000_94C306DFA9D94FAC8C4BAE3E90E29417nbcunicom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR14MB3094.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e30a166-40ad-4ea4-5fb2-08d81d7369c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2020 04:01:20.3666 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nneoxJetHvlHRZyfz2EQu6p1HHaxY9yZAGby63asmTsIk4dQmo0pyUArJ1uXaYspOeOKmGNzmm43nWtQ3BZsoA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR14MB2246 X-OriginatorOrg: nbcuni.com X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-01_01:2020-07-01, 2020-06-30 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 mlxlogscore=999 cotscore=-2147483648 mlxscore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 adultscore=0 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007010024 Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 04:01:29 -0000 --_000_94C306DFA9D94FAC8C4BAE3E90E29417nbcunicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KDQpPbiBKdW4gMzAsIDIwMjAsIGF0IDg6MzEgUE0sIFJvYiBTYXlyZSA8c2F5cmVyQGdt YWlsLmNvbT4gd3JvdGU6DQoNCu+7vw0KT24gVHVlLCBKdW4gMzAsIDIwMjAgYXQgNTo1MiBQTSBF cmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0K DQoNCk9uIFR1ZSwgSnVuIDMwLCAyMDIwIGF0IDQ6MjUgUE0gRGVlbiwgR2xlbm4gKE5CQ1VuaXZl cnNhbCkgPEdsZW5uLkRlZW5AbmJjdW5pLmNvbTxtYWlsdG86R2xlbm4uRGVlbkBuYmN1bmkuY29t Pj4gd3JvdGU6DQpUaGlzIGFsbCBjb21lcyBiYWNrIHRvIHRoZSB0aHJlZSBzbGljZXMgb2YgYWNj ZXNzIHR5cGVzIHRoYXQgaGFkIGJlZW4gZGlzY3Vzc2VkIHNvbWUgbW9udGhzIGFnbzoNCg0KDQog IDEuICBUcnVzdGVkICYga25vd24gbmV0d29ya3Mg4oCTIHRoaXMgaXMgeW91ciBlbnRlcnByaXNl LCB5b3VyIGhvbWUuICBZb3UgaGF2ZSBhIHJlbGF0aW9uc2hpcCB3aXRoIHRoZW0uDQogIDIuICBV bmtub3duIG5ldHdvcmtzIOKAkyBUaGlzIGlzIHRoZSBjYWbDqSwgc2Nob29sLCBob3RlbCAtIHlv dSBjaG9vc2UgdGhlbSBiZWNhdXNlIHRoZXkgYXJlIGF2YWlsYWJsZSwgYnV0IHlvdSBrbm93IHZl cnkgbGl0dGxlIHRvIG5vdGhpbmcgYWJvdXQgdGhlbS4NCiAgMy4gIEhvc3RpbGUgbmV0d29ya3Mg 4oCTIHlvdSBtYXkgbm90IGhhdmUgYW55IGNob2ljZSBpbiBuZXR3b3JrIGFuZCBtdXN0IHVzZSB0 aGlzIGlzIHlvdSB3YW50IGFueSBJbnRlcm5ldCBhY2Nlc3MgYXQgYWxsLiAgSG93ZXZlciwgbm90 IG9ubHkgZG8geW91IG5vdCB0cnVzdCB0aGVtLCB5b3Uga25vdyB0aGV5IGFyZSBhY3RpdmVseSBh Y3RpbmcgaW4gd2F5cyB5b3UgZG8gbm90IHdhbnQuDQoNCkFub3RoZXIgc2xpY2UgYXJvdW5kIHRo cmVhdCBsZXZlbHMgd291bGQgYmU6IEdyZWVuLCBZZWxsb3csIFJlZCBuZXR3b3Jrcw0KDQoNCkNl cnRhaW5seSBpbiB0ZXJtcyBvZiBwb2xpY3kgYW5kIHNlY3VyaXR5IGNvbmNlcm5zIG9uZSBzaXpl IGRvZXMgbm90IGZpdCBhbGwgMy4gIFRoZSBxdWVzdGlvbiBpcyBjYW4gd2UgZmFzaGlvbiBhIGRp c2NvdmVyeSBtZWFucyB0aGF0IHdvcmtzIGluIGFsbCAzLCBidXQgcGVyaGFwcyBtaXRpZ2F0ZXMg dGhlIHBvbGljeSBhbmQgc2VjdXJpdHkgY29uY2VybnMgaW4gZWFjaD8NCg0KREhDUCBtYXkgYmUg YSBwZXJmZWN0bHkgZmluZSBjaG9pY2UgaW4gYSBncmVlbiBuZXR3b3JrLCBidXQgaW4gYSB5ZWxs b3cgbmV0d29yayB0aGVyZSBpcyBhIG5lZWQgZm9yIHZhbGlkYXRpb24gYW5kIGFzc3VyYW5jZSBv ZiB0aGUgY2hvaWNlLCB3aGlsZSBpbiBhIHJlZCBuZXR3b3JrIOKAkyBjYW4geW91IHRydXN0IGFu eXRoaW5nIGF0IGFsbCwgZXZlbiB0aGluZ3MgeW91IGV4cGxpY2l0bHkgc3BlY2lmaWVkIHN1Y2gg YXMgSVAgYWRkcmVzcyBvZiByZXNvbHZlcnMgd2l0aG91dCBzb21lIGFkZGl0aW9uYWwgdmFsaWRh dGlvbiA/DQoNClRoaXMgaXMgYSBncmVhdCB0YXhvbm9teS4gVGhhbmtzLg0KDQpJIHRoaW5rIHRo ZSBxdWVzdGlvbiBJIHdvdWxkIGFzayBpczogaW4gYSBncmVlbiBuZXR3b3JrLCBob3cgbXVjaCBi ZW5lZml0IGRvIHlvdSBnZXQgZnJvbSBEb1tIVF0/IFdlIGNhbiBwcm9iYWJseSBkaXZpZGUgdGhp cyB1cCBpbnRvIHRoZSBsb2NhbCBuZXR3b3JrIGVudmlyb25tZW50IChlLmcuLCB0aGUgd2lyZWxl c3MgbmV0d29yaykgYW5kIHRoZSBhY2Nlc3MgbGluayBmcm9tIHRoZSBJU1AuDQoNClRoZXJlIGFy ZSBsb3RzIG9mIGF0dGFja3MgdGhhdCBjcmVhdGUgY29tcHJvbWlzZWQgIkdyZWVuIiBuZXR3b3Jr cy4gRm9yIGV4YW1wbGU6DQoNCmh0dHBzOi8vd3d3LnpkbmV0LmNvbS9hcnRpY2xlL2JyYXppbC1p cy1hdC10aGUtZm9yZWZyb250LW9mLWEtbmV3LXR5cGUtb2Ytcm91dGVyLWF0dGFjaw0KDQpJIG1p Z2h0IGNhdGVnb3JpemUgYW4gImVudGVycHJpc2UiIG5ldHdvcmsgYXMgc29tZXRoaW5nIG1hbmFn ZWQgd2VsbCBlbm91Z2ggdG8gZG8gYW4gaW52ZXN0aWdhdGlvbiBpbiB0aGUgZXZlbnQgb2YgYSBz ZWN1cml0eSBicmVhY2guIE1vc3QgYnVzaW5lc3MgYW5kIGhvbWUgbmV0d29ya3MgZG8gbm90IGZp dCB0aGlzIGRlZmluaXRpb24sIHNvIHRoZXkgYXJlIGNhdGVnb3J5IDIgKCJZZWxsb3ciKSwgYmVj YXVzZSBwZW9wbGUgc2V0IHRoZW0gdXAgYW5kIGZvcmdldCB0aGVtLg0KDQpTaG91bGQgd2UgZGVz aWduIGZvciB0aGUgZWRnZSBjYXNlIHdoZXJlIHNvbWV0aGluZyBiYWQgaGFwcGVucywgYnV0IGlz IHRoZSBleGNlcHRpb24gb3Igc2hvdWxkIHdlIGRlc2lnbiBmb3IgdGhlIDk5JSBjYXNlIHdoZW4g dGhlIGhvbWUgbmV0d29yayBpcyBqdXN0IGZpbmU/DQoNCkdyYW50ZWQgaGFja3MgYW5kIGF0dGFj a3Mgd2lsbCBoYXBwZW4sIGJ1dCB3aGlsZSB3ZSBzaG91bGQgYW5kIGRvIHRha2UgcmVhc29uYWJs ZSBzdGVwcyB0byBtaXRpZ2F0ZSBvYnZpb3VzIHByb2JsZW1zLCBtb3N0IG9mIHRoZSB0aW1lIGFu ZCBtb3N0IG9mIHRoZSBleHBlcmllbmNlIG9mIGhvbWUgbmV0d29ya3MgaXMgdGhhdCB0aGV5IGFy ZW7igJl0IGNvbXByb21pc2VkIGFuZCBiZWhhdmUgdGhlIHdheSB0aGVpciB1c2VycyBleHBlY3Qu DQoNCklmIHdlIGNsYXNzaWZpZWQgbmV0d29ya3MgYmFzZWQgb24gdGhlIGNvbmNlcm4gdGhhdCBz b21ldGhpbmcgYmFkIG1heSBoYXBwZW4uIFRoZW4gZXZlcnl0aGluZyB3b3VsZCBiZSB5ZWxsb3cs IG9yIGV2ZW4gcmVkIGFzIGl04oCZcyBlYXN5IHRvIGZpbmQgZXhhbXBsZXMgd2hlbiBiYWQgdGhp bmdzIGhhcHBlbmVkIGluIGFueSBzaXR1YXRpb24uIEV4YW1wbGU6IEhvbWUgRGVwb3Qgd2FzIGNv bXByb21pc2VkIC0gdGh1cyBjb3Jwb3JhdGUgbmV0d29ya3MgY2Fu4oCZdCBiZSB0cnVzdGVkLiBF eGFtcGxlOiBUaGUgTlNBIHdhcyBjb21wcm9taXNlZCAtIHRodXMgaGlnaGx5IHNlY3VyZWQgbmV0 d29ya3MgY2Fu4oCZdCBiZSB0cnVzdGVkLiBFYWNoIHN1Y2ggcmVhY3Rpb24gaXMgYSBmZWFyZnVs IG92ZXIgZ2VuZXJhbGl6YXRpb24gb2YgYW4gaW5jaWRlbnQgYW5kIG5vdCB0aGUgbm9ybWFsIGV4 cGVjdGVkIHN0YXRlIG9mIHN1Y2ggbmV0d29yayB0eXBlcy4NCg0KSWYgeW91IGxvb2sgYnJvYWRs eSBhdCBob21lIG5ldHdvcmtzIHRoZSBjb21tb24gZ2VuZXJhbGl6ZWQgY2FzZSBpcyB0aGF0IFRo ZSB2YXN0IG1ham9yaXR5YXJlbuKAmXQgY29tcHJvbWlzZWQgYW5kIHRoZSBjb25maWd1cmF0aW9u IGluZm9ybWF0aW9uIGZyb20gdGhlIG5ldHdvcmsgY2FuIGJlIHRydXN0ZWQuDQoNClNvIGluc3Rl YWQgb2YgZGVzaWduaW5nIGZvciBlZGdlIGNhc2Ugb2YgYSBwcmV2aW91c2x5IHRydXN0IG5ldHdv cmsgYmVpbmcgY29tcHJvbWlzZWQgLCB3aHkgbm90IGRlc2lnbiBmb3IgdGhlIG1vcmUgY29tbW9u IHN0YXRlIG9mIHRoZSBuZXR3b3JrIGJlaW5nIHRydXN0d29ydGh5IGJ1dCBhbmQgdGhlbiBhZGQg aW4gc29tZSBtZWNoYW5pc20gdG8gdmVyaWZ5IHRoZSBpbmZvcm1hdGlvbiB5b3UgZ2V0IGZyb20g aXQuIEJhc2ljYWxseSBhIHZlcnNpb24gb2YgdGhlIHRydXN0IGJ1dCB2ZXJpZnkgYXBwcm9hY2gs IHdoaWNoIGhhcyBiZWVuIHByb3ZlbiByZXBlYXRlZGx5IGFzIGEgcmVhc29uYWJsZSBzdHJhdGVn eSBpbiB0aGUgcmVhbCB3b3JsZC4NCg0KRm9yIGluc3RhbmNlLCBpZiB5b3UgZ2V0IGEgRG9IIHJl c29sdmVyIGZyb20gdGhlIGdyZWVuIG5ldHdvcmssIHdoeSBub3QgdHJ1c3QgYnV0IHZlcmlmeSBi eSBjaGVja2luZyB0aGUgcmVhc29uYWJsZW5lc3Mgb2YgdGhlIGFuc3dlciB5b3Ugd2VyZSBkaXJl Y3RlZCB0bz8gIFRoaXMgY291bGQgc29tZXRoaW5nIGxpa2UgdmFsaWRhdGluZyB3aXRoIEROU1NF QyBvciBzb21lIG90aGVyIHZhbGlkYXRpb24gbWV0aG9kLg0KDQpUaGlzIGdldHMgYmFjayAgdG8g RWty4oCZcyBxdWVzdGlvbiBvZiBkZWNsYXJpbmcgd2hhdCB0aHJlYXRzIHlvdSBhcmUgYWN0dWFs bHkgd29ycmllZCBhYm91dC4NCg0KLUdsZW5uDQo= --_000_94C306DFA9D94FAC8C4BAE3E90E29417nbcunicom_ Content-Type: text/html; charset="utf-8" Content-ID: <6045D4A21B8B234C9CFE0B639525FD1C@NBCUNI.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0K PGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj5PbiBKdW4gMzAsIDIwMjAsIGF0IDg6MzEgUE0sIFJvYiBTYXlyZSAm bHQ7c2F5cmVyQGdtYWlsLmNvbSZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPu+7vw0KPGRp diBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj5PbiBUdWUsIEp1biAzMCwgMjAyMCBhdCA1OjUy IFBNIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBy dGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAw cHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRp bmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rp dj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz PSJnbWFpbF9hdHRyIj5PbiBUdWUsIEp1biAzMCwgMjAyMCBhdCA0OjI1IFBNIERlZW4sIEdsZW5u IChOQkNVbml2ZXJzYWwpICZsdDs8YSBocmVmPSJtYWlsdG86R2xlbm4uRGVlbkBuYmN1bmkuY29t IiB0YXJnZXQ9Il9ibGFuayI+R2xlbm4uRGVlbkBuYmN1bmkuY29tPC9hPiZndDsgd3JvdGU6PGJy Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46 MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7 cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGxhbmc9IkVOLVVTIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5UaGlzIGFsbCBj b21lcyBiYWNrIHRvIHRoZSB0aHJlZSBzbGljZXMgb2YgYWNjZXNzIHR5cGVzIHRoYXQgaGFkIGJl ZW4gZGlzY3Vzc2VkIHNvbWUgbW9udGhzIGFnbzo8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj48 dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSIxIiBzdGFydD0iMSI+DQo8bGkgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbiI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+VHJ1c3RlZCAmYW1wOyBrbm93biBuZXR3b3Jr cyDigJMgdGhpcyBpcyB5b3VyIGVudGVycHJpc2UsIHlvdXIgaG9tZS4mbmJzcDsgWW91IGhhdmUg YSByZWxhdGlvbnNoaXAgd2l0aCB0aGVtLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvbGk+PGxpIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2Ei PlVua25vd24gbmV0d29ya3Mg4oCTIFRoaXMgaXMgdGhlIGNhZsOpLCBzY2hvb2wsIGhvdGVsIC0g eW91IGNob29zZSB0aGVtIGJlY2F1c2UgdGhleSBhcmUgYXZhaWxhYmxlLCBidXQgeW91IGtub3cg dmVyeSBsaXR0bGUgdG8gbm90aGluZyBhYm91dCB0aGVtLjx1PjwvdT48dT48L3U+PC9zcGFuPjwv bGk+PGxpIHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpI ZWx2ZXRpY2EiPkhvc3RpbGUgbmV0d29ya3Mg4oCTIHlvdSBtYXkgbm90IGhhdmUgYW55IGNob2lj ZSBpbiBuZXR3b3JrIGFuZCBtdXN0IHVzZSB0aGlzIGlzIHlvdSB3YW50IGFueSBJbnRlcm5ldCBh Y2Nlc3MgYXQgYWxsLiZuYnNwOyBIb3dldmVyLCBub3Qgb25seSBkbyB5b3Ugbm90IHRydXN0IHRo ZW0sIHlvdSBrbm93IHRoZXkgYXJlIGFjdGl2ZWx5IGFjdGluZyBpbg0KIHdheXMgeW91IGRvIG5v dCB3YW50Ljx1PjwvdT48dT48L3U+PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPjx1PjwvdT4mbmJzcDs8dT48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpIZWx2ZXRpY2EiPkFub3RoZXIgc2xpY2UgYXJvdW5kIHRocmVhdCBsZXZlbHMgd291bGQg YmU6IEdyZWVuLCBZZWxsb3csIFJlZCBuZXR3b3Jrczx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPjx1PjwvdT4mbmJzcDs8dT48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpIZWx2ZXRpY2EiPkNlcnRhaW5seSBpbiB0ZXJtcyBvZiBwb2xpY3kgYW5kIHNlY3VyaXR5 IGNvbmNlcm5zIG9uZSBzaXplIGRvZXMgbm90IGZpdCBhbGwgMy4mbmJzcDsgVGhlIHF1ZXN0aW9u IGlzIGNhbiB3ZSBmYXNoaW9uIGEgZGlzY292ZXJ5IG1lYW5zIHRoYXQgd29ya3MgaW4gYWxsIDMs IGJ1dCBwZXJoYXBzIG1pdGlnYXRlcyB0aGUgcG9saWN5IGFuZCBzZWN1cml0eSBjb25jZXJucw0K IGluIGVhY2g/PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkhlbHZldGljYSI+REhDUCBtYXkgYmUgYSBwZXJmZWN0bHkgZmluZSBjaG9pY2UgaW4gYSBncmVl biBuZXR3b3JrLCBidXQgaW4gYSB5ZWxsb3cgbmV0d29yayB0aGVyZSBpcyBhIG5lZWQgZm9yIHZh bGlkYXRpb24gYW5kIGFzc3VyYW5jZSBvZiB0aGUgY2hvaWNlLCB3aGlsZSBpbiBhIHJlZCBuZXR3 b3JrIOKAkyBjYW4geW91IHRydXN0IGFueXRoaW5nIGF0IGFsbCwgZXZlbg0KIHRoaW5ncyB5b3Ug ZXhwbGljaXRseSBzcGVjaWZpZWQgc3VjaCBhcyBJUCBhZGRyZXNzIG9mIHJlc29sdmVycyB3aXRo b3V0IHNvbWUgYWRkaXRpb25hbCB2YWxpZGF0aW9uID88L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgaXMgYSBncmVh dCB0YXhvbm9teS4gVGhhbmtzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB0aGlu ayB0aGUgcXVlc3Rpb24gSSB3b3VsZCBhc2sgaXM6IGluIGEgZ3JlZW4gbmV0d29yaywgaG93IG11 Y2ggYmVuZWZpdCBkbyB5b3UgZ2V0IGZyb20gRG9bSFRdPyBXZSBjYW4gcHJvYmFibHkgZGl2aWRl IHRoaXMgdXAgaW50byB0aGUgbG9jYWwgbmV0d29yayBlbnZpcm9ubWVudCAoZS5nLiwgdGhlIHdp cmVsZXNzIG5ldHdvcmspIGFuZCB0aGUgYWNjZXNzIGxpbmsgZnJvbSB0aGUgSVNQLjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGVyZSBhcmUg bG90cyBvZiBhdHRhY2tzIHRoYXQgY3JlYXRlIGNvbXByb21pc2VkICZxdW90O0dyZWVuJnF1b3Q7 IG5ldHdvcmtzLiBGb3IgZXhhbXBsZTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxh IGhyZWY9Imh0dHBzOi8vd3d3LnpkbmV0LmNvbS9hcnRpY2xlL2JyYXppbC1pcy1hdC10aGUtZm9y ZWZyb250LW9mLWEtbmV3LXR5cGUtb2Ytcm91dGVyLWF0dGFjayI+aHR0cHM6Ly93d3cuemRuZXQu Y29tL2FydGljbGUvYnJhemlsLWlzLWF0LXRoZS1mb3JlZnJvbnQtb2YtYS1uZXctdHlwZS1vZi1y b3V0ZXItYXR0YWNrPC9hPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBtaWdodCBj YXRlZ29yaXplIGFuICZxdW90O2VudGVycHJpc2UmcXVvdDsgbmV0d29yayBhcyBzb21ldGhpbmcg bWFuYWdlZCB3ZWxsIGVub3VnaCB0byBkbyBhbiBpbnZlc3RpZ2F0aW9uIGluIHRoZSBldmVudCBv ZiBhIHNlY3VyaXR5IGJyZWFjaC4gTW9zdCBidXNpbmVzcyBhbmQgaG9tZSBuZXR3b3JrcyBkbyBu b3QgZml0IHRoaXMgZGVmaW5pdGlvbiwgc28gdGhleSBhcmUgY2F0ZWdvcnkgMiAoJnF1b3Q7WWVs bG93JnF1b3Q7KSwgYmVjYXVzZSBwZW9wbGUgc2V0IHRoZW0NCiB1cCBhbmQgZm9yZ2V0IHRoZW0u PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij5TaG91bGQgd2UgZGVzaWduIGZvciB0aGUgZWRnZSBjYXNl IHdoZXJlIHNvbWV0aGluZyBiYWQgaGFwcGVucywgYnV0IGlzIHRoZSBleGNlcHRpb24gb3Igc2hv dWxkIHdlIGRlc2lnbiBmb3IgdGhlIDk5JSBjYXNlIHdoZW4gdGhlIGhvbWUgbmV0d29yayBpcyBq dXN0IGZpbmU/PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0 ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 Ij5HcmFudGVkIGhhY2tzIGFuZCBhdHRhY2tzIHdpbGwgaGFwcGVuLCBidXQgd2hpbGUgd2Ugc2hv dWxkIGFuZCBkbyB0YWtlIHJlYXNvbmFibGUgc3RlcHMgdG8gbWl0aWdhdGUgb2J2aW91cyBwcm9i bGVtcywgbW9zdCBvZiB0aGUgdGltZSBhbmQgbW9zdCBvZiB0aGUgZXhwZXJpZW5jZSBvZiBob21l IG5ldHdvcmtzIGlzIHRoYXQNCiB0aGV5IGFyZW7igJl0IGNvbXByb21pc2VkIGFuZCBiZWhhdmUg dGhlIHdheSB0aGVpciB1c2VycyBleHBlY3QuICZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIg c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij48 YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyI+SWYgd2UgY2xhc3NpZmllZCBuZXR3b3JrcyBiYXNl ZCBvbiB0aGUgY29uY2VybiB0aGF0IHNvbWV0aGluZyBiYWQgbWF5IGhhcHBlbi4gVGhlbiBldmVy eXRoaW5nIHdvdWxkIGJlIHllbGxvdywgb3IgZXZlbiByZWQgYXMgaXTigJlzIGVhc3kgdG8gZmlu ZCBleGFtcGxlcyB3aGVuIGJhZCB0aGluZ3MgaGFwcGVuZWQgaW4gYW55IHNpdHVhdGlvbi4NCiBF eGFtcGxlOiBIb21lIERlcG90IHdhcyBjb21wcm9taXNlZCAtIHRodXMgY29ycG9yYXRlIG5ldHdv cmtzIGNhbuKAmXQgYmUgdHJ1c3RlZC4gRXhhbXBsZTogVGhlIE5TQSB3YXMgY29tcHJvbWlzZWQg LSB0aHVzIGhpZ2hseSBzZWN1cmVkIG5ldHdvcmtzIGNhbuKAmXQgYmUgdHJ1c3RlZC4gRWFjaCBz dWNoIHJlYWN0aW9uIGlzIGEgZmVhcmZ1bCBvdmVyIGdlbmVyYWxpemF0aW9uIG9mIGFuIGluY2lk ZW50IGFuZCBub3QgdGhlIG5vcm1hbCBleHBlY3RlZA0KIHN0YXRlIG9mIHN1Y2ggbmV0d29yayB0 eXBlcy48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsiPklm IHlvdSBsb29rIGJyb2FkbHkgYXQgaG9tZSBuZXR3b3JrcyB0aGUgY29tbW9uIGdlbmVyYWxpemVk IGNhc2UgaXMgdGhhdCBUaGUgdmFzdCBtYWpvcml0eWFyZW7igJl0IGNvbXByb21pc2VkIGFuZCB0 aGUgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBmcm9tIHRoZSBuZXR3b3JrIGNhbiBiZSB0cnVz dGVkLjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyI+U28g aW5zdGVhZCBvZiBkZXNpZ25pbmcgZm9yIGVkZ2UgY2FzZSBvZiBhIHByZXZpb3VzbHkgdHJ1c3Qg bmV0d29yayBiZWluZyBjb21wcm9taXNlZCAsIHdoeSBub3QgZGVzaWduIGZvciB0aGUgbW9yZSBj b21tb24gc3RhdGUgb2YgdGhlIG5ldHdvcmsgYmVpbmcgdHJ1c3R3b3J0aHkgYnV0IGFuZCB0aGVu IGFkZCBpbiBzb21lDQogbWVjaGFuaXNtIHRvIHZlcmlmeSB0aGUgaW5mb3JtYXRpb24geW91IGdl dCBmcm9tIGl0LiBCYXNpY2FsbHkgYSB2ZXJzaW9uIG9mIHRoZSB0cnVzdCBidXQgdmVyaWZ5IGFw cHJvYWNoLCB3aGljaCBoYXMgYmVlbiBwcm92ZW4gcmVwZWF0ZWRseSBhcyBhIHJlYXNvbmFibGUg c3RyYXRlZ3kgaW4gdGhlIHJlYWwgd29ybGQuPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsiPjxicj4NCjwv ZGl2Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij5Gb3IgaW5zdGFuY2UsIGlmIHlvdSBnZXQgYSBEb0ggcmVzb2x2 ZXIgZnJvbSB0aGUgZ3JlZW4gbmV0d29yaywgd2h5IG5vdCB0cnVzdCBidXQgdmVyaWZ5IGJ5IGNo ZWNraW5nIHRoZSByZWFzb25hYmxlbmVzcyBvZiB0aGUgYW5zd2VyIHlvdSB3ZXJlIGRpcmVjdGVk IHRvPyAmbmJzcDtUaGlzIGNvdWxkIHNvbWV0aGluZyBsaWtlIHZhbGlkYXRpbmcNCiB3aXRoIERO U1NFQyBvciBzb21lIG90aGVyIHZhbGlkYXRpb24gbWV0aG9kLjwvZGl2Pg0KPGRpdiBkaXI9Imx0 ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 Ij48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyI+VGhpcyBnZXRzIGJhY2sgJm5ic3A7dG8gRWty 4oCZcyBxdWVzdGlvbiBvZiBkZWNsYXJpbmcgd2hhdCB0aHJlYXRzIHlvdSBhcmUgYWN0dWFsbHkg d29ycmllZCBhYm91dC48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRp cj0ibHRyIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAw LCAwKTsiPi1HbGVubiZuYnNwOzwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_94C306DFA9D94FAC8C4BAE3E90E29417nbcunicom_-- From nobody Tue Jun 30 21:55:49 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493CD3A0CE5 for ; Tue, 30 Jun 2020 21:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 vztoWAdp3FDd for ; Tue, 30 Jun 2020 21:55:44 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 D92CB3A0CE6 for ; Tue, 30 Jun 2020 21:55:44 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id f6so7993690ioj.5 for ; Tue, 30 Jun 2020 21:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kLzF2aCpelPH0qoBJ4do2Rl6ue/Ikl5aXUOzdkVkXB8=; b=aCx7at2xIKISVgtegZ3c9TuSdH9iC5sLF3WzWEBIT8FWt0DL8hTsQm0IYYBuhSZ8oK CrK2GvRFVYj9fuzPG5my3TDSHBFKEN67sj5aoPh/1/+V+tyNJ1oY7MsLEMUB2RfoKGJR 3SUOGdk6xdJcdTxLzCoBaDCoZBSIe7w35zNPvaHJit3ojhFKpU0/USdKNzPlkXvOZ/yv GByrhy3GlxKHgIxIlSrAmwmx+parl4WVgkOWDYm00fkkZjKuIk9JM7ABoeODtrDK8EYq l9jMaGIM8mPyJrMVl20HXzmqp1u9j9lONlOqVdEpp1ba3m/caF83luBtKPMxtNNjsLih 4X/g== 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:to:cc; bh=kLzF2aCpelPH0qoBJ4do2Rl6ue/Ikl5aXUOzdkVkXB8=; b=Qp9s4Zxv+/On8tZNJNdLDIgOARZPIX9JM0R+3hhU8l7IuwngqPWk8WEL89Eg5fFft1 isrQFLOT+AhlzM8D/Peecm8fTakRz1QVMRinR1nJnKfGH7us5vqoQUzNMpU7Vpe8V8kL Vi2RGAnQk9Fmf6XHaPoioGMiSwQsz3IuDZ34Pwt4x2LOgn/OUOU+8ZCx/HmJbWzY5jtU +U1q94uz/KsKOFgDE+HwhMYf3xadIHeI4lwDdvr253Pm67xi79xw5Vu3dGq7ciNpRJR+ 6s6kBj14mmZ2LtGE3SPDWtZxYZA6sZb0dgZnCmHlEKivSVa2YfNcdxwrEMluDWndqXGp /Ygw== X-Gm-Message-State: AOAM531nIItBzzyFkmXMEZstpuFAVY7zXXts0AEbgrQXCc7yX4zsNAFP luhA5JwB8B+C4uUHLAdKEQk5f0Rudiu8bJEpIxE= X-Google-Smtp-Source: ABdhPJx/GBLr3IF7T0CtfX26eyaxdpa5ZfVQ7xxihqEmZxWWTCKrooW21BogIosQV46GxcgKsJIqVtM2E0g9si/7Hys= X-Received: by 2002:a6b:d119:: with SMTP id l25mr468969iob.192.1593579344062; Tue, 30 Jun 2020 21:55:44 -0700 (PDT) MIME-Version: 1.0 References: <94C306DF-A9D9-4FAC-8C4B-AE3E90E29417@nbcuni.com> In-Reply-To: <94C306DF-A9D9-4FAC-8C4B-AE3E90E29417@nbcuni.com> From: Rob Sayre Date: Tue, 30 Jun 2020 21:55:30 -0700 Message-ID: To: "Deen, Glenn (NBCUniversal)" Cc: Eric Rescorla , ADD Mailing list , Paul Vixie , Vittorio Bertola Content-Type: multipart/alternative; boundary="000000000000b96d0605a95a1a25" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 04:55:47 -0000 --000000000000b96d0605a95a1a25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 30, 2020 at 9:01 PM Deen, Glenn (NBCUniversal) < Glenn.Deen@nbcuni.com> wrote: > > Should we design for the edge case where something bad happens, but is th= e > exception or should we design for the 99% case when the home network is > just fine? > > Granted hacks and attacks will happen, but while we should and do take > reasonable steps to mitigate obvious problems, most of the time and most = of > the experience of home networks is that they aren=E2=80=99t compromised a= nd behave > the way their users expect. > Although only one example was given, it's a common problem. A web search will turn up many other instances. Note that Mozilla's current approach is resistant to such misconfiguration, whether or not it's malicious. Most of these problems seem to be unintentional or the work of common criminals, not anything more sophisticated. I agree that DNSSEC or some other validation method might improve discovery over DHCP etc, but have yet to see anything like that deployed. Examples might help. > > This gets back to Ekr=E2=80=99s question of declaring what threats you a= re > actually worried about. > Private IPs should not be trusted as DNS servers absent client software such as VPNs, enterprise management, or parental control features. I know others disagree. thanks, Rob --000000000000b96d0605a95a1a25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 30, 2020 at 9:01 PM Deen, Gle= nn (NBCUniversal) <Glenn.Deen@n= bcuni.com> wrote:

Should we design for the edge c= ase where something bad happens, but is the exception or should we design f= or the 99% case when the home network is just fine?

Granted hacks and attacks will = happen, but while we should and do take reasonable steps to mitigate obviou= s problems, most of the time and most of the experience of home networks is= that they aren=E2=80=99t compromised and behave the way their users expect.=C2= =A0=C2=A0

Although only on= e example was given, it's a common=C2=A0problem. A web search will turn= up many other=C2=A0instances.=C2=A0Note that Mozilla's current approac= h is resistant to such misconfiguration, whether or not it's malicious.= Most of these problems seem to be unintentional or the work of common crim= inals, not anything more sophisticated.

I agree th= at DNSSEC or some other validation method might improve discovery over DHCP= etc, but have yet to see anything=C2=A0like that deployed. Examples might = help.
=C2=A0

This gets back =C2=A0to Ekr=E2= =80=99s question of declaring what threats you are actually worried about.<= br>

Private IPs should not be t= rusted as DNS servers absent client software such as VPNs, enterprise manag= ement, or parental control features. I know others disagree.

=
thanks,
Rob

--000000000000b96d0605a95a1a25-- From nobody Tue Jun 30 22:34:25 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870983A0064 for ; Tue, 30 Jun 2020 22:34:23 -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, SPF_HELO_NONE=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 ySKUe-cb5n3H for ; Tue, 30 Jun 2020 22:34:21 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C673D3A0063 for ; Tue, 30 Jun 2020 22:34:21 -0700 (PDT) Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 367C0B0588; Wed, 1 Jul 2020 05:34:19 +0000 (UTC) From: Paul Vixie To: Ted Lemon Cc: add@ietf.org Date: Wed, 01 Jul 2020 05:34:17 +0000 Message-ID: <2560148.jvFFTcX3xC@linux-9daj> Organization: none In-Reply-To: <6EC5A247-F873-4B0C-9773-E708D3B6AC77@fugue.com> References: <3421779.8U4dVgcHlH@linux-9daj> <6EC5A247-F873-4B0C-9773-E708D3B6AC77@fugue.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 05:34:24 -0000 On Tuesday, 30 June 2020 13:17:32 UTC Ted Lemon wrote: > On Jun 30, 2020, at 5:19 AM, Paul Vixie wrote: > > moving on, what i'd love to have is SDNCP rather than DHCP. S=3Dsecure, > > N=3Dnetwork. because i want to know i'm getting what the operator of the > > network wants me to get, and because there are other parameters besides > > RDNS that i care about, such as whether there's a mandatory HTTPS or > > HTTP/3 proxy i will have to talk to. because, IoT. if DHCP isn't useful > > because it's not secure, we should stop using it. but before we could do > > that, we'd have to meet its functionality in another way. >=20 > We tried that. Unfortunately, what we found is that it just moves the > problem. Suppose you send out an SDNCP discovery request and get back one > or more signed responses. Which one do you choose? as i wrote, i'd expect it to be like bluetooth pairing, which has the same= =20 problem, and which solves it with a six-digit PIN code for verification. ma= ybe=20 we can use something more modern, like thumbprint scans. > ... >=20 > So the question is, what problem are you solving with SDNCP that isn=E2= =80=99t > already solved with DNSSEC, TLS and PKI? as i wrote, there are other network configuration parameters which are also= =20 valuable targets, such as outbound proxy settings. as i've written elsewhere, not all DNSSEC-validating servers are equal. as = the=20 owner and operator of private networks, i require all my users, apps, and=20 nodes to use a DNSSEC-validating server that also has a policy layer, and=20 transaction logging. so, using DNSSEC as a measure of correctness does not = and=20 will never cover the requirements of the Secure Access Service Edge. this i= s=20 more important than ever now that so many workers are working from home. se= e: https://techspective.net/2020/06/23/the-four-horsemen-of-sase-secure-access= =2Dservice-edge/ > The only answer we came up with is that it might be nice to be able to kn= ow > that we are speaking to the same operator we were last time. But we didn= =E2=80=99t > actually identify a compelling use case for that, and consequently the wo= rk > was abandoned. i think i should have paid more attention at that time, and i apologize. DH= CP=20 was always the wrong thing to build, like BOOTP before it, and IPv6 address= =20 assignment after it. secure hosting networks have to use /30 and later /31= =20 netmasks (one customer per vlan) in order to trust any of this. =2D-=20 Paul From nobody Tue Jun 30 23:00:01 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABBC3A07B9 for ; Tue, 30 Jun 2020 22:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M0wOmvQx2NL for ; Tue, 30 Jun 2020 22:59:55 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 7B10B3A07B7 for ; Tue, 30 Jun 2020 22:59:55 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id z2so17588747qts.5 for ; Tue, 30 Jun 2020 22:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hCZjENKeKrt9uecK9lOGLC7aJmP5iNKhPpX2jbbWPU0=; b=hfkwwDDF2uKoHKFIJhR4mUKN+fjdJ3twG8WhXCnShMYXBQ3CvFYixJ0WZkjs5/2QEB RH0BCAcCH+rN11UYPBMACmLRNP1m1Ssm1fThfKNO7EnYjcn3ZYFlCaeQSToNfW67pVrT 2gnMOgrskfywJbTq6ALu5ZRj2t9KOD7hX0Unn76lAjMs7L9lx4Jc5r3f3nSq2YXZXejx YzAxSDXDd+GK0K+R+rcrerpE/eGYppZNjhKhlvx7RZE2E9NVxkNge/fK1V9OlooCzFgi Fdq8bUZl9VYamZ2o3r64EcF0AllOKNV3jMTRvanWiHr9vOGX4/vz6RTdBPhv09LhdHTY U0RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hCZjENKeKrt9uecK9lOGLC7aJmP5iNKhPpX2jbbWPU0=; b=jkPkgVPHoiJdxLsXvePAJs/nncA1OMKdFKziwFHrMUsGd6yWA8DebAfbUt/Ll52y6Y dYt0RcVkinFq7CowZyf2LAhDqfAGG90y94bjSqqmcsoXBnFZxBsQVUQIril8dmkEY4mH opjlrBEvgxrMZH/gnvRjRpvV5fOxz1+pKJpGHy7aTK9JEsCSICardb9EbsJVyo5UZrk6 fFZ8X5NtgSZTkkx1CfwBG3oza24hDkyT0AcUsYLIqSuHmlsIfp5YwF55JB2JyoChtPGr EojbHsU/yWHJboLfiz3MkMM255ZZS3vc4R32/5Cc76uHvjlt76CPlbgxeBzEwzAL6xtj v15A== X-Gm-Message-State: AOAM530nupZnNO0ouZDPYuHbKz864g5/21FeNJHsTZ0yuT6fSuNBncqe ior3UE76W7C0qAYnKssFq5OA9I6JYBY= X-Google-Smtp-Source: ABdhPJwGDIBwKeoqISKGa1czqB7vsOmrwguFrd2D0SXH43bZhtU6QWK0rycdOaPG2uh++QKClxSeFw== X-Received: by 2002:ac8:7182:: with SMTP id w2mr25029442qto.115.1593583194254; Tue, 30 Jun 2020 22:59:54 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:d992:16e2:c47d:eae5? ([2601:18b:300:36ee:d992:16e2:c47d:eae5]) by smtp.gmail.com with ESMTPSA id l56sm5612609qtl.33.2020.06.30.22.59.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2020 22:59:53 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2238DE81-6F2D-4362-A2E1-2D2D7123E5CE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 1 Jul 2020 01:59:51 -0400 In-Reply-To: <2560148.jvFFTcX3xC@linux-9daj> Cc: add@ietf.org To: Paul Vixie References: <3421779.8U4dVgcHlH@linux-9daj> <6EC5A247-F873-4B0C-9773-E708D3B6AC77@fugue.com> <2560148.jvFFTcX3xC@linux-9daj> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 05:59:59 -0000 --Apple-Mail=_2238DE81-6F2D-4362-A2E1-2D2D7123E5CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 1, 2020, at 1:34 AM, Paul Vixie wrote: > as i wrote, i'd expect it to be like bluetooth pairing, which has the = same=20 > problem, and which solves it with a six-digit PIN code for = verification. maybe=20 > we can use something more modern, like thumbprint scans. Yes, we thought of all that. But we couldn=E2=80=99t come up with a use = case for it. > as i wrote, there are other network configuration parameters which are = also=20 > valuable targets, such as outbound proxy settings. Who configures those with DHCP? That would be insane. > as i've written elsewhere, not all DNSSEC-validating servers are = equal. as the=20 > owner and operator of private networks, i require all my users, apps, = and=20 > nodes to use a DNSSEC-validating server that also has a policy layer, = and=20 > transaction logging. so, using DNSSEC as a measure of correctness does = not and=20 > will never cover the requirements of the Secure Access Service Edge. = this is=20 > more important than ever now that so many workers are working from = home. see: It sounds like a validating stub resolver will fail to work with your = product.=20 > i think i should have paid more attention at that time, and i = apologize. DHCP=20 > was always the wrong thing to build, like BOOTP before it, and IPv6 = address=20 > assignment after it. secure hosting networks have to use /30 and later = /31=20 > netmasks (one customer per vlan) in order to trust any of this. I don=E2=80=99t know what a =E2=80=9Csecure hosting network=E2=80=9D is. = Is that an IETF thing? --Apple-Mail=_2238DE81-6F2D-4362-A2E1-2D2D7123E5CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 1, 2020, at 1:34 AM, Paul Vixie <paul@redbarn.org> = wrote:
as i wrote, = i'd expect it to be like bluetooth pairing, which has the same 
problem, and = which solves it with a six-digit PIN code for verification. maybe 
we can use = something more modern, like thumbprint = scans.

Yes, = we thought of all that. But we couldn=E2=80=99t come up with a use case = for it.

as i wrote, there are = other network configuration parameters which are also 
valuable targets, such = as outbound proxy settings.

Who configures those with DHCP? That would be = insane.

as i've written = elsewhere, not all DNSSEC-validating servers are equal. as = the 
owner and operator of = private networks, i require all my users, apps, and 
nodes to use a = DNSSEC-validating server that also has a policy layer, = and 
transaction logging. = so, using DNSSEC as a measure of correctness does not = and 
will never cover the = requirements of the Secure Access Service Edge. this is 
more important than = ever now that so many workers are working from home. = see:

It sounds = like a validating stub resolver will fail to work with your = product. 

i think i should have = paid more attention at that time, and i apologize. DHCP 
was always the wrong = thing to build, like BOOTP before it, and IPv6 address 
assignment after it. = secure hosting networks have to use /30 and later /31 
netmasks (one customer = per vlan) in order to trust any of this.

I don=E2=80=99t know what a =E2=80=9Csecu= re hosting network=E2=80=9D is. Is that an IETF thing?

= --Apple-Mail=_2238DE81-6F2D-4362-A2E1-2D2D7123E5CE-- From nobody Tue Jun 30 23:35:02 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738193A084F for ; Tue, 30 Jun 2020 23:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 V8wP5x0QCAnH for ; Tue, 30 Jun 2020 23:34:57 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 6A4E83A085B for ; Tue, 30 Jun 2020 23:34:43 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id q3so9362217ilt.8 for ; Tue, 30 Jun 2020 23:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mYixJ3o+GgBJcpOmoVgV7hXviwuq77RQZQqAqEggmsk=; b=SEB75roiN+crfm+Ih7IkYrysQSr+8nOWO7Cvht3lSwTf5QpUNhUkaCq+lR2WgAU5/w cSpooJFOXSG+ODL8Q3eg+2PqRErSfCU1mb4Ph1obtbvuk7H3x4XkIZDH36touUfMTZWF nPNMi0rJgcE9GpfpFVSb778jLzeLKMvRfMpSrP1JyJZ8eoifY/5wYAbqUM6+fRRPVDcm ZiT2HWs1knxPmpvh4OIEOzq9X63bjWqAOgX6CuCF1wdiK/HCttrx8AO41leaNhMTN9ga /Pj3wnqOD1uFm0lQUP6xbeGa/BJK67iXub89VH2N5Fqo+OwEd3C0TUHBJL+gOBQG3/Ij tlOQ== 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:to:cc; bh=mYixJ3o+GgBJcpOmoVgV7hXviwuq77RQZQqAqEggmsk=; b=sYmlqTbLsACjg6oKmcRWB7CgY67utw5zDYSzJIKgFb6UroGLTVakPfyoK3RGt3jqoJ 2iaHddjF0RQ7Esdos6ydNlMwuobaBRW6fkpq77/dU1zwrONkdYgz9q2h7vRe3F94JMAm p1iCU66rm/HmBJrczq5LU1TeL42qh/uCf0f2wBxoakIa+fcttAaUyoOMqNv0kgpGA+zX cVWFQjBxWnG4Q9BZxRB/vAAfJpi9+V4LBNwnrvsbytyxERNm7cE6P+//wPpJrQSgOUpp YpkuodAs/83GG/pXs03YQp9edIjavKC5GEnJ8M3osp9w6Rd/S+lcTzqyB1gafYRYq8OU srmw== X-Gm-Message-State: AOAM531dPqMcMk4Obh6MhU+3EZMaZBQn68yt38gv0yrEZwdHSDo4y8QG kztA1BSPi1BoeO+gdWteDFPrzOD0DPCoVDpyEAxt3NGdry2bWA== X-Google-Smtp-Source: ABdhPJx/wfaCHFx098GgRR1dlqiS3nMfw2ZjnrdPWYS8qYRk7T1CIP/0T6lDkmark37nSvq47Bri5a8p/wyLzjnU4NY= X-Received: by 2002:a92:c530:: with SMTP id m16mr6600157ili.300.1593585282643; Tue, 30 Jun 2020 23:34:42 -0700 (PDT) MIME-Version: 1.0 References: <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> In-Reply-To: From: tirumal reddy Date: Wed, 1 Jul 2020 12:04:31 +0530 Message-ID: To: Eric Rescorla Cc: Paul Vixie , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000b0fe0305a95b7cd7" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 06:35:00 -0000 --000000000000b0fe0305a95b7cd7 Content-Type: text/plain; charset="UTF-8" On Tue, 30 Jun 2020 at 21:30, Eric Rescorla wrote: > > > On Tue, Jun 30, 2020 at 6:44 AM tirumal reddy wrote: > >> >> >> On Tue, 30 Jun 2020 at 18:28, Eric Rescorla wrote: >> >>> >>> >>> On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie wrote: >>> >>>> On Tuesday, 30 June 2020 09:07:43 UTC Martin Thomson wrote: >>>> > Hi Paul, >>>> > >>>> > On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote: >>>> > > Eric Rescorla wrote on 2020-06-29 20:08: >>>> > > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault < >>>> mglt.ietf@gmail.com >>>> > > > >>>> > > > > wrote: >>>> > > > If the lookup takes as input the IP addresses or something >>>> provided >>>> > > > by the ISP (like the local resolver IP address), the >>>> resulting chain >>>> > > > is likely to be from the ISP. DNSSEC is needed to assert it. >>>> > > > >>>> > > > Why do you assume that the IP is delivered securely? >>>> > > >>>> > > because dnssec allows me to verify end-to-end authenticity of >>>> > > name/address bindings (and other dns content.) >>>> > >>>> > DNSSEC allows you to be sure of the veracity of what comes from >>>> DNSSEC, but >>>> > in this case the IP address didn't come from DNSSEC. It's not DNS >>>> content. >>>> >>>> i have badly misunderstood. >>>> >>>> the way i know that the ip address provided by the isp was delivered >>>> securely >>>> today is because off-net DHCP forgery is hard, >>> >>> >>> Let's start here: >>> I agree that off-net DHCP forgery is hard. However, once you assume that >>> you are off-path, then Do53 interception is *also* hard. So for this to be >>> useful you need an environment in which the attacker is able to attack Do53 >>> but *not* to attack DHCP. What I'm asking for is for someone to define that >>> threat model precisely so that we can design protocols that match it. >>> >> >> The various possible attacks in a home network are discussed in >> https://tools.ietf.org/html/draft-btw-add-home-06#section-9 >> > > As far as I can tell, what this text says is that authenticating the > server based on information received in DHCP is not useful. > No, the draft discusses new DHCP/RA options to convey the DoH/DoT server domain name. Section 9 discusses several attacks and mitigations the endpoint can use to defend from an on-path attacker modifying the DHCP response. (1) Attacker modifying the DHCP response to point to the DoH/DoT server hosted by the attacker. (2) Attacker modifying the DHCP response to point to a public DoH server not capable of filtering malware when the local resolver provides malware filtering capability. -Tiru > -Ekr > --000000000000b0fe0305a95b7cd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 30 Jun 2020 at 21:30, Eric Rescor= la <ekr@rtfm.com> wrote:


On Tue, Jun 30, 2020 at 6:44 AM ti= rumal reddy <kond= tir@gmail.com> wrote:


On Tue, 30 Jun 2020 at 1= 8:28, Eric Rescorla <e= kr@rtfm.com> wrote:


On Tue, Jun 30, 2020 at 2:= 19 AM Paul Vixie <= paul@redbarn.org> wrote:
= On Tuesday, 30 June 2020 09:07:43 UTC Martin Thomson wrote:
> Hi Paul,
>
> On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote:
> > Eric Rescorla wrote on 2020-06-29 20:08:
> > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault <mglt.ietf@gmail.com > > >
> > > <mailto:mglt.ietf@gmail.com>> wrote:
> > >=C2=A0 =C2=A0 =C2=A0If the lookup takes as input the IP addre= sses or something provided
> > >=C2=A0 =C2=A0 =C2=A0by the ISP (like the local resolver IP ad= dress), the resulting chain
> > >=C2=A0 =C2=A0 =C2=A0is likely to be from the ISP. DNSSEC is n= eeded to assert it.
> > >
> > > Why do you assume that the IP is delivered securely?
> >
> > because dnssec allows me to verify end-to-end authenticity of
> > name/address bindings (and other dns content.)
>
> DNSSEC allows you to be sure of the veracity of what comes from DNSSEC= , but
> in this case the IP address didn't come from DNSSEC.=C2=A0 It'= s not DNS content.

i have badly misunderstood.

the way i know that the ip address provided by the isp was delivered secure= ly
today is because off-net DHCP forgery is hard,

=
Let's start here:
I agree that off-net DHCP forgery is h= ard. However, once you assume that you are off-path, then Do53 interception= is *also* hard. So for this to be useful you need an environment in which = the attacker is able to attack Do53 but *not* to attack DHCP. What I'm = asking for is for someone to define that threat model precisely so that we = can design protocols that match it.
=
The various possible attacks in a home network are discussed= in=C2=A0https://tools.ietf.org/html/draft-btw-add-home-06#s= ection-9

As far as I = can tell, what this text says is that authenticating the server based on in= formation received in DHCP is not useful.

No, the draft discusses new=C2=A0DHCP/RA options to convey the DoH/DoT server do= main name. Section 9 discusses several attacks and mitigations the endpoint= can use to defend from an on-path attacker modifying the DHCP response.=C2= =A0
<= br>
(= 1) Attacker modifying the DHCP response to point to the DoH/DoT server host= ed by the attacker.=C2=A0
(2)=C2=A0Attacker modifying the DHCP response t= o point=C2=A0to a publ= ic DoH server not capable of filtering malware when the local resolver prov= ides malware filtering capability.=C2=A0

-Tiru


-Ekr
--000000000000b0fe0305a95b7cd7-- From nobody Tue Jun 30 23:48:03 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D61B3A0882 for ; Tue, 30 Jun 2020 23:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 g8LZusF6P5Py for ; Tue, 30 Jun 2020 23:48:00 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 D9F523A087C for ; Tue, 30 Jun 2020 23:47:59 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id t18so169530ilh.2 for ; Tue, 30 Jun 2020 23:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ImGsa6X3xpM0VJkG1Ycb/M21vg9XDGQYYvQhc+mwna8=; b=DI+nsBfORAEe3Qly0VgRewh9D5LMImDZNis5VO8TF2xypstu93lpo0E8hXUyMSC7H+ BI5fi8yBwVHRjZJThlIhXl/HKpX/n9zBxQ7WljHOn9BOPtTggubMevf1/PrP7yGD0lhH GFD9shsq++bSDLfw1hB5DqIUAZ4QnK+Qs59L/etFIYF0+Hfqy/tB0vxGGKOg9EZnF42s aW3Vxvr2uDjISVgUEcjktwCZcyY3Zluv2/v/zNVurf9eqQlNS4ikPkniSIwHQGWW6Ycs mUM0wJ+Q2INeD1KEtnZYeKOl9mHTV0as7khuMb+6W+rxQkIr0n9nxfwvAKo7SfIdWSFL bbLQ== 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:to:cc; bh=ImGsa6X3xpM0VJkG1Ycb/M21vg9XDGQYYvQhc+mwna8=; b=M+l9bN8wxRoLovpqesa1bUp6vnePR5EWHJMcCo79ACkT9XNg7FHzGX2gmIsihIXimg 1TgPZWjRg5aIDvmKkVX865H1a20xZNlHqjhI4U5/iKRSNG26CnnezSknN6Jw5868P97r zLvJQnruyDnWQ+/O/LZxW5mAvv3LLleW1Xjzn6sk22DO+/j+ygD/TDSKWtH9xkXi6iXg 3ZSNS5xsKi1W+rug/1OgC+savmz9Shv0R8MuI+QEOTFNgE2srn5ZOrAxP59omrzk4Vx7 qNZJlBFC8x97CA7hnwcZhuCGEbeXuhCkYz+d3cUQFBcvthp9ypMTmZX6BeJtQI7WLeGA oyrw== X-Gm-Message-State: AOAM532cilpLU9MbiiwwQPPNmJ/YYqN8gcwCpRQ5iKzeyPW0hzRbJ/MJ MmHO2jAo++9zvIs6biHH9VRB9106lzDKZ6W0kwA= X-Google-Smtp-Source: ABdhPJwnGzriXRHrM1XJeuZ/l6ByiIqndxso05s2R2V6sjyLi73vEM1dmqtuWpP0E+xN63HLxmhiTkT+mo3l+dBEjC0= X-Received: by 2002:a92:79cb:: with SMTP id u194mr6441958ilc.161.1593586079223; Tue, 30 Jun 2020 23:47:59 -0700 (PDT) MIME-Version: 1.0 References: <94C306DF-A9D9-4FAC-8C4B-AE3E90E29417@nbcuni.com> In-Reply-To: <94C306DF-A9D9-4FAC-8C4B-AE3E90E29417@nbcuni.com> From: tirumal reddy Date: Wed, 1 Jul 2020 12:17:48 +0530 Message-ID: To: "Deen, Glenn (NBCUniversal)" Cc: Rob Sayre , Eric Rescorla , ADD Mailing list , Paul Vixie , Vittorio Bertola Content-Type: multipart/alternative; boundary="0000000000002bd42b05a95bacd4" Archived-At: Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 06:48:02 -0000 --0000000000002bd42b05a95bacd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 1 Jul 2020 at 09:31, Deen, Glenn (NBCUniversal) < Glenn.Deen@nbcuni.com> wrote: > > > > > On Jun 30, 2020, at 8:31 PM, Rob Sayre wrote: > > =EF=BB=BF > On Tue, Jun 30, 2020 at 5:52 PM Eric Rescorla wrote: > >> >> >> On Tue, Jun 30, 2020 at 4:25 PM Deen, Glenn (NBCUniversal) < >> Glenn.Deen@nbcuni.com> wrote: >> >>> This all comes back to the three slices of access types that had been >>> discussed some months ago: >>> >>> >>> >>> 1. Trusted & known networks =E2=80=93 this is your enterprise, your = home. >>> You have a relationship with them. >>> 2. Unknown networks =E2=80=93 This is the caf=C3=A9, school, hotel -= you choose >>> them because they are available, but you know very little to nothing= about >>> them. >>> 3. Hostile networks =E2=80=93 you may not have any choice in network= and >>> must use this is you want any Internet access at all. However, not = only do >>> you not trust them, you know they are actively acting in ways you do= not >>> want. >>> >>> >>> >>> Another slice around threat levels would be: Green, Yellow, Red network= s >>> >>> >>> >>> Certainly in terms of policy and security concerns one size does not fi= t >>> all 3. The question is can we fashion a discovery means that works in = all >>> 3, but perhaps mitigates the policy and security concerns in each? >>> >>> >>> >>> DHCP may be a perfectly fine choice in a green network, but in a yellow >>> network there is a need for validation and assurance of the choice, whi= le >>> in a red network =E2=80=93 can you trust anything at all, even things y= ou >>> explicitly specified such as IP address of resolvers without some >>> additional validation ? >>> >> >> This is a great taxonomy. Thanks. >> >> I think the question I would ask is: in a green network, how much benefi= t >> do you get from Do[HT]? We can probably divide this up into the local >> network environment (e.g., the wireless network) and the access link fro= m >> the ISP. >> > > There are lots of attacks that create compromised "Green" networks. For > example: > > > https://www.zdnet.com/article/brazil-is-at-the-forefront-of-a-new-type-of= -router-attack > > I might categorize an "enterprise" network as something managed well > enough to do an investigation in the event of a security breach. Most > business and home networks do not fit this definition, so they are catego= ry > 2 ("Yellow"), because people set them up and forget them. > > > Should we design for the edge case where something bad happens, but is th= e > exception or should we design for the 99% case when the home network is > just fine? > > Granted hacks and attacks will happen, but while we should and do take > reasonable steps to mitigate obvious problems, most of the time and most = of > the experience of home networks is that they aren=E2=80=99t compromised a= nd behave > the way their users expect. > > If we classified networks based on the concern that something bad may > happen. Then everything would be yellow, or even red as it=E2=80=99s easy= to find > examples when bad things happened in any situation. Example: Home Depot w= as > compromised - thus corporate networks can=E2=80=99t be trusted. Example: = The NSA > was compromised - thus highly secured networks can=E2=80=99t be trusted. = Each such > reaction is a fearful over generalization of an incident and not the norm= al > expected state of such network types. > > If you look broadly at home networks the common generalized case is that > The vast majorityaren=E2=80=99t compromised and the configuration informa= tion from > the network can be trusted. > > So instead of designing for edge case of a previously trust network being > compromised , why not design for the more common state of the network bei= ng > trustworthy but and then add in some mechanism to verify the information > you get from it. Basically a version of the trust but verify approach, > which has been proven repeatedly as a reasonable strategy in the real wor= ld. > > For instance, if you get a DoH resolver from the green network, why not > trust but verify by checking the reasonableness of the answer you were > directed to? This could something like validating with DNSSEC or some > other validation method. > Good point. If the discovered DoH/DoT server is not pre-configure in the OS/Browser, https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-03 can be used by DNS client to authenticate it is connecting to a DoH/DoT server hosted by a specific organization (e.g., ISP). It is particularly useful when the DoH/DoT server is insecurely discovered, the discovered DoH/DoT server is not pre-configured as TRR and prevents the client from connecting to an attacker's DoH/DoT server. -Tiru > > This gets back to Ekr=E2=80=99s question of declaring what threats you a= re > actually worried about. > > -Glenn > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000002bd42b05a95bacd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 1 Jul 2020 at 09:31, Deen, Glenn = (NBCUniversal) <Glenn.Deen@nbcu= ni.com> wrote:




On Jun 30, 2020, at 8:31 PM, Rob Sayre <sayrer@gmail.com> wr= ote:

=EF=BB=BF
On Tue, Jun 30, 2020 at 5:52 PM Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Jun 30, 2020 at 4:25 PM Deen,= Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com> wrote:

This all comes= back to the three slices of access types that had been discussed some mont= hs ago:

=C2=A0<= u>

  1. Trusted= & known networks =E2=80=93 this is your enterprise, your home.=C2=A0 Y= ou have a relationship with them.
  2. Unknown networks =E2=80= =93 This is the caf=C3=A9, school, hotel - you choose them because they are= available, but you know very little to nothing about them.
  3. Hostile networks =E2=80=93 you may not have any choice in network and mu= st use this is you want any Internet access at all.=C2=A0 However, not only= do you not trust them, you know they are actively acting in ways you do not want.

=C2=A0<= u>

Another slice = around threat levels would be: Green, Yellow, Red networks

=C2=A0

Certainly in t= erms of policy and security concerns one size does not fit all 3.=C2=A0 The= question is can we fashion a discovery means that works in all 3, but perh= aps mitigates the policy and security concerns in each?

=C2=A0<= u>

DHCP may be a = perfectly fine choice in a green network, but in a yellow network there is = a need for validation and assurance of the choice, while in a red network = =E2=80=93 can you trust anything at all, even things you explicitly specified such as IP address of resolvers without so= me additional validation ?


This is a great taxonomy. Thanks.

I think the question I would ask is: in a green network, how much bene= fit do you get from Do[HT]? We can probably divide this up into the local n= etwork environment (e.g., the wireless network) and the access link from th= e ISP.=C2=A0

There are lots of attacks that create compromised "Green" ne= tworks. For example:


I might categorize an "enterprise" network as something mana= ged well enough to do an investigation in the event of a security breach. M= ost business and home networks do not fit this definition, so they are cate= gory 2 ("Yellow"), because people set them up and forget them.

Should we design for the edge c= ase where something bad happens, but is the exception or should we design f= or the 99% case when the home network is just fine?

Granted hacks and attacks will = happen, but while we should and do take reasonable steps to mitigate obviou= s problems, most of the time and most of the experience of home networks is= that they aren=E2=80=99t compromised and behave the way their users expect. =C2= =A0

If we classified networks based= on the concern that something bad may happen. Then everything would be yel= low, or even red as it=E2=80=99s easy to find examples when bad things happ= ened in any situation. Example: Home Depot was compromised - thus corporate networks can=E2=80=99= t be trusted. Example: The NSA was compromised - thus highly secured networ= ks can=E2=80=99t be trusted. Each such reaction is a fearful over generaliz= ation of an incident and not the normal expected state of such network types.

If you look broadly at home net= works the common generalized case is that The vast majorityaren=E2=80=99t c= ompromised and the configuration information from the network can be truste= d.

So instead of designing for edg= e case of a previously trust network being compromised , why not design for= the more common state of the network being trustworthy but and then add in= some mechanism to verify the information you get from it. Basically a version o= f the trust but verify approach, which has been proven repeatedly as a reas= onable strategy in the real world.

For instance, if you get a DoH = resolver from the green network, why not trust but verify by checking the r= easonableness of the answer you were directed to?=C2=A0 This could somethin= g like validating with DNSSEC or some other validation method.
=
Good point. If the discovered DoH/DoT server is not pre-conf= igure in the OS/Browser, https://tools.ietf.org/html/draft-reddy-ad= d-server-policy-selection-03 can be used by DNS client to authenticate = it is connecting to a DoH/DoT server hosted by a specific organization (e.g= ., ISP). It is particularly useful when the DoH/DoT server is insecurely di= scovered, the discovered DoH/DoT server is not pre-configured as TRR and pr= events the client from connecting to an attacker's DoH/DoT server.

-Tiru
=C2=A0

This gets back =C2=A0to Ekr=E2= =80=99s question of declaring what threats you are actually worried about.<= /div>

-Glenn=C2=A0
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000002bd42b05a95bacd4--